Verkäufe

c○ M. Scholl, 2005/06 – Informationssysteme: 8. Data Warehousing 8-1
8 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.)

◮ 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)“

◮ 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

◮ 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

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

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

◮ 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

◮ 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)!

◮ 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!

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

◮ 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.

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

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

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

Stern-Schema
...
...
...
...
...
...
825
4711
1
1347
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
...
...
...
...
...
...
...
23
119
Elektronik
Handyman
825
...
wieAlt
Manager
Fachgebiet
Name
VerkäuferNr
Verkäufer
Faktentabelle (SEHR groß)
Dimensionstabellen (relativ klein)

Stern-Schema (cont‘d)
...
...
...
...
...
...
...
...
Weihnachten
Dienstag
52
4
2001
12
18
18-Dec-01
Hochsommer
Saison
Dienstag
Wochentag
...
...
...
...
...
...
30
3
2000
7
25
25-Jul-00
KW
Quartal
Jahr
Monat
Tag
Datum
Zeit
..
...
...
...
...
...
..
Siemens
Telekom
Mobiltelekom
Handy
1347
..
Hersteller
Produkthauptgruppe
Produktgruppe
Produkttyp
ProduktNr
Produkte

Nicht-normalisierte Dimensionstabellen:
effizientere Anfrageauswertung
Zeit
Datum Tag Monat Jahr Quartal KW Wochentag Saison
25-Jul-00 25 7 2000 3 30 Dienstag Hochsommer
... ... ... ... ... ...
18-Dec-01 18 12 2001 4 52 Dienstag Weihnachten
... ... ... ... ... ... ...
...
Datum Monat Quartal
ProduktNr
Produkttyp
Produkte
Produktgruppe
Produkthauptgruppe
Hersteller
..
1347
...
Handy
...
Mobiltelekom
...
Telekom
...
Siemens
...
..
..
ProduktNr Produkttyp Produktgruppe Produkthauptgruppe

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

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

Algebra-Ausdruck
σ...(Produkte)
σ...(Filialen)
A
A
Verkäufe
A
A
σ...(Kunden)
σ...(Zeit)

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

Ultimative Verdichtung
select sum(Anzahl)
from Verkäufe v, Produkte p
where v.Produkt = p.ProduktNr and p.Produkttyp = 'Handy';

Rollup
Drill-
Down

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

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' );

Relationale Struktur der Datenwürfel

Würfeldarstellung

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);

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

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

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)

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

◮ 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 $.

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 ’1995-01-01’ and date ’1996-12-31’
and p_type = "’
) as all_nations
group by o_year
order by o_year;

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 = and l_quantity = and l_quantity

8.5 SQL-Support für Data Warehousing
c○ M. Scholl, 2005/06 – Informationssysteme: 8. Data Warehousing 8-17
8.5.1 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
----- ---------- --------- --------- ------ --------- --------- ---------
7369 SMITH CLERK 7902 171280 800 20
7499 ALLEN SALESMAN 7698 200281 1600 300 30
7521 WARD SALESMAN 7698 220281 1250 500 30
7566 JONES MANAGER 7839 020481 2975 20
7654 MARTIN SALESMAN 7698 280981 1250 1400 30
7698 BLAKE MANAGER 7839 010581 2850 30
7782 CLARK MANAGER 7839 090681 2450 10
7788 SCOTT ANALYST 7566 091282 3000 20
7839 KING PRESIDENT 171181 5000 10
7844 TURNER SALESMAN 7698 080981 1500 0 30
7876 ADAMS CLERK 7788 120183 1100 20
7900 JAMES CLERK 7698 031281 950 30
7902 FORD ANALYST 7566 031281 3000 20
7934 MILLER CLERK 7782 230182 1300 10
DEPT: DEPTNO DNAME LOC
--------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON

◮ 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)
--------- --------- --------- ---------
10 CLERK 1 1300
10 MANAGER 1 2450
10 PRESIDENT 1 5000
10 3 8750
20 ANALYST 2 6000
20 CLERK 2 1900
20 MANAGER 1 2975
20 5 10875
30 CLERK 1 950
30 MANAGER 1 2850
30 SALESMAN 4 5600
30 6 9400
14 29025
◮ Wie sieht diese Anfrage ohne rollup aus?

◮ 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 1300
10 MANAGER 2450
10 PRESIDENT 5000
10 8750
20 ANALYST 6000
20 CLERK 1900
20 MANAGER 2975
20 10875
30 CLERK 950
30 MANAGER 2850
30 SALESMAN 5600
30 9400
ANALYST 6000
CLERK 4150
MANAGER 8275
PRESIDENT 5000
SALESMAN 5600
29025

◮ 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)
--------- --------- --------- ---------
10 3 8750
20 5 10875
30 6 9400
14 29025

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 1 1300
ACCOUNTING MANAGER 1 2450
ACCOUNTING PRESIDENT 1 5000
ACCOUNTING All Jobs 3 8750
RESEARCH ANALYST 2 6000
RESEARCH CLERK 2 1900
RESEARCH MANAGER 1 2975
RESEARCH All Jobs 5 10875
SALES CLERK 1 950
SALES MANAGER 1 2850
SALES SALESMAN 4 5600
SALES All Jobs 6 9400
All Departements All Jobs 14 29025

◮ 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!

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

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)

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;

◮ 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;

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;

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’

◮ 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?

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
◮ . . .

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

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):65–74.
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. http://www.tpc.org.