Operative vs. Informationelle Systeme Informationelle

Moderne Betriebliche Anwendungen von
Datenbanksystemen
Operative vs. Informationelle
Systeme
• Anspruch an Datenbanken in Unternehmen ist vielschichtig.
Online Transaction Processing
• Man kann sie - je nach Einsatzzweck - in operative und informationelle Systeme einteilen.
• Operative Systeme
Betriebswirtschaftliche StandardSoftware (SAP R/3)
• eingesetzt von Sachbearbeitern, am Bankschalter, etc.
• dienen der täglichen Arbeit
• Informationelle Systeme
Data Warehouse-Anwendungen
• helfen dem Management, (strategische) Entscheidungen zu finden.
Data Mining
• bieten Grundlage für weitere Analysen mit OLAP / Data Mining
(durch DSS = Decision Support Systems)
(Systeme für Business Intelligence Anwendungen)
Informationelle Systeme
• zugeschnitten auf Gegenstandsbereiche (sog. Subjects), z.B.
Informationelle Systeme
• enthalten sehr große Datenmengen
• Kunde,
• Produkt,
• Vertriebsregion
• unterstützen Informations- und Analyseaufgaben,
• enthalten zum großen Teil historische, zusammengefasste Daten
• Historie aus Daten der operativen Systeme ist nachvollziehbar
• relativ hohe Redundanz
d.h. das Management in der Entscheidungsfindung
• Überblick über alle relevanten Unternehmensdaten
• wenige Zugriffe, aber mit relativ hohem Datenvolumen
• komplexe, oft heuristische Ad-hoc-Anfragen
• Datenbankeinträge werden nicht geändert (keine Updates)
• Antwortzeitverhalten spielt untergeordnete Rolle
• z.B. auf der Basis von OLAP-Funktionalitäten
• Daten sind wohl strukturiert, integriert und konsolidiert
• Anzahl Benutzer ist eher klein („Power-User“)
Gegensätze
Grundlagen
Operative Systeme
Informationelle Systeme
•
•
•
•
•
•
•
•
•
•
Schnelle Antwortzeit
Anwendungsorientiert
Aktuelle Daten
Detaillierte, primäre Daten
Häufige Änderungen
Dient täglicher Arbeit
OLAP
Tools
Hohe Speicherkapazität
Gegenstandsorientiert
Historische Daten
Auch zusammengefasste, abgeleitete
Daten
• Keine Updates
• Dienst als Datenspeicher für Analyse
und Entscheidungsfindung
DWh
Ext.
Daten
Legacy
Systeme
Data
Mining und
Statistik
Tools
DBMS &
Data Marts
⇒ Man muss beide Systeme trennen.
Kausale
Modelle
Intelligente
Informationssysteme und
Reports
Analytiker
Management
Data Warehouse für den informationellen Systemteil
operative
Daten
OLTP: Online Transaction Processing
Beispiele
Flugbuchungssystem
Bestellungen in einem Handelsunternehmen
Charakterisierung
Hoher Parallelitätsgrad
Viele (Tausende pro Sekunde) kurze Transaktionen
TAs bearbeiten nur ein kleines Datenvolumen
„mission-critical“ für das Unternehmen
Hohe Verfügbarkeit muss gewährleistet sein
Normalisierte Relationen (möglichst wenig Update-Kosten)
Nur wenige Indexe (wegen Fortschreibungskosten)
informationelle
Daten
SAP R/3: Enterprise Resource
Modelling (ERP-System)
WAN (Internet)
LAN
Relationales DBMS als Backend-Server
(Oracle, Informix, DB2, MS SQL-Server,
Adabas)
Dreistufige Client/Server-Architektur (3
Tier, SAP R/3)
sehr
viele
(Tausen
de)
Clients
Sehr schnelles
LAN
(z.B. FDDI)
Interne Architektur von SAP R/3
ein
DatenbankServer mehrere
Applikatio
nsServer
zur
Skalierun
g
„langsame“
Netzverbindung
(WAN, Internet, Telefon, ...)
Transaktionsverarbeitung in SAP R/3
Sperren
freigeben
Sperren anfordern
P2
P3
Wie hat sich die Auslastung der Transatlantikflüge über die
letzten zwei Jahre entwickelt?
oder
Posting-Schritte
P1
Data Warehouse-Anwendungen:
OLAP~Online Analytical Processing
P3
Dialog-Schritte
D1
D2
Online-Phase
Wie haben sich besondere offensive Marketingstrategien für
bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt?
D3
Posting-Phase
Gegenstandsorientierung
(subject-oriented)
Was ist ein Data Warehouse?
• DWh ist an Gegenstandsbereichen des Unternehmens orientiert,
• „Mit dem Begriff Data Warehouse wird eine von den operationalen DV-Systemen
• z.B. Produkten, Kunden, Lieferanten
isolierte Datenbank umschrieben, die als unternehmensweite Datenbasis für
Management-Unterstützungssysteme dient.“
[Muksch et al. 1996]
• Gegensatz zu Funktions- oder Anwendungsorientierung bei operativen
(legacy) Systemen:
• „A Data Warehouse is a
• Funktionen sind z.B. Einkauf, Lagerhaltung, Verkauf
• subject-oriented,
• integrated,
• Bei der Entwicklung eines DWh stehen die Daten im Mittelpunkt.
• time-variant,
• Bei operationalen Systemen muss auch der Prozess berücksichtigt werden.
• nonvolatile
collection of data in support of management‘s decision-making process.“
[Inmon, Hackathron 1994]
• 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
Integration
• Daten aus verschiedenen Quellen werden im DWh vereinheitlicht, u.a. durch
Operative Systeme
• konsistente Vergabe und Definition von Bezeichnern
• einheitliche Kodierung
Integration,
Konsolidierung
• z.B. wird jedes Datum in der Form <YYYY-MM-DD> gespeichert
Data
Warehouse
• einheitliches Festlegen der Maßeinheiten von Attributen
• z.B. werden Preise in Dollar angegeben
Externe Datenquellen
• Auflösung von strukturellen Konflikten
• z.B. Schema-Wert-Konflikt
• In zwei verschiedenen operativen Systemen können
• die gleichen Daten unter verschiedenen Bezeichnern abgelegt sein
• Integration führt dazu, dass alle Daten im DWh in einer einzigen, allgemein
akzeptierten Art und Weise gespeichert sind.
• die gleichen Bezeichner für verschiedene Zwecke benutzt werden
• der gleiche Sachverhalt auf verschiedene Weise kodiert sein
• Erst die Integration erlaubt die einfache und effektive Nutzung der DWh-Daten
für Anwendungen z.B. im Management
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 ist ein schwieriger und zeitaufwendiger Prozess
Lebenszyklus eines Data Warehouse
Zeitraumbezug (time variancy)
Behandlung von Strukturkonflikten in relationalen Schemata: [Saltor et. al. 1993]
• In operativen Systemen ist der aktuelle Datenbestand gespeichert.
Er kann jederzeit geändert werden (Update).
• Beispiel: Datenbank für Aktienkurse
• Datenbank New York (ein Tupel pro Tag und Aktie)
date
991008
991008
991008
991009
991009
991009
stock
IBM
HP
GM
IBM
HP
GM
clsprice
347
418
250
350
420
215
• 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)
• Datenbank Barcelona (ein Tupel pro Tag, ein Attribut pro Aktie)
date
991008
991009
HP
418
420
IBM
365
350
GM
250
200
• Datenbank Melbourne (eine Relation pro Aktie, ein Tupel pro Tag)
HP
date
clsprice
991008
991009
425
420
IBM
date
clsprice
910408
910409
347
350
GM
date
clsprice
991008
991009
385
320
• 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 support
of management‘s decision-making process.
[Inmon, Hackathron 1994]
Beständigkeit (nonvolatility)
Architektur einer Data Warehouse
Umgebung
• Operative Systeme: Daten werden oft geändert, gelöscht, eingefügt.
OLAP
Tools
• Aufwendige Mechanismen, um Deadlocks zu vermeiden
• Locking-Mechanismen, etc.
DWh
• DWh: primär nur Leseoperationen
• Daten werden aus den operativen Systemen (initial) geladen
Ext.
Daten
• Analysesysteme greifen lesend auf DWh-Daten zu.
Legacy
Systeme
• Es gibt keine Updates
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]
operative
Daten
Data
Mining und
Statistik
Tools
DBMS &
Data Marts
informationelle
Daten
Kausale
Modelle
Intelligente
Informationssysteme und
Reports
Analytiker
Management
Architektur einer DWh-Umgebung
Die innere Struktur eines Data Warehouse
Beispiel: Telekommunikationsunternehmen
Stark zusammengefasste Daten
Leicht zusammengefasste Daten
Metadaten
Architektur einer DWh-Umgebung
detailliert
• Für jeden Kunden, jedes
Gespräch inkl.
• Zone
• Teilnehmer
• Zeitpunkt
• Dauer
• Gebühren
• Art des Dienstes
∅ 45.000 Byte pro Kunde
Aktuelle detaillierte Daten
leicht zusammengefasst
• Für jeden Kunden
• Anzahl der Gespräche
insgesamt
• Anzahl der Ferngespräche
• ∅ Gesprächsdauer
• Umsatz je Zone
• Umsatz insgesamt
Zusammenfassung monatlich
ca. 200 Byte pro Kunde
Alte (detaillierte) Daten
Architektur einer DWh-Umgebung
Architektur einer DWh-Umgebung
Datenflüsse im Data Warehouse
Metadaten
• Metadaten sind Daten über Daten
• Metadaten lassen sich in Kategorien einteilen:
Zusam
menfas
sen
• semantische Metadaten
Zus
am
me
nfa
sse
n
• 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
Laden von Daten aus
operativen Systemen
verschiedenen Aggregationsstufen
A
ess
roz
gsp
n
u
lter
Architektur einer DWh-Umgebung
Metadaten (forts.):
• verwaltungstechnische Metadaten
• Festlegung von Benutzer (-gruppen) und zugehörige Zugriffsrechte
DWh-Entwicklungszyklus
DWh-Entwicklungszyklus unterscheidet sich vom klassischen:
• Am Anfang des Data-Warehouse-Entwicklungszyklus stehen die Daten
(der Prozess ist datengeleitet (data-driven))
• statische Daten über das DWh
• Größe von Tabellen
• Das Data Warehouse wird schrittweise entwickelt.
• Zugriffsrechte auf Tabellen
• Gründe:
• schematische Metadaten
• logisches Schema des DWh
• Abbildung zwischen logischem und physischem Schema
• Quellen der DWh-Daten
Data Warehouse Entwicklungszyklus
• 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 Entwicklungszyklus
Iterative Vorgehensweise
Monitoring der DWh-Benutzung
• 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)
• 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?
• Management wird erst dann größeres Projektbudget genehmigen,
wenn positive Resultate sicher greifbar sind.
• Welche Antwortzeiten treten bei welchen Anfragen auf?
• Wie ist die Belastung des DWh?
• Qualität des DWh wird durch feedback loops mit Anwendern deutlich verbessert.
⇒ Leitmotiv: Think big! Start small! Grow step by step!
Sammlung und periodische Auffrischung
der Data Warehouse-Daten
OLTP-Datenbanken
und andere Datenquellen
Das Stern-Schema
OLAP-Anfragen
Decision Support
Data Mining
Data Warehouse
Stern-Schema bei Data WarehouseAnwendungen
Eine sehr große Faktentabelle
Alle Verkäufe der letzten drei Jahre
Alle Telefonate des letzten Jahres
Alle Flugreservierungen der letzten fünf Jahre
normalisiert
Mehrere Dimensionstabellen
Zeit
Filialen
Kunden
Produkt
Oft nicht normalisiert
Das Stern-Schema:
Handelsunternehmen
Produkte
Kunden
Filialen
Verkäufe
Zeit
Verkäufe
r
Das Stern-Schema:
Krankenversicherung
Stern-Schema
Patienten
Ärzte
VerkDatum
Filiale
Verkäufe
Produkt
Anzahl
Kunde
Verkäufer
25-Jul-00
...
Passau
...
1347
...
4711
...
825
...
1
...
Faktentabelle (SEHR groß)
Kranken
häuser
Behandlunge
n
Filialen
FilialenKennung Land
Bezirk
Passau
...
Bayern ...
...
...
D
...
...
Kunden
KundenNr Name
wieAlt
...
4711
...
...
...
Kemper 43
...
...
Dimensionstabellen (relativ klein)
Zeit
Krankhei
ten
Stern-Schema (cont‘d)
Datum
Tag
Monat
Jahr
Zeit
Quartal KW
25-Jul-00
...
18-Dec-01
...
25
...
18
...
7
...
12
...
2000
...
2001
...
3
...
4
...
30
...
52
...
Verkäufer
Fachgebiet Manager
VerkäuferNr
Name
825
...
Handyman Elektronik
...
...
119
...
wieAlt
...
23
...
...
...
Nicht-normalisierte Dimensionstabellen:
effizientere Anfrageauswertung
Wochentag
Saison
Datum
Tag
Monat
Jahr
Zeit
Quartal KW
Dienstag
Hochsommer
Dienstag
...
Weihnachten
...
25-Jul-00
...
18-Dec-01
...
25
...
18
...
7
...
12
...
2000
...
2001
...
3
...
4
...
30
...
52
...
Wochentag
Saison
Dienstag
Hochsommer
Dienstag
...
Weihnachten
...
Datum Æ Monat Æ Quartal
ProduktNr Produkttyp
1347
...
Handy
...
Produkte
Produktgruppe Produkthauptgruppe Hersteller ..
Mobiltelekom
...
Telekom
...
Siemens
...
..
..
ProduktNr Produkttyp
Produkte
Produktgruppe Produkthauptgruppe Hersteller ..
1347
...
Mobiltelekom
...
Handy
...
Telekom
...
Siemens
...
ProduktNr Æ Produkttyp Æ Produktgruppe Æ Produkthauptgruppe
..
..
Normalisierung führt zum
Schneeflocken-Schema
Produkthau
ptgruppen
Produktgr
uppen
Filialen
Produktty
pen
Kunden
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.
Verkäufe
Produkte
Zeit
Verkäufe
r
• 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.
KWs
Quartale
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 den
Kontext 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 Sternschema
select sum(v.Anzahl), p.Hersteller
from Verkäufe v, Filialen f, Produkte p, Zeit z, Kunden k
Einschränkung
where z.Saison = 'Weihnachten' and
der Dimensionen
z.Jahr = 2001 and k.wieAlt < 30 and
Join-Prädikate
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;
Algebra-Ausdruck
Roll-up/Drill-down-Anfragen
σ...(Produkte)
σ...(Filialen)
A
A
Verkäufe
σ...(Kunden)
A
σ...(Zeit)
Ultimative Verdichtung
select sum(Anzahl)
from Verkäufe v, Produkte p
where v.Produkt = p.ProduktNr and p.Produkttyp = 'Handy';
Roll-up
A
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)
Drill-down
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;
R eg io n en
Roll-up
Flexible Auswertungsmethoden: slice
and dice
ProduktgruppenK
u
n
d
u
Materialisierung von
Aggregaten
en
en
Produktgruppen K
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' );
d
R eg io n en
DrillDown
R eg io n en
Produktgruppen K
n
Relationale Struktur der Datenwürfel
u
n
d
en
Würfeldarstellung
Der cube-Operator
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
Wiederverwendung von Teil-Aggregaten
insert into VerkäufeProduktFilialeJahr
select v.Produkt, v.Filiale, sum(v.Anzahl)
( select v.Produkt, v.Filiale, z.Jahr, sum(v.Anzahl)
from VerkäufeProduktFilialeJahr v
from Verkäufe v, Zeit z
group by v.Produkt, v.Filiale
where v.VerkDatum = z.Datum
group by v.Produkt, v.Filiale, z.Jahr );
select v.Produkt, z.Jahr, sum(v.Anzahl)
from Verkäufe v, Zeit z
where v.VerkDatum = z.Datum
select v.Produkt, v.Filiale, sum(v.Anzahl)
from Verkäufe v
group by v.Produkt, v.Filiale
group by v.Produkt, z.Jahr
Die Materialisierungs-Hierarchie
{
Jahr
}
{Jahr}
{P rodukt}
Die Zeit-Hierarchie
{F iliale}
Quartal
{P rodukt, F iliale}
{P rodukt, Jahr}
{F iliale, Jahr}
W oche (K W )
{P rodukt, F iliale, 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)
Bitmap-Indexe
Optimierung durch Komprimierung der Bitmaps
Ausnutzung 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änge
Sonst speichere das Bitmuster
Monat
T ag
Beispiel-Anfrage und Auswertung
Bitmap-Operationen
Bitmap-Join-Index
B-Baum
B-Baum
B-Baum
B-Baum
TID-V
TID-K
TID-V
TID-K
(i,II)(ii,I)(iii
,II)(iv,II)(v,
(I,i)(I,v)(II,i
)(II iii)(II iv
(i,II)(ii,I)(iii
,II)(iv,II)(v,
(I,i)(I,v)(II,i
)(II iii)(II iv
5
5
B-Baum
TID-V
(i,II)(ii,I)(iii
,II)(iv,II)(v,
Select k.*
From Verkäufe v, Kunden k
Where v.ProduktID = 5 And
v.KundenNr = k.KundenNr
B-Baum
TID-K
Select v.*
From Verkäufe v, Kunden k
Where k.KundenNr = 4711 and
v.KundenNr = k.KundenNr
(I,i)(I,v)(II,i
)(II,iii)(II,iv
Beispielanfrage auf dem Sternschema:
Stern-Verbund -- Star Join
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
Einschränkung
der Dimensionen
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;
Join-Prädikate
Illustration des Star Join
Z eit
K unden
V erkäufe
Bitmap-Indexe für die DimensionsSelektion
Z eit
Kunden
Verkäufe
1
1
1
1
1
1
1
P rodukte
Produkte
F ilialen
F ilialen
1
1
1
1
1
1
Ausnutzung der Bitmap-Join-Indexe
Z eit
Kunden
Verkäufe
1
1
1
1
1
1
1
1
1
1
1
1
1
Produkte
F ilialen
1
1
1
1
1
1
1
1
1
1
Eine weitere Join-Methode: DiagJoin
Für 1:N-Beziehungen
Daten sind zeitlich geballt (clustered)
Beispiel
Order
Lineitem
Order A Lineitem
Die Lineitems (Bestellpositionen) einer Order (Bestellung)
kommen zeitlich kurz hintereinander
Grundidee des DiagJoins besteht darin, synchron über die
beiden Relationen zu laufen
Die Orders werden in einem Fenster gehalten
1
DiagJoin
Order
Customer
Order#
Kemper
4711
Maier
5645
Müller
7765
Hummer
9876
Kaller
9965
Lola
3452
Junker
1232
…
…
Order#
LineItem
Position
Produkt
Preis
4711
5645
4711
4711
5645
7765
4711
5645
7765
9876
1
1
2
3
2
1
4
3
2
1
PC
Laptop
Drucker
Toner
Hub
Fax
Papier
Handy
Mixer
Handy
…
…
…
…
…
…
…
…
…
…
…
…
…
…
Order#
LineItem
Position
Produkt
DiagJoin
Order
Customer
Order#
Kemper
4711
Maier
5645
Müller
7765
Hummer
9876
Kaller
9965
Lola
3452
Junker
1232
…
…
DiagJoin
Order
Customer
Order#
Kemper
4711
Maier
5645
Müller
7765
Hummer
9876
Kaller
9965
Lola
3452
Junker
1232
…
…
Order#
LineItem
Position
Produkt
Preis
4711
5645
4711
4711
5645
7765
4711
5645
7765
9876
1
1
2
3
2
1
4
3
2
1
PC
Laptop
Drucker
Toner
Hub
Fax
Papier
Handy
Mixer
Handy
…
…
…
…
…
…
…
…
…
…
…
…
…
…
Order#
LineItem
Position
Produkt
Preis
4711
5645
4711
4711
5645
7765
4711
5645
7765
9876
1
1
2
3
2
1
4
3
2
1
PC
Laptop
Drucker
Toner
Hub
Fax
Papier
Handy
Mixer
Handy
…
…
…
…
…
…
…
…
…
…
…
…
…
…
DiagJoin
Order
Preis
4711
5645
4711
4711
5645
7765
4711
5645
7765
9876
1
1
2
3
2
1
4
3
2
1
PC
Laptop
Drucker
Toner
Hub
Fax
Papier
Handy
Mixer
Handy
…
…
…
…
…
…
…
…
…
…
…
…
…
…
Customer
Order#
Kemper
4711
Maier
5645
Müller
7765
Hummer
9876
Kaller
9965
Lola
3452
Junker
1232
…
…
DiagJoin
Order
Customer
Order#
Kemper
4711
Maier
5645
Müller
7765
Hummer
9876
Kaller
9965
Lola
3452
Junker
1232
…
…
DiagJoin
Order#
LineItem
Position
Produkt
Preis
4711
5645
4711
4711
5645
7765
4711
5645
7765
9876
4711
…
1
1
2
3
2
1
4
3
2
1
5
…
…
…
…
…
…
…
…
…
…
…
…
…
PC
Laptop
Drucker
Toner
Hub
Fax
Papier
Handy
Mixer
Handy
Quirl
…
Order
Customer
Order#
Kemper
4711
Maier
5645
Müller
7765
Hummer
9876
Kaller
9965
Lola
3452
Junker
1232
…
…
Muss zwischengespeichert
werden und „nachbearbeitet“
Order#
LineItem
Position
Produkt
Preis
4711
5645
4711
4711
5645
7765
4711
5645
7765
9876
4711
…
1
1
2
3
2
1
4
3
2
1
5
…
…
…
…
…
…
…
…
…
…
…
…
…
PC
Laptop
Drucker
Toner
Hub
Fax
Papier
Handy
Mixer
Handy
Quirl
…
werden.
Anforderungen an den DiagJoin
1:N Beziehung
Die „1“-er Tupel sind in etwa derselben Reihenfolge gespeichert
worden wie die „N“-er Tupel
Die Tupel werden in der „time-of-creation“-Reihenfolge wieder
von der Platte gelesen (full table scan)
Die referentielle Integrität muss gewährleistet sein
Das Fenster muss so groß sein, dass kaum Tupel
nachbearbeitet werden müssen
Nachbearbeitung bedeutet
Tupel auf dem Hintergrundspeicher speichern
Den zugehörigen Joinpartner via Index auffinden
Also ist ein Index auf Order.Order# hierfür notwendig
Nicht für die erste Phase des DiagJoins
Weitere Decision-Support Anfrage-Typen
Top N-Anfragen
Ich will nur die N besten Treffer erhalten und nicht alle 5
Millionen
Muss bei der Anfrageoptimierung berücksichtigt werden
Online Aggregation
Man berechnet das Ergebnis approximativ
Je länger die Anfrage läuft, desto genauer wird das Ergebnis
Top N-Anfragen
Online-Aggregation
Select A.*
From Angestellte A, Abteilungen abt
Where A.Abteilung = abt.AbteilungsNr and abt.Ort = Passau
Order by A.Gehalt
Stop after 20
Select abt.Ort, avg(A.Gehalt)
From Angestellte A, Abteilungen abt
Where A.Abteilung = abt.AbteilungsNr
Group by abt.Ort