Möglichkeiten und Konzepte zur XML
Werbung
Datenbank Spektrum (2013) 13:225–230 DOI 10.1007/s13222-013-0132-z FA C H B E I T R A G Möglichkeiten und Konzepte zur XML-Schemavalidierung am Beispiel von DB2 for z/OS V9.1 Christoph Koch Eingegangen: 16. November 2012 / Angenommen: 8. Mai 2013 / Online publiziert: 13. Juni 2013 © Springer-Verlag Berlin Heidelberg 2013 Zusammenfassung Das von IBM entwickelte relationale Datenbankmanagementsystem (DBMS) DB2 for z/OS V9.1 ermöglicht durch die Implementierung der pureXMLTechnologie (IBM Corporation 2012) die native Speicherung und Verarbeitung von „Extensible Markup Language (XML)“-Daten. Hierzu zählen auch Mechanismen zum Umgang mit XML-Schemas – dem de facto Standardinstrument zur Datenmodellierung und Integritätssicherung im XML-Kontext. Der vorliegende Beitrag reflektiert in Anlehnung an (Koch 2012) die DB2-Funktionalitäten zur XML-Schemavalidierung anhand eines zuvor erarbeiteten Anforderungsprofils. Darauf aufbauend werden Konzepte zur XML-Schemavalidierung – die nachträgliche und die automatische Schemavalidierung – vorgestellt, durch deren Implementierung sich die DB2-Funktionalitäten gemäß der Anforderungen gezielt ergänzen lassen. Abschließend werden die Ausführungen dieses Beitrags in Bezug zur Fragestellung, inwieweit der Einsatz von datenbankseitiger XMLSchemavalidierung bereits mit DB2 for z/OS V9.1 sinnvoll ist, zusammengefasst. Schlüsselwörter XML-Schema · DB2 for z/OS · Anforderungen · Konzepte C. Koch () Lehrstuhl für Datenbanken und Informationssysteme, Friedrich-Schiller-Universität Jena, Ernst-Abbe-Platz 2, 07743 Jena, Deutschland e-mail: [email protected] C. Koch Datenbanken, DATEV eG, Paumgartnerstr. 6-14, 90429 Nürnberg, Deutschland e-mail: [email protected] 1 Einleitung Bereits 1998 wurde die XML-Spezifikation durch das World Wide Web Consortium (W3C) verabschiedet. Während diese Auszeichnungssprache primär zum standardisierten Datenaustausch konzipiert war, nahm sie recht schnell auch Einzug in den Datenbanksektor. Folglich entwickelten sich dedizierte XML-DBMS wie beispielsweise Tamino (Software AG) sowie Erweiterungen für bestehende relationale DBMS um XML-Funktionalitäten. Als ein Vertreter der relationalen DBMS erfuhr auch DB2 über verschiedene Phasen hinweg die fortlaufende Erweiterung um XML-Spezifika. Erste XML-Funktionalitäten wurden mit dem XML-Extender [4] in DB2 for z/OS für Version 7 integriert. Später gelang es IBM, diese in erheblichem Maß durch die Einführung der pureXML-Technologie in der hier betrachteten Version 9.1 von DB2 for z/OS auszubauen. Insofern sind auch die im Beitrag thematisierten Mechanismen erst Bestandteil des pureXML-Funktionspakets. Die Ausführungen zum Thema XML-Schemavalidierung gliedern sich wie folgt. Nachdem in Abschn. 2 ein Überblick zum Hintergrund der Untersuchungen in der DATEV gegeben wird, folgt in Abschn. 3 eine Vorstellung der XMLSchema-Spezifikation. Diese Darstellungen bilden die Basis für die in Abschn. 4 spezifizierten Anforderungen an die datenbankseitige XML-Schemavalidierung. Daran knüpft in Abschn. 5 ein Überblick zu den bereits in DB2 for z/OS V9.1 implementierten Funktionalitäten zur XMLSchemavalidierung an. Anschließend wird ebenfalls in Abschn. 5 die Erarbeitung eines gezielten Erweiterungskonzepts behandelt. Dieses Konzept bildet zusammen mit den zuvor geschilderten Anforderungen den Kern dieses Beitrags, der abschließend durch Abschn. 6 zusammengefasst wird. 226 2 Hintergrund der Untersuchung Die Abteilung Datenbanken in der DATEV untersucht stets aktuelle Trends und evaluiert deren Einsatzfähigkeit für die zentrale Datenbanklandschaft der DATEV. Einer der dabei zuletzt betrachteten Themenbereiche ist die pureXMLFunktionalität von DB2 for z/OS Version 9.1, zu der seit 2010 diverse Untersuchungen [1, 15] durchgeführt wurden. DATEV-seitig sind sowohl XML als auch XML-Schema vertraute und angewandte Spezifikationen. Unternehmensweit existiert eine Vielzahl von XML-Dokumenten, XMLSchemas und dazugehörigen etablierten Standards zum Umgang mit diesen Strukturen. Spezielle Anwendungen wie beispielsweise das DATEV Belegwesen online, das per OCR-Software Rechnungsbelege zu XML-Dokumenten digitalisiert und DB2-seitig nicht-nativ in Form von „Large Object (LOB)“-Dokumenten (plus Metadaten) speichert, verwaltet XML-Datenbestände von über 1.000.000 Dokumenten. Daraus ergibt sich die generelle Anforderung, auch bestehende Anwendungen in konzeptionelle Untersuchungen einzubeziehen und herauszuarbeiten, welche möglichen Vorteile insbesondere für diese Anwendungskontexte durch eine DB2-seitige XML-Schemavalidierung zu erwarten sind. Obwohl zum aktuellen Zeitpunkt bereits die Nachfolgeversion 10 von DB2 for z/OS verfügbar ist, stellt ein zentrales Ziel des Beitrags die Klärung der Fragestellung dar, inwieweit der Einsatz von datenbankseitiger XMLSchemavalidierung mit dem aktuell in der DATEV eingesetzten DB2 for z/OS V9.1 oder womöglich erst mit der Folgeversion sinnvoll ist. Ein „einfaches“ Migrieren von DB2 ist nicht möglich, da eine solche Umstellung hohen Aufwand verursacht und eine langfristige Vorbereitung benötigt. Ursachen dafür sind beispielsweise komplexe Abhängigkeitsprüfungen, die Abarbeitung umfangreicher Check-Listen, das Abstimmen von Lizenzvereinbarungen und nicht zuletzt die aufwändige Durchführung der DB2-Migration selbst. Für eine vollständige Migration der DB2-Systemlandschaft ist daher je nach Komplexität und Größe ein Jahr Migrationsdauer durchaus realistisch. 3 XML-Schema Die ersten Ansätze zur Entwicklung einer Schemasprache für XML-Dokumente mündeten in der vom W3C verabschiedeten Document Type Definition (DTD). Dieses Konzept zeigte aber speziell bei der datenbankorientierten Anwendung von XML viele Schwächen, sodass sich kurze Zeit später die Verabschiedung des XML-Schema-Konzepts [5–7] durch das W3C anschloss. Es folgten weitere alternative Schemasprachen wie beispielsweise Relax NG oder Schematron, die jedoch bisher wenig Verbreitung gefunden Datenbank Spektrum (2013) 13:225–230 haben. Eine vergleichende Darstellung der Sprachen findet sich in [14]. XML-Schema ist aktuell das am weitesten verbreiteste Konzept zur Schemamodellierung von XML-Dokumenten und charakterisiert sich durch Eigenschaften wie Optionalität und Variabilität (bezogen auf den Grad der Modellierung oder auch Einschränkung). Somit handelt es sich bei XML-Schemas um optionale Dokumente, mit deren Hilfe XML-Dokumente unterschiedlich „streng“ beschrieben werden können, aber nicht müssen. Der Prozess der Gültigkeitsprüfung von XML-Dokumenten bezogen auf ein konkretes XML-Schema nennt sich Schemavalidierung [3]. Erfüllt ein XML-Dokument alle Vorgaben eines zugeordneten XML-Schemas, dann ist es gültig, andernfalls ungültig. 4 Anforderungen an die XML-Schemavalidierung In diesem Abschn. soll auf konkrete Anforderungen eingegangen werden, die sich aus Perspektive der DATEV zum Teil auch angesichts der verfügbaren Funktionalitäten dedizierter XML-DBMS wie beispielsweise Tamino an die XML-Schemavalidierung in DB2 stellen. Es handelt sich folglich nicht ausschließlich um reine DATEV-spezifische, sondern vielmehr gar allgemeingültige funktionale Anforderungen im XML-Kontext. 4.1 Zuordnung von Dokumenten zu XML-Schemas Die Zuordnung von XML-Dokumenten zu XML-Schemas wird einerseits für den Prozess der Schemavalidierung benötigt, um zu wissen gegen welches XML-Schema ein XMLDokument validiert werden soll. Andererseits ist diese Verbindung auch notwendig für die nachträgliche Gültigkeitsauskunft von XML-Dokumenten (bezogen auf das dazugehörige Schema). 4.2 Umgang mit ungültigen XML-Dokumenten Eine besondere Rolle bei der datenbankseitigen XMLSchemavalidierung spielt der Umgang mit ungültigen XMLDokumenten. Zum einen ist es naheliegend, ungültige XML-Dokumente per Fehler (SQLCODE) abzuweisen. Andererseits muss aber auch bestehenden Anwendungen Rechnung getragen werden, die bereits – ähnlich wie das in Abschn. 2 vorgestellte DATEV Belegwesen online – XMLDaten verarbeiten und mitunter zum Teil noch keine vollständig etablierten XML-Schemas besitzen. Um speziell in diesen Kontexten eventuellen Datenverlusten durch das Abweisen von ungültigen XML-Dokumenten vorzubeugen, kann es notwendig sein, auch ungültige XML-Dokumente datenbankseitig – beispielsweise mit einem speziellen Ungültigkeitsvermerk versehen – abzuspeichern, damit sie zu Datenbank Spektrum (2013) 13:225–230 227 Abb. 1 Umgang mit ungültigen XML-Dokumenten einem späteren Zeitpunkt noch nachanalysiert und gegebenenfalls korrigiert werden können. Abbildung 1 visualisiert die diskutierten Varianten, die je nach Einsatzzweck beide in der Praxis anzutreffen sind. 4.3 Auskunft über Gültigkeit von XML-Dokumenten Nicht alle gespeicherten XML-Dokumente lassen sich bezogen auf ein ihnen zugeordnetes XML-Schema in gültige und ungültige XML-Dokumente unterteilen. Es existieren auch solche XML-Dokumente, die aus verschiedenen Gründen (bislang ungenutzte Funktionalität, bewusste Nicht-Validierung aus Performanceaspekten heraus, etc.) noch gar nicht gegen ein zugehöriges XML-Schema validiert worden sind beziehungsweise denen bislang noch kein XML-Schema zugeordnet wurde. Um später nachzuvollziehen, ob schon alle XML-Dokumente erfolgreich validiert worden sind, ist es daher wichtig vom DBMS Auskunft über den aktuellen Zustand – also die Gültigkeit – eines XMLDokuments erhalten zu können. 4.4 Automatische und nachträgliche Validierung Die erste Anforderung in diesem Kontext richtet sich an eine Möglichkeit zur automatischen Schemavalidierung bei Manipulation von XML-Dokumenten, sodass der Validierungsprozess funktional transparent zur externen Anwendungslogik stattfindet und somit von dieser entkoppelt ist. Davon profitieren insbesondere auch diejenigen Anwendungen, die bereits mit XML-Daten arbeiten und erst nachträglich ein Schema bereitstellen beziehungsweise erst nachträglich die Möglichkeiten der DB2-seitigen XML-Schemavalidierung nutzen. Voraussetzung für einen automatisch gestalteten Validierungsprozess ist allerdings, dass datenbankseitig die Verknüpfung von XML-Dokument und XML-Schema vermerkt ist (siehe Abschn. 4.1). Auf der anderen Seite sollte alternativ aber auch die Möglichkeit zur nachträglichen Schemavalidierung bestehen. Sie wird beispielsweise benötigt, um ungültige XMLDokumente nach ihrer Korrektur oder aber bislang noch nicht validierte Dokumente (nach-)validieren zu können. Zusätzlich dazu erfordert auch die Anpassung/Weiterentwicklung eines XML-Schemas (Schemaevolution) zum Teil das Nachvalidieren der dadurch beschriebenen Dokumente. 4.5 Unterstützung bei Schemaevolution XML-Schemas sind unter Umständen dynamische Dokumente, die sich über die Zeit hinweg mehrfach ändern [12]. Für einen konkreten Änderungsfall des XML-Schemas sollten daher Mechanismen vorhanden sein, die den Umgang mit den XML-Dokumenten regeln, die bereits zuvor gegen einen „alten“ Stand des XML-Schemas validiert worden sind. Im Idealfall wäre direkt nachgelagert an eine Schemaänderung ein automatisches Nachvalidieren der betroffenen XML-Dokumente vorzusehen. Abhängig von der zu validierenden Menge an XML-Dokumenten kann dies jedoch einen erheblichen Aufwand verursachen, sodass auch eine Möglichkeit existieren muss, die Nachvalidierung etwa von Millionen von Dokumenten zu einem späteren Zeitpunkt durchzuführen. Auf der anderen Seite erfordert fachlich nicht jede 228 Schemaänderung das Nachvalidieren der XML-Dokumente. In derartigen Fällen, wie beispielsweise der Erweiterung des Schemas um optionale Elemente, muss es auch möglich sein, gänzlich auf einen solchen Prozess verzichten zu können. Die Notwendigkeitsprüfung selbst könnte dabei DB2seitig beispielsweise durch einen intelligenten Automatismus erfolgen, der anhand eines speziellen Regelwerks die Entscheidung zum Nachvalidieren trifft. 5 XML-Schemavalidierung in DB2 for z/OS V9.1 Ein wesentlicher Bestandteil der pureXML-Implementierung in DB2 ist dessen Erweiterung um Funktionalitäten zur datenbank-seitigen XML-Schemavalidierung. Das folgende Kapitel gibt einen knappen Überblick über die dazugehörigen Mechanismen, evaluiert diese in Relation zu den entwickelten Anforderungen (siehe Abschn. 4) und stellt ein Konzept vor, diese geeignet zu erweitern. Auf Details zur Funktionsweise der DB2-Mechanismen, wie sie beispielsweise in [11] zu finden sind, soll dabei nicht eingegangen werden. Datenbank Spektrum (2013) 13:225–230 Abb. 2 UPDATE der SCHEMA_INFO (gültig) geeignete Basis, mit deren Hilfe sich durch das anschließend vorgestellte Konzept in Anlehnung an [8] die aufgestellten Anforderungen umsetzen lassen. Dieses Konzept umfasst Erweiterungen in Form einer zusätzlichen Spalte SCHEMA_INFO und zweier generischen Prozeduren (sowie Trigger). Die Bedeutung und Notwendigkeit dieser Objekte wird nachfolgend zusammen mit (zum Teil vereinfachten) Ausschnitten aus ihrer Implementierung in [1] näher beschrieben. 5.2 Konzept zur Erweiterung und Umsetzung der Anforderungen Zusätzliche Spalte SCHEMA_INFO Die zusätzliche Spalte SCHEMA_INFO zielt ab auf die Umsetzung der Anforderungen: Zuordnung von Dokumenten zu XML-Schemas und Auskunft über Gültigkeit von XML-Dokumenten. Sie ist pro XML-Spalte und jeweils mit dem Datentyp INTEGER anzulegen. Im Rahmen der Schemavalidierung ist anschließend in die Spalte SCHEMA_INFO per UPDATE (siehe Abb. 2) für den jeweiligen Datensatz (identifizierbar per DB2_GENERATED_DOCID_FOR_XML) die eindeutige XSROBJECTID des XML-Schemas einzupflegen, gegen das XML-Dokument desselben Tupels validiert worden ist. Somit ist die Zuordnung von XML-Dokumenten zu XML-Schemas gewährleistet. Da die XSROBJECTIDs stets positive Werte sind, bleibt der negative Wertebereich des INTEGER-Datentyps bei deren Vergabe ungenutzt. Er lässt sich zur Umsetzung der verbleibenden Anforderung verwenden. Auf diese Weise kann die Gültigkeit von XML-Dokumenten bezogen auf das ihnen zugeordnete XML-Schema dadurch abgebildet werden, dass in der Spalte SCHEMA_INFO für gültige XMLDokumente die XSROBJECTID als positiver Wert und für ungültige XML-Dokumente als negativer Wert abgelegt wird. Bei noch nicht gegen ein XML-Schema validierten Dokumenten bliebe der Wert einfach NULL. Abbildung 3 zeigt beispielhaft eine solche datenbankseitige Klassifikation. Alternativ dazu ließen sich die Schemainformationen auch auf zwei Spalten wie etwa SCHEMA_ID und VALIDATION_RESULT aufteilen. Aus Kompaktheitsgründen ist im Rahmen dieser Untersuchung jedoch die eingangs geschilderte Ein-Spalten-Variante (SCHEMA_INFO) verwendet worden. Bezogen auf die in Abschn. 4 diskutierten Anforderungen bietet DB2 mit seinen Standard-Mechanismen zur XMLSchemavalidierung nur wenig Unterstützung. Trotzdem bilden das XSR und die Funktion DSN_XMLVALIDATE eine Generische Prozeduren (und Trigger) Die generischen Prozeduren verfolgen das Ziel, Mechanismen zur automatischen und nachträglichen Schemavalidierung bereitzustellen und gleichzeitig auch den Umgang mit ungültigen 5.1 Standard-Mechanismen in DB2 for z/OS V9.1 Der Prozess der Schemavalidierung wird in DB2 mittels der Funktion DSN_XMLVALIDATE durchgeführt. Dieser Funktion muss als Argument das XML-Dokument und ein Verweis auf das XML-Schema, gegen das die Validierung des Dokuments stattfinden soll, übergeben werden. Das eigentliche XML-Schema ist zuvor datenbankseitig im XML Schema Repository (XSR) zu hinterlegen, welches aus verschiedenen Tabellen besteht und einen Teil des DB2Katalogs bildet. Die größte Besonderheit und damit aber auch Einschränkung der Funktion DSN_XMLVALIDATE besteht in ihrer Verwendbarkeit. So kann die Funktion nur als Argument der Funktion XMLPARSE benutzt werden, was wiederum bedeutet, dass eine DB2-seitige Schemavalidierung nur gemeinsam mit dem XML-Parsen von somit nicht-nativen XML-Dokumenten stattfinden kann. Bereits in die native XML-Speicherform überführte XML-Dokumente müssen daher im Voraus einer Schemavalidierung eigentlich unnötigerweise mit zusätzlichem Aufwand wieder zu nicht-nativen XML-Dokumenten serialisiert werden. In der Nachfolgeversion 10 von DB2 for z/OS ist diese Vorgehensweise bereits nicht mehr nötig. Datenbank Spektrum (2013) 13:225–230 229 Abb. 3 Beispielinhalt einer Tabelle mit Zusatzspalte SCHEMA_ INFO zur Gültigkeitsauskunft Abb. 5 Automatische Schemavalidierung Abb. 4 Trigger zur automatischen Schemavalidierung XML-Dokumenten zu regeln. Dabei ist pro Validierungsform (automatisch oder nachträglich) je eine Stored Procedure in DB2 [13] zu definieren, über deren Argumente die zur Validierung notwendigen Informationen (XML-Daten, XML-Schema, etc.) spezifiziert werden können. Der Unterschied zwischen beiden Prozeduren besteht im Wesentlichen in der Menge der bei einem Aufruf zu validierenden XML-Dokumente. Während bei der automatischen Schemavalidierung stets nur einzelne manipulierte Dokumente validiert werden müssen, dient die Prozedur zur nachträglichen Schemavalidierung der Validierung des kompletten Datenbestands einer XML-Spalte. Für die automatische Schemavalidierung sieht das hier betrachtete Konzept noch eine Besonderheit in Form zusätzlicher Trigger (siehe Abb. 4) vor, die aktiv auf Datenmanipulationen (INSERT oder UPDATE) an den XML-Daten reagieren und den Aufruf (CALL) der Prozedur zur automatischen Schemavalidierung übernehmen. Dies hat auch den Vorteil, dass durch Löschen des Triggers der Automatismus in einzelnen Fällen auf einfache Art und Weise wieder deaktiviert werden kann. Abbildung 5 veranschaulicht zusammenfassend den realisierten Ablauf. Wie bereits erwähnt lässt sich mithilfe der hier beschriebenen Prozeduren auch der Umgang mit ungültigen XMLDokumenten regeln. Hierzu bieten Stored Procedures durch die SQL Procedural Language (SQL PL) und speziell deren Abb. 6 Fehlerbehandlung: Condition und Continue Handler Konstrukten Condition und Continue Handler gezielte Möglichkeiten zur Fehlerbehandlung [9]. Dadurch lassen sich ungültige XML-Dokumente entweder mit selbst definierten Fehlermeldungen (SQLCODEs) abweisen oder mit einer negativen XSROBJECTID (in der Spalte SCHEMA_INFO) versehen abspeichern. Abbildung 6 demonstriert an einem Beispiel den Einsatz der zuvor genannten Konstrukte. Dabei wird eine Condition INVALID_DOCUMENT für den SQLSTATE 2201R („Das XML-Dokument ist nicht gültig.“) definiert, bei deren Auftreten ein Continue Handler aktiv wird. Dieser wiederum schreibt anschließend per UPDATE die negierte Form der entsprechenden XSROBJECTID in die SCHEMA_INFO-Spalte des aktuellen Datensatzes. Über die bereits betrachteten Anforderungen hinaus ist die Prozedur zur nachträglichen Schemavalidierung auch ausschlaggebend zur Unterstützung bei Schemaevolution. Dabei sollte der Prozess der Schemaänderung so konstruiert werden, dass ein geändertes XML-Schema als neues Schema (beziehungsweise neue Version des XML-Schemas) mit neuer XSROBJECTID datenbankseitig geführt wird. Da- 230 durch blieben zum einen die bisher gespeicherten Schemainformationen (SCHEMA_INFO) weiterhin gültig. Zum anderen könnte auf diesem Weg im Anschluss einer Schemaevolution dediziert entschieden werden, ob und, falls ja, wann ein Nachvalidieren der davon betroffenen XMLDokumente mit der Prozedur zur nachträglichen Schemavalidierung erfolgen soll. 6 Zusammenfassung Mit der pureXML-Technologie ist DB2 for z/OS V9.1 um erste Funktionalitäten der XML-Schemavalidierung erweitert worden. Dabei handelt es sich um Mechanismen zur datenbankseitigen Speicherung von XML-Schemas und zur Schemavalidierung einzelner XML-Dokumente gegen diese XML-Schemas. Darüber hinausgehende für den produktiven Einsatz wichtige Anforderungen, wie sie beispielsweise in diesem Beitrag spezifiziert wurden, unterstützt DB2 for z/OS V9.1 standardmäßig nicht. Das vorgestellte Konzept zur Erweiterung der DB2Standard-Funktionalitäten kann in diesem Zusammenhang leider auch nur bedingt als Lösung angesehen werden. Zwar ist es durch dessen Implementierung möglich, die diskutierten Anforderungen zu erfüllen. Allerdings hat sich speziell in [1] gezeigt, dass die Performance einer eigenimplementierten Lösung unter anderem aufgrund der in diesem Beitrag diskutierten Restriktionen verhältnismäßig schlecht ist. Aussagekräftig ist hierbei vor allem der gemessene Zusatzaufwand, den eine derartige Schemavalidierung im Rahmen einer Datenmanipulation verursacht. So konnte zum Beispiel in den in [1] betrachteten Fällen festgestellt werden, dass die vorgestellten Verfahren zur Schemavalidierung beim INSERT von XML-Dokumenten mindestens den 3-fachen Aufwand des „einfachen“ INSERTs (mit gleichzeitigem XML-Parsen) verursachten. Insofern ist es bezüglich der hier diskutierten Anforderungen ratsam, den Einsatz von datenbankseitiger XMLSchemavalidierung in DB2 for z/OS V9.1 zu überdenken. Wesentlich mehr Funktionalitäten bietet in dieser Hinsicht die Nachfolgeversion DB2 for z/OS V10. Hier ist es unter anderem möglich, eine Spalte vom XML-Datentyp direkt mit einem datenbankseitig hinterlegten XML-Schema Datenbank Spektrum (2013) 13:225–230 zu verknüpfen und darüber Funktionalitäten wie beispielsweise eine automatische Schemavalidierung zu gewährleisten. Nähere Details dazu und anderen in diesem Kontext relevanten Erweiterungen finden sich in [10, 11]. Literatur 1. Koch C (2012) Der Datentyp XML in DB2 for z/OS aus Performance-Perspektive. Diplomarbeit, Friedrich-SchillerUniversität Jena und DATEV eG 2. IBM Corporation (2012) DB2 pureXML-intelligent XML database management. http://www-01.ibm.com/software/data/db2/ xml. Stand 01.08.2012 3. Schöning H (2002) XML und Datenbanken: Konzepte und Systeme, 1. Aufl. Carl Hanser Verlag, Munich 4. IBM Corporation (2004) DB2 for OS/390 and z/OS library – XML extender administration and programming. http://publibfp. dhe.ibm.com/epubs/pdf/dxxxa811.pdf. Stand 01.08.2012 5. World Wide Web Consortium (W3C) (2004) XML schema part 0: primer second edition. W3C recommendation. http://www.w3. org/TR/xmlschema-0. Stand 01.08.2012 6. World Wide Web Consortium (W3C) (2004) XML schema part 1: structures second edition. W3C recommendation. http://www. w3.org/TR/xmlschema-1. Stand 01.08.2012 7. World Wide Web Consortium (W3C) (2004) XML schema part 2: datatypes second edition. W3C recommendation. http://www. w3.org/TR/xmlschema-2. Stand 01.08.2012 8. Nicola M, Kumar-Chatterjee P (2009) DB2 pureXML cookbook, 1. Aufl. IBM Press, Raleigh 9. IBM Corporation (2008) IBM redbook DB2 9 for z/OS: stored procedures: through the CALL and beyond. http://www.redbooks. ibm.com/redbooks/pdfs/sg247604.pdf. Stand 01.08.2012 10. IBM Corporation (2012) IBM redbook DB2 10 for z/OS: What’s new? http://publib.boulder.ibm.com/epubs/pdf/dsnwnm05.pdf. Stand 01.08.2012 11. IBM Corporation (2012) IBM redbook DB2 10 for z/OS: pureXML guide. http://publib.boulder.ibm.com/epubs/pdf/ dsnxgm04.pdf. Stand 01.08.2012 12. Hörnig E, Maßmann S, Rahm E (2006) Schema Evolution für XML und Web Services. http://dbs.uni-leipzig.de/html/ seminararbeiten/semWS0506/arbeit4.pdf. Stand 01.08.2012 13. Treutlein K (2009) DB2 9 for z/OS stored procedures. Diplomarbeit, Eberhard Karls Universität Tübingen 14. Van der Vlist E (2001) Comparing XML schema languages. http:// www.xml.com/pub/a/2001/12/12/schemacompare.html. Stand 01.08.2012 15. Koch C (2012) XML-Speicherstrukturen in DB2 for z/OS Version 9.1 und Überführungskonzepte für nicht-native XMLSpeicherformen. Studienarbeit, Friedrich-Schiller-Universität Jena und DATEV eG
