Efficiently Publishing Relational Data as XML Documents

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

2. 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

3. 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

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

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

6. Beispiel <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> Customer ( id integer, name varchar(20) ) PurchOrder ( id integer, custId integer, acctId varchar(20), date varchar(10) ) Account ( id varchar(20), custId integer, acctnum integer ) Item ( id integer, poId integer, desc varchar(10) ) Payment ( id integer, poId integer, desc varchar(10) )

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

8. Verschachtelte Struktur XMLAGG konkateniert XML Elemente Verwendung von XML Konstruktoren

9. XML-Konstruktor Parameter werden in festgelegte Tags eingebunden

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

11. Early Tagging, Early Structuring Stored Procedure (outside engine) • Startpunkt: root-Element • Iterative Schachtelung aller in Relation stehenden Elemente • Zu viele SQL-queries nötig ( overhead ) • Feste Ordnung beim join ( schlecht )

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

13. Grafik: correlated CLOB

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

15. 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 )

16. Grafik: de-correlated CLOB

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

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

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

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

21. Grafik: Path Outer Union

22. Grafik: Node Outer Union

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

24. Grafik: Hash - Tables HashTable (Account) ??? ( AcctID,Typ) ??? ( AcctID,Typ) ??? ( AcctID,Typ) HashTable (Customer) HashTable (root) HashTable (PurchaseOrd) Account ( custID,Typ) Customer ( ID,Typ) Item ( PoID,Typ) PurchaseOrder ( custID,Typ) Payment ( PoID,Typ) Tupel lösen und Tags nach Typ setzten tagging hashing

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

26. Structured content: Sorted Outer Union • Folgende Dinge müssen beachtet werden • Parent Informationen kommen vor den child Infos • Alle Informationen eines Knotens gehören zusammen • Sortierung des path-outer-union Ergebnis ( sortiert nach Ids )

27. Sorted Outer Union ( type, custId, custName, acctId, acctNum, poId, poAcct, poDate, itemId, itemInfo, payId, payInfo ) ( type, custId, custName, acctId, acctNum, poId, poAcct, poDate, itemId, itemInfo, payId, payInfo ) Order by: custId, poDate, poId, acctId, payId, itemId Outer Union

28. Tagging Sorted Data: Constant Space Tagger • Tags werden sofort nach auslesen gesetzt • Nur Parent Id merken um Tag zu schließen Platz - konstant in Anzahl der Levels

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

30. Messvorbereitung Verwendung ausgeglichener Strukturen Einführung von Parametern

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

32. Was kostet Wieviel ? Execution Bind out Tagging XML File

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

34. Änderung an derquery depth Fehler des rel. Optimierers Sortierung nach XMLAGG ( CLOB )

35. Änderung an der number of roots kaum Auswirkungen correlated CLOB

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

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

38. 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

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

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