3. Mehrdimensionale Datenmodellierung. Kennzahlen

Transkript

1 3. Mehrdimensionale Datenmodellierung Grundlagen Kennzahlen, Dimensionen, Cube Cuboide / Aggregationsgitter hierarchische Dimensionen / Konzepthierarchien CubeOperationen Multidimensionale Speicherung (MOLAP) MDX Relationale Repräsentation mehrdimensionaler Daten (ROLAP) StarSchema Varianten: Snowflake, GalaxienSchema Anfragen: Star Join, RollUp, DrillDown CubeOperator, RollupOperator, Grouping Sets Prof. E. Rahm 3 1 Kennzahlen auch: Fakten, Meßgrößen, Measures, Measured Facts Kennzahl ist Größe mit konzentrierter Aussagekraft zur Diagnose, Überwachung und Steuerung eines Sstems meist betriebswirtschaftliche Größen Bsp.: Umsatz / Gewinn / Rentabilität komplexe Beziehungen zwischen Kennzahlen möglich Kennzahlen besitzen beschreibende Attribute, z.b. Einheit, Wertebereich, Berechnungsvorschrift Arten von Kennzahlen additive Kennzahlen: additive Aggregation hinsichtlich aller Dimensionen möglich semiadditive Kennzahlen: additive Aggregation nur hinsichtlich ausgewählter Dimensionen möglich nichtadditive Kennzahlen (Bsp. Durchschnittswerte, Prozentanteile) Prof. E. Rahm 3 2

2 Dimensionen Zahlenwert einer Kennzahl ohne zugehörigen semantischen Bezug nichtssagend Dimensionen setzen Kennzahlen in Bezug zu Eigenschaften / sachlichen Kriterien Sachsen Bücher Wo? Mit was? Umsatz = EUR Wann? 1. Quartal Dimension: Datentp, i.a. endlich (z.b. Aufzählung) Beispiele: Menge aller e, en, Kunden, perioden etc. Attribute: Klassifikations/Kategorienattribute (inkl. eines Primärattributs) sowie dimensionale Attribute (zusätzliche beschreibende Eigenschaften, z.b. farbe / Gewicht Dimensionselement: Element / Ausprägung / Wert zu einer Dimension (z.b. bestimmtes ) Prof. E. Rahm 3 3 Data Cube Datenwürfel bzw. OLAPWürfel (Cube), Data Cube Dimensionen: Koordinaten Kennzahlen: Zellen im Schnittpunkt der Koordinaten Cube bezüglich Dimensionen D1, Dn und k Kennzahlen (Fakten): W = { (d 1, d n ), (f 1, f k ), Dimensionselement d i aus D i, i= 1.. n, Kennzahlen f j, j = 1..k)} eindeutige ZellenAdresse: (d 1, d n ) ZellenInhalt: (f 1, f k ) n: Dimensionalität des Cube Alternative: k Cubes mit je einer Kennzahl pro Zelle (MultiCube) tpischerweise 4 12 Dimensionen dimension fast immer dabei weitere Standarddimensionen:, Kunde, Verkäufer,, Lieferant, Q 2Q 3Q 4Q Ost West Nord Süd Sonstiges PC Video TV Prof. E. Rahm 3 4

3 TabellenDarstellung von Cubes direkte Umsetzung für 2 Dimensionen (2DSicht auf x ) = Quartal1 = Quartal2 Ost Süd West Ost Süd West Dimensionen: mehrere 2DTabellen bzw. geschachtelte Tabellen bzw. 3DCube Ost Süd West 1 Quartal 1 Quartal Quartal 1 Quartal Prof. E. Rahm 3 5 Quartal 1 Quartal CubeDarstellung 4DCube kann als Menge von 3DCubes dargestellt werden Lieferant = L1 Lieferant = L2 Lieferant = L3 allgemein: Ndimensionaler Cube entspricht Menge von (N1)dimensionalen SubCubes oder Cuboiden ( Quadern ) BasisCuboid: ndimensionaler Cube ScheitelCuboid: 0dimensionale Aggregation über alle Dimensionen aus BasisCuboid lassen sich Cuboiden geringerer Dimensionsanzahl ableiten > Data Cube entspricht Verband (Lattice) von Cuboiden Ndimensionaler Cube hat 2 N Cuboiden inkl. BasisCuboid (ohne Berücksichtigung von Dimensionshierarchien) Prof. E. Rahm 3 6

4 Cube: Verband von Cuboiden All 0D(Scheitel) Cuboid Lieferant 1D Cuboiden,,,, Lieferant, Lieferant, Lieferant 2D Cuboiden,,Lieferant,,,,Lieferant Product,, Lieferant 3D Cuboiden,,, Lieferant 4D (Basis)Cuboid Prof. E. Rahm 3 7 Data Cube: 3DBeispiel mit Aggregation TV PC VCR Summe 1Qtr 2Qtr 3Qtr 4Qtr Gesamtjahresabsatz für TV in West Summe West Süd Ost Summe Prof. E. Rahm 3 8

5 Zugehörige Cuboiden (Aggregationsgitter) All 0D (Scheitel) Cuboid 1D Cuboiden,,, 2D Cuboiden,, 3D (Basis)Cuboid Prof. E. Rahm 3 9 Dimensionshierarchien (Konzepthierarchien) häufig hierarchische Beziehungen zwischen Dimensionsobjekten TopLevel pro Hierarchie für alle Dimensionselemente (Gesamt, Top, All) Primärattribut: unterste (genaueste) Stufe funktionale Abhängigkeiten zwischen Primärattribut und Klassifikationsattributen höherer Stufen Beispiele Gesamt Gesamt Gesamt Jahr Branche Kontinent Quartal gruppe Land Monat familie Bezirk Tag Ort Dimensionen haben neben Klassifikations(Hierarchie)attributen meist noch beschreibende dimensionale Attribute Prof. E. Rahm 3 10

6 Beispiel einer Konzepthierarchie () (Gesamt) abgeleitete (verdichtete) Elemente Gebiet Ost Ort Leipzig Basiselemente (unabhängige Dimensionselemente) einfache Hierarchie (pro Element höchstens ein übergeordnetes Element) vs. parallele Hierarchie bzw. Halbordnung Prof. E. Rahm 3 11 Konzepthierarchien (3) Hierarchien sind meist auf Schemaebene durch Klassifikationsattribute und deren funktionalen Abhängigkeiten gegeben Variante: Hierarchiebildung durch Wertegruppierungen / Diskretisierungen ( Setgrouping Hierarchies ) können Auswertungen vereinfachen günstige Einteilungen auf Basis vorhandener Werte teilweise automatisch berechenbar Alter (Gesamt) 030 (jung) mittel alt Prof. E. Rahm 3 12

7 Cube mit hierarchischen Dimensionen Land Ort Gesamt gruppe Branche Gesamt Monat Quartal Jahr Prof. E. Rahm 3 13 Operationen auf Cubes Slice: Herausschneiden von Scheiben aus dem Würfel durch Einschränkung (Selektion) auf einer Dimension Verringerung der Dimensionalität Dice: Herausschneiden einen Teilwürfels durch Selektion auf mehreren Dimensionen leitersicht Controller Sicht Umsatzdaten alleitersicht unterschiedlichste mehrdimensionale Aggregationen / Gruppierungen Pivot (Austausch von Dimensionen), Sortierung, TopnAnfragen, Prof. E. Rahm 3 14 AdHoc Sicht

8 Beispiele: Slice / Pivot Prof. E. Rahm 3 15 Quelle: J. Han, M. Kamber: Data Mining,Morgan Kaufmann, 2001 Beispiel: Dice Prof. E. Rahm 3 16

9 Navigation in Hierarchien DrillDown Navigation nach unten in der Hierarchie Erhöhung des Detailgrad: von verdichteten Daten zu weniger verdichteten/aggregierten Daten manchmal auch verwendet für Erhöhung der Dimensionsanzahl RollUp (DrillUp) Navigation nach oben in der Hierarchie von weniger verdichteten (aggregierten) Daten zu stärker verdichteten Daten manchmal auch verwendet für Reduzierung der Dimensionsanzahl (Gesamt) RollUp Land Ort DrillDown Drill across Prof. E. Rahm 3 17 RollUp Prof. E. Rahm 3 18

10 DrillDown Prof. E. Rahm 3 19 DrillDown / RollUp (2D) gruppe Ost Süd Nord West Elektronik Spielwaren Kleidung DrillDown RollUp Elektronik Ost Süd Nord West TV 800 DVDPlaer 500 Camcorder 300 Prof. E. Rahm 3 20

11 Summenbildung Aggregation: 2DBeispiel gruppe Ost Süd Nord West Summe Elektronik Spielwaren Kleidung Summe Vorberechnung (Materialisierung) der Aggregationen zur schnellen Beantwortung von Aggregationsanfragen hoher Speicher und Aktualisierungsaufwand (bei vielen Dimensionselementen) ermöglicht nur kleinen Teil benötigter Aggegationen vorzuberechnen Prof. E. Rahm 3 21 Größe der Cubes Größe der BasisCuboids der Zellen entspricht der Dimensionskardinalitäten D i, i=1..n Beispiel: Tage, e, 1 Million Kunden jede weitere Dimension, z.b. oder Verkäufer, führt zu einer Vervielfachung des Datenraumes Vorberechnung von (aggregierten) Cuboiden erhöht Speicherbedarf Größe eines hierarchisch aggregierten Cubes Aggregierung für jedes Dimensionselement auf einer höheren Hierarchiestufe möglich Kombinationsmöglichkeit mit jedem Element auf einer der Hierarchiestufen der anderen n1 Dimensionen Cuboiden bei ndimensionalem Cube: L i : #Ebenen von Dimension i (ohne TopLevel) T = n ( L i + 1) i = 1 Kunde Gesamt 1 Gesamt 1 Gesamt 1 Quartal 12 Branche 50 Kundengruppe Monat 36 gruppe Einzelkunde 1 Million Tag Prof. E. Rahm 3 22

12 Umsetzung des multidimensionalen Modells Aspekte Speicherung der Daten Formulierung / Ausführung der Operationen MOLAP: Direkte Speicherung in multidimensionalen Speicherungsstrukturen CubeOperationen einfach formulierbar und effizient ausführbar begrenzte Skalierbarkeit auf große Datenmengen ROLAP: relationale Speicherung der Daten in Tabellen effiziente Speicherung sehr großer Datenmengen umständliche Anfrageformulierung StandardSQL nicht ausreichend (nur 1dimensionale Gruppierung, ) HOLAP: hbride Lösung relationale Speicherung der DetailDaten, multidimensionale Zugriffsschnittstelle unterschiedliche Kombinationen mit multidimensionaler Speicherung / Auswertung von aggregierten Daten Vorberechnung von Aggregationen erforderlich für ausreichende Leistung Prof. E. Rahm 3 23 Multidimensionale Datenspeicherung Datenspeicherung in multidimensionaler Matrix direkte Umsetzung der logischen CubeSicht VorabBerechnung und Speicherung der Kennzahlen basierend auf dem Kreuzprodukt aller Wertebereiche der Dimensionen schneller direkter Zugriff auf jede Kennzahl über Indexposition (x 1, x 2, x n ) multidimensional (Kreuztabelle) Sachsen Brandenburg TV DVDPlaer Camcorder Thüringen relational TV Camcorder Brandenburg Sachsen Umsatz Anfragen: Wie hoch ist der Umsatz für DVDPlaer in Thüringen Wie hoch ist der Gesamtumsatz für Camcorder? Prof. E. Rahm 3 24

13 Multidimensionale Datenspeicherung (2) mehrdimensionale Speicherung führt oft zu dünn besetzten Matrizen Beispiel (Kundenumsätze nach en) Kunde Kunde 1 Kunde 2 Kunde 3 Kunde 4 Kunde 5 Kunde 6 Kunde 7 Kunde 8 Kunde 9 REGION B S multidimensional (2dimenstional) NRW 150 SH 170 BW 200 SA 20 MVP 120 HH 100 TH 100 Kunden Kunde 1 Kunde 2 Kunde 3 Kunde 4 Kunde 5 Kunde 6 Kunde 7 Kunde 8 Kunde 9 relational B NRW BW S SH TH SA MVP HH Umsatz vollständig besetzte Matrizen i.a. nur für höhere Dimensionsebenen Unterstützung dünn besetzter Matrizen erforderlich (Leistungseinbussen) Zerlegung eines Cubes in SubCubes ( chunks ), die in Hauptspeicher passen zweistufige Adressierung: ChunkId, Zelle innerhalb Chunk Prof. E. Rahm 3 25 Sprachansatz MDX* MDX: Multidimensional Expressions MicrosoftSpezifikation für CubeZugriffe im Rahmen von OLE DB for OLAP an SQL angelehnt Extraktion von aggregierten SubCubes / Cuboiden aus Cubes Hauptanweisung SELECT [<axis_specification> [, <axis_specification>]] FROM [<cube_specification>] [WHERE [<slicer_specification>]] Beispiele SELECT FROM WHERE.CHILDREN ON COLUMNS,.CHILDREN ON ROWS Verkauf (Umsatz,.[]) SELECT Measures.MEMBERS ON COLUMNS, TOPCOUNT(Filiale.Ort.MEMBERS, 10, Measures.) ON ROWS FROM Verkauf Unterstützung durch Microsoft und zahlreiche ToolAnbieter * Prof. E. Rahm 3 26

14 ERDiagramm eines multidimensionalen Datenmodells KundenNr DatumID KundenName Kunde Tag Geschlecht Monat Jahr Verkauf Nr Umsatz Fname Name Filialen Ort gruppe Land Prof. E. Rahm 3 27 Relationale Speicherung: StarSchema Fakten (Kennzahlen) und Dimensionsdaten werden in Tabellen gehalten Faktentabelle bildet Zentrum des StarSchemas und enthält die DetailDaten mit den zu analsierenden Kennzahlen (analog den Zelleneinträgen einer multidimensionalen Matrix) pro Dimension existiert eine Dimensionstabelle, die nur mit der Faktentabelle verknüpft ist (> sternförmige Anordnung der Tabellen) Kunde KundenNr KundenName Geschlecht Alter 1 1 n n Verkauf KundenNr Nr Datum Filiale Datum Tag Monat Quartal Jahr Nr Name tp Branche Hersteller Farbe Preis 1 n Umsatz n 1 Fname Ort Land Filialen Dimensionstabelle Faktentabelle Dimensionstabelle Prof. E. Rahm 3 28

15 Beispielausprägungen Verkauf Datum 7654 Filiale Leipzig4 Nr 1847 KundenNr Umsatz FName Leipzig4 Ort Leipzig Filialen Land Sachsen Ost KundenNr 4711 Name Weber Kunde Geschlecht M Alter 39 Datum 7654 Tag 25 Monat April Jahr Quartal 2 Nr 1847 name Passat XY tp Auto Hersteller Farbe Blau Preis Prof. E. Rahm 3 29 StarSchema (2) Formale Definition: StarSchema besteht aus einer Menge von Tabellen D 1, D n, F mit Dimensionstabellen D i bestehend aus (i.a. künstlichen) Primärschlüssel d i und Dimensionsattributen Faktentabelle F bestehend aus Fremdschlüsseln d 1, d n sowie Meßgrößen (Kennzahlen) als weiteren Attributen Die Dimensionstabellen sind i.a. denormalisiert, d.h. nicht in dritter Normalform Beobachtungen der Datensätze in Faktentabelle entspricht der belegten Zellen einer multidimensionalen Matrix leere Dimensionskombinationen unproblematisch, da nur relevante Kombinationen in der Faktentabelle auftreten. dennoch oft riesige Faktentabellen Dimensionstabellen vergleichsweise klein, teilweise jedoch auch umfangreich (Kunden, Artikel etc.) Prof. E. Rahm 3 30

16 SnowflakeSchema explizite Repräsentation der Dimensionshierarchien normalisierte Dimensionstabellen leicht geringere Redundanz, geringerer Änderungsaufwand erhöhte Zugriffskosten (höherer JoinAufwand) StarSchema ist SnowflakeSchema meist vorzuziehen PGruppe gruppe Branche Kunde KundenNr KundenName Geschlecht Alter Nr Name tp Hersteller Farbe Preis Verkauf KundenNr Nr Datum Filiale Umsatz Faktentabelle Prof. E. Rahm 3 31 Datum Tag Monat Jahr Filialen Fname Ort MonatQ Monat Quartal OrtL Ort Land Land GalaxienSchema Data Warehouses benötigen meist mehrere Faktentabellen > MultiStarSchema (GalaxienSchema, Fact Constellation Schema ) gemeinsame Nutzung von Dimensionstabellen Speicherung vorberechneter Aggregate separate Faktentabelle im Rahmen der Faktentabelle mit DetailDaten Kunde Filiale Verkauf Einkauf Lieferant Prof. E. Rahm 3 32

17 Behandlung von Änderungen in Dimensionen Änderungsarten neue Dimensionselemente (z.b. neue version) Änderung von Werten zu einem Dimensionselement (z.b. neuer Familienstand/Wohnort von Kunden) neue Hierarchiestufe einer Dimension neue Dimension Behandlung auf SchemaEbene (SchemaEvolution) oder TupelEbene Änderung von Dimensionselementen Lösung 1: Überschreiben der alten Werte (Auswertungen für ältere räume sind verfälscht) Lösung 2: Versionierung von Dimensionselementen auf TupelEbene, z.b. erweiterte Schlüsselwerte Lösung 3: Versionierung auf SchemaEbene (Neue attribute für Gültigkeitszeit, Änderungszeit) Prof. E. Rahm 3 33 Anfragen auf dem StarSchema StarJoin sternförmiger Join der (relevanten) Dimensionstabellen mit der Faktentabelle Einschränkung der Dimensionen Verdichtung der Kennzahlen durch Gruppierung und Aggregation Allgemeine Form aggregierte Kennzahlen select g 1, g k, agg(f 1 ), agg (f m ) from D 1,, D n, F where group b g 1, g k sort b ; <Selektionsbedingung auf D 1 > and and <Selektionsbedingung auf D n > and D 1.d 1 = F.d 1 and and D n.d n = F.d n Relationen des StarSchemas JoinBedingungen ErgebnisDimensionalität Prof. E. Rahm 3 34

18 Beispiel eines StarJoin In welchen Jahren wurden von weiblichen Kunden in Sachsen im 1. Quartal die meisten Autos gekauft? select from where group b order b z.jahr as Jahr, sum (v.) as Gesamtzahl Filialen f, p, z, Kunden k, Verkauf v z.quartal = 1 and k.geschlecht = W and p.tp = Auto and f.land = Sachsen and v.datum = z.datum and v.nr = p.nr and v.filiale = f. FName and v.kundennr = k.kundennr z.jahr Gesamtzahl Descending; Jahr 2004 Gesamtzahl Prof. E. Rahm 3 35 Mehrdimensionale Aggregationen mit GroupB Attributanzahl in group bklausel bestimmt Dimensionalität select Hersteller, Jahr, sum () as from Verkauf v, p, z where v.nr = p.nr and v.datum= z.datum and p.tp = Auto group b Hersteller, Jahr; select Hersteller, sum () as from Verkauf v, p where v. = p. Nr and and p. tp = Auto group b Hersteller; select sum () as from Verkauf v, p where v. = p. Nr and p. tp = Auto ; Prof. E. Rahm 3 36 Hersteller BMW Ford Ford Ford Hersteller Ford BMW Jahr

19 Relationale Speicherung aggregierter Werte Kreuztabelle (CrosstabDarstellung) Jahr Hersteller BMW Ford Σ Prof. E. Rahm 3 37 Σ relationale Darstellung (2DCube) Hersteller BMW BMW BMW Ford Ford Ford BMW Ford Jahr Materialisierung von Aggregaten create table Auto2DCube (Hersteller varchar (20), Jahr integer, integer); insert into Auto2DCube (select p.hersteller, z.jahr, sum (v. ) from Verkauf v, p, z where v.nr = p.nr and p.tp = Auto and v.datum = z.datum group b z.jahr, p.hersteller) union (select p.hersteller,, sum (v.) from Verkauf v, p where v.nr = p.nr and p.tp = Auto group b p. Hersteller) union (select, z. Jahr, sum (v.) from Verkauf v, p, p where v.nr = p Nr and p.tp = Auto and v.datum = z.datum group b z. Jahr) union (select,, sum (v.) from Verkauf v, p where v.nr = p. Nr and p.tp = Auto ); Prof. E. Rahm 3 38

20 CubeOperator SQLErweiterung um CUBEOperator für ndimensionale Gruppierung und Aggregation Sntax: Group B CUBE (D 1, D 2, D n ) generiert als Ergebnis eine Tabelle mit aggregierten Ergebnissen (Tupel) implementiert in MS SQLServer, DB2, Oracle erspart mehrfache Berechnung der Aggregationen erspart 2 n unionanfragen (bei n Attributen in der group bklausel / n Dimensionen) einfache Formulierung von Anfragen effiziente Berechenbarkeit durch DBS (Wiederverwendung von Zwischenergebnisse) Beispiel select p. Hersteller, z. Jahr, k.geschlecht, sum (v. ) from Verkauf v, p, z, Kunde k where v.nr = p. Nr and p.tp = Auto and v.datum = z.datum group b cube (p.hersteller, z.jahr, k.geschlecht); Prof. E. Rahm DCube in relationaler Form Hersteller Jahr Geschl Hersteller Jahr Geschl BMW m w m w m m w CUBE Ford Ford 2001 m w m w m m Prof. E. Rahm 3 40

21 CubeAggregatgitter Dimensionalität (,, ) 0 (Hersteller,, ) (, Jahr, ) (,, Geschlecht) 1 (Hersteller, Jahr, ) (Hersteller,, Geschlecht) (, Jahr, Geschlecht) 2 (Hersteller, Jahr, Geschlecht) 3 niedrigdimensionale Aggregate / Cuboiden können aus höherdimensionalen abgeleitet werden Materialisierung / Caching häufiger benutzter Aggregate ermöglicht Anfrageoptimierung Prof. E. Rahm 3 41 ROLLUPOperator CUBEOperator: interdimensionale Gruppierung / Aggregierung generiert Aggregate für alle 2 n Kombinationsmöglichkeiten bei n Dimensionen zu aufwendig für RollUp / DrillDown innerhalb einer Dimension ROLLUPOperator: intradimensionale Aggregierung ROLLUP zu a1, a2,, an, f () liefert nur die Cuboide a1, a2,, an1,, f (), a1,,,, f (), (,, ),,,, f () Reihenfolge der Attribute relevant! Beispiel (Hersteller,, ) 0 1 select p. Hersteller, p. Marke, p.farbe, sum (v. ) from Verkauf v, Filiale p where v.nr = p. Nr and p.hersteller in (, ) group b rollup (p.hersteller, p.marke, p.farbe); (Hersteller, Marke, ) (Hersteller, Marke, Farbe) 2 3 Prof. E. Rahm 3 42

22 ROLLUPBeispiel Hersteller Marke Passat Passat Passat Golf Golf Golf Vectra Vectra Vectra Farbe rot weiß blau rot weiß blau rot rot weiß blau ROLLUP Hersteller Marke Passat Passat Passat Golf Golf Golf Vectra Vectra Vectra Passat Golf Vectra Farbe rot weiß blau rot weiß blau rot rot weiß blau Prof. E. Rahm 3 43 Grouping Sets mehrere Gruppierungen pro Anfrage GROUP BY GROUPING SETS ( <Gruppenspezifikationsliste> ) Gruppenspezifikation: (<Gruppenspezifikationsliste> ) CUBE <Gruppenspezifikationsliste> ROLLUP <Gruppenspezifikationsliste> leere Spezifikationsliste ( ) möglich: Aggregation über gesamte Tabelle Beispiel Hersteller Farbe select p. Hersteller, p.farbe, sum (v. ) from Verkauf v, p where v.nr = p. Nr and p.hersteller in (, ) groupbgroupingsets((p.hersteller), (p.farbe)); blau rot weiß CUBE, ROLLUP, herkömmliches GroupB entsprechen speziellen GroupingSets Prof. E. Rahm 3 44

23 Einzelschritte beim Entwurf eines multidimensionalen Schemas Welche Geschäftsprozesse sollen modelliert und analsiert werden? Festlegung der Kennzahlen Wo kommen sie her? Granularität der Fakten. Welche OLAPGenauigkeit ist notwendig? Bestimmung der Dimensionen Gemeinsame Eigenschaften der Kennzahlen Spezifikation der Dimensionsattribute Konstante vs. sich ändernde Dimensionsattribute Etablierung / Verwendung einer einheitlichen Terminologie Phsische DesignEntscheidungen Architektur (ROLAP/MOLAP/HOLAP) vorzuberechnende Aggregationen Speicherbedarf ermitteln Festlegung der Dauer der Historie, Behandlung alter Daten Aktualisierungsfrequenz bezüglich der Quellssteme Prof. E. Rahm 3 45 Prof. E. Rahm 3 46 Zusammenfassung Einfachheit des multidimensionalen Modellierungsansatzes wesentlich für Erfolg von Data Warehousing CubeRepräsentation mit Kennzahlen und hierarchischen Dimensionen Operationen: Slice and Dice, RollUp, DrillDown, Multidimensionale Speicherung Problem dünn besetzter Matrizen primär für aggregierte Daten relevant, weniger zur Verwaltung von DetailFakten Relationale Speicherung auf Basis von StarSchemas Unterstützung großer Datenmengen, Skalierbarkeit neue Anforderungen bezüglich effizienter Verarbeitung von StarJoins, mehrdimensionale Gruppierung und Aggregation Vorberechnung aggregierter Daten wesentlich für ausreichende Leistung Sprachansätze MDXAnweisungen für Cubes SQLErweiterungen: CUBE, ROLLUPOperator

24 Übungsaufgabe: WarehouseEntwurf a) Erstellen Sie ein StarSchema für ein großes deutsches Telefonunternehmen. Es soll Auswertungen über Anrufhäufigkeiten, generierte Umsätze und Dauer der Gespräche für die einzelnen Tarifarten über unterschiedliche en (Tageszeiten, Wochentage, Monate, Jahre) ermöglichen. Die Teilnehmer werden über ihre Adressen bzw. Telefonnummern Orten sowie Bundesländern zugeordnet. Es werden die üblichen Personenmerkmale für Analsezwecke erfasst, insbesondere Alter, Geschlecht und Beruf. b) Schätzen Sie den Speicherbedarf für eine Aufzeichnungsdauer von 3 Jahren, 40 Millionen Teilnehmern und durchschnittlich 10 Gesprächen pro Tag und Teilnehmer. c) Wie lautet für das Schema aus a) die SQLAnfrage zur Bestimmung des Umsatzes aller sächsischen Ferngespräche am Abend nach Tarif AKTIV++ für jeden Monat im Jahr? Prof. E. Rahm 3 47 Übungsaufgabe 2 Bestimmen Sie für die gezeigte Tabelle Goals das Ergebnis folgender SQL Anfragen: Select Spieler, Saison, Sum () as Tore From Goals Group BY ROLLUP (Spieler, Saison); Select Spieler, Saison, Sum () as Tore From Goals Group BY CUBE (Spieler, Saison); Select Spieler, Saison, Sum () as Tore From Goals Group BY GROUPING SETS ((Spieler), (Saison),()); Spieler Elber Elber Elber Scholl Scholl Scholl Scholl Scholl Saison Prof. E. Rahm 3 48