Datenbankmodelle für die Realisierung von Anwendungen

Datenbankmodelle für die Realisierung von Anwendungen Hauptseminar ‚Nichtrelationale Datenbanken‘Master of Ceremony: Christian Daum

Grundlagen Datenbankmodell • Datenbankmodell : • Ein System von Konzepten zur Beschreibung von Datenbanken • Es liefert zudem die Grundlage für Syntax & Semantik eines Datenbankschemas (& damit auch einer Datenbankprogrammiersprache). • Nach Edgar F. Codd definiert sich ein Datenbankmodell aus 3 Eigenschaften: • Einer Sammlung von Datenstrukturen • Einer Menge von Operatoren, die auf jede der Datenstrukturen angewandt werden kann, um Daten abzufragen oder abzuleiten. • Einer Menge von Integritätsregeln, die Veränderungen der Daten festlegen. • Datenbankschema • Formales Modell für die Struktur von Daten: Beschreibt den Aufbau einer konkreten Datenbank auf Basis des Datenbankmodells: 3 • Aufbau der Daten, Basisdatentypen, zulässige Operationen auf Daten, Beziehungen, Konsistenz-/Integritätsbedingungen etc. • Das Datenbankschema ist in einer formalen Sprache definiert – einer Datenbankprogrammiersprache (DBPL = Database Programming Language); Beispiele: • XML-Datenbanken -> Schema durch DTD (Document Type Definition) definiert • SQL-Datenbanken -> Schema durch DDL (Data Definition Language) definiert

Übersicht Datenbankmodelle • Relationenmodell • Derzeit das am weitesten verbreitete Modell • Netzwerkmodell & hierarchisches Modell • Eher historische aber nichtsdestotrotz nach wie vor im Einsatz befindliche Modelle • Erweiterte relationale & semantische Modelle • Neuere Modelle wie NF2 etc. • Objektorientierte (ODMG) & objektrelationale (SQL-3/SQL-99) Modelle • Die beiden aktuellen Trends im DB-Bereich • Multidimensionale Modelle (MOLAP/OLAP/ROLAP) • Insbesondere im Data Warehouse-Umfeld weit verbreitet • Semistrukturierte Modelle (z.B. auf XML-Basis) • Besonders für die Verarbeitung von heterogenen und uneinheitlich strukturierten Dokumenten (Text, Bild etc.) geeignet

Das Relationenmodell Zentrale Eigenschaften des 1970 von Edgar F. Codd eingeführten Relationenmodells I: • Im Relationenmodell werden – idealerweise logisch zusammenhängende – Daten (‚Realweltausschnitte‘) in Form von zweidimensionalen Tabellen(Relationen) verwaltet, die über Schlüssel (Primärschlüssel, Fremdschlüssel) miteinander verknüpft werden können. • Die Attribute (Tabellenspalten) stellen die Eigenschaften der aufgelisteten Datensätze (Records) dar, welche den Tabellenzeilen (Tupel) entsprechen. Die konkrete Ausprägung einer solchen Eigenschaft lässt sich jeweils am Kreuzungspunkt zwischen Attribut & Tupel – den Komponenten (Zellen) – ablesen. • Der Tabellenname (Relationenname) sowie die Menge der Attribute einer Tabelle werden als Relationenschema bezeichnet. • 2 Tupel einer Relation (‚Tabelle‘ bzw. Menge von Zeilen) sind dabei niemals identisch & besitzen also immer unterschiedliche Schlüssel

Das Relationenmodell Zentrale Eigenschaften des Relationenmodells II: • Ein Primärschlüssel ist ein Attribut (bzw. eine Attributkombination), dass zur eindeutigen Identifikation eines Tupels einer Relation dient. Wird dieser Schlüssel in einer anderen Tabelle als Attribut verwendet, ist er dort Fremdschlüssel – über Fremdschlüssel werden also die Relationen zwischen Tabellen realisiert • Schlüssel sind auch für die Einhaltung von sog. Integritätsbedingung notwendig (Bsp. Reservierungssystem Fluggesellschaft: Kein Sitzplatz eines Fluges darf mehrfach reserviert werden etc.) • Insbesondere Fremdschlüssel sind für globale – also über mehrere/alle Relationen hinweg geltende – Integritätsbedingungen maßgeblich; s. referentielle Integrität: Ein Eintrag in ein Feld darf nur vorgenommen werden, wenn ein entsprechender Eintrag im – über den Fremdschlüssel – referenzierten Feld der entsprechenden Tabelle existiert. • Primärschlüssel hingegen gewährleisten die lokale Integrität innerhalb einer Relation. Die Integrität kann dabei automatisch von einem Integritätsmonitor als Teil des DBMS überwacht werden (s. Access etc.) • Die Reihenfolge der Tupel einer Relation ist nicht von Bedeutung – desgleichen gilt für die Attribute einer Relation (mal abgesehen von irgendwelchen finsteren weil diskriminierenden Sortierabsichten etc.). • Attribute haben i.d.R. atomare Werte (d.h. eine Komponente bzw. Zelle enthält normalerweise – in der 1. NF – nur einfache Datentypen wie string, int etc. –im sog. ‚Non First Normal Form‘-Model (NF2 -Modell) sind allerdings auch komplexere Datentypen & Relationen – also weitere Tabellen – als Werte erlaubt)

Das Relationenmodell Die wichtigsten Basisoperationen im Relationenmodell (sog. Relationenalgebra) • Selektion:Wählt Tupel aus einer Relation aus -> z.B. alle Personen mit Nachnamen Meyer etc. • Das Ergebnis ist wieder eine Relation • Projektion:WähltAttribute einer Relation aus -> z.B. nur Vorname & PLZ aller Personen • Natürlicher Verbund (Join) • Verknüpft/Vereinigt 2 Relationen hinsichtlich ihrer gemeinsamen (da in logischem bzw. ‚natürlichem‘ Zusammenhang stehenden) Attribute -> mehrere Tupel werden also zu einem Neuen vereinigt • z.B. wird aus einem Tupel der Relation ‚Personen‘ (Attribute: Vorname, Name) & einem Tupel der Relation ‚Personen_Tel‘ (Attribut: Nummer) über einen Join ein neuer Tupel, der nun sowohl die Attribute Vorname & Name als auch das Attribut Nummer enthält. • Mengen-Operationen (Vereinigung, Differenz, Durchschnitt) • Diese Mengen-Operationen können nur auf Relationen angewandt werden, welche ein identisches Relationenschema aufweisen (s. a. Umbenennung) • Umbenennung:z.B. die Umbenennung des Attributs Ort in Wohnort • Die Notwendigkeit einer solchen Umbenennung wäre beispielsweise bei einer Vereinigung zweier Relationen gegeben, um deren Attribute zueinander kompatibel zu machen – enthielte eine Relation das Attribut Wohnort & die andere das Attribut Ort, muss eines dieser Attribute vor einer Vereinigung dergestalt umbenannt werden, dass es mit dem anderen Attributnamen identisch ist, da eine Vereinigung nur bei identischem Schema möglich ist – puh. • Das Ergebnis einer Umbenennung ändert also nicht die Relation selbst sondern lediglich das Relationenschema

Das Relationenmodell Begriffe des Relationenmodells 2 Relationen zur Darstellung von Personen:

Netzwerkmodell & hierarchisches Modell • Hierarchisches Modell • Ältestes & kommerziell erfolgreichstes Datenbankmodell der ersten Generation • 1969 von IBM mit dem IMS – Information Management System – eingeführt • Insbesondere von Banken & Versicherungen z.T. bis dato eingesetzt • Hierarchie/Wald als Datenbankschema: • Bildet die Realwelt durch eine hierarchische Baumstruktur (einen Wald – also eine ‚Menge von Bäumen‘) ab • Verknüpfungen der Records via PCR (Parent Child Relationships): • Die einzelnen Records sind dabei jeweils mit ihrem Vorgänger (Parent) verlinkt – mit Ausnahme der Wurzel, welche aus einem einzelnen Record besteht & keinen Vorgänger hat • Ergo tritt jeder Record mit Ausnahme der Wurzel genau einmal als Child auf • Die „Enden“ des Baums, welche also nicht als Parent fungieren können, werden jeweils „Blatt“ genannt • Operationen im Hierarchischen Modell: • Die Operationen des hierarchischen Modells lassen sich sehr einfach implementieren (was eine der Ursachen für die Beliebtheit des Modells in der Praxis ist); Basisoperationen: • Durchlauf eines Baums ausschließlich von oben nach unten ... • ... bzw. bei Geschwistern einer Ebene von links nach rechts

Netzwerkmodell & hierarchisches Modell • Hierarchisches Modell • Problem dieses Datenbankschemas: • Mit einer solchen Baumstruktur lassen sich lediglich 1:1 sowie 1:n-Beziehungen darstellen – nicht jedoch die oftmals benötigten n:m-Beziehungen: • Lösung:VPCR (um nicht zu sagen: Virtual Parent Child Relationships): • Hier wird via „virtual records“ (Zeigern) die klassische Baumstruktur durchbrochen, so dass auch Querverbindungen möglich sind, um auch allgemeine Beziehungen darzustellen:

Netzwerkmodell & hierarchisches Modell • Netzwerkmodell (CODASYL-Datenbankmodell) • Datenbankmodell der ersten Generation • 1971 von CODASYL-DBTG (Yihah: Conference on Data Systems Language - Data Base Task Group) entwickelt (wird deswegen oft auch CODASYL-Datenbankmodell genannt) • Zwar wird das Netzwerkmodell seit den 90ern zunehmend durch das relationale Modell verdrängt, ist jedoch insbesondere im Großcomputerbereich heute noch weit verbreitet & gewinnt zudem im Zuge des Semantic Web wieder an Bedeutung • Bekannte Systeme: • IDMS(Integrated Database Management System) von Cullinet Software • UDS(Universelles Datenbank-System) von Siemens • Begriffe des Netzwerkmodells/Gegenüberstellung zum ER- & Relationenmodell:

Netzwerkmodell & hierarchisches Modell • Netzwerkmodell (CODASYL-Datenbankmodell) Datenbankschema: • Das Netzwerkmodell fordert keine strengen Hierarchien – vielmehr kann es als Verallgemeinerung bzw. Erweiterung des hierarchischen Modells betrachtet werden. Es entspricht jedoch auch – mit gewissen Einschränkungen – dem ER-Modell • Verknüpfungen der Records • Records können mehrere Vorgänger haben – es sind prinzipiell also auch m:n-Beziehungen erlaubt – zudem können mehrere Records an oberster Stelle stehen, so dass sich eine Netzwerkstruktur ergibt. • Allerdings sind Beziehungen immer 2stellig (binär) • Beispiel n-stellige Beziehung: • Professor Jedöns hält Vorlesung V & empfiehlt das passende Buch B mit der ISBN xyz • Beispiel 2stelliger Beziehungen: • Professor Jedöns hält Vorlesung V; • Professor Jedöns empfiehlt Buch B; • Buch B hat die ISBN xyz usw. ... • Die Beziehungstypen haben zudem keine Attribute (hein?) • Anstelle der Mengensemantik des ER-Modells hat das Netzwerkmodell eine Listensemantik • Das Schema des Netzwerkmodells wird als gerichteter Graph definiert: • Mit der Menge der Record-Typen (‚Schemata‘) als Knoten& den Set-Typen (‚Relationen‘) als Kanten • Über Zeiger wird eine Reihenfolge von Instanzen (Member) festgelegt • Diese Member sind einer Vorgängerinstanz (Owner) zugeordnet • Wird der Member-Satz (Set) vollständig durchlaufen, gelangt man schließlich wieder zum Owner

Netzwerkmodell & hierarchisches Modell • Netzwerkmodell (CODASYL-Datenbankmodell) • Beispiel Netzwerkstruktur: • Basisoperationen im Netzwerkmodell: • Selektionsoperationen für Rekord-Typen (‚Schemata‘) • z.B.: Suche alle Studenten die in Rostock wohnen • Befehle zum Verfolgen von Links (Set-Typen/‘Relationen‘) in beiden Richtungen • z.B.: Suche alle Vorlesungen eines Professors

Erweiterte relationale & semantische Modelle • Geschachtelte Relationen: NF2-Modell (NF2 = NFNF = Non First Normal Form): • Erlaubt im Gegensatz zum klassischen Relationenmodell auch geschachtelte Relationen. • Während im Relationenmodell Attribute i.d.R. nur atomare Werte haben (eine Komponente bzw. Zelle also in der 1. NF nur einfache Datentypen wie string, int etc enthält), sind im sog. NF2 -Modell neben komplexeren Datentypen vor allem auch Relationen – also weitere Tabellen – als Werte erlaubt, was letztlich einer Schachtelung von Relationen entspricht • PNF-Relationen (Partitioned Normal Form): • Da die beschriebene Schachtelung von Relationen schnell zu unübersichtlichen & auch fehlerträchtigen Relationen führen können, gibt es sog. PNF-Relationen • Diese lassen sich immer zu einer klassischen (flachen) Relation im Sinne der 1. NFentschachteln • PNP-Relationen haben demnach auf jeder Stufe der Schachtelung einen flachen Schlüssel • PNF-Relationen sind also jene NF-Relationen, die sich entschachtelt immer durch eine flache 1. NF-Relation darstellen lassen • Erweitertes NF-Modell (eNF): • Hier sind als Attributwerte „Mengen von...“, „Listen von...“ , „Tupel von...“ erlaubt • Semantische Datenmodelle: • Datenmodelle, die das Relationenmodell um weitere Abstraktionskonzepte wie Generalisierung, Spezialisierung, Aggregation, Gruppierung etc. ergänzen

Objektorientierte & Objektrelationale Modelle • Objektorientierte Modelle • Modelle, deren Gegenstände Objekte im Sinn der objektorientierten Programmierung sind • Basieren dementsprechend auf objektorientierten Sprachen wie C++ & bilden deren Typsystem direkt auf das Datenmodell ab • Ziel: Struktur & Verhalten von Umweltobjekten möglichst 1:1 zu erfassen • Zu diesem Zweck unterstützen OODB-Modelle im Gegensatz zu klassischen DB-Modellen weiterführende OO Konzepte wie • Komplexe Werte (Objekte), die als set of, tuple of & list of beschrieben werden können • Also bspw. Objekte, die neben den üblichen Attributen wiederum Objekte beinhalten können • Objektidentität, um die gespeicherten Objekte von ihren Werten unterscheiden zu können • Methoden, um objektspezifische Operationen definieren & ausführen zu können (& damit ausschließlich für bestimmte Objekttypen zuzulassen) • Vererbung von Attributen & Methoden zwischen Objekten, die in einer IST-Beziehung zueinander stehen • Möglichkeit der (Neu)Definition von Objekttypen(s. Definition von Klassen in der OOP im Sinne selbstdefinierter Datentypen) • Kapselung– Verbergen von Attributen & Methoden – bzw. Kontrolle des Zugriffs auf Objekteigenschaften durch öffentliche Methoden (s. public/private/protected/friends-Prinzip bei C++) • Persistenz– Objekte werden ‚dauerhaft‘ gespeichert • Wichtiger Vertreter OODBM ist ODMG-93 (Object Database Management Group) • Hier beschreibt ein (C++-lastiges) Objektmodell Begriffe & semantische Bedingungen des OO Datenmodells • Mögliche Schnittstellen zur Datendefinition & -manipulation werden durch Datenbanksprachen wie ODL (Object Definition Language) OQL (Object Query Language) geboten • Zudem sind Bindings (Spracheinbettungen) für C++, Java & SMALLTALK vorgesehen

Objektorientierte & Objektrelationale Modelle • Objektorientierte Modelle • Abgrenzung zum relationalen Modell: • Im relationalen Modell sind Informationen über ein ‚Objekt‘ (wie einen Angestellten o.ä.) über mehrere Relationen„verstreut“ – d.h. die gefragte Information muss unter Umstände aus mehreren Relationen (via Verbundoperationen etc.) vergleichsweise umständlich zusammengesetzt werden • Im OODBM hingegen wird die Gesamtheit der Informationen über einen Angestellten o.ä. in einem Datenobjekt „gehalten“ – eine entsprechende Anfrage betrifft dann auch nur dieses Objekt. • Vereinfachung der Konsistenzregeln & Leistungsvorteil:Demzufolge müsste auch bei einer Aktualisierung nicht die gesamte Datenbasis der DB nach eventuell betroffenen Tupeln abgesucht werden, wie dies im relationalen Modell der Fall wäre.

Objektorientierte & Objektrelationale Modelle • Objektrelationale Modelle • Bindeglied zwischen klassischen relationalen und objektorientierten Datenbanksystemen – also eine Erweiterung relationaler DB-Systeme um bestimmte objektorientierte Eigenschaften (s. SQL3/SQL-99) • Häufig wird über eine Relationale Datenbank eineobjektorientierte Zugriffsschicht (Persistent Framework) gesetzt. • Objektrelationale Modelle kommen überall dort zum Einsatz, wo Mengen von Objekten in Beziehung zu anderen Daten oder Objekten gebracht werden müssen. • Beispiel GIS: Mehrere Koordinaten-Objekte referenzieren eine Straße – die Koordinaten stehen also in Relation mit einem Straßennamen und sind selbst Objekte, die zueinander eine Beziehung haben.

Multidimensionale Datenmodelle Data Warehouse • Data Warehouse:Mitnichten ein Warenhaus, sondern ein multidimensionales System, das unternehmensübergreifend Daten aus den operativen Einzelsystemen zusammenführt, integriert & für die Analyse aufbereitet • Also eher ein Datenlager, dass der Informationsintegration dient • Der Inhalt dieses Datenlagers setzt sich demnach aus Daten unterschiedlicher Quellen zusammen, die in das Warehouse geladen & dort mehr oder weniger langfristig gespeichert werden, um zu Analysezwecken sowie als betriebswirtschaftliche Entscheidungshilfe verwendet zu werden. • Es wird also eine homogene, vergleichbare Datenbasis generiert, um eine globale Sicht auf heterogene & verteilte Datenbestände zu ermöglichen • Ein Data Warehouse dient oft einem OLAP(OnLine Analytical Processing) als Datenquelle (s. Folgechart). • Die „Beladung“ eines Warehouse erfolgt z.B. turnusmäßig, um Analysen über die Zeit zu ermöglichen. Der Trend geht allerdings inzwischen zum Real-Time-Data-Warehousing (yoyoyo!).

Multidimensionale Datenmodelle OLAP • OLAP (OnLine Analytical Processing):Ein analytischesInformationssystem, welches entscheidungsunterstützend im interaktiven Bereich eingesetzt wird • OLAP wird zur hypothesengestützten Analyse von Daten z.B. eines Data Warehouse verwendet: • Der Analyst muss also vor der eigentlichen Untersuchung wissen, welche Anfragen er an das OLAP-System stellen möchte. • Seine Hypothese wird dann durch das Analyseergebnis bestätigt oder abgelehnt • Ziel ist, durch multidimensionale Betrachtung dieser Daten ein entscheidungsunterstützendes Analyseergebnis zu gewinnen. • OLAP-Cube Der OLAP-Cube ist ein Data Cube, ein mehrdimensionaler Datenwürfel, der auf Basis bspw. eines Data Warehouse erstellt wurde und der logischen Darstellung von Daten dient • Die Daten – z.B. Kennzahlen wie Geldbeträge etc. – werden dabei als Elemente eines solchen mehrdimensionalen Würfels angeordnet. • Da häufig mehr als 3 Dimensionen realisiert werden, spricht man auch von einem Hypercube • Bei OLAP sind die Dimensionen des Cube i.d.R. hierarchisch angeordnet • Produktgruppen -> Produktklassen -> Produkte etc. • Staaten -> Bundesländer -> Städte -> Stadtbezirke etc.

Multidimensionale Datenmodelle Data Warehouse & OLAP • Ich hab da mal ne Grafik vorbereitet, ne: Oder wie der Spanier sagt:

Multidimensionale Datenmodelle Data Warehouse & OLAP Zusammenspiel zwischen Data Warehouse & OLAP: • Das ‚Befüllen‘ eines Data Warehouse ist ein komplexer & zeitaufwendiger Prozess, der nicht synchron zum normalen Transaktionsbetrieb der als Quelle dienenden DB erfolgen kann & deshalb nur selten vorgenommen wird: • Ein Data Warehouse wird aus mehreren verschiedenen operationalen DB gefüllt – also DB, welche im laufenden Betrieb beständig Transaktionen verschiedenster Art durchführen • Als mögliche Datenquellen werden neben DB auch WWW-Quellen genutzt • Vor der Datenintegration ins Warehouse müssen die Daten aktualisiert (refreshed), extrahiert, transformiert & bereinigt werden (Data Cleaning), um schließlich eine homogene & vergleichbare Datenbasiszu generieren • Auf dem Gesamtbestand des Warehouse setzt (i.d.R. nach dem Client-Server-Prinzip) ein OLAP-System auf, welches aus ein od. mehreren OLAP-Servern besteht • Dabei sollte das OLAP-System den durch das Akronym FASMI (Fast Analysis of Shared Multidimensional Information) definierten Anforderungen genügen: • Fast: Fürgegen interaktives Arbeiten notwendig • Analysis: Unterstützung analytischer & statistischer Funktionalitäten • Shared: Unterstützung des Mehrbenutzerbetriebs • Multidimensional: Unterstützung des multidimensionalen Datenmodells • Information: Gewährleistung der Informationsgewinnung aus Rohdaten • OLAP-Varianten • MOLAPMultidimensional OLAP (s. OLAP-Cube: eigene Datenhaltung in Form eines Datenwürfels – realisiert als direkte Speicherung von Matrizen; schneller Zugriff) • ROLAPRelationales OLAP (basiert auf relationaler DB) • HOLAPHybrides OLAP (Hybrid zwischen MOLAP & ROLAP)

Semistrukturierte Datenbanken • Semistrukturierte Daten/Dokumente:Daten bzw. Dokumente wie Text- oder HTML-Files mit wechselnder Strukturierung • Bestenfalls liegt zwar eine interne Struktur vor, jedoch ist diese oft wechselhaft/nicht zwingend konsistent • Mögliche Merkmale semistrukturierter Datenmodelle: • Kein Zentrales Schema vorhanden:Das Schema solcher Modelle ist nicht zentral für alle Daten gleichen Typs gespeichert – sondern implizit in jedem Dokument enthalten • Notwendigkeit von Parsern o.ö. zur Strukturerkennung & -interpretation, da sich ein solches Schema nicht von ‚Standard-Datenmodellen‘ adäquat verarbeiten ließe • Wechselnde Datenstruktur:Selbst Daten desselben Typs können eine wechselnde Struktur aufweisen • differierende, fehlende od. zusätzliche Attribute bzw. divergierende Strukturierung auch innerhalb der Attribute selbst • Daten haben keine Struktur im Sinne von Attributen bzw. Tags • So lassen sich beispielsweise die einzelnen Sätze eines Textes in Ermangelung von Attributen bzw. Tags nicht ohne weiteres (parsing o.ä.) identifizieren • Ggf. variierende Datentypen der Attribute: Diese haben keine verbindliche Typisierung im Sinne einer Integritätsbedingung • Relationale Modelle definieren für die Attribute Integritätsbedingungen hinsichtlich der zuzulassenden Datentypen • Große Anzahl möglicher Attribute & polymorphe interne Strukturierungder Attribute (im Gegensatz zu relationalen Modellen mit einer überschaubaren Anzahl von Attributen & deren durchgängigen Strukturierung)

Semistrukturierte Datenbanken Mögliche Merkmale semistrukturierter Datenmodelle (Fortsetzung): • Kein festes Schema (als auch nicht implizit):Attribute & Dokument-Struktur unterliegen häufigen Änderungen • relationale DB haben über einen längeren Zeitraum hinweg ein festes Schema • Unscharfe Trennung zwischen Daten & Schema:Bedingt durch häufige strukturelle Änderungen können Schema & die eigentlichen Nutzdaten nicht immer klar voneinander unterscheiden werden – Schemainformationen werden also ggf. als Daten ‚missverstanden‘ • Relationale Modelle trennen Schemata & Instanzen (Daten) streng voneinander • Inhaltsbasierte Anfragen:Bei Anfrageoptionen wie Vergleichsprädikaten (z.B. die Suche nach einem Begriff) wird oftmals das gesamte Dokument & nicht einzelne Attribute abgeglichen bzw. durchsucht(s. übliche Suchanfragen im klassischen (nicht semantischen) Web: Ein gesuchter Begriff wird im Titel, in den Keywords sowie des gesamten HTML-Dokuments gesucht) • In relationalen Modelle erfolgen Anfragen hingegen auf Basis von konkreten Attributen

Semistrukturierte Datenbanken • Datenmodelle für semistrukturierte Dokumente (welche die beschriebenen Merkmale teilweise beheben) • Schemalose Datenmodelle:Nutzen Graphendarstellungen für Instanzen & Attribute • OEM (Object Exchange Model) • Baummodell • Union-Datenmodell:Hier wird eine Dokumentstruktur durch Vereinigung von Basisstrukturen erreicht • Problemski:Notwendigkeit vordefinierter Basisstrukturen – andernfalls bleiben die Probleme semistrukturierter Modelle bestehen • Die Markup-Sprache HTML (Hypertext Markup Language):Strukturierung durch Tags • Vorteil: Hohe Toleranz bei fehlenden/zusätzlichen Tags – deshalb eigentlich für semistrukturierte Dokumente gut geeignet • Problem: Vordefinierter & nicht veränderbarer Satz von (Tag-)Attributen • Metasprachen wie SGML (Standard Generalized Markup Language) & XML (Extensible Markup Language):Ermöglichen die Beschreibung einer sog. DTD (Document Type Definition), welche Art, Menge & Strukturierung (Schachtelung) der Attribute definiert

Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML • XML ist eine Teilmenge von SGML, die aufgrund der hohen Komplexität von SGML vom W3C neu abgeleitet wurde • Damit ist XML - wie SGML auch – eine Metasprache (also eine Sprache zur (Regel-)Definition anderer Sprachen) zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur • XML-Dokumente haben eine logische & eine physische Struktur (im Gegensatz zu HTML jedoch keine zwingende Layout-Struktur für die Browser-Darstellung) • Logische Struktur:Durch einen hierarchisch strukturierten Baum gewährleistet; Baumknoten: • Elemente:Tags bzw. Tag-Paare oder Empty-Element-Tags • Attribute:Schlüsselwort-Werte-Paare für Zusatz-Informationen über Elemente • Processing Instructions(Verarbeitungsanweisungen): • Werden z.B, verwendet, um Verarbeitungsanweisungen anderer Sprachen zu integrieren – PHP-Beispiel: <?php echo("Hello, World");?> • Kommentare: • Daten/Payload wie Text etc.:<![CDATA[ beliebiger Text ]]> • Physische Struktur: • Hauptdatei des XML-Dokuments als erste Entität: *.xml • XML-Deklaration(spezifiziert XML-Version, Zeichenkodierung und Verarbeitbarkeit):<?xml version="1.0" encoding="UTF-8" standalone="yes"?> • DTDdefiniert Entitäten & spezifiziert den erlaubten logischen Aufbau des XML-Dokuments (s. Folgerchart): *.dtd

Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD I (Elementtyp-Deklaration) • In einer DTD werden Elemente, Attribute von Elementen & Entitäten definiert. • Mit einer Elementtyp-Deklaration wird ein Element (Tag) & sein möglicher Inhalt definiert. In einem validen XML-Dokument dürfen nur Elemente vorkommen, die in der DTD definiert sind. • Die DTD verwendet zur Elementtyp-Deklaration folgende Ausdrücke : • Sequenz: (A1, A2)Definiert die Reihenfolge von Elementen – logo: erst A1, dann A2 ... • Alternative: (A1|A2)Definiert eine Wahlmöglichkeit zwischen Elementen - entweder muss A1 oder A2 enthalten sein • Verschiedene Varianten für Wiederholungen (Iteration),deren Notation an reguläre Ausdrücke anlehnt (fehlt eine solche Notation, muss das entsprechende Element genau einmal vorkommen!): • Beliebige Iteration: A*A kann beliebig oft vorkommen –also auch gar nicht • nichtleere Iteration: A+A muss mindestens einmal vorkommen • optionales Element: A?A darf vorkommen, muss es jedoch nicht – wenn A vorkommt, dann jedoch nur einmal! • Gruppierung von Elementen mit runden Klammern: () • Kein Inhalt: EMPTY (das Element ist immer leer, wie z.B. bei <br>) • Beliebiger Inhalt: ANY • Ausschließlich Text: #PCDATA (parseable character data)

Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD II (Attributlisten-Deklaration) • Die Liste der möglichen Attribute eines Elementes wird in einer DTD mit <!ATTLIST Elementname Attributliste>angegeben. • Die Attributliste enthält durch Leerzeichen oder Zeilenumbrüche getrennt jeweils den Namen, den Typ und Vorgaben eines Attributes. • Attributtypen: • CDATA(Zeichenketten) • ID(Attributwert gilt als eindeutige ID – optimal für IDs aus Datenbanken) • IDREF (Einzelne Referenz auf Attribute des Typs ID - Attributwert muss also gleich einer ID sein) IDREFS (Liste von Referenzen auf Attribute des Typs ID - dito für ein oder mehrere ID's) • NMTOKEN (einzelnes Token - Attributwert muss gleich einem Namen sein) NMTOKENS (Liste von Tokens - dito für ein oder mehrere Namen) • ENTITY (Attributwert muss gleich ungeparster Entity sein) ENTITIES (dito für ein oder mehrere Entities) • Aufzählungen & NOTATION-Aufzählungen (Liste der erlaubten Werte; wird der Reihe nach angegeben und durch | getrennt) • Attribut-Vorgaben: • #REQUIREDErforderliches Attribut (muss explizit im Element vorkommen) • #IMPLIEDOptionales Attribut (darf fehlen & hart dann auch keinen Default-wert) • "..." Default-Wert (falls das Attribut weggelassen wird) • #FIXED "..." Das Attribut hat immer einen festen Standardwert

Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD III (Entity-Deklaration) • Ein Entity ist eine benannte Abkürzung für eine Zeichenkette (oder ein externes Dokument), die innerhalb der DTD oder des XML-Dokumentes, das diese DTD benutzt, verwendet werden kann. • Entities sind also (verkürzte) Platzhalter für längere Deklarationen innerhalb einer DTD • Die Entity-Deklaration wird durch das Schlüsselwort ENTITY in der DTD festgelegt. • Ein Beispiel-Entity fasst unter dem Platzhalter %adresse die Elemente straße, plz und stadt zusammen: • <!ENTITY %adresse „(straße, plz, stadt)“> //Anführungsstriche beachten! • Möchte man nun die Adresse als Unterelement einer Person verwenden, tut man dies über das Entity %adresse: • <!ELEMENT person (%adresse; alter)> //Semikolon nicht vergessen! • Hier zeigt sich der Vorteil der Entity-Verwendung, da logisch zusammengehörende Elemente zu einem verkürzten Platzhalter zusammengefasst werden können. • Interne Entities:Diese bestehen aus Zeichenketten (& können selber wieder Entity-Referenzen und wohlgeformtes XML-Markup enthalten) – hier wird eine Entity-Referenz der Form &name; wird durch den Inhalt der Entity name ersetzt: • Externe Entities:Diese bestehen aus dem Inhalt einer externen Datei, auf die verwiesen wir

Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD IV (Verschiedene ‚DTD-Klassen‘) • Standard-DTDs • Also gleichsam als Standard verabschiedete DTDs (EAD-DTD, TEI-DTD, EBIND-DTD etc.) mit einem fixen Schema • Vorteil: Lassen sich leicht in beliebige Datenbanken importieren • Separate DTDs • Z.B. für den Datenaustausch innerhalb von Firmen etc. • Vorteil: dito; die Programmierung spezifischer Import-Filter etc. lohnt sich jedoch erst bei einer großen Anzahl zu importierender XML-Dokumente • Lokale DTDs für selbstbeschreibende Dokumente • Als Teil des Dokuments selbst (interne Notation) • Nachteil: Variierende, zueinander inkompatible DTDs - hier muss also auf die genannten anderen Modelle zur Verarbeitung semistrukturierter Datenbanken zurückgegriffen werden

Semistrukturierte Datenbanken Import semistrukturierter Daten in relationalen od. objektorientierten Datenbanken • Hier lässt sich ein Import dadurch realisieren, dass die zu importierenden, semistrukturierten Daten als neuer Datentyp für Dokumente etc. definiert werden. • Bei XML-Dokumenten od. DTDs kann dies durch die Definition eines Erweiterungsmoduls geschehen • XML kann hier auch als Datenaustauschformat zwischen verschiedenartigen relationalen DB fungieren (Die Tabellenstruktur wird dann als DTD erfasst) • XQL, XML-Q & Lorel sind mögliche Technologien zur Abfrage von XML basiertenDatenbanken • Das DOM (Document Object Model) als plattform- & PPSneutrale Schnittstelle fungiert im Zusammenhang mit XML-Parsern als API, um Programmen den Zugriff auf Inhalt, Struktur & Stil von XML-Dokumenten zu ermöglichen.

Sonstige DB-Modelle • GOOD (Graph-Oriented Object Model)DB-Modell auf Basis von Graphen • Hier werden die Ecken eines Graphen als Werte, Objekte & Typen interpretiert, wobei die Kanten des Graphen dessen Ecken einander zuordnen • Ein GOOD-Graph besteht aus DB & DB-Schema in einer homogenen Darstellung • Mittels Graphmanipulationen werden Anfragen & Änderungen vorgenommen • Klassenlose DB-ModelleVariante der OODBM • Mit ähnlichen Eigenschaften, allerdings wird hier auf eine strenge Klassifizierung & Typisierung verzichtet • Vorteil: Höhere Flexibilität bei der Modellierung dynamischer & komplexer Anwendungen • Nachteil: Erschweren von Anfragen & effizienten Speicherstrukturen • Feature-TermeDienen der Wissensrepräsentation • Feature-Terme bestehen aus einem eindeutigen Namen & verschiedenen Features (Attributen) • Die Features können wiederum weitere vollständige Feature-Terme aufnehmen, so dass eine komplexe Objektstruktur ermöglicht wird • Das Lilog-Datenmodell dient der Verarbeitung natürlicher Sprachen (& wohl auch von feature-Termen) – eine logikbasierte Abfragesprache stellt F-Logic dar (basiert auf Feature-Termen) • Komplex-Objekt-Datenmodelle wie MAD (Molekül-Atom-Datenmodell)Dient der Darstellung komplexer Objektstrukturen • Wird im technischen Bereich verwendet, um die dort weit verbreiteten hierarchischen ‚Ist Teil von-Beziehungen‘ zu unterstützen. MAD ermöglicht z.B. das Zusammensetzen von Basisobjekten (Atomen) zu komplexen Objektstrukturen (Molekülen)

Datenbankmodelle für die Realisierung von Anwendungen