Oracle, PL/SQL und XML
Seiten
2008
|
1., Aufl.
Comelio (Verlag)
978-3-939701-10-1 (ISBN)
Comelio (Verlag)
978-3-939701-10-1 (ISBN)
- Titel ist leider vergriffen;
keine Neuauflage - Artikel merken
XML-Schnittstellen ersetzen allerorten Lösungen auf Basis von einfachen Textdateien oder Protokolldaten, Unternehmen gehen dazu über, semistrukturierte Daten direkt in einer (objekt)relationalen Datenbank zu speichern. Wenn Oracle im Einsatz ist, hat man eine vollwertige XML-Datenbank bereits zur Verfügung und kann aus einer Reihe von Werkzeugen für die Erzeugung, Speicherung, Abfrage und allgemein die Integration von XML-Daten in seine Datenlandschaft die beste Kombination auswählen. Dieses Buch stellt die Techniken von Oracle dar, wie in der Standard-DB oder in der speziellen XML DB (XDB) XML-Daten verwendet werden können. Dabei erläutert es die verschiedenen traditionellen und Oracle-spezifischen Speicheransätze sowie die vollständige relationale Zerlegung oder native Speicherung und Verarbeitung im XML-Datentyp XMLType genauso wie die Verarbeitung mit Hilfe von PL/SQL, die Erzeugung über SQL/XML und den Einsatz von Webservices. Das Buch fokussiert insbesondere den Aspekt der Errichtung von XML-fähigen Schnittstellen zwischen kooperierenden Systemen. Versionen: 9i, 10g und 11g.
XML aus relationalen Daten erzeugen und Import-/Export-Schnittstellen planen;
SQL/XML und PL/SQL für die Erzeugung und Verarbeitung von XML verwenden;
Einsatz von XML Schema zur Validierung und Erzeugung von XML;
XML-Daten in XMLType-/Objekt-Spalten und in der XML DB speichern;
Administrative Aspekte von XMLType und der XML DB; Datentyp XMLType und sein Einsatz;
Webservices mit PL/SQL und Oracle.
XML bietet eine Reihe von Vorteilen, welche die schnelle und umfassende Verbreitung sehr gefördert haben. Teilweise befürchten insbesondere Datenbankprogrammierer und Administratoren, XML könnte in irgendeiner Weise eine Datenbank ersetzen. Ab und an trifft man auch auf Verantwortliche, die eine solche Überlegung pflegen oder wenigstens grundsätzlich erwogen haben. Dazu wird es nicht kommen. Vielmehr haben sich, wie man in den letzten Jahren gut gesehen hat, die großen DB-Hersteller wie Oracle, Microsoft und IBM in ihren Datenbanksystemen einen neuen XML-Datentyp eingeführt, der es den DB-Produkten ermöglicht, sich diese neue Technologie der Datenspeicherung und –abbildung gleichfalls einzuverleiben. Zu den gerade genannten Vorteilen von XML im Gegensatz zu CSV und insbesondere sonstigen Protokollformaten zählen u.a. die folgenden:
Einfachheit: XML ist, wenn man sich grundlegend damit beschäftigt, ein sehr einfacher Standard, der durch die starke Verbreitung von HTML nur wenig Neues für HTML-versierte Entwickler bietet. Damit ist allerdings auch schon die erste Problemstelle aufgedeckt, denn mehr als die spitzen Klammern, die Verwendung von Attributen und der korrekten Verschachtelung haben HTML und XML nichts gemeinsam. Stattdessen dient XML dem allgemeinen Datenaustausch und der ebenso allgemeinen Datenmodellierung. Doch die Ähnlichkeit mit einer noch einfacheren Syntax und die gute Lesbarkeit von XML-Strukturen im Gegensatz zu Protokollen begünstigen eine starke und vor allen Dingen schnelle Verbreitung. HTML bzw. seine wohlgeformte Variante XHTML dagegen entspricht einer gegebenen Modellierung von Strukturen in XML, die für die Inhaltspräsenation in so genannten Browser-Programmen eingesetzt werden kann.
Vielseitiger Einsatz: Da – wie gerade schon erwähnt – XML für die Datenmodellierung und den Datenaustausch eingesetzt werden kann, ist es ebenso vielseitig verwendbar wie eine Datenbank. Praktisch überall dort, wo Daten anfallen, ausgetauscht und verarbeitet werden, lässt sich eine Lösung grundsätzlich auch in XML denken. Aus technischen Einschränkungen heraus oder aufgrund von zusätzlichen Anforderungen ist dies nicht immer die endgültige Wahl, doch ließe sich wenigstens eine Alternativ-Lösung in XML denken. Dies liegt nicht daran, dass XML besondere Fähigkeiten hat, sondern schlichtweg daran, dass es eine gute Möglichkeit ist, Daten zu verarbeiten. Nichtsdestotrotz wird man für allereinfachste Datenaustauschziele weiterhin auch kommagetrennte Werte verwenden oder aus XML heraus solche CSV-Werte erstellen oder den umgekehrten Weg beschreiten und aus CSV-Daten XML-Strukturen generieren müssen. Vielseitige Verwendung für Daten in Textform oder mit notwendigen Verschachtelungen und komplexen Strukturen, die in relationalen Datenbanken nicht akzeptabel abgebildet werden können, zeichnen XML aus. Gerade hinsichtlich des Datenaustauschs zwischen verschiedenen Datenbanken gibt es viele gemischte Lösungen, die gleichzeitig XML und Text in Form von CSV oder auch SQL verwenden. Dabei werden oft die verschiedenen Textformate aus XML-Srukturen heraus generiert.
Gute Lesbarkeit: Im Gegensatz zu kommagetrennten Werten oder gar Protokollen, welche Daten durch XML-ähnliche Steuerzeichen trennen, bietet XML im Normalfall eine schnell zu verstehende Lesbarkeit. Lange Dokumente oder tief verschachtelte Strukturen eignen sich zwar nicht notwendigerweise für eine direkte Lektüre ohne Transformation in ein tabellen- oder listenorientiertes Format, aber bei gut gewählten Bezeichnern und einem grundlegenden Verständnis des Themas oder der modellierten Datenstrukturen wird eine XML-Datei durch die Auszeichnung mit Hilfe der XML-Tags immer einfacher und besser zu lesen sein als kommagetrennte Werte ohne Auszeichnung oder Protokolldaten mit kryptischen Steuerzeichen. Ein frühes Gegenargument, das bei der Verwendung von XML auftauchte, beruhte darauf, dass durch die Auszeichnung der Daten sehr viel Speicherplatz einer Datei allein für die Datendarstellung und –aufbereitung verwendet wird. Dies ist unter den beiden Stichwörtern Nutzdaten und Beschreibungsdaten bekannt. Sind dazu diese Daten auch noch sehr kurz, kann der Fall eintreten, dass sogar mehr Dateispeicherplatz für die XML-Strukturen verwendet wird als für die eigentlichen Daten. Dies sollte allerdings bei heutiger Festplattengröße sowie Netzwerkübertragungsgeschwindigkeit einen zu vernachlässigenden Aspekt darstellen. XML-Daten sind natürlich nur dann gut lesbar, wenn die XML-Tags, welche die Daten auszeichnen, für den Leser verständlch sind. Gerade in speziellen Anwendungen im Finanz-, Wissenschafts- oder Technikbereich benötigt ein dem Gebiet grundsätzlich fern stehender Leser dann eine entsprechende Übersetzungshilfe. Es entfällt allerdings das bei CSV-Daten übliche Zählen (und vor allen Dingen Verzählen) von Positionen, was gerade bei breiten Strukturen mit vielen einzelnen Feldern Hürden für die Datenzugänglichkeit aufbaut.
Standardisierung: Protokolldaten in unterschiedlichen Systemen bzw. Industriezweigen beruhten und beruhen natürlich auch heute noch auf Standardisierungsabkommen zwischen Unternehmen und Organisationen. XML oder das W3C bieten auch keine Möglichkeiten, Datenstrukturen für jedweden Einsatzbereich einfach von der W3C-Webseite herunterzuladen und direkt weiterzuverwenden, aber der Grundansatz und das theoretische Fundament von XML sowie angrenzende Technologien wie XML Schema, XSLT, RDF oder XML Topic Maps liegen jeweils als Standards vor. Viele Industriezweige besitzen Schemata für ihre Datenstrukturen, welche weit verbreitet sind und sich auch gut verwenden lassen. Im Gegensatz zu Protokollen, in denen zumindest dieser Zustand auch vorherrscht(e), bietet die Verwendung von XML mit XSLT eine wirklich sehr einfache Möglichkeit, Daten auszutauschen und in andere Formate zu transformieren bzw. über das gesamte Namensraumkonzept auch Daten mit gleicher Auszeichnung oder fremden Strukturen zu mischen und weiterhin getrennt zu adressieren und zu verarbeiten. Die Vorteile der Standardisierung bei XML liegen also im Wesentlichen nicht darin, dass es eine große Auswahl an Standard-Schemata gibt, sondern vielmehr, dass die Grundkonzeption (XML selbst), die einfache Datenmodellierung (XML Schema), die semantische Datenmodellierung (RDF, XTM, OWL), die Adressierung (XPath, XQL) sowie die Transformation (XSLT, XSL-FO) herstellerungebunden vom W3C durchgeführt werden. Die Herstellerungebundenheit darf natürlich nicht überschätzt werden, weil die bedeutenden IT-Unternehmen mit entsprechender Marktmacht selbstverständlich alle auch im W3C Mitglied sind und dort auch Einfluss ausüben. Doch zumindest handelt es sich um ein Gremium, das nicht durch schiere Marktmacht dominiert wird, sondern seine Entscheidungen in einem Prozess trifft, in dem viele Parteien eingebunden sind. Neben dieser Standardisierung, welche die Basisarchitektur und damit die allgemeinen Bereiche Modellierung, Validierung, Abfrage und Umwandlung betrifft, gibt es eine Reihe von Versuchen, für bestimmte Sinnzusammenhänge Referenzmodelle und sogar feste Standards zu etablieren, welche den Datenaustausch noch weiter vereinfachen, da eine Umwandlung komplett entfällt. Man kann nicht erwarten, dass jeder Datenbereich überhaupt beschrieben wurde oder gar so gut modelliert wurde, dass die Modellierung exakt für das eigene Problem genutzt werden kann. Doch lohnt sich immer die Überlegung, ob möglicherweise ein solcher Standard existiert, um wenigstens Anregungen und Denkanstöße zu erhalten. Teilweise droht man allerdings auch, das Rad neu zu erfinden, sodass eine Kontrolle, ob ein Modellierungsversuch vorliegt, teilweise auch zu der Erkenntnis führt, dass andere Organisationen (Unternehmen, Regierungen und sonstige Körperschaften) bereits umfangreiche Modellierungsarbeiten geleistet haben und daher die Entscheidung, einen eigenen Weg zu gehen, bereits erfordert, für dieses Verhalten eine gute Begründung zu finden.
Das erste Kapitel stellt als Einstiegskapitel XML-Technologien allgemein mit den Daten der Beispieldatenbank dar. Es startet mit der klassischen DTD (Document Type Definition) als erster Modellierungs- und Beschreibungstechnik für XML-Daten und stellt dann auf Basis der Technik der DTD die Unterschiede, Vorteile und neuartigen Ansätze von XML Schema dar. XML Schema ist auch die Technologie, mit der in Oracle XML-Daten beschrieben und validiert werden können, wenn man sich dafür entscheidet, typisiertes XML zu verwenden und nicht einfach beliebige XML-Strukturen zuzulassen. Für die Abfrage von XML-Daten folgen dann die Pfadbeschreibungssprache XPath und die relativ komplexe Abfragesprache XQuery. Mit XPath ist es möglich, innerhalb von XML-Dokumenten zu navigieren und entweder vom Wurzelelement oder jedem beliebigen Knoten aus andere Knoten zu lokalisieren, zu filtern und eine Reihe von Funktionen einzusetzen. Die XPath-Ausdrücke können in SQL eingesetzt werden, um Teile von XML-Daten abzurufen oder komplexe Filter vorzugeben. Man setzt diese Technik allerdings auch in XML Schema für die Angabe von Schlüsseln und Fremdschlüsseln ein. Die Umwandlung von XML-Daten mit Hilfe des DOM (Document Object Model) und XSLT (eXtensible Stylesheet Language for Transformations) lässt sich ebenso einsetzen. Es dient in vielen Anwendungen als Ausdruckssprache, um dem Benutzer komplexe Filter oder Bedingungen zu ermöglichen. XQuery dagegen kombiniert Filterung und Auswahl mit einer verkürzten und nicht XML-basierten Syntax, um die gefundenen Strukturen auch unmittelbar wieder in XML umzuwandeln. Während XPath eine Ergebnismenge mit unterschiedlichen Inhalten in Form von Knoten, Knotensätzen oder Zeichenketten und Zahlen liefert, kann man mit XQuery unmittelbar ein XML-Ergebnis erzeugen. Schließlich stellt dieses Kapitel noch die Technik XSLT vor, mit der es möglich ist, neue Dokumente in Form von XML, HTML oder Text zu erzeugen. Dabei setzt man eine programmiersprachenähnliche Syntax in XML-Form ein, die man als deklarative Sprache bezeichnet.
Das zweite Kapitel beschreibt, wie eine der wesentlichen Anforderungen beim XML-Einsatz in Oracle umgesetzt wird: den Datenabruf von relationalen Daten und die Erzeugung von XML-Ausgabedaten in einer ad-hoc-Abfrage oder einer Sicht. Oracle bietet in diesem Bereich verschiedene Möglichkeiten, die sich hinsichtlich Geschwindigkeit und Komplexität der Formulierung unterscheiden. In diesem Kapitel lernt man sowol die Techniken kennen, die sofort aus einer SQL-Abfrage heraus XML erzeugen, wie auch die Durchführung der gleichen Aufgabenstellung in PL/SQL.
Das dritte Kapitel konzentriert sich ganz auf PL/SQL und die Verarbeitung von XML. Hier gibt es eine Vielzahl an möglichen Techniken, von denen insbesondere die beiden W3C-Techniken DOM und XSLT ins Auge fallen, die in PL/SQL genauso umgesetzt sind wie in vielen anderen Programmiersprachen. Dazu gibt es allerdings auch eine Reihe von PL/SQL-Paketen, die entweder für den Einsatz der beiden genannten Standardtechnologien notwendig sind, oder die ein eigenes Angebot bieten, mit XML-Daten zu arbeiten, sie zu manipulieren und sie umzuwandeln.
Das vierte Kapitel stellt den Fokus auf das wichtige Thema Import und Export ein. Es gibt eine Reihe von traditionellen und nicht nur in Oracle einsetzbaren Techniken, mit XML umzugehen und insbesondere XML somit relational oder objektrelational zu zerlegen, sodass man noch nicht direkt XML in einer traditionellen Datenbank speichern muss. Das Kapitel diskutiert verschiedene Speicheransätze, in denen XML relational zerlegt wird oder in denen mehr oder weniger große Teile in speziellen Datentypen und selbstverständlich auch den XML-Datentyp gespeichert werden. Die Erläuterungen in diesem Kapitel sollen eine Sensibilität für den großen Gestaltungsspielraum bewirken, mit der dann in der konkreten Modellierungssituation eine passende Variante ausgewählt wird.
Das fünfte Kapitel setzt die Überlegungen des vierten Kapitels insoweit fort, als dass die Oracle XDB (XML Datenbank) als eigenständige Möglichkeit zur direkten, nativen und nicht auf Tabellen basierenden Speicherung von XML-Daten (Dateien, Dokumenten) vorgeführt wird. Für dokumentenorientierte Systeme (Redaktionssysteme, Archive) ist dies eine geeignete Möglichkeit, mit Oracle eine XML-Datenbank im ursprünglichen Sinne aufzubauen und eine Reihe von Oracle-Techniken für Sicherheit und Geschwindigkeit zu verwenden und sich darüber hinaus in der gewohnten Umgebung zu bewegen.
Das sechste Kapitel rückt den wesentlichen Datentyp, mit dem die XML-Verwendung in Oracle mit PL/SQL und SQL überhaupt erst denkbar ist, in den Mittelpunkt: XMLType. Im Gegensatz zu einer langen Zeichenkette oder einem großen Binärobjekt erlaubt XMLType die Abfrage und Filterung mit XPath und XQuery, die Umwandlung mit XSLT, die Validierung mit XML Schema sowie die Verarbeitung mit einer Reihe von speziellen SQL-Funktionen und PL/SQL-Paketen. Seine Fähigkeiten sind schon in den vorherigen Kapiteln immer mal wieder in Beispielen vorgeführt worden, doch im sechsten Kapitel erhält XML Type eine Bühne, in der die verschiedenen Möglichkeiten gesammelt, dargestellt und zusammengefasst werden.
Das siebte Kapitel schließt das Buch mit dem neu in Oracle 11g eingeführten Thema Webservices ab. Es beginnt mit einer Einführung in den Grundgedanken, der hinter dem Themenkomplex serviceorientierte Anwendungsentwicklung und verteilte Software steht und beschreibt dann kurz Einsatzbereiche sowie die beiden entscheidenden Standards, die auch in Oracle zum Einsatz kommen. Neben XML Schema, das auch für die Validierung der zwischen Service und Klient ausgetauschten XML-Nachrichten Verwendung findet und bereits eingeführt wurde, handelt es sich dabei um die Standards WSDL (WebServices Description Language) und SOAP (Akronym ohne offizielle Auflösung). WSDL-Dokumente beschreiben in technischer und inhaltlicher Sicht einen Webdienst, werden typischerweise vom Server generiert und in Klienten-Programmen verwendet, um die Struktur von Nachrichten und Kommunikationsadressen auszulesen und korrekt zu verwenden. In vielen Programmiersprachen stehen auf Basis dieser Datei Hilfsmittel zur Verfügung, die Nachrichten nicht direkt in XML, sondern vielmehr in Form von Methoden/Funktionen aufzurufen und so den Webdienst quasi in die eigene Anwendung zu integrieren. SOAP dagegen ist ein einfaches XML-Format, welches Nachrichten sammelt und sie im Wesentlichen in einen strukturierten Kopf- und Hauptabschnitt unterteilt.
XML aus relationalen Daten erzeugen und Import-/Export-Schnittstellen planen;
SQL/XML und PL/SQL für die Erzeugung und Verarbeitung von XML verwenden;
Einsatz von XML Schema zur Validierung und Erzeugung von XML;
XML-Daten in XMLType-/Objekt-Spalten und in der XML DB speichern;
Administrative Aspekte von XMLType und der XML DB; Datentyp XMLType und sein Einsatz;
Webservices mit PL/SQL und Oracle.
XML bietet eine Reihe von Vorteilen, welche die schnelle und umfassende Verbreitung sehr gefördert haben. Teilweise befürchten insbesondere Datenbankprogrammierer und Administratoren, XML könnte in irgendeiner Weise eine Datenbank ersetzen. Ab und an trifft man auch auf Verantwortliche, die eine solche Überlegung pflegen oder wenigstens grundsätzlich erwogen haben. Dazu wird es nicht kommen. Vielmehr haben sich, wie man in den letzten Jahren gut gesehen hat, die großen DB-Hersteller wie Oracle, Microsoft und IBM in ihren Datenbanksystemen einen neuen XML-Datentyp eingeführt, der es den DB-Produkten ermöglicht, sich diese neue Technologie der Datenspeicherung und –abbildung gleichfalls einzuverleiben. Zu den gerade genannten Vorteilen von XML im Gegensatz zu CSV und insbesondere sonstigen Protokollformaten zählen u.a. die folgenden:
Einfachheit: XML ist, wenn man sich grundlegend damit beschäftigt, ein sehr einfacher Standard, der durch die starke Verbreitung von HTML nur wenig Neues für HTML-versierte Entwickler bietet. Damit ist allerdings auch schon die erste Problemstelle aufgedeckt, denn mehr als die spitzen Klammern, die Verwendung von Attributen und der korrekten Verschachtelung haben HTML und XML nichts gemeinsam. Stattdessen dient XML dem allgemeinen Datenaustausch und der ebenso allgemeinen Datenmodellierung. Doch die Ähnlichkeit mit einer noch einfacheren Syntax und die gute Lesbarkeit von XML-Strukturen im Gegensatz zu Protokollen begünstigen eine starke und vor allen Dingen schnelle Verbreitung. HTML bzw. seine wohlgeformte Variante XHTML dagegen entspricht einer gegebenen Modellierung von Strukturen in XML, die für die Inhaltspräsenation in so genannten Browser-Programmen eingesetzt werden kann.
Vielseitiger Einsatz: Da – wie gerade schon erwähnt – XML für die Datenmodellierung und den Datenaustausch eingesetzt werden kann, ist es ebenso vielseitig verwendbar wie eine Datenbank. Praktisch überall dort, wo Daten anfallen, ausgetauscht und verarbeitet werden, lässt sich eine Lösung grundsätzlich auch in XML denken. Aus technischen Einschränkungen heraus oder aufgrund von zusätzlichen Anforderungen ist dies nicht immer die endgültige Wahl, doch ließe sich wenigstens eine Alternativ-Lösung in XML denken. Dies liegt nicht daran, dass XML besondere Fähigkeiten hat, sondern schlichtweg daran, dass es eine gute Möglichkeit ist, Daten zu verarbeiten. Nichtsdestotrotz wird man für allereinfachste Datenaustauschziele weiterhin auch kommagetrennte Werte verwenden oder aus XML heraus solche CSV-Werte erstellen oder den umgekehrten Weg beschreiten und aus CSV-Daten XML-Strukturen generieren müssen. Vielseitige Verwendung für Daten in Textform oder mit notwendigen Verschachtelungen und komplexen Strukturen, die in relationalen Datenbanken nicht akzeptabel abgebildet werden können, zeichnen XML aus. Gerade hinsichtlich des Datenaustauschs zwischen verschiedenen Datenbanken gibt es viele gemischte Lösungen, die gleichzeitig XML und Text in Form von CSV oder auch SQL verwenden. Dabei werden oft die verschiedenen Textformate aus XML-Srukturen heraus generiert.
Gute Lesbarkeit: Im Gegensatz zu kommagetrennten Werten oder gar Protokollen, welche Daten durch XML-ähnliche Steuerzeichen trennen, bietet XML im Normalfall eine schnell zu verstehende Lesbarkeit. Lange Dokumente oder tief verschachtelte Strukturen eignen sich zwar nicht notwendigerweise für eine direkte Lektüre ohne Transformation in ein tabellen- oder listenorientiertes Format, aber bei gut gewählten Bezeichnern und einem grundlegenden Verständnis des Themas oder der modellierten Datenstrukturen wird eine XML-Datei durch die Auszeichnung mit Hilfe der XML-Tags immer einfacher und besser zu lesen sein als kommagetrennte Werte ohne Auszeichnung oder Protokolldaten mit kryptischen Steuerzeichen. Ein frühes Gegenargument, das bei der Verwendung von XML auftauchte, beruhte darauf, dass durch die Auszeichnung der Daten sehr viel Speicherplatz einer Datei allein für die Datendarstellung und –aufbereitung verwendet wird. Dies ist unter den beiden Stichwörtern Nutzdaten und Beschreibungsdaten bekannt. Sind dazu diese Daten auch noch sehr kurz, kann der Fall eintreten, dass sogar mehr Dateispeicherplatz für die XML-Strukturen verwendet wird als für die eigentlichen Daten. Dies sollte allerdings bei heutiger Festplattengröße sowie Netzwerkübertragungsgeschwindigkeit einen zu vernachlässigenden Aspekt darstellen. XML-Daten sind natürlich nur dann gut lesbar, wenn die XML-Tags, welche die Daten auszeichnen, für den Leser verständlch sind. Gerade in speziellen Anwendungen im Finanz-, Wissenschafts- oder Technikbereich benötigt ein dem Gebiet grundsätzlich fern stehender Leser dann eine entsprechende Übersetzungshilfe. Es entfällt allerdings das bei CSV-Daten übliche Zählen (und vor allen Dingen Verzählen) von Positionen, was gerade bei breiten Strukturen mit vielen einzelnen Feldern Hürden für die Datenzugänglichkeit aufbaut.
Standardisierung: Protokolldaten in unterschiedlichen Systemen bzw. Industriezweigen beruhten und beruhen natürlich auch heute noch auf Standardisierungsabkommen zwischen Unternehmen und Organisationen. XML oder das W3C bieten auch keine Möglichkeiten, Datenstrukturen für jedweden Einsatzbereich einfach von der W3C-Webseite herunterzuladen und direkt weiterzuverwenden, aber der Grundansatz und das theoretische Fundament von XML sowie angrenzende Technologien wie XML Schema, XSLT, RDF oder XML Topic Maps liegen jeweils als Standards vor. Viele Industriezweige besitzen Schemata für ihre Datenstrukturen, welche weit verbreitet sind und sich auch gut verwenden lassen. Im Gegensatz zu Protokollen, in denen zumindest dieser Zustand auch vorherrscht(e), bietet die Verwendung von XML mit XSLT eine wirklich sehr einfache Möglichkeit, Daten auszutauschen und in andere Formate zu transformieren bzw. über das gesamte Namensraumkonzept auch Daten mit gleicher Auszeichnung oder fremden Strukturen zu mischen und weiterhin getrennt zu adressieren und zu verarbeiten. Die Vorteile der Standardisierung bei XML liegen also im Wesentlichen nicht darin, dass es eine große Auswahl an Standard-Schemata gibt, sondern vielmehr, dass die Grundkonzeption (XML selbst), die einfache Datenmodellierung (XML Schema), die semantische Datenmodellierung (RDF, XTM, OWL), die Adressierung (XPath, XQL) sowie die Transformation (XSLT, XSL-FO) herstellerungebunden vom W3C durchgeführt werden. Die Herstellerungebundenheit darf natürlich nicht überschätzt werden, weil die bedeutenden IT-Unternehmen mit entsprechender Marktmacht selbstverständlich alle auch im W3C Mitglied sind und dort auch Einfluss ausüben. Doch zumindest handelt es sich um ein Gremium, das nicht durch schiere Marktmacht dominiert wird, sondern seine Entscheidungen in einem Prozess trifft, in dem viele Parteien eingebunden sind. Neben dieser Standardisierung, welche die Basisarchitektur und damit die allgemeinen Bereiche Modellierung, Validierung, Abfrage und Umwandlung betrifft, gibt es eine Reihe von Versuchen, für bestimmte Sinnzusammenhänge Referenzmodelle und sogar feste Standards zu etablieren, welche den Datenaustausch noch weiter vereinfachen, da eine Umwandlung komplett entfällt. Man kann nicht erwarten, dass jeder Datenbereich überhaupt beschrieben wurde oder gar so gut modelliert wurde, dass die Modellierung exakt für das eigene Problem genutzt werden kann. Doch lohnt sich immer die Überlegung, ob möglicherweise ein solcher Standard existiert, um wenigstens Anregungen und Denkanstöße zu erhalten. Teilweise droht man allerdings auch, das Rad neu zu erfinden, sodass eine Kontrolle, ob ein Modellierungsversuch vorliegt, teilweise auch zu der Erkenntnis führt, dass andere Organisationen (Unternehmen, Regierungen und sonstige Körperschaften) bereits umfangreiche Modellierungsarbeiten geleistet haben und daher die Entscheidung, einen eigenen Weg zu gehen, bereits erfordert, für dieses Verhalten eine gute Begründung zu finden.
Das erste Kapitel stellt als Einstiegskapitel XML-Technologien allgemein mit den Daten der Beispieldatenbank dar. Es startet mit der klassischen DTD (Document Type Definition) als erster Modellierungs- und Beschreibungstechnik für XML-Daten und stellt dann auf Basis der Technik der DTD die Unterschiede, Vorteile und neuartigen Ansätze von XML Schema dar. XML Schema ist auch die Technologie, mit der in Oracle XML-Daten beschrieben und validiert werden können, wenn man sich dafür entscheidet, typisiertes XML zu verwenden und nicht einfach beliebige XML-Strukturen zuzulassen. Für die Abfrage von XML-Daten folgen dann die Pfadbeschreibungssprache XPath und die relativ komplexe Abfragesprache XQuery. Mit XPath ist es möglich, innerhalb von XML-Dokumenten zu navigieren und entweder vom Wurzelelement oder jedem beliebigen Knoten aus andere Knoten zu lokalisieren, zu filtern und eine Reihe von Funktionen einzusetzen. Die XPath-Ausdrücke können in SQL eingesetzt werden, um Teile von XML-Daten abzurufen oder komplexe Filter vorzugeben. Man setzt diese Technik allerdings auch in XML Schema für die Angabe von Schlüsseln und Fremdschlüsseln ein. Die Umwandlung von XML-Daten mit Hilfe des DOM (Document Object Model) und XSLT (eXtensible Stylesheet Language for Transformations) lässt sich ebenso einsetzen. Es dient in vielen Anwendungen als Ausdruckssprache, um dem Benutzer komplexe Filter oder Bedingungen zu ermöglichen. XQuery dagegen kombiniert Filterung und Auswahl mit einer verkürzten und nicht XML-basierten Syntax, um die gefundenen Strukturen auch unmittelbar wieder in XML umzuwandeln. Während XPath eine Ergebnismenge mit unterschiedlichen Inhalten in Form von Knoten, Knotensätzen oder Zeichenketten und Zahlen liefert, kann man mit XQuery unmittelbar ein XML-Ergebnis erzeugen. Schließlich stellt dieses Kapitel noch die Technik XSLT vor, mit der es möglich ist, neue Dokumente in Form von XML, HTML oder Text zu erzeugen. Dabei setzt man eine programmiersprachenähnliche Syntax in XML-Form ein, die man als deklarative Sprache bezeichnet.
Das zweite Kapitel beschreibt, wie eine der wesentlichen Anforderungen beim XML-Einsatz in Oracle umgesetzt wird: den Datenabruf von relationalen Daten und die Erzeugung von XML-Ausgabedaten in einer ad-hoc-Abfrage oder einer Sicht. Oracle bietet in diesem Bereich verschiedene Möglichkeiten, die sich hinsichtlich Geschwindigkeit und Komplexität der Formulierung unterscheiden. In diesem Kapitel lernt man sowol die Techniken kennen, die sofort aus einer SQL-Abfrage heraus XML erzeugen, wie auch die Durchführung der gleichen Aufgabenstellung in PL/SQL.
Das dritte Kapitel konzentriert sich ganz auf PL/SQL und die Verarbeitung von XML. Hier gibt es eine Vielzahl an möglichen Techniken, von denen insbesondere die beiden W3C-Techniken DOM und XSLT ins Auge fallen, die in PL/SQL genauso umgesetzt sind wie in vielen anderen Programmiersprachen. Dazu gibt es allerdings auch eine Reihe von PL/SQL-Paketen, die entweder für den Einsatz der beiden genannten Standardtechnologien notwendig sind, oder die ein eigenes Angebot bieten, mit XML-Daten zu arbeiten, sie zu manipulieren und sie umzuwandeln.
Das vierte Kapitel stellt den Fokus auf das wichtige Thema Import und Export ein. Es gibt eine Reihe von traditionellen und nicht nur in Oracle einsetzbaren Techniken, mit XML umzugehen und insbesondere XML somit relational oder objektrelational zu zerlegen, sodass man noch nicht direkt XML in einer traditionellen Datenbank speichern muss. Das Kapitel diskutiert verschiedene Speicheransätze, in denen XML relational zerlegt wird oder in denen mehr oder weniger große Teile in speziellen Datentypen und selbstverständlich auch den XML-Datentyp gespeichert werden. Die Erläuterungen in diesem Kapitel sollen eine Sensibilität für den großen Gestaltungsspielraum bewirken, mit der dann in der konkreten Modellierungssituation eine passende Variante ausgewählt wird.
Das fünfte Kapitel setzt die Überlegungen des vierten Kapitels insoweit fort, als dass die Oracle XDB (XML Datenbank) als eigenständige Möglichkeit zur direkten, nativen und nicht auf Tabellen basierenden Speicherung von XML-Daten (Dateien, Dokumenten) vorgeführt wird. Für dokumentenorientierte Systeme (Redaktionssysteme, Archive) ist dies eine geeignete Möglichkeit, mit Oracle eine XML-Datenbank im ursprünglichen Sinne aufzubauen und eine Reihe von Oracle-Techniken für Sicherheit und Geschwindigkeit zu verwenden und sich darüber hinaus in der gewohnten Umgebung zu bewegen.
Das sechste Kapitel rückt den wesentlichen Datentyp, mit dem die XML-Verwendung in Oracle mit PL/SQL und SQL überhaupt erst denkbar ist, in den Mittelpunkt: XMLType. Im Gegensatz zu einer langen Zeichenkette oder einem großen Binärobjekt erlaubt XMLType die Abfrage und Filterung mit XPath und XQuery, die Umwandlung mit XSLT, die Validierung mit XML Schema sowie die Verarbeitung mit einer Reihe von speziellen SQL-Funktionen und PL/SQL-Paketen. Seine Fähigkeiten sind schon in den vorherigen Kapiteln immer mal wieder in Beispielen vorgeführt worden, doch im sechsten Kapitel erhält XML Type eine Bühne, in der die verschiedenen Möglichkeiten gesammelt, dargestellt und zusammengefasst werden.
Das siebte Kapitel schließt das Buch mit dem neu in Oracle 11g eingeführten Thema Webservices ab. Es beginnt mit einer Einführung in den Grundgedanken, der hinter dem Themenkomplex serviceorientierte Anwendungsentwicklung und verteilte Software steht und beschreibt dann kurz Einsatzbereiche sowie die beiden entscheidenden Standards, die auch in Oracle zum Einsatz kommen. Neben XML Schema, das auch für die Validierung der zwischen Service und Klient ausgetauschten XML-Nachrichten Verwendung findet und bereits eingeführt wurde, handelt es sich dabei um die Standards WSDL (WebServices Description Language) und SOAP (Akronym ohne offizielle Auflösung). WSDL-Dokumente beschreiben in technischer und inhaltlicher Sicht einen Webdienst, werden typischerweise vom Server generiert und in Klienten-Programmen verwendet, um die Struktur von Nachrichten und Kommunikationsadressen auszulesen und korrekt zu verwenden. In vielen Programmiersprachen stehen auf Basis dieser Datei Hilfsmittel zur Verfügung, die Nachrichten nicht direkt in XML, sondern vielmehr in Form von Methoden/Funktionen aufzurufen und so den Webdienst quasi in die eigene Anwendung zu integrieren. SOAP dagegen ist ein einfaches XML-Format, welches Nachrichten sammelt und sie im Wesentlichen in einen strukturierten Kopf- und Hauptabschnitt unterteilt.
Marco Skulschus studierte Ökonomie in Wuppertal und Paris und setzt im Rahmen seiner Arbeit .NET und Java für das Datenbanksystem Oracle ein. Er beschäftigt sich seit Beginn der XML-Zeitrechnung mit diesem Thema. Seine Spezialgebiete sind hierbei Datenbanken und XML sowie Ontologien auf XML-Basis. Marcus Wiederstein studierte Elektrotechnik in Bochum und Dortmund und ist verantwortlich für die Durchführung von Projekten im Bereich Systemintegration und Datenbanken (Sicherheit, Hochverfügbarkeit, Datenintegration). Zusammen haben sie eine Reihe von Büchern zu Datenbanken (Oracle und MS SQL Server) sowie zu XML (XML Schema und XSLT/XSL-FO) geschrieben.
Sprache | deutsch |
---|---|
Maße | 150 x 220 mm |
Einbandart | Paperback |
Themenwelt | Informatik ► Programmiersprachen / -werkzeuge ► XML |
Schlagworte | Administration • Datenbanken • Export • Import • Oracle • PL/SQL • Programmiersprache • SQL • XML |
ISBN-10 | 3-939701-10-6 / 3939701106 |
ISBN-13 | 978-3-939701-10-1 / 9783939701101 |
Zustand | Neuware |
Haben Sie eine Frage zum Produkt? |
Mehr entdecken
aus dem Bereich
aus dem Bereich
Grundlagen | Technologien| Validierung | Auswertung
Buch | Softcover (2018)
MITP (Verlag)
10,00 €