Vorlesung Datenbanken I 5. Komplex strukturierte DB

Prof. Dr. rer.nat.habil. Bernhard Thalheim
Information Systems Engineering
Department of Computer Science
Christian-Albrechts-University Kiel
Olshausenstr. 40
D - 24098 Kiel
Vorlesung Datenbanken I
SS 2008
5. Komplex strukturierte DB
5 Komplex strukturierte Datenbanken
5.1 XML-Datenbanken
Mit Hilfe von XML ist es möglich Daten zu strukturieren und in Form von XML-Dokumenten abzuspeichern. Die Struktur der Daten wird dabei mit Hilfe von XML-tags beschrieben. Aufgrund dieser
Möglichkeit wird XML als Daten- bzw. Austauschformat im World Wide Web immer populärer. Die
Dokumente können dann entweder im Dateisystem selbst oder in Datenbanken gespeichert werden.
Kommerzielle Datenbanksysteme wie IBMs DB2 UDB bieten bereits den XML-Extender als Erweiterung an, mit dem es möglich ist XML Dokumente mit den Vorteilen eines Datenbankmanagementsystems zu verwalten. Auf die XML Informationen in den Datenbanken oder Dateisystemen könnten
dann zukünftige Web-Server über XML Prozessoren zugreifen und diese z.B. mit Hilfe von HTML
zur Präsentation graphisch aufbereitet werden.
Von Electronic Data Interchange (EDI) erhofft man sich eine wichtige business application für
XML. Firmen könnten mit Hilfe von EDI Daten über ihre Produkte und Dienstleistungen im WWW
veröffentlichen. Und potentielle Kunden könnten diese Informationen automatisch vergleichen und
auswerten lassen. Weiter könnten geschäftliche Partner interne, vertrauliche Daten über sichere Kanäle
zwischen ihren Systemen austauschen oder sogenannte search robots könnten Daten verschiedenster
Quellen, welche ihre strukturierten Daten in Form von XML anbieten, automatisch in eigene Anwendungen integrieren. Vorstellbar wären z.B. Aktienkurse von diversen Finanzseiten oder Sportdaten von verschiedenen Nachrichtenanbietern. Außerdem werden sich weitere Möglichkeiten ergeben,
XML Daten auf verschiedenste Art und Weise zu integrieren, transformieren oder zu aggregieren.
Hat sich XML erst einmal als Datenformat dauerhaft durchgesetzt, ist es leicht vorstellbar, daß
viele Informationsquellen ihre Daten in XML Dokumente strukturieren und im Internet anbieten werden. Dann können Anwendungen wie EDI Wirklichkeit werden.
Um Informationen aus einer Vielzahl von XML Dokumenten zu extrahieren, braucht man eine
Anfragesprache. Diese soll strukturierte und inhaltsbezogene Anfragen ermöglichen, die als Ergebnis
sehr genaue Informationen liefern und keine 15000 Treffer, die mit den gewünschten Informationen
nicht viel gemeinsam haben, wie es bei heutigen Suchmaschinen keine Seltenheit ist. Demzufolge
wurden gleich mehrere XML Anfragesprachen wie z.B. Lorel , XML-QL, XQL, YATL, XML-GL
oder XSL entwickelt, die sich zum Teil stark unterscheiden.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
2
XML - Alternative zur HTML-Strukturierung
eXtensible Markup Language
entstanden aus:
MGML - minimal generalized markup language
SIMPL - simple internet markup language
in Spezialisierung von SGML
Standardisierung
1997/1998 XML 1.0
“Erweiterung” von HTML
start- und end-Bezeichner (evt auch / >)
Erweiterungsprobleme von HTML
Trennung von Struktur und Inhalt möglich (IR)
neue Bezeichner definierbar
<? XML version="1.0" ?>
<spass>
<brennt> Sage <quote> Gute Nacht</quote>
Alf. </brennt>
<anders> <quote> Gute Nacht, Alf. </quote></anders>
</spass>
<!- nur so zur Illustration -->
Weiterentwicklung z.Z. in 2 committees:
W3C mit partiell systematischen Hintergrund
MS mit Firmen-Monopoly
Euphorie in der “community”
kaum eine Konferenz ohne XML
auch wegen ASCII-Austausch
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
3
ISO 8879 (1986) Standard Generalized Markup Language (SGML)
• Text Encoding Initiative TEI ähnlich breit wie Web
• ISO 12083 Vereinheitlichung von elektronischen Manuskripten
Textsorten: Bücher, Artikel, Periodika
Einführung von DTD
• umrankt von HyTime (Hypermedia and Time-based structuring language, ISO 10744, 1997) [für Verlinkung von multimedialen Dokumenten]
(beliebige Dokumente mit hypermedialen Dokumenten ohne Strukturveränderung
Lokation über Namenraum, sturkturelle Adressierung, semantische Adressierung, über Koordinatenraum
XLink als vereinfachtes Linking-System
XPointer zur Spezifikation relativer Knoten und Teilbäume
und
DSSSL (Document Style and Semantic Specification Language, ISO 10179,
1996)
Erweiterungen und spezifische Anwendungen
• TopicMaps (ISO 13250) (Topic Navigation Maps) als Architektur für Darstellung
von thematischen Bezügen zwischen Informationsobjekten
Formen: topicmap, topic, name, occur, assoc, assocrl, facet, fvalue
• ICADD (International Committee for Accessible Document Design, 1991) für
Sehbehinderte
• Standard-DTD als Architekturen
Ersatzpfad HTML
• HyperText Markup Language über HyperText Transmission Protocol zur
Beschreibung von Bildschirmseiten
keine abstrakte inhaltliche Strukturierung des Textes, sondern nur formale Struktur eines Dokuments mit abstrakten Begriffen
Nebenpfad Tex
• D.E. Knuth in Wut über Textverarbeitung
• Tex78, Tex 82 als public domain auf Web (Pascal-Dialekt)
Trennung von Darstellungsinformation von Satzinformation mit eingelagertem Inhalt
• LaTex als Programmiersprache der 4. Generation für Texte
1988 (L. Lamport)
Text-Informationsverarbeitung
Informationen als Text oder in hierarchischer Struktur
evt. auch mit Verweisen
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
4
unterschiedliche Ebenen in Texten
in Texten: geordnete Anordnung von
abstrakten und konkreten Einheiten
nahe am hierarchischen Datenbankmodell
Buchstabenmengendeklaration
i.a. UTB-8 oder UCS-2
<?XML
<?XML
ENCODING=’UTF-8’?>
ENCODING=’EUC’-JP’?>
Klassen für Buchstaben: Latin-1; Extended Latin-A, Latin-B; griechisch, koptisch, kyrillisch, armenisch, hebräisch, ...
CAU Kiel, IfI, ISE
5.1.1
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
5
Primäre Strukturierung in XML/SGML
2-Ebenen-Architektur für Informationseinheiten
1. Ebene der konkreten Daten
2. Ebene der abstrakten Einheiten (Zuordnung von Funktionen zu Daten bzw. Gruppierung)
• Daten-Elemente für konkrete Daten
• Container-Elemente mit Konstruktoren
• Leere Elemente
Datenelemente als Zeichenfolgen
<!ELEMENT autor (#PCDATA)>
# als vordefiniertes Schlüsselwort
oft wird damit ‘Semantik’ vermutet
es findet KEINE Integritätskontrolle statt
Container-Elemente
Konstruktoren
• Tupel-Konstruktor
<!ELEMENT buch (autor, titel, verlag, jahr)>
• Wiederholungsausdrücke
a Element genau einmal
a? Element einmal oder keinmal
a+ Element mindestens einmal
a* beliebig oft
<!ELEMENT buch (autor+, titel, verlag?, jahr?)>
• Konnektoren
a , b Sequenz
a | b entweder-oder
a & b erstes nach zweitem oder zweites nach erstem Element (SGML)
β
CAU Kiel, IfI, ISE
SS 2008
Datenbanken I
5. Komplex strukturierte DB
6
Vorsicht vor Ambiguitäten
<!ELEMENT a ((b, c) | (b, d))>
<!ELEMENT a (b, (c | d )) >
Hierarchisches Datenmodell
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
buch (autor+, titel, verlag?, jahr?)>
autor (vorname+, familienname)>
vorname (#PCDATA)>
familienname (#PCDATA)>
Leere Elemente
<!ELEMENT autor ((vorname+, familienname) | unbekannt)>
<!ELEMENT unbekannt EMPTY>
Vorsicht vor implizit leeren Elementen
<!ELEMENT katalog (buch)*>
SGML erlaubt zusätzlich Exklusion/Inklusion
komplette Teilbäume beliebig oft wiederholt
bzw. vollkommen ausgeschlossen
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
a
b
c
d
(b, c) +(x) >
(#PCDATA) >
(b | d) >
(#PCDATA) >
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
a
b
c
d
(x*, b, x*, c, x*)>
(x | #PCDATA) >
(x*, (b | d), x*)) >
(#PCDATA) >
e
f
g
h
(f, g) -(y) >
(#PCDATA) >
((f, y?) | (h, y*))>
(#PCDATA) +(y) >
entspricht
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
können durch Normalisierung entfernt werden
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
e
f
g
h
(f, g) >
(#PCDATA) >
(f | h)) >
(#PCDATA) >
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
7
Attribute als zusätzliche Strukturierung
<!ATTLIST person geschlecht (m|f) #REQUIRED>
unterschiedliche Werte-Integritätsbedingungen
#REQUIRED: immer mit Wert belegt
#IMPLIED: Zeichenkette auch optional
‘‘wert’’ : mit Wert <wert> vorbelegt
#FIXED ‘‘wert’’ : Wert fest als Zeichekette vorgegeben
#UNSPECIFIED: SGML - ohne Wert
#CURRENT: SGML - zuletzt benutzter Wert der Geschwister
Wertemengen für XML-Attribute
#NAME: SGML-Zeichenkette
#NUMBER: SGML-Zahl
CDATA: beliebige Zeichenkette
#NMTOKEN: XML/SGML-Wort (auch mit Ziffer beginnend)
#NUTOKEN: SGML-Wort beginnend mit Ziffer
<!ELEMENT person (name, funktion,adresse)>
<!ATTLIST person
geschlecht (m|w) #REQUIRED
fakultaet
(1|2|3|4) "1"
geburtstag NMTOKEN #IMPLIED>
<!ELEMENT adresse EMPTY>
<!ATTLIST adresse
strasse
CDATA
#REQUIRED
nummer
NMTOKEN #REQUIRED
plz
NMTOKEN #REQUIRED
ort
CDATA
#REQUIRED >
NDATA: weitere Datentypen als Notationen
Name kann dann als Alias-Name weiterverwendet werden
<!NOTATION GIF PUBLIC
"+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION
CompuServe Graphic Interchange Format//EN">
Notation GIF mit Dokument “...” definiert,
Verweis auf Beschreibung, PUBLIC
SYSTEM - für private Notationen
Externe Dateien als ‘Entitäten’
SGML-Identifikationsnummer
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
8
<!ENTITY btu-logo SYSTEM "/standard/logo.gif" NDATA GIF>
oder mit Attributlisten und Quellenangaben
<!ELEMENT
bild
EMPTY>
<!ATTLIST
bild
quelle
ENTITY
#REQUIRED
typ
#NOTATION (GIF|BMP|JPG)
<!ATTLIST
form
method CDATA #FIXED "POST">
"GIF" >
Identifikatoren und Verweise
ID als Referenztyp
mit Möglichkeiten des Verweises IDREF auf ID
mit Rückverweispflege IDREFS
<!ATTLIST person
personalnummer
chef
mitarbeiter
ID
#IMPLIED
IDREF #IMPLIED
IDREFS #IMPLIED>
Unterstützung der Stern-Modellierung
− semantisch einfach abhängige Attribute
als XML-Attribute
− strukturell bedeutsame Attribute
als weiterführende XML-Elemente
Entitäten ... auch mit Alias-Konzept
&name; als Alias
als gekapselte Informationseinheiten
<!ENTITY BTU "Brandenburg University of Technology">
&BTU;
&lt; <
&gt; >
&amp;
&
&apos; ’
&quod; "
<!ENTITY ent-name SYSTEM "meinFile" >
<!ENTITY ent-name PUBLIC "public-name" NDATA notation>
<!ENTITY ent-name "meinFile" >
<!ENTITY ent-name "Zeichenkette" >
anlog Einfügen von files durch &name;
<!ENTITY eroeffnung SYSTEM "http://.../beta/eroeff.html">
sowie parametrisierte Referenz-Entitites mit % vor Name
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
9
<!ENTITY % end-name .... >
werden (sofort) expandiert bei Aufruf
damit auch hierarchische Kapselung von Dokumenten
Namen sollten eindeutig definiert sein, insbesondere für optionale Komponenten
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
10
Dokumententyp-Deklaration - DTD
kann auch wegfallen
<!DOCTYPE
<!DOCTYPE
<!DOCTYPE
<!DOCTYPE
<!DOCTYPE
el-name
el-name
el-name
el-name
el-name
>
SYSTEM "Filename" >
PUBLIC "publ-Name" >
PUBLIC "publ-Name" [Deklarationen] >
"File-Name" >
Markierte Anweisungen
<!ENTITY % draft "INCLUDE">
<!ENTITY % final "IGNORE">
<![%draft; [
<!ELEMENT buch(kommentar*, titel, inhalt, anhang?)>
]]>
<![%final; [
<!ELEMENT buch(titel, inhalt, anhang?)>
]]>
Verwendung von % anstelle von &
Vorsicht mit verschachtelten Markierungen !
Vorteil: Deklaration als Parameter-Entität:
<!DOCTYPE buch SYSTEM "book.dtd" [
<!ELEMENT name (#PCDATA)>
....
<!ENTITY % m.spec-text
"name|begriff|hervorgehoben" >
....
<!ELEMENT para
(#PCDATA|%m.spec-text;)*>
<!ELEMENT zitat
(#PCDATA|%mspec-text|auslassung)*>
]>
....
<buch> ....
</buch>
analog können auch Attribute verschachtelt werden bzw. als globale Attribute
definiert werden
<!ENTITY
<!ENTITY
<!ENTITY
<!ENTITY
%
%
%
%
id-status
"#IMPLIED">
spec-status "#IMPLIED">
x.global
"">
a.global "
%x.global;
%a.linking;
id
ID
%id-status;
spec
CDATA
%spec-status,">
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
11
XML erfordert nicht notwendigerweise eine DTD
• Wohlgeformtheit
korrekte Baumstruktur, nicht fehlerhaft, eindeutig
• Validierbarkeit (wie bei SGML)
Standardisierte DTD können auch als Architekturen genutzt werden (→ 2.2.2.)
DocType kann auf externe Datei verweisen (mit Element-,
Attribut-, Notationen- und Entity-Deklarationen)
DTD kann auch vollständig im DocType mit enthalten sein
(mit [] eingeschlossen)
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
Weitere Dokument-Strukturen:
Tabellen
Zeile 1
Zeile 2
Zeile 3
Spalte 1 Spalte 2 Spalte 3
Wert 1
Wert 2
Wert 3
Wert 4
Wert 5
Wert 6
wird erzeugt mit DTD für Tabellen
<!ELEMENT tblrows (tbldefs,tblrow)+>
<!ELEMENT tbldefs (tblcdef)+>
<!ATTLIST tbldefs
%a.format-alle-spalten;>
<!ELEMENT tbldef
EMPTY>
<!ATTLIST tbldef
%a.format-eine-spalte;>
<!ELEMENT tblrows (tblrow)+>
<!ATTLIST
%a.format-alle-zeilen;>
<!ELEMENT tblrow
(tblcell)+>
<!ATTLIST tblrow
%a.format-eine-zeile;>
<!ELEMENT tblcell (#PCDATA)>
<!ATTLIST tblcell
%a.format-zeile;
colstart NMTOKEN #REQUIRED
colspan
NMTOKEN "1"
rowspan
NMTOKEN "1">
dagegen für einfache Tabellen mit folgender DTD
<!ELEMENT
<!ELEMENT
<!ELEMENT
tblrows
tblrow
tblcell
(tblrow)+>
(tblcell)+>
(#PCDATA)>
12
analog zu LaTex
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
13
dann ist Tabelle definiert durch
<table> <tabldefs>
<tblrows> <tblrow>
<tblcell
<tblcell
<tblcell
<tblcell
</tblrow>
<tblrow>
<tblcell
<tblcell
<tblcell
<tblcell
</tblrow>
<tblrow>
<tblcell
<tblcell
</tblrow>
<tblrow>
<tblcell
<tblcell
<tblcell
</tblrow>
<tbldef/> <tabldef/> <tabldef/> </tabldef>
colstart="1"></tblcell>
colstart="2">Spalte 1</tblcell>
colstart="3">Spalte 2</tblcell>
colstart="4">Spalte 3</tblcell>
colstart="1">Zeile 1</tblcell>
colstart="2">Wert 1</tblcell>
colstart="3">Wert 2</tblcell>
colstart="4" rowspan="2">Wert 3</tblcell>
colstart="1">Zeile 2</tblcell>
colstart="2" colspan="2">Wert 4</tblcell>
colstart="1">Zeile 3</tblcell>
colstart="2">Wert 5</tblcell>
colstart="4" colspan="2">Wert 6</tblcell>
einfache Tabelle mit Struktur
<tblrows>
<tblrow>
.....
<tblcell>Zeile 3</tblcell>
<tblcell>Wert 7</tblcell>
<tblcell>Wert 8</tblcell>
<tblcell>Wert 9</tblcell>
</tblrow>
</tblrows>
LaTex-Definition dagegen
\begin{tabular}{|c|c|c|c|} \hline
& Spalte 1 & Spalte 2 & Spalte 3 \\ \hline
Zeile 1
& Wert 1
& Wert 2
& Wert 3 \\ \cline{1-3}
Zeile 2
& \multicolumn{2}{c|}{Wert 4} & \\ \hline
Zeile 3
& Wert 5 & \multicolumn{2}{c|}{Wert 6} \\ \hline
\end{tabular}
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
14
Graphen als gerichtete Graphen
mit Mirror-Konzept als hierarchische Struktur
0
1
3
2
4
<!ELEMENT
<!ELEMENT
<!ATTLIST
<!ELEMENT
<!ATTLIST
5
gag
(knoten)+>
knoten
(knoten|verweis)>
knoten
id
ID
#REQUIRED
inhalt
ENTITY #REQUIRED>
verweis EMPTY>
verweis
zu-knoten IDREF #REQUIRED>
damit ist dann die Struktur von oben halbkorrekt spezifiziert durch
<gag> <knoten ID="k0" inhalt=knoten-0">
<verweis zu-knoten="k2"/>
</knoten>
<knoten ID="k1" inhalt=knoten-1">
<knoten ID="k2" inhalt="knoten-2">
<knoten ID="k4" inhalt="knoten-4"></knoten>
</knoten>
<knoten ID="k3" inhalt="knoten-3">
<verweis zu-knoten="k4"/>
<knoten ID="k5" inhalt="knoten-5"></knoten>
</knoten>
</knoten>
</gag>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
Gerichte azyklische Graphen mit bewerteten Kanten
<!ELEMENT
<!ELEMENT
<!ATTLIST
<!ELEMENT
<!ATTLIST
<!ELEMENT
<!ATTLIST
gagb
(knoten)+>
knoten
(kante)*>
knoten
id
ID
#REQUIRED
inhalt
ENTITY #REQUIRED>
kante
(knoten|verweis)>
kante
bewertung
(a|b|c) #REQUIRED>
verweis EMPTY>
verweis
zu-knoten IDREF #REQUIRED>
Graph mit Bewertungen der Kanten halbkorrekt spezifiziert durch:
<gagb> <knoten ID="k0" inhalt=knoten-0">
<kante bewertung="a">
<verweis zu-knoten="k2"/>
</kante>
</knoten>
<knoten ID="k1" inhalt=knoten-1">
<kante bewertung="c">
<knoten ID="k2" inhalt="knoten-2">
<kante bewertung="c">
<knoten ID="k4" inhalt="knoten-4"></knoten>
</kante>
</knoten> </kante>
<kante bewertung="b">
<knoten ID="k3" inhalt="knoten-3">
<kante bewertung="a">
<verweis zu-knoten="k4"/>
</kante>
<kante bewertung="a">
<knoten ID="k5" inhalt="knoten-5"></knoten>
</kante></knoten></kante></knoten>
</gagb>
15
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
DTD als Umgebung
<?xml version="1.0" standalone="yes">
<!DOCTYPE personal SYSTEM "personal.dtd">
<personal>
<mitarbeiter mitarbid="ma007" leiter="ma0815">
Alf Blaha </mitarbeiter>
.... </personal>
mit der zugehörigen DTD
<!ELEMENT mitarbeiter (#PCDATA)>
<!ATTLIST mitarbeiter mitarbid ID #REQUIRED
leiter IDREF #IMPLIED > ...
falls standalone auf ‘‘no’’ steht, dann muß DTD angegeben werden
XML
• XML-Dokument
• Dokument-Typ-Deklaration
• Stil-Deklaration (eXtended Styesheet Language)
XML-Dokumente als Bäume
• Wurzel
• Elemente
• Text
• Attribute
• Bezeichner (namespace)
• Verarbeitungsanweisungen
• Kommentare
16
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
<?xml version="1.0"?>
<PERIODIC_TABLE>
<ATOM>
<NAME>Aluminum</NAME>
<ATOMIC_WEIGHT>26.98154</ATOMIC_WEIGHT>
<ATOMIC_NUMBER>13</ATOMIC_NUMBER>
<OXIDATION_STATES>3</OXIDATION_STATES>
<BOILING_POINT UNITS="Kelvin">2740</BOILING_POINT>
<MELTING_POINT UNITS="Kelvin">933.5</MELTING_POINT>
<SYMBOL>Al</SYMBOL>
<DENSITY UNITS="grams/cubic centimeter">
2.7
</DENSITY>
<ELECTRON_CONFIGURATION>[Ne] 3s2 p1 </ELECTRON_CONFIGURATION>
<COVALENT_RADIUS UNITS="Angstroms">1.18</COVALENT_RADIUS>
<ELECTRONEGATIVITY>1.61</ELECTRONEGATIVITY>
<ATOMIC_RADIUS UNITS="Angstroms">1.43</ATOMIC_RADIUS>
<HEAT_OF_VAPORIZATION UNITS="kilojoules/mole">
290.8
</HEAT_OF_VAPORIZATION>
<ATOMIC_VOLUME UNITS="cubic centimeters/mole">
10
</ATOMIC_VOLUME>
<HEAT_OF_FUSION UNITS="kilojoules/mole">
10.7
</HEAT_OF_FUSION>
<IONIZATION_POTENTIAL>5.986</IONIZATION_POTENTIAL>
<SPECIFIC_HEAT_CAPACITY UNITS="Joules/gram/degree Kelvin">
0.9
</SPECIFIC_HEAT_CAPACITY>
<THERMAL_CONDUCTIVITY UNITS="Watts/meter/degree Kelvin">

237
</THERMAL_CONDUCTIVITY>
</ATOM>
...
</PERIODIC_TABLE>
17
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
18
XSL für Darstellung
Verallgemeinerung von CSS (Cascading StyleSheets)
noch im Vorschlagsstadium (Jan. 99 - 1. Version; Nov. 99 call)
Ziel: Definition eines Dokumentes, das sich in HTML-Dokument konvertieren läßt je nach
angewählter Umgebung z.B.
<?xml version="1.0"?>
<Springer:Katalog title="New books in March 2000">
<Springer:Book title="Entity-Relationship Modeling">
<Springer:Image src="http://www.springer.de/beta.gif"/>
<Springer:Author>Bernhard Thalheim</Springer:Author>
<Springer:Body>Database technology and ...</Springer:Body>
</Springer:Book>
</Springer:Katalog>
wird umgeformt in das HTML-Dokument
<HTML> <HEAD> <TITLE>New books in March 2000</TITLE></HEAD>
<BODY><H1>Entity-Relationship Modeling</H1>
<img src="http://www.springer.de/beta.gif"/>
<H2>Bernhard Thalheim</H2>
<P>Database technology and ...</P>
</BODY>
</HTML>
Komponenten:
1. Konstruktionsregeln
<xsl>
<rule>
<root/>
<HTML> <HEAD>
<TITLE>Style Sheet </TITLE>
</HEAD>
<BODY> <children/></BODY>
</HTML>
</rule>
</xsl>
bestehen aus 2 Teilen:
• Muster (pattern)
<rule> <target-element type="name"/>
<DIV font-family="sans-serif"
line-spacing="1.1"
font-size="12pt"
font-weight="bold"
margin-left="30%"
color="#333366">
<A href="=ancestor(’author’,this).
getAttribute(’named’)+ ’.html’">
children/></A>
</DIV>
</rule>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
19
named weil MS nicht mit ID umgehen kann
• Aktion (action) (z.B. DIV zum Einsammeln der children-Elemente)
Funktion
ancestor
ancestorChildNumber
childNumber
children
formatNumber
formatNumberList
getAttribute
hierarchicalNumberRecursive
item
length
parent
path
tagName
text
Rückgabewert
nächster Ahne mit dem übergebenen Namen
nächster Ahne mit dem übergebenen Namen als Zahl (der
wievielte) - gut für Kapitelnummern
um das wievielte Element in der Reihe handelt es sich beim
Kindelement
die Kindelemente der Hierarchie
Zahl als String
Liste von Zahlen samt Trennzeichen (für Gliederungen)
Wert eines Attributes
die Nummern von Kindelementen - ähnlich den
formatNumber- Funktionen (zum Beispiel: 2.1.2)
das angegebene Element
Länge einer Elementmenge
der direkte Ahne des Elements
Array inklusive der Elementnummer, bezogen auf die Geschwisterelemente/Eltern ...
der Elementname
Wert des Elements
2. Stilregeln z.B. begebenheit wird in Grau gesetzt, außer für den Attributwert
wichtig (dann fett und rot)
<style-rule>
<target-element type="begebenheit">
<attribute name="kateg" value="wichtig"/>
</target-element>
<apply font-weight="bold" color="red"/>
</style-rule>
<style-rule>
<target-element type="begebenheit"/>
<apply color="#666666">
</style-rule>
damit auch Funktionen einbettbar (z.B. Autoren mit Nummer in der Aufzählung)

<eval>formatNumberList(hierarchicalNumberRecursive("author",this),
"1", ".")</eval>.
oder auch selbstgeschriebene Funktionen (z.B. Monatsausgabe)
<xsl><define-script><![CDATA[
function showMonth(m) {if (m == 1) return "Januar";
else if (m == 2) return "Februar";
else if (m == 3) return "M&auml;rz";
else if (m == 4) return "April";
else if (m == 5) return "Mai";
else if (m == 6) return "Juni";
else if (m == 7) return "Juli";
else if (m == 8) return "August";
else if (m == 9) return "September";
else if (m == 10) return "Oktober";
else if (m == 11) return "November";
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
20
else if (m == 12) return "Dezember";
}]]>
</define-script>

<rule><target-element type="month"/>
<TD background="#999999" color="#ffff33">
<eval>showMonth(this.text)</eval>
</TD>
</rule>
</xsl>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
21
Periodentabelle mit XSL:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="PERIODIC_TABLE">
<html>
<xsl:apply-templates/>
</html>
</xsl:template>
<xsl:template match="ATOM">
<P>
<xsl:apply-templates/>
</P>
</xsl:template>
</xsl:stylesheet>
verbunden mit:
<?xml version="1.0"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

</xsl:transform>
und wird transformiert zu
<HTML>
<P>
Hydrogen
H
1
1.00794
20.28
13.81
0.0899
</P>
<P>
Helium
He
2
4.0026
4.216
0.95
0.1785
</P>
</HTML>
CAU Kiel, IfI, ISE
5.1.2
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
22
Sekundäre Strukturierung in XML/SGML
HyTime-Standard: SGML-Dokumente mit hypermedialen Informationen
• Repräsentation von Hyperlinks (Relationen der Anker in Dokumenten
mit Rollen (Semantik))
damit auch unabhängige Verwaltung der Links
• Lokationen in strukturierten Informationsgebilden
• Adressierung über den Namenraum (ID-Attribute, Entitäten zur Lokalisierung)
• strukturelle Adressierung (relative hierarchische und/oder sequentielle Position in Informationsbäumen
• semantische Adressierung in Abhängigkeit von Objekt-Eigenschaften
(damit auch spezielle Anfragesprachen)
• Adressierung über den Koordinatenraum (abstrakt definerte Achsen
(Raum-, Zeit-)
• abstrakte Repräsentation hypermedialer Prozesse (Ereignisverläufe, Koordinatenräume)
HyTime-engine (z.Z. nur für linking und adressing)
abgeleitet: XLink für XML (vereinfachtes Linking-System)
XPointer (Sprache zur Spezifikation relativer Knoten und Teilbäume im Informationsbaum)
XLink und XPointer: XML Adressierungs- und Navigationssystem
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
23
in Verallgemeinerung:
• General Architecture (z.Z. noch ohne engine)
• Topic (Navigation) Maps (ISO/IEC 13250) mit architektonischen Formen
• topicmap zur Deklaration für Architektur
• topic zur Deklaration von Gegenstand und Konzepten (evt. auch mehrere Informationsobjekte umfassend, über Namen)
• name eines topics in Sprachvarianten, Abkürzungen ...
• occur für relevante Informationsobjekte
•
•
•
•
assoc für Assoziierungslinks zwischen topics und roles
assocrl für benutzungsspezifische Rollen
facet für zusätzliche Attribut-Wert-Paare zur weiteren Charakterisierung
fvalue Werte für parametrische Attribute von Informationsobjekten von facet
• ICADD (International Committee for Accessible Document Design) z.B.
ICADD-DTD für Braille-Schrift etc.
• allgemeine Architekturen zur Unterstützung von ISO 12083 oder TEI
Vielzahl von DTD’s
• darstellungsbezogene wie HTML 4.x oder ICADD ohne strukturelle Einschränkungen
• standardisierte wie z.B. ISO 12083 für wissenschaftliche Texte und TEI für geisteswissenschaftliche Texte
• zentrale proprietäre von Organisationen
• proprietäre benutzer-orientierte zur Konsistenz der Aufgaben
Zusammenhang von DTD’s am besten durch DTD-Netze
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
24
Architekturen für
• Ausstattung von DTD’s mit Funktionalität
• zur Einführung von beliebige abstrakten meta∗ -Ebenen
SGML - Extended Facilities: Architectural Form Definition Requirements
(AFDR)
z.B. Meta-DTD “person.dtd”
<!AFDR "ISO/IEC 10744:1997">
<!ELEMENT person
(surname, givenname, info*)>
<!ATTLIST person
sex
(male|female) #IMPLIED>
<!ELEMENT surname
(#PCDATA)>
<!ELEMENT givenname (#PCDATA)>
<!ELEMENT info
(#PCDATA)>
<!ATTLIST #ALL
spec
CDATA
#IMPLIED>
#ALL wird immer vererbt
darauf aufbauend CLIENT-DTD “kunde.dtd”
• Bezug zur Meta-DTD StandardPerson
• architecture support attributes (externe Entität, Element-form, Form-Attribut zum Namen (ArcFormA), renamer-Attribute zum Verbinden von Meta-Client-Namen StdPersAtts
werden bei Element- und Attributlisten als Steuerattribute (control attributes) verwendet (StdPersAF zu person in kunde) (sex auf geschlecht)
• Instanz dann:
<!DOCTYPE kunde SYSTEM "kunde.dtd">
<kunde anrede="Herr" geschlecht="m">
<name> <nachname> Zitterbacke </nachname>
<vorname> Alf </vorname> </name>
<firma kommentar="sowieso pleite">Braun-Torf-Universal GmbH
</firma>
<funktion kommentar="gerade bef\"{o}rdert">Leiter DV </funktion>
</kunde>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
25
<?IS10744 ArcBase StandardPerson>
<!NOTATION AFDRMeta PUBLIC
"ISO/IEC 10744:1997// AFDR Meta-DTD Notation//EN">
<!ENTITY PersonDTD SYSTEM "person.dtd" CDATA AFDRMeta>
<!NOTATION StandardPerson PUBLIC
"-//LOCAL/NOTATION AFDR ARCBASE Person Architecture//EN"
-- A base architecture used in conformance with the
Architectural Form Definition Requirements of
Internation Standard ISO/IEC 10744. -->
<!ATTLIST #NOTATION StandardPerson
ArcDTD
CDATA
"PersonDTD"
ArcDocF
NAME
"person"
ArcFormA
NAME
"StdPersAF"
ArcNamrA
NAME
"StdPersAtts">
<!ELEMENT kunde
(name, firma, funktion)>
<!ATTLIST kunde
anrede
CDATA
#IMPLIED
geschlecht (m|w)
#REQUIRED
StdPersAF
NAME #FIXED "person"
StdPersAtts CDATA
"spec anrede
sex geschlecht
MAPTOKEN male m
female
w">
<!ELEMENT name
(nachname, vorname)>
<!ELEMENT nachname (#PCDATA)>
<!ATTLIST nachname StdPersAF NAME
#FIXED "surname">
<!ELEMENT vorname
(#PCDATA)>
<!ATTLIST vorname
StdPersAF NAME #FIXED "givenname">
<!ELEMENT firma
(#PCDATA)>
<!ATTLIST firma
kommentar
CDATA
#IMPLIED
StdPersAF
NAME
#FIXED "info"
StdPersAF
CDATA
"spec kommentar">
<!ELEMENT funktion
(#PCDATA)>
<!ATTLIST funktion
kommentar
CDATA
#IMPLIED
StdPersAF
NAME
#FIXED "info">
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
Architektur-Deklaration in XML
• Client-DTD in XML
header
<?IS10744 arch
name=
public-id=
dtd-system-id=
doc-elem-form=
form-att=
renamer-att=
"StandardPerson"
"-//LOCAL//NOTATION AFDR ARCBASE
Person Architecture//EN"
"person.dtd"
"person"
"StdPersAF"
"StdPersAtts"
?>
Inhalt der Client-DTD
<!ELEMENT kunde
(name,
<!ATTLIST kunde
anrede
CDATA
geschlecht (m|w)
StdPersAF
NMTOKEN
StdPersAtts CDATA
firma, funktion)>
#IMPLIED
#REQUIRED
#FIXED "person"
"spec anrede
sex geschlecht
MAPTOKEN male m
female
w">
<!ELEMENT name
(nachname, vorname)>
<!ELEMENT nachname (#PCDATA)>
<!ATTLIST nachname
StdPersAF NMTOKEN
#FIXED "surname">
<!ELEMENT vorname
(#PCDATA)>
<!ATTLIST vorname
StdPersAF NMTOKEN #FIXED "givenname">
<!ELEMENT firma
(#PCDATA)>
<!ATTLIST firma
kommentar
CDATA
#IMPLIED
StdPersAF
NMTOKEN #FIXED "info"
StdPersAF
CDATA
"spec kommentar">
<!ELEMENT funktion
(#PCDATA)>
<!ATTLIST funktion
kommentar
CDATA
#IMPLIED
StdPersAF
NMTOKEN
#FIXED "info">
• Darstellung über markierte Teile
<![ &XML; [
<?IS10744 arch
name=
public-id=
dtd-system-id=
doc-elem-form=
form-att=
"StandardPerson"
"-//LOCAL//NOTATION AFDR ARCBASE
Person Architecture//EN"
"person.dtd"
"person"
"StdPersAF"
26
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
"StdPersAtts"
renamer-att=
?>
]]>
<![ %SGML; [ <?IS10744 ArchBase StandardPerson> ... ]]>
<!ELEMENT kunde ...
>
....
Aktivierung mit declaration subset
<?XML version="1.0"?>
<!DOCTYPE kunde SYSTEM "kunde.dtd" [
<!ENTITY % XML "INCLUDE">
<!ENTITY % SGML "IGNORE">]>
<kunde>
....
</kunde>
27
β
CAU Kiel, IfI, ISE
SS 2008
Datenbanken I
5. Komplex strukturierte DB
28
Verbindung von Element-Formen in Meta-DTD und ElementDeklarationen in Client-DTD
Meta-DTD
<!ELEMENT
a
(b, (c | d), f*)>
kann verbunden werden mit Client-DTD durch:
• Anreicherung
<!ELEMENT
<!ELEMENT
a
a
(x+, (b & y), (c|d), f*) +(z)>
(x+, (b, e), (a,x,b), f* >
(SGML)
• durch unsichere oder inkorrekte Erweiterung
<!ELEMENT
<!ELEMENT
<!ELEMENT
a
a
a
(b, (c | d | x), f*)>
(b, b, (c | d ), f*)>
( (b | e), (c | d ), f*)>
• durch Einschränkung
<!ELEMENT
<!ELEMENT
a
a
(b, (c | d ), f)>
(b, c, f+ )>
analoge Verbindungen für Attribut-Formen und Werten (z.B. IDREFS zu
IDREF, CDATA zu NMTOKEN
in Meta-DTD auch mehrere Attributlisten kombinierbar
<!ELEMENT
<!ATTLIST
att1
att2
<!ATTLIST
att3
att4
att5
a
a
(b,c)>
(a1|a2|a3) "a1"
CDATA
#REQUIRED>
a
NMTOKEN
#IMPLIED
(order|disorder) "order"
NMTOKEN
"novamp" >
wird in Client-DTD
<!ATTLIST
a
att2
CDATA
att3
NMTOKEN
att5
NMTOKEN
#REQUIRED
#IMPLIED
"vamp" >
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
29
Support-Attribute
zur Festlegung der Beziehungen Meta-DTD zu Client-DTD
1. allgemeine Zuordnung der Meta-DTD:
• ArcDTD: Deklaration der externen Entität in der Meta-DTD (XML:
dtd-public-id, dtd-system-id), evt. auch URL
für Parameter-Entität oder generelle Entität
• ArcQuant: SGML-Kardinalitäten (Name-Länge, ...) werden für Client gefiltert (XML: quantity)
ArcQuant
CDATA
"ATTCNT
NAMELEN
GRPCNT
100
64
100
• ArcDocF: Zuordnung des Dok-Elements der Client-DTD zu ElementForm der Meta-DTD (XML: doc-elem-form)
Beispiel einer Meta-DTD
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
a1
a2
b
c
(b*, c*)>
(b, b+, c, c+)>
(#PCDATA)>
(#PCDATA)>
daraus abgeleitete Client-DTD nur mit b und c
<!ELEMENT x1
<!ELEMENT x2
<!ELEMENT y
<!ATTLIST y
ArcForm
<!ELEMENT z
<!ATTLIST z
ArcForm
(y,y,z,z)>
(y+, z+)>
(#PCDATA)>
NMTOKEN
#FIXED
(#PCDATA)>
NMTOKEN
#FIXED
"b">
"c">
damit wird Dokument-Instanz möglich
<!DOCTYPE x1 SYSTEM
<x1>
<y>y-daten</y>
<y>y-daten</y>
<z>z-daten</z>
<z>z-daten</z>
</x1>
"x.dtd">
da für x1 keine Zuordnung
deshalb Zuordnung einer entsprechenden architektonische Form
mit der Zuordnung
<!ATTLIST
....
ArcDocF
#NOTATION
NAME
Beispiel
"a2" ....
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
30
wird dann daraus
<!DOCTYPE a2 SYSTEM
<a2>
<b>y-daten</b>
<b>y-daten</b>
<c>z-daten</c>
<c>z-daten</c>
</a2>
"a.dtd">
2. Steuer-Attribute für Eigenschaften der Architekturen:
• Kontrollattribute bereits in Client-DTD mit festem oder StandardWert belegt
• Kontrollattribute erst in Instanz belegt
Zuordnungen:
• Element-Formen: Benennung eines Steuerattributes, das in der ClientDTD für diese Zuordnungsaufgabe genutzt werden kann (mit ArcFormA
(XML: form-att))
Festlegung des Namens des Support-Attributes
<!ATTLIST
#NOTATION
Beisp
... ArcFormA
NMTOKEN
... >
"BeispAF"
Nutzung in einer Element-Deklaration
<!ATTLIST
BeispAF
... >
y
NMTOKEN
#FIXED "b"
• Attribut-Formen: Benennung eines Steuerattributes, das in AttributDeklarationen ein Steuerattribut bezeichnet ArcNamrA (XML: renamer-att)
z.B. Meta-DTD hat Attribut-form
<!ATTLIST
mod
info
b
CDATA
CDATA
#IMPLIED
#REQUIRED
...>
Einleitung der Attribut-Umbenennung in der Client-DTD:
<!ATTLIST
#NOTATION Beisp
... ArcNamrA
NAME
"BeispRA" ... >
• automatisches Übertragen auf untergeordnete Strukturen kann verhindert werden mit ArcSuprA (XML: suppressor-att)
3. automatische Zuordnung für gleichbenannte Element-Formen (bei XML
und SGML als Default-Option) ArcAuto bzw. nArcAuto (XML: auto):
z.B. automatische Zuordnung von
<!ELEMENT
<!ATTLIST
info
typ
a
a
(b,b) >
CDATA
#REQUIRED
(A|B|C) "A" >
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
31
der Meta-DTD
<!ELEMENT
<!ATTLIST
info
typ
a
a
(b+) >
CDATA
(A|B|C|D|E)
#IMPLIED
#IMPLIED >
analog auch für ArcDataF (XML: data-form) (für externe Datenentitäten, deren Notationsname mit keinem der architektonischen Notationsnamen übereinstimmt)
und ArcBridF (XML: bridge-form) für Elemente mit einer ID und
keinem ArcForm-Attribut, denen Standardmäßig keine Form zugewiesen ist
4. für gezielte Aktivierung von einzelnen Bereichen der Meta-DTD in ClientDTD (für modularisierte Meta-DTD mit marked section) durch SupportAttribut ArcOpt (XML: options)
damit in Meta-DTD auch übersichtliche Deklaration von Varianten
<!ATTLIST
#NOTATION
...
ArcOpt CDATA
WeitBeisp
"block-1.1 block-1.3 block-2.2
block-3.3 block-3.4 block-4.2
block-4.7 block-5.2 block7.2" ... >
Werte von ArcOpt sind Parameter-Entitäten, deren Werte auf INCLUDE
gesetzt werden sollen in markierten Sektionen:
Externe Speicherung der Kontrollattribute mit link process declaration (LPD)
unterstützbar
Name ist mißverständlich
• explizite LPD’s (analog zu architektonischer Verarbeitung: Überführung
einer Dokumenten-Instanz in eine Dokumenten-Instanz, die konform zu
anderer DTD gebildet ist)
<!DOCTYPE
<!LINKTYPE
kunde SYSTEM "kunde.dtd" >
kunde-person kunde #IMPLIED SYSTEM
"kunde-person.lpd">
<kunde> ... </kunde>
<!LINKTYPE
kunde-person
<!ATTLIST
firma
info
kunde
CDATA
#IMPLIED SYSTEM
"kunde-person.lpd" [
#IMPLIED >
]>
• implizite LPD’s (als Vereinfachung der expliziten (Konvention der Anreicherung einer Dokumenten-Instanz mit zusätzlichen Link-Attributen
ohne sie zu verändern))
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
32
• einfache LPD’s (wie bei impliziten; Dokument-Element mit zusätzlichen
Link-Attributen)
LPD’s nur in SGML
damit auch Verbindung einer inhaltlichen DTD mit darstellungsorientierter
DTD
analog zu Tex-Umbenennung von Schlüsselwörtern
Inhaltliche Einschränkung (Hinzufügen von Semantik) mit Struktur-Mustern
(XML: XML-Schema)
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
33
XML Schema
wie normales XML-Dokument bzw. XML-DTD, zu Beschreibung der Inhalte von Elementen
und Attributen
<elementType name="name">
<mixed/>
</elementType>
type für Klassen- bzw. Typspezifikation
mixed für Character data und auch für Elemente
<datatype name="zipCode">
<basetype name="string"/>
<lexicalRepresentation>
<lexical>99999</lexical>
<lexical>99999-9999</lexical>
</lexicalRepresentation>
</datatype>
mit Varianten für ZIP-Kode bzw. PLZ
mit picture-Typ
damit dann ZIP so definierbar:
<elementType name="zip">
<datatypeRef name="zipCode"/>
</elementType>
vergleiche mit DTD (dort keine Constraints
damit sogar komplexere Typen definierbar
<elementType name="address">
<sequence>
<elementTypeRef name="company" minOccur="0" maxOccur="1">
<elementTypeRef name="name" minOccur="1" maxOccur="1"/>
<elementTypeRef name="street" minOccur="1" maxOccur="2"/>
<elementTypeRef name="city" minOccur="1" maxOccur="1"/>
<elementTypeRef name="state" minOccur="1" maxOccur="1"/>
<elementTypeRef name="zip" minOccur="1" maxOccur="1"/>
</sequence>
</elementType>
sequence wie , in DTD (für Reihenfolge)
mit Referenzen auf existierende andere Typen
Häufigkeit wie mit +, *, ? in DTD (nur feiner)
anstelle von Paraterdefinitionen wie:
<!ENTITY % address
"company?, name, street+, city, state, zip">
<!ELEMENT billing.address (%address;)>
<!ELEMENT shipping.address (%address;)>
in XMLSchema über Architekturen:
<archetype name="address" model="refinable">
<sequence>
<elementTypeRef name="company" minOccur="0" maxOccur="1"/>
<elementTypeRef name="name" minOccur="1" maxOccur="1"/>
<elementTypeRef name="street" minOccur="1" maxOccur="2"/>
<elementTypeRef name="city" minOccur="1" maxOccur="1"/>
<elementTypeRef name="state" minOccur="1" maxOccur="1"/>
<elementTypeRef name="zip" minOccur="1" maxOccur="1"/>
</sequence>
</archetype>
<elementType name="billing.address">
<archetypeRef name="address"/>
</elementType>
<elementType name="shipping.address">
<archetypeRef name="address"/>
</elementType>
Vorteil: redefinierbar, explizite Hierarchie
damit dann fast ER-Modellierung nachvollziehbar mit comp(R, E)-Komplexität
Parser definiert über explizite Expansion
als Beispiel mit komplexeren DTD:
<!DOCTYPE purchase.order SYSTEM "po.dtd">
<purchase.order>
<date>16 June 1967</date>
<billing.address>
<name>Beton-Torf-Universal GmbH</name>
<street>German Titow Str. 17</street>
<city>Klein-Schilda</city>
<state>BB</state>
<zip>03046</zip>
</billing.address>
<items>
<item>
<quantity>3</quantity>
<product.number>248</product.number>
<description>gelbe Fenster</description>
<unitcost>99.95</unitcost>
</item>
<item>
<quantity>1</quantity>
<product.number>1632</product.number>
<description>blaue M\"ulltonnen</description>
<unitcost>4.95</unitcost>
</item>
</items>
</purchase.order>
<!DOCTYPE schema SYSTEM "o:/reference/w3c/schema/structures.dtd">
<schema>
<archetype name="address" model="refinable">
<sequence>
<elementTypeRef name="company" minOccur="0" maxOccur="1"/>
<elementTypeRef name="name" minOccur="1" maxOccur="1"/>
<elementTypeRef name="street" minOccur="1" maxOccur="2"/>
<elementTypeRef name="city" minOccur="1" maxOccur="1"/>
<elementTypeRef name="state" minOccur="1" maxOccur="1"/>
<elementTypeRef name="zip" minOccur="1" maxOccur="1"/>
</sequence>
</archetype>
<elementType name="billing.address">
<archetypeRef name="address"/>
</elementType>
<elementType name="shipping.address">
<archetypeRef name="address"/>
</elementType>
.....
</schema>
Deklaration der anderen ‘wrapper’ im Schema
<elementType name="items">
<elementTypeRef name="item" minOccur="1"/>
</elementType>
<elementType name="item">
<sequence>
<elementTypeRef name="quantity" minOccur="1" maxOccur="1"/>
<elementTypeRef name="product.number" minOccur="1" maxOccur="1"/>
<elementTypeRef name="description" minOccur="1" maxOccur="1"/>
<elementTypeRef name="unitcost" minOccur="1" maxOccur="1"/>
</sequence>
</elementType>
<elementType name="purchase.order">
<sequence>
<elementTypeRef name="date" minOccur="1" maxOccur="1"/>
<elementTypeRef name="billing.address" minOccur="1" maxOccur="1"/>
<elementTypeRef name="shipping.address" minOccur="0" maxOccur="1"/>
<elementTypeRef name="items" minOccur="1" maxOccur="1"/>
</sequence>
</elementType>
<elementType name="company">
<mixed/>
</elementType>
<elementType name="name">
<mixed/>
</elementType>
<elementType name="street">
<mixed/>
</elementType>
<elementType name="city">
<mixed/>
</elementType>
<elementType name="state">
<mixed/>
</elementType>
<datatype name="zipCode">
<basetype name="string"/>
<lexicalRepresentation>
<lexical>99999</lexical>
<lexical>99999-9999</lexical>
</lexicalRepresentation>
</datatype>
<elementType name="zip">
<datatypeRef name="zipCode"/>
</elementType>
<elementType name="product.number">
<mixed/>
</elementType>
<elementType name="description">
<mixed/>
</elementType>
<datatype name="quantityType">
<basetype name="integer"/>
<minExclusive>0</minExclusive>
</datatype>
<elementType name="quantity">
<datatypeRef name="quantityType"/>
</elementType>
<datatype name="currency">
<basetype name="decimal"/>
<precision>8</precision>
<scale>2</scale>
</datatype>
<elementType name="unitcost">
<datatypeRef name="currency"/>
</elementType>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
<elementType name="date">
<datatypeRef name="dateTime"/>
</elementType>
damit können analog beliebige XML-Grammatiken definiert werden
37
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
38
XForms als Anwendung von XML Schema
für Beschreibung des Datenmodelles unabhängig von technischer Umgebung
(Verallgemeinerung von HTML Form)
• mit expliziten Daten-Modell
• Benutzer-Interface
• Datenaustausch mit DBMS-Server
z.B. in obigem Beispiel Lieferadresse mit Eingabe
<group name="purchase.order">
<group name="shipping.address">
<string name="name"/>
<string name="street"/>
<string name="city"/>
<string name="state"/>
<string name="zip">
<mask>ddddd</mask>
<!-<mask>ddddd</mask>
<!-<mask>ddddd-dddd</mask> <!-<mask>lldsdll</mask>
<!-<mask>llddsdll</mask>
<!-<mask>ldlsdld</mask>
<!-</string>
</group>
</group>
German PLZ -->
US ZIP code -->
US ZIP+4 code -->
UK postal code -->
UK postal code -->
Canadian postal code -->
Einbettung in Umgebung:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML-XForms 1.0//EN"
"http://www.w3.org/TR/xhtml-forms1/DTD/xhtml-xforms1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en" lang="en">
<head>
<title>Purchase Order</title>
<xform xmlns="http://www.w3.org/2000/xforms"
action="http://www.my.com/cgi-bin/receiver.pl"
method="postXML"
id="po_xform">
<model>
<group name="purchase.order">
<group name="shipping.address">
<string name="name"/>
<string name="street"/>
<string name="city"/>
<string name="state"/>
<string name="zip">
<mask>ddddd</mask>
</string>
</group>
</group>
</model>
<instance>
<purchase.order>
<shipping.address>
<name>Beton-Torf-Universal GmbH</name>
<street>German Titow Str. 17</street>
<city>Klein-Schilda</city>
<state>BB</state>
<zip>03046</zip>
</shipping.address>
</purchase.order>
</instance>
</xform>
</head>
<body>
<h1>Shipping Information</h1>
<form name="po_xform">
Name: <input name="purchase.order.shipping.address.name"/><br/>
Stra&szlig;e: <input name="purchaseOrder.shipTo.street"/><br/>
Stadt: <input name="purchaseOrder.shipTo.city"/><br/>
Land: <input name="purchaseOrder.shipTo.state"/><br/>
PLZ: <input name="purchaseOrder.shipTo.zip"/><br/>
<button onclick="submit(’po_xform’)">Submit</button>
</form>
</body>
</html>
Weitere Datentypen
Boolean mit Wahrheitswerten TRUE,FALSE
string String mit Masken mask (COBOL-like)
number Zahlen (integer, decimal) mit (min,max)
money Währungen mit currency ($ etc.)
und decimals und (min,max)
date Datum mit (min, max) in precision (year, month, day)
time Tageszeit mit (min,max) und precision (hours, miniutes, seoconds)
duration Dauer mit precision
uri mit Verbindungsprotokoll schema
binary für Binärdaten mit type
sowie default-Attribute-Wert, fixierten (read-only),
geforderten (required) Input-Werten, berechneten Werten
Konstruktoren: Aufzählung (value-Folge), Vereinigung, Tupel,
variablen Typen (case-Blöcke),
Felder (group mit max/minOccur und Index quantity)
verteilte Namen (RFC)
Grammatik zur Konstruktion weiterer Typen
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
XML Namensraum
zur Vermeidung von Namenskonflikten
Lokalisierungsabstraktion
(lokaler Name, globaler Name (evt. über Erweiterung))
(URI-Name, lokaler Name)-Paare in Sinne von
< {http://www.w3.org/TR/xhtml1} head >
spezielles Attribut und assoziierte Präfixe
<... xmlns:foo="http://www.w3.org/TR/xhtml1">
...
<foo:head>...</foo:head>
...
</...>
als namespace: xmlns:prefix=‘‘URI’’
mit default namespace: ohne Präfix xmlns=‘‘URI’’
spezielles Attribut xmlns:NS prefix
Namespace- Prefix frei gewählt
i.a. vor der eigentlichen Verwendung in einem
übergeordnetem Element oder DTD
Wert: eindeutige URL (namespace-Name)
gilt von dem Element, in dem er deklariert
wird, für alle enthaltenen Elemente (bis auf Widerruf)
streng hierarchisch
Pfade mit entsprechendem Kontext
über identifizierbare Namen
Namen im Namensraum
Identifikatoren im Namensraum
40
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
41
XPath
als Adressierungsschema (auch für Dokumentteile)
für alle Dokumentteile (Wurzel, Elemente, Texte, Attribute, Namensraum-Knoten, Verarbeitungsinstruktionen, Kommentare)
Pfade werden als Ausdruck evaluiert zu
• Knoten
• Boolescher Wert
• Zahl
• String
auf der Grundlage ihres Kontexts
• ihres Knotens
• Positionspaar (Position, Größe)
• Variablenbindungen
• Namensraum-Deklaration der Umgebung
als bedingte/iterative Baum-Tracing-Sprache (Achsen)
• Kind-Knoten (erster, alle, x-ter)
• Nachbar (linker, rechter)
• Vaterknoten
orthogonal dazu
• Inhalt von Elementen oder Attributen
• Element selbst
in beliebiger Höhe/Tiefe und Zusammenstellung
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
42
XLink
Verknüpfung mehrerer XML- Dokumente untereinander
Attribut xml:link
• inline-Links: Link innerhalb des gleichen Dokumentes
• “out-of-line-” Links: Link in anderem Dokument verwaltet
verbunden mit Aktionen bei Aktivierung des Verweise
• Anzeige show mit neuem Fenster new, mit Erweiterung embed oder Überschreibung
replace
• Aufruf actuate erfolgt automatisch auto oder auf Benutzeraktion user
• Weiterverfolgen von komplexen Links eingeschränkt auf steps=‘‘i’’ Schritte
Unterscheidung in
• einfache Links xml:link=‘‘simple’’
• komplexe erweiterte Links
<?xml version="1.0">
<einfachesDokum>
<title> XLinkDemo </title>
<section id="Link-Ziel">
<para> Erster Paragraph in dieser Sektion </para>
<para> Mehr Information zu XLink ist erreichbar unter
<reference xml:link="simple"
href="http://www.org/XLink"> W2C.</reference>
</para>
</section>
<section id="Link-Source">
<para> Erster Paragraph in der zweiten Sektion. </para>
<para> Man sollte
<reference xml:link="simple" href="Link-Ziel"> zuerst
</referenve> lesen. </para>
</section>
</einfachesDokum>
Erweiterte Links zu mehreren Dokumenten
gelinkte Ressource wird über einen “Locator” spezifiziert,
der Inhalt des Linking Elements ist

<link xml:link="extended">
<loc xml:link="locator" href="http://www.w3.org"/>
<loc xml:link="locator" href="http://www.leo.org"/>
<loc xml:link="locator" href="http://www.sun.com/>
</link>
auch in Gruppen
(Verwaltung in separatem Dokument)

<link xml:link="group" steps="2">
<doc xml:link="document" href="all_the_links"/>
</link>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
43
damit auch Deklaration in DTD etc. möglich
<!ELEMENT FOOTNOTE (#PCDATA)>
<!ATTLIST FOOTNOTE
xmlns:xlink CDATA #FIXED "http://www.thalheim.edu/bsp/herm"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED >
<!ELEMENT AUTHOR (#PCDATA)>
<!ATTLIST AUTHOR
xmlns:xlink CDATA #FIXED "http://www.thalheim.edu/cv/herm"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED>
<!ELEMENT IMAGE EMPTY>
<!ATTLIST IMAGE
xmlns:xlink
CDATA #FIXED "http://www.thalheim.edu/bild/alte"
xlink:type
CDATA #FIXED "simple"
xlink:href
CDATA #REQUIRED
xlink:show
CDATA #FIXED "onLoad"
xlink:actuate CDATA #FIXED "embed" >
damit sind dann auch komplexere Seiten aufbaubar
<?xml version="1.0" standalone="no"?>
<ERSteering xmlns:xlink="http://www.peterchen.edu/ERSteering">
<CHAIR xlink:type="simple" xlink:show="embed"
xlink:href="BernhardThalheim.xml" />
<VICE-CHAIR
xlink:type="simple" xlink:show="embed"
xlink:href="TokWngLing.xml" />
<LIASON
xlink:type="simple" xlink:show="embed"
xlink:href="PeterChen.xml" />
<ERConfCHAIR
xlink:type="simple" xlink:show="embed"
xlink:href="DavidEmbley.xml" />
</ERSteering>
wird expandiert zu
<?xml version="1.0" standalone="no"?>
<ERSteering xmlns:xlink="http://www.peterchen.edu/ERSteering">
<CHAIR xlink:type="simple" xlink:show="embed"
xlink:href="BernhardThalheim.xml" />
<PERSON ID="p1035" SEX="M">
<NAME> <GIVEN>Bernhard</GIVEN><SURNAME>Thalheim</SURNAME></NAME>
<BIRTH><DATE>...</DATE><PLACE>..., Sachsen</PLACE></BIRTH>
</PERSON>
<VICE-CHAIR xlink:type="simple" xlink:show="embed"
xlink:href="TokWanLing.xml" />
<PERSON ID="p007" SEX="M">
<NAME> <GIVEN>Tok Wang</GIVEN><SURNAME>Ling</SURNAME></NAME>
<BIRTH><DATE>...</DATE><PLACE>..., Singapore</PLACE></BIRTH>
</PERSON>
<LIASON
xlink:type="simple" xlink:show="embed"
xlink:href="PeterChen.xml" />
<PERSON ID="p4711" SEX="M">
<NAME> <GIVEN>Peter P.-S.</GIVEN><SURNAME>Chen</SURNAME></NAME>
<BIRTH><DATE>...</DATE><PLACE>..., Taiwan</PLACE></BIRTH>
</PERSON>
<ERConfCHAIR
xlink:type="simple" xlink:show="embed"
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
xlink:href="DavidEmbley.xml" />
<PERSON ID="p4711" SEX="M">
<NAME> <GIVEN>David</GIVEN><SURNAME>Embley</SURNAME></NAME>
<BIRTH><DATE>...</DATE><PLACE>..., Taiwan</PLACE></BIRTH>
<FAMILY ...><WIFE ... /><CHILD1 .... /> ...
<CHILD14 .... /></FAMILY>
</PERSON>
44
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
45
damit auch mehrfache Links möglich
<ERWebsite xmlns:xlink="http://www.peterchen.edu/ERCommunity"
xlink:type="extended" xlink:title="ERWebsite">
<NAME xlink:type="resource" xlink:role="source">
ER Community Website </NAME>
<HOMESITE xlink:type="locator"
xlink:href="http://www.kathydavis.edu/ERHomesite"
xlink:role="default"/>
<MIRROR xlink:type="locator"
xlink:title="ER Website - German Mirror" xlink:role="ge"
xlink:href="http://www.informatik.tu-cottbus.de/ER96"/>
<MIRROR xlink:type="locator"
xlink:title="ER Website - Singapore Mirror" xlink:role="sg"
xlink:href="http://www.cs.nsu.sg/ER98"/>
<CONNECTION xlink:type="arc" xlink:from="source"
xlink:to="mirror"
xlink:show="replace"
xlink:actuate="onRequest"/>
</ERWebsite>
mit DTD
<!ELEMENT ERWebsite (NAME, HOMESITE, MIRROR*) >
<!ATTLIST ERWebsite
#FIXED "http://www.peterchen.edu/ERCommunity"
xmlns:xlink CDATA
xlink:type (extended) #FIXED "extended"
xlink:title CDATA
#IMPLIED
xlink:role
CDATA
#IMPLIED >
<!ELEMENT NAME (#PCDATA)>
<!ATTLIST NAME
xlink:type (resource) #FIXED
"resource"
xlink:role
CDATA
#IMPLIED
xlink:title CDATA
#IMPLIED>
<!ELEMENT HOMESITE (#PCDATA)>
<!ATTLIST HOMESITE
xlink:type (locator) #FIXED
"locator"
xlink:href
CDATA
#REQUIRED
xlink:role
CDATA
#IMPLIED
xlink:title CDATA
#IMPLIED>
<!ELEMENT MIRROR (#PCDATA)>
<!ATTLIST MIRROR
xlink:type (locator) #FIXED "locator"
xlink:href
CDATA
#REQUIRED
xlink:role
CDATA
#IMPLIED
xlink:title CDATA
#IMPLIED >
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
46
XPointer
Adressierung einer Reßource innerhalb eines XML- Dokuments
mit XPath und Baum-Tracing-Sprache
child
descendant
parent
ancestor
following-siblings
preceeding-siblings
following
preceeding
attribute
namespace
self
descendant-or-self
ancestor-or-self
sowie Auswertungsfunktionen und Prädikate
Kinder des Kontextknotens
Kinder, Enkel etc. des Kontextknotens
Eltern (oder leer falls Wurzel)
alle Vorgänger bis zur Wurzel
alle folgenden Geschwister
all vorhergehenden Geschwister
alle folgenden Knoten
alle vorgehenden Knoten
Attribute des Knotens
Namespace-Deklaration des Knotens
Knoten selbst
oder
oder
an einen XLink angehängt (durch den Fragment Identifier # getrennt)
Selektor selector(arg1, arg2, ...) anhand der Dokumentstruktur (Baum!)
Beispiel einer URI mit (location, fragment) und Fragment (function(poiter expression))
http://www.w3c.org/bar.xml#xptr(art/sect[pos() &lt;= 5])
root().child(2) - 2. Sohn des Dokument-Elements
child(2) - 2. Sohn des Dokument-Elements
child(5, mylink, show, new) - 5. Element des Dokuments, dessen Tagname “mylink” und dessen “show”-Attribut “new”ist
span(child(2, para).id(23).following(2,#pi), child(-1).string(1,‘W3C’’,1
- Dokumentausschnitt beginnend mit der 2. Processing Instruction des Elements mit der ID
“23” des 2. <para>-Elements, bis zum String “W3C” im letzten Element des Dokuments
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
47
XDNL - XML Document Navigation Language
Navigation: Szenario für Dokumentlesen je nach Umgebung in Abhängigkeit von der Benutzerinteraktion
Szenario führt zu Blatt-Szenen, die abhängen von Benutzerinteraktion
“Story” kann sich ändern in Abhängigkeit von aktueller Benutzung
Stil: Arrangement bzw. Dekoration der Szenen
XML-Dokument wird in Blöcke unterteilt
XML-Dokument
Blattknoten A
... Blattknoten Q
Blockbeschreibung
• Inhalt des Blattknoten (als Teil des Dokumentes)
• Verweisverbindungen, Navigationstruktur
analog zu pdf-file-display
• Überblick über das Dokument
• Browsing des Inhaltes
• gewünschte Inhalte
damit auch Auswahl des Inhaltes
Reduktion des Datentransfers
Anwendung unterschiedlicher Stile
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
Ein etwas längeres Beispiel
<?xml version="1.0"?>
<Address>
<Title>MY Business Address Book</Title>
<Company>
<CompanyName>Foo Japan</CompanyName>
<Person>
<LastName>Ito</LastName><FirstName>Taro</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-0000</Phone>
<Fax>+81-3-0000-1111</Fax>
</Person>
<Person>
<LastName>Kato</LastName><FirstName>Yoshiko</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-0000</Phone>
<Fax>+81-3-0000-1111</Fax>
</Person>
...
<Person>
<LastName>Wada</LastName><FirstName>Jiro</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-0123</Phone>
<Fax>+81-3-0000-1234</Fax>
</Person>
</Company>
<Company>
<CompanyName>Foo Foo</CompanyName>
<Person>
<LastName>Manabe</LastName><FirstName>Kazuo</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-2222</Phone>
<Fax>+81-3-0000-3333</Fax>
</Person>
<Person>
<LastName>Yamamoto</LastName><FirstName>Hanako</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-2222</Phone>
<Fax>+81-3-0000-3333</Fax>
</Person>
...
<Person>
<LastName>Yamada</LastName><FirstName>Taro</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-2222</Phone>
<Fax>+81-3-0000-3333</Fax>
</Person>
<Person>
<LastName>Tanaka</LastName><FirstName>Jiro</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-2222</Phone>
<Fax>+81-3-0000-3333</Fax>
</Person>
48
<Person>
<LastName>Suzuki</LastName><FirstName>Miho</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-2222</Phone>
<Fax>+81-3-0000-3333</Fax>
</Person>
</Company>
</Address>
XDNL Blattdokumentes
<?xml version="1.0"?>
<!DOCTYPE xdnl:documents SYSTEM
"http://www.w3.org/TR/xdnl/xdnl.dtd">
<xdnl:documents>

<xdnl:leaf-document select="Address" type="CompanyList">
<xdnl:copy-of select="//Title"/>
<xdnl:for-each chunk="series" counter-size="10" select="Company">
<xdnl:link href="#xdnl:{$class}-Company{@page}">
<xdnl:copy-of select="CompanyName"/>
</xdnl:link>
</xdnl:for-each>
<xdnl:element name="Instruction">

<xdnl:link href="#xdnl:{$class}-CompanyList{@page-1}">
Previous 10 Companies</xdnl:link>
<xdnl:link href="#xdnl:{$class}-CompanyList{@page+1}">
Next 10 Companies</xdnl:link>
</xdnl:element>
</xdnl:leaf-document>

<xdnl:leaf-document select="Address/Company" type="Company">
<xdnl:copy-of select="CompanyName"/>
<xdnl:for-each chunk="series" counter-size="10" select="Person">
<xdnl:link href="#xdnl:{$class}-EachPerson{@page}">
<xdnl:copy-of select="LastName"/><xdnl:copy-of select="FirstName"/>
</xdnl:link>
</xdnl:for-each>
<xdnl:element name="Instruction">
<xdnl:link href="#xdnl:{$class}-Company{@page-1}">Previous</xdnl:link>
<xdnl:link href="#xdnl:{$class}-Company{@page+1}">Next</xdnl:link>
</xdnl:element>
</xdnl:leaf-document>

<xdnl:leaf-document select="Address/Company/Person" type="EachPerson">
<xdnl:copy-of select="*"/>
<xdnl:element name="Instruction">
<xdnl:link chunk="head" chunk-size="{$Screen.cols/3}"
href="#xdnl:{$class}-EachPerson{@page-1}">Previous Person</xdnl:link>
<xdnl:link chunk="head" chunk-size="{$Screen.cols/3}"
href="#xdnl:{$class}-Page{@page+1}">Next Person</xdnl:link>
<xdnl:link chunk="head" chunk-size="{$Screen.cols/3}"
href="#xdnl:{$class}-Index1">Back to Index</xdnl:link>
</xdnl:element>
</xdnl:leaf-document>
</xdnl:documents>
kann benutzt werden um weitere Blattdokumente zu generieren
Telefonliste der 1. Firma
<?xml version="1.0"?>

<leaf-document id="xdnl:phone-CompanyList1">
<Address>
<Title>MY Business Address Book</Title>
<xdnl:link href="phone-Company1">Foo Japan</xdnl:link>
<xdnl:link href="phone-Company2">Foo Foo</xdnl:link>
...
<xdnl:link href=":phone-Company10">Foo Bar Co.</xdnl:link>
<Instruction>
<xdnl:link href="phone-CompanyList1-1">Next 10 Companies</xdnl:link>
</Instruction>
</Address>
</leaf-document>
Telefonliste der Firma 1 in anderer Version
<?xml version="1.0"?>
<leaf-document id="xdnl:phone-CompanyList1-1">
<Address>
<Title>MY Business Address Book</Title>
<xdnl:link href="phone-Company11">Foo Foo Bar Ltd.</xdnl:link>
<xdnl:link href="phone-Company12">Bar Ltd.</xdnl:link>
...
<xdnl:link href="phone-Company20">Bar Bar Co.</xdnl:link>
<Instruction>
<xdnl:link href="phone-CompanyList1">Prev 10 Companies</xdnl:link>
</Instruction>
</Address>
</leaf-document>
Telefon der Firma 1
<?xml version="1.0"?>

<leaf-document id="xdnl:phone-Company1">
<Address>
<Company>
<CompanyName>Foo Japan</CompanyName>
<xdnl:link href="phone-EachPerson1">
<LastName>Ito</LastName><FirstName>Taro</FirstName>
</xdnl:link>
<xdnl:link href="phone-EachPerson2">
<LastName>Kato</LastName><FirstName>Yoshiko</FirstName>
</xdnl:link>
...
<xdnl:link href="phone-EachPerson8">
<LastName>Wada</LastName><FirstName>Jiro</FirstName>
</xdnl:link>
<Instruction>
<xdnl:link href="phone-Company2">Next</xdnl:link>
</Instruction>
</Company>
</Address>
</leaf-document>
Telefonliste von Personen

<leaf-document id="xdnl:phone-EachPerson1">
<Address>
<Company>
<Person>
<LastName>Ito</LastName><FirstName>Taro</FirstName>
<Email>[email protected]</Email>
<Phone>+81-3-0000-0000</Phone>
<Fax>+81-3-0000-1111</Fax>
<Instruction>
<xdnl:link href="phone-EachPerson2">Next</xdnl:link>
</Instruction>
</Person>
</Company>
</Address>
</leaf-document>
Eine entsprechende XSL erlaubt Generierung entsprechender HTML-Dokumente
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xdnl="http://www.w3.org/2000/xdnl">
<xsl:output method="html" />

<xsl:template match="/">
<HTML>
<HEAD>
<TITLE>MY Business Address Book</TITLE>
</HEAD>
<BODY>
<xsl:apply-templates/>
</BODY>
</HTML>
</xsl:template>

<xsl:template match="*">
<xsl:apply-templates/>
<BR/>
</xsl:template>
<xsl:template match="leaf-document">
<xsl:element name="DIV">
<xsl:attribute name="id"><xsl:value-of select="@id"/></xsl:attribute>
<xsl:apply-templates/>
</xsl:element>
</xsl:template>
<xsl:template match="LastName">
<xsl:apply-templates/>,
</xsl:template>
<xsl:template match="Email">
<A>
<xsl:attribute name="href">mailto:<xsl:value-of select="."/></xsl:attribute>
<xsl:apply-templates/>
</A>
<BR/>
</xsl:template>
<xsl:template match="Phone">
<A>
<xsl:attribute name="href">tel:<xsl:value-of select="."/></xsl:attribute>
<xsl:apply-templates/>
</A>
<BR/>
</xsl:template>
<xsl:template match="Instruction">
<DIV>
<xsl:apply-templates/>
</DIV>
</xsl:template>
<xsl:template match="xdnl:link">
<A>
<xsl:attribute name="href">
<xsl:value-of select="@href"/><xsl:text>.html</xsl:text>
</xsl:attribute>
<xsl:apply-templates/>
</A>
</xsl:template>
</xsl:stylesheet>
z.B.
<HTML>
<HEAD> <TITLE>MY Business Address Book</TITLE>
</HEAD>
<BODY>

<DIV id="xdnl:phone-CompanyList1">MY Business Address Book<BR />
<A href="phone-Company1.html">Foo Japan</A>
<A href="phone-Company2.html">Foo Foo</A>
...
<A href="phone-Company10.html">Foo Bar Co.</A>
<DIV> <A href="phone-CompanyList1-1.html">Next 10 Companies</A></DIV>
<BR />
</DIV>
</BODY>
</HTML>
oder
<HTML> <HEAD><TITLE>MY Business Address Book</TITLE></HEAD>
<BODY>

<DIV id="xdnl:phone-EachPerson1">Ito, Taro<BR />
<A href="mailto:[email protected]">[email protected]</A><BR />
<A href="tel:+81-3-0000-0000">+81-3-0000-0000</A><BR />+81-3-0000-1111<BR />
<DIV><A href="phone-EachPerson2.html">Next</A></DIV>
<BR /><BR /><BR />
</DIV>
</BODY>
</HTML>
CAU Kiel, IfI, ISE
5.1.3
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
53
Erweiterungen von XML/SGML
• HTML-MATH
• Cascading Style Sheets CSS
• Java Universal Markup Language (JUMBO)
• CSL - Chemical markup language (auf Jumbo-Basis)
• Web Interface Definition Language (WIDL)
mit Service-Definition (binding ...)
binding über I/O-Variable
mit Erfolgs- und Fehlerbedingung für Output-Variable
REGION für Teil des HTML-Dokumentes
Erweiterungen von SGML mit komplexeren Ausdrucksmöglichkeiten für DTD ( XML ⊂ SGML )
• Web-SGML ( XML ⊂ Web-SGML, Web-SGML ¬ ⊂ SGML,
SGML ¬ ⊂ Web-SGML )
• revidiertes SGML ( Web-SGML ⊂ revSGML, SGML ⊂ revSGML )
• SGML extended facilities ( revSGML ⊂ SGML-X )
Varietät von Implementationen
günstig z.Z. XML storage, compiliert auf Perl Datenstrukturen (mit PerlXML-Parser), verwaltet durch Perl-Module, versandt als HTML-Seiten bzw.
SMTP/NNTP-Nachrichten
CAU Kiel, IfI, ISE
5.1.4
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
54
XML-QL als Anfragesprache
in Verallgemeinerung von SQL
mit partiellem Lernen aus den Fehlern von SQL
Aufsetzen auf verabschiedeten Standardteilen
• Filtern und Extraktion von Teilen aus XML-Dokumenten
• Transformation von Resultaten
entspricht dem Cottbuser Vorschlag für Informationsdienste:
Inhaltsbeschreibung von Sichten
generate < mapping > : < variables >
from < HERM subschema >
where < selection condition >
order by < condition >.
⇒
< structure >
Präsentationsbeschreibung in Abhängigkeit vom Nutzer, Kanal, techn. Umgebung und
Stilvorschriften:
represent < unit > uses < style guide > |
< abstraction > | < presentation function > |
< scaling rules >.
evt. auch mit Darstellungsalternativen:
alternative representation for < unit >
uses < style guide > |
< abstraction > | < presentation function > |
< scaling rules >.
Funktionsspezifikation: (Suche, Navigation, Support, ...)
add to < unit > browsing definition < condition >
add to < unit > { index | navigation | search | selection }
function < specification >
add to < unit > analysis function < specification >
add to < unit > analysis scenario < specification >
add to < unit > refresh scenario < specification >.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
55
Originalvorschlag
gegeben sei DTD mit z.B.
<!ELEMENT book (author+, title, publisher)>
<!ATTLIST book year CDATA>
<!ELEMENT article (author+, title, year?, (shortversion|longversion))>
<!ATTLIST article type CDATA>
<!ELEMENT publisher (name, address)>
<!ELEMENT author (firstname?, lastname)>
Matching auf der Grundlage von Pattern
WHERE <book>
<publisher><name>Addison-Wesley</></>
<title> $t</>
<author> $a</>
</> IN "www.a.b.c/bib.xml"
CONSTRUCT <result>
<author> $a</>
<title> $t</>
</>
(shortcut < / name > einfach als < / >
Konstruktion auch in genesteter Form
Damit könnte man aus XML-Daten
<bib>
<book year="1995">

<title> An Introduction to Database Systems </title>
<author> <lastname> Date </lastname> </author>
<publisher> <name> Addison-Wesley </name > </publisher>
</book>
<book year="1998">
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
<author> <lastname> Date </lastname> </author>
<author> <lastname> Darwen </lastname> </author>
<publisher> <name> Addison-Wesley </name > </publisher>
</book>
</bib>
folgendes Resultat erhalten:
<result>
<author> <lastname> Date </lastname> </author>
<title> An Introduction to Database Systems </title>
</result>
<result>
<author> <lastname> Date </lastname> </author>
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
</result>
<result>
<author> <lastname> Darwen </lastname> </author>
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
</result>
besser mit direkter Gruppierung
und Bindung des Inhaltes content as
WHERE <book>
<title> $t </>
<publisher><name>Addison-Wesley </> </>
</> CONTENT_AS $p IN "www.a.b.c/bib.xml"
CONSTRUCT <result><title> $t </>
WHERE <author> $a</> IN $p
CONSTRUCT <author> $a</>
</>
dann Resultat:
<result>
<title> An Introduction to Database Systems </title>
<author> <lastname> Date </lastname> </author>
</result>
<result>
<title> Foundation for Object/Relational Databases: The Third Manifesto </tit
<author> <lastname> Date </lastname> </author>
<author> <lastname> Darwen </lastname> </author>
</result>
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
Weiterhin auch mit üblichen SQL-Konstrukten
WHERE <article>
<author>
<firstname> $f </> // firstname $f
<lastname> $l </> // lastname $l
</>
</> CONTENT_AS $a IN "www.a.b.c/bib.xml"
<book year=$y>
<author>
<firstname> $f </> // join on same firstname $f
<lastname> $l </> // join on same lastname $l
</>
</> IN "www.a.b.c/bib.xml",
y > 1995
CONSTRUCT <article> $a </>
auch mit Variablen für ‘tags’
WHERE <$p>
<title> $t </title>
<year>1995</>
<$e> Smith </>
</> IN "www.a.b.c/bib.xml",
$e IN {author, editor}
CONSTRUCT <$p>
<title> $t </title>
<$e> Smith </>
</>
p für irgendeine Wurzel, e mit Einschränkung
sowie Pfadvariable
Implementationen: z.B. LORE
57
CAU Kiel, IfI, ISE
5.1.5
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
58
Übersetzung von HERM in XML-Bäume
HERM ist besser geeignet als einfache ER-Modelle
• Typen bereits genestete Struktur
• Typen höherer Ordnung
• unäre Kardinalitätsbeschränkungen mit Participation-Semantik
HERM ist besser geeignet als UML
• Typen haben klar definierte Semantik
• Schematakomponenten sind integriert
• durch Codesign auch Pragmatik und Entwicklungsmethodik
XML ist Einschränkung von HERM
• XML Schema und XForms geeignet für hierarchische Extrakte von HERM
• HERM-Spezialisierung entspricht Schema-Typen-Spezialisierung
• einelementige Kardinalitäten
ansonsten clustering mit pivoting
• Varianten von I-Objekten über XDNL-Zugang
• XML - objekt-orientiertes hierarchisches Datenmodell
• Mehrfach-Szenarien werden mit XDNL-Varianten verbunden
damit ist Übertragung von HERM-Schemata in XML Schemata determiniert
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
59
Übersetzung
• Objektifizierung mit Master-Slave-Mirror
für Auflösung mit ID’s
alle Typen, auf die verwiesen wird
unter Beachtung der Exklusionsabhängigkeiten
• starke Aggregationen sind exklusiv (Komponente gehört zu genau einem Supertyp)
• schwache (nicht-exklusive) Aggregationen werden in (evt. auch künstliche) MirrorBeziehung abgebildet
evt. mit Varianten je nach Interaktion un Szenarien
• schrittweise Übersetzung von HERM-Typen von 0. Ordnung bis zu i.
Ordnung
Entity-Typen werden direkt übertragen
Attributtypen sind auch in HERM exklusiv, gehören zu ER-Typen
Cluster-Typen werden in Varianten übertragen
Relationship-Typen werden ggf. auch kolladiert ((1, 1)(1, 1)-Typen) bzw. objektifiziert
Hierarchien müssen nicht aufgelöst werden, sondern werden direkt als Subtypen realisiert
• Sichten werden als Anfragen in XML-QL formuliert, falls nicht bereits
in Schema-Definition eingegangen
• Integritätsbedingungen der Datenbank für XML-Interaktion müssen spezifisch behandelt werden
• Translationsmechanismus wird analog für die Datenbank mit HERMReengineering-Zugang erweitert
damit ist dann Direktanbindung der Datenbank möglich
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
60
5.1.6 Die Anfragesprachen Lorel, XML-QL und XQL
Lorel
Die Lightweight Object REpository Language (LOREL) ist eine datenbankorientierte Anfragesprache. Sie wurde an der Stanford University von S.Abiteoul, D.Quass, J.McHugh, J.Widom und J.Wiener
entwickelt undimplementiert. Der Prototyp ist unter http://www-db.stanford.edu/lore zu finden. Lorel
ist eine benutzerfreundliche Sprache im SQL/OQL Stil. Entwickelt wurde die Sprache zum Umgang
mit großen Datenbeständen, sie soll Daten aus heterogenen Informationsquellen integrieren sowie
Daten in allgemeine Datenaustauschformate transformieren können.
XML-QL
Auch XML-QL ist eine datenbankorientierte Anfragesprache, die demzufolge auch die selben Aufgaben hat wie Lorel. XML-QL wurde an den AT & T Labs von Alin Deutsch, Mary Fernandez, Daniela
Florescu, Alon Levy und Dan Suciu als Teil des Strudel-Projektes entwickelt. Der Prototyp ist unter
http://www.research.att.com/sw/tools/xmlql zu finden. XML-QL besitzt eine explizite CONSTRUCTKlausel, die zur Erstellung eines neuen Dokumentes aus dem Ergebnis der Anfrage dient.
XQL
XML Query Language ist eine dokumentorientierte Anfragesprache. Sie wurde von Jonathan Robie
(Texcel Inc.), Joe Lapp (webMethods Inc.) und David Schach (Microsoft) entwickelt. Die Hauptaufgaben der Sprache ist hauptsächlich die Suche innerhalb von sehr großen Dokumenten (Volltext
Suche) und demzufolge muß XQL auch einen sehr effizienten Zugriffsmechanismus auf die Quellen
besitzen. Da wir auf semistruktierte Daten zugreifen, soll XQL Volltext- und strukturierte Anfragen
integrieren können. Mit Hilfe von XML-Behältern kann XQL auch Anfragen über mehrere Dokumente stellen, indem diese zu einem Dokument zusammengefügt werden. XQL ist keine vollständige
Abfragesprache und bietet nur reduzierte Ausdrucksmöglichkeiten, kann aber in einer Vielzahl von
Fällen eingesetzt werden und ist leicht zu erlernen. XQL ist eine natürliche Erweiterung zur XSL
pattern language. Sie wurde erweitert um eine Boolesche Logik, um Filter sowie der Indizierung von
Knotensammlung. Genutzt wird XQL hauptsächlich zur Selektion und Filterung von Elementen und
Text aus XML-Dokumenten. Es ist eine sehr einfache und kompakt gehaltene Sprache und kann so
als Teil einer URL eingesetzt werden.
Die Syntax
Die Syntax der Sprache soll hier nur vereinfacht in einer BNF-ähnlichen Notation dargestellt werden.
Dabei sind Terminale in Hochkommas eingeschlossen. Geschweifte Klammern bedeuten eine Liste
von 0 oder mehreren Elementen, getrennt durch Kommas. Eckige Klammern bedeuten das optionale
Auftreten, und Alternativen werden durch ein \j\ getrennt. Eine Abfrage besteht aus 3 Teilen:
• pattern-clause
Die Muster-Klausel überprüft Übereinstimmungen von verschachtelten Elementen und bindet
Variablen an Elemente.
• filter-clause
Die Filter-Klausel testet die gebundenen Variablen.
• constructor-clause Die Erbauer-Klausel spezifiziert das Ergebnis, als Terme von gebundenen
Variablen.
Lorel
’select’ {select_expr}
[’from’] {from_expr}]
[’where’ {where_expr}]
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
61
Lorel-Ausdrücke werden in SQL typischen Select-, From-, Where- (SFW) Blöcken geschrieben. Die
Sprache ist orthogonal, so kann jeder Block wieder eine Query enthalten.
XML-QL
Query:= ’where’ {Predicate}
’construct’ {’{’Query’}’}
Bei XML-QL wird das Resultat in der construct-Klausel spezifiziert. Mit Hilfe von tag-names und den
Inhalt der Anfrage, kann ein neues XML Dokument konstruiert werden, welches dann als Ergebnis
der Anfrage zurückgegeben wird.
XQL
Query::=[’./’|’/’|’//’|’.//’] Element [’[’Predicate ’]’][Path]
Path ::=[’/’|’//’] Element [’[’Predicate’]’][Path]
XQL unterstützt nur patterns und filter, keine constructors. Das ist, wie sich in den folgenden Beispielen noch zeigen wird, ein großer Nachteil von XQL, da viele Queries allein dadurch nicht ausdrückbar
sein werden. Wie an der Syntax schon zu sehen ist, wird mit XQL durch einen XML-Baum navigiert,
wobei Prädikate (filter) auf Elemente und Text entlang des Pfades angewandt werden. Das Resultat
einer XQL Anfrage ist wieder ein XML Dokument.
Lorel und XML-QL erweisen sich als die mächtigsten der 3 Sprachen. Ihre Ausdrucksmöglichkeiten könnte man mit hochentwickelten SQL Standards wie SQL92 vergleichen. Sie wurden unabhängig
voneinander entwickelt und weisen doch viele Gemeinsamkeiten auf. Das mag sicher daran liegen,
daß beide Sprachen aus der Datenbankgemeinschaft kommen und von vornherein versucht wurde,
ihnen Datenbankfähigkeiten zukommen zu lassen (datenbankorientiert). Deshalb besitzt die Syntax
der Sprachen auch die gleiche Struktur. Lorel ist die mächtigere der beiden Sprachen ist. XQL ist
dagegen doch stark in ihren Ausdrucksmöglichkeiten eingeschränkt. Der Grund hierfür liegt in den
Ursprüngen der Sprache. Mit XQL wollten die Entwickler eine Möglichkeit schaffen, Elemente aus
XML-Dokumenten zu selektieren und auch eine Volltextsuche auf sehr großen Dokumenten durchzuführen und das möglichst effektiv. Deshalb nennt man XQL auch eine dokumentorientierte Sprache.
Sie ist keine vollständige Anfragesprache, das soll sie auch nicht sein. Sie ist vielmehr der nützlichste
Teil einer Anfragesprache. Deshalb sollte XQL aber nicht unterbewertet werden, es gibt auch Anfragen, die mit XQL aber nicht mit Lorel und XML-QL ausgedrückt werden können. XQL ist eine
einfach zu erlernende, allgemein einsetzbare und sehr kompakte Sprache, dadurch könnte eine Query als Teil einer URL mit übergeben werden. Mittlerweile gibt es einige Erweiterungen, um XQL
ausdrucksstärker zu machen und die großen Defizite der Sprache zu beseitigen.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
62
5.2 User-defined types und objektrelationale Datenbanken
5.2.1 Objekt-Orientierung für Datenbanken
Obwohl wir die Entwicklungsmethodik nicht als voll ausgebaute objekt-orientierte Entwicklungsmethodik bezeichnen können - was auch z.Z. kaum eine Entwicklungsmethodik behaupten kann, weil die
dazu erforderliche Theorie zu einigen Problemen nicht im Entferntesten ausgearbeitet ist - , können
wir doch unsere Entwicklungsmethodik als ein Beispiel einer schrittweise aufgebauten und methodologisch ausgereiften Methodik auffassen. Dabei ist es gelungen, die Vorteile objekt-orientierter Entwicklung mit den Vorteilen klassischer struktur-orientierter Entwicklungsmethodik zu verknüpfen.
Vorteile objekt-orientierten Herangehens sind insbesondere die folgenden:
Schnellere Entwicklung
Wiederverwendung
Modulare Architektur
Beherrschung der Komplexität
Bessere Darstellung des Anwendungsgebietes
Client/Server-Anwendungen
Vollständige Dokumentation des Entwicklungsprozesses
Bibliotheken von Datenbankanwendungen.
Durch einen objekt-orientierten Entwurf soll auch eine Wiederverwendung der bereits erstellten
Entwürfe erleichtert werden. Diese Entwürfe werden in einer Bibliothek zusammengestellt. In einer
Bibliothek können analoge Lösungen ausgewählt und für die Anwendung aufbereitet werden. Damit
ergibt sich eine neuartige Entwurfsmethodik, die die Potenzen objekt-orientierter Entwicklung besser
aussschöpfen. Diese Entwurfsmethodik kann durch die folgenden Schritte gekennzeichnet werden:
1. Identifizierung der Kenntnisse über den Anwendungsbereich
2. Spezifikation der Kenntnisse als abstrakte Klassen oder Familien abstrakter Klassen im Rahmen
von Bereichsbibliotheken
3. Anforderungsanalyse der Aufgabenstellung, Identifikation abstrakter Konzepte, Reformulierung der Anforderungen auf der Grundlage des zweiten Schrittes und entsprechende Erweiterung
4. Problemzerlegung durch Verfeinerung der ersten drei Schritte
5. Spezifikation durch vollständige Erfassung der Datenstrukturen, der Funktionen and der Semantik, sowie deren Zusammenhänge auf Spezifikationsebene
6. Entwurf der Anwendung durch Verfeinerung der Spezifikation verbunden mit der Suche nach
Ähnlichkeiten, dem Auffinden mehrerer Abstraktionen zur Vereinheitlichung, Umstrukturierung unter Berücksichtigung des Inhaltes der Bereichsbibliothek und anderer Bibliotheken
7. Konstruktion von Implementierungskonzepten (von unten nach oben), Konstruktion von Teilklassen der abstrakten Klassen zur Repräsentation der Strukturen, Funktionen und der Semantik
unter Zuhilfenahme von Implementationskonzepten
8. Verifikation, Test, Dokumentation, Zuverlässigkeitsanalyse
Die Implementation besteht aus:
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
63
• einem Nutzerinterface mit einer Erklärungskomponente zur Unterstützung der Datenbankentwerfer,
• einer durch die Komponente Interpreter ausgeführten abstrakten OODB-Maschine,
• einer Übersetzer-Komponente, die vollständige Schemata in ausführbare Programme der abstrakten Maschine transformiert, und
• einer Entwurfsobjektbibliothek zur effizienten Abspeicherung, Suche und Analogieberechnung
in der Menge der abstrakten Entwurfsobjekte,
• einer Komponente zur Unterstützung des Nutzers während des Entwurfsprozesses mit einer
Komponente zur Verwaltung, Verfeinerung und der Integration der Nutzerentwürfe,
• einer Komponente zur effizienten Unterstützung des Auswahl- und Verfeinerungsprozesses mit
einem Lernprogramm, einer Strategiekomponente zum Tweaking und einer Wissensakquisitionskomponente, die auch zur Erweiterung der Objektbibliothek herangezogen wird und
• einem Programm Prüfer, das die Vollständigkeit eines Schemas überprüft.
Das Vorgehen berücksichtigt dabei die bereits vielfach gemachte Erfahrung, daß eine Vielzahl von
Projekten in spezifischen Anwendungsgebieten sich meist nur durch kleinere Details voneinander unterscheiden und zum anderen aber durch einen generischen, wiederverwendbaren Entwurf ein großer
Teil an Entwurfsaufwand vermieden werden kann. Das ist insbesondere dann der Fall, wenn auf anwendungsspezifisches Wissen zurc̈kgegriffen werden kann. Dieses Vorgehen entspricht dem intuitiven
Ansatz, den erfahrene Problemanalytiker verwenden. Sie schöpfen aus ihrem Erfahrungsschatz und
passen die konkrete Anwendung in ihre bisherigen Lösungen ein. Dadurch arbeiten sie wesentlich
effizienter als z.B. auch gut ausgebildete Neulinge.
Die Architektur eines diesen Zugang berücksichtigenden Systems ist in Abbildung 1 dargestellt.
Abstrakte Maschine
Nutzerinterface
Dokumentation
des
Entwurfes
Erklärungsunterstützung
Interpreter
6
?
Nutzerunterstützung
Prüfer
Verfeinerungskomponente
Objektbibliothek
Nutzerentwurfsverwaltung
Suche
-
Tweakingkomponente
Abspeicherung
Integrationskomponente
Wissensakquisitionskomponente
Analogieberechnung
Lernkomponente
Abbildung 1: Komponenten des Systems, das entwickelt werden sollte
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
64
Dieser Zugang basiert auf der Annahme, daß sich ein generischer, objektorientierter Entwurfsprozeß nicht mehr mit klassischen Herangehensweisen erreichen läßt. Objekte bzw. Klassen in einer
generischen Entwurfsbibliothek werden nach anderen Gesichtspunkten erstellt. Sie sind unter dem
Gesichtspunkt der Wiederverwendbarkeit und der Generizität entworfen und werden durch Verfeinerung an die Anwendung angepaßt. Dadurch wird nicht die Adequatheit des Entwurfes zum zentralen
Anwendungskriterium der Strategie, sondern die Wiederverwendbarkeit und Generizität.
Anwendungsabstraktion.
Wir beschäftigen uns nun mit dem objektorientierten Datenbankentwurf als zentraler Komponente bei der Entwicklung von Informationssystemen. Das zugrundegelegte Szenario beginnt mit einem
anfänglichen objektorientierten Schema, das in der Regel partiell ist, d.h. Typ- und Klassendefinitionen fehlen oder sind unvollständig. Sodann wird dieses Schema durch schrittweise Verfeinerung in
ein geschlossenes Datenbankschema überführt. Verfeinerungsschritte sind dabei die Instanziierung,
operationale Verfeinerung, Erweiterung, Spezialisierung und Abspaltung.
Instanziierung meint die nachträgliche Definition von Typen und Klassen, für die zunächst nur
ein Name festgelegt wurde. Erweiterung bezieht sich auf die Hinzunahme neuer Klassen bzw. neuer Methoden in einer Klasse. Operationale Verfeinerung ergänzt unvollständig definierte Methoden,
z.B. durch Aufrufe von Methoden auf anderen Klassen, und reduziert etwaigen Nichtdeterminismus.
Spezialisierung meint die Einführung von Subklassen und Abspaltung ersetzt eine Klasse durch mehrere, die über Referenzen miteinander verbunden sind. Dabei werden Methoden ebenfalls abgespalten
und durch Aufrufe ersetzt. Die formale Basis dieses Vorgehens bildet ein mathematisch fundiertes
objektorientiertes Datenmodell mit einem abstrakten Objektbegriff, der im Gegensatz zu vielen bestehenden Ansätzen ein Objekt nicht an eine einzige festgelegte Struktur koppelt. Es kann außerdem
gezeigt werden, daß alle beschriebenen Verfeinerungsschritte tatsächlich der formalen Definition von
struktureller bzw. operationaler Verfeinerung genügen.
5.2.2 Typensysteme
Wir verwenden hier ein objektorientiertes Datenbankmodell (OODM), das im Gegensatz zu den in
der Literatur üblichen Modellen über eine wohlfundierte theoretische Basis verfügt. In aller Kürze
läßt sich das Modell wie folgt definieren:
Typdefinitionen im objektorientierten Datenmodell: Typen dienen der Gruppierung von Werten, sind
also zunächst Mengen vonWerten. Das OODM unterscheidet grundsätzlich zwischen Basistypen und konstruierten Typen. Basistypen sind BOOL, N AT , IN T ,F LOAT , ST RIN G, ID
und ⊥, wobei ID einen Typ abstrakter Objektidentifikatoren und ⊥ den trivialen Typ mit genau einem Wert bezeichnet. Konstruierte Typen werden durch (geschachteltes) Anwenden der
folgenden Typkonstruktoren gebildet:
( a1 : T1 , . . ., an : Tn )
Der Typ wird aus n Typen T1 , . . . , Tn zusammengesetzt (RECORD).
Die Feldnamenai dienen der Selektion der einzelnen Komponenten
und können weggelassen werden, sofern hierdurch keine Mißverständnisse auftreten.
“a1 ” + . . . + “an ”
Der Typ legt die zulässigen Werte auf “a1 ” oder ... oder “an ” fest
(Aufzählungstyp).
(a1 : T1 ) ∪ . . . ∪ (an : Tn ) Der Typ enthält alle Werte der Typen T1 . . . Tn (Vereinigungstyp).
Die Selektoren ai dienen dazu, mehrfaches Auftreten des gleichen
Typs zuzulassen. Wie im ersten Fall können sie aber weggelassen
werden, solange keine Mißverständnisse hieraus resultieren.
[T ]
Werte dieses Typs sind endliche Listen mit Elementen vom Typ T .
{T }
Werte dieses Typs sind endliche Mengen mit Elementen vom Typ
T.
CAU Kiel, IfI, ISE
T Where P
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
65
Werte dieses Typs sind Werte des Typs T , die die Formel P erfüllen.
Dabei enthält diese Formel genau eine freie Variable self, die
sich auf eben diesen Wert bezieht.
Wir können diesen Typen noch allgemeine Operationen wie z.B. +, ∗ aufNAT, INT, ∧, ∨ auf
BOOL, concat auf STRING sowie map, filter, pump auf Mengen- und Listentypen zuordnen,
mit denen Terme auf dieübliche Art und Weise gebildet werden können. Operationen auf Typen
dienen nur diesem Zweck und sind nicht mit den zustandsverändernden Methoden auf Klassen
zu verwechseln.
Klassendefinitionen im objektorientierten Datenmodell: Im OODM wird zwischen Werten und Objekten unterschieden. Ein Objekt besteht aus
• einem (abstrakten) Identifikator id,
• einer Menge von Werten vi von möglicherweise verschiedenen Typen T1 , . . . , Tn ,
• einerMenge von Referenzen refj (j = 1, . . . , m) zu Objekten o1 , . . . , om und
• einer Menge von Methoden (= Operationen) auf dem Objekt.
Im OODM sind Identifikatoren Werte vom Typ ID. Identifikatoren verschiedener Objekte
sind verschieden. Im Gegensatz zu Werten anderer Typen werden Identifikatoren jedoch ausschließlich durch das DBMS vergeben und bleiben für den Benutzer stets unsichtbar. In einigen
anderen OODB-Systemen dagegen sind Identifikatoren sichtbar, was äquivalent zur Vergabe
eines einheitlichen künstlichen Schlüssels und damit konzetionell inakzeptabel wäre. Ferner
bleibt der Identifikator eines Objektes über die gesamte Lebensdauer des Objekts unverändert,
während sich Werte, Referenzen und Methoden verändern können. Insbesondere ist die obige Menge {T1 , . . . , Tn } von Typen nicht a priori festgelegt, sondern Objekte können Typen
hinzubekommen oder verlieren.
Klassen dienen nur der Gruppierung von Objekten, sind also, wenn man sich auf die Identifikatoren als Stellvertreter zurückzieht, Mengen von Objekten. Die Klassendefinition im OODM
umfaßt nun strukturelle Aspekte von Objekten, d.h. zugeordnete Typen und Referenzen zu Objekten in anderen Klassen, sowie Methoden, die auf alle Objekte in der Klasse Anwendung
finden können. Typen und Referenzen lassen sich wiederum zu sog. Strukturausdrücken zusammenfassen.
Eine Klasse besteht aus einem Klassennamen C, einer Menge {C1 , . . . , Cn } von Klassennamen, den sog. Superklassen, einem Strukturausdruck S und einer Menge {f1 , . . . , fm } von
Methoden. Dabei entsteht ein Strukturausdruck aus einem parametrisierten Typ ohne Vorkommen von ID (einem sog. Wertetyp), in dem Parameter αi durch Paare ri : Ci mit einem Referenznamen ri und einem Klassennamen Ci ersetzt wurden. Ersetzen wir hier in wiederum
alle Referenzen ri : Ci durch den Typ ID, so heißt der entstehende parametrisierte Typ der
Repräsentationstyp der Klasse C und wird mit TC bezeichnet.
In dieser Definition wird nicht verlangt, daß alle Parameter ersetzt werden; es kann sogar vorkommen, daß überhaupt kein Parameter durch eine Referenz ersetzt wird.
Ein Schema im OODM ist eine Menge von Typ- und Klassendefinitionen. Wir nennen ein Schema genau dann geschlossen, wenn keine Parameter mehr vorkommen und alle Methoden deterministisch sind. Eine Instanz D eines geschlossenen Schemas S ordnet jeder Klasse C einen
Wert D(C) vom Typ { ( ident : ID , value : TC ) } zu, so daß
• Identifikatoren in D(C) eindeutig sind, d.h.
(i, v1 ) ∈ D(C) ∧ (i, v2 ) ∈ D(C) ⇒ v1 = v2 gilt ,
• die referentielle Integrität bezüglich aller Referenzen r : C ′ erfüllt ist, d.h.
(i, v) ∈ D(C) ∧ or (v, j) ⇒ ∃v ′ :: TC ′ .(j, v ′ ) ∈ D(C ′ ) gilt ,
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
66
wobei das Prädikat or (v, j) genau dann erfüllt ist, wenn der Identifikator j im Wert v an
der Stelle vorkommt, die durch die Referenz r markiert wird,und
• die Inklusionsintegrität bezüglich aller Superklassen Ci von C erfüllt ist, d.h. es muß
gelten
(i, v) ∈ D(C) ⇒ ∃v ′ :: TCi .(i, v ′ ) ∈ D(Ci ) .
Die in der Instanzendefinition enthaltenen Integritätsbedingungen müssen in Transaktionen
selbstverständlich berücksichtigt werden (Konsistenzforderung). Ist nun ein beliebiges Schema S gegeben und ist inst eine Abbildung, die jedem Parameter P in S einen Typ zuordnet, so
bezeichnen wir eine Instanz des geschlossenen Schemas S ′ , das durch Ersetzung von P durch
inst(P ) entsteht, als eine Instanz von S unter der Instanziierunginst. Anfängliche Schemata
sind in der Regel offen. Semantisch steht ein solches Schema für die Menge aller möglichen
Instanziierungen. Dies realisiert das Prinzip der Klassenabstraktion.
Graphische Schemadarstellung: Zusätzlich zu der textuellen Repräsentation sehen wir eine mehrschichtige graphische Repräsentation vor. Gerade die einfache graphische Unterstützung für
den Datenbankentwurf mit dem Entity-Relationship-Modell hat zu dessen Erfolg beigetragen.
Das Problem bei der graphischen Repräsentation objektorientierter Schemata liegt nicht darin,
einem Schema eine Graphik zuzuordnen, die die (statische) Schemainformation widerspiegelt.
Unter Verwendung verschiedener graphischer Symbole für Typen, Typkonstruktoren und Klassen lassen sich solche Graphiken einfach finden. Das Problem ist vielmehr, auch solche Graphiken zuzulassen, die nur eine vergröberte Darstellung der Schemainformation enthalten, in
dem einzelne Komponenten des Strukturausdrucks einer Klasse, der gesamte Strukturausdruck
oder ganze Klassen weggelassen werden. Zusätzlich muß es möglich sein, derartige Graphiken
aufeinanderabzubilden.
Subklassen und Subtypen: Die Klassendefinition beinhaltet die Angabe von Superklassen. Sind diese bereits definiert, so besagt die Forderung der Inklusionsintegrität, daß in jeder Instanz die
Mengen der Objektidentifikatoren der beiden Klassen in einer Teilmengenbeziehung zueinander stehen müssen. Eine Forderung an die Werte der zugehörigen Repräsentationstypen beinhaltet die bisherige Definition allerdings noch nicht. Zur Verschärfung der Instanzdefinition führen
wir zunächst eine Subtypbeziehung ein, die wir mit ≼ bezeichnen und die folgendermaßen definiert ist.
1. Jeder Typ ist Subtyp von sich selbst und von ⊥.
2. N AT ≼ IN T ≼ F LOAT .
3. (a1 : T1 , . . . , am : Tm ) ≼ (b1 : T1′ , . . . , bn : Tn′ ) gilt genau dann, wenn n ≤ m, aσ(j) =
bj und Tσ(j) ≼ Tj′ für ein injektives σ : {1, . . . , n} → {1, . . . , m} gelten.
4. (a1 : T1 ) ∪ . . . ∪ (am : Tm ) ≼ (b1 : T1′ ) ∪ . . . ∪ (bn : Tn′ ) gilt genau dann, wenn m ≤ n,
′
aj = bσ(j) und Tj ≼ Tσ(j)
für ein injektives σ : {1, . . . , m} → {1, . . . , n} gelten.
5. “a1 ” + . . . + “an ” ≼ “b1 ” + . . . + “bm ”gilt genau dann, wenn {a1 , . . . , an } ⊆ {b1 , . . . , bm }
gilt.
6. {T } ≼ {T ′ } gilt genau dann, wenn T ≼ T ′ gilt. Analog gilt [T ] ≼ [T ′ ] genau dann, wenn
T ≼ T ′ gilt. Ferner ist T Where P ≼ T .
In allen obigen Fällen definiert eine Subtypbeziehung T ≼ T ′ eine eindeutige Abbildung
T → T ′ für die zugrundeliegenden Mengen von Werten. Wir bezeichnen diese Abbildung
als Subtypfunktion.
Im OODM wird nicht gefordert, daß die Subklassenbeziehung (IsA) mit einer Subtypbeziehung
für die Repräsentationstypen einhergeht. Stattdessen müssen nur in dem Fall, daß der Repräsentationstyp der Subklasse C von C ′ tatsächlich ein Subtyp ist, die zugehörigen Werte mittels der
Subtypfunktion f aufeinander abbildbar sein, d.h. es muß
(i, v) ∈ D(C) ⇒ (i, f (v)) ∈ D(C ′ )
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
67
für alle Instanzen D gelten. Dies verschärft die bisherige Definition der Inklusionsintegrität.
Objektidentität als zentrale Forderung an objektorientierte Datenbanken wird durch Identifikatoren (Werte vom Typ ID) modelliert. Da diese abstrakt und nicht sichtbar sind, stellt sich
die Frage, ob Objekte in der Datenbank immer eindeutig identifiziert werden können, ohne die
hierfür nicht brauchbaren Objektidentifikatoren zu verwenden, d.h. zu jedem Objekt in der Datenbank muß eine Anfrage existieren, die genau dieses Objekt als Antwort liefert. Dafür wurde
der Begriff der schwachen Werteidentifizierbarkeit eingeführt und theoretisch untersucht.
Methoden im objektorientierten Datenmodell: Bisher haben wir nur statische Aspekte beschrieben.
Dynamik wird durch die den Klassen zugeordneten Methoden ausgedrückt. Wir unterscheiden zwischen verborgenen Methoden, gekennzeichnet durch das Schlüsselwort hidden, und
Methoden, die vom Benutzer der Datenbank aufgerufen werden können. Letztere sollen als
Transaktionen fungieren. Wir wollen damit unterstreichen, daß diese der Transaktionssemantik
in Datenbanken (ACID-Prinzip) genügen, insbesondere müssen nur diese die Konsistenzforderung erfüllen. Die Transaktionsverarbeitung ist dann Aufgabe des für die Realisierung verwendeten Datenbanksystems. Diese Unterscheidung verbietet nicht den Aufruf einer verborgenen
Methode durch andere Methoden.
Methoden bestehen aus einem Kopf, in dem die Ein- und Ausgabeparameter mit ihren Typen genannt werden, und einem Rumpf. Im OODM werden Methodenrümpfe durch typisierte
guarded commands beschrieben, deren Semantik axiomatisch durch das Dijkstra’sche Prädikattransformerkalkül definiert werden kann. Hier verwenden wir eine etwas eingänglichere Form
zur Methodenbeschreibung. Ein Methodenrumpf wird hierbei aus den folgenden Konstrukten
gebildet.
1) Variablendeklarationen: Let ⟨Var⟩ ::⟨Typname⟩ ,
2) Wertzuweisungen: ⟨Var⟩ := ⟨Term⟩ , wobei die Variable und der Term vom gleichen Typ
sein müssen,
3) Fallunterscheidungen: IF ⟨Bedingung⟩ THEN. . . ELSE . . . ENDIF ,
4) Schleifen: WHILE ⟨ Bedingung ⟩ DO. . . ENDDO oder
FOR ⟨Var⟩ WITH ⟨Bedingung⟩ DO. . . ENDFOR ,
5) skip ohne Effekt, fail, das backtracking erzwingt und damit partiell undefinierte Methodenrümpfe erlaubt,
6) Aufrufe: ⟨Klassenname⟩ :-⟨Methodenname⟩ (⟨aktuelleParameter⟩), wobei der Klassenname weggelassen werden kann, wenn die aufgerufene Methode auf der gleichen Klasse
definiert ist,
7) nichtdeterministische Wertselektionen: New.⟨Selektor⟩(⟨Var⟩) und New Id (out :⟨Var⟩).
Die verschiedenen nicht-deterministischen Wertselektionen bedürfen noch einer kurzen Erläuterung. Im ersten Fall wird ein Selektor aufdem Repräsentationstyp verwendet. Dies ist eine
nicht-deterministische Typoperation, die einem Wert eines konstruierten Typs eine bestimmte
Komponente zuordnet. Der Typ dieses selektierten Werts ist ableitbar. Die Selektion ist lokal
auf die jeweilige Klasse bezogen. New Id dagegen selektiert einen Identifikator (vom Typ ID),
der global in der Instanz nicht vorkommt. Wir können dies auch als eine Methode auf einer
Klasse O BJ auffassen, die Superklasse von allen Klassen ist. Der Strukturausdruck von O BJ
wäre dann ⊥.
Die Erarbeitung der Methoden kann bereits Teil der Verfeinerung sein. Fügen wir wie in diesem Fall zu einer gegebenen Klasse einfach Methoden hinzu, so bezeichnen wir diesen Verfeinerungsschritt als operationale Erweiterung. Sie gibt im Entwurfsprozeß häufig Hinweise auf
Vervollständigungen des Strukturausdrucks der Klasse.
Umgekehrt ist klar, daß Methoden ohne zugehörige Klasse nicht existieren. Objektorientierung beseitigt also nicht etwa den Unterschied zwischen Funktions- und Datenentwurf, sondern
ermöglicht deren Integration mit einem eindeutigen Primat des Datenentwurfs.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
68
Ein besonderes Augenmerk bei Datenbanken gilt generischen Veränderungsmethoden zum Einfügen,
Ändern und Löschen von Objekten in einer Klasse. Diese können dann und nur dann existieren,
wenn die Klasse werterepräsentierbar ist. Dies ist wiederum äquivalent dazu, daß Werte des
Repräsentationstyps einer Klasse in jeder Instanz eindeutig sind, d.h.es muß
(i1 , v) ∈ D(C) ∧ (i2 , v) ∈ D(C) ⇒ i1 = i2
in jeder Instanz D gelten. Wir bemerken noch, daß Werterepräsentierbarkeit die schwache Werteidentifizierbarkeit einschließt. Werterepräsentierbarkeit beseitigt allerdings nicht den Unterschied zwischen Werten und Objekten, da Objekte nach wie vor nicht an einen einzigen Typ
gekoppelt werden können.
Operationale Spezialisierung: Der Begriff der Inklusionsintegrität berücksichtigt keine Methoden.
Zur Ausdehnung auf Methoden wird häufig der Vererbungsbegriff aus der objektorientierten
Programmierung herangezogen. Für objektorientierte Datenbanken ist der Vererbungsbegriff
allerdings überladen, so daß das OODM auf die Verwendung dieses Begriffs verzichtet.
Der programmiersprachliche Vererbungsbegriff dient dazu, Methoden eines Objekts auf Superklassen zugänglich zu machen. Eine einfache Übertragung auf Datenbanken verbietet sich, da
Werte eines Objekts in verschiedenen Klassen und weitgehend unabhängig voneinander gehalten werden. Alle Methoden eines Objekts sind sofort zugänglich, wenn das Objekt identifiziert
ist. Ferner erzwingen die impliziten Integritätsbedingungen in der Instanzendefinition die Propagierung von Veränderungen entlang der Referenzen und der Subklassenbeziehungen.
Im OODM wird daher lediglich gefordert, daß Methoden auf Subklassen, die Methoden auf
einer Superklasse überschreiben sollen, operationale Spezialisierungen sein müssen.
5.2.3
Anpassungs- und Verfeinerungsmechanismen
Der Verfeinerungsbegriff verwendet Historien, das sind Folgen D0 , D1 , . . . von Instanzen, wobei
D0 (C) für alle Klassen C leer sei und der Übergang von Di−1 zu Di durch eine Transaktion auf
einer Klasse C ∈ Serfolgt. Für Schemata S und T betrachten wir nun
• eine Abbildung finst von den Instanzen des Schemas T zu denen von S,
• eine partielle Abbildung fclass von den Klassen in T zu denen in S und
• eine Abbildung fmeth von Methoden in T zu einer(möglicherweise leeren) Menge von Methoden in S,
wobei für jede Methode M auf einer Klasse C in T die Methoden M ′ ∈ fmeth (M ) zur Klasse
fclass (C) in S gehören. T ist genau dann eine Verfeinerung von S, wenn für jedesPaar (Di−1 , Di )
in einer Folge von Instanzen des SchemasT mit zugehöriger Transaktion M und jeder Methode
M ′ inf meth (M ), die auf die Instanz finst (Di−1 ) angewendet werden kann, in einer neuen Instanz
finst (Di )) resultiert. Eine Formalisierung des Verfeinerungsbegriffs mittels des Dijkstra’schen Prädikattransformerkalküls findet sich in der Literatur zur Theorie der Programmiersprachen. Im folgenden werden einige grundlegende Standardverfeinerungsschritte vorgestellt, die sich an strukturellen
Aspekten von Klassen orientieren. Es wird diskutiert, wann diese Verfeinerungen verwendet werden
können, wann ihre Verwendung sinnvoll ist und welche Auswirkungen dies auf die Methoden hat.
Wir unterscheiden dabei die folgenden Verfeinerungstechniken:
Verfeinerung durch Instantiierung: Ziel des Verfeinerungsprozesses ist es, ein geschlossenes OODMSchema zu erhalten. Da Schemata vor allem in frühen Stadien undefinierte Typen, Klassen und
Methoden enthalten, ist die Instanziierung ein erster wichtiger Verfeinerungsschritt. Wir verstehen darunter die Definition von Typen und Klassen, die im anfänglichen Schema bzw. nach
den bisher erfolgten Verfeinerungsschritten nur benannt, aber nicht festgelegt waren. Instanziierungen können jederzeit erfolgen. Sie sind unabhängig von der Reihenfolge und sie sind unvermeidbar. Allerdings ist nicht ausgeschlossen, daß durch die Instanziierung neue Parameter
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
69
eingeführt werden. Es ist Aufgabe des Entwufs sicherzustellen, daß die Einführung neuer Parameter nicht ins Unendliche fortgeführt wird, während eine formale Geschlossenheitsprüfung —
abgesehen von der Überprüfung der Methoden auf deterministisches Verhalten — automatisch
erfolgen kann.
Methoden auf parametrisierten Klassen sind einfach parametrisch polymorph. Insbesondere
entsteht kein Fehler, wenn sie bei Instanziierungsverfeinerungen nicht verändert werden. Andererseits ermöglicht die Instanziierung, die Methoden zu überprüfen und gegebenenfalls zu
verändern. So können in der Methode ermittle Restfond für Kostenstelle die Verarbeitungen
für die Speicherung des Institut und des Lehrstuhls ergänzt und konkretisiert werden.
Auf weitere Details dieser operationalen Verfeinerungen gehen wir hier nicht ein.
Ob zunächst nur strukturelle Instanziierungen vorgenommen werden, ohne die Methoden zu
verändern, oder alle Auswirkungen auf Methoden sofort umgesetzt werden ist eine freie Entwurfsentscheidung. Als grobes Kriterium kann die Stabilität des bisherigen Entwurfs herangezogen werden. Wenn zu erwarten ist, daß etliche weitere Strukturänderungen (durch Verfeinerungen) erfolgen, so sollten die Methodenverfeinerungen vorläufig zurückgestellt werden. Die
Verfeinerungsstrategie läßt derartige verschiedene Entwurfsstrategien bewußt zu. Primäres Ziel
ist es, die Korrektheit der Entwürfe sicherzustellen.
Verfeinerung durch Abspaltung: Bei der Verfeinerung durch Abspaltung wird ein zusammengesetzter Typ im Strukturausdruck einer Klasse zum Strukturausdruck einer neuen eigenständigen
Klasse gemacht. Sein Vorkommen im “alten” Strukturausdruck wird dabei zu einer Referenz auf
die neue Klasse. Ob ein Schema durch Abspaltung zu verfeinern ist hängt davon ab, ob die zugrundeliegenden Informationen als Objekte oder als Werte modelliert werden sollen. Im ersten
Fall gibt es Objekte der realen Welt, die (teilweise) durch Objekte in der neuen Klasse beschrieben werden können und dementsprechend redundanzfrei in der Datenbank gespeichert werden
sollen.
Eine Verfeinerung durch Abspaltung führt außer zu Methoden auf der neuen Klasse (Verfeinerung durch operationale Erweiterung) zu Veränderungen in bereits vorhandenen Methoden.
Auf diese Weise wird die in der Instanzendefinition geforderte referentielle Integrität sichergestellt
Verfeinerung durch Spezialisierung: Bei der Verfeinerung durch Spezialisierung werden entweder Subklassen von vorhandenen Klassen gebildet oder es werden Klassen gebildet, deren Repräsentationstyp ein Subtyp des Repräsentationstyps einer vorhandenen Klasse ist. Im letzteren
Fall ist es eine freie Entwurfsentscheidung, ob die neue Klasse als zusätzliche Subklasse eingeführt wird oder ob sie die alte Klasse ersetzt. Ob eine Spezialisierung sinnvoll ist, kann nur
aus dem Anwendungszusammenhang beantwortet werden:
• Gibt es “optionale Werte”, d.h. Werte, die bei einer Teilmenge von Objekten der Klasse
fehlen?
• Gibt es Referenzen, die nur auf einer Teilmenge einer Klasse vorhanden sind?
• Gibt es Methoden, die sich auf einer Teilmenge einer Klasse spezifisch verhalten?
In einer IsA-Beziehung kann ein Objekt der Superklasse auch in mehreren Subklassen (oder in
keiner) enthalten sein. Außerdem muß die IsA-Beziehung nicht, mit einer Subtypbeziehung
der Repräsentationstypen der Klassen einhergehen. Zusammen mit obigen Aussagen ergibt
sich,daß Objekte nicht an Typen gekoppelt sind, sondern mehrere Typen (und damit mehrere
Werte) gleichzeitig haben können. Dies erlaubt es, im OODM auf die Behandlung künstlicher
Probleme wie dem der “Objektmigration” zu verzichten, da diese durch ableitbare generische
Veränderungsoperationen bereits mit erfaßt werden.
Als nächster Schritt wären die bereits vorhandenen Methoden zu überprüfen.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
70
Mit einer Spezialisierung der Struktur geht eine Spezialisierung der Methoden einher. Denkbar
(wenn auch hier nicht fachlich sinnvoll) ist natürlich auch ein Spezialisieren der Methode, d.h.
zum Beispiel ein Formulieren zusätzlicher Prüfungen auf derSubklasse.
Verfeinerung durch strukturelle Erweiterung: Außer zu neuen Werten können fachlich neue Erkenntnisse natürlich auch direkt zu neuen Klassen führen. Ein Kriterium zur Einführung neuer
Klassen ist z.B. eine Unterbrechung in der Sachbearbeitung, die sich in den Methoden widerspiegelt. Derartige Erweiterungsverfeinerungen sind genau so wie Instanziierungen jederzeit
möglich.
Andere Modelle verwenden einen weitaus weniger abstrakten Objektbegriff, bei denen ein Objekt nur einer Klasse angehören kann oder mehreren Klassen, die paarweise in IsA-Beziehungen
zueinander stehen. Dies schränkt von vornherein die Möglichkeiten der konzeptionellen Modellierung ein und verursacht zusätzliche Probleme, z.B. das der “Objektmigration”, die mit
unserem Ansatz vermieden werden. Sinn des objektorientierten Zugangs ist es aber gerade, die
vom relationalen Datenmodell her bekannten Probleme, die durch eine rein wertebasierte Modellierung entstehen, zu lösen. Diese Verfeinerung durch Vervollständigung wirkt sich nicht auf
die bisher definierten Klassen aus, wohl aber können Verfeinerungen von Methoden auf diesen
jetzt vollzogen werden. Dies erfolgt durch Aufruf der entsprechenden Methode. Das bis jetzt
entwickelte Schema ist damit noch keineswegs abgeschlossen. Weitere fachliche Erkenntnisse
oder Neubewertungen bereits modellierter Tatsachen führen zur wiederholten Anwendung der
genannten Verfeinerungsschritte.
5.2.4
Fallen und Mißverständnisse
Die hier vorgestellte Modellierungmethodik ist objekt-orientiert. Es erscheint insbesondere für die
Modellierung ein objekt-orientierter Zugang viele Probleme zu lösen. Jedoch sollte man nicht glauben, daß mit einem objekt-orientierten Zugang auch alle klassischen Probleme gelöst seien, und vor
allem nicht glauben, daß die Objekt-Orientierung das eigene Denken und Analysieren ersetzen kann.
Mit dem objekt-orientierten Paradigma ist eine sehr mächtige Herangehensweise entwickelt worden.
Aber nicht mehr.
Basiskonzepte, die konsistent zu verwenden, sind die folgenden:
Objekte wie bereits erläutert;
Messages zwischen den Objekten (Retrieval, Aktionen, Update, Veränderung von Beziehungen);
Abstraktion von Eigenschaften, Strukturen, Methoden etc.;
Verkapselung mit einem Interface;
Instantiierung wie bereits erläutert;
Vererbung im Rahmen struktureller Vererbungshierarchien wie der Spezialisierungshierarchie und
der Generalisierungshierarchie;
Spezialisierung, Generalisierung Spezialisierung durch Hinzufügen, Überschreiben, Blockieren,
...;
Polymorphismus auf Typenniveau, auf Implementationsniveau, über Protokolle;
Typenkontrolle und Bindung für Methoden mit verschiedenen Implementationsstrategien;
Komposition, Aggregation von Typen und Klassen;
Teile-Ganze-Beziehungen und deren Einbeziehung bei der Bildung von Containern und entspr.
Beziehungen.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
71
Dabei existieren eine ganze Reihe von Mißverständnissen, Fallen und konzeptionell falschen Vorstellungen, die man bei der Entwicklung berücksichtigen sollte. Insbesondere sind die folgenden 82
“pitfalls” zu nennen. Diese Liste ist weder vollständig noch demotivierend. Im Gegenteil, jeder, der
Fehler - auch solche dieser Liste - vermeiden kann, sollte diese Fehler auch bewußt vermeiden. Dadurch wird die Anwendungsentwicklung eher mit hoher Qualität geführt werden können.
Konzeptionelle Mißverständnisse sind meist Mißverständnisse, die durch ein Unverständnis oder
einen - evt. auch intuitiven - Mißbrauch der Konzepte entstehen. Man sollte die Form nicht mit
Konzepten verwechseln. Objekt-Orientierung umfaßt auch Klassen und Objekte, aber nur als
jeweils ein Konzept unter vielen. Weiterhin sollten die Implikationen einer objekt-orientierten
Entwicklung verstanden werden. Durch eine objekt-orientierte Methodik wird ein anderer Stil
gepflegt als bisher. Außerdem bedingt eine objekt-orientierte Methodik nicht, daß alle klassischen, wohlerprobten Methoden über Bord geworfen werden müssen. Oft wird aufgrund der
höheren Produktivität ein objekt-orientierter Zugang gewählt, was zu entsprechenden Enttäuschungen führt. Alles hat seinen Preis.
Objekt-Orientierung aus falschen Gründen. Es gibt eine Vielzahl von Gründen, warum objektorientierte Entwicklung auch sinnvoll erscheinen kann: Jemand hat etwas darüber gehört.
Man scheint ohne Testen auszukommen. Man scheint schneller voranzukommen. Bisherige Entwicklungsprobleme gibt es nicht mehr. Graphische Benutzerschnittstellen sind
besser. Man möchte Systeme einfach verbinden können.
Richtiger ist den Zugang aufgrund seiner Konzepte und der damit verbundenen Qualität
zu wählen.
Objekt-Orientierung hat keinen Preis. Mit Objekt-Orientierung scheint ein ‘plug-and-play’Zugang in greifbare Nähe gerückt zu sein. Man scheint schnell und einfach jeden Entwickler auch für eine objekt-orientierte Entwicklung heranziehen zu können.
Im Gegenteil, zur Objekt-Orientierung gehört auch eine entsprechende Ausbildung. Diese
benötigt Zeit und erfordert einen Reifungsprozeß. Man benötigt auch die richtigen Werkzeuge und auch eine solide Theorie im Hintergrund.
Objekte sollen alle Probleme lösen. Der Modellierungsprozeß ist ein umfangreicher Prozeß, der viele Entwicklungsstadien erfordert und sehr komplex ist. Man entwirft nicht nur,
sondern muß auch eine Reihe von Problemen im Rahmen der gegebenen Grenzen lösen.
Einige dieser Probleme lassen sich einfacher lösen, einige werden auch schwieriger.
Objekt-Orientierung ist ausgereift. Obwohl über Objekt-Orientierung für Informationssysteme seit über einem Jahrzehnt gesprochen wird, ist diese Entwicklungsmethodik immer
noch nicht ausgereift. Weder die Anwendungsgebiete sind klar eingegrenzt, noch eine
Vielzahl von Experten ausgebildet, die auch eine längere Erfahrung einbringen können,
noch ist die Problemlösung deterministisch, noch ist die ‘menschliche’ Komponente der
Modellierung verstanden, noch ist die entsprechende Theorie entwickelt.
Deshalb ist Objekt-Orientierung über die guten Seiten entsprechend zu benutzen, ohne die
Nachteile außer Acht zu lassen.
Verwechseln von Schlagworten mit Konzepten. Schlagworte wie Polymorphismus, Wiederverwendung, Identität, dynamisches Binden, sind meist schnell auswendig zu lernen.
Die Inhalte sind dagegen schon aufgrund nicht ausreichender theoretischer Durchdringung
weniger schnell zu lernen und adäquat anzuwenden.
Man kann dagegen durch eine entsprechende Ausbildung und durch das Erfassen von
Erfahrungen, die Experten machen mußten, auch das Verständnis verbessern.
Verwechseln von Werkzeugen mit Prinzipien. Oft meint man allein durch die Benutzung
objekt-orientierter Werkzeuge auch objekt-orientiert zu sein.
Erfahrung und Ausbildung bleiben aus diesem Grund nach wie vor erstrangig.
Verwechseln von Darstellung mit Methodik. Produkte geben oft an, objekt-orientierte Herangehensweisen zu unterstützen, weil die eine oder andere Funktionalität wie Fenster, Ta-
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
72
sten, graphische Repräsentation, Ereignisse, Wiederverwendung, Verteilung, Nachrichten
die Objekt-Orientierung unterstützen.
Man muß dagegen die verschiedenen Konzepte der Objekt-Orientierung im Zusammenhang und im Zusammenspiel beherrschen.
Verwechseln von Training mit Fähigkeiten. Das Besuchen eines oder mehrerer Kurse kann
zur Entwicklung vom Verständnis beitragen. Fähigkeiten entwickeln sich dagegen erst
beim Gebrauch und durch Erfahrung.
S. Covey (Seven Habits of Highly Effective People): Gesetz der Schnitter (Man kann auch nicht
Getreide über Nacht säen und am nächsten Morgen ernten.).
Fähigkeiten kommen mit der Zeit und mit entsprechender Anstrengung. Deshalb kann
man nicht, objekt-orientierte Entwicklungsmethodiken übernacht einsetzen.
Verwechseln von Prototypen mit ausgereiften Produkten. Man kann durch die größere Entwicklungsgeschwindigkeit verführt, die insbesondere mit dem Prototyping verbunden ist,
das Endprodukt aus den Augen verlieren. Produkte, die mit dem Prototyping entstehen
sollen die Machbarkeit aufzeigen und sind deshalb nur die Vorstufe zum erfolgreichen
Endprodukt.
Machbarkeitsstudien sind deshalb weniger für eine Präsentation von Ergebnissen geeignet.
Strategische Mißverständnisse sind oft durch die Zusammenarbeit mit einer Leitung entstanden,
die den vielen Versprechungen von (unseriösen) Anbietern aufsitzt. Deshalb ist auch das Management von den Potenzen und den Problem einer objekt-orientierten Entwicklung zu unterrichten.
Leitung nicht vollständig informiert über Konzepte. Da sich eine Leitung mit einer Vielzahl von Problemen auseinandersetzen muß, ist oft nicht die Gründlichkeit beim Verständnis der Konzepte vorhanden, so daß damit die Urteilsfähigkeit insbesondere über die Potenzen und Schwierigkeiten eingeschränkt ist.
Damit ist auch die Leitung mit den wichtigsten Problemen objekt-orientierter Entwicklung
zu konfrontieren.
Unterschätzung der Trägheit. Jede neue Technologie benötigt auch ein umfassendes Verständnis ihrer Grundkonzepte. Oft entscheidet aber darüber auch die Arbeitsumgebung oder die
Gewohnheiten.
Erfolgserlebnisse sind dagegen ein guter Antrieb, um sich entsprechende Konzepte schnell
zu eigen zu machen.
Überschätzung der Technologie. Man erwartet vom neuen Herangehen oft zu viel und ist
dann ebenso tief enttäuscht. Gerade die Proponenten objekt-orientierter Datenbanken wird
oft zuviel versprochen.
Deshalb ist eine gewisse Skepzis angebracht.
Religiöse Propaganda. Die Vorteile objekt-orientierter Entwicklung wie z.B. Wiederverwendung kommen erst bei entsprechender erfahrener Benutzung zum Tragen. Dagegen wird
oft versprochen, die Produktivität vom ersten Tag an zu heben. Analog geht es mit anderen
enthusiastischen oder fanatischen Versprechen.
Eine Technologie ist stets nur so nützlich wie sie ihr Anwender macht.
Nichtberücksichtigung der Architektur. Eine Anwendung ist oft durch eine größere Anzahl
von verschiedenartigen Anwendungsfällen charakterisiert, so daß eine Grobarchitektur
auch sinnvoll erscheint. Damit wird auch eine Modularisierung erleichtert.
Einem Entwickler ist deshalb oft auch die Rolle des Chefarchitekten mit allen Konsequenzen zuzuweisen.
Abhängigmachen von eigenen Versionen. Nach Vervollständigung eines Entwurfes wird
oft auch eine Reihe von Entwurfsfehlern sichtbar, die man glaubt im Schellverfahren überwinden zu können. Damit wird auch die Modellierung selten besser. Hinzu kommt oft
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
73
auch die Forderung nach einer schnellen Erweiterung um zusätzliche Typen oder zusätzliche Funktionalität. Oft ist dazu auch die Leitung am schnellen Vertrieb der erweiterten
Version interessiert.
Versionen erfordern eine sehr gute Dokumentation der Entwurfsentscheidungen und der
Alternativen. Damit wird auch die Komplexität einer neuen Version eher verständlich.
Verkaufen der Entwicklung für Objekt-Orientierung. Es wird die Anwendung von ObjektOrientierung mit einer kurzen Entwicklungszeit versprochen. Objekte werden als die Universalwaffe in den Mittelpunkt gestellt. Klassenlose Objekte werden ohne hinreichende
Strukturierung verwendet.
Im Mittelpunkt einer Entwicklung sollte dagegen stets der Anwender stehen.
Mißverständnisse beim Herangehen werden oft durch einfaches Übertragen bisheriger Praktiken
gemacht. Objekt-Orientierung erfordert dagegen eine größere Entwicklungsdisziplin.
Einsatz von Objekten ohne wohldefinierte Ziele. Man setzt Objekt-Orientierung ohne eine
entsprechende Motivation, ohne eine Methodik und ohne klare Ziele ein. Damit kann auch
nicht der gewünschte Effekt. Ziele wechseln oft sehr schnell. Deshalb ist ihre Auswirkung
auf den Entwurf zu dokumentieren.
Erzwingen von Objektbenutzung. Wird durch eine intensive Propaganda eine objekt-orientierte
Entwicklung erzwungen ohne ausreichend darauf vorbereitet zu sein, dann sollte vor einer
objekt-orientierten Entwicklung eine gründliche Ausbildung angestrebt werden.
Ohne Berücksichtigung guter Software-Praktiken.
Ohne wohldefinierte Methodik.
Zu viel, zu schnell, zu bald.
Annahme einer linearen Entwicklung.
Spezifikationen ohne allgemeine Übereinstimmung gewechselt.
Neue Charakteristika einfach eingearbeitet.
Verwechseln von Prototyping mit Fertigstellung.
Kosten falsch berechnet.
Ohne Identifikation und Verwaltung von Risiken.
Leben und Verbreiten von Illusionen.
Benutzung der falschen Metriken.
Einsatz falscher Entwickler.
Mißverständnisse im Entwurf und bei der Analyse
Unterschätzen von Analyse und Entwurf.
Unterschätzen der Schwierigkeit von Analyse und Entwurf.
Alter Wein in neuen Schläuchen (oder umgekehrt).
Ohne Berücksichtigung der eigenen Schwächen.
Elfenbein-Turm-Lösungen.
Falsche Anzahl von Teammitgliedern.
Lösungen werden zu komplex gemacht.
Entwurf durch Aufzählung.
Reentwurf - zu oft und unter falschen Voraussetzungen.
Reentwurf - zu selten.
Berücksichtigung des falschen Kundenkreises.
Aufdrücken von neuen Paradigmen.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
Mißverständnisse durch die Umgebung und Werkzeuge
Falsche Werkzeuge für die Anwendung.
Einsatz ohne vorherigen Reentwurf der Umgebung.
Glauben an falsche Versprechen der Verkäufer.
Benutzung von C++.
Keine Benutzung von C++.
Benutzung von Werkzeuge ohne diese zu lernen.
Implementations-Mißverständnisse
Zu schnelles Implementieren.
Verkapselung verhütet nicht Entwurf.
Hoffen durch schnellen Erfolg beim Prototyping.
Zu viele Versprechen ohne sie zu halten.
Detail für spätere Implementation gelassen.
‘Code-and-go’-Implementation.
Kernentscheidungen nicht dokumentiert.
Mißbrauch von Konzepten.
Klassen- und Objekt-Mißverständnisse
Verwechseln der Hierarchien (is-a, has-a, is-using).
Verwechseln von Interface-Vererbung und Implementations-Vererbung.
Schlechte Benutzung von Vererbung.
Kernklassen überladen oder übersplittet.
Kernklassensemantik verletzt.
Abstrakte Objektklassen ohne Bedeutung.
Aufgeschwemmte Objekte.
Durchsichtige Objekte.
Objekte mit der Universalität von Schweizer Armeemessern.
Hyperspaghettiklassen und -objekte.
Kodierungs-Mißverständnisse
Kopieren von Objekten.
Identifikatoren und Identifizierung.
Objekte entschlüpfen.
Speichervergeudung.
Fälle sind nicht gleich polymorphe Funktionen.
Mißverständnisse bei der Qualitätssicherung
Vergessen der kombinatorischen Explosion.
Auskommen ohne Komponententests.
Testen nach Abschluß.
Unterschätzen des Testens und Kontrolle der Anforderungen und Kosten.
Mißverständnisse bei der Wiederverwendung
74
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
75
Unterschätzung der Wiederverwendbarkeit.
Unrealistische Erwartungen.
Zu enge Ausrichtung auf Kode-Wiederverwendung.
Keine Beachtung der Wiederwendung.
Verallgemeinerung zu spät.
Zu komplexe Verknüpfungen.
Zyklische Abhängigkeiten.
5.2.5 Objektrelationale Datenbanksysteme
Obwohl mit den relationalen Datenbanken ausgereifte, leistungsfähige und theoretisch untermauerte
Systeme vorliegen, ist der alleinige Einsatz des relationalen Datenbankkonzeptes in vielen Anwendungsfällen nicht befriedigend, da die Existenz von nur einfachen Datentypen Modellierungen komplexer Aufgabenstellungen nicht unterstützt.
Objektorientierte Datenbanken sind zwar genau hierzu zu in der Lage, können aber nicht ohne
weiteres Datenbestände aus den älteren relationalen Systemen übernehmen. Außerdem stellen objektorientierte Datenbanken keinen vollständigen Ersatz für relationale Datenbanken dar, da sie in
den klassischen Anwendung für relationale Systeme, also Verwaltung großer, einfach strukturierte
Datenbestände, gegenüber diesen Systemen konzeptionell im Nachteil sind. Objektrelationale Datenbanksysteme wurden entwickelt um die Vorteile des objektorientierten und des relationalen Konzeptes
zu vereinen und dabei deren jeweilige Nachteile auszuschalten.
Nachteile relationaler Datenbanksysteme.
Die grundlegende Einschränkung relationaler Datenbanken ist Tatsache, daß diese von Hause aus
nur einfache Datentypen anbieten und darüber hinaus nicht die Neudefinition von benutzerdefinierten Datentypen gestatten. Allein die Fähigkeit zum Umgang mit komplexen Datentypen würde den
Datenbankentwurf in viele Fällen vereinfachen.
Für komplexe Aufgabenstellung hat sich die objektorientierte Modellierung durchgesetzt. Objektorientierte Konzepte werden aber von relationalen Datenbanken in keiner Weise unterstützt, wodurch
der Datenbankentwurf in solch einem Fall extrem umständlich wird. Ist ein solches komplexes, objektorientiertes Modell einmal in das Relationenschema umgesetzt worden, so können selten alle Attribute
eines Objektes aus dem Ausgangmodell in einer Tabelle untergebracht werden. Vielmehr ist es notwendig ein Objekt auf mehrere Tabellen aufzuteilen. Sollen in solch einem Fall durch eine Anfrage
alle Attribute dieses Objektes ermittelt werden, so sind hierzu explizite Join-Operationen notwendig.
Für komplexe Aufgabenstellungen bei denen objektorientierte Modellierung angebracht ist wird also nicht nur der Datenbankentwurf komplizierter, sondern in vielen Fällen müssen auch die späteren
Anfragen an die Datenbank umständlicher formuliert werden.
Relationale Datenbanken kennen keine Objektidentität. Dieses Merkmal objektorientierter Datenbanken und Programmiersprachen erlaubt die Identifizierung eines Objektes selbst dann, wenn all
seine Attribute in ihrem ursprünglichen Wert verändert worden sind. Wird ein Objekt in einem Tupel
einer relationalen Tabelle gespeichert, so verliert es seine Identität, also die Möglichkeit es von außen
eindeutig zu identifizieren sobald sein Primärschlüssel geändert wird.
Von einer rein relationalen Datenbank wird auch Persistenz durch Erreichbarkeit nicht unterstützt.
Bei diesem Persistenzkonzept werden alle Objekte in die Datenbank aufgenommen, die von einem
bereits gespeicherten Objekt referenziert werden. Da auf diese Weise das Persistenzmerkmal von
Objekt zu Objekt weitergegeben wird, ist z.B. das Abspeichern oder Löschen einer kompletten Listen
mit nur einer Operation auf dem Listenkopf möglich. Bei relationalen Datenbanken muß man hierzu
explizit jedes Element Speichern oder Löschen.
Ein weiteres Manko ist die geringe Mächtigkeit von SQL, der Datenbankprogrammiersprache
relationaler Systeme. Anspruchsvolle Berechnungen lassen sich besser oder ausschließlich in einer
externe Programmiersprache verwirklichen. Auch ist es nicht möglich benutzerdefinierte Prozeduren
oder Funktionen in SQL zu erstellen. Muß im Anwendungsfall auf eine externe Programmiersprache
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
76
ausgewichen werden, so kommt es beim Datenaustausch zwischen Datenbank und externer Programmiersprache zum sogenannten Impedance Mismatch. Dieser Begriff beschreibt den Umstand das die
Typsysteme von Datenbank und Programmiersprache sich unterscheiden. So muß das externes Programm dafür sorgen, daß die von der Datenbank gelieferten Daten in das Typsystem der Programmiersprache umgesetzt werden. Umgekehrt müssen die, in die Datenbank zu transferierenden, Daten zuvor
in einen Datenbankkonformen Typen konvertiert werden. Dieser zusätzliche Programmieraufwand ist
nicht nur zeitraubend, sondern zudem eine unerwünschte mögliche Fehlerquelle. Abschließend nochmals eine Auflistungen der größten Schwächen relationaler Systeme:
• keine komplexen Typen
• keine Objektorientierung
• keine Objektidentität, Primärschlüssel müssen durch Programmierer geeignet gewählt werden
• keine Persistenz durch Erreichbarkeit
• SQL als Programmiersprache nicht mächtig genug, keine benutzerdefinierbaren Prozeduren
• Impedance Mismatch: Typen von SQL und externen Programmiersprachen passen nicht zueinander und müssen ineinander konvertiert werden
Nachteile objektorientierter Datenbanksysteme.
Trotz der im letzten Abschnitt beschriebenen Nachteile stellen relationale Datenbanksysteme derzeit
die weit verbreitetste Technologie dar. Für die Datenbestände, die hier gepflegt werden, ist es für den
Fall, daß die relationale Technologie nicht mehr als ausreichend erachtet wird, wünschenswert, daß
sie mit möglichst geringem Aufwand auf das neue Datenbanksystem zu portieren sind. Aufgrund der
grundlegenden Unterschiede zwischen relationalen und objektorientierten Systemen ist die Migration
von Erstem zu Zweitem keineswegs ohne weiteres zu erledigen.
Bei Anwendungsfällen, in denen sich die relationale Datenbanktechnologie bewährt hat, also vor
allem beim Verwalten großer, einfach aufgebauter Daten, ist zwar prinzipiell der Einsatz von objektorientierten Systemen möglich, allerdings nicht sonderlich empfehlenswert. In diesen Fällen sind
objektorientierte Datenbanksysteme in der Regel erhebliche langsamer. Ein Grund hiefür ist die gesteigerte Komplexität objektorientierter Datenbankprogrammiersprachen, die eine datenbankinterne
Optimierungen von Lese- und Schreibzugriffen erschwert.
Ein weiterer Nachteil, der mit der Komplexität und Leistungsfähigkeit objektorientierter Datenbankprogrammiersprachen zusammenhängt, ist die erhöhte Fehleranfälligkeit die diese Komplexität
mit sich bringt. Je einfacher und überschaubarer eine Programmiersprache desto geringer ist auch
die Wahrscheinlichkeit von Programmierfehlern, welche den Datenbestand einer Datenbank eventuell
verfälschen könnten.
Den objektorientierten Datenbanken fehlt das theoretische Fundament ihrer relationalen Verwandten, welche mathematisch mit Hilfe der Relationenalgebra eindeutig beschrieben werden können.
Auch sind relationale Datenbankprodukte in der Regel ausgereifter, schließlich existieren diese Produkte seit Beginn der achtziger Jahre, während objektorientierte Datenbanken erst in den Neunzigern,
einhergehend mit der Etablierung objektorientierter Entwurfs und Programmiermethoden, entstanden
sind.
Ein Rollenkonzept ist bei objektorientierten Datenbanken zwar vorhanden, allerdings in bestimmten Fällen recht aufwendig nur durch Mehrfacherbung zu realisieren. Allgemein kann gesagt werden,
daß je mehr Rollen ein Objekt annehmen kann, desto umständlicher ist das objektorientierte Rollenkonzept.
In Kapitel 2 wurde als grundlegende Anforderung an Datenbanksysteme die Datenunabhängigkeit genannt. Objektorientierte Datenbanksysteme besitzen allerdings weder ein Sichtenkonzept, welches logische Datenunabhängigkeit ermöglichen würde, noch implementieren sie externe Datenunabhängigkeit. Es wird die konzeptuelle Ebene, die Objektstrukturen, nahezu eins zu eins auf die
verwendeten Massenspeichermedien ausgelagert. Das Fehlen von Datenunabhängikeit äußert sich bei
nachträglichen Änderungen an konzeptueller oder physischer Ebene, und führt in diesen Fällen zu
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
77
einem Mehraufwand, beispielsweise zum Anpassen bereits bestehender Applikationen an neue Datentypen, der bei bestehender Datenunabhängigkeit nicht erbracht werden muß.
Zusammenfassen weist ein objektorientiertes Datenbanksystem also folgende Schwachpunkt auf:
• Migration relationaler Datenbestände in objektorientierte Datenbanken nicht ohne weiteres möglich
• Performanznachteil bei großen, einfach strukturierten Datenbeständen
• Höhere Anfälligkeit für Programmierfehler, da Datenbanksprache komplexer
• keine theoretische Untermauerung, nicht so ausgereift wie relationale Systeme
• Rollenkonzept in bestimmten Fällen umständlich
• Keine Datenunabhängigkeit, da kein Drei-Ebenen Konzept
Resultierende Anforderungen für objektrelationale Datenbanksysteme.
Relationale Datenbanksysteme stellen heute eine etablierten Technologie dar, die in vielen Bereichen
der Datenverarbeitung erfolgreich eingesetzt wird. Ein Großteil aller Geschäfts- und Prozeßdaten ist
in relationalen Datenbanken abgelegt. Die von den Systemen angebotenen Datentypen und Anfragesprachen sind für die typischen Standard-Datenbankanwendungen ausreichend. Nicht-StandardDatenbankanwendungen stellen neue Anforderungen an Datenbanksysteme wie den Umgang mit
komplex strukturierten Multimedia Daten. In einem Städteinformationssystem müssen beispielsweise
Anfahrtspläne, Photographien und mit Bildern angereicherte Dokumente ebenso wie Audiodaten und
Videos verwaltet werden. Aufgrund der anwendungsspezifischen Anforderungen an neue Datentypen,
wäre eine herstellerseitige Ergänzung der vordefinierten Datentypen um neue Typen unzureichend. Es
sollte vielmehr jedem Entwickler möglich sein, das Datenbanksystem seinen Bedürfnissen entsprechend mit neuen Datentypen und Funktionen zu erweitern.
Somit werden die Anforderungen an ein neues Datenbankkonzept offenbar: Es sollte, um problemlose Übernahme vorhandener Datenbestände zu ermöglichen, auf der konventionellen relationalen Technologie aufsetzen und diese durch objektorientierte Erweiterungen ergänzen. Hierfür wäre
eine objektorientierte Erweiterung des SQL-Standards wünschenswert, der erlaubt das Datenbanksystem mit neuen Typen, Funktionen und Regeln zu erweitern, ohne allerdings die Komplexität der
Sprache ausufern zulassen. Genau dieser Gedanke wird von objektrelationalen Datenbanksystemen
verfolgt.
Ausgangspunkte für die aktuellen objektrelationalen Datenbankprodukte sind die etablierten relationalen Systemen, die die Hersteller nun um objektorientierte Konzepte erweitern, um die erwähnten
Einschränkungen relationaler Systeme auszuschalten. Da mit SQL:1999 erst seit kurzem ein wohldefinierter Standard für objektrelationale Funktionalität besteht, ist die Implementierung objektrelationeller Merkmale in den verschiedenen Produkten auch unterschiedlich weit fortgeschritten.
Merkmale objektrelationaler Datenbanksysteme.
Das objektrelationale Konzept ist relativ neu, es ist durch Integration bekannter Ansätze und durch
logische Weiterentwicklung entstanden. Seit vielen Jahren hat man immer wieder versucht das relationale Datenbankmodell zu erweitern, weil die Umstellung relationaler Datenbestände auf das strikte
objektorientierte Konzept sehr umständlich bleibt. Bevor man aber auf das objektrelationale Modell
gekommen ist, sind schon viele Neuerungen und Forschungen gemacht worden. Daraus sind neue
Konzepte entstanden. Alle Konzepte sind unter dem Begriff “Postrelationales Datenbanksystem” zu
verstehen. Der Name Postrelational soll an die unternommene Erweiterung des relationalen Modells
erinnern. Zu den am häufigsten realisierten Konzepten zählen:
• Erweiterte, vordefinierte und benutzerdefinierte Datentypen
• Funktionen und Methoden
• Typkonstruktkoren
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
78
• Objektidentität
• Referenzen
Die Basis für diese Systeme ist jeweils das Relationenmodell. Unterscheiden kann man Systeme dieser
Entwicklungsrichtung wieder nach:
• Relationalen Datenbanksystemen mit strukturellen Erweiterungen
• Relationalen Datenbanksystemen mit Verhaltensmäßigen Erweiterungen
• Relationalen Datenbanksystemen mit einem ADT-Konzept, wobei die ADTs gleichermaßen
Struktur und Verhalten definieren
• Relationalen Datenbanksystemen, die innerhalb des Relationenmodells relativ weitgehend ein
objektorientiertes Datenbankmodell verwirklichen
Wann ist ein System objektrelational? Das Unterscheidungsmerkmal zwischen relationalen und
objektrelationalen Datenbanken ist die Unterstützung komplexer Datentypen. In der Praxis müßte
man aber dadurch viele postrelationale Systeme, die die Objektorientierung nicht verwirklichen als
objektrelational bezeichnen. Zwischen objektrelationalen und objektorientierten Datenbanken trennt
man nach der Existenz von Abfragesprachen.
Objektrelational fordert in erster Linie, daß das relationale Modell vollständig unterstützt wird.
Begriffe wie Entitätstypen, Attribute, Tupel, Primärschlüssel und Fremdschlüssel, Projektion, Selektion und Verbindung von Tabellen gehören hier nach wie vor zum Grundvokabular. Das objektrelationale Model versucht darüber hinaus ein Datenbankmodell zu erschaffen das mit “einige OO-Konzepten
in der Form einer Tabelle” charakterisiert werden kann. Persistente Daten werden schon längst mit
einer Tabelle verarbeitet, hinzugekommen ist nun die Fähigkeit, das Felder der Tabelle strukturierte
Daten bzw. abstrakte Datentypen einnehmen können sollen. Außerdem sollen aus dem objektorientierten Konzept Merkmale wie Vererbungsprinzipen und Methodenüberschreibung (Overriding) integriert
sein.
Erweiterung relationaler Datenbanksysteme um abstrakte Datentypen.
Damit relationale Datenbanksysteme mit abstrakten Datentypen umgehen können benötigen sie
die folgenden Erweiterungen:
• komplexe, benutzerdefinierbare Datentypen
• Funktionen, Methoden
• Typenkonstruktoren
Unter komplexen Datentypen versteht man Typen wie Struktur und Menge. Benutzerdefinierbare Datentypen resultieren aus der Kombination der internen Datentypen der Datenbank. Funktionen konnten
bisher in Standard-SQL nicht erzeugt werden. Dieses, in herkömmlichen Programmiersprachen schon
lange bekannte Konzept zur Programmstrukturierung und Wiederverwendung von Quellcode, kann
somit auch in Datenbanken Verwendung finden. Angewandt wird es z. B. für benutzerdefinierbare
Operationen in Anfragen. Hauptelement der Erweiterung um abstrakte Datentypen ist die Einführung
von Methoden. Dabei handelt es sich um mit bestimmet Datentypen assoziierte Funktionen. In der Praxis werden Methoden verwand um zu Typen dazugehörigen Zugriffs- und Verarbeitungsfunktionen zu
definieren. Neben den klassischen einfachen Typen wie ‘Integer’ mit den Funktionen ‘Addition’ und
‘Subtraktion’ kann man nun auch neue Datentypen wie ‘Bild’ mit den Funktionen ‘Bildanzeigen’
definieren.
Jeder benutzerdefinierte Typ besitzt einen Konstruktor gleichen Namens, mit dem Objekte bzw.
Instanzen dieses Typs erzeugt werden können. Durch Aufruf eines Konstruktors wird jedoch nicht nur
eine Instanz eines Typen erzeugt, sondern der Konstruktor kann darüber hinaus als benutzerdefinierbare Methode angesehen werden, die bei jeder Erzeugung einer Instanz des Typen aufgerufen wird.
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
79
Aufgrund dieser Eigenschaft werden Konstruktoren z. B. für die Zuweisung von Initialwerten verwendet. Mit den hier erläuterten Merkmalen erweiterter relationaler Datenbanken ist es also möglich
abstrakt Datentypen zu implementieren. Die Unterstützung abstrakter Datentypen ist attraktiv, weil
Methoden als Operationen assoziiert mit diesen neuen Datentypen benutzt werden können um Datenmengen z. B. zu indexieren, zu speichern und Anfragen, die auf diese Datentypen basieren, zu
realisieren.
Objektorientierte Erweiterungen.
Wie bereits erwähnt ist das wichtigste Merkmal von objektrelationalen Datenbanken die Vererbung. Hierbei handelt es sich um ein grundlegendes objektorientierten Konzeptes, welches vor allem
dann von Vorteil ist, wenn aus Entity-Relationship-Modellen, Datenbankschemata entwickelt werden
sollen. Mit herkömmlichen relationalen Datenbanken kann so etwas nämlich nicht direkt implementiert werden. Die abgeleiteten Typen erben alle Eigenschaften von übergeordneten Typ, können aber
auch erweiterte spezifische Attribute zugewiesen bekommen, die nur für den Untertyp gelten. Diese
Form von Vererbung, also das Vererben von Attributen von Basisklassen an Unterklassen, wird auch
Strukturvererbung genannt. Eine Unterklasse erbt aber auch alle Methoden von der darüber liegenden
Klasse. Soll eine Methode in einer Unterklasse aber nachträglich gegenüber einer geerbten Methode
aus einer Basisklasse verändert werden, so wird dieser Vorgang als Overriding oder Überschreiben
bezeichnet.
Im objektorientierten Konzept existiert lediglich Vererbung auf der Ebene von Typen, die dort
Klassen genannt werden. Eine auf Basis dieser Vererbung erzeugte Hierarchie wird Typenhierarchie
genannt. Objektrelationale Systeme kennen weitergehend auch Vererbung auf Tabellenebene, bei der
eine Tabelle erstellt werden kann, indem sie Attribute einer bereits bestehenden Tabelle übernimmt.
Eine solche Tabellenhierarchie wird auch als Relationenhierarchie bezeichnet.
Eine weiteres nützliches Merkmal, daß die objektrelationalen von den objektorientierten Datenbanken übernommen haben ist die Objektidentität. Zu jedem Objekt wird automatisch ein systemweit
eindeutiger Identifikator erzeugt (OID), der z.B. zur Modellierung von Beziehungen durch Referenzen herangezogen werden kann. Dieser Identifikator bleibt während der Lebenszeit des Objekts unverändert. Mit dem OID können Referenzen erzeugt werden. Eine Referenz gleicht dem Speichern
eines Fremdschlüssels in einer Tabelle und dient dazu auf ein Objekt oder auf ein Tupel in einer Tabelle zu zeigen. Beziehungen können durch Referenzen aber “natürlicher” dargestellt werden, als durch
künstlich eingeführte Fremdschlüsselattribute. Sobald Referenzen vorhanden sind kann zwischen verschiedenen Objekten bzw. Tupeln direkt navigiert werden. Somit werden komplexe Abfragen, die
im relationalen Modell Joins über mehrere Tabellen erfordern, u.U. erheblich vereinfacht, wenn die
Beziehung durch Referenzen modelliert wird (weniger Tabellen in der from-Klausel, besser lesbare
Anfragebedingungen).
Objektrelationale Erweiterungen zu SQL.
Der lange Zeit unter dem Namen SQL3 entwickelte Standard für objektrelationale Datenbanksprachen
ist 1999 unter dem Namen SQL:1999 verabschiedet worden. Es fehlt diesem noch die Möglichkeit zur
Mehrfacherbung, welche erst mit SQL:2003 angestrebt wird. Der Aufbau des SQL:1999-Standards
besteht wie folgt aus 9 Teilen:
1. Framework: Dieser Teil beschreibt den Aufbau des Standards
2. Foundation: Die Foundation ist der eigentliche Kern des Standards
3. SQL / CLI: Das Call Level Interface des SQL:1999 Standards
4. SQL / PSM: Dies sind die sog. Persistent Storage Modules
5. SQL / Bindings
6. SQL / Transaction
7. SQL / Temporal
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
80
8. SQL / MED: Das Management externer Daten
9. SQL / OLB: Das Object Language Binding, was auch dem SQLJ entspricht
Wir wollen hier nicht die vollständige Liste aller SQL:1999- und SQL:2003-Erweiterungen angeben. Stattdessen verweisen wir auf die Vorlesung Datenbanksysteme III.
Die folgende Liste ist nicht vollständig, zeigt aber das wesentliche auf:
Ausgezeichnete Typen:
CREATE TYPE <Distinct-Typname> AS <Quelltyp> FINAL;
Konstruierte Typen:
Kollektionen:
<Elementtyp> ARRAY [<Max-Kardinalitaet>]
Zeilentypen:
ROW(<Feldname> <Datentyp>, ...,<Feldname> <Datentyp>)
Strukturierte Typen:
Wurzeltypen:
CREATE TYPE <Typname> AS
(
<Attributdefinitionsliste>
)
[[NOT] INSTANTIABLE]
NOT FINAL
[OID-Typspezifikation]
[<Methodendeklarationsliste>]
Subtypen:
CREATE TYPE <Subtypname> UNDER <Supertypname> AS
(
<Attributdefinitionsliste>
)
[[NOT] INSTANTIABLE]
NOT FINAL
[<Methodendeklarationsliste>]
Methoden:
Deklaration:
[INSTANCE|CONSTRUCTOR|STATIC]
METHOD <Methodenname>(<Parameterdefinition>)
RETURNS <R\"uckgabetyp>
[SELF AS RESULT]
Implementierung:
CREATE [INSTANCE|CONSTRUCTOR|STATIC]
METHOD <Methodenname>(<Parameterdefinition>)
RETURNS <R\"uckgabetyp>
FOR <Typname>
<Methodenrumpf>
Tabellen:
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
CREATE TABLE <Tabellenname> OF <Typname>
(
<OID-Generierung>
[,<Spaltenoptionsliste>]
[,<Tabellenbedingungsliste>
)
CREATE TABLE <Tabellenname> OF <Typname>
UNDER <Supertabellenname>
(
<OID-Generierung>
[,<Spaltenoptionsliste>]
[,<Tabellenbedingungsliste>
)
Prozedurales SQL:
Zusammengesetzte Anweisungen
BEGIN [ [ NOT ] ATOMIC ]
[ <Deklaration1>; ... ]
[ <SQL-Anweisung1>; ... ]
[ EXCEPTION <Ausnahmebehandlung>; ]
END;
Variablendeklaration:
DECLARE
<Variablen-Namen-Liste>
<Typ> [ Initialisierungswert ];
Zuweisung:
SET <Ziel> = <Quelle>;
IF-Anweisung:
IF <Bedingung1>
THEN <Anweisungs-Liste1>
[ ELSEIF <Bedingung2>
THEN <Anweisungs-Liste2>
... ]
[ ELSE <Anweisungs-ListeN> ]
END IF;
While-Schleife:
WHILE <Bedingung> DO
<Anweisungs-Liste>
END WHILE;
Prozeduren:
CREATE PROCEDURE
<Prozedur-Name> ( [ <Parameter-Liste> ] )
BEGIN
...
END;
Funktionen:
81
CAU Kiel, IfI, ISE
β
Basisdatentypen in SQL99+
Basisdatentyp
SMALLINT
INTEGER
DECIMAL(p,q)
NUMERIC(p,q)
FLOAT(p) , REAL
DOUBLE
CHAR(q)
VARCHAR(q)
BIT(q)
BIT VARYING(q)
DATE
TIME
TIMESTAMP
INTERVAL
XML
SS 2008
Datenbanken I
Bedeutung
ganze Zahl
Festkommazahl mit
Genauigkeit p und q
Fließkommazahl mit
Genauigkeit p
Zeichenkette mit fester bzw.
variabler Länge bis zu q
Bitfolge mit fester bzw.
variabler Länge bis zu q
Datum
Zeit
Zeitstempel
Zeitintervall
XML-Wert
5. Komplex strukturierte DB
Beispielwerte
1704, 4070
1003.44, 160139.9
1.5E-4, 10E20
’Das ist eine Zeichenkette’,
’SQL:1999’
B’01101’, X’9E’
DATE ’1997-06-19’, DATE
TIME ’20:30:45’
TIMESTAMP ’2002-08-23
INTERVAL ’11:15’ HOUR TO
<Titel>SQL:2003
CREATE FUNCTION
<Funktions-Name> ( [<Parameter-Liste>] )
RETURNS <R\"uckgabetyp>
BEGIN
...
RETURN <Wert>;
END;
Trigger:
CREATE TRIGGER <Name>
( BEFORE | AFTER | INSTEAD OF )
( DELETE | INSERT | UPDATE [ OF <Spalte>, ...])
[ OR (DELETE | INSERT | UPDATE [OF ...])]
...
ON ( <Tabelle> | <Sicht> )
[ REFERENCING OLD AS <alt> NEW AS <neu>]
[ FOR EACH ( ROW | STATEMENT ) ]
[ WHEN ( <Bedingung> ) ]
<Trigger-Kode in prozeduralem SQL>;
5.3
Ausblick
82
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I
5. Komplex strukturierte DB
83
Literaturhinweis
Bernhard Thalheim: Entity-Relationship Modeling, Foundations of Database Technology. Springer, 2000. ISBN 3-540-65470-4
An die Teilnehmer der Veranstaltung wird der Verkauf des Buches zu einem ermäßigten Preis (80% bzw. weniger)
durch das Sekretariat TIS organisiert. Bitte sprechen Sie persönlich bei Frau Kruse vor.
Die folgenden Bücher sind als Ergänzung des Stoffes dieses Kapitels geeignet:
Alfons Kemper, André Eickler: Datenbanksysteme - Eine Einführung, 5. Auflage. Oldenbourg 2003
Die Skripte zur Vorlesung sind abgelegt unter:
http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/kemper/kapitel1.pdf — kapitel 13.pdf
Meike Klettke, Holger Meyer: XML & Datenbanken. dpunkt Verlag, 2003
Diese Buch ist die beste und profundeste Einführung in die Datenbankgrundlagen von XMLDatenbanksystemen. Folien zum Buch findet man unter
http://www.xml-und-datenbanken.de/
Zusammengefaßte Arbeiten des Lehrstuhles zu Thema Objektorientierung:
http://www.is.informatik.uni-kiel.de/∼thalheim/OOreport.ps.gz
Weitere Literaturquellen zu diesem Kapitel der Vorlesung sind:
• Jeffrey D. Ullman, Jennifer Widom: A First Course in Database Systems. Prentice-Hall 1997