Erweiterte Entwurfskonzepte im Data Warehousing

Transkript

1 Universität Karlsruhe (TH) Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation (IPD) Hauptseminar Imperfektion und erweiterte Konzepte im Data Warehousing Erweiterte Entwurfskonzepte im Data Warehousing Seminararbeit von Yingzhe Liu Sommersemester 2005

2

3 Inhaltsverzeichnis Abbildungsverzeichnis iii 1 Erweiterte Entwurfskonzepte Einführung in DWS Denition DWS Anwendungsbereich Entwurfsgrundlagen für DWS Konzeptuelle Modellierung - ME/R-Modell Logische Modellierung Snowake-Schema Star-Schema Erweiterte Entwurfskonzepte konformierte Dimensionstabelle Erweiterte Dimensionstabelle Zusammenfassung Literaturverzeichnis 19 i

4

5 Abbildungsverzeichnis 1.1 Entwurfsprozess von Datenbanksystemen Grasche Notation der ME/R-Elemente Kaufhaus-Szenario in ME/R-Notation Snowake-Schema Snowake-Schema-Beispiel Star-Schema Star-Schema-Beispiel Speditionsszenario Speditionsszenario Speditionsszenario: konformierte Dimensionstabelle Many-to-many-Dimension Many-to-many-Dimension Many-to-many-Dimension Role-playing-Dimension Role-playing-Dimension Role-playing-Dimension iii

6

7 Yingzhe Liu 1 Erweiterte Entwurfskonzepte 1.1 Einführung in DWS Aufgrund der enormen operativen Datenmenge und dem Bedarf für Echtzeit- Reporting bzw. für die Auswertung durch OLAP (OnLine Analytical Processing) werden auf der Basis operativer Daten in betrieblichen Informationssystemen Data Warehouses immer mehr eingesetzt. Die Analyse bzw. Auswertung von umfangreichen Daten aus betrieblichen Informationssystemen stellt sich als Hauptzweck des Data Warehouse dar. In einem Data-Warehouse-System (DWS) sollen umfangreiche Datenbestände aus vielen verschiedenen Quellsystemen in passender Form zur Verfügung gestellt werden. Eine der zentralen Themen im Data Warehousing stellt die Modellierung der Datenstrukturen dar. In dieser Arbeit werden die Grundlagen auf Modellierungsebene im Data Warehousing, insbesondere die erweiterte konzeptuelle und logische Modellierung, erläutert. Vollständigkeitshalber wird zuerst die Begriichkeit im Bereich von Data- Warehouse-Systemen im Kapitel 1 vorgestellt. Kapitel 2 behandelt die grundlegenden Entwurfskonzepte für DWS. Anschlieÿend werden die erweiterten Entwurfskonzepte für DWS in Kapitel 3 vorgestellt. Zum Schluÿ werfen wir einen Blick auf verwandte Forschungen Denition DWS Data-Warehouse-Systeme repräsentieren ein analyseorientiertes Informationsystem einer Organisation. Eine ozielle Denition von Data Warehouse gibt es bis heute nicht. Die am häugsten zitierte Denition nach Bill Inmon [Imm96] lautet: 1

8 1 Erweiterte Entwurfskonzepte Denition (Data-Warehouse-System) A data warehouse is a subjectoriented, integrated, time-varying, non-volatile collection of data in support of the management s decision-making process. Ein Data Warehouse hat nach dieser Denition also vier Eigenschaften (siehe [BG01]), die alle der Entscheidungsunterstützung dienen: Fachorientierung Die Datenbasis dient also zur Modellierung eines spezischen Anwendungsziels. Integrierte Datenbasis Die Datenverarbeitung ndet auf integrierten Daten aus mehreren Datenbanken statt. Nicht üchtige Datenbasis Daten, die einmal in das Data Warehouse eingebracht wurden, werden kaum entfernt oder geändert. Historische Daten Die Daten werden über einen längeren Zeitraum gehalten. Der DW-Prozess, auch Data Warehousing genannt, beschreibt den dynamischen Vorgang: Datenbeschaungsprozess Datenspeichern Datenanalyse Ein Data-Warehouse-System enthält Systemkomponenten und einzelne, riesige Datenbanken. Ein Data Warehouse ist jedoch mehr als die Summe seiner Komponenten, d.h. erst mit dem Data-Warehouse-System kann es seine Aufgaben erfüllen Anwendungsbereich Der Hintergrund für DWS ist die Analysierbarkeit der Daten: eine homogene und integrierte Datenbasis, um eine eziente und zielorientierte Analyse durchzuführen. Im Folgenden werden drei häuge Anwendungsbereiche genannt. Betriebswirtschaftliche Anwendungsgebiete Die häugsten Einsatzbereiche benden sich zurzeit hier. Es gibt eigentlich keinen Bereich eines Unternehmens, in welchem auf Daten und Informationen für eine erfolgreiche Abwicklung der Geschäftsprozesse verzichtet werden kann. In diesem Bereich gibt es die vier Untergebiete: Informationsbereitstellung, Analyse, Planung und Kampagnenmanagement (siehe: [BG01]). Mit den dargestellten Informationen können qualizierte Anwender Analysen durchführen und weitergehende Erkenntnisse gewinnen. 2

9 1.2 Entwurfsgrundlagen für DWS Wissenschaftliche Anwendungsgebiete Aus diesem Bereich stammen auch die technischen Wurzeln der DW-Technologie, vor allem im Hinblick auf die datenbanktechnische Speicherung und Verarbeitung. Bei wissenschaftlichen, empirischen Untersuchungen fallen oft groÿe Mengen an Daten, beispielsweise Messwerte, an. Ein beispielhaftes Projekt lautet Earth Observing System [Mic91]. Technische Anwendungsgebiete Auch in technisch orientierten Anwendungsfeldern gibt es viele mögliche Verwendungszwecke. Wir erklären es durch ein paar Beispiele. Hier gelten die Mechanismen, die dem Data Warehousing zugrunde liegen, entsprechend. Eine Fabrik kann beispielsweise eine Sto- oder Materialdatenbank aufbauen, um die in Produkten verwendeten Materalien zu dokumentieren. So können die verantwortlichen Lieferanten bei Rückfrufaktionen oder Gewährleistungsfällen festgestellt werden. (siehe auch [BG01] in Kapitel 11.5). 1.2 Entwurfsgrundlagen für DWS Hier gehen wir zuerst auf den typischen Entwurfsprozess von Datenbanksystemen ein. Diesen zeigt Abbildung 1.1. Abbildung 1.1: Entwurfsprozess von Datenbanksystemen Im typischen Entwurfsprozess von Datenbanksystemen werden nach der Anforderungsanalyse die konzeptuelle und logische Datenbankmodellierung durchgeführt. Dabei werden die Anforderungen an das Datenbanksystem zuerst im konzeptuellen Schema und dann im logischen Schema abgebildet. Aus Sicht der Datenbanktheorie wird die konzeptuelle Modellierung eher auf einer von Zieldatenmodellen unabhängigen Ebene durchgeführt. Deshalb ist das konzeptuelle Schema unabhängig vom 3

10 1 Erweiterte Entwurfskonzepte konkret verwendeten Zieldatenmodell. Demgegenüber wird das logische Schema in einem konkreten Datenmodell dargestellt. Nach der Entscheidung für ein konkretes Datenbanksystem wird das interne Schema hergestellt (vgl. [Leh03]). Im klassischen relationalen Datenbankenentwurf ndet für die Erstellung des konzeptionellen Schemas meist eine Variante des Entity/Relationship-Modells (E/R- Modell) Anwendung. Das logische Datenschema wird dann formal im konkreten relationalen Datenmodell speziziert. Das relationale Datenmodell stellt dazu lediglich Relationen über Attribute als Ausdrucksmittel bereit. Die Schönheit eines logischen Schemas als Ergebnis des logischen Datenbankenentwurfs wird dabei formal quantizierbar durch den Grad der vorgenommenen Normalisierung bestimmt. Das interne Schema wird durch die Fähigkeiten des jeweiligen Datenbanksystems bestimmt (vgl. [BG01]). Der Entwurf von Data-Warehouse-Systemen wird in der Praxis analog wie der vorstehende Entwurfsprozess von klassischen Datenbanksystemen vorgehen. Die Frage hier ist aber, wie das Datenmodell in Data-Warehouse-Systemen aussehen soll und welche konzeptuelle und logische Modellierungsmethode in Data- Warehouse-Systemen eingesetzt werden sollen. In dieser Arbeit werden entsprechend folgende Fragen erklärt: Welche konzeptuellen Modellierungen von Data-Warehouse-Systemen existieren? Welche logischen Modellierungsschemata nden bei der Modellierung von Data-Warehouse-Systemen Anwendung? Was für erweiterte Konzepte sind in welchen Anwendungsfällen geeignet? Daraus ergibt sich als Zielsetzung dieses Kapitel, einen Überblick sowohl über die Grundlagen der konzeptuellen und logischen Modellierung von Data-Warehouse- Systemen als auch darüber hinausgehende erweiterte Konzepte zu geben Konzeptuelle Modellierung - ME/R-Modell Die ME/R-Notation (Multidimensional Entity/Relationship, [SBHD99]) wurde als spezielle Modellierungstechnik für multidimensionale Schemata entwickelt. Sie stellt eine Erweiterung des bekannten E/R-Ansatzes (Entity/Relationship, [Che76]) für relationale Schemata dar. Die Grundidee des ME/R-Ansatzes ist wie folgt: Um eine naturgemäÿe Darstellung der multidimensionalen Semantik zu erlauben, wird das E/R-Modell entsprechend spezialisiert und geringfügig erweitert. Zuerst sollen alle eingeführten Elemente der ME/R-Notation Spezialfälle der ursprünglichen E/R-Konstrukte sein, damit Leute, die mit dem E/R-Modell schon erfahren sind, auch das ME/R-Modell verstehen und benutzen können. Die Semantik muss die Unterscheidung zwischen Klassikationsschema, Würfelstruktur und die hierarchische Struktur der Klassikationen darstellen. Aus dieser Überlegung führt die ME/R-Notation folgende spezialisierte Konstrukte zusätzlich zur ursprünglichen E/R-Notation ein (siehe Abbildung 1.2): Eine spezielle Entitätenmenge Klassikationsstufe 4

11 1.2 Entwurfsgrundlagen für DWS Eine spezielle Entität Fakt Eine spezielle binäre Klassikationbeziehung zur Verbindung von Klassikationsstufen. Eine aus E/R übernommene Faktbeziehung, um Fakten und Dimensionen zu verbinden. Die Klassikationsbeziehung verbindet eine Dimensionsstufe A mit einer Dimensionsstufe B, welche eine höherwertige Abstraktionsebene darstellt. Beispielsweise werden Städte nach Ländern klassiziert. Aufgrund der speziellen Semantik der Klassikationsbeziehung dürfen keine Zyklen im so genannten Klassikationsgraphen existieren (vgl. [BG01]). Abbildung 1.2: Grasche Notation der ME/R-Elemente Die Faktbeziehung stammt aus einer allgemeinen n-ären Beziehung im E/R- Modell und wird hier spezialisiert. Durch sie werden n verschiedene Entitäten von Klassikationsstufen verbunden. Solche Beziehungen stellen ein Fakt der Dimensionalität n dar und bilden einen Würfel. Eine Beschreibung des Fakts verwenden wir als Name der Menge. Die unmittelbar verbundenen Klassikationsstufen nennen wir atomare Klassikationsstufen. Die Faktbeziehung modelliert die inhärente Trennung zwischen Dimension und Würfelzellen und somit die Struktur des Würfels. Die Attribute der Faktbeziehung modellieren die Kenngröÿen der Fakten, wogegen die Klassikationsstufen die qualizierenden Daten darstellen (vgl. [BG01]). Beispiel Wir betrachten eine Verkaufsanalyse. Kenngröÿen können z. B. Verkaufszahlen oder der Umsatz sein. Als Dimension dienen Produkt, Geographie und Zeit. Innerhalb einer Dimension sind auch Alternativpfade der Klassikationsbeziehungen möglich. Abbildung 1.3 zeigt solche Alternativpfade bei der Zeitdimension. Wochen sind somit nicht mehr eindeutig zu Quartalen oder Jahren zusammengefasst. 5

12 1 Erweiterte Entwurfskonzepte Abbildung 1.3: Kaufhaus-Szenario in ME/R-Notation Logische Modellierung Nach der konzeptuellen Modellierung ist eine formale Beschreibung des multidimensionalen Datenmodells für Data-Warehouse-Systeme dringend nötig. Zunächst müssen die verwendeten Basiskonstrukte und deren Beziehungen formal beschrieben werden. Das Pendant im relationalen Datenmodell ist die formale Denition einer Relation, eines Relationenschemas, einer Domäne etc. Im Falle des multidimensionalen Paradigmas sind die zu formalisierenden Entitäten Datenwürfel, Dimensionen etc. ([BG01]). In den folgenden zwei Kapiteln werden zwei verschiedene Verfahren, die das systemunabhängige konzeptuelle Modell in ein logisch eingesetztes Modell verwandeln, vorgestellt. Die Vorgehendsweise ist etwas anders als im relationalen Modell. Der Hauptunterschied zwischen dem multidimensionalen und relationalen Modell ist die zusätzliche Semantik, durch die die Beziehungen zwischen den Klassikationsstufen einer Dimension untereinander, zwischen den Würfeln und den Klassikationsstufen seiner Dimensionen sowie zwischen verschiedenen Würfeln zum Bestandteil des Modells gemacht werden Snowake-Schema Die Klassikationen im ME/R-Modell können direkt in einer relationalen Datenbank umgesetzt werden. Dies realisiert man durch die Zuordnung einer eigenen Tabelle für jede Klassikationsstufe. Diese Tabelle enthält neben der ID für die Klassikationsknoten dieser Klassikationsstufe auch die beschreibenden Attribute und Fremdschlüssel der direkt benachbarten höheren Klassikationsstufen. Abbildung 1.4 verdeutlicht das Snowake-Schema. Die Kenngröÿen eines Datenwürfels werden innerhalb einer Faktentabelle verwaltet. Diese wird nach obigem Schema konstruiert, d.h., neben einer Spalte für jede Kenngröÿe enthält sie Fremd- 6

13 1.2 Entwurfsgrundlagen für DWS schlüsselbeziehungen zu den jeweils niedrigsten Klassikationsstufen der verschiedenen Dimensionen, gemäÿ der Granularität des Datenwürfels. Die Fremdschlüssel entsprechen den Zellkoordinaten in der multidimensionalen Datensicht. Sie bilden daher den zusammengesetzten Primärschlüssel für die Faktentabelle (siehe [Lin03]). Abbildung 1.4: Snowake-Schema Die hierarchischen Klassikationsstufen lassen sich am besten mit einem Beispiel verdeutlichen. Abbildung 1.5 zeigt eine Umsetzung in einem Speditionsunternehmen nach diesem Muster. Die Namensgeber vergleichen diese Variante mit dem Kristall einer Schneeocke. Damit werden n:m-beziehungen zwischen Hierarchieobjekten besser unterstürtzt, Aggregate optimal benutzt. Redundanz verschwindet auch. Auf der Schattenseite entsteht hier ein komplexeres Modell, welches für den Benutzer das Verständnis erschwert und bei der Anfrage kompliziert erscheint. Wie in Abbildung 1.4 gezeigt, sind bei Snowake-Schema alle Tabellen in Normalform. Bei einer Anfrage werden viele Join-Operationen ausgeführt, um viele Tabellen miteinander zu verbinden. Weil solche Verbindungen besonders zeitaufwändig sind, wird stattdessen in Data- Warehouse-Systemen häug das Star-Schema benutzt Star-Schema Im Star-Schema werden alle Dimensionsstufen, die zu einer Dimension gehören zu einer Dimensionstabelle zusammengefügt. Dies führt zur Denormalisierung der Dimensionstabelle, um eine schnellere Anfragebearbeitung zu erreichen. Eine Fak- 7

14 1 Erweiterte Entwurfskonzepte Abbildung 1.5: Snowake-Schema-Beispiel tentabelle wird mit N Dimensionen assoziiert. Im Modell ergibt sich dann ein Stern: die Faktentabelle steht im Mittelpunkt des Sternes, die dazugehörigen Dimensionen bilden die Strahlen des Sternes, daher kommt der Name Star-Schema. Innerhalb eines Star-Schemas gibt es für jede Dimension genau eine Dimensionstabelle. Abbildung 1.6 zeigt den prinzipiellen Aufbau eines Star-Schemas und Abbildung 1.7 repräsentiert das bereits ernannte Beispiel Spedition im Star-Schema. In Abbildung 1.7 sind die Klassikationsschemata der Zeit-, Produkt- und Geographiedimension dargestellt. Fahrzeug, Spedition, Landkreis, Regierungsbezirk, Bundesland und Staat werden im Star-Schema zu einer einzigen Dimensionstabelle Fahrzeug zusammengefsst. Die Fremdschlüssel der Faktentabelle sind mit der niedrigsten Granularität bezeichnet (z. B. FahrzeugID). In einem Star-Schema ist die Faktentabelle wie im Snowake-Schema normalisiert, demgegenüber sind die Dimensionstabellen nicht normalisiert. Demzufolge gibt es viele Redundanzen innerhalb der Dimensionstabellen. Die funktionalen Abhängigkeiten zwischen den Klassikationsstufen werden bei dieser Abbildung nicht sichtbar. Die Argumentation, wann und warum ein Star-Schema trotzdem dem Snowake- Schema vorzuziehen ist, stützt sich auf folgende Heuristiken über die Charakteristika von Data-Warehouse-Systemen (siehe [Lin03]): Schnellere Anfragebeantwortung. Anfragen werden auf höherer Granularitätsstufe (zum Beispiel Produktkategorie) eingeschränkt. Die aufwändigen Verbindungsopreationen zwischen verschiedenen Tabellen einer Dimension beim Snowake-Schema werden durch die Denormalisierung gespart. Erträglicher Speicheraufwand für Dimensionstabellen. 8

15 1.2 Entwurfsgrundlagen für DWS Abbildung 1.6: Star-Schema Abbildung 1.7: Star-Schema-Beispiel 9

16 1 Erweiterte Entwurfskonzepte Das Datenvolumen der Dimensionstabellen mit den Klassikationshierarchien ist relativ gering im Vergleich zum gesamten Volumen der Zellinhalte (Gröÿe der Faktentabelle). Das Datenvolumen wird somit durch die Denormalisierung insgesamt nicht dramastisch erhöht. Wenige Änderungen im Dimensionstabellen. Die Dimensionenstabellen werden seltener verändert als das Hinzufügen von neuen Faktendaten. Zusammenfassend besitzt das Star-Schema also folgende Eigenschaften, die es für Anwendungen geeignet erscheinen lassen: Einfache Struktur: Anfragen werden dadurch einfacher und lassen sich leichter formulieren. Einfache und exible Darstellung von Klassikationshierarchien: Klassikationshierarchien werden einfach innerhalb von Dimensionstabellen als Spalten angegeben. Eziente Anfrageverarbeitung innerhalb der Dimensionen: Die Selektionsprädikate, die höhere Dimensionsstufen zur Einschränkung verwenden, benötigen keine Verbindungsoperationen, um die Menge von Tupeln zu bestimmen, die mit der Faktentabellen verbunden werden müssen. Ob die Vorteile des Snowake-Schemas wie z. B. geringerer Speicherplatzbedarf und bessere Änderungsfreundlichkeit überwiegend oder das Star-Schema besser geeignet ist, hängt stark von den konkreten Daten- und Anfragecharakteristiken. 1.3 Erweiterte Entwurfskonzepte Wir werden hier die für das Data Warehousing bedeutendsten erweiterten Entwurfskonzepte: konformierte Dimensionstabelle und erweiterte Dimensionstabelle verdeutlichen konformierte Dimensionstabelle Der Leser wird sich hier vielleicht die Frage stellen: Was ist denn eine konformierte Dimensionstabelle? Dies stammt aus einem englischen Begri (vgl. Denition 1.3.1). Denition A conformed dimension is a dimension that means the same thing with every possible fact table to which it can be joined.[krrt98] Das heiÿt im Allgemeinen, dass eine konformierte Dimension mit allen benötigten Faktentabellen identisch verwendet werden kann. Das erklären wir in einem einfachen Beispiel. 10

17 1.3 Erweiterte Entwurfskonzepte Wir nehmen wieder das obige Szenario aus Abschnitt in einem Speditionsunternehmen. In der Faktentabelle in Abbildung 1.8 sind die Daten enthalten, welches Fahrzeug an welchem Tag welche Produkte transportiert hat. Abbildung 1.8: Speditionsszenario 1 Für die Abteilung, die die Aufträge an die Mitarbeiter verteilt, fügen wir zusätzlich eine Faktentabelle hinzu (siehe Abbildung 1.9). Darin werden die Daten gespeichert, wer welchen Auftrag mit welchem Fahrzeug ausführt. Abbildung 1.9: Speditionsszenario 2 Dieselbe Dimension Fahrzeug hat in beiden Fällen unterschiedliche Einträge, was aufgrund verschiedener Einsatzmöglichkeiten in verschiedenen Abteilungen gerecht ist. Soll es dann zwei Dimensionen Fahrzeug in demselben Unternehmen geben? 11

18 1 Erweiterte Entwurfskonzepte Wir wissen doch, dass die beiden Dimensionen im Unternehmen eigentlich dasselbe meinen. Somit passen wir die Dimension Fahrzeug so an, dass sie in beiden Fällen eingesetzt werden kann. Abbildung 1.10 stellt die angepasste Dimension Fahrzeug dar. Alle Attribute werden in einer konformierten Dimension gespeichert. Abbildung 1.10: Speditionsszenario: konformierte Dimensionstabelle Diese Vorgehensweise bietet reichlich Vorteile: Es ist nur eine einzige Dimension zu pegen und sie ist mit jeder Faktentabelle (bei gleicher Granularität) verwendbar Erweiterte Dimensionstabelle In diesem Kapitel beschreiben wir zwei normale Modellierungssituationen, wo eine spezische Dimensionsstruktur sehr ezient ist. Many-to-many-Dimension In vielen klassischen Modellierungssituationen sind die Existenz und die Granularität einer Faktentabelle verständlich und fundamental. Die Zuordnung der Dimensionstabellen zu Faktentabellen sind auch trivial. Aber eine Dimension kann auch mehrere Werte haben und die Anzahl der möglichen Werte für diese Dimension ist eventuell unbekannt, wenn die Faktentabelle erstellt wird. Solch eine Dimension nennen wir Many-to-many-Dimension. Patientendaten in einer Praxis liefern ein gutes Beispiel (siehe Abbildung 1.11). Alle Patientendaten inkl. die zugehörigen Personaldaten, Diagnosen und Zeitangaben werden in einer Patient-Faktentabelle abgespeichert. Das Problem ist, was mit der Diagnosentabelle passiert. Oft hat ein Patient mehrere Diagnosen. Eine mögliche Lösung zeigt uns die Abbildung 1.12: für jede Diagnose eine eigene Dimension. Diese Lösung ist nicht realistisch. Der Grund ist: 12

19 1.3 Erweiterte Entwurfskonzepte Abbildung 1.11: Many-to-many-Dimension 1 Abbildung 1.12: Many-to-many-Dimension 2 13

20 1 Erweiterte Entwurfskonzepte 1. Wir kennen die obere Schranke der Diagnosenanzahl nicht. 2. So ein Schema würde beim Abfragen (zum Beispiel: join) sehr langsam sein. Eine bessere Lösung ist, zwischen der Faktentabelle und der Diagnose-Dimension eine Brückentabelle hinzufügen (siehe Abbildung 1.13). In der Brückentabelle generieren wir die originale DiagnoseID in der Faktentabelle zu einer spezialen Diagnose- GruppeID. Die Diagnosengruppe-Tabelle, also unsere Brückentabelle, enthält eine spezische Menge von Einträgen für jeden Patienten. Jeder Eintrag enthält wieder die DiagnoseGruppeID, eine individuelle DiagnoseID und einen Gewichtungsfaktor. In einer gegebenen Diagnosengruppe muss die Summe aller Gewichtungsfaktoren 1,00 sein. Abbildung 1.13: Many-to-many-Dimension 3 Die Lösung mit einer zusätzlichen Brücktabelle ist nicht perfekt. Mit einem Beispiel verdeutlichen wir die Schwierigkeiten bei Brückentabellen. Beispiel Annahme: eine Diagnosentabelle hat 1k Einträge und jeder Eintrag hat 10kByte. Speicheraufwand: 10MB eine Faktentabelle hat 100k Einträge und jeder Eintrag hat 1kByte. Speicheraufwand: 100MB in einer Brückentabelle hat jeder Eintrag 50Byte. Dann muss man bei einer zusätzlichen Brückentabelle mit folgendem zusätzlichen Speicheraufwand (siehe Tabelle 1.1) rechnen: Speicheraufwand = alle Fakten Diag/Pat. Gröÿe eines Eintrags 14

21 Speicheraufwand Diag./Pat. 50MB MB MB 100 Tabelle 1.1: Speicheraufwand der Brückentabelle 1.3 Erweiterte Entwurfskonzepte Wie gezeigt verursacht die Erhöhung der Diagnosenanzahl einen entsprechend höheren Speicheraufwand. Deshalb ist die Lösung mit einer Brückentabelle bei extrem gestiegener Diagnosenanzahl (was zwar selten auftritt, aber nicht ausgeschlossen werden kann) auch nicht mehr akzeptabel. Role-Playing-Dimension Eine role in einem Data Warehouse ist eine Situation, wo eine einzelne Dimension mehrmals in derselben Faktentabelle auftritt. Abbildung 1.14 liefert wieder ein Beispiel aus einer Klinik. Abbildung 1.14: Role-playing-Dimension 1 In der Faktentabelle kann das Datum mehrfach auftauchen. Zum Beispiel hat ein Patient ein Operationsdatum und ein Rechnungsdatum. Anfrage: select * from Patient where OpZeitID= and RechZeitID= Da wir nur eine Zeitdimension haben, versucht SQL in so einem Join alle Daten gleichzustellen. Das ist aber nicht gewünscht. Eine mögliche Lösung (siehe Abbildung 1.15) wäre, verschiedene Dimensionen zu verwenden, da sie ja auch verschiedene Rollen spielen. Diese intuitive Lösung hat folgende Nachteile: 15

22 1 Erweiterte Entwurfskonzepte Alle Zeitdimensionen werden zwar unterschiedlich benannt. Sie müssen aber konsistent gehalten werden, weil sie immerhin die gleiche Domäne haben müssen. In einer komplizierten Umgebung (zum Beispiel Telekommunikationsindustrie) müssen mehrere verschiedene partiell überlappende Tabellen gehalten werden. Hier verursacht obige Lösung extrem hohen Wartungsaufwand. Abbildung 1.15: Role-playing-Dimension 2 Durch Einsatz von Sichten auf dieselbe Dimension kann eine bessere Lösung geliefert werden. Es ist zu beachten, dass jede Sicht auf eine Dimension eindeutige Spaltennamen benötigt. Abbildung 1.16 verdeutlicht die Vorgehensweise. Abbildung 1.16: Role-playing-Dimension Zusammenfassung In dieser Arbeit haben wir gemeinsam die benötigten Grundlagen beim Data- Warehouse-Entwurf und anschlieÿend die passenden Techniken in vielen allgemeingültigen Fällen kennengelernt. Hier muss man betonen, dass das Star-Schema aufgrund seiner schnellen Anfragebeantwortung und einfachen Struktur zwar überwiegend verwendet wird, um eine relativ optimale Struktur zu bekommen, aber 16

23 1.4 Zusammenfassung in der Praxis fast immer zusätzliche Techniken, sogenannte erweiterte Konzepte, notwendig sind. Konformierte Dimensionen sind eine der grundlegenden Techniken. In manchen Fällen kann man auch analog konformierte Fakten verwenden. Bei Many-to-many- Dimension oder Role-playing-Dimension benutzen wir erweiterte Dimensionstabellen. In anderen Fällen zum Beispiel Time-of-Day und Value-Band-Reporting ist der Einsatz der sogenannten erweiterten Faktentabelle von Vorteil (siehe [KRRT98]). 17

24

25 Literaturverzeichnis [BG01] [Che76] [Imm96] Andreas Bauer and Holger Günzel. Data-Warehouse-Systeme. dpunkt, Heidelberg, Peter Pin-Shan Chen. The Entity-Relationship ModelToward a Uni- ed View of Data. ACM Trans. Database Syst., 1(1):936, W. H. Immon. Building the Data Warehouse. Second Edition. John Wiley & Sons, New York, [KRRT98] R. Kimball, L. Reeves, M. Ross, and W. Thornthwaite. Warehause Lifecycle Toolkit. John Wiley & Sons, [Leh03] The Data Wolfgang Lehner. Datenbanktechnologie für Data-Warehouse-Systeme, Konzepte und Methoden. dpunkt, [Lin03] Kong Ling. Konzeptuelle und logische Modellierung eines Data- Warehouse-Systems. Seminararbeit, Seminar: Data Warehousing im Verkehrsbereich, IPD, Fakultät für Informatik, Universität Karlsruhe (TH), [Mic91] Z. Michalewicz. Statistical and scientic databases. In Series in Computers and Their Applications. Ellis Horwood, [SBHD99] C. Sapia, M. Blaschka, G. Höing, and B. Dinter. Extending the e/r model for the multidimensional paradigm. In Kambayashi Y. et. Al., editor, Advances in Database Technologies, volume LNCS Springer,