Moderne Betriebliche Anwendungen von Datenbanksystemen

Online Transaction Processing

Betriebswirtschaftliche Standard-Software (SAP R/3)

Data Warehouse-Anwendungen

Data Mining

• Anspruch an Datenbanken in Unternehmen ist vielschichtig.• Man kann sie - je nach Einsatzzweck - in operative und informationelle Systeme einteilen.

• Operative Systeme• eingesetzt von Sachbearbeitern, am Bankschalter, etc.• dienen der täglichen Arbeit

• Informationelle Systeme• helfen dem Management, (strategische) Entscheidungen zu finden.(durch DSS = Decision Support Systems) (Systeme für Business Intelligence Anwendungen)

• bieten Grundlage für weitere Analysen mit OLAP / Data Mining

Operative vs. Informationelle Systeme

Informationelle Systeme• zugeschnitten auf Gegenstandsbereiche (sog. Subjects), z.B.

• Kunde,• Produkt,• Vertriebsregion

• unterstützen Informations- und Analyseaufgaben, d.h. das Management in der Entscheidungsfindung

• wenige Zugriffe, aber mit relativ hohem Datenvolumen

• Datenbankeinträge werden nicht geändert (keine Updates)

• Antwortzeitverhalten spielt untergeordnete Rolle

Informationelle Systeme• enthalten sehr große Datenmengen

• enthalten zum großen Teil historische, zusammengefasste Daten• Historie aus Daten der operativen Systeme ist nachvollziehbar

• relativ hohe Redundanz

• Überblick über alle relevanten Unternehmensdaten

• komplexe, oft heuristische Ad-hoc-Anfragen• z.B. auf der Basis von OLAP-Funktionalitäten

• Daten sind wohl strukturiert, integriert und konsolidiert

• Anzahl Benutzer ist eher klein („Power-User“)

GegensätzeOperative Systeme Informationelle Systeme• Schnelle Antwortzeit• Anwendungsorientiert• Aktuelle Daten• Detaillierte, primäre Daten• Häufige Änderungen• Dient täglicher Arbeit

• Hohe Speicherkapazität• Gegenstandsorientiert• Historische Daten• Auch zusammengefasste, abgeleitete

Daten• Keine Updates• Dienst als Datenspeicher für Analyse

und Entscheidungsfindung

⇒ Man muss beide Systeme trennen.Data Warehouse für den informationellen Systemteil

Grundlagen

LegacySysteme

DWh

DBMS & Data Marts

Ext.Daten

DataMining und

StatistikTools

OLAPTools

IntelligenteInformations-systeme und

Reports

operativeDaten

informationelleDaten

Analytiker Management

KausaleModelle

OLTP: Online Transaction ProcessingBeispiele

FlugbuchungssystemBestellungen in einem Handelsunternehmen

CharakterisierungHoher ParallelitätsgradViele (Tausende pro Sekunde) kurze TransaktionenTAs bearbeiten nur ein kleines Datenvolumen„mission-critical“ für das UnternehmenHohe Verfügbarkeit muss gewährleistet sein

Normalisierte Relationen (möglichst wenig Update-Kosten)Nur wenige Indexe (wegen Fortschreibungskosten)

SAP R/3: Enterprise Resource Modelling (ERP-System)

Relationales DBMS als Backend-Server(Oracle, Informix, DB2, MS SQL-Server,

Adabas)

LAN

WAN (Internet)

Sehr schnelles LAN

(z.B. FDDI)

ein Datenbank-

Server mehrereApplikatio

ns-Server

zur Skalierun

g

„langsame“Netzverbindung

(WAN, Internet, Telefon, ...)

sehr viele

(Tausende)

Clients

Dreistufige Client/Server-Architektur (3 Tier, SAP R/3) Interne Architektur von SAP R/3

Transaktionsverarbeitung in SAP R/3

D1 D2 D3

P1 P2 P3 P3Dialog-Schritte

Posting-Schritte

Sperren anfordern

Online-Phase Posting-Phase

Sperrenfreigeben

Data Warehouse-Anwendungen:OLAP~Online Analytical Processing

Wie hat sich die Auslastung der Transatlantikflüge über die letzten zwei Jahre entwickelt?

oder

Wie haben sich besondere offensive Marketingstrategien für bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt?

Was ist ein Data Warehouse?

• „Mit dem Begriff Data Warehouse wird eine von den operationalen DV-Systemen isolierte Datenbank umschrieben, die als unternehmensweite Datenbasis für Management-Unterstützungssysteme dient.“ [Muksch et al. 1996]

• „A Data Warehouse is a• subject-oriented,• integrated,• time-variant,• nonvolatile

collection of data in support of management‘s decision-making process.“[Inmon, Hackathron 1994]

Gegenstandsorientierung (subject-oriented)

• DWh ist an Gegenstandsbereichen des Unternehmens orientiert, • z.B. Produkten, Kunden, Lieferanten

• Gegensatz zu Funktions- oder Anwendungsorientierung bei operativen (legacy) Systemen:

• Funktionen sind z.B. Einkauf, Lagerhaltung, Verkauf

• Bei der Entwicklung eines DWh stehen die Daten im Mittelpunkt.• Bei operationalen Systemen muss auch der Prozess berücksichtigt werden.

• DWh enthält nur solche Daten, die für DSS-Analysten/Manager relevant und interessant sind, werden oder sein könnten.

A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management‘s decision-making process.

[Inmon, Hackathron 1994]

Integration

DataWarehouse

Externe Datenquellen

Operative Systeme

Integration,Konsolidierung

• In zwei verschiedenen operativen Systemen können• die gleichen Daten unter verschiedenen Bezeichnern abgelegt sein• die gleichen Bezeichner für verschiedene Zwecke benutzt werden• der gleiche Sachverhalt auf verschiedene Weise kodiert sein

A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management‘s decision-making process.

[Inmon, Hackathron 1994]

Integration• Daten aus verschiedenen Quellen werden im DWh vereinheitlicht, u.a. durch

• konsistente Vergabe und Definition von Bezeichnern• einheitliche Kodierung

• z.B. wird jedes Datum in der Form <YYYY-MM-DD> gespeichert

• einheitliches Festlegen der Maßeinheiten von Attributen• z.B. werden Preise in Dollar angegeben

• Auflösung von strukturellen Konflikten• z.B. Schema-Wert-Konflikt

• Integration führt dazu, dass alle Daten im DWh in einer einzigen, allgemeinakzeptierten Art und Weise gespeichert sind.

• Erst die Integration erlaubt die einfache und effektive Nutzung der DWh-Datenfür Anwendungen z.B. im Management

• Integration ist ein schwieriger und zeitaufwendiger Prozess

Lebenszyklus eines Data WarehouseBehandlung von Strukturkonflikten in relationalen Schemata: [Saltor et. al. 1993]

• Beispiel: Datenbank für Aktienkurse• Datenbank New York (ein Tupel pro Tag und Aktie)

date stock clsprice991008 IBM 347991008 HP 418991008 GM 250991009 IBM 350991009 HP 420991009 GM 215

• Datenbank Barcelona (ein Tupel pro Tag, ein Attribut pro Aktie)date HP IBM GM991008 418 365 250991009 420 350 200

• Datenbank Melbourne (eine Relation pro Aktie, ein Tupel pro Tag)

GM date clsprice991008 385991009 320

HP date clsprice991008 425991009 420

IBM date clsprice910408 347910409 350

Zeitraumbezug (time variancy)• In operativen Systemen ist der aktuelle Datenbestand gespeichert.

Er kann jederzeit geändert werden (Update).

• DWh enthält eine ganze Historie von Daten

• DWh besteht aus Snapshots der operativen Systeme

• DWh-Daten sind zu einem bestimmten Zeitpunkt gültig (gewesen).Der Gültigkeitszeitraum ist an allen Daten im DWh vermerkt (als Teil des Schlüssels)

• Zeithorizont des DWh: ca. 5-10 Jahre• operative Systeme: max. 60-90 Tage

A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in supportof management‘s decision-making process.

[Inmon, Hackathron 1994]

Beständigkeit (nonvolatility)• Operative Systeme: Daten werden oft geändert, gelöscht, eingefügt.

• Aufwendige Mechanismen, um Deadlocks zu vermeiden• Locking-Mechanismen, etc.

• DWh: primär nur Leseoperationen• Daten werden aus den operativen Systemen (initial) geladen• Analysesysteme greifen lesend auf DWh-Daten zu.• Es gibt keine Updates

A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in supportof management‘s decision-making process.

[Inmon, Hackathron 1994]

Architektur einer Data WarehouseUmgebung

LegacySysteme

DWh

DBMS & Data Marts

Ext.Daten

DataMining und

StatistikTools

OLAPTools

IntelligenteInformations-systeme und

Reports

operativeDaten

informationelleDaten

Analytiker Management

KausaleModelle

Architektur einer DWh-UmgebungDie innere Struktur eines Data Warehouse

Met

adat

enStark zusammengefasste Daten

Leicht zusammengefasste Daten

Aktuelle detaillierte Daten

Alte (detaillierte) Daten

Architektur einer DWh-UmgebungBeispiel: Telekommunikationsunternehmen

detailliert leicht zusammengefasst• Für jeden Kunden, jedes

Gespräch inkl.• Zone• Teilnehmer• Zeitpunkt• Dauer• Gebühren• Art des Dienstes

∅ 45.000 Byte pro Kunde

• Für jeden Kunden• Anzahl der Gespräche

insgesamt• Anzahl der Ferngespräche• ∅ Gesprächsdauer• Umsatz je Zone• Umsatz insgesamt

Zusammenfassung monatlichca. 200 Byte pro Kunde

Architektur einer DWh-UmgebungDatenflüsse im Data Warehouse

Alterungsprozess

Laden von Daten ausoperativen Systemen

Zusammenfassen

Zusammenfassen

Architektur einer DWh-UmgebungMetadaten• Metadaten sind Daten über Daten

• Metadaten lassen sich in Kategorien einteilen:

• semantische Metadaten

• Festlegung der DWh-Terminologie• Transformations- und Integrationsregeln für die Abbildung der

operativen Daten in die DWh-Daten

• Aggregationsregeln für das Zusammenfassen der Daten auf

verschiedenen Aggregationsstufen

Architektur einer DWh-UmgebungMetadaten (forts.):

• verwaltungstechnische Metadaten

• Festlegung von Benutzer (-gruppen) und zugehörige Zugriffsrechte• statische Daten über das DWh

• Größe von Tabellen

• Zugriffsrechte auf Tabellen

• schematische Metadaten

• logisches Schema des DWh

• Abbildung zwischen logischem und physischem Schema

• Quellen der DWh-Daten

DWh-EntwicklungszyklusDWh-Entwicklungszyklus unterscheidet sich vom klassischen:

• Am Anfang des Data-Warehouse-Entwicklungszyklus stehen die Daten(der Prozess ist datengeleitet (data-driven))

• Das Data Warehouse wird schrittweise entwickelt.

• Gründe:• genaue Ziele/ Anforderungen an das DWh sind meistens noch

nicht bekannt, Größe auch schlecht abschätzbar• Kosten und Entwicklungszeit schlecht abschätzbar• benötigte Ressourcen (Mitarbeiter, Rechner, ...) sind hoch

Data Warehouse EntwicklungszyklusIterative Vorgehensweise

• iteratives Vorgehen und kurze feedback loops haben viele Vorteile:

• Anwender können ihre Anforderungen erst dann detailliert artikulieren,wenn der erste DWh-Prototyp vorliegt (1. Stufe der DWh-Entwicklung)

• Management wird erst dann größeres Projektbudget genehmigen, wenn positive Resultate sicher greifbar sind.

• Qualität des DWh wird durch feedback loops mit Anwendern deutlich verbessert.

⇒ Leitmotiv: Think big! Start small! Grow step by step!

Data Warehouse EntwicklungszyklusMonitoring der DWh-Benutzung

• Monitoring ist Voraussetzung für Anpassung des DWh an aktuelle Nutzung

• Welche Daten des DWh werden regelmäßig genutzt?

• In welchem Umfang wächst der Datenbestand?

• Wer benutzt das DWh?

• Welche Antwortzeiten treten bei welchen Anfragen auf?

• Wie ist die Belastung des DWh?

Sammlung und periodische Auffrischung der Data Warehouse-Daten

Data Warehouse

OLTP-Datenbankenund andere Datenquellen

OLAP-AnfragenDecision Support

Data Mining

Das Stern-Schema

Stern-Schema bei Data Warehouse-Anwendungen

Eine sehr große FaktentabelleAlle Verkäufe der letzten drei JahreAlle Telefonate des letzten JahresAlle Flugreservierungen der letzten fünf Jahrenormalisiert

Mehrere DimensionstabellenZeitFilialenKundenProduktOft nicht normalisiert

Das Stern-Schema: Handelsunternehmen

Verkäufe

Zeit

Verkäufer

ProdukteKunden

Filialen

Das Stern-Schema: Krankenversicherung

Behandlungen

Zeit

Krankheiten

ÄrztePatienten

Krankenhäuser

Stern-Schema

..................825471111347Passau25-Jul-00VerkäuferKundeAnzahlProduktFilialeVerkDatum

Verkäufe

............

...BayernDPassau

...BezirkLandFilialenKennungFilialen

............

...43Kemper4711

...wieAltNameKundenNrKunden

..................

...23119ElektronikHandyman825

...wieAltManagerFachgebietNameVerkäuferNrVerkäufer

Faktentabelle (SEHR groß)

Dimensionstabellen (relativ klein)

Stern-Schema (cont‘d)

........................WeihnachtenDienstag5242001121818-Dec-01

HochsommerSaison

DienstagWochentag

..................303200072525-Jul-00KWQuartalJahrMonatTagDatum

Zeit

.................

..SiemensTelekomMobiltelekomHandy1347

..HerstellerProdukthauptgruppeProduktgruppeProdukttypProduktNrProdukte

Nicht-normalisierte Dimensionstabellen: effizientere Anfrageauswertung

........................WeihnachtenDienstag5242001121818-Dec-01

HochsommerSaison

DienstagWochentag

..................303200072525-Jul-00KWQuartalJahrMonatTagDatum

Zeit

.................

..SiemensTelekomMobiltelekomHandy1347

..HerstellerProdukthauptgruppeProduktgruppeProdukttypProduktNrProdukte

Datum Monat Quartal

ProduktNr Produkttyp Produktgruppe Produkthauptgruppe

Normalisierung führt zum Schneeflocken-Schema

Verkäufe

ZeitVerkäufe

r

Produkte

KundenFilialen

Quartale

KWs

Produkttypen

Produktgruppen

Produkthaupt-

gruppen

Vorteile des Stern-Schemas gegenüber herkömmlichen relationalen Schemata

• Schema-Entwurf entspricht der natürlichen Sichtweise der Benutzer• Daten können in einer für Analysen adäquaten Weise zugegriffen werden.

• Erweiterungen und Änderungen am Schema sind leicht zu realisieren.

• Beziehungen zwischen den Tabellen sind vordefiniert• Join-Operationen können durch entsprechende Zugriffspfade

unterstützt werden• Schnelle Antwortzeiten sind möglich

• Stern-Schema kann leicht in relationales DB-Schema umgesetzt werden.

Vorteile des Stern-Schemas gegenüber herkömmlichen relationalen Schemata

• Umsetzung des Stern-Schemas in relationale Tabellen:• Kennzahlentabelle (major table): Die Gegenstände der Analyse

(Kennzahlen) werden in dieser Tabelle gesichert• Nebentabelle (minor tables): Jede Dimension wird zu einer eigenen

Relation / Tabelle.

Kennzahlentabelle:• Jedes Tupel der Kennzahlentabelle besteht aus

• einem Zeiger für jede Dimensionstabelle (Fremdschlüssel), die denKontext eindeutig definieren und

• den numerischen Werten (Daten) für den jeweiligen Kontext.

• Sie enthält die eigentlichen Geschäftsdaten, die analysiert werden sollen.• Die Kennzahlentabelle kann sehr viele Zeilen enthalten (Millionen).• Der Schlüssel der Kennzahlentabelle wird durch die Gesamtheit der

Dimensionszeiger gebildet

Anfragen im Sternschemaselect 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änkungder Dimensionen

Join-Prädikate

Algebra-Ausdruck

Verkäufe

σ...(Filialen)

σ...(Zeit)σ...(Kunden)

σ...(Produkte)

A

A A

A

Roll-up/Drill-down-Anfragenselect Jahr, Hersteller, sum(Anzahl)from Verkäufe v, Produkte p, Zeit zwhere 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 zwhere v.Produkt = p.ProduktNr and v.VerkDatum = z.Datum

and p.Produkttyp = 'Handy'group by z.Jahr;

Roll-up

Drill-down

Ultimative Verdichtungselect sum(Anzahl)

from Verkäufe v, Produkte p

where v.Produkt = p.ProduktNr and p.Produkttyp = 'Handy';

Roll-

up

Drill-

Dow

n

Flexible Auswertungsmethoden: slice and dice

Produktgruppen

Reg

ion

en

K u n d en

Produktgruppen

Re

gio

ne

n

K u n d en

Produktgruppen

Re

gio

ne

n

K u n d en

Materialisierung von Aggregateninsert into Handy2DCube

( select p.Hersteller, z.Jahr, sum(v.Anzahl)from Verkäufe v, Produkte p, Zeit zwhere v.Produkt = p.ProduktNr and p.Produkttyp = 'Handy'

and v.VerkDatum = z.Datumgroup by z.Jahr, p.Hersteller ) union

( select p.Hersteller, to_number(null), sum(v.Anzahl)from Verkäufe v, Produkte pwhere 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 zwhere 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 pwhere v Produkt = p ProduktNr and p Produkttyp = 'Handy' );

Relationale Struktur der Datenwürfel

Würfeldarstellung Der cube-Operatorselect 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-Aggregateninsert 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-Aggregatenselect 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

Teilaggregate T sind für eine Aggregation A wiederverwendbar wenn es einen gerichteten Pfad von T nach A gibtAlso T ...... AMan nennt diese Materialisierungshierarchie auch einen Verband (Engl. Lattice)

{Produkt, Jahr}

{Produkt}

{Filiale, Jahr}

{ }

{Produkt, F iliale}

{Produkt, F iliale, Jahr}

{Jahr} {Filiale}

Die Zeit-Hierarchie

Tag

W oche (KW )

Monat

Quartal

Jahr

Bitmap-Indexe

Optimierung durch Komprimierung der BitmapsAusnutzung der dünnen Besetzung

Runlength-compression Grundidee: speichere jeweils die Länge der Nullfolgen zwischen zwei Einsen

Mehrmodus-Komprimierung: bei langen Null/Einsfolgen speichere deren LängeSonst speichere das Bitmuster

Beispiel-Anfrage und Auswertung

Bitmap-Operationen

Bitmap-Join-Index

B-Baum

TID-V

(i,II)(ii,I)(iii,II)(iv,II)(v,

B-Baum

TID-K

(I,i)(I,v)(II,i)(II iii)(II iv

B-Baum

TID-V

(i,II)(ii,I)(iii,II)(iv,II)(v,

B-Baum

TID-K

(I,i)(I,v)(II,i)(II iii)(II iv

B-Baum

TID-V

(i,II)(ii,I)(iii,II)(iv,II)(v,

Select k.*From Verkäufe v, Kunden kWhere v.ProduktID = 5 And

v.KundenNr = k.KundenNr

5

5

Select v.*From Verkäufe v, Kunden kWhere k.KundenNr = 4711 and

v.KundenNr = k.KundenNr

B-Baum

TID-K

(I,i)(I,v)(II,i)(II,iii)(II,iv

Beispielanfrage auf dem Sternschema: Stern-Verbund -- Star Joinselect 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änkungder Dimensionen

Join-Prädikate

Verkäufe KundenZeit

Filialen

Produkte

Illustration des Star Join

1

1

1

1

1

1

1

1

1

1

1

1

1

1

Verkäufe KundenZeit

FilialenProdukte

Bitmap-Indexe für die Dimensions-Selektion

Ausnutzung der Bitmap-Join-IndexeVerkäufe KundenZeit

F ilialenProdukte

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1Eine weitere Join-Methode: DiagJoin

Für 1:N-BeziehungenDaten sind zeitlich geballt (clustered)Beispiel

OrderLineitemOrder A LineitemDie Lineitems (Bestellpositionen) einer Order (Bestellung) kommen zeitlich kurz hintereinander

Grundidee des DiagJoins besteht darin, synchron über die beiden Relationen zu laufenDie Orders werden in einem Fenster gehalten

DiagJoin

……

1232Junker

3452Lola

9965Kaller

9876Hummer

7765Müller

5645Maier

4711Kemper

Order#Customer

Order

…Handy19876

…………

…Mixer27765…Handy35645…Papier44711…Fax17765…Hub25645…Toner34711…Drucker24711…Laptop15645…PC14711

PreisProduktPositionOrder#LineItem

DiagJoin

……

1232Junker

3452Lola

9965Kaller

9876Hummer

7765Müller

5645Maier

4711Kemper

Order#Customer

Order

…Handy19876

…………

…Mixer27765…Handy35645…Papier44711…Fax17765…Hub25645…Toner34711…Drucker24711…Laptop15645…PC14711

PreisProduktPositionOrder#LineItem

DiagJoin

……

1232Junker

3452Lola

9965Kaller

9876Hummer

7765Müller

5645Maier

4711Kemper

Order#Customer

Order

…Handy19876

…………

…Mixer27765…Handy35645…Papier44711…Fax17765…Hub25645…Toner34711…Drucker24711…Laptop15645…PC14711

PreisProduktPositionOrder#LineItem

DiagJoin

……

1232Junker

3452Lola

9965Kaller

9876Hummer

7765Müller

5645Maier

4711Kemper

Order#Customer

Order

…Handy19876

…………

…Mixer27765…Handy35645…Papier44711…Fax17765…Hub25645…Toner34711…Drucker24711…Laptop15645…PC14711

PreisProduktPositionOrder#LineItem

DiagJoin

……

1232Junker

3452Lola

9965Kaller

9876Hummer

7765Müller

5645Maier

4711Kemper

Order#Customer

Order

…Handy19876…Quirl54711…………

…Mixer27765…Handy35645…Papier44711…Fax17765…Hub25645…Toner34711…Drucker24711…Laptop15645…PC14711

PreisProduktPositionOrder#LineItem

DiagJoin

……

1232Junker

3452Lola

9965Kaller

9876Hummer

7765Müller

5645Maier

4711Kemper

Order#Customer

Order

…Handy19876…Quirl54711…………

…Mixer27765…Handy35645…Papier44711…Fax17765…Hub25645…Toner34711…Drucker24711…Laptop15645…PC14711

PreisProduktPositionOrder#LineItem

Muss zwischengespeichertwerden und „nachbearbeitet“

werden.

Anforderungen an den DiagJoin1:N BeziehungDie „1“-er Tupel sind in etwa derselben Reihenfolge gespeichertworden wie die „N“-er TupelDie Tupel werden in der „time-of-creation“-Reihenfolge wieder von der Platte gelesen (full table scan)Die referentielle Integrität muss gewährleistet seinDas Fenster muss so groß sein, dass kaum Tupel nachbearbeitet werden müssenNachbearbeitung bedeutet

Tupel auf dem Hintergrundspeicher speichernDen zugehörigen Joinpartner via Index auffindenAlso ist ein Index auf Order.Order# hierfür notwendig

Nicht für die erste Phase des DiagJoins

Weitere Decision-Support Anfrage-TypenTop N-Anfragen

Ich will nur die N besten Treffer erhalten und nicht alle 5 MillionenMuss bei der Anfrageoptimierung berücksichtigt werden

Online AggregationMan berechnet das Ergebnis approximativJe länger die Anfrage läuft, desto genauer wird das Ergebnis

Top N-AnfragenSelect A.*From Angestellte A, Abteilungen abtWhere A.Abteilung = abt.AbteilungsNr and abt.Ort = PassauOrder by A.GehaltStop after 20

Online-AggregationSelect abt.Ort, avg(A.Gehalt)From Angestellte A, Abteilungen abtWhere A.Abteilung = abt.AbteilungsNrGroup by abt.Ort