Ausarbeitung zum Allgemeinen Seminar von Thomas Dickel im Sommersemester 2002.
Ein XML Schema dient der Definition und Beschreibung einer Klasse von XML-Dokumenten durch Verwendung von Schemakomponenten. Die Schemakomponenten sind die Einzelteile, aus dem das abstrakte Datenmodell des Schemas besteht. Das Schema selbst wird dabei in XML geschrieben und erlaubt die Daten in mehr als 40 Datentypen abzubilden. Die Daten können nicht nur über den Datentyp bestimmt werden, sondern auch z.B. für Zahlen eine Ober- oder Untergrenze, für Zeichenketten bestimmte Zeichen erlaubt oder ausgeschlossen werden können.
Die Datentypsprache, die selbst in XML 1.0 repräsentiert ist, stellt eine Obermenge der Möglichkeiten dar, die durch XML 1.0 Dokumenttyp-Definitionen (DTDs) gegeben sind, um Datentypen für Elemente und Attribute zu spezifizieren.
Der Zweck eines XML Schemas besteht nicht nur darin, die Datentypen für Elemente und Attribute zu spezifizieren, sondern auch der Überprüfung des XML Dokumentes auf seine Korrektheit bezüglich des Schemas. Die Validierung beschränkt sich nicht nur auf das Datendokument; da das XML Schema ebenfalls in XML geschrieben ist, ist es möglich das XML Schema mittels eines weiteren Schemas zu validieren.
Die Überprüfung bezieht sich auf Reihenfolge und Hierarchie der XML Tags und auf die Einhaltung der Semantik der angegebenen Datentypen. Ein weiterer Vorteil der XML Schemas ist die Unterstützung von Selbstdokumentation.
XML Schema 1.0 wurde im Mai 2001 als Empfehlung des W3C herausgegeben. Das W3C ist dabei, eine von einigen Fehlern befreite und verbesserte Version 1.1 herauszugeben, wobei aber die Kompatibilität zu der Version 1.0 beibehalten werden soll.
In [9] gibt es einen Validator des World Wide Web Consortiums W3C, der XML Schema Dokumente auf ihre Korrektheit überprüft.
In Produkten der Firma Microsoft wird auch heute noch größtenteils das XDR Schema verwendet. XDR (XML Data Reduced) basiert auf der XML Data Notiz [5] des W3C, allerdings ist der Umfang der Schemabeschreibungssprache an einigen Stellen reduziert, daher die Namensgebung XDR. Seitdem das W3C im Mai 2001 aber die XML Schema Empfehlung ausgesprochen hat, baut Microsoft in den meisten Produkten aber nach und nach die XML Schema Unterstützung ein.
Der Vorteil von XML liegt in der Plattformunabhängigkeit und in der einfachen Handhabung der Dokumente. Die Schwächen der heute verfügbaren XML Tools liegen aber in der Durchführung von, auch dokumentübergreifenden, Suchanfragen. In diesem Gebiet haben die relationalen Datenbanken einem Geschwindigkeitsvorteil. Relationale Datenbanken unterstützen auch zwei andere wichtige Features, die bei XML Datenbanken schlecht zu realisieren: die Fähigkeiten zur Durchführung von Transaktionen sowie das Sperren von Datensätzen.
XML Dokumente können auch mehr Daten enthalten, die für die eigentliche Suchanfrage nicht gebraucht werden. Man kann also die nicht relevanten Daten bei dem Transport auf die relationale Datenbank wegfallen lassen und erhöht somit die Verarbeitungsgeschwindigkeit.
Der Hauptzweck der Konvertierung von XML Dokumenten liegt ist im umternehmensübergreifenden Datenaustausch zu finden. Bisher wurde der meiste Datenaustausch über Datenformate wie EDIFAKT realisiert. Nach und nach beginnt aber auch hier XML Fuß zu fassen und den Datenverkehr zu vereinfachen und zu standardisieren. Firmen muß für EDIFAKT Systeme viel investieren um den Datenaustausch mit ihren Geschäftspartnern zu ermöglichen. Software wie XML-edifact [6] erlaubt die Übertragung herkömlicher EDIFAKT Daten zu XML Daten. Hierbei werden Schemas wie XML Schema eingesetzt, die das XML Dokumentformat der Daten für die Übertragung definieren, aber gleichzeitig die Freiheit der technischen Umsetzung lassen, die eben die Eingliederung der Daten in eine bestehende Infrastruktur bedeutet.
Sind die XML-Daten nun irgendwann bei einem Geschäftspartner eingetroffen, so will dieser sie mit Sicherheit auch in seine eigene relationale Datenbank integrieren. Dazu muss eine Möglichkeit gefunden werden, die XML Daten in die Datenbank zu überführen.
Es gibt zum einen die Möglichkeit, ein XML Schema, daß das zu übertragende Dokument beschreibt, manuell mittels definierter Regeln in ein Datenbankmodell zu überführen. In einem zweiten Schritt müssen auch die Daten in die neue Datenbank gebracht werden. Bei einigen Datentypen sind hierbei Anpassungen nötig, die die Daten in XML Schema Datentypen in Datentypen einer relationalen Datenbank umwandelt.
Zum anderen gibt es fertige Software, die dieses in ähnlicher Weise erledigt. Als ein kommerzielles Beispiel wäre Microsoft Biztalk Server [7] zu nennen, daß eine Unterstützung in der gesamten Bandbreite des unternehmensübergreifenden Datenaustausches anbietet.
Weitere Werkzeuge, die in den nächsten Kapiteln vorgestellt werden, sind die SQLXML Erweiterung für den Microsoft SQL Server 2000 [8], sowie das Hilfsprogramm Microsoft XMLViewmapper 1.0, das aber leider nur das XDR Schema unterstützt.
XML Schema erlaubt über 40 verschiedene Datentypen sowie die Kombination und Erweiterung der Typen. Bei dem Transport der Daten auf eine relationale Datenbank muss eine Anpassung dieser Daten vorgenommen werden. Für die Basistypen ist in Tabelle 1 eine Gegenüberstellung der in XML Schema verwandten Basistypen und der Datentypen des Microsoft SQL Servers zu sehen. Weiteres wird im nächsten Abschnitt behandelt.
Datentypen des XML Schemas haben drei Attribute: den Wertebereich, den lexikalischen Bereich sowie den Eigenschaften der Wertebereiche ("facets").
Der Wertebereich ist die Menge von Werten eines Datentyps, der lexikalische Bereich enthält die zulässigen Literale. Die Eigenschaften der Wertebereiche, ("facets") dienen dazu, den Wertebereich semantisch zu beschreiben oder auch einzuschränken.
Beispielsweise hat der Datentyp Boolean einen Wertebereich, der dazu dient , das mathematische Konzept einer zweiwertigen Logik nachzubilden: {true, false}.
Bild 1: Hierarchie der Datentypen in XML Schema (aus [4])
Der lexikalische Bereich dieses Datentyps hat die Werte {true, false, 1, 0}. Die Eigenschaften des Wertebereichs sind "pattern" und "whiteSpace", wobei "pattern" den Wertebereich den Wertebereich auf Werte beschränkt, die auf Werte aus dem lexikalischen Bereichs passen und "whiteSpace" den Ausdruck soweit beeinflusst, dass bestimmte Sonderzeichen durch Leerzeichen ersetzt werden.
XML Schema ist auch mit dem Anspruch entwickelt worden, die Datentypen der SQL Welt abzubilden. Jedoch erlaubt XML Schema weitergehende Möglichkeiten, die bei einer Umsetzung in eine relationale Datenbank beachtet werden müssen, beispielsweise erlaubt der Boolean-Typ von XML Schema die Werte {true,false,0,1}, während bei einer SQL Datenbank nur die Werte {0,1} erlaubt sind.
Ähnliches gilt für die XML Schema Datentypen float und double. Bei ihnen sind auch die Textwerte INF und NAN erlaubt, die den Wert Unendlich bzw. Not-A-Number (also keine Zahl) repräsentieren. Der SQL Server erlaubt hier auch keine Texte, so daß diese Werte entsprechend anders umzusetzen sind. Als Vorschlag wäre hierfür die Nutzung des NULL-Wertes eines Datenfeldes zu sehen.
| XML Schema | SQL | |
|---|---|---|
| string normalizedString token base64Binary hexBinary | nvarchar oder ntext | nvarchar max. 4000 Zeichen, ntext für grössere Strings: 1.073.741.823 Zeichen (2^30-1) |
| duration | nvarchar | in der Form: P1Y2M3DT10H30M12.3S |
| boolean | bit | true/false zu 1/0 konvertieren |
| dateTime time date | datetime | Bei time und datetime: "1999-05-31T13:20:00.000-05:00" muss zu "1999-05-31 13:20:00" konvertiert werden |
| float | float(24) / real | INF u. NAN n. unterstützt |
| double | float(53) / double | INF u. NAN n. unterstützt |
| decimal | float | |
| integer positiveInteger negativeInteger nonNegativeInteger nonPositiveInteger | decimal | |
| byte | smallint | |
| unsignedByte | tinyint | |
| int unsignedInt | int | |
| long unsignedLong | bigint | |
| short unsignedShort | smallint | |
| gMonth gYear gYearMonth gDay gMonthDay Name Qname NCName AnyURI language | nvarchar |
Tabelle 1: Datentypen im Vergleich
In den ersten beiden Abschnitten sollen die heute üblichen Schema-Sprachen XML Schema (XSD) und XML Data Reduced erläutert werden. Danach werden grundsätzliche, für eine Konvertierung von XML Schema in eine relationale Datenbank erforderliche, Schritte gezeigt. Diese sollen die Problematik dieser Umsetzung verdeutlichen helfen.
Ein XML Schema besteht zum einem aus Namensräumen, die im Kopf des Schemas angegeben werden. Im Beispielcode
[Code1] ist es der Namensraum vom XML Schema (http://www.w3.org/2000/XMLSchema). "xmlns:dt" bezeichnet
den Namensraum für XML Schema Datentypen. Der dritte angebene
Namensraum xmlns:msch ist ein Zielnamensraum, dies bedeutet, dieser Namensraum enthält alle in diesem Schema-Dokument
definierten Elemente und Attribute.
Unterhalb dieses Tags werden alle Elemente und Attribute aufgelistet. Das xsd:element-Tag erzeugt im u.a. Beispiel dabei ein Element
namens daBuch, dessen Datentyp daBuch_type ist. Dieser Datentyp wird später definiert.
Der von diesem Element benötigte Benutzerdatentyp daBuch_type wird im nächsten Element definiert. Dieser Datentyp besteht aus einem
sog. Complextype, daß den Inhalt und die Attribute eines Elements dieses Typs angibt.
Die Unterelemente des Complextype-Tags definieren im u.a. Beispiel allesamt Attribute, die Datentypen selbst beziehen sich
auf die Datentypen von XML Schema, dies wird angegeben durch den Attributwert type="xsd:...".
Code 1: Beispielcode zu XML Schema
Das gleiche Schema in XML Data Reduced (XDR)[Code2] sieht nicht viel anders aus.
Man erkennt, daß für die Attribute eines Elementes die doppelte Anzahl an Tags erforderlich ist. AttributeType definiert
nur einen Datentyp, der in diesem Schema-Dokument benutzt werden kann, während attribute dieses Attribut unterhalb eines
Elementes einbindet. Im wesentlichen sind beide Darstellungsformen XDR und XSD identisch.
Ein weiterer Unterschied bezieht sich aber
auf die unterschiedlichen Datentypen von XDR. So ist ein (32Bit-)integer von XML Schema ein i4, und ein decimal ist ein
fixed.14.4, wobei bei letzterem die Zahlen die Vor- und Nachkommastellen der Darstellung des Datentyps angeben.
Code 2: Beispielcode zu XDR (XML Data Reduced) Schema
Diese Regel zur Umsetzung eines XML Schemas in eine Datenbank ist die nahezu wichtigste.
Es müssen zunächst die Tätigkeiten und allgemeine Regeln definiert werden, die bei jedem Hinzufügen einer Tabelle immer wieder erforderlich sind.
Beim Anlegen einer Tabelle in der Datenbank sollte man den Datenbanknamen als Datentabelle kennzeichnen. Als Vorschlag sollte man das Kürzel da verwenden.
Für die Tabelle muß ein Primärschlüssel definiert sein, der autoinkrementierend sein sollte. Desweiteren sollten alle verwendeten Spaltenname einer Tabelle ein Kürzel im Namen tragen, daß den verwendeten
Datentyp angibt (z.B. str für String, int für Integer, etc.). Der Name des Schlüssels sollte dabei noch die Text ID am Ende haben, um ihn als Primärschlüssel zu kennzeichnen.
Das ganze sollte so aussehen wie in [Bild2]. intBuchID ist im u.a. Beispiel ein Primärschlüssel des Datentyps Integer, u.s.w.
Bild 2: Regel 1
In dieser und den nächsten Regeln wird die Umsetzung von XML Schema Elementen behandelt.
Die grundlegende Tabellenerzeugung für ein Element läuft so ab:
Für jedes Element im XML Schema:
Hat das Element mindestens ein Attribut und/oder weitere Unterelemente?
Im Beispiel [Code3] gibt es das Element Buch, daß dem Element Verlag
untergeordnet ist. Nimmt man an, daß ein Buch nur genau einen Verlag zugeordnet sein kann, kann man diese Regel anwenden.
Unter der Annahme, daß die Tabelle daVerlag schon existiert, wird eine neue Tabelle daBuch angelegt. Sie bekommt nach Regel 1
einen Primärschlüssel, die Namensgebung erfolgt ebenso. Danach wird der Fremdschlüssel auf den Index der Tabelle daVerlag angelegt, um zu kennzeichnen, daß es das Element Buch nur genau einmal unter dem Element Verlag geben kann.
<Verlag strName="Wrox Press" ...>
<Buch strTitel="Professional XML".../>
</Verlag>
Code 3: Beispielcode zu Regel 2
Bild 3: Regel 2
Dies ist die Fortsetzung der Regel 2 im Fall, daß das zu bearbeitende Element in mehreren Elternelementen
vorkommen kann. Hierbei gibt es aber auch wieder zwei Fälle, je nachdem ob das Element einfach oder mehrfach unterhalb der Elternelemente auftritt. Schematisch:
Kommt das Element bei jedem Elternelement genau einmal vor?
Code 4: Beispielcode zu Regel 3
Im zweiten Fall, also wenn das Element bei mehreren Elternelementen mehrmals vorkommt, dann wird diese Situation mittels einer zusätzlichen Tabelle abgebildet. Solche Tabellen sollte man der Übersicht halber mit einem rl Präfix versehen. Die Tabelle rlBuchSchlagwort im [Bild 4] bildet die n:m Beziehung im Beispiel [Code 5] zwischen dem Tag Schlagwort und den Elternelementen Buch sowie weiteren vorstellbaren, im Bild nicht dargestellten Elementen, ab.
Code 5: Beispielcode zum zweiten Fall der Regel 3
Bild 4: Regel 3
Ist ein Element ein Nur-Text Element, d.h. es hat selbst keine Attribute und es kommen keine Unterelemente vor, wird es als eine weitere Spalte einer Tabelle (wie in [Bild 2] hinzugefügt. In [Code 6] sieht man die Elemente strTitel und strVerlag, die unterhalb des Elementes Buch eingebettet sind. Es wird angenommen, daß ein Buch nur jeweils genau einen Titel und einen Verlag hat.
Code 6: Nur-Text Elemente
Kann das gleiche Element hingegen mehrmals bei einem Elternelement vorkommen, dann fügt man zur Tabelle des aktuellen Elements einen Fremdschlüssel auf das Elternelement ein. In [Code 7] sieht man mehrere Schlagwort Elemente, die unterhalb eines Buch Elementes angeordnet sind. Wie in [Bild 5] zu sehen, hat der Tabelle ltSchlagwort neben ihrem eigenen Schlüssel und dem dazugehörigen Schlagwort-Text einen Fremdschlüssel auf die Tabelle Buch bekommen.
Code 7: Mehrfach vorkommende Nur-Text Elemente
Bild 5:
Zur vollständigen Umsetzung eines XML Schemas sind noch weitere Regeln erforderlich. Bei jeder Anwendung der obigen Regeln muß natürlich
noch auf die Konvertierung der Datentypen, wie in Tabelle 1 dargestellt, geachtet werden.
Desweiteren ist eine Prüfung auf Namenskollisionen wichtig, insbesondere wenn mehrere unterschiedliche XML-Dokumente bearbeitet werden,
bei denen gleichnamige Tags existieren, die aber eine unterschiedliche Bedeutung haben. Auch ist darauf zu achten, daß die Elemente des XML Schemas keine von SQL reservierten Worte sind.
In [1] wird ein Beispiel für das Umsetzen einer DTD in eine relationale Datenbank angegeben. Für das vollständige Umsetzen
einer DTD sind insgesamt 18 Regeln angegeben, dabei ist die Komplexität der DTD geringer als der von XML Schema
Fazit des Versuchs einer manuellen Umsetzung eines XML Schemas in eine relationale Datenbank:
Da die Nachteile des manuellen Verfahrens doch überwiegen sehen wir uns im nächsten Anschnitt Alternativen an, die das ganze programmgesteuert erledigen.
SQLXML 3.0 ist eine Erweiterung für den SQL Server 2000 in Bezug auf den verbesserten Umgang mit XML.
Das einfache Ein- und Auslesen von XML Daten geschieht mit Erweiterungen der SQL Befehle SELECT, INSERT,
UPDATE und DELETE. Da es in den ersten Versionen von SQLXML Performance-Probleme beim massenhaften Austausch von XML Daten gab, haben sich die Entwickler
eine neue Erweiterung namens BulkLoading ausgedacht, die dieses Problem behebt.
Bulkloading XML Data ist eine einfach von Visual Basic oder anderen Microsoft-Sprachen ansprechbare Schnittstelle,
der man XML Daten von einem Programm direkt an die Datenbank übergeben kann. Mit unserem Problem des Konvertierens eines XML Schemas in eine Datenbank steht diese Erweiterung
unmittelbar im Zusammenhang. Sie erlaubt es nämlich zusätzlich ein XML Schema anzugeben, dass bestimmte, in den Annotations des Schemas befindliche Anweisungen enthält, die
angeben, wohin die Daten geschrieben werden sollen.
Das SQLXMLBULKLOAD Objekt erlaubt auch Schemata im XDR Schema Format anzugeben oder sogar automatisch eine Anpassung der XML Daten auf eine Zieldatenbank zu versuchen.
In [Code 8] ist ein Beispiel in Visual Basic angegeben, daß zeigt, das nur wenige Befehle zur Umsetzung notwendig sind. Zum einem kann man dem
Bulkload-Objekt bestimmte Optionen angeben, die das Verhalten beeinflussen. In [Tabelle 2] ist eine Auswahl einiger Eigenschaften angegeben.
Code 8: Visual Basic-Code zur Anwendung des Bulkload-Objekts
| Eigenschaft | Beschreibung | |
| ConnectionString | gibt die Verbindung zu einer Datenbank an | |
| XMLFragment | gibt an, daß ein umschliessendes Root-Element im XML Dokument fehlen kann | |
| ErrorLogFile | gibt eine Datei an, in der eventuelle Fehlermeldungen und Warnungen geschrieben werden. Wichtig für das Fehlerdebugging. | |
| SchemaGen | gibt an, ob die Tabellen aus dem XML Schema neu angelegt werden sollen oder nicht |
Tabelle 2: Auswahl von Eigenschaften des Bulkload-Objekts
...
<xsd:annotation>
<xsd:appinfo>
<sql:relationship name= "VerlagBuch"
parent="daVerlag" parent-key="intVerlagID"
child="daBuch" child-key="intBuchID" />
</xsd:appinfo>
</xsd:annotation>
...
Bild 6:
Die Umsetzung der Daten wird über spezielle Tags in den Kommentierungsmöglichkeiten von XML Schema angegeben. Diese
Kommentierungsmöglichkeiten heißen Annotations. Diese Befehle geben an in welcher Art und Weise eine Verknüpfung
eines XML Elementes mit einem Element aus der Datenbank geschieht. Es kann einem Element eine ganze Tabelle oder eine Spalte
zugeordnet werden; ferner kann festgelgt werden, ob das Element bei einer späteren XML Ausgabe noch auftauchen soll oder ob das Element
mit anderen XML Elementen verknüpft ist. [Tabelle 3] gibt über die Möglichkeiten der Annotations Auskunft.
In [Code 9] sehen wir ein Beispiel einer Annotation. Das xsd:annotation-Element des abgebildeten Ausschnitt
befindet sich in einem XML Schema direkt hinter dem xsd:schema-Tag. Die Tags für das Mapping der XML Schema Elemente werden innerhalb des
xsd:appinfo-Blocks angegeben. Das Beispiel zeigt eine Beziehung namens VerlagBuch, die zwischen einer Tabelle
daVerlag mit dem Primärschlüssel intVerlagID und der Tabelle daBuch mit dem Schlüssel intBuchID besteht.
| Element | Beschreibung | |
| sql:relation | Element ist Tabelle | |
| sql:field | Element ist Spalte | |
| sql:is-constant | Element ist nicht verknüpft, erscheint aber im XML (z.B. für Root Element) | |
| sql:mapped | Nichtverknüpfte Elemente tauchen nicht mehr auf | |
| sql:relationship (parent, child, parent-key, child-key) | Verknüpfung zwischen den XML Elementen parent und child |
Tabelle 3: Auswahl von Eigenschaften der XSD Annotations
Die Vorteile der Arbeit mit dem SQLXMLBulkload Objekt sind also:
Microsoft XMLViewMapper ist ein Tool zur einfachen Erstellung der weiter oben beschriebenen Annotations zum Mapping
von XML Elementen auf Datenbankelemente. Leider kann dieses Programm nur XDR Schema verarbeiten, noch hat Microsoft kein
XML Schema integriert. Andererseits gibt es bei der oben besprochenen SQLXML Erweiterung ein Kommandozeilenprogramm namens
cvtschema.exe, das eben genau diese XDR Schema in ein XML Schema umwandeln kann.
Das Programm arbeitet folgendermassen:
Man wählt zuerst eine Datenbank aus, XMLViewmapper liest dabei eine vorhandene Datenbank ein und zeigt die enthaltenen Tabellen und
Spalten an. In [Bild 7] sieht man dies auf der linken Seite des Fensters. Dort ist eine Datenquelle (Source) namens
Books angegeben, die aus den Tabellen daAutor, daBuch, daVerlag usw. besteht. Die Tabelle daBuch ist aufgeklappt
dargestellt und man sieht die einzelnen Spalten der Tabelle. Die letzten beiden Einträge in dem Baum daBuch sind die Fremdschlüssel
der daBuch-Tabelle auf die Indizes der daAutor- und daVerlag-Tabellen.
Nach der Auswahl der Datenbank wählt man ein XDR Schema aus. Das Schema wird in ähnlicher Weise wie die Datenbank dargestellt.
Bis zu diesem Zeitpunkt sind noch keine Verbindungslinien zwischen Datenbank und XDR Schema dargestellt. Als letzten Schritt muss man die
Elemente der Datenbank mit den Elementen des XDR Schemas verknüpfen. Dazu zieht man per Drag-and-drop vom linken Fenster ein Element und lässt
es auf ein Element der rechten Seite fallen.
Die Verknüpfungen zwischen Datenbank und Schema ergeben ein View, dass eben die Annotations enthält; also die Regeln nach denen Elemente aus dem
XML Dokument mit Elementen der Datenbank, Tabellen oder Spalten, verknüpft sind.
Bild 7: Microsoft XMLViewMapper
Das Programm arbeitet mit Microsoft SQL Server 2000 oder auch mit dem Microsoft Biztalk Server zusammen, wobei letzteres standardmäßig ein ähnliches Tool enthält..
Das Ziel dieses Programms ist es aus dem XDR Schema, das definiert, welche Elemente und wie erlaubt sind, ein SQL Schema zu machen, in dem definiert ist, wie
die XML Elemente auf eine spezifische Datenbank abgebildet werden. Der Sinn und Zweck liegt darin, ein immer gleiches XDR Schema zu haben, dass das XML Dokument
definiert, aber das SQL Schema ist davon unabhängig und erlaubt eine freie Implementation der Datenbankstrukturen.
Der unternehmensübergreifende Datenaustausch wird in einer sich globalisierenden Welt immer wichtiger. Umso wichtiger ist es den Datenverkehr zu standardisieren. Standards wie
EDIFACT haben zwar in der Industrie Fuß gefasst, aber allein dadurch, daß grössere Unternehmen kleinere dieses aufgezwungen hat. Für die kleinen und mittelständischen Unternehmen
hat eine solche Technologie enorme Kosten verursacht.
XML ist aber mit dem Anspruch aufgetreten, ein "preiswerter" Standard zu sein. In der Tat ist für diese Technologie weitaus weniger an Kosten erforderlich. Allerdings erfordert
der unternehmensübergreifende Datenaustausch ebenfalls neue Technologien wie z.B. Microsoft Biztalk, die eben nicht kostenlos zu haben sind.
Mit den oben beschriebenen Technologien wie Bulkloading XML oder dem XMLViewmapper steht aber kostenlose Software zur Verfügung, die den Datenaustausch zwischen XML Dokumenten und
relationalen Datenbanken einfach handhabt. Eine manuelle Umsetzung wie weiter oben beschrieben scheint aufgrund der hohen Entwicklungskosten und- dauer wenig sinnvoll.
Was bringt die Zukunft?
Die im Vortrag benutzte Powerpoint-Präsentation.
[1] Williams, Kevin et al. "Database Structures for Existing XML". Professional XML Databases. Birmingham,UK: Wrox Press, 2000: 67-109
[2] XML Schema Part 0: Primer 02 May 2001. World Wide Web Consortium (W3C).
31 May 2002 <http://www.w3.org/TR/xmlschema-0/>
[3] XML Schema Part 1: Structures 02 May 2001. World Wide Web Consortium (W3C).
31 May 2002 <http://www.w3.org/TR/xmlschema-1/>
[4] XML Schema Part 2: Datatypes 02 May 2001. World Wide Web Consortium (W3C).
31 May 2002 <http://www.w3.org/TR/xmlschema-2/>
[5] XML-Data 05 Jan 1998. World Wide Web Consortium (W3C).
31 May 2002 <http://www.w3.org/TR/1998/NOTE-XML-data/>
[6] XML-edifact 04 Mar 2000. Michael Koehne.
31 May 2002 <http://www.xml-edifact.org/>
[7] Microsoft Biztalk Server 31 May 2002. Microsoft.
31 May 2002 <http://www.microsoft.com/biztalk/>
[8] Microsoft SQL Server 31 May 2002. Microsoft.
31 May 2002 <http://www.microsoft.com/sql/>
[9] Validator for XML Schema 16 May 2001. World Wide Web Consortium (W3C).
31 May 2002 <http://www.w3.org/2000/09/webdata/xsv/>
