Inhalt. 4.1 Motivation. 4.2 Datenintegration. 4.3 Konzeptuelle Modellierung. 4.4 Anfragen an Data Warehouses. 4.5 Implementierungsaspekte

Transkript

1 4. Data arehouses

2 Inhalt 4. Motivation 4.2 Datenintegration 4.3 Konzeptuelle Modellierung 4.4 Anfragen an Data arehouses 4.5 Implementierungsaspekte 2

3 Literatur V. Köppen, G. Saake und K.-U. Sattler: Data arehouse Technologien, mitp Professional, Andreas Bauer und Holger Günzel: Data arehouse Systeme, dpunkt.verlag, 203 3

4 4. Motivation Vielzahl von operativen Systemen in Unternehmen Einkauf/Verkauf von Lieferanten/Kunden Kundenverwaltung (Adressen, Beschwerden) Organisation (Mitarbeiter, Abteilungen) Marketing (Management von Kampagnen) Unternehmenssteuerung (management) benötigt ganzheitliche Sicht auf Unternehmensdaten, um analytische Fragen zu beantworten und Entscheidungen zu treffen 4

5 Online Transaction Processing (OLTP) Online Transaction Processing (OLTP) zur raschen Bearbeitung von Transaktionen aus operativen Systemen Transaktionen betreffen nur einen kleinen Teil der Daten Mitarbeiter stoßen Transaktionen im Tagesgeschäft bei Verwendung der operativen Systeme an Beispiele: Zeige Daten zu Kunde mit KundenNr an Füge neue Bestellung mit Bestellpositionen ein RDBMS sind für diese Art von Transaktionen optimiert 5

6 Online Analytical Processing (OLAP) Online Analytical Processing (OLAP) zur raschen Bearbeitung von analytischen Transaktionen Transaktionen betreffen u.u. einen großen Teil der Daten Ursprung der Transaktionen sind analytische Fragen, die in der Unternehmenssteuerung entstehen Beispiele: Umsatzentwicklung von Produkt B in den letzten 0 Jahren Gewinn nach Bundesland und Produktkategorie in den letzten 6 Quartalen 6

7 Data arehouses Data arehouses (Ds) haben sich als eigenständige Systeme zur Unterstützung von OLAP etabliert Ds als eigenständige Systeme, um Beeinträchtigung der operativen Systeme durch Anfragen zu vermeiden Ds müssen Daten aus den verschiedenen operativen Systemen und evtl. externen Datenquellen integrieren 7

8 Datenquellen Ds integrieren Daten aus verschiedenen Quellen operative Systeme (z.b. Einkauf/Verkauf, Organisation) externe Datenquellen (z.b. statistische Daten, etterdaten) Datenintegration stößt auf viele Herausforderungen Verknüpfung von Datensätzen (z.b. nach Akquisition) Datenqualität (z.b. Eingabefehler, fehlende Attribute) Duplikate (z.b. doppelte Kundeneinträge) Effizienz (z.b. inkrementelle Integration, Bulk-Loading) 8

9 Basisdatenbank und Datenwürfel Terminologie im Bereich Data arehouses uneinheitlich; wir orientieren uns an der in [2] vorgeschlagenen Datenintegration führt zu einer Basisdatenbank (BDB), in der alle relevanten Rohdaten zusammengeführt sind Datenwürfel (data cubes) werden aus BDB abgeleitet; sie stellen betriebswirtschaftliche Fakten (z.b. Umsatz) mehrdimensional (z.b. Produkt, Zeitraum, Region) dar 9

10 Datenwürfel Produkt Kategorie Gruppe Artikel Kennzahl Umsatz Zeit Jahr Quartal Monat Filiale Stadt Verkaufsort Bundesland Quelle: Köppen, Saake und Sattler [2, S.46] 0

11 Data Marts und Data arehouse Data Marts sind definierte Sichten (z.b. für eine Sparte oder ein Vertriebsgebiet) auf Datenwürfeln und/oder BDB Data arehouse bezeichnet Gesamtheit aus Basisdatenbank, Datenwürfeln sowie Data Marts

12 2 OLAP-Regeln nach Codd E. F. Codd hat 993 einen Katalog von Anforderungen formuliert, die OLAP-Systeme erfüllen müssen. Multidimensionale Sicht auf Kennzahlen (z.b. Umsatz), die in verschiedenen Dimension (z.b. Zeit) aggregiert und gruppiert werden 2. Transparenz Implementierung bleibt dem Benutzer verborgen 3. OLAP-Zugriffe Zugriffsschnittstelle ist auf OLAP-Analysen zugeschnitten 4. Performanz Leistung des Data-arehouse-Systems ist unempfindlich gegenüber Anzahl von Dimensionen 2

13 2 OLAP-Regeln nach Codd 5. Skalierbarkeit Nutzung von verteilten Architekturen zum Umgang mit sehr großen Datenmengen 6. Generische Dimensionalität Dimensionen gleich behandelt und organisiert 7. Dünnbesetzte Strukturen Effizienter Umgang mit dünnbesetzten Datenwürfeln durch geeignete Daten- und Indexstrukturen 8. Mehrbenutzerbetrieb Konfliktfreier Betrieb mit mehreren Benutzern 3

14 2 OLAP-Regeln nach Codd 9. Uneingeschränkte Operationen Auf Datenwürfel definierte Operatoren werden umgesetzt 0. Intuitive Benutzeroberflächen Benutzeroberfläche soll intuitiv sein und z.b. eine Navigation entlang der Dimensionshierarchien erlauben. Flexibles Reporting Tabellarische, aber auch zwei- oder mehrdimensionale Reports (Berichte) müssen frei konfigurierbar sein 2. Beliebig viele Dimensionen und Aggregationsebenen Keinerlei Einschränkungen bzgl. Anzahl von Dimensionen und Tiefe der Dimensionshierarchien 4

15 FASMI-Anforderungen Pendse und Creeth haben folgende Anforderungen an Data-arehouse-Systeme formuliert Fast, d.h. kurze Antwortzeiten, die dem Benutzer ein interaktives Arbeiten ermöglichen (weniger als 5 Sekunden) Analysis, d.h. es muss eine adäquate auf analytische Fragestellungen ausgerichtete Schnittstelle bereitstehen Shared, d.h. das System muss mehrere Benutzer erlauben und ihre heterogenen Anforderungen unterstützen 5

16 FASMI-Anforderungen Multidimensional, d.h. das konzeptionelle Datenmodell muss die inhärente Multidimensionalität der analytischen Fragestellungen berücksichtigen Information, d.h. das System muss alle für die Analysen benötigten Daten zusammenführen und verwalten 6

17 4.2 Datenintegration Daten werden im Rahmen eines ETL-Prozesses aus operativen Systemen ins Data arehouse überführt Extraktionsphase identifiziert regelmäßig zu übernehmende Änderungen in den Datenquellen Transformationsphase behebt Daten- und Schemakonflikte zwischen Datenquelle und Basisdatenbank Ladephase bringt die transformierten Daten effizient (z.b. mittels Bulk-Loading) in die Basisdatenbank ein 7

18 Datenqualität und Datenbereinigung Mangelnde Qualität der Daten aus den verschiedenen Datenquellen machen eine Bereinigung notwendig Vereinheitlichung von Datentypen und Format (z.b. Name) Erkennen und Zusammenführen von Duplikaten Eindeutigkeit verletzt Unterschiedliche Repräsentation idersprüchliche erte Referentielle Integrität verletzt unvollständig Person KNr Name Geb.datum Alter Geschl. Telefon PLZ 34 Meier, Tom M Tina Möller Tom Meier F null null t@r.de Ort PLZ Ort Magdeburg Spanien Illmenau Falsche oder unzulässige erte Fehlende erte (z.b. Default-erte) Duplikate Schreib- oder Tippfehler Quelle: Köppen, Saake und Sattler [2, S.82] 8

19 Duplikatenerkennung Duplikatenerkennung mittels einer Vergleichsfunktion, welche die Ähnlichkeit von zwei Datensätzen misst Editierdistanzen für textuelle Attribute Numerischen Distanzen für numerische Attribute Paare von Datensätzen deren Ähnlichkeit über einem Schwellwert liegt, werden zusammengefasst Verfahren versuchen durch geschicktes Abschätzen von Ähnlichkeiten oder Sortieren möglichst weniger als O(n 2 ) Vergleiche durchzuführen 9

20 Editierdistanz nach Levenshtein Editierdistanz nach Levenshtein d(s,t) zwischen zwei Zeichenketten s und t misst die minimale Anzahl von Operationen (Zeichen löschen, ändern, hinzufügen), die notwendig sind, um s in t umzuwandeln Beispiel: Editierdistanz zwischen cabel und cube lösche l am Ende von cabel ersetzte a durch u 20

21 Editierdistanz nach Levenshtein Editierdistanz lässt sich somit wie folgt rekursiv definieren Y _] d(s[0..i],t[0..j]) = min _[ d(s[0..i ],t[0..j ]) + (s[i] = t[j]) // Ändern? d(s[0..i],t[0..j ]) + // Hinzufügen d(s[0..i ],t[0..j]) + // Löschen Berechnung in O(n 2 ) mit dynamischer Programmierung 2

22 Editierdistanz nach Levenshtein Beispiel: Editierdistanz von ware und wurst w u r s t w a r e DP-Tabelle beinhaltet d(s[0..i],t[0..j]) in DP[i,j] 22

23 Editierdistanz nach Levenshtein Beispiel: Editierdistanz von ware und wurst w u r s t w a r e DP-Tabelle beinhaltet d(s[0..i],t[0..j]) in DP[i,j] 23

24 q-gramme Menge der q-gramme zu einer Zeichenkette beinhaltet alle Zeichenketten der Länge 3, die darin enthalten sind Beispiel: warehouse beinhaltet die 3-Gramme { w, _wa, war, are, reh, eho, hou, ous, use, se_, e } Ähnlichkeit von zwei Zeichenketten als Dice-Koeffizient der Mengen ihrer q-gramme dice(s, t) = 2 grams(s, q) fl grams(t, q) grams(s, q)+grams(t, q) 24

25 q-gramme Zwei Zeichenketten s und t müssen mindestens max( s, t ) (k ) gemeinsame q-gramme haben, um eine Editierdistanz von höchstens k zu haben Man kann diese Schranke ausnutzen, um die Zahl der Paare von Zeichenketten, für die die Editierdistanz exakt berechnet werden muss, deutlich zu reduzieren 25

26 4.3 Konzeptuelle Modellierung erkzeuge zur konzeptuellen Modellierung von Data arehouses betrachten Fakten und Dimensionen Produkt Kategorie Gruppe Artikel Kennzahl Umsatz Zeit Jahr Quartal Monat Filiale Stadt Verkaufsort Bundesland Quelle: Köppen, Saake und Sattler [3, S.46] 26

27 Fakten und Kennzahlen Zellen eines Datenwürfels stellen betriebswirtschaftliche Fakten in Form einer Kennzahl (measure) dar Fakten sind in den Dimensionen des Datenwürfels eingebettet und beziehen sich auf eine Position im aufgespannten Datenraum Kennzahlen (z.b. Umsatz, Gewinn, verkaufte Stückzahl) sollen Verdichtung entlang der Dimensionen erlauben Beispiel: Umsatz für Produkt B in Filiale im Mai

28 Dimensionen Dimensionen beschreiben mögliche Sichten und strukturieren den aufgespannten Datenraum Dimensionen beinhalten einfache oder parallele Klassifikationshierarchien, entlang derer sich Fakten auf einer höheren Klassifikationsstufe weiter verdichten lassen 28

29 Einfache und parallele Hierarchien Einfache Hierarchie für Dimension Verkaufsort Top Bundesland Stadt Filiale Parallele Hierarchien für Dimension Zeitraum Top Jahr Quartal oche Monat Tag Quelle: Köppen, Saake und Sattler [2, S.48] 29

30 Multidimensional Entity-Relationship-Modell Multidimensional Entity-Relationship-Modell (ME/R) als Erweiterung des ERMs zur konzeptuellen Modellierung von Data arehouses Fakten als ausgezeichnete Beziehungstypen Dimensionen als Gruppen von Entitytypen verbunden durch ausgezeichneten Klassifikationsbeziehungstyp Faktenname Ebene Attributbezeichnung Faktenbeziehung Klassifikationsstufe Klassifikationsbeziehung Attribut Quelle: Köppen, Saake und Sattler [2, S.53] 30

31 Rückblick Unterstützung der Unternehmenssteuerung durch Data arehouses mit ganzheitlicher Sicht auf Daten aus operativen Systemen Online Transaction Processing (OLTP) und Online Analytical Processing unterscheiden sich deutlich Datenintegration als eine wichtige Herausforderung Multidimensional Entity-Relationship-Model zur konzeptuellen Modellierung von Data arehouses 3

32 Multidimensional Entity-Relationship-Modell Anzahl Umsatz Produktgruppe Artikel Verkauf Filiale Stadt Bundesland Produktkategorie Tag Kunde Kundengruppe oche Monat Quartal Jahr Quelle: Köppen, Saake und Sattler [2, S.54] 32

33 Zusammenfassung Unterstützung der Unternehmenssteuerung durch Data arehouses mit ganzheitlicher Sicht auf Daten aus operativen Systemen Online Transaction Processing (OLTP) und Online Analytical Processing unterscheiden sich deutlich Datenintegration als eine wichtige Herausforderung Multidimensional Entity-Relationship-Model zur konzeptuellen Modellierung von Data arehouses 33

34 Literatur [] A. Kemper und A. Eickler: Datenbanksysteme Eine Einführung, De Gruyter Oldenbourg, 203 (Kapitel 7) [2] V. Köppen, G. Saake und K.-U. Sattler: Data arehouse Technologien, mitp Professional,

35 Implementierung von Data arehouses Verschiedene Ansätze zur Speicherung von Datenwürfeln Relationales OLAP (ROLAP) bildet Datenwürfel auf Relationen ab und verwendet RDBMS Multidimensionales OLAP (MOLAP) speichert Datenwürfel direkt in Form eines mehrdimensionalen Arrays Hybrides OLAP (HOLAP) verwendet eine Kombination von ROLAP und MOLAP (z.b. Detaildaten relational und vorberechnete Aggregate mehrdimensional) 35

36 Snowflake-Schema Snowflake-Schema setzt Fakten in eine Faktentabelle und jede Dimension in mehrere normalisierte Dimensionstabellen um Faktentabelle enthält Kennzahl sowie Fremdschlüssel der jeweils niedrigsten Klassifikationsstufe Dimensionstabelle enthält eine ID, beschreibende Attribute sowie Fremdschlüssel der jeweils nächsthöheren Klassifikationsstufe 36

37 Snowflake-Schema Dimension "Produkt" Produktkategorie PK_ID PK_Bezeichnung * Produktgruppe PG_ID PG_Bezeichnung PG_PKategorie_ID Dimension "Kunde" * Bundesland B_ID B_Name B_Land_ID Kundengruppe KG_ID KG_Bezeichnung * Stadt S_ID S_Name S_BLand_ID * * Kunde K_ID K_Name K_ohnort K_Strasse K_Geschlecht K_KGruppe_ID Filiale F_ID F_Filiale F_Stadt_ID * * Verkauf V_Anzahl V_Kanal V_Produkt_ID V_Zeit_ID V_Kunden_ID V_Filial_ID * * Produkt P_ID P_Bezeichnung P_Verkaufspreis P_Einkaufspreis P_Rabatt P_Steuern P_PGruppe_ID Zeit Z_ID Z_Datum * Dimension "Zeit" Land L_ID L_Name Dimension "Ort" Quelle: Köppen, Saake und Sattler [2, S.58] 37

38 Star-Schema Star-Schema setzt Fakten in eine Faktentabelle und jede Dimension in eine denormalisierte Dimensionstabelle um Faktentabelle enthält Kennzahl sowie Fremdschlüssel der jeweils zugehörigen Einträge in den Dimensionstabellen Dimensionstabelle enthält ID sowie beschreibende Attribute für eine der niedrigsten Klassifikationsstufe und allen höheren Klassifikationsstufen 38

39 Star-Schema Kunde K_ID K_Name K_ohnort K_Strasse K_Geschlecht K_Kundengruppe Ort O_ID O_Filiale O_Stadt O_Bundesland O_Land * * Verkauf V_Anzahl V_Kanal V_Produkt_ID V_Zeit_ID V_Kunden_ID V_Ort_ID * * Produkt P_ID P_Bezeichnung P_Verkaufspreis P_Einkaufspreis P_Rabatt P_Steuern P_Produktgruppe P_Produktkategorie Zeit Z_ID Z_Datum Quelle: Köppen, Saake und Sattler [2, S.59] 39

40 Snowflake-Schema vs. Star-Schema Snowflake-Schema hält Dimensionstabellen in 3NF und vermeidet somit redundante Datenspeicherung; beim Star-Schema sind sie nur in NF, wodurch Redundanzen und Anomalien entstehen Star-Schema kann, dank seiner Denormalisierung, Anfragen bzgl. höherer Klassifikationsstufen direkt, ohne zusätzliche Joins bearbeiten 40

41 Snowflake-Schema vs. Star-Schema Beispielanfrage im Snowflake-Schema (5 Joins) SELECT S_Name, YEAR(Z_Datum), SUM(V_Anzahl) 2 FROM Verkauf, Filiale, Stadt, Produkt, Produktgruppe, Zeit 3 HERE V_Produkt_ID = P_ID AND P_PGruppe_ID = PG_ID 4 AND V_Filial_ID = F_ID AND F_Stadt_ID = S_ID 5 AND V_Zeit_ID = Z_ID AND PG_Bezeichnung = ein 6 GROUP BY S_Name, YEAR(Z_Datum) Beispielanfrage im Star-Schema (3 Joins) SELECT O_Stadt, YEAR(Z_Datum), SUM(V_Anzahl) 2 FROM Verkauf, Ort, Produkt, Zeit 3 HERE V_Produkt_ID = P_ID AND V_Zeit_ID = Z_ID 4 AND V_Ort_ID = O_ID AND P_Produktgruppe = ein 5 GROUP BY O_Stadt, YEAR(Z_Datum) 4

42 Galaxie-Schema Snowflake-Schema und Star-Schema beinhalten eine Faktentabelle, die Kennzahlen in den gleichen Dimensionen speichert Galaxie-Schema als Erweiterung des Snowflake-Schemas beinhaltet mehrere Faktentabellen, die Kennzahlen in verschiedenen Dimensionen speichern Vorberechnete Aggregate (z.b. über alle Filialen hinweg) als eine Quelle zusätzlicher Faktentabellen 42

43 Galaxie-Schema Land L_ID L_Name Kundengruppe KG_ID KG_Bezeichnung Produktkategorie PK_ID Produktgruppe PG_ID PK_Bezeichnung * PG_Bezeichnung PG_PKategorie_ID * Bundesland B_ID B_Name B_Land_ID * Kunde K_ID K_Name K_ohnort K_Strasse K_Geschlecht K_KGruppe_ID * * Verkauf V_Anzahl V_Kanal V_Produkt_ID V_Zeit_ID V_Kunden_ID V_Filial_ID * * Produkt P_ID P_Bezeichnung P_Verkaufspreis P_Einkaufspreis P_Rabatt P_Steuern P_PGruppe_ID * * Stadt S_ID S_Name S_BLand_ID * Filiale F_ID F_Filiale F_Stadt_ID * Summe_Verkauf SV_Anzahl SV_Kanal SV_Monat_ID SV_PGruppe_ID SV_BLand_ID * * Zeit Z_ID Z_Datum Z_Monat_ID Z_Monat Quelle: Köppen, Saake und Sattler [2, S.63] 43

44 4.4 Anfragen an Data arehouses Analytische Anfragen an Data arehouses wählen einen mehrdimensionalen Teilbereich von Fakten aus und berechnen Aggregationen auf höheren Klassifikationsstufen Beispiel: Umsatz je Produktkategorie in allen europäischen Filialen in den Monaten seit Januar 200 Beispiel: Verkaufte Einheiten je Produkt über alle Filialen pro Jahr seit

45 Anfragen an Data arehouses Analytische Anfragen betreffen oft eine große Menge von Daten (z.b. alle Verkäufe seit 200) Antwortzeiten sollen interaktiv (d.h. kürzer 5 Sekunden) sein, um eine Interaktion mit dem Datenwürfel zu erlauben Betrachtung eines kleineren Teilwürfels Verdichtung der Kennzahlen zu höherer Klassifikationsstufe etc. Data arehouses setzen auf Vorberechnungen, um diese Anforderungen zu erfüllen 45

46 OLAP-Operatoren Datenwürfel dient nicht nur der Modellierung, sondern es lassen sich eine Reihe von Operatoren auf ihm definieren, die dann effizient umgesetzt werden müssen Pivotieren/Rotieren des gesamten Datenwürfels (PIVOT) Navigieren aufwärts/abwärts entlang der Dimensionen (ROLL UP / DRILL DON) Betrachten eines Teilwürfels oder einer Scheibe (DICE / SLICE) 46

47 PIVOT Pivotieren/Rotieren des gesamten Datenwürfels Produkt Zeit Softdrink ein Bier Bier 200 ein 20 Softdrink Zeit Sachsen- Anhalt Thüringen Bayern Ort Produkt Sachsen- Anhalt Thüringen Bayern Ort Quelle: Köppen, Saake und Sattler [2, S.26] 47

48 DRILL DON und ROLL UP Navigieren aufwärts/abwärts entlang der Dimensionen Produkt Drill Down Produkt 2009 Softdrink ein Bier Roll Up Softdrink ein Bier Q Q2 Q3 Zeit Sachsen- Anhalt Thüringen Bayern Ort 200 Q Zeit Sachsen- Anhalt Thüringen Bayern Ort Quelle: Köppen, Saake und Sattler [2, S.27] 48

49 SLICE Betrachten einer Scheibe des Datenwürfels Produkt Produkt Softdrink ein Bier Softdrink ein Bier Zeit Sachsen- Anhalt Thüringen Bayern Ort Zeit Sachsen- Anhalt Thüringen Bayern Ort Quelle: Köppen, Saake und Sattler [2, S.27] 49

50 DICE Betrachten eines Teilwürfels des Datenwürfels Produkt Produkt 2009 Softdrink ein Bier 2009 Softdrink ein Bier Zeit Sachsen- Anhalt Thüringen Bayern Ort Zeit Sachsen- Anhalt Thüringen Bayern Ort Quelle: Köppen, Saake und Sattler [2, S.28] 50

51 Umsetzung in SQL Data-arehouse-Systeme vertrauen meist auf RDBMS zur Speicherung und zum Anfragen der Daten Bei Verwendung eines Star-Schema ergibt sich folgendes Anfragemuster zum Berechnen eines Datenwürfels (n+)-ege-verbund zwischen n Dimensionstabellen und einer Faktentabelle Restriktionen über den Dimensionstabellen Aggregation und Gruppierung über Kennzahlen 5

52 Umsetzung in SQL Beispiel: SELECT O_Stadt, YEAR(Z_Datum), SUM(V_Anzahl) 2 FROM Verkauf, Ort, Produkt, Zeit 3 HERE V_Produkt_ID = P_ID AND V_Zeit_ID = Z_ID 4 AND V_Ort_ID = O_ID AND P_Produktgruppe = ein 5 GROUP BY O_Stadt, YEAR(Z_Datum) In den Standards SQL:999 und SQL:2003 wurden Erweiterungen speziell für OLAP eingeführt zusätzliche (statistische) Aggregatfunktionen CUBE und ROLLUP Operatoren 52

53 Aggregatfunktionen Zusätzliche statistische Aggregatfunktionen in SQL:2003 VAR_POP(A) und VAR_SAMP(A) zum Berechnen der Varianz auf Population oder Stichprobe STDDEV_POP(A) und STDDEV_SAMP(A) zum Berechnen der Standardabweichung auf Population oder Stichprobe COVAR_POP(A,B) und COVAR_SAMP(A,B) zum Berechnen der Kovarianz auf Population oder Stichprobe CORR(A,B) zum Berechnen des Korrelationskoeffizienten 53

54 CUBE Analysen benötigen oft Zwischen- und Gesamtsummen PGruppe Jahr Bundesland Umsatz Umsatz Umsatz PGruppe- PGruppe- PGruppe Jahr- Jahr Bundesland ein 200 Sachsen-Anhalt 45 Thüringen Sachsen-Anhalt 47 Bier 20 Thüringen 42 Quelle: Köppen, Saake und Sattler [2, S.32] Je Zwischen- oder Gesamtsumme ist eine separate Unteranfrage an das RDBMS notwendig 54

55 CUBE Beispiel: Zwischen- und Gesamtsummen mittels Vereinigung von Unteranfragen -- Zwischensumme () über alle Produktgruppen,Jahre und Bundesländer 2 SELECT P_Produktgruppe AS PGruppe, YEAR(Z_Datum), O_Bundesland, 3 SUM(V_Anzahl * P_Verkaufspreis) AS Umsatz 4 FROM Verkauf, Zeit, Produkt, Ort 5 HERE V_Zeit_ID = Z_ID AND V_Produkt_ID = P_ID AND V_Ort_ID = O_ID 6 GROUP BY P_Produktgruppe, YEAR (Z_Datum), O_Bundesland 7 8 UNION ALL Zwischensumme (2) über alle Produktgruppen und Jahre SELECT P_Produktgruppe AS PGruppe, YEAR (Z_Datum), 2 CAST( NULL AS VARCHAR(50)), 3 SUM(V_Anzahl * P_Verkaufspreis) AS Umsatz 4 FROM Verkauf, Zeit, Produkt, Ort 5 HERE V_Zeit_ID = Z_ID AND V_Produkt_ID = P_ID AND V_Ort_ID = O_ID 6 GROUP BY P_Produktgruppe, YEAR(Z_Datum) 7 8 UNION ALL

56 CUBE Vollständige Berechnung aller Zwischen- und Gesamtsummen führt bei n Gruppierattributen zu 2 n auszuwertenden Unteranfragen CUBE-Operator berechnet für gegebene Menge von Gruppierattributen {A,..., A n } Summen für alle Teilmengen der Gruppierattribute {} {A }, {A 2 }, {A 3 },... {A,A 2 }, {A,A 3 },.... {A,...A n } 56

57 CUBE Beispiel: Zwischen- und Gesamtsummen mittels Verwendung des CUBE-Operators SELECT P_Produktgruppe AS PGruppe, O_Bundesland, YEAR(Z_Datum), 2 SUM(V_Anzahl * P_Verkaufspreis) AS Umsatz 3 FROM Verkauf, Zeit, Produkt, Ort 4 HERE V_Zeit_ID = Z_ID AND V_Produkt_ID = P_ID AND V_Ort_ID = O_ID 5 GROUP BY CUBE(P_Produktgruppe, O_Bundesland, YEAR(Z_Datum)) CUBE-Operator ist interdimensional, d.h. Gruppierattribute stammen von verschiedenen Klassifikationsstufen unterschiedlicher Dimensionen 57

58 ROLLUP ROLLUP-Operator als intradimensionales Pendant zum CUBE-Operator berechnet Zwischen- und Gesamtsummen entlang verschiedener Klassifikationsstufen einer Dimension Beispiel: Zwischen- und Gesamtsummen für Bundesländer, Städte und Filialen SELECT O_Bundesland, O_Stadt, O_Filiale, 2 SUM(V_Anzahl * P_Verkaufspreis) AS Umsatz 3 FROM Verkauf, Zeit, Produkt, Ort 4 HERE V_Produkt_ID = P_ID AND V_Ort_ID = O_ID 5 AND V_Zeit_ID = Z_ID AND YEAR(Z_Datum) = 20 6 AND P_Produktgruppe = ein 7 GROUP BY ROLLUP(O_Bundesland, O_Stadt, O_Filiale) 58

59 MD Multidimensional Expressions (MD) als von Microsoft vorgeschlagene Anfragesprache für multidimensionale Daten, die auch von anderen Herstellern unterstützt wird MD-Anfrage nach folgendem Muster SELECT <Achsen> 2 FROM <Cube> 3 HERE <Slicer> zur Spezifikation eines Datenwürfels 59

60 MD Achsen-Klausel spezifiziert Achsen des Datenwürfels Aufzählung z.b. {ProduktA, ProduktC} Mengenausdruck z.b. Produkte.CHILDREN Kreuzprodukt z.b. CROSSJOIN(Produkte, Regionen) Cube-Klausel spezifiziert Faktentabelle als Datenquelle Slicer-Klausel erlaubt eine Selektion der Daten gemäß Dimensionen, die nicht als Achsen verwendet werden (z.b. Measures.[Umsatz] betrachtet nur Umsätze) 60

61 MD Beispiel ([2], S. 49) SELECT CROSSJOIN ( 2 {Produkt.Kategorie.Gruppe.[Rotwein], 3 Produkt.Kategorie.Gruppe.[eißwein]}, 4 {Ort.[Sachsen-Anhalt].CHILDREN, 5 Ort.[Thüringen]}) 6 ON COLUMNS, 7 {Zeit.[20].[Q].CHILDREN, Zeit.[20].[Q2], 8 Zeit.[20].[Q3], Zeit.[20].[Q4].CHILDREN} 9 ON ROS 0 FROM Verkauf HERE (Measures.[Umsatz]) Achse : Kreuzprodukt aus Produktkategorien Rotwein und eißwein mit Orten in Sachsen-Anhalt und Thüringen Achse 2: Monate im ersten Quartal von 20, zweites und drittes Quartal von 20, Monate im vierten Quartal von 20 6

62 MD Beispiel ([2], S. 49) SELECT CROSSJOIN ( 2 {Produkt.Kategorie.Gruppe.[Rotwein], 3 Produkt.Kategorie.Gruppe.[eißwein]}, 4 {Ort.[Sachsen-Anhalt].CHILDREN, 5 Ort.[Thüringen]}) 6 ON COLUMNS, 7 {Zeit.[20].[Q].CHILDREN, Zeit.[20].[Q2], 8 Zeit.[20].[Q3], Zeit.[20].[Q4].CHILDREN} 9 ON ROS 0 FROM Verkauf HERE (Measures.[Umsatz]) Datenquelle: Faktentabelle Verkauf Slicer: Nur Umsätze werden berücksichtigt 62

63 MD Beispiel ([2], S. 49) Umsätze 20 Rotwein eißwein S.-A. Thür. S.-A. Thür. Magdeb. Halle Magdeb. Halle. Quart. Jan Feb Mär Quart Quart Quart. Okt Nov Dez

64 4.5 Implementierungsaspekte Implementierungsansätze für Data-arehouse-Systeme ROLAP verwendet RDBMS zum Speichern und Anfragen MOLAP speichert Daten als multidimensionales Array HOLAP verwendet Kombination der beiden Ansätze Bitmap-Indizes als zusätzliche Indexstruktur, die insbesondere für Attribute mit kleiner Anzahl möglicher Attributwerte und relativ statische Daten geeignet ist 64

65 ROLAP Relationales OLAP (ROLAP) verwendet ein RDBMS, um Datenwürfel in Fakten- und Dimensionstabellen zu speichern Vorteile: RDBMS sind ausgereifte Systeme und weit verfügbar geringer Implementierungsaufwand und Kosten Nachteile: Faktentabellen haben, aufgrund von Dimensionsattributen, einen vergleichsweise hohen Speicherbedarf 65

66 MOLAP Multidimensionales OLAP (MOLAP) verwendet ein multidimensionales Arrays zur Speicherung des Datenwürfels Klassifikationsstufen der verschiedenen Dimensionen müssen intern als ganze Zahlen (0...n) kodiert werden Dimensionsinformation eines Fakts muss dann nicht separat gespeichert werden, sondern ist aus seiner Position im multidimensionalen Array ablesbar 66

67 MOLAP Datenwürfel als multidimensionales Array, welches dann mittels Linearisierung (wie in Programmiersprachen) als Folge von Fakten (Kennzahlen) gespeichert wird D 3 Magdeburg D Halle D 2 Sachsen-Anhalt Erfurt Thüringen Februar März. Quartal Januar Quelle: Köppen, Saake und Sattler [2, S.57/59] 67

68 Bitmap-Indizes Bitmap-Indizes als zusätzliche Form von Indexstruktur (neben B + -Bäumen und hashbasierten Indizes), die insbesondere in Data arehouses Anwendung findet Bitmap-Indizes geeignet für Attribute mit kleiner Anzahl möglicher Attributwerte (z.b. Geschlecht, Kategorie) Für jeden möglichen Attributwert wird ein Bitvektor gespeichert, der Tupel anzeigt (Bit auf gesetzt), welche diesen Attributwert besitzen 68

69 69 Bitmap-Indizes Beispiel: eibliche Kunden in Vertriebsgebieten S und G:w S U T V V:S S U T V V: S U T V Q c c c c c c c c a S U T V R d d d d d d d d b = S U T V

70 Bitmap-Indizes Bitvektoren lassen sich kompakt speichern und sehr effizient mittels Boole scher Operationen verknüpfen Bitmap-Indizes haben für Attribut mit wenigen möglichen erten einen geringeren Speicherbedarf als herkömmliche B + -Bäume Bitmap-Indizes sind insbesondere für statische Daten geeignet; ein Einfügen oder Löschen von Tupeln erfordert eine Neuberechnung aller Bitvektoren 70

71 Zusammenfassung Datenwürfel besteht aus Fakten und Dimensionen, die sich in Form eines Snowflake-Schemas oder eines Star-Schemas in Relationen abbilden lassen OLAP-Operatoren (ROLL UP, DRILL DON, SLICE, etc.) zur Interaktion mit einem Datenwürfel OLAP-Unterstützung in SQL und durch in Form der von Microsoft vorgeschlagenen Anfragesprache MD 7

72 Literatur [] A. Kemper und A. Eickler: Datenbanksysteme Eine Einführung, De Gruyter Oldenbourg, 203 (Kapitel 7) [2] V. Köppen, G. Saake und K.-U. Sattler: Data arehouse Technologien, mitp Professional,