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

Präsentation zum Thema: "Efficiently Publishing Relational Data as XML Documents Hauptseminar: Datenbanksysteme und XML Dennis Säring."—  Präsentation transkript:

1 Efficiently Publishing Relational Data as XML Documents Hauptseminar: Datenbanksysteme und XML 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 ? Sprache I.Sprache für die Spezifizierung der Konvertierung von rel. Daten in XML Implementation II.Eine effiziente Implementation dieser Konvertierung

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

6 John Doe 1894654 3849342 // 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) )

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 Ort der Berechnung ( inside / outside ) Geschachtelte Struktur erstellen ( structuring ) Tags müssen erstellt werden ( tagging )

11 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

12 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 )

13 Grafik: correlated CLOB

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

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 Erstellen der relationalen Daten ( content creation ) Strukturieren und Tags schreiben ( structuring / tagging ) Unterteilung in 2 wesentliche Prozesse

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

19 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

20 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

21 Grafik: Path Outer Union

22 Grafik: Node Outer Union

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

24 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

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

26 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 )

27 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 )

28 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

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

30 Verwendung ausgeglichener Strukturen Messvorbereitung Einführung von Parametern

31 Inside Engine (query fan out) Outside Engine Ergebnisse ( inside - outside ) 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 der query 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 & node outer 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 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

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