Efficiently Publishing Relational Data as XML Documents Hauptseminar: Datenbanksysteme und XML Dennis Säring

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

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

Was wird dazu benötigt ? Sprache I.Sprache für die Spezifizierung der Konvertierung von rel. Daten in XML Implementation II.Eine effiziente Implementation dieser Konvertierung

2. Wiederholung XML Semistrukturiert Tags kennzeichnen Elemente Elemente sind geschachtelt angeordnet

John Doe // first purchase order 1 Jan 2000 shoes bungee ropes // second purchase order … Beispiel Customer ( idinteger, namevarchar(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) )

3. Einstieg Verwendung der bestehenden SQLanguage Verschachtelung durch SQL-Struktur Konstruktion von Tags durch SQL-Funktionen

Verschachtelte Struktur XMLAGG konkateniert XML Elemente Verwendung von XML Konstruktoren

XML- Konstruktor Parameter werden in festgelegte Tags eingebunden

4. Alternativen der Konvertierung Klassifizierung der Alternativen Ort der Berechnung ( inside / outside ) Geschachtelte Struktur erstellen ( structuring ) Tags müssen erstellt werden ( tagging )

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

Verwendung vieler queries umgehen, indem nur noch eine große query erstellt wird ( siehe Bsp. )siehe Bsp. Correlated CLOB ( inside ) Feste Zuordnung ( correlated ) erfordert Schleifen zur Schachtelung XML Fragmente werden als CLOBs ( Character Large Objects ) gespeichert ( teuer )

Grafik: correlated CLOB

keine feste Zuordnung De-Correlated CLOB ( inside) auch Speicherung in CLOBs Verwendung von outer joins

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 )

Grafik: de-correlated CLOB

Late Tagging, Late Structuring Erstellen der relationalen Daten ( content creation ) Strukturieren und Tags schreiben ( structuring / tagging ) Unterteilung in 2 wesentliche Prozesse

Zusammenfügen aller tables ( join all ) Redundant Relation Content Creation: Redundant Relation Multiplikative Vergößerung ( schlecht ) Man erhält redundante Daten Verwendung redundanter Prozesse

Ast wird separat geführt, keine Daten vom Nachbarn Content creation: Outer Union ( unsorted ) Outer Union Nicht immer einheitliche Größe Immer noch Redundanz ( parent Daten ) Zusammenführung aller Daten am Ende

Path - outer - union Path Es wird am Pfad entlang entwickelt Wiederholung von parent - Daten ( s.o. ) PATH - NODE Node - outer - unionNode Parent Daten direkt ins outer union schreiben große Anzahl an Tupeln

Grafik: Path Outer Union

Grafik: Node Outer Union

hash-basierter Tagger Gruppierung der Elemente mittels Hash-Tabellen Effizient bei genügend Speicher Tupel lösen und Tags setzten Structuring/Tagging

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) hashing tagging Tupel lösen und Tags nach Typ setzten

Late Tagging, Early Structuring Late Tagging, Late Structuring benötigt viel Speicher um effizient zu sein Sortierung bereits im content creation

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 )

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 )

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

5. Beurteilung der Effizienz Verwendetes System DB2 Pentium 366 / 256 MB / Win NT 4.0 alle Funktionen innerhalb der Maschine

Verwendung ausgeglichener Strukturen Messvorbereitung Einführung von Parametern

Inside Engine (query fan out) Outside Engine Ergebnisse ( inside - outside ) Weitere Test inside the engine !

Was kostet Wieviel ? Execution Bind out Tagging XML File

Änderung am query fan out mehr joins corr CLOB am schlechtesten ( loop joins ) unsorted besser als sorted o-u-plan

Änderung an der query depth Fehler des rel. Optimierers Sortierung nach XMLAGG ( CLOB )

Änderung an der number of roots kaum Auswirkungen correlated CLOB

Änderung an der number of leaf tuples (+) Speicher: kaum Auswirkung (-) Speicher: unsort.o-u => kein Ergebnis

Vergleich path & node outer union (+) Speicher: path outer union weniger Tupel müssen gebildet werden (-) Speicher: node outer union mehr redundante Daten overhead beim Auslagern

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

Überblick: Alternativen Late TaggingEarly Tagging Late Structuring Early Structuring Inside Engine De-Correlated CLOB Outside Engine Stored Procedure Inside Engine Outside Engine Sorted Outer Union (Tagging inside) Sorted Outer Union (Tagging outside) Unsorted Outer Union (Tagging inside) Unsorted Outer Union (Tagging outside) Outside Engine Correlated CLOB

6. Kommentar und Zukunft Parallelmaschinen Laufzeitoperatoren innerhalb der engine Speicherverwaltung Tagger verbessern ( tiefe Strukturen )