PPT

Datenbankmodelle für die
Realisierung von Anwendungen
Hauptseminar
‚Nichtrelationale Datenbanken‘
Master of Ceremony: Christian Daum
Grundlagen Datenbankmodell

Datenbankmodell :
o Ein System von Konzepten zur Beschreibung von Datenbanken
o Es liefert zudem die Grundlage für Syntax & Semantik eines
Datenbankschemas (& damit auch einer Datenbankprogrammiersprache).
o 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
o 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.
o 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
o Derzeit das am weitesten verbreitete Modell

Netzwerkmodell & hierarchisches Modell
o Eher historische aber nichtsdestotrotz nach wie vor im Einsatz befindliche Modelle

Erweiterte relationale & semantische Modelle
o Neuere Modelle wie NF2 etc.

Objektorientierte (ODMG) & objektrelationale (SQL-3/SQL-99) Modelle
o Die beiden aktuellen Trends im DB-Bereich

Multidimensionale Modelle (MOLAP/OLAP/ROLAP)
o Insbesondere im Data Warehouse-Umfeld weit verbreitet

Semistrukturierte Modelle (z.B. auf XML-Basis)
o 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
o
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.
o
Das Ergebnis ist wieder eine Relation

Projektion: Wählt Attribute einer Relation aus -> z.B. nur Vorname & PLZ aller Personen

Natürlicher Verbund (Join)
o
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
>

Mengen-Operationen (Vereinigung, Differenz, Durchschnitt)
o

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.
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
o
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.
o
Das Ergebnis einer Umbenennung ändert also nicht die Relation selbst sondern lediglich
das Relationenschema
Das Relationenmodell
Begriffe des Relationenmodells
Attribut
 Spalte einer Tabelle
Wertebereich
 Mögliche Werte eines Attributs
(auch Domäne; int, string, boolean)
Attributwert
 Element eines Wertebereichs
Relation/Instanz
 ‚Tabelle‘ bzw. Menge von Zeilen
einer Tabelle
(auch Instanz eines Relationenschemas)
2 Relationen zur Darstellung von Personen:
Relationenschema
 Relationenname + Menge von
Attributen
Tupel
 Zeile einer Tabelle / Record
Datenbankschema
 Menge von Relationenschemata
Datenbank
 Menge von Relationen
(Basisrelationen)
Schlüssel
 minimale Menge von Attributen,
Primärschlüssel
 ein beim Datenbankentwurf
ausgezeichneter Schlüssel
Fremdschlüssel
 Attributmenge, die in einer
anderen Relation Schlüssel ist
Fremdschlüsselbedingung
 alle Attributwerte des
Fremdschlüssels tauchen in der
anderen Relation als Werte des
Schlüssels auf
(auch Element einer Relation)
deren Werte ein Tupel einer Tabelle
eindeutig identifizieren
Netzwerkmodell & hierarchisches Modell
Hierarchisches Modell



Ältestes & kommerziell erfolgreichstes Datenbankmodell der ersten Generation
o
1969 von IBM mit dem IMS – Information Management System – eingeführt
o
Insbesondere von Banken & Versicherungen z.T. bis dato eingesetzt
Hierarchie/Wald als Datenbankschema:
o
Bildet die Realwelt durch eine hierarchische Baumstruktur (einen Wald – also eine
‚Menge von Bäumen‘) ab
o
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:
o
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:

Lösung: VPCR (um nicht zu sagen: Virtual Parent Child Relationships):
o
o
Mit einer solchen Baumstruktur lassen sich lediglich 1:1 sowie 1:n-Beziehungen darstellen –
nicht jedoch die oftmals benötigten n:m-Beziehungen:
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
o
1971 von CODASYL-DBTG (Yihah: Conference on Data Systems Language - Data
Base Task Group) entwickelt (wird deswegen oft auch CODASYL-Datenbankmodell
genannt)
o
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
o
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
o
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.
o
Allerdings sind Beziehungen immer 2stellig (binär)
>
Beispiel n-stellige Beziehung:

>

Beispiel 2stelliger Beziehungen:

Professor Jedöns hält Vorlesung V;

Professor Jedöns empfiehlt Buch B;

Buch B hat die ISBN xyz usw. ...
o
Die Beziehungstypen haben zudem keine Attribute (hein?)
o
Anstelle der Mengensemantik des ER-Modells hat das Netzwerkmodell eine Listensemantik
Das Schema des Netzwerkmodells wird als gerichteter Graph definiert:
o

Professor Jedöns hält Vorlesung V & empfiehlt das passende Buch B mit der ISBN xyz
Mit der Menge der Record-Typen (‚Schemata‘) als Knoten & den Set-Typen (‚Relationen‘)
als Kanten
Über Zeiger wird eine Reihenfolge von Instanzen (Member) festgelegt
o
Diese Member sind einer Vorgängerinstanz (Owner) zugeordnet
o
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:
o
Selektionsoperationen für Rekord-Typen (‚Schemata‘)
>
o
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):
o
Erlaubt im Gegensatz zum klassischen Relationenmodell auch geschachtelte Relationen.
o
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):
o
Da die beschriebene Schachtelung von Relationen schnell zu unübersichtlichen & auch
fehlerträchtigen Relationen führen können, gibt es sog. PNF-Relationen
o
Diese lassen sich immer zu einer klassischen (flachen) Relation im Sinne der 1. NF
entschachteln
o
PNP-Relationen haben demnach auf jeder Stufe der Schachtelung einen flachen Schlüssel
o
PNF-Relationen sind also jene NF-Relationen, die sich entschachtelt immer durch eine
flache 1. NF-Relation darstellen lassen
Erweitertes NF-Modell (eNF):
o

Hier sind als Attributwerte „Mengen von...“, „Listen von...“ , „Tupel von...“ erlaubt
Semantische Datenmodelle:
o
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
o
Ziel: Struktur & Verhalten von Umweltobjekten möglichst 1:1 zu erfassen
o
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

o
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:
o
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
o
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)
o

Häufig wird über eine Relationale Datenbank eine objektorientierte
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.
o
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
o
Also eher ein Datenlager, dass der Informationsintegration dient
o
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.
o
Es wird also eine homogene, vergleichbare Datenbasis generiert, um eine
globale Sicht auf heterogene & verteilte Datenbestände zu ermöglichen
o
Ein Data Warehouse dient oft einem OLAP (OnLine Analytical Processing)
als Datenquelle (s. Folgechart).
o
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-DataWarehousing (yoyoyo!).
Multidimensionale Datenmodelle
OLAP

OLAP (OnLine Analytical Processing):
Ein analytisches Informationssystem, welches entscheidungsunterstützend im
interaktiven Bereich eingesetzt wird
o
o
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:
o
Ein Data Warehouse wird aus mehreren verschiedenen operationalen DB gefüllt – also DB,
welche im laufenden Betrieb beständig Transaktionen verschiedenster Art durchführen
>
o

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 Datenbasis zu 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
o
o
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
>
MOLAP
Multidimensional OLAP (s. OLAP-Cube: eigene Datenhaltung in Form eines
Datenwürfels – realisiert als direkte Speicherung von Matrizen; schneller Zugriff)
>
ROLAP
Relationales OLAP (basiert auf relationaler DB)
>
HOLAP
Hybrides OLAP (Hybrid zwischen MOLAP & ROLAP)
Semistrukturierte Datenbanken

Semistrukturierte Daten/Dokumente:
Daten bzw. Dokumente wie Text- oder HTML-Files mit wechselnder Strukturierung
o
Bestenfalls liegt zwar eine interne Struktur vor, jedoch ist diese oft
wechselhaft/nicht zwingend konsistent
o
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

>
Wechselnde Datenstruktur:
Selbst Daten desselben Typs können eine wechselnde Struktur aufweisen

>
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

>
differierende, fehlende od. zusätzliche Attribute bzw. divergierende Strukturierung
auch innerhalb der Attribute selbst
Daten haben keine Struktur im Sinne von Attributen bzw. Tags

>
Notwendigkeit von Parsern o.ö. zur Strukturerkennung & -interpretation, da sich ein
solches Schema nicht von ‚Standard-Datenmodellen‘ adäquat verarbeiten ließe
Relationale Modelle definieren für die Attribute Integritätsbedingungen hinsichtlich
der zuzulassenden Datentypen
Große Anzahl möglicher Attribute & polymorphe interne Strukturierung der
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
o

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‘
o

relationale DB haben über einen längeren Zeitraum hinweg ein festes Schema
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)
o
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
o
OEM (Object Exchange Model)
o
Baummodell
Union-Datenmodell:
Hier wird eine Dokumentstruktur durch Vereinigung von Basisstrukturen erreicht
o


Problemski: Notwendigkeit vordefinierter Basisstrukturen – andernfalls bleiben die
Probleme semistrukturierter Modelle bestehen
Die Markup-Sprache HTML (Hypertext Markup Language):
Strukturierung durch Tags
o
Vorteil: Hohe Toleranz bei fehlenden/zusätzlichen Tags – deshalb eigentlich für
semistrukturierte Dokumente gut geeignet
o
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)
o
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):

o
Werden z.B, verwendet, um Verarbeitungsanweisungen anderer Sprachen zu
integrieren – PHP-Beispiel: <?php echo("Hello, World");?>
>
Kommentare: <!-- Kommentar-Text -->
>
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"?>
>
DTD definiert Entitäten & spezifiziert den erlaubten logischen Aufbau des XMLDokuments (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 :
o
Sequenz: (A1, A2)
Definiert die Reihenfolge von Elementen – logo: erst A1, dann A2 ...
o
Alternative: (A1|A2)
Definiert eine Wahlmöglichkeit zwischen Elementen - entweder muss A1 oder A2 enthalten sein
o
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!
o
Gruppierung von Elementen mit runden Klammern: ()
o
Kein Inhalt: EMPTY (das Element ist immer leer, wie z.B. bei <br>)
o
Beliebiger Inhalt: ANY
o
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:

o
CDATA
(Zeichenketten)
o
ID
(Attributwert gilt als eindeutige ID – optimal für IDs aus Datenbanken)
o
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)
o
NMTOKEN (einzelnes Token - Attributwert muss gleich einem Namen sein)
NMTOKENS (Liste von Tokens - dito für ein oder mehrere Namen)
o
ENTITY (Attributwert muss gleich ungeparster Entity sein)
ENTITIES (dito für ein oder mehrere Entities)
o
Aufzählungen & NOTATION-Aufzählungen
(Liste der erlaubten Werte; wird der Reihe nach angegeben und durch | getrennt)
Attribut-Vorgaben:
o
#REQUIRED
Erforderliches Attribut (muss explizit im Element vorkommen)
o
#IMPLIED
Optionales Attribut (darf fehlen & hart dann auch keinen Default-wert)
o
"..."
Default-Wert (falls das Attribut weggelassen wird)
o
#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:
//Anführungsstriche beachten!
o
<!ENTITY %adresse „(straße, plz, stadt)“>
o
Möchte man nun die Adresse als Unterelement einer Person verwenden, tut man dies über das
Entity %adresse:
<!ELEMENT person (%adresse; alter)>
o

//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
o
Also gleichsam als Standard verabschiedete DTDs (EAD-DTD, TEI-DTD, EBIND-DTD etc.) mit
einem fixen Schema
o
Vorteil: Lassen sich leicht in beliebige Datenbanken importieren
Separate DTDs
o
Z.B. für den Datenaustausch innerhalb von Firmen etc.
o
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
o
Als Teil des Dokuments selbst (interne Notation)
o
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.
o
Bei XML-Dokumenten od. DTDs kann dies durch die Definition eines
Erweiterungsmoduls geschehen
o
XML kann hier auch als Datenaustauschformat zwischen verschiedenartigen relationalen
DB fungieren (Die Tabellenstruktur wird dann als DTD erfasst)
o
XQL, XML-Q & Lorel sind mögliche Technologien zur Abfrage von XML basierten
Datenbanken
o
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
o
Hier werden die Ecken eines Graphen als Werte, Objekte & Typen interpretiert, wobei die Kanten des
Graphen dessen Ecken einander zuordnen
o
Ein GOOD-Graph besteht aus DB & DB-Schema in einer homogenen Darstellung
o
Mittels Graphmanipulationen werden Anfragen & Änderungen vorgenommen
Klassenlose DB-Modelle
Variante der OODBM
o

>
Vorteil: Höhere Flexibilität bei der Modellierung dynamischer & komplexer Anwendungen
>
Nachteil: Erschweren von Anfragen & effizienten Speicherstrukturen
Feature-Terme
Dienen der Wissensrepräsentation
o

Mit ähnlichen Eigenschaften, allerdings wird hier auf eine strenge Klassifizierung & Typisierung
verzichtet
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
o
Wird im technischen Bereich verwendet, um die dort weit verbreiteten hierarchischen ‚Ist Teil vonBeziehungen‘ zu unterstützen. MAD ermöglicht z.B. das Zusammensetzen von Basisobjekten
(Atomen) zu komplexen Objektstrukturen (Molekülen)