8.1 Überblick. 8 Data Warehousing. klassischen Datenbankanwendungen werden Datenbanken im wesentlichen zur Abwicklung des (

Transkript

1 c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing Data Warehousing 8.1 Überblick In klassischen Datenbankanwendungen werden Datenbanken im wesentlichen zur Abwicklung des ( operativen ) Tagesgeschäfts verwendet (z.b.: Buchungen, Einkauf/Verkauf, Personal,...) Operationen (Transaktionsprogramme) auf diesen Datenbanken typischerweise mit Zugriff auf kleine Datenmengen (z.b. Direktzugriff über Kontonummern), Durchführung weniger Änderungsoperationen bzw. kleiner Lesetransaktionen Anforderungen: hoher Parallelitätsgrad hoher Transaktionsdurchsatz (mehrere Hundert bis Tausend Transaktionen pro Sekunde!) hohe Verfügbarkeit ( mission critical ) OnLine Transaction Processing (OLTP) Charakteristik: normalisierte Relationen (geringer Update-Overhead) vgl.weise wenige Indexe (dto.)

2 Neue, zusätzliche Anwendungsgebiete für große Informationssysteme: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-2 Management-Informationssysteme Decision-Support Integration mehrerer operativer Datenbanken Hier sollen die vorhandenen Daten verdichtet werden, um globalere Zusammenhänge zu erkennen, beispielsweise: Wie hat sich die Auslastung der Transatlantikflüge über die letzten zwei Jahre entwickelt? Wie haben sich besondere offensive Marketingstrategien für bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt? Anforderungen: große komplexe Anfragen mit hohem Aggregationsgrad, wenig oder keine Änderungen OnLine Analytical Processing (OLAP)

3 Typische Aspekte: Sehr große operative Datenbanken (> 1 TByte) Gewünschte Anfragen stellen Daten stark verdichtet aggregiert dar: relativ teuer können nicht parallel zum laufenden Betrieb gestellt werden. sollen unterschiedliche Präzisierungsgrade ermöglichen. Aus den operativen Datenbanken werden regelmässig (etwa 1x täglich oder 1x monatlich) Daten in eine zusätzliche (wesentlich kleinere) Datenbank, das Data Warehouse übertragen. Das Data Warehouse steht dann für beliebige Anfragen zur Verfügung. Gegebenenfalls wird das Data Warehouse in weitere Komponenten unterteilt, die sog. Data Marts. OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining operationale DB operationale DB Data Warehouse operationale DB operationale DB c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-3

4 Datenbankarchitektur: Ein Data Warehouse enthält üblicherweise zwei Arten von Informationen: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-4 eine (sehr große) Faktentabelle: Diese enthält pro Tupel einen einzelnen Geschäftsvorfall (einen Verkauf, einen Vertragsabschluß, einen Auftrag,...) enthält jeweils Fremdschlüssel der beteiligten Dimensionen sowie weitere Informationen Beispiele: Alle Verkäufe der letzten drei Jahre Alle Telefonate des letzten Jahres Alle Flugreservierungen der letzten fünf Jahre typischerweise eine normalisierte Relation verschiedene Dimensionstabellen: Jede Dimension beschreibt einen zentralen Aspekt für das Data Warehouse. Übliche Dimensionen sind: Lieferant, Produkt, Zeit, Region, Filiale, Kunde,... oftmals nicht normalisiert

5 c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-5 Ein wesentliches Problem ist etwa die adäquate Modellierung der Dimensionen Auftretende Probleme: Dimensionen haben eine hierarchische Gliederungsstruktur: Region: Kontinent Land Bundesland Stadt Straße Zeit: Jahr Monat Tag Manche Dimensionen haben mehrere nicht-kompatible Strukturen: Jahr Quartal Monat Tag Jahr Woche Tag Jahr Woche (KW) Quartal Monat Tag Dimensionsstrukturen können sich über die Zeit verändern, wenn sich das Anwendungsfeld verändert Anpassung alter Daten/Dimensionsinformation problematisch! Üblicherweise werden Anfragen an die Fakten-Tabelle im Zusammenhang mit einer oder mehreren Dimensionen gestellt (mehrfache Joins). Diese Anfragen enthalten oft Aggregierungen und sind nach den Dimensionen strukturiert Multidimensionale Anfragen

6 Beispiel: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-6 Abbildung 8-1: Multidimensionale Anfragen

7 Datenwürfel ( Cube ): Strukturierte Darstellung der vorhandenen Informationen: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-7 Hersteller Jahr Übliche Variationen: Abbildung 8-2: Ein Datenwürfel Hinzunahme/Wegnahme von Dimensionen: Steuerung durch group by-klausel Verfeinerung von Dimensionen

8 Da die spezielle Struktur eines Data Warehouse nur unzureichend von relationalen Datenbanken unterstützt wird, werden bei der Entwicklung adäquater Systeme insbesondere folgende Entwicklungslinien verfolgt: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-8 ROLAP: Das Data-Warehouse-System wird auf der Basis eines relationalen DBMS als Anwendungssystem realisiert. MOLAP: Die Daten werden in einer speziellen mehrdimensionalen Form gespeichert (etwa mehrdimensionale Arrays). Gegenwärtig haben viele Datenbankhersteller den SQL-Support fürs Data Warehousing wesentlich erweitert (so auch der aktuelle SQL-Standard)!

9 Wesentliche Anforderung: Das Data Warehouse soll unterschiedlichen Mitarbeitern und Problemstellungen gerecht werden. Deswegen werden auch unterschiedliche Anfragewerkzeuge eingesetzt: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-9 Standard-SQL-Aggregierungen Data Mining Tools (inkl. Neuronalen Netzwerken) Statistische Analysen Expertensysteme (Frage/Antwort-Systeme) Die adäquate Aufbereitung von Dimensionsanfragen ist durchaus aufwendig und nicht unproblematisch!

10 8.2 Adäquater Datenbankentwurf c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-10 Dimensionstabellen sind üblicherweise nicht normalisiert, d.h. es gibt eine Faktentabelle mit zugehörigen Dimensionstabellen. Dies nennt man auch Star-Schema. Abbildung 8-3: Ein Star-Schema

11 Zweck: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-11 Anzahl der Joins wird kleiner. spezieller Join: star-join kann gut optimiert werden Auftretende Redundanzen oft unproblematisch, da Dimensionsdaten sich nur wenig ändern und im wesentlichen Einfügungen enthalten. Normalisierte Dimensionen werden auch Snowflake-Schema genannt. Praktiker empfehlen üblicherweise das Starschema! ggf. weitere Variationen in bestimmten Anwendungsszenarien sinnvoll: Beispiel: Die Struktur einiger Dimensionen ändert sich sehr häufig: Hier kann es sinnvoll sein, ggf. diese Dimension durch eine Meta-Dimension zu ersetzen.

12 8.3 Datenwürfel und DW-Anfragen c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing entnommen aus (Kemper und Eickler 2001, Kapitel 17)

13 Das Stern-Schema: Handelsunternehmen Kunden Produkte Verkäufe Filialen Zeit Verkäufer

14 Das Stern-Schema: Krankenversicherung Patienten Ärzte Behandlungen Krankenhäuser Zeit Krankheiten

15 Stern-Schema Passau 25-Jul-00 Verkäufer Kunde Anzahl Produkt Filiale VerkDatum Verkäufe Bayern D Passau Bezirk Land FilialenKennung Filialen 43 Kemper 4711 wiealt Name KundenNr Kunden Elektronik Handyman 825 wiealt Manager Fachgebiet Name VerkäuferNr Verkäufer Faktentabelle (SEHR groß) Dimensionstabellen (relativ klein)

16 Stern-Schema (cont d) Weihnachten Dienstag Dec-01 Hochsommer Saison Dienstag Wochentag Jul-00 KW Quartal Jahr Monat Tag Datum Zeit.... Siemens Telekom Mobiltelekom Handy Hersteller Produkthauptgruppe Produktgruppe Produkttyp ProduktNr Produkte

17 Nicht-normalisierte Dimensionstabellen: effizientere Anfrageauswertung Zeit Datum Tag Monat Jahr Quartal KW Wochentag Saison 25-Jul Dienstag Hochsommer 18-Dec Dienstag Weihnachten Datum Monat Quartal ProduktNr Produkttyp Produkte Produktgruppe Produkthauptgruppe Hersteller Handy Mobiltelekom Telekom Siemens.... ProduktNr Produkttyp Produktgruppe Produkthauptgruppe

18 Normalisierung führt zum Schneeflocken-Schema Produkthauptgruppen Kunden Filialen Produktgruppen Produkttypen Zeit Verkäufe Verkäufer Produkte KWs Quartale

19 Anfragen im Sternschema select sum(v.anzahl), p.hersteller from Verkäufe v, Filialen f, Produkte p, Zeit z, Kunden k where z.saison = 'Weihnachten' and z.jahr = 2001 and k.wiealt < 30 and p.produkttyp = 'Handy' and f.bezirk = 'Bayern' and v.verkdatum = z.datum and v.produkt = p.produktnr and v.filiale = f.filialenkennung and v.kunde = k.kundennr group by p.hersteller; Einschränkung der Dimensionen Join-Prädikate

20 Algebra-Ausdruck σ(produkte) σ(filialen) A A Verkäufe A A σ(kunden) σ(zeit)

21 Roll-up/Drill-down-Anfragen select Jahr, Hersteller, sum(anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and v.verkdatum = z.datum and p.produkttyp = 'Handy' group by p.hersteller, z.jahr; select Jahr, sum(anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and v.verkdatum = z.datum and p.produkttyp = 'Handy' group by z.jahr; Roll-up Drill-down

22 Ultimative Verdichtung select sum(anzahl) from Verkäufe v, Produkte p where v.produkt = p.produktnr and p.produkttyp = 'Handy';

23 Rollup Drill- Down

24 Flexible Auswertungsmethoden: slice and dice Regionen Produktgruppen Kunden Regionen Regionen Produktgruppen Produktgruppen Kunden Kunden

25 Materialisierung von Aggregaten insert into Handy2DCube ( select p.hersteller, z.jahr, sum(v.anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and p.produkttyp = 'Handy' and v.verkdatum = z.datum group by z.jahr, p.hersteller ) union ( select p.hersteller, to_number(null), sum(v.anzahl) from Verkäufe v, Produkte p where v.produkt = p.produktnr and p.produkttyp = 'Handy' group by p.hersteller ) union ( select null, z.jahr, sum(v.anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and p.produkttyp = 'Handy' and v.verkdatum = z.datum group by z.jahr ) union ( select null, to_number(null), sum(v.anzahl) from Verkäufe v, Produkte p where v.produkt = p.produktnr and p.produkttyp = 'Handy' );

26 Relationale Struktur der Datenwürfel

27 Würfeldarstellung

28 Der cube-operator (SQL-3) select p.hersteller, z.jahr, f.land, sum(v.anzahl) from Verkäufe v, Produkte p, Zeit z, Filialen f where v.produkt = p.produktnr and p.produkttyp = 'Handy' and v.verkdatum = z.datum and v.filiale = f.filialenkennung group by cube (z.jahr, p.hersteller, f.land);

29 Wiederverwendung von Teil-Aggregaten insert into VerkäufeProduktFilialeJahr ( select v.produkt, v.filiale, z.jahr, sum(v.anzahl) from Verkäufe v, Zeit z where v.verkdatum = z.datum group by v.produkt, v.filiale, z.jahr ); select v.produkt, v.filiale, sum(v.anzahl) from Verkäufe v group by v.produkt, v.filiale

30 Wiederverwendung von Teil-Aggregaten select v.produkt, v.filiale, sum(v.anzahl) from VerkäufeProduktFilialeJahr v group by v.produkt, v.filiale select v.produkt, z.jahr, sum(v.anzahl) from Verkäufe v, Zeit z where v.verkdatum = z.datum group by v.produkt, z.jahr

31 Die Materialisierungs-Hierarchie { } {Produkt} {Jahr} {Filiale} {Produkt, Jahr} {Produkt, Filiale} {Filiale, Jahr} {Produkt, Filiale, Jahr} Teilaggregate T sind für eine Aggregation A wiederverwendbar wenn es einen gerichteten Pfad von T nach A gibt Also T A Man nennt diese Materialisierungshierarchie auch einen Verband (Engl. Lattice)

32 8.4 TPC-D-Benchmark c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-13 Decision-Support-Anfragen in einem hypothetischen Handelsunternehmen Inzwischen ist dieser Benchmark in zwei Benchmarks aufgeteilt (TPC-H und TPC-R). Abbildung 8-4: Das TPC-D-Datenmodell

33 Datenbankgröße skalierbar (SF=1,10,30,100,300,1000), dabei ergibt SF=1 ungefähr 1GB Nutz- Daten. 19 Anfragen: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-14 aufsummierender Preisbericht Gute Lieferanten für bestimmte Teile nichtabgearbeitete Lieferungen (sortiert nach Priorität)... Erzeugung neuer Bestellungen (SF*1500) Entfernung von überflüssigen oder überholten Informationen (ebenfalls SF*1500) Leistungsgrößen: Systempreis auf 5 Jahre TPC-D-Powermetrik QppD@Size: Anzahl der sequentiell ausgeführten Anfragen und Änderungen pro Stunde, gewichtet mit der Skalierung Durchsatz QthD@Size: Anzahl der Anfragen und Änderungen pro Stunde bei Parallelisierung Preis/Leistungsverhältnis (Dollar pro Anfrage pro Stunde): Hierbei wird für die Anzahl der Anfragen pro Stunde das geometrische Mittel von QppD@Size und QthD@Size verwendet. Gegenwärtige Werte (für eine 300-GB-Datenbank): QppD@300GB=2000, QthD@300GB=1200 bei einem Systempreis von 5 Mio $.

34 c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-15 Beispiel: Veränderung des Marktanteils einer Nation innerhalb zweier Jahre (Query 8) (Achtung: Hier SQL-2, nicht Oracle-SQL!) select o_year, sum(case when nation = " then volume else 0 end) / sum(volume) as mkt_share from ( select extract(year from o_orderdate) as o_year, l_extendedprice * (1 - l_discount) as volume, n2.n_name as nation from part,supplier,lineitem,orders,customer, nation n1,nation n2,region where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name = " and s_nationkey = n2.n_nationkey and o_orderdate between date and date and p_type = " ) as all_nations group by o_year order by o_year;

35 Beispiel: Bestimmng des Brutto-Umsatzes bestimmter Produkte (Query 19) (Typische Anfrage für Data Mining-Tools) c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-16 select sum(l_extendedprice* (1 - l_discount)) as revenue from lineitem, part where ( p_partkey = l_partkey and p_brand = and p_container in ( SM CASE, SM BOX, SM PACK, SM PKG ) and l_quantity >= and l_quantity <= + 10 and p_size between 1 and 5 and l_shipmode in ( AIR, AIR REG ) and l_shipinstruct = DELIVER IN PERSON ) or ( p_partkey = l_partkey and p_brand = and p_container in ( MED BAG, MED BOX, MED PKG, MED PACK ) and l_quantity >= and l_quantity <= + 10 and p_size between 1 and 10 and l_shipmode in ( AIR, AIR REG ) and l_shipinstruct = DELIVER IN PERSON ) or ( p_partkey = l_partkey and p_brand = and p_container in ( LG CASE, LG BOX, LG PACK, LG PKG ) and l_quantity >= and l_quantity <= + 10 and p_size between 1 and 15 and l_shipmode in ( AIR, AIR REG ) and l_shipinstruct = DELIVER IN PERSON );

36 8.5 SQL-Support für Data Warehousing c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing Erweiterte Anfrageunterstützung In der SQL GROUP BY-Klausel können Rollup- und Cube-Anfragen direkt formuliert werden. Beispiel: EMP: EMPNO ENAME JOB MGR HIREDA SAL COMM DEPTNO SMITH CLERK ALLEN SALESMAN WARD SALESMAN JONES MANAGER MARTIN SALESMAN BLAKE MANAGER CLARK MANAGER SCOTT ANALYST KING PRESIDENT TURNER SALESMAN ADAMS CLERK JAMES CLERK FORD ANALYST MILLER CLERK DEPT: DEPTNO DNAME LOC ACCOUNTING NEW YORK 20 RESEARCH DALLAS 30 SALES CHICAGO 40 OPERATIONS BOSTON

37 Rollup-Anfragen: select deptno,job,count(*),sum(sal) from emp group by rollup (deptno,job) c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-18 DEPTNO JOB COUNT(*) SUM(SAL) CLERK MANAGER PRESIDENT ANALYST CLERK MANAGER CLERK MANAGER SALESMAN Wie sieht diese Anfrage ohne rollup aus?

38 Bestimmung aller Werte eines Datenwürfels: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-19 select deptno,job,sum(sal) DEPTNO JOB SUM(SAL) from emp group by cube(deptno,job); 10 CLERK MANAGER PRESIDENT ANALYST CLERK MANAGER CLERK MANAGER SALESMAN ANALYST 6000 CLERK 4150 MANAGER 8275 PRESIDENT 5000 SALESMAN

39 Weitere Beispiele: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-20 select deptno,job,count(*),sum(sal) from emp group by rollup (deptno,job) having grouping(job)=1 DEPTNO JOB COUNT(*) SUM(SAL)

40 c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-21 select decode(grouping(dname),1, All Departements,dname) AS departement, decode(grouping(job),1, All Jobs,job) AS job, count(*), sum(sal) from where emp,dept emp.deptno=dept.deptno group by rollup (dname,job) DEPARTEMENT JOB COUNT(*) SUM(SAL) ACCOUNTING CLERK ACCOUNTING MANAGER ACCOUNTING PRESIDENT ACCOUNTING All Jobs RESEARCH ANALYST RESEARCH CLERK RESEARCH MANAGER RESEARCH All Jobs SALES CLERK SALES MANAGER SALES SALESMAN SALES All Jobs All Departements All Jobs

41 Top-n/Bottom-n-Anfragen: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-22 oft interessieren nur die besten/schlechtesten Ergebnisse. SQL-3 bietet hierzu eine neue Klausel STOP AFTER n. Derartige Anfragetypen wurden zuvor von SQL nicht adäquat unterstützt. Beliebter Trick: Viele DBMSe nummerieren die Tupel in Tabellen und Anfrageergebnissen. Risiko: Fehlinterpretation der Nummerierung, Änderung der Implementierung des DBMS,... Beispiel: Oracle 8i: Attribut rownum enthält die Nummer eines Tupels Folgende Anfrage scheitert: select ename, sal ENAME SAL from emp where rownum < 6 ALLEN 1600 order by sal desc WARD 1250 MARTIN 1250 SMITH 800 In Oracle-8i wird erst rownum gesetzt und dann sortiert!

42 c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-23 Lauffähige Oracle8i-Lösungen: create or replace view emp_view as select * from emp order by sal desc select ename,sal from emp_view where rownum < 6 oder auch select ename,sal from (select * from emp order by sal desc) where rownum < 6 Ergebnis: ENAME SAL KING 5000 SCOTT 3000 FORD 3000 JONES 2975 BLAKE 2850

43 8.5.2 Datenmodellierung c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-24 Dimensionen können hierarchisch strukturiert werden. Dies kann in Anfragen und bei der Anfrageoptimierung (Materialisierung von Anfragen) effizient eingesetzt werden. Beispiel: (Oracle) Data-Warehouse-Tabellen: bundeslaender(bundeslaender code,budeslaender name) staedte(staedte code,staedte name,bundeslaender code) produkte(produkte code,produkte name,marke) verkaeufe(verkauf code,datum,betrag,produkte code,staedte code) zeit(datum,woche,monat, monats name,quartal,jahr,jahreszeit)

44 c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-25 Flexible Definition von Dimensionen: create dimension zeit_dim level datum is zeit.datum level woche is zeit.woche level monat is zeit.monat level quartal is zeit.quartal level jahreszeit is zeit.jahreszeit level jahr is zeit.jahr hierarchy kalender_rollup ( datum child of monat child of quartal child of jahr) hierarchy jahreszeit_rollup( datum child of jahreszeit child of jahr) hierarchy wochen_rollup ( datum child of woche child of jahr) attribute monat determines zeit.monats_name;

45 Normalisierte Dimensionen: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-26 create dimension regionen_dim level staedte_code is staedte.staedte_code level staedte_name is staedte.staedte_name level bundeslaender_code is bundeslaender.bundeslaender_code level bundeslaender_name is bundeslaender.bundeslaender_name hierarchy bundeslaender_rollup ( staedte_code CHILD OF bundeslaender_code JOIN KEY staedte.bundeslaender_code REFERENCES bundeslaender_code) ATTRIBUTE staedte_code determines staedte.staedte_name ATTRIBUTE bundeslaender_code DETERMINES bundeslaender.bundeslaender_name;

46 8.5.3 Optimierung von Data Warehouse-Anfragen c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-27 Wesentliches Problem: der Join mit den verschiedenen Dimensionen wird dauernd benötigt. Idee: Bestimmte Anfragen kommen immer wieder als Teilanfragen vor. Diese Anfragen werden als Sicht berechnet und gespeichert! ( Materialized View) Darauf basierende Anfragen greifen dann nicht mehr auf die Basistabellen, sondern auf den Materialized View zu. Dabei werden auch die in der HIERACHY-Klausel Dimensionen mitberücksichtigt! Beispiel: create materialized view verkaeufe_summary enable query rewrite as select p.marke, b.bundeslaender_code, s.staedte_name, z.monat, sum(v.betrag) as total_verkaeufe from verkaeufe v, staedte s, zeit z, bundeslaender b, produkte p where v.staedte_code = s.staedte_code and s.bundeslaender_code = b.bundeslaender_code and v.datum = z.datum and v.produkte_code = p.produkte_code group by p.marke, b. bundeslaender_code, s.staedte_name, z.monat;

47 Anfrage: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-28 select p.marke, b.bundeslaender_name, z.jahr, sum(v.betrag) as total_verkaeufe from verkaeufe v, staedte s, zeit z, bundeslaender b, produkte p where v.staedte_code = s.staedte_code and s.bundeslaender_code = b.bundeslaender_code and v.datum = z.datum and v.produkte_code = p.produkte_code group by p.marke, b. bundeslaender_name, z.jahr; Execution Plan SELECT STATEMENT Optimizer-CHOOSE SORT (GROUP BY) HASH JOIN HASH JOIN TABLE ACCESS (FULL) OF BUNDESLAENDER TABLE ACCESS (FULL) OF VERKAEUFE_SUMMARY VIEW SORT (UNIQUE) TABLE ACCESS (FULL) OF ZEIT

48 Weitere Optimierungsaspekte: c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-29 Spezielle Algorithmen für Star-Joins Load-Strategien fürs Data Warehouse: Wie lädt man 1 TByte oder 20 Mio. Transaktionen in vier Stunden in das Data Warehouse?

49 8.6 Weitere Fragestellungen c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-30 Im Zusammenhang mit Data Warehouses werden eine ganze Reihe weiterer aktueller Forschungsfragen behandelt, darunter im Zusammenhang mit dem sog. ETL-Prozess (Extract Transform Load): (konsistente) Integration von Daten aus verschiedenen Quellen Auswahl der zu integrierenden Daten Auswahl einer gemeinsamen Darstellung (Modell) Bereinigung von Fehlern, Vervollständigung Erkennen von Änderungen in operationalen DBen (inkrementelles) Propagieren der Änderungen ins Warehouse erforderliche Meta-Daten...

50 ETL-Prozess c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-31 data warehouse data staging area Loading Completion Cleaning Integration aux. DB Completion Integration Cleaning Transformation Transformation Completion rules Monitoring & Extraction Monitoring & Extraction Monitoring & Extraction operational DB operational DB operational DB

51 8.7 Literaturhinweise c M. Scholl, 2005/06 Informationssysteme: 8. Data Warehousing 8-32 Chaudhuri, S. und U. Dayal (1997). An Overview of Data Warehousing and OLAP Technology. ACM SIGMOD Record, 26(1): Craig, R.S., J. Vivona und D. Bercovitch (1999). Microsoft Data Warehousing. Wiley. Debevoise, T. (1999). The data warehouse method. Prentice Hall. Inmon, W.H., K. Rudin, C. Buss und R. Sousa (1999). Data Warehouse Performance. Wiley. Kemper, A. und A. Eickler (2001). Datenbanksysteme: Eine Einführung. Oldenbourg, 4 Aufl. Kimball, R. (1996). The data warehouse toolkit: practical techniques for building dimensional data warehouses. Wiley. Kisseleff, A. (1999). Oracle8i Warehousing. In: 12. DOAG, Stuttgart. Kurz, A. (1999). Data Warehousing Enabling Technology. mitp Verlag, Bonn. TPC (1999). The TPC Benchmark H.