Samstag, 11. Februar 2012
Jetzt neu: Onlinezugriff auf das digitalisierte Archiv des Entwickler Magazins

Artikel

Februar 2006 | Artikel

Face to Face

(Link zum Artikel: http://www.entwickler-magazin.de/jaxenter//000795)

XML-APIs in relationalen Datenbanken

Text: von Carsten Czarski
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
Die zunehmende Verbreitung von XML als Datenaustauschformat macht sowohl das Erstellen von XML aus Datenbanktabellen als auch die Übernahme von XML in dieselben zu einer Standard-Anforderung der täglichen Praxis. Dieser Artikel stellt anhand eines praktischen Beispiels vor, wie eine XML-Schnittstelle auf relationale Tabellen direkt in der Datenbank hinterlegt wird. Zur Umsetzung kommen Standards wie SQL/XML und Datenbank-Technologien wie Views und Trigger zum Einsatz. Zwar beziehen sich die vorgestellten SQL-Skripte auf die Oracle-Datenbank, sie können jedoch in jedem RDBMS, das den SQL/XML-Standard, Views und INSTEAD-OF Trigger unterstützt, nachvollzogen werden. Natürlich lässt sich das Konzept auch abwandeln: Anstelle von Views können auch Stored Procedures verwendet werden.

Als Ausgangssituation dient ein einfaches Datenmodell für Wertpapierdepots (Abpictureung 1). Es enthält drei Tabellen: Ein Kunde kann null bis viele Wertpapierdepots besitzen und in jedem Depot können null bis viele Wertpapierpositionen enthalten sein. Das XML-Format ist in Abpictureung 2 dargestellt. Die XML-Schnittstelle muss dieses Format demnach sowohl erzeugen als auch verarbeiten können.

XML erzeugen: Von einfachen Strukturen ...
Im ersten Schritt wird das Generieren der XML-Dokumente betrachtet. Dazu kommen die Funktionen des SQL/XML-Standards [1] zum Einsatz. Sie dienen zum Erzeugen von XML mit SQL und sind Bestandteil des ANSI-SQL-Standards (SQL:2003).
  • XMLElement(): erzeugt ein XML-Tag
  • XMLAttributes(): erzeugt ein oder mehrere XML-Attribute
  • XMLComment(): erzeugt einen XML-Kommentar
  • XMLRoot(): generiert den XML-Prolog
  • XMLAgg(): dient zum Erzeugen von Hierarchien
Die SQL/XML-Funktionen werden wie gewöhnliche SQL-Funktionen eingesetzt und können natürlich auch mit solchen kombiniert werden. Sie verwenden intern keine DOM-Objekte und arbeiten auch mit großen Datenmengen extrem performant.
  1. select XMLElement("Gruss", 'Hallo Welt') TEXT
  2. from dual
  3. TEXT
  4. -------------------------
  5. <Gruss>Hallo Welt</Gruss>
Listing 1: Einfache XML-Sicht auf die Wertpapier-Tabelle
  1. create view WERTPAPIER_XML_VIEW as
  2. select
  3. XMLRoot(
  4. XMLElement("wertpapier",
  5. XMLAttributes(
  6. wp.ISIN as "isin",
  7. dp.KONTONR as "depotnummer"
  8. ),
  9. XMLElement("bezeichnung", wp.BEZEICHNUNG),
  10. XMLElement("stueck_nominale", wp.STUECK_NOM)
  11. )
  12. ) as XML
  13. from WERTPAPIER_TAB wp join DEPOT_TAB dp
Listing 1 zeigt den konkreten Einsatz der SQL/XML-Funktionen. Es erzeugt aus der Tabelle WERTPAPIER_TAB für jede Zeile ein (einfaches) XML-Dokument. Als Datentyp liefert die so erzeugte View einen XMLTYPE zurück. Es ist für den Nutzer der View nicht erkennbar, ob die XML-Dokumente tatsächlich als XMLTYPE
in der Datenbank gespeichert sind oder ob sie aus relationalen Daten generiert wurden.
  1. SQL> select XML from WERTPAPIER_XML_VIEW
  2. XML
  3. --------------------------------------------------------
  4. <wertpapier isin="US00010281" depotnummer="500917211">
  5. <bezeichnung>Oracle Corp</bezeichnung>
  6. <stueck_nominale>1000</stueck_nominale>
  7. </wertpapier>
  8. <wertpapier isin="DE01020911" depotnummer="500917211">
  9. <bezeichnung>Bundesanleihe 10/2010</bezeichnung>
  10. :
... hin zu komplexen Strukturen
In der Praxis sind meist komplexere, hierarchische XML-Strukturen gefordert. Auch diese lassen sich mit den SQL/XML-Funktionen erzeugen. XMLAgg() fügt eine neue Hierarchieebene ein. Das Beispiel in Listing 2 erzeugt zwei Hierarchieebenen, wobei jedes XMLAgg() in eine Unterabfrage (Sub-Select) eingebettet ist.

Listing 2: Erstellung komplexer XML-Dokumente mit den SQL/XML-Funktionen
  1. create view KUNDE_XML_VIEW as
  2. select
  3. XMLElement("kunde",
  4. XMLAttributes(kd.KUNDE_ID as "kundennummer"),
  5. XMLElement("name", kd.NAME),
  6. XMLElement("vorname", kd.VORNAME),
  7. XMLElement("ort", kd.ORT),
  8. (
  9. select
  10. XMLAgg(
  11. XMLElement("depot",
  12. XMLAttributes(dp.KONTONR as "kontonummer"),
  13. (
  14. select
  15. XMLAgg(
  16. XMLElement("wertpapier",
  17. XMLAttributes(wp.ISIN as "isin"),
  18. XMLElement("bezeichnung", wp.BEZEICHNUNG),
  19. XMLElement("stueck_nominale", wp.STEUCK_NOM)
  20. ))
  21. from WERTPAPIER_TAB wp where depot_id = dp.depot_id
  22. )))
  23. from DEPOT_TAB dp where dp.kunde_id = kd.kunde_id
  24. )) as XML
  25. from KUNDE_TAB kd
Es ist einleuchtend, dass die SQL-Abfrage mit zunehmender Komplexität der zu erzeugenden XML-Dokumente immer länger und unübersichtlicher wird. In der Praxis empfiehlt es sich daher, nach dem "Bausteinprinzip" vorzugehen - also zunächst Views für kleine XML-Dokumente aus einzelnen Tabellen zu erzeugen und diese dann in anderen Views zusammenzufassen. Da virtuelle XML-Dokumente aus einer XML-View tatsächlich gespeicherten gleichgestellt sind, können Operationen wie Stylesheet-Transformationen (XMLTRANSFORM) oder Datenextraktion (EXTRACTVALUE) auch mit XML-Views durchgeführt werden. Daraus kann dennoch eine relationale Übersicht über alle Depots eines Kunden angefordert werden.
  1. select
  2. extractvalue(kd.XML, '/kunde/name') name,
  3. extractvalue(value(dp), '/depot/@kontonummer') dpnr
  4. from KUNDE_XML_VIEW kd,
  5. table(xmlsequence(extract(kd.XML, '/kunde/depot'))) dp
  6. NAME DPNR
  7. --------------------- --------------------
  8. Mustermann 500917211
  9. Meier 500189212
  10. : :
Der Vorteil liegt auf der Hand. Da die Datenbank die View-Definition kennt, kann der Optimizer ein Query Rewrite durchführen. Die Datenbank führt also tatsächlich eine (wesentlich performantere) relationale Abfrage aus. Obwohl die relationalen Tabellen dem Nutzer verborgen bleiben, profitiert er dennoch davon.
XML abrufen? Ganz einfach mit HTTP!
Mit dem Erstellen der Views ist der erste Teil der XML-Schnittstelle abgeschlossen. Die relationalen Tabellendaten können nun als XML-Dokumente aus der Datenbank abgerufen werden. Dies ist in der Oracle-Datenbank übrigens nicht nur per SQL, sondern auch per HTTP-Protokoll möglich. Eine standardmäßig installierte Oracle-Datenbank "lauscht" auf Port 8080 auf HTTP-Anfragen. Mit einem speziell formulierten URL kann die XML-View aus Listing 2 direkt angesprochen werden (Abpictureung 3): http://[host]:8080/oradb/[DB-USER]/[VIEW-NAME]
XML entgegennehmen
Die vollständige XML-Schnittstelle muss XML auch entgegennehmen können. Wird ein XML-Dokument gespeichert, so soll die Datenbank dessen Inhalt auf die relationalen Tabellen verteilen.
DML auf Views - möglich oder nicht möglich?
XML-Views können wie gewöhnliche relationale Views updatefähig oder nichtupdatefähig sein. In der Theorie ist jede View updatefähig, sofern keine Aggregatsfunktionen wie SUM(), AVG() oder andere verwendet werden. Denn in diesem Fall werden die Daten von der View verdichtet, Änderungen können nicht mehr auf die Originaldaten zurückgeführt werden. Jede View, die keine Aggregatsfunktionen verwendet, ist demnach updatefähig - soweit die Theorie. In der Praxis können jedoch alle am Markt befindlichen Datenbanken DML auf Views mit mehr oder weniger komplexen Definitionen (SQL Joins) nicht mehr umsetzen.
 
 
Versucht man, ein XML-Dokument per SQL INSERT in die View einzufügen, so erhält man eine Fehlermeldung. Der Grund dafür ist die fehlende Update-Fähigkeit der View (siehe Kasten „DML auf Views“).
  1. SQL> insert into KUNDE_XML_VIEW values ('<kunde>...');
  2. insert into KUNDE_XML_VIEW values ('<kunde>...')
  3. *
  4. ERROR at line 1:
  5. ORA-01733: virtual column not allowed here
Speziell zu diesem Zweck wurden in der Oracle-Datenbank die INSTEAD-OF-Trigger [3] eingeführt. Sie sind seit der Version 8 verfügbar, werden auf Views angelegt und anstelle eines INSERT, UPDATE oder DELETE ausgeführt. So lässt sich jede View updatefähig machen - der Entwickler entscheidet selbst, was bei einer DML-Operation geschehen soll.

Listing 3: Deklaration und „Gerüst“ eines INSTEAD-OF-Triggers
  1. create or replace trigger tr_kunde_xml_view
  2. instead of insert or update or delete
  3. on kunde_xml_view for each row
  4. declare
  5. begin
  6. if inserting then
  7. ...
  8. end if;
  9. if updating then
  10. ...
  11. end if;
  12. if deleting then
  13. ...
  14. end if;
  15. end;

Der Aufbau eines INSTEAD-OF-Triggers ist in Listing 3 dargestellt. Im Gegensatz zu einem normalen Datenbanktrigger enthält er in Zeile 2 die Schlüsselworte INSTEAD OF. Im Trigger-Body können nun unterschiedliche Aktionen für die verschiedenen DML-Ereignisse implementiert werden. Das neu eingefügte oder geänderte XML-Dokument wird durch das Präfix :new referenziert, das "alte" durch :old.
DML-Operation „Altes“ Dokument „Neues“ Dokument
INSERT Nicht verfügbar :new
UPDATE :old :new
DELETE :old Nicht verfügbar
 
 
Die folgenden Beispiele gehen auf die Aktionen des INSTEAD-OF-Triggers für ein INSERT ein - UPDATE und DELETE können dann analog implementiert werden.
Zunächst wird die "Root"-Ebene des XML-Dokuments in die relationale Tabelle KUNDE_TAB übernommen (Listing 4). Informationen zum Kunden kommen im XML-Dokument nur einmal vor. Die Übernahme erfolgt durch ein einfaches SQL INSERT-Kommando, wobei die Werte mit der EXTRACTVALUE-Funktion aus dem neu eingefügten XML-Dokument (:new) extrahiert werden. Welcher XML-Knoten von EXTRACTVALUE angesprochen wird, richtet sich nach dem übergebenen XPath-Ausdruck. Da die Kundennummer für die weitere Verarbeitung der Depot- und Wertpapierinformationen noch gebraucht wird, wird sie in eine Variable (v_kundeid) übernommen.

Listing 4: INSTEAD-OF-Trigger - Bearbeitung der Root-Ebene
  1. :
  2. if inserting then
  3. insert into kunde_TAB (
  4. kunde_id, name, vorname, ort)
  5. values (
  6. extractvalue(:new.XML, '/kunde/@kundennummer'),
  7. extractvalue(:new.XML, '/kunde/name'),
  8. extractvalue(:new.XML, '/kunde/vorname'),
  9. extractvalue(:new.XML, '/kunde/ort')
  10. ) returning kunde_id into v_kundeid;
  11. :
  12. end if;
  13. :
Die Informationen zu Depot und Wertpapieren können im XML-Dokument mehrfach vorkommen - daher müssen sie anders behandelt werden.

Listing 5: INSTEAD-OF-Trigger - Übernahme der mehrfach vorkommenden Elemente
  1. :
  2. for dp_lst in (
  3. select
  4. extractvalue(value(dp), '/depot/@kontonummer') as ktonr
  5. from table(xmlsequence(extract(:new.XML, '/kunde/depot'))) dp
  6. ) loop
  7. insert into DEPOT_TAB (kunde_id, KONTONR)
  8. values (dp_list.ktonr, v_kundeid);
  9. -- Hier eine geschachtelte Schleife für die Verarbeitung
  10. -- der Wertpapier-Informationen<br></br>
  11. end loop;
  12. :
Die Funktion TABLE(XMLSEQUENCE(EXTRACT(...))) extrahiert das XML-Fragment mit den Depot-Informationen und erzeugt daraus eine Sequenz über die einzelnen Depots (Listing 5). Die Schleife (loop) läuft über diese Sequenz. Die Schleifen können geschachtelt werden.
Nach Erstellung des Triggers ist die XML-Schnittstelle vollständig. Ein SQL INSERT in die View ist nun erfolgreich. Die Inhalte finden sich anschließend in den relationalen Tabellen wieder.
  1. SQL> insert into kunde_xml_view values ('<kunde>...');
  2. 1 row created.

Beim Implementieren der Schnittstelle sollte man auch mögliche Konfliktfälle von vorneherein berücksichtigen. Ein neu einzufügender Kunde könnte bereits existieren. Die Frage ist, woran man dies erkennen kann und was passieren soll: Sollen die alten Informationen überschrieben, beibehalten oder soll eine Fehlermeldung ausgelöst werden? Solche Fragen können jedoch nicht pauschal, sondern nur im Einzelfall entschieden werden.
Fazit
Mit der vorgestellten Technik kann man eine XML-Schnittstelle direkt in der Datenbank hinterlegen. Im Vergleich zu vielfach verfügbaren, fertigen Frameworks ist diese Variante auf den ersten Blick aufwendiger. Bei genauerer Betrachtung bieten sich jedoch einige Vorteile:
Information hiding: Das XML-Dokument kann direkt aus der Datenbank abgerufen werden. Der Nutzer greift auf eine View zu - die Herkunft der Daten bleibt verborgen.
Offenheit: Die so erzeugte XML-Schnittstelle ist für viele Programmierumgebungen (Java, .NET, PHP, Perl, C/C++ ...) nutzbar. Die einzige Voraussetzung ist die Fähigkeit zur Kommunikation mit der Datenbank.
Performance: Besonders das Erzeugen von XML ist hier sehr performant gelöst. Denn die Datenbank stellt das XML-Dokument zusammen und liefert es „auf einmal“ aus. Dies ist wesentlich effizienter als das Ausliefern zahlreicher Einzelsätze.
Links und Literatur

Kommentare