Efficiently Publishing Relational Data as XML Documents
description
Transcript of Efficiently Publishing Relational Data as XML Documents
![Page 1: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/1.jpg)
Efficiently Publishing Relational Data as XML Documents
Hauptseminar: Datenbanksysteme und XML
Dennis Säring
![Page 2: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/2.jpg)
Inhaltsverzeichnis
1. Motivation
2. kurze Wiederholung von XML
3. Ein Beispiel kurz erläutert mit Quellcode belegt
4. Ausführliche Vorstellung der Alternativen
5. Beurteilung der Effizienz aller Alternativen
6. Abschließender Kommentar und Ansätze für die
Zukunft
7. Referenzen
8. Diskussion
![Page 3: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/3.jpg)
1. Motivation & Einführung
XML als kommender Standard, Daten im WWW zu veröffentlichen
Relationale Datenbanken als Industriestandard
Suche nach einer Lösung relationale Daten
in XML – Form zu konvertieren
![Page 4: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/4.jpg)
Was wird dazu benötigt ?
I. SpracheSprache für die Spezifizierung der Konvertierung von rel. Daten in XML
II. Eine effiziente ImplementationImplementation dieser Konvertierung
![Page 5: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/5.jpg)
2. Wiederholung XML Semistrukturiert
Tags kennzeichnen Elemente
Elemente sind geschachtelt angeordnet
![Page 6: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/6.jpg)
<customer id=“C1“> <name> John Doe </name>
<accounts>
<account id=”A1”> 1894654 </account> <account id=”A2”> 3849342 </account> </accounts>
<porders> <porder id=”P01” acct=”A2”> // first purchase order <date> 1 Jan 2000 </date>
<items> <item id=”I1”> shoes </item> <item id=”I2”> bungee ropes </items> </items>
<payments> <payment id=”P1” due Jan 15 </payment> <payment id=”P2” due Jan 20 </payment> <payment id=”P3” due Feb 15 </payment> </payments>
</porders> <porder id=”P02” acct=”A1”> // second purchase order … </porder></customer>
Beispiel
Customer ( id integer, name varchar(20) )
Account ( id varchar(20), custId integer, acctnum integer )
PurchOrder ( id integer, custId integer, acctId varchar(20), date varchar(10) )
Item ( id integer, poId integer, desc varchar(10) )
Payment ( id integer, poId integer, desc varchar(10) )
![Page 7: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/7.jpg)
3. Einstieg
Verwendung der bestehenden SQLanguage
Verschachtelung durch SQL-Struktur
Konstruktion von Tags durch SQL-Funktionen
![Page 8: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/8.jpg)
Verschachtelte Struktur
XMLAGG konkateniert XML Elemente
Verwendung von XML Konstruktoren
![Page 9: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/9.jpg)
XML-Konstruktor
Parameter werden in festgelegte Tags eingebunden
![Page 10: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/10.jpg)
4. Alternativen der KonvertierungKlassifizierung der Alternativen
Ort der Berechnung ( inside / outside )
Geschachtelte Struktur erstellen ( structuring )
Tags müssen erstellt werden ( tagging )
![Page 11: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/11.jpg)
Early Tagging, Early Structuring
Stored Procedure (outside engine)
Feste Ordnung beim join ( schlecht )
Zu viele SQL-queries nötig ( overhead )
Iterative Schachtelung aller in Relation stehenden Elemente
Startpunkt: root-Element
![Page 12: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/12.jpg)
Verwendung vieler queries umgehen, indem nur noch eine große query erstellt wird ( siehe Bsp. )
Correlated CLOB ( inside )
Feste Zuordnung ( correlated ) erfordert Schleifen
zur Schachtelung
XML Fragmente werden als CLOBs
( Character Large Objects ) gespeichert ( teuer )
![Page 13: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/13.jpg)
Grafik: correlated CLOB
![Page 14: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/14.jpg)
keine feste Zuordnung
De-Correlated CLOB ( inside)
auch Speicherung in CLOBs
Verwendung von outer joins
![Page 15: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/15.jpg)
Outer Join 2 od. Mehrere Tabellen werden durch einen Join
zusammengefaßt
Elemente die nicht der join-condition nicht entsprechen
werden:
Inner Join
left / right Outer Join
full Outer Join ( Outer Join )
![Page 16: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/16.jpg)
Grafik: de-correlated CLOB
![Page 17: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/17.jpg)
Late Tagging, Late Structuring
Erstellen der relationalen Daten ( content creation )
Strukturieren und Tags schreiben
( structuring / tagging )
Unterteilung in 2 wesentliche Prozesse
![Page 18: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/18.jpg)
Zusammenfügen aller tables ( join all )
Content Creation: Redundant RelationRedundant Relation
Multiplikative Vergößerung ( schlecht )
Man erhält redundante Daten
Verwendung redundanter Prozesse
![Page 19: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/19.jpg)
Ast wird separat geführt, keine Daten vom Nachbarn
Content creation: Outer Union ( unsorted )
Nicht immer einheitliche Größe
Immer noch Redundanz ( parent Daten )
Zusammenführung aller Daten am Ende
![Page 20: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/20.jpg)
Path - outer - union Es wird am Pfad entlang entwickelt Wiederholung von parent - Daten ( s.o. )
PATH - NODE
Node - outer - union Parent Daten direkt ins outer union schreiben große Anzahl an Tupeln
![Page 21: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/21.jpg)
Grafik: Path Outer Union
![Page 22: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/22.jpg)
Grafik: Node Outer Union
![Page 23: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/23.jpg)
hash-basierter Tagger
Gruppierung der Elemente mittels Hash-Tabellen
Effizient bei genügend Speicher
Tupel lösen und Tags setzten
Structuring/Tagging
![Page 24: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/24.jpg)
Grafik: Hash - Tables
Customer ( ID,Typ)PurchaseOrder ( custID,Typ)
Account ( custID,Typ)Item ( PoID,Typ)
Payment ( PoID,Typ)
HashTable (Customer)HashTable (PurchaseOrd)HashTable (root)
??? ( AcctID,Typ)
HashTable (Account)
??? ( AcctID,Typ)
??? ( AcctID,Typ)
hashing
tagging
Tupel lösen und Tags nach Typ setzten
![Page 25: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/25.jpg)
Late Tagging, Early Structuring
Late Tagging, Late Structuring benötigt viel Speicher um effizient zu sein
Sortierung bereits im content creation
![Page 26: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/26.jpg)
Folgende Dinge müssen beachtet werden
Structured content: Sorted Outer Union
Parent Informationen kommen vor den child Infos Alle Informationen eines Knotens gehören
zusammen
Sortierung des path-outer-union Ergebnis
( sortiert nach Ids )
![Page 27: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/27.jpg)
Sorted Outer Union
Outer Union
Order by: custId, poDate, poId, acctId, payId, itemId
( type, custId, custName, acctId, acctNum, poId, poAcct, poDate, itemId, itemInfo, payId, payInfo )
( type, custId, custName, acctId, acctNum, poId, poAcct, poDate, itemId, itemInfo, payId, payInfo )
![Page 28: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/28.jpg)
Tags werden sofort nach auslesen gesetzt
Tagging Sorted Data: Constant Space Tagger
Platz - konstant in Anzahl der Levels
Nur Parent Id merken um Tag zu schließen
![Page 29: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/29.jpg)
5. Beurteilung der Effizienz
Verwendetes System
DB2
Pentium 366 / 256 MB / Win NT 4.0
alle Funktionen innerhalb der Maschine
![Page 30: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/30.jpg)
Verwendung ausgeglichener Strukturen
Messvorbereitung
Einführung von Parametern
![Page 31: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/31.jpg)
Inside Engine (query fan out)
Outside Engine
Ergebnisse ( inside - outside )
Weitere Test inside the engine !
![Page 32: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/32.jpg)
Was kostet Wieviel ?
Execution
Bind out
Tagging
XML File
![Page 33: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/33.jpg)
Änderung am query fan out
mehr joins
corr CLOB am schlechtesten ( loop joins )
unsorted besser als sorted o-u-plan
![Page 34: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/34.jpg)
Änderung an der query depth
Fehler des rel. Optimierers
Sortierung nach XMLAGG ( CLOB )
![Page 35: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/35.jpg)
Änderung an der number of roots
kaum Auswirkungen
correlated CLOB
![Page 36: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/36.jpg)
Änderung an der number of leaf tuples
(+) Speicher: kaum Auswirkung
(-) Speicher: unsort.o-u => kein Ergebnis
![Page 37: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/37.jpg)
Vergleich path & nodeouter union
(+) Speicher: path outer union
weniger Tupel müssen gebildet werden
(-) Speicher: node outer union
mehr redundante Daten
overhead beim Auslagern
![Page 38: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/38.jpg)
Zusammenfassung der Ergebnisse
Inside the engine ist effizienter Bei genügend Speicher liegen die
Unsorted Outer Union Ansätze vorn Zu wenig Speicher: Sorted Outer Union
![Page 39: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/39.jpg)
Überblick: AlternativenLate TaggingEarly Tagging
LateStructuring
EarlyStructuring
Inside Engine
Inside Engine
De-Correlated CLOB
Out
side
Eng
ine
Stored Procedure
Inside Engine
Out
side
Eng
ine
Sorted Outer Union(Tagging inside)
Sorted Outer Union(Tagging outside)
Unsorted Outer Union(Tagging inside)
Unsorted Outer Union(Tagging outside)
Out
side
Eng
ine
Correlated CLOB
![Page 40: Efficiently Publishing Relational Data as XML Documents](https://reader036.fdocuments.us/reader036/viewer/2022081603/56814376550346895daff761/html5/thumbnails/40.jpg)
6. Kommentar und Zukunft
Parallelmaschinen Laufzeitoperatoren innerhalb der engine Speicherverwaltung Tagger verbessern ( tiefe Strukturen )