Die Besonderheit von Data-Warehouse-Projekten im Vergleich zu herkömmlichen Verwaltungsanwendungen zeigt sich auch in einer anderen Technik der Datenmodellierung. Im Entscheidungsumfeld werden die Daten so organisiert, dass sie direkt auf die typischen Anfragen des Endnutzers antworten. Um den vollständigen Text herunterzuladen und weitere Informationen zu erhalten, klicken Sie HIER
Nehmen wir zum Beispiel an, dass das Ziel des Benutzers darin besteht, im Zeitverlauf die Planung und Umsetzung von Investitionsprojekten zu überwachen, die öffentliche Finanzmittel verwenden, an verschiedenen Orten im Nationalgebiet liegen und mit unterschiedlichen Tätigkeitsbereichen verbunden sind. Vereinfacht ausgedrückt, kann man sich vorstellen, diese Aktivität durch einen Würfel darzustellen, dessen Seiten die Variablen Zeit, Ort und Tätigkeitsklassifizierung in Bezug auf die Projekte wiedergeben. Jeder Punkt innerhalb des Würfels ist die Schnittmenge der Koordinaten, die durch die Seiten des Würfels definiert sind, und stellt das Maß des interessierenden Sachverhalts (das Projekt und seine Finanzierung) für die jeweilige Kombination aus Ort, Tätigkeitsbereich und Zeit dar, welche die Dimensionen der Analyse repräsentieren. Im Data Warehouse-Bereich spricht man somit von dimensionaler Datenmodellierung. Das dimensionale Modell und das traditionelle Entity-Relationship-Modell sind potenziell in der Lage, dieselben Informationen zu speichern. Der Unterschied liegt in der Suche nach optimaler Performance in beiden Umgebungen. In operativen Umgebungen ist es entscheidend, Normalisierungstechniken anzuwenden, die durch die Eliminierung von Redundanzen eine große Anzahl an wiederholten Transaktionen ermöglichen, Informationen an einem einzigen Punkt der Datenbank abzufragen und zu aktualisieren. Entscheidungsunterstützungssysteme hingegen zeichnen sich durch eine geringe Anzahl an Transaktionen aus, die jedoch transversal auf der Datenbasis operieren und den Lesezugriff auf eine große Menge an Daten erfordern, die verknüpft werden müssen. Die Verwendung von Normalisierungstechniken erweist sich daher bei der Gestaltung eines Data Warehouse-Systems als kontraproduktiv. Im Entscheidungsbereich ist es korrekter, die Datenbank so zu gestalten, dass die spezifischen Bedürfnisse der Endnutzer direkt und vereinfacht erfüllt werden, auch durch den Einsatz von denormalisierten und aggregierten Daten. Es ist wichtig, der Analyse des konzeptionellen Modells viel Aufmerksamkeit zu widmen, indem alle Analyse-Dimensionen und die dazugehörigen Attribute für jede Dimension vorgesehen werden. Die Attribute der Dimensions-Tabellen werden direkt als Suchkriterien in Abfragen auf das Data Warehouse und als Spaltenüberschriften in den Berichten der Endnutzer verwendet. Die Verwendung von voraggregierten und zusammengefassten Daten begrenzt die Anzahl der für die Rekonstruktion der gewünschten Information erforderlichen Operationen. Das Star-Schema ist neben der Optimierung für Abfragen auch vorteilhaft, da es eine grafische Darstellung des Geschäftsprozesses ermöglicht, die für den Endnutzer leichter verständlich ist. Im Gegensatz zum Entity-Relationship-Schema, bei dem alle Entitäten auf die gleiche Weise dargestellt werden, ist das Star-Schema asymmetrisch. Im Mittelpunkt des Diagramms steht eine große dominante Tabelle, die als einzige mehrere Verbindungen enthält, die sich in Schlüsselfeldern äußern und zu den anderen Tabellen führen. Die übrigen Tabellen repräsentieren die Analysekriterien, durch welche das betrachtete „Faktum“ analysiert wird. Technisch wird die zentrale Tabelle als „Fact Table“ und die anderen als „Dimension Table“ bezeichnet. Die Fact Table speichert die numerischen Messwerte des Fakts (im Beispiel den Betrag der Investitionsprojektförderung), von denen jede die Schnittmenge aller Dimensionen darstellt und eine oder mehrere Variablen quantifiziert. Normalerweise ist sie die einzige normalisierte Tabelle. Die anderen Tabellen stellen die Dimensionen der Analyse dar und enthalten beschreibende Attribute. Die Kardinalität dieser normalerweise denormalisierten Tabellen ist begrenzt. Unter den Dimensionstabellen ist die Zeit-Dimensionstabelle stets in dimensionalen Modellen vorhanden, unabhängig vom abzubildenden Geschäft. Dies resultiert aus der Eigenschaft von Data Warehouse-Systemen, auch historische Informationen zu verwalten. Manchmal, zur weiteren Verbesserung der Interpretierbarkeit des Modells, werden auch die Dimensionstabellen normalisiert, indem Hierarchien explizit gemacht werden. Dies führt zu einem sogenannten „Schneeflocken-Schema“ (Snowflake Schema). Die Navigation der Daten durch das Snowflake-Modell ist weniger effizient als im Star-Schema, da sich die Anzahl der Tabellen, über die Join-Operationen ausgeführt werden müssen, erhöht. Es ist zu beachten, dass zwar die Denormalisierung im Abfragebetrieb bessere Leistungen sichert, sie aber auch die Aktualisierung und das Laden der Daten erschwert. Allgemein erfordern Wartungsoperationen am multidimensionalen Datenmodell, wie das Hinzufügen neuer Analyse-Dimensionen, das Neuladen („ex novo“) der Datenbasis. Deshalb muss stets der Kompromiss zwischen diesen beiden Anforderungen abgewogen und je nach Fall entweder das Star Schema oder das Snowflake Schema verwendet werden. Weiterhin ist zu erwähnen, dass bei sehr komplexen Modellen mit mehreren Fact Tables, die viele Dimensionen gemeinsam nutzen, der Einsatz der dimensionalen Technik schwierig wird, auch weil nicht immer klar ist, welche Tabellen Fakten- und welche Dimensionstabellen sind. Für das konzeptionelle Design des Enterprise Data Warehouse ist daher ein denormalisiertes Entity-Relationship-Datenmodell vorzuziehen. Die dimensionale Modellierung eignet sich hingegen zweifellos besser für die Darstellung von Daten in Data Marts. Dimensionale Modelle können sowohl auf relationalen DBMS als auch auf speziellen multidimensionalen DBMS implementiert werden. ALLE RECHTE VORBEHALTEN
Pubblicato in Geschäft
Hinterlasse jetzt einen Kommentar