XML und Internet-Datenbanken

Transkript

1 ZUSATZKAPITEL 1 XML und Internet-Datenbanken Wir richten unsere Aufmerksamkeit nun darauf, wie man Datenbanken im Internet benutzt und darauf zugreift. Viele E-Commerce- und andere Internetanwendungen bieten Web-Oberflächen für den Zugriff auf Informationen, die in einer oder mehreren Datenbanken gespeichert sind. Diese Datenbanken werden oft als Datenquellen bezeichnet. Es ist üblich, zwei- und dreischichtige Client/Server-Architekturen für Internetanwendungen zu benutzen (siehe Abschnitt 2.5). In manchen Fällen kommen auch andere Varianten des Client/Server-Modells zum Einsatz. E-Commerce- und andere Internet-Datenbankanwendungen werden für die Interaktion mit dem Benutzer über Web-Oberflächen, die Web-Pages anzeigen, ausgelegt. Bei der üblichen Methode zur Spezifizierung des Inhalts und der Formatierung von Web-Pages werden Hyperlink-Dokumente verwendet. Zum Schreiben dieser Dokumente stehen verschiedene Sprachen zur Verfügung, wobei HTML (Hypertext Markup Language) die häufigste ist. Obwohl HTML vorwiegend zur Formatierung und Strukturierung von Web-Dokumenten benutzt wird, eignet es sich nicht zur Spezifikation strukturierter Daten, die aus Datenbanken extrahiert werden. Vor einiger Zeit entstand eine neue Sprache XML (Extended Markup Language) als Standard für die Strukturierung und den Austausch von Daten im Web. XML kann benutzt werden, um Informationen über die Struktur und Bedeutung der Daten in Web-Pages bereitzustellen, statt einfach nur zu spezifizieren, wie die Web-Pages zur Anzeige am Bildschirm formatiert werden. Die Formatierungsaspekte werden getrennt spezifiziert, z. B. durch Verwendung einer Formatierungssprache wie XSL (Extended Stylesheet Language). In diesem Kapitel werden die Grundlagen zum Zugriff und Austausch von Informationen über das Internet beschrieben. Wir beginnen in Abschnitt 1.1 mit einer Diskussion, wie sich traditionelle Web-Pages von strukturierten Datenbanken unterscheiden und wie sich strukturierte, teilstrukturierte und unstrukturierte Daten unterscheiden. In Abschnitt 1.2 werden der XML-Standard und das baumstrukturierte (hierarchische) Datenmodell beschrieben. Abschnitt 1.3 behandelt XML-Dokumente und die Sprachen zur Spezifikation der Struktur dieser Dokumente, nämlich XML- DTD (Document Type Definition) und XML-Schema. In Abschnitt 1.4 werden die verschiedenen Ansätze zum Speichern von XML-Dokumenten im nativen (Text-) Format, in komprimierter Form oder in relationalen und anderen Datenbanktypen präsentiert. Abschnitt 1.5 gibt einen Überblick über die zur Anfrage von XML-Daten vorgeschlagenen Sprachen. Abschnitt 1.6 enthält eine Zusammenfassung des Kapitels.

2 2 Zusatzkapitel 1 XML und Internet-Datenbanken 1.1 Strukturierte, teilstrukturierte und unstrukturierte Daten Die in Datenbanken gespeicherten Informationen werden als strukturierte Daten bezeichnet, weil sie in einem strikten Format dargestellt werden. Beispielsweise weist jeder Datensatz in einer relationalen Datenbanktabelle wie z. B. der Tabelle ANGE- STELLTER in Abbildung 7.6 das gleiche Format wie die übrigen Datensätze in dieser Tabelle auf. Für strukturierte Daten ist es üblich, die Datenbank unter Verwendung von Techniken wie die in den Kapiteln 3, 4, 7, 10 und 11 beschriebenen sorgfältig auszulegen, um das Datenbankschema zu erstellen. Das DBMS prüft das Ganze dann, um sicherzustellen, dass alle Daten die im Schema spezifizierten Strukturen und Einschränkungen erfüllen. Allerdings werden nicht alle Daten in sorgfältig entworfenen strukturierten Datenbanken gesammelt und eingefügt. In manchen Anwendungen werden Daten ad hoc erfasst, bevor bekannt ist, wie sie gespeichert und verwaltet werden. Diese Daten mögen eine bestimmte Struktur aufweisen, haben aber nicht alle eine identische Struktur. Möglicherweise werden einige Attribute von den verschiedenen Entitäten gemeinsam genutzt, während andere nur in ein paar Entitäten existieren. Außerdem kann es sein, dass zu irgendeinem Zeitpunkt zusätzliche Attribute, für die es kein vordefiniertes Schema gibt, in einige der neueren Datenexemplare eingeführt werden. Dieser Datentyp wird als teilstrukturierte Daten bezeichnet. Eine Reihe von Datenmodellen wurde zur Darstellung teilstrukturierter Daten eingeführt. Meist basieren diese Datenmodelle auf der Verwendung von Baum- oder Graphen-Datenstrukturen statt den flachen relationalen Modellstrukturen. Ein wichtiger Unterschied zwischen strukturierten und teilstrukturierten Daten betrifft die Behandlung der Schemakonstrukte (z. B. die Namen von Attributen, Beziehungen und Entitätstypen). Bei teilstrukturierten Daten wird die Schemainformation in die Datenwerte eingemischt, weil jedes Datenobjekt unterschiedliche Attribute haben kann, die nicht im Voraus bekannt sind. Folglich wird dieser Datentyp auch als selbstbeschreibende Daten bezeichnet. Man betrachte das folgende Beispiel. Wir wollen eine Liste mit bibliographischen Bezugsquellen in Zusammenhang mit einem bestimmten Forschungsprojekt erfassen. Das können Bücher oder technische Berichte, Forschungsartikel in Journalen und Konferenzprotokollen (Conference Proceedings) oder auch komplette Journalausgaben sein. Selbstverständlich können diese Bezugsquellen unterschiedliche Attribute und Informationstypen aufweisen. Sogar für den gleichen Bezugstyp sagen wir, Konferenzartikel können sich unterschiedliche Informationen ergeben. Beispielsweise kann eine Artikelangabe ziemlich vollständig sein, mit Informationen über Autorennamen, Titel, Protokollen, Seitennummern usw., während zu anderen Quellenangaben überhaupt keine Informationen verfügbar sind. Außerdem können künftig neue Arten bibliographischer Quellen auftauchen, z. B. Bezugnahmen auf Web-Pages oder Konferenztutorien, die durch neue Attribute beschrieben werden müssen. Teilstrukturierte Daten können als gerichteter Graph (siehe Abbildung 1.1) dargestellt werden. Die Informationen in dieser Abbildung entsprechen teilweise den strukturierten Daten von Abbildung 7.6. Wir sehen, dass dieses Modell dadurch, dass es komplexe Objekte und verschachtelte Strukturen darstellen kann, dem Objektmodell (siehe Abbildung 11.1) ähnelt. In Abbildung 1.1 stellen die Label oder Tags auf den gerichteten Kanten die Schemanamen dar: Attributnamen, Objekttypen (bzw. Entitäts-

3 1.1 Strukturierte, teilstrukturierte und unstrukturierte Daten 3 typen oder Klassen) und Beziehungen. Die internen Knoten stellen einzelne Objekte oder zusammengesetzte Attribute dar. Die Blattknoten stellen tatsächliche Datenwerte von einfachen (atomaren) Attributen dar. Abbildung 1.1: Darstellung teilstrukturierter Daten als Graph. Zwischen dem teilstrukturierten Modell und dem in Kapitel 11 behandelten Objektmodell bestehen zwei hauptsächliche Unterschiede: 1. Die Schemainformationen Namen von Attributen, Beziehungen und Klassen (Objekttypen) im teilstrukturierten Modell sind mit den Objekten und ihren Datenwerten in derselben Datenstruktur vermischt. 2. Im teilstrukturierten Modell besteht keine Anforderung für ein vordefiniertes Schema, mit dem die Datenobjekte konform sein müssen. Zusätzlich zu strukturierten und teilstrukturierten Daten gibt es eine dritte Kategorie, die als unstrukturierte Daten bezeichnet wird, weil Hinweise auf den Typ dieser Daten sehr begrenzt sind. Ein typisches Beispiel ist ein Textdokument mit eingebetteten Informationen. Web-Pages in HTML, die einige Daten enthalten, gelten als unstrukturierte Daten. Man betrachte den Teil einer HTML-Datei in Abbildung 1.2. Der zwischen eckigen Klammern, <...>, stehende Text ist ein HTML-Tag. Ein Tag mit einem Schrägstrich, </...>, ist ein End-Tag, das die Wirkung eines passenden Start- Tags beendet. Die Tags gelten als Markup, d. h. sie zeichnen das Dokument 1 aus, um einen HTML-Prozessor anzuweisen, wie der Text zwischen einem Start- und einem passenden End-Tag anzuzeigen ist. Folglich spezifizieren die Tags eine Dokument- 1. Deshalb wird diese Auszeichnung als Hypertext Markup Language bezeichnet.

4 4 Zusatzkapitel 1 XML und Internet-Datenbanken formatierung statt die Bedeutung der verschiedenen Datenelemente im Dokument. HTML-Tags spezifizieren Informationen, wie z. B. Schriftgröße und -stil (Fett, Kursiv usw.), Farbe, Überschriftebenen usw. Einige Tags spezifizieren Textstrukturierung in Dokumenten, z. B. eine nummerierte oder unnummerierte Aufzählungsliste oder eine Tabelle. Sogar diese Strukturierungs-Tags spezifizieren, dass die eingebetteten Textdaten auf bestimmte Weise angezeigt werden müssen, statt den in der Tabelle dargestellten Datentyp anzudeuten. Abbildung 1.2: Teil eines HTML-Dokuments, das unstrukturierte Daten darstellt. <html> <head>... </head> <body> <H1>Auflistung der Firmenprojekte und Angestellten in jedem Projekt</H1> <H2>Das Projekt ProductX:</H2> <table width="100%" border=0 cellpadding=0 cellspacing=0> <TR> <TD width="50%"><font size="2" face="arial">john Smith:</font></TD> <TD>32,5 Stunden pro Woche</TD> </TR> <TR> <TD width="50%%"><font size="2" face="arial">joyce English: </font></td> <TD>20,0 Stunden pro Woche</TD> </TR> </table> >H2>Das Projekt ProductY:</H2> <table width="100%" border=0 cellpadding=0 cellspacing=0> <TR> <TD width="50%"><font size="2" face="arial">john Smith:</font></TD> <TD>7,5 Stunden pro Woche</TD> </TR> <TR> <TD width="50%%"><font size="2" face="arial">joyce English: </font></td> <TD>20,0 Stunden pro Woche</TD> </TR> <TR> <TD width="50%%"><font size="2" face="arial">franklin Wong:</font></TD> <TD>10,0 Stunden pro Woche</TD> </TR> </table>... </body> </html>

5 1.1 Strukturierte, teilstrukturierte und unstrukturierte Daten 5 In HTML können zahlreiche vordefinierte Tags benutzt werden, um eine Vielzahl von Befehlen zur Formatierung der Anzeige von Web-Dokumenten zu spezifizieren. Die Start- und End-Tags spezifizieren den von jedem Befehl zu formatierenden Textbereich. Nachfolgend ein paar Beispiele für die in Abbildung 1.2 dargestellten Tags: Die Tags <html>...</html> spezifizieren die Grenzen des Dokuments. Der Dokumentkopf zwischen den Tags <head>...</head> spezifiziert verschiedene Befehle, die anderswo im Dokument benutzt werden, z. B. verschiedene Script-Funktionen in einer Sprache wie JAVA Script oder PERL oder bestimmte Formatierungsstile (Schriftarten, Absatz- und Überschriftstile usw.), die im Dokument benutzt werden können. Diese Informationen können auch einen Titel spezifizieren, um anzudeuten, wofür die HTML-Datei dient, und weitere ähnliche Informationen, die nicht als Teil des Dokuments angezeigt werden. Der Dokumentrumpf zwischen den Tags <body>...</body> beinhaltet den Dokumenttext und die Markup-Tags, die spezifizieren, wie der Text zu formatieren und anzuzeigen ist. Er kann auch Referenzen auf andere Objekte, z. B. Bilder, Videos, Sprachnachrichten und andere Dokumente, enthalten. Die Tags <H1>...</H1> spezifizieren, dass der Text als Überschrift der Ebene 1 angezeigt werden soll. Es gibt viele Überschriftebenen (<H2>, <H3> usw.), die den Text jeweils in einem weniger stark hervorgehobenen Format darstellen. Die Tags <table>...</table> spezifizieren, dass der anschließende Text als Tabelle angezeigt werden soll. Jede Zeile der Tabelle steht zwischen den Tags <TR>... </TR>, und die eigentlichen Textdaten werden zwischen den Tags <TD>...</TD> 2 angezeigt. Einige Tags enthalten vielleicht Attribute, die dann im Start-Tag stehen und zusätzliche Tag-Eigenschaften beschreiben. 3 In Abbildung 1.2 verfügt das Start-Tag <table> über vier Attribute, die verschiedene Merkmale der Tabelle beschreiben. Das anschließende <TD> und das Start-Tag <font> haben ein bzw. zwei Attribute. HTML verfügt über eine sehr große Anzahl vordefinierter Tags, und ganze Bücher sind über die Beschreibung, wie diese Tags benutzt werden, erhältlich. Sofern HTML- Dokumente korrekt entworfen werden, können sie so formatiert werden, dass man die Dokumentinhalte leicht verstehen und mühelos durch die resultierenden Web- Dokumente navigieren kann. Die HTML-Quelltextdokumente lassen sich aber nur schwerlich automatisch von Computerprogrammen interpretieren, weil sie keine Schemainformationen über den Datentyp in den Dokumenten enthalten. Im Zuge der steigenden Automatisierung von E-Commerce- und anderen Internetanwendungen wird es umso wichtiger, Web-Dokumente zwischen verschiedenen Computerstandorten austauschen und ihre Inhalte automatisch interpretieren zu können. Dieser Bedarf war einer der Gründe, die zur Entwicklung von XML führten. XML wird im nächsten Abschnitt behandelt. 2. <TR> steht für»table Row«und <TD> für»table Data«. 3. Auf diese Weise wird der Begriff Attribut in Dokument-Markup-Sprachen benutzt, die sich von seiner Bedeutung in Datenbankmodellen unterscheidet.

6 6 Zusatzkapitel 1 XML und Internet-Datenbanken 1.2 Das hierarchische (Baum-)Datenmodell von XML Wir führen jetzt das in XML benutzte Datenmodell ein. Das Basisobjekt ist XML im XML-Dokument. Zur Konstruktion eines XML-Dokuments werden zwei wichtige Strukturierungskonzepte angewandt: Elemente und Attribute. Man beachte die vorherige Feststellung, dass der Begriff Attribut in XML nicht die gleiche Bedeutung wie in der Datenbankterminologie hat, sondern wie in Dokumentbeschreibungssprachen, z. B. HTML und SGML 4, benutzt wird. In XML bieten Attribute zusätzliche Informationen, die Elemente beschreiben, wie wir noch sehen werden. Daneben gibt es in XML weitere Konzepte, wie Entitäten, Identifizierer und Referenzen. Zuerst konzentrieren wir uns aber auf die Beschreibung von Elementen und Attributen, um die Essenz des XML-Modells aufzuzeigen. Abbildung 1.3 zeigt ein XML-Beispielelement namens <Projekte>: Wie in HTML werden Elemente in einem Dokument durch ihr Start- und End-Tag identifiziert. Die Tag-Namen stehen zwischen eckigen Klammern, <...>, und die End-Tags haben zusätzlich einen Schrägstrich, </...> 5. Komplexe Elemente werden aus anderen Elementen hierarchisch gebildet, während einfache Elemente Datenwerte enthalten. Ein wichtiger Unterschied zwischen XML und HTML ist, dass Tag-Namen in XML definiert werden, um die Bedeutung der Datenelemente im Dokument zu beschreiben, und nicht, wie der Text angezeigt werden soll. Dadurch ist es möglich, die Datenelemente im XML-Dokument automatisch von Computerprogrammen verarbeiten zu lassen. Die Entsprechung zwischen der in Abbildung 1.3 dargestellten textlichen XML- Darstellung und der Baumstruktur von Abbildung 1.1 lässt sich leicht erkennen. In der Baumstruktur stellen interne Knoten komplexe und Blattknoten einfache Elemente dar. Aus diesem Grund wird das XML-Modell als Baum- oder hierarchisches Modell bezeichnet. In Abbildung 1.3 sind die einfachen Elemente diejenigen mit den Tag-Namen <PName>, <PNummer>, <PStandort>, <AbtNr>, <SSN>, <Nachname>, <Vorname> und <Stunden>. Die komplexen Elemente sind diejenigen mit den Tag- Namen <Projekte>, <Projekt> und <Mitarbeiter>. Im Allgemeinen sind die Elementverschachtelungsebenen nicht begrenzt. Generell kann man XML-Dokumente in drei Haupttypen unterteilen: Datenzentrische XML-Dokumente: Diese Dokumente enthalten viele kleine Datenexemplare, die einer spezifischen Struktur entsprechen und folglich aus einer strukturierten Datenbank extrahiert werden können. Sie werden als XML-Dokumente formatiert, um sie über das Web austauschen und anzeigen zu können. Dokumentzentrische XML-Dokumente: Hierbei handelt es sich um Dokumente mit großen Textmengen, z. B. Nachrichtenartikel oder Bücher. Sie enthalten wenige oder keine strukturierten Datenelemente. Hybride XML-Dokumente: Diese Dokumente können Teile umfassen, die strukturierte Daten und andere, die vorwiegend textliche oder unstrukturierte Daten enthalten. 4. SGML (Standard Generalized Markup Language) ist eine allgemeinere Sprache zur Beschreibung von Dokumenten mit Möglichkeiten für die Spezifikation neuer Tags. Sie ist aber komplexer als HTML und XML. 5. Die linke und rechte eckige Klammer (< und >) sind reservierte Zeichen, ebenso wie Ampersand (&), Apostroph ( ) und einfache Anführungszeichen ('). Um sie im Text selbst verwenden zu können, müssen sie als &lt, &gt, &amp, &apos bzw. &quot kodiert werden.

7 1.2 Das hierarchische (Baum-)Datenmodell von XML 7 Abbildung 1.3: Ein komplexes XML-Element namens <Projekte>. <?xml version ="1.0" standalone="yes"?> <Projekte> <Projekt> <PName>ProductX</PName> <PNummer>1</PNummer> <PStandort>Bellaire</PStandort> <AbtNr>5</AbtNr> <Mitarbeiter> <SSN> </SSN> <Nachname>Smith</Nachname> <Stunden>32,5</Stunden> </Mitarbeiter> <Mitarbeiter> <SSN> </SSN> <Vorname>Joyce</Vorname> <Stunden>20,0</Stunden> </Mitarbeiter> </Projekt> </Projekt> <PName>ProductY</PName> <PNummer>2</PNummer> <PStandort>Sugarland</PStandort> <AbtNr>5</AbtNr> <Mitarbeiter> <SSN> </SSN> <Stunden>7,5</Stunden> </Mitarbeiter> <Mitarbeiter> <SSN> </SSN> <Stunden>20,0</Stunden> </Mitarbeiter> <Mitarbeiter> <SSN> </SSN> <Stunden>10,0</Stunden> </Mitarbeiter> </Projekt>... </Projekte> Wichtig ist die Feststellung, dass datenzentrische XML-Dokumente entweder als teilstrukturierte oder strukturierte Daten betrachtet werden können. Wenn ein XML- Dokument mit einem vordefinierten XML-Schema oder einer DTD (siehe Abschnitt 1.3) konform ist, besteht das Dokument aus strukturierten Daten. Andererseits lässt XML Dokumente zu, die mit keinem Schema konform sind; sie würde man als teilstrukturierte Daten betrachten. Letztere werden auch als schemalose XML-Dokumente bezeichnet. Wenn der Wert des Attributs STANDALONE in einem XML-Dokument

8 8 Zusatzkapitel 1 XML und Internet-Datenbanken»YES«ist, wie in der ersten Zeile von Abbildung 1.3, ist das Dokument als standalone deklariert und schemalos. XML-Attribute werden im Allgemeinen ähnlich wie in HTML benutzt (siehe Abbildung 1.2), nämlich um Eigenschaften und Charakteristika der Elemente (Tags), in denen sie erscheinen, zu beschreiben. Man kann XML-Attribute auch zur Aufnahme der Werte einfacher Datenelemente benutzen; dies wird aber nicht empfohlen. XML-Attribute werden in Zusammenhang mit XML-Schema und XML-DTD ausführlicher behandelt. 1.3 XML-Dokumente, -DTD und -Schema Wohlgeformte, gültige XML-Dokumente und XML-DTD In Abbildung 1.3 haben wir gesehen, wie ein einfaches XML-Dokument aussehen könnte. Ein XML-Dokument ist wohlgeformt, wenn es ein paar Bedingungen erfüllt. Insbesondere muss es mit einer XML-Deklaration beginnen, um die benutzte XML- Version und einige weitere, relevante Attribute auszuweisen, wie in der ersten Zeile von Abbildung 1.3 ersichtlich ist. Es muss auch den syntaktischen Richtlinien des Baummodells entsprechen. Das bedeutet, dass es ein einzelnes Wurzelelement haben und dass jedes Element ein passendes Paar von Start- und End-Tags innerhalb der Start- und End-Tags des Elternelements enthalten soll. Dadurch ist gewährleistet, dass die verschachtelten Elemente eine wohlgeformte Baumstruktur spezifizieren. Ein wohlgeformtes XML-Dokument ist syntaktisch korrekt. Dies ermöglicht, dass es in generischen Prozessoren verarbeitet werden kann, die das Dokument durchlaufen und eine interne Baumdarstellung erzeugen. Eine Standardmenge von API-Funktionen (API = Application Programming Interface), die als DOM (Document Object Model) bezeichnet wird, ermöglicht es, dass Programme die resultierende Baumdarstellung gemäß einem wohlgeformten XML-Dokument manipulieren können. DOM setzt allerdings die vorherige Analyse des gesamten Dokuments voraus. Ein weiteres API namens SAX ermöglicht die sofortige Verarbeitung von XML-Dokumenten, da das verarbeitende Programm benachrichtigt wird, sobald ein Start- oder End-Tag vorkommt. Dies vereinfacht die Verarbeitung großer Dokumente und ermöglicht die Verarbeitung so genannter Streaming-XML-Dokumente, wobei das verarbeitende Programm die Tags verarbeiten kann, wenn es auf sie stößt. Ein wohlgeformtes XML-Dokument kann beliebige Tag-Namen für die in ihm enthaltenen Elemente haben. Es gibt keine vordefinierten Elemente (Tag-Namen), die ein Programm, welches das Dokument verarbeitet, erwarten würde. Dies bietet dem Dokumentverfasser Spielraum für die Spezifikation neuer Elemente, hat aber gewisse Grenzen hinsichtlich der Möglichkeiten für die automatische Interpretation der im Dokument enthaltenen Elemente. Ein stärkeres Kriterium ist es für ein XML-Dokument, gültig zu sein. In diesem Fall muss das Dokument wohlgeformt sein. Zusätzlich müssen die Elementnamen in Start- und End-Tag-Paaren die in einer separaten XML-DTD- (Document Type Definition) oder -Schemadatei spezifizierte Struktur aufweisen. Wir beginnen hier mit XML-DTD und geben dann in Abschnitt einen Überblick über XML-Schema. Abbildung 1.4 zeigt eine einfache XML-DTD-Datei, welche die Elemente (Tag- Namen) und ihre verschachtelten Strukturen spezifiziert. Gültige Dokumente, die mit dieser DTD konform sind, müssen die spezifizierte Struktur aufweisen. Aus Abbil-

9 1.3 XML-Dokumente, -DTD und -Schema 9 dung 1.4 wird ersichtlich, dass es für die Spezifikation von DTD-Dateien eine spezielle Syntax gibt. Zuerst wird das Wurzel-Tag des Dokuments benannt; in der ersten Zeile von Abbildung 1.4 heißt es»projekte«. Anschließend werden die Elemente und ihre verschachtelte Struktur spezifiziert. Abbildung 1.4: Eine XML-DTD-Datei namens Projekte. <!DOCTYPE Projekte [ <!ELEMENT Projekte (Projekt+)> <!ELEMENT Projekt (PName, PNummer, PStandort, AbtNr?, Mitarbeiter)> <!ELEMENT Name (#PCDATA)> <!ELEMENT PNummer (#PCDATA)> <!ELEMENT PStandort (#PCDATA)> <!ELEMENT AbtNr (#PCDATA)> <!ELEMENT Mitarbeiter (Mitarbeiter*)> <!ELEMENT Mitarbeiter (SSN, Nachname?, Vorname?, Stunden)> <!ELEMENT SSN (#PCDATA)> <!ELEMENT Nachname (#PCDATA)> <!ELEMENT Vorname (#PCDATA)> <!ELEMENT Stunden (#PCDATA)> ] > Zur Spezifikation von Elementen wird folgende Notation benutzt: Ein * nach dem Elementnamen bedeutet, dass das Element keinmal oder mehrmals im Dokument wiederholt werden kann. Diese Elementart wird als optionales mehrwertiges (wiederholendes) Element bezeichnet. Ein + nach dem Elementnamen bedeutet, dass das Element einmal oder mehrmals im Dokument wiederholt werden kann. Diese Elementart wird als erforderliches mehrwertiges (wiederholendes) Element bezeichnet. Ein? nach dem Elementnamen bedeutet, dass das Element kein- oder einmal wiederholt werden kann. Diese Art ist ein optionales einwertiges (nicht wiederholendes) Element. Ein Element, das keines der obigen drei führenden Symbole aufweist, muss genau einmal im Dokument erscheinen. Diese Art ist ein erforderliches einwertiges (nicht wiederholendes) Element. Der Typ eines Elements wird mittels Klammern nach dem Element spezifiziert. Wenn die Klammern Namen von anderen Elementen beinhalten, sind Letztere die Kinder des Elements in der Baumstruktur. Beinhalten die Klammern das Schlüsselwort #PCDATA oder einen der übrigen, in der XML-DTD verfügbaren Datentypen, ist das Element ein Blattknoten. PCDATA steht für Parsed Character Data, was etwa einem String-Datentyp ähnelt. Klammern können bei der Spezifikation von Elementen verschachtelt werden. Ein senkrechter Strich (e 1 e 2 ) bedeutet, dass entweder e 1 oder e 2 im Dokument erscheinen kann.

10 10 Zusatzkapitel 1 XML und Internet-Datenbanken Wir sehen, dass die Baumstruktur in Abbildung 1.1 und das XML-Dokument in Abbildung 1.3 mit der XML-DTD von Abbildung 1.4 konform sind. Soll ein XML- Dokument auf Konformität mit einer DTD geprüft werden, müssen wir dies in der Deklaration des Dokuments angeben. Wir könnten z. B. die erste Zeile von Abbildung 1.3 wie folgt abändern: <?xml version="1.0" standalone="no"?> <!DOCTYPE Projekte SYSTEM "proj.dtd"> Wenn der Wert des Attributs standalone in einem XML-Dokument "no" (nein) ist, muss das Dokument mit einem getrennten DTD-Dokument gegengeprüft werden. Die DTD-Datei von Abbildung 1.4 sollte im gleichen Dateisystem wie das XML-Dokument gespeichert und mit dem Dateinamen "proj.dtd" benannt werden. Alternativ können wir den DTD-Dokumenttext direkt am Anfang des XML-Dokuments einfügen, um es prüfen zu lassen. Obwohl sich XML-DTD gut zur Spezifikation von Baumstrukturen mit erforderlichen, optionalen und wiederholenden Elementen eignet, ist es mehreren Einschränkungen unterworfen. Erstens sind die Datentypen in DTD nicht sehr generell. Zweitens hat DTD ihre eigene spezielle Syntax, so dass spezialisierte Prozessoren erforderlich sind. Es wäre vorteilhaft, XML-Schemadokumente mit Hilfe der Syntaxregeln von XML selbst spezifizieren zu können, damit die Prozessoren, die für XML- Dokumente benutzt werden, auch XML-Schemabeschreibungen verarbeiten können. Drittens sind alle DTD-Elemente immer gezwungen, die spezifizierte Ordnung des Dokuments einzuhalten, was bedeutet, dass ungeordnete Elemente unzulässig sind. Diese Nachteile führten zur Entwicklung von XML-Schema, einer generelleren Sprache zur Spezifikation der Struktur und Elemente von XML-Dokumenten XML-Schema Die XML-Schemasprache ist ein Standard zur Spezifikation der Struktur von XML- Dokumenten. Sie benutzt die gleichen Syntaxregeln wie reguläre XML-Dokumente, so dass die gleichen Prozessoren für beides benutzt werden können. Um die beiden Dokumenttypen zu unterscheiden, verwenden wir den Begriff XML-Instanzdokument oder kurz XML-Dokument für ein reguläres XML-Dokument und XML-Schemadokument für ein Dokument, das ein XML-Schema spezifiziert. Abbildung 1.5 zeigt ein XML-Schemadokument, das der Datenbank FIRMA aus den Abbildungen 3.2 und 7.5 entspricht. Obwohl es unwahrscheinlich ist, dass man die ganze Datenbank als ein einziges Dokument anzeigen möchte, wurden als Alternative zur Datenspeicherung in relationalen Datenbanken Vorschläge ausgearbeitet, um Daten im nativen XML- Format zu speichern. Das Schema in Abbildung 1.5 würde dazu dienen, die Struktur der FIRMA-Datenbank zu spezifizieren, wenn man sie in einem nativen XML-System speichern will. Dieses Thema wird ausführlicher in Abschnitt 1.4 behandelt.

11 1.3 XML-Dokumente, -DTD und -Schema 11 Abbildung 1.5: Eine XML-Schemadatei namens FIRMA. <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="en">firma-schema (Element-Ansatz) - erstellt von Babak Hojabri</xsd:documentation> </xsd:annotation> <xsd:element name="firma"> <xsd:complextype> <xsd:sequence> <xsd:element name="abteilung" type="abteilung" minoccurs="0" maxoccurs="unbounded" /> xsd:element name="angestellter" type="angestellter" minoccurs="0" maxoccurs="unbounded"> xsd:unique name="angehörigernameunique"> <xsd:selector xpath="angehöriger_von" /> <xsd:field xpath="angehörigername" /> </xsd:unique> </xsd:element> <xsd:element name="projekt" type="projekt" minoccurs="0" maxoccurs="unbounded" /> </xsd:sequence> </xsd:complextype> <xsd:unique name="abteilungnameunique"> <xsd:selector xpath="abteilung" /> <xsd:field xpath="abteilungname" /> </xsd:unique> xsd:unique name="projektnameunique"> <xsd:selector xpath="projekt" /> <xsd:field xpath="projektname" /> </xsd:unique> <xsd:key name="projektnummerkey"> <xsd:selector xpath="projekt" /> <xsd:field xpath="projektnummer" /> </xsd:key> xsd:key name="abteilungnummerkey"> <xsd:selector xpath="abteilung" /> <xsd:field xpath="abteilungnummer" /> </xsd:key> xsd:key name="angestellterssnkey"> <xsd:selector xpath="angestellter" /> <xsd:field xpath="angestellterssn" /> </xsd:key>

12 12 Zusatzkapitel 1 XML und Internet-Datenbanken Abbildung 1.5: Eine XML-Schemadatei namens FIRMA (Fortsetzung). <XSD:keyred name="abteilungmanagerssnkeyref" refer="angestellterssnkey"> <xsd:selector xpath="abteilung" /> <xsd:field xpath="abteilungmanagerssn" /> </xsd:keyref> <xsd:keyref name="angestellterabteilungnummerkeyref" refer="abteilungnummerkey"> <xsd:selector xpath="angestellter" /> <xsd:field xpath="angestellterabteilungnummer" /> </xsd:keyref> <xsd:keyref name="angestelltervorgesetzterssnkeyref" refer="angestellterssnkey"> <xsd:selector xpath="angestellter" /> <xsd:field xpath="angestelltervorgesetzterssn" /> </xsd:keyref> <xsd:keyref name="projektabteilungnummerkeyref" refer="abteilungnummerkey"> <xsd:selector xpath="projekt" /> <xsd:field xpath="projektabteilungnummer" /> </xsd:keyref> </xsd:keyref name="projectworkerssnkeyref" refer="angestellterssnkey"> <xsd:selector xpath="projekt/projektmitarbeiter" /> <xsd:field xpath="ssn" /> </xsd:keyref> <xsd:keyref name="angestellterarbeitet_anprojektnummerkeyref" refer="projektnummerkey"> <xsd:selector xpath="angestellter/angestellterarbeitet_an" /> <xsd:field xpath="projektnummer" /> </xsd:keyref> </xsd: element> <xsd:complextype name="abteilung"> <xsd:sequence> <xsd:element name="abteilungname" type="xsd:string" /> <xsd:element name="abteilungnummer" type="xsd:string" /> <xsd:element name="abteilungmanagerssn" type="xsd:string" /> <xsd:element name="abteilungmanageranfangsdatum" type="xsd:date" /> <xsd:element name="abteilungstandort" type="xsd:string" /> minoccurs="0" maxoccurs="unbounded" /> </xsd:sequence> </xsd:complextype>

13 1.3 XML-Dokumente, -DTD und -Schema 13 Abbildung 1.5: Eine XML-Schemadatei namens FIRMA (Fortsetzung). <xsd:complextype name="angestellter"> <xsd:sequence> xsd:element name="angestelltername" type="name" /> <xsd:element name="angestellterssn" type="xsd:string" /> <xsd:element name="angestelltergeschlecht" type="xsd:string" /> <xsd:element name="angestelltergehalt" type="xsd:unsignedint" /> <xsd:element name="angestelltergdatum" type="xsd:date" /> <xsd:element name="angestellterabteilungnummer" type="xsd:string" /> <xsd:element name="angestelltervorgesetzterssn" type="xsd:string" /> <xsd:element name="angestellteradresse" type="adresse" /> <xsd:element name="angestellterarbeitet_an" type="arbeitet_an" minoccurs="1" maxoccurs="unbounded" /> <xsd:element name="angestellterangehöriger" type="angehöriger" minoccurs="0" maxoccurs="unbounded" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="projekt"> <xsd:sequence>< xsd:element name="projektname" type="xsd:string" /> <xsd:element name="projektnummer" type="xsd:string" /> <xsd:element name="projektstandort" type="xsd:string" /> <xsd:element name="projektabteilungnummer" type="xsd:string" /> <xsd:element name="projektmitarbeiter" type="mitarbeiter" minoccurs="1" maxoccurs="unbounded" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="angehöriger"> <xsd:sequence> <xsd:element name="angehörigername" type="xsd:string" /> <xsd:element name="angehörigergeschlecht" type="xsd:string" /> <xsd:element name="angehörigergdatum" type="xsd:date" /> <xsd:element name="angehörigergrad" type="xsd:string" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="adresse"> <xsd:sequence> <xsd:element name="hausnr" type="xsd:string" /> <xsd:element name="strasse" type="xsd:string" /> <xsd:element name="ort" type="xsd:string" /> <xsd:element name="land" type="xsd:string" /> </xsd:sequence> </xsd:complextype>

14 14 Zusatzkapitel 1 XML und Internet-Datenbanken Abbildung 1.5: Eine XML-Schemadatei namens FIRMA (Fortsetzung). <xsd:complextype name="name"> <xsd:sequence> <xsd:element name="vorname" type="xsd:string" /> <xsd:element name="initial" type="xsd:string" /> <xsd:element name="nachname" type="xsd:string" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="mitarbeiter"> <xsd:sequence> <xsd:element name="ssn" type="xsd:string" /> <xsd:element name="stunden" type="xsd:float" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="arbeitet_an"> <xsd:sequence> <xsd:element name="projektnummer" type="xsd:string" /> <xsd:element name="stunden" type="xsd:float" /> </xsd:sequence> </xsd:complextype> </xsd:schema> Wie XML-DTD basiert auch XML-Schema auf dem Baumdatenmodell mit Elementen und Attributen als wichtigste Strukturierungskonzepte. Allerdings entlehnt es zusätzliche Konzepte von Datenbank- und Objektmodellen, wie z. B. Schlüssel, Referenzen und Identifizierer. Wir beschreiben hier die Merkmale von XML-Schema schrittweise und beziehen uns der besseren Anschaulichkeit halber auf das Beispiel eines XML- Schemadokuments von Abbildung 1.5. Außerdem beschreiben wir einige Schemakonzepte in der Reihenfolge, in der sie in Abbildung 1.5 vorkommen. 1. Schemabeschreibungen und XML-Namensräume: Die spezifische zu benutzende Menge von XML-Schemasprachelementen (Tags) muss identifiziert werden, indem man eine am Standort der Website gespeicherte Datei spezifiziert. Die zweite Zeile in Abbildung 1.5 spezifiziert die in diesem Beispiel benutzte Datei, d. h. " Das ist der am häufigsten benutzte Standard für XML-Schemabefehle. Jede dieser Definitionen wird als XML- Namensraum bezeichnet, weil sie die verfügbare Befehlsmenge (Namensmenge) definiert. Der Dateiname wird der Variablen xsd (XML-Schemabeschreibung) mit Hilfe des Attributs xmlns (XML-Namensraum) zugewiesen. Diese Variable wird als Präfix für alle XML-Schemabefehle (Tag-Namen) benutzt. Wenn wir beispielsweise in Abbildung 1.5 xsd:element oder xsd:sequence schreiben, beziehen wir uns auf die Definitionen des Tags element bzw. sequence gemäß Definition in der Datei " 2. Annotationen, Dokumentation und benutzte Sprache: Die nächsten beiden Zeilen in Abbildung 1.5 illustrieren die XML-Schemaelemente (Tags) xsd:annotation und xsd:documentation, die zur Bereitstellung von Kommentaren und anderen Beschreibungen im XML-Dokument benutzt werden. Das Attribut xml:lang des

15 1.3 XML-Dokumente, -DTD und -Schema 15 Elements xsd:documentation spezifiziert die zu benutzende Sprache, wobei "en" für Englisch steht. 3. Elemente und Typen: Als Nächstes spezifizieren wir das Wurzelelement unseres XML-Schemas. In XML-Schema spezifiziert das Attribut name des Tags xsd:element den Elementnamen in unserem Beispiel Firma (siehe Abbildung 1.5). Anschließend wird die Struktur des Wurzelelements Firma spezifiziert in unserem Beispiel xsd:complextype. Die Spezifikation der Struktur xsd:sequence des XML-Schemas wird fortgesetzt, um eine Folge von Abteilungen, Mitarbeitern und Projekten zu erhalten. Wichtig ist hier die Feststellung, dass dies nicht die einzige Möglichkeit ist, ein XML-Schema für die Firma-Datenbank zu spezifizieren. Weitere Möglichkeiten werden in Abschnitt 1.4 behandelt. 4. Elemente der ersten Ebene in der Firma-Datenbank: Als Nächstes spezifizieren wir die drei Elemente der ersten Ebene unter dem Wurzelelement in Abbildung 1.5. Diese Elemente heißen Mitarbeiter, Abteilung und Projekt und wurden jeweils in einem xsd:element-tag spezifiziert. Man beachte: Wenn ein Tag nur Attribute und keine weiteren Subelemente oder Daten enthält, kann es direkt mit einem Schrägstrich (/>) statt einem separaten passenden End-Tag beendet werden. Das sind so genannte leere Elemente; Beispiele sind die xsd:element-elemente namens Abteilung und Projekt in Abbildung Spezifizierung des Elementtyps sowie minimale und maximale Vorkommen: In XML- Schema spezifizieren die Attribute type, minoccurs und maxoccurs im Tag xsd:element den Typ und die Häufigkeit jedes Elements in einem Dokument, das mit den Schemaspezifikationen konform ist. Wenn wir ein type-attribut in einem xsd:element spezifizieren, muss die Struktur des Elements separat beschrieben werden, typischerweise mit Hilfe des xsd:complextype-elements von XML-Schema. In Abbildung 1.5 wären das die Elemente Mitarbeiter, Abteilung und Projekt. Wird andererseits kein type-attribut spezifiziert, kann die Elementstruktur direkt nach dem Tag definiert werden, wie im Firma-Wurzelelement in Abbildung 1.5 ersichtlich ist. Die Tags minoccurs und maxoccurs werden zur Spezifikation einer Oberund Untergrenze für die Vorkommen eines Elements in einem Dokument, das mit den Schemaspezifikationen konform ist, benutzt. Werden sie nicht spezifiziert, ist das Default genau ein Vorkommen. Sie erfüllen eine ähnliche Rolle wie die Symbole *, + und? in XML-DTD und die (min-, max-)einschränkungen des ER- Modells (siehe Abschnitt 3.7.4). 6. Spezifizierung von Schlüsseln: In XML-Schema können Einschränkungen spezifiziert werden, die den eindeutigen und Primärschlüsseleinschränkungen einer relationalen Datenbank (siehe Abschnitt 7.2.2) bzw. Fremdschlüssel- oder Integritätseinschränkungen (siehe Abschnitt 7.2.4) entsprechen. Das Tag xsd:unique spezifiziert Elemente, die den eindeutigen Attributen einer relationalen Datenbank, die keine Primärschlüssel sind, entsprechen. Wir können jeder Eindeutigkeitseinschränkung dieser Art einen Namen geben. Außerdem müssen wir dafür xsd:selector- und xsd:field-tags spezifizieren, um den Elementtyp, in dem sich das eindeutige Element befindet, und den darin enthaltenen Elementnamen, der durch das xpath-attribut eindeutig ist, zu identifizieren. Ein Beispiel dafür sind die Elemente AbteilungNameUnique und ProjektNameUnique in Abbildung 1.5. Zum Spezifizieren von Primärschlüsseln wird das Tag xsd:key statt xsd:unique benutzt; siehe als Beispiel die Elemente ProjektNummerKey, AbteilungNummerKey und

16 16 Zusatzkapitel 1 XML und Internet-Datenbanken AngestellterSSNKey in Abbildung 1.5. Zum Spezifizieren von Fremdschlüsseln wird das Tag xsd:keyref benutzt, wie bei den sechs xsd:keyref-elementen in Abbildung 1.5. In der Spezifikation eines Fremdschlüssels spezifiziert das Attribut refer des Tags xsd:keyref den referenzierten Primärschlüssel, während die Tags xsd:selector und xsd:field den referenzierenden Elementtyp und Fremdschlüssel spezifizieren (siehe Abbildung 1.5). 7. Spezifizierung der Strukturen komplexer Elemente mittels komplexer Typen: Der nächste Teil unseres Beispiels spezifiziert die Strukturen der komplexen Elemente Abteilung, Mitarbeiter, Projekt und Angehöriger mit Hilfe des Tags xsd:complextype (siehe Abbildung 1.5). Wir spezifizieren sie alle als Folge von Subelementen entsprechend den Datenbankattributen jedes Entitätstyps (siehe Abbildungen 3.2 und 7.7). Hierfür verwenden wir die Tags xsd:sequence und xsd:element von XML-Schema. Jedes Element wird mit Hilfe der Attribute name und type von xsd:element mit einem Namen und einem Typ versehen. Wir können auch die Attribute minoccurs und maxoccurs spezifizieren, wenn wir den Vorgabewert (genau ein Vorkommen) ändern müssen. Für (optionale) Datenbankattribute, für die null erlaubt ist, müssen wir minoccurs = 0 spezifizieren, während wir bei mehrwertigen Datenbankattributen für das jeweilige Element maxoccurs = "unbounded" spezifizieren müssen. Man beachte: Wenn wir keine Schlüsseleinschränkungen spezifizieren, können wir stattdessen die Subelemente direkt in die Elternelementdefinitionen einbetten, ohne komplexe Typen spezifizieren zu müssen. Wenn aber eindeutige, Primärschlüssel- und Fremdschlüsseleinschränkungen zu spezifizieren sind, dann müssen wir bei der Spezifikation der Elementstrukturen komplexe Typen definieren. 8. Zusammengesetzte Attribute: Auch zusammengesetzte Attribute aus Abbildung 3.2 werden in Abbildung 1.5 als komplexe Typen spezifiziert, wie aus den komplexen Typen Adresse, Name, Mitarbeiter und Arbeitet_an ersichtlich ist. Alternativ hätte man sie direkt in ihre Elternelemente einbetten können. Dieses Beispiel verdeutlicht einige wichtige Merkmale von XML-Schema. Es gibt noch weitere Merkmale, die jedoch über Zweck und Umfang dieses Buchs hinausgehen. Im nächsten Abschnitt werden die verschiedenen Methoden behandelt, wie man XML- Dokumente aus relationalen Datenbanken erstellt und speichert. 1.4 XML-Dokumente und Datenbanken In diesem Abschnitt wird erklärt, wie verschiedene Arten von XML-Dokumenten gespeichert und eingelesen werden können. Abschnitt enthält eine Übersicht über die verschiedenen Methoden zum Speichern von XML-Dokumenten. In Abschnitt wird eine dieser Methoden, bei der datenzentrische XML-Dokumente aus existierenden Datenbanken extrahiert werden, ausführlicher erklärt. Insbesondere zeigen wir, wie baumstrukturierte Dokumente aus graphenstrukturierten Datenbanken erstellt werden können. Abschnitt handelt von dem Zyklenproblem und wie es behandelt werden kann.

17 1.4 XML-Dokumente und Datenbanken Methoden zum Speichern von XML-Dokumenten Mehrere Methoden zur Organisation des Inhalts von XML-Dokumenten wurden vorgeschlagen, um die anschließende Anfrage und das Retrieval zu vereinfachen. Die häufigsten Methoden sind wie folgt: 1. Verwendung eines DBMS, um die Dokumente als Text zu speichern: Ein relationales oder Objekt-DBMS kann benutzt werden, um ganze XML-Dokumente als Textfelder in den DBMS-Datensätzen oder -Objekten zu speichern. Diese Methode eignet sich, wenn das DBMS über ein spezielles Modul zur Dokumentverarbeitung verfügt, um schemalose und dokumentzentrische XML-Dokumente zu speichern. Die Funktionen zur Schlüsselwortindexierung des Dokumentverarbeitungsmoduls (siehe Kapitel 24) können herangezogen werden, um die Suche und das Retrieval von Dokumenten zu indexieren und zu beschleunigen. 2. Verwendung eines DBMS, um die Dokumentinhalte als Datenelemente zu speichern: Diese Methode eignet sich zum Speichern von Dokumenten, die mit einer spezifischen XML-DTD oder einem XML-Schema konform sind. Da alle Dokumente die gleiche Struktur aufweisen, kann man eine relationale oder Objekt-Datenbank entwerfen, um die Datenelemente der Blattebene in den XML-Dokumenten zu speichern. Bei dieser Methode sind Abbildungsalgorithmen für den Entwurf eines Datenbankschemas, das mit der XML-Dokumentstruktur gemäß Spezifikation im XML-Schema oder in der XML-DTD kompatibel ist, und für die Wiederherstellung der XML-Dokumente aus den gespeicherten Daten erforderlich. Diese Algorithmen können entweder als internes DBMS-Modul oder als separate Middleware, die nicht Teil des DBMS ist, implementiert werden. 3. Entwurf eines spezialisierten Systems zum Speichern nativer XML-Daten: Man könnte eine neue Art von Datenbanksystem auf der Grundlage des hierarchischen bzw. Baummodells entwerfen und implementieren. Das System würde spezialisierte Indexier- und Anfragetechniken beinhalten und für alle Arten von XML-Dokumenten funktionieren. Es könnte auch Datenkompressionstechniken beinhalten, um den Speicherplatzbedarf der Dokumente zu reduzieren. 4. Erstellen oder Publizieren angepasster XML-Dokumente aus vorhandenen relationalen Datenbanken: Da in relationalen Datenbanken enorme Datenmengen gespeichert sind, müssen möglicherweise Teile dieser Daten als Dokumente für den Austausch oder die Anzeige im Web formatiert werden. Bei dieser Methode würde man eine separate Middleware-Softwareschicht benutzen, um die zwischen den XML-Dokumenten und der relationalen Datenbank nötigen Konvertierungen zu behandeln. Alle vier Methoden haben in den letzten Jahren beträchtliche Aufmerksamkeit erlangt. Wir konzentrieren uns im nächsten Unterabschnitt auf Methode 4, weil sie die Unterschiede zwischen dem XML-Baumdatenmodell und den traditionellen Datenbankmodellen, die auf flachen Dateien (relationales Modell) und Graphendarstellungen (ER-Modell) basieren, gut verständlich macht.

18 18 Zusatzkapitel 1 XML und Internet-Datenbanken XML-Dokumente aus relationalen Datenbanken extrahieren In diesem Abschnitt beschreiben wir die Darstellungsproblematik, die entsteht, wenn man Daten aus einem Datenbanksystem in XML-Dokumente konvertiert. Wie bereits erwähnt, benutzt XML ein hierarchisches bzw. Baummodell zur Darstellung von Dokumenten. Die meisten gebräuchlichen Datenbanksysteme basieren demgegenüber auf dem flachen relationalen Datenmodell. Wenn man referenzielle Integritätseinschränkungen dazunimmt, lässt sich ein relationales Schema als Graphenstruktur betrachten (siehe als Beispiel Abbildung 7.7). Ähnlich stellt das ER-Modell Daten in graphenähnlichen Strukturen dar (siehe als Beispiel Abbildung 3.2). Wir wissen aus Kapitel 9, dass es umkomplizierte Abbildungen (Mappings) zwischen ER- und relationalen Modellen gibt, so dass wir ein relationales Datenbankschema mit Hilfe des entsprechenden ER-Schemas konzeptionell darstellen können. Obwohl wir in unserer Diskussion das ER-Modell mit Beispielen heranziehen, um die konzeptionellen Unterschiede zwischen Baum- und Graphenmodellen zu erklären, gilt das Gleiche auch für die Konvertierung relationaler Daten in XML. Anhand des vereinfachten ER-Schemas UNIVERSITY in Abbildung 1.6 wollen wir unsere Diskussion illustrieren. Es sei gegeben, dass eine Anwendung XML-Dokumente mit Informationen über Studenten, Kurse und Noten aus der UNIVERSITY- Datenbank (siehe Abschnitt 1.2) extrahieren muss. Die für diese Dokumente benötigten Daten sind in den Datenbankattributen der Entitätstypen COURSE, SECTION und STUDENT von Abbildung 1.6 sowie den zwischen ihnen vorhandenen Beziehungen S-S und C-S enthalten. Im Allgemeinen verwenden die meisten aus einer Datenbank extrahierten Dokumente nur eine Teilmenge der Attribute, Entitätstypen und Beziehungen der Datenbank. In diesem Beispiel ist die benötigte Teilmenge der Datenbank in Abbildung 1.7 dargestellt. Aus der Datenbankteilmenge von Abbildung 1.7 lassen sich mindestens drei mögliche Dokumenthierarchien extrahieren. Erstens können wir wie in Abbildung 1.8 COURSE als Wurzel wählen. Hier hat jede Kursentität die Menge ihrer Kursabschnitte (SECTIONS) als Subelemente, und jeder Kursabschnitt hat seine Studenten als Subelemente. Eine Konsequenz der Modellierung von Informationen in einer hierarchischen Baumstruktur lässt sich sofort erkennen. Hat ein Student mehrere Kursabschnitte belegt, kommen die Informationen dieses Studenten mehrmals im Dokument vor: einmal unter jedem Kursabschnitt. Abbildung 1.9 zeigt ein mögliches vereinfachtes XML-Schema für diesen View. Das Datenbankattribut grade in der S-S- Beziehung migrierte in das Element STUDENT, weil STUDENT in dieser Hierarchie ein Kind von SECTION wird. Das bedeutet, dass jedes STUDENT-Element unter einem bestimmten SECTION-Element einen spezifischen Grad im betreffenden Kursabschnitt haben kann. In dieser Dokumenthierarchie gibt es für einen Studenten, der mehr als einen Kursabschnitt belegt, mehrere Replikate (eines unter jedem Kursabschnitt), und jedes Replikat hat den spezifischen, in diesem bestimmten Kursabschnitt erteilten Grad. Im zweiten hierarchischen Dokument-View können wir STUDENT als Wurzel wählen (Abbildung 1.10). In diesem View hat jeder Student eine section-menge als Kindelemente, und jeder Kursabschnitt (section) hat einen course als Kind, weil die Beziehung zwischen SECTION und COURSE N:1 ist. Wie in Abbildung 1.10 können wir daher die Elemente COURSE und SECTION mischen. Darüber hinaus können wir das Datenbankattribut GRADE in das SECTION-Element migrieren lassen. In dieser Hierar-

19 1.4 XML-Dokumente und Datenbanken 19 Abbildung 1.6: ER-Schemadiagramm für eine vereinfachte UNIVERSITY-Datenbank. Abbildung 1.7: Teilmenge des UNIVERSITY-Datenbankschemas, die zur Extraktion von XML-Dokumenten benötigt wird. chie werden die kombinierten COURSE/SECTION-Daten unter jedem Student, der den Kursabschnitt abgeschlossen hat, repliziert. Ein mögliches vereinfachtes XML-Schema für diesen View ist in Abbildung 1.11 dargestellt. Die dritte Möglichkeit besteht in der Auswahl von SECTION als Wurzel wie in Abbildung Ähnlich wie im zweiten hierarchischen View können die COURSE-Daten in das SECTION-Element eingemischt werden. Das Datenbankattribut GRADE kann man in das Element STUDENT migrieren lassen. Wir sehen, dass es sogar bei diesem einfachen Beispiel zahlreiche hierarchische Dokument-Views geben kann, die jeweils eine andere Wurzel haben und einer anderen XML-Dokumentstruktur entsprechen.

20 20 Zusatzkapitel 1 XML und Internet-Datenbanken Abbildung 1.8: Hierarchischer (Baum-)View mit COURSE als Wurzel. Abbildung 1.9: XML-Schemadokument mit COURSE als Wurzel. <xsd:element name="root"> <xsd:sequence> <xsd:element name="course" minoccurs="0" maxoccurs="unbounded"> xsd:sequence> xsd:element name="cname" type="xsd:string" /> xsd:element name="cnumber" type="xsd:unsignedint" /> <xsd:element name="section" minoccurs="0" maxoccurs="unbounded"> xsd:sequence xsd:element name="secnumber" type="xsd:unsignedint" /> <xsd:element name="year" type="xsd:string" /> <xsd:element name="quarter" type="xsd:string" /> <xsd:element name="student" minoccurs="0" maxoccurs="unbounded"> <xsd:sequence> <xsd:element name="ssn" type="xsd:string" /> xsd:element name="sname" type="xsd:string" /> <xsd:element name="class" type="xsd:string" /> <xsd:element name="grade" type="xsd:string" /> </xsd:sequence> </xsd:element> </xsd:sequence> </xsd:element> </xsd:sequence> </xsd:element> </xsd:sequence> </xsd:element>