operative vs. informationelle datenbanksystemen systemestaab/lehre/ws0506/db1/kapitel18... ·...
Post on 08-Sep-2019
1 Views
Preview:
TRANSCRIPT
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
top related