3. Datenbankmodelle für die Realisierung Relationenmodell

3. Datenbankmodelle für die Realisierung
Relationenmodell
■
Relationenmodell
■
Codd im Jahre 1970
■
Objektorientierte Modelle
■
■
Semistrukturierte Modelle und XML
Veranschaulichung eines Relationenschemas und einer
Relation
Relationenname
R
A1
...
...
Attribute
An
} Relationenschema
...
...
Relation
Tupel
VL Datenbanken I – 3–1
Beispiele für Relationen
Personen
PANr
4711
5588
6834
8832
9999
Vorname
Andreas
Gunter
Michael
Tamara
Christa
Pers_Telefon
Nachname
Heuer
Saake
Korn
Jagellovsk
Loeser
PANr
4711
4711
5588
5588
9999
VL Datenbanken I – 3–2
Begriffe des Relationenmodells
PLZ
18209
39106
39104
38106
69121
Ort
DBR
MD
MD
BS
HD
GebDatum
31.10.1958
05.10.1960
24.09.1974
11.11.1973
10.05.1969
Telefon
038203-12230
0381-498-3401
0391-345677
0391-5592-3800
06221-400177
VL Datenbanken I – 3–3
Begriff
Informale Bedeutung
Attribut
Wertebereich
Spalte einer Tabelle
mögliche Werte eines Attributs (auch
Domäne)
Element eines Wertebereichs
Menge von Attributen
Menge von Zeilen einer Tabelle
Zeile einer Tabelle
Menge von Relationenschemata
Menge von Relationen (Basisrelationen)
Attributwert
Relationenschema
Relation
Tupel
Datenbankschema
Datenbank
VL Datenbanken I – 3–4
Begriffe des Relationenmodells II
Begriff
Formalisierung Relationenmodell I
Attribute und Domänen
Informale Bedeutung
Schlüssel
minimale Menge von Attributen,
deren Werte ein Tupel einer Tabelle eindeutig identifizieren
Primärschlüssel
ein beim Datenbankentwurf ausgezeichneter Schlüssel
Fremdschlüssel
Attributmenge, die in einer anderen Relation Schlüssel ist
Fremdschlüsselbedingung alle Attributwerte des Fremdschlüssels tauchen in der anderen Relation als Werte des
Schlüssels auf
■ U
nichtleere, endliche Menge: Universum
■ A ∈ U:
Attribut
■ D = {D1 , . . . , Dm }
Menge endlicher, nichtleerer Mengen:
jedes Di : Wertebereich oder Domäne
■
total definierte Funktion dom : U −→ D
■
dom(A): Domäne von A
w ∈ dom(A): Attributwert für A
VL Datenbanken I – 3–5
VL Datenbanken I – 3–6
Formalisierung Relationenmodell II
Formalisierung Relationenmodell III
Relationenschemata und Relationen
Datenbankschema und Datenbank
■
Relation r über R = {A1 , . . . , An } (kurz: r(R)
) ist
S
endliche Menge von Abbildungen t : R −→ m
i=1 Di ,
Tupel genannt
Menge von Relationenschemata S := {R1 , . . . , Rp }:
Datenbankschema
■
Datenbank über S : Menge von Relationen
d := {r1 , . . . , rp }, wobei ri (Ri )
■
Es gilt t(A) ∈ dom(A) (t(A) Restriktion von t auf A ∈ R)
■
Datenbank d über S : d(S)
■
für X ⊆ R analog t(X) X-Wert von t Menge aller
Relationen über R: REL(R) := {r | r(R)}
■
Relation r ∈ d: Basisrelation
■ R ⊆ U:
■
Relationenschema
VL Datenbanken I – 3–7
VL Datenbanken I – 3–8
Unterschied zur klassischen Definition I
„klassische“ Definition einer Relation: Teilmenge des
kartesischen Produktes
■
r1 ⊆ dom(PANr) × dom(Vorname) × dom(Nachname)
Unterschied zur klassischen Definition II
r1
PANr
Vorname
Nachname
PANr
Nachname
4711
Andreas
5588
Gunter
Heuer
4711
Heuer
Andreas
Saake
5588
Saake
Gunter
6834
Michael
Korn
6834
Korn
Michael
r2
Relationen r1 und r2 bestehen aus Tupeln t1 , t2 , t3 mit
und
t1 (PANr)=4711, t1 (Vorname)=‘Andreas’,
t1 (Nachname)=‘Heuer’
t2 (PANr)=5588, t2 (Vorname)=‘Gunter’,
t2 (Nachname)=‘Saake’
t3 (PANr)=6834, t3 (Vorname)=‘Michael’,
t3 (Nachname)=‘Korn’
r2 ⊆ dom(PANr) × dom(Nachname) × dom(Vorname)
sind ungleich bei Definition mittels kartesischem Produkt!
VL Datenbanken I – 3–9
Integritätsbedingungen
■
=⇒
■
∃B ∈ K : t1 (B) 6= t2 (B)].
Schlüssel: ist minimale identifizierende Attributmenge
{Vorname, Nachname, PLZ, Geburtsdatum} und
{PANr} für Personen
{PANr, Telefon} für Pers_Telefon
■
Primattribut: Element eines Schlüssels
■
Primärschlüssel: ausgezeichneter Schlüssel
■
Fremdschlüssel: X(R1 ) → Y (R2 )
VL Datenbanken I – 3–10
Relationenalgebra
Identifizierende Attributmenge K := {B1 , . . . , Bk } ⊆ R:
∀t1 , t2 ∈ r [t1 6= t2
Vorname
Selektion: σNachname=’Meyer’ (r(Personen))
Projektion: πVorname, PLZ (r(Personen))
■ Verbund: r(Personen) ./ r(Pers_Telefon)
■
■
Mengenoperationen: ∩, ∪, −
■
Umbenennung: βWohnort←Ort (r(Personen))
{t(X)|t ∈ r1 } ⊆ {t(Y )|t ∈ r2 }
VL Datenbanken I – 3–11
VL Datenbanken I – 3–12
Objektorientierte Modelle inkl. ODMG
Objektorientierte Datenbankmodelle bieten
■ mehr Konzepte zur Darstellung der Struktur
◆ komplexe Werte, die mit Typkonstruktoren wie set of,
tuple of und list of beschrieben werden können,
◆ Objektidentität, die gespeicherte Objekte von Werten,
die sie besitzen, unterscheiden kann,
◆ Vererbung von Attributen zwischen Objekttypen, die
in einer IST-Beziehung stehen, sowie
■
mehr Konzepte zur Darstellung objektspezifischer
Operationen, etwa Methoden (legen Operationen fest,
mit denen die Anwendungsdaten (nur) manipuliert
werden dürfen)
Modell nach Beeri
■
Strukturteil
◆ Typen und Typkonstruktoren
◆ Objektidentität
◆ Klassen
◆ Strukturvererbung (oder Klassen- und Typhierarchie)
■
Operationenteil
◆
■
Anfrage- und Änderungsoperationen
Höhere Konzepte
◆ Metaklassen
◆ Methoden, Vererbung und Overriding von Methoden
◆ Einkapselung
VL Datenbanken I – 3–13
VL Datenbanken I – 3–14
Definition eines OODBS
Klassifikation von OODBS
Datenbanksystem, das
Systeme (seit 1987, Manifesto 1989,
ODMG-Industrie-Standard 1993)
■
auf einem objektorientierten Datenbankmodell mit
Strukturteil, Operationenteil und höheren Konzepten
basiert,
■
auf der konzeptuellen Ebene durch neue Datentypen
und neue Funktionen erweiterbar ist,
■
weitere Datenbank-Eigenschaften besitzt (wie
Persistenz, Speicherungsstrukturen und Zugriffspfade,
Transaktionen und Concurrency-Control-Komponenten
sowie Recovery-Mechanismen)
■
und neben den Operationen des Operationenteils
(Anfrage- und Datenmanipulationssprache) auch eine
komplette Programmier-Umgebung beinhaltet.
VL Datenbanken I – 3–15
■
Erweiterung objektorientierter Programmiersprachen
◆ C++- oder Smalltalk-Datenmodell (etwa GemStone,
ObjectStore, POET, . . . )
■
Erweiterung relationaler Datenbanksysteme
◆ Relationales Datenmodell + Typkonstruktoren +
Objektidentität + . . . (etwa DASDBS, AIM/P,
POSTGRES, . . . )
◆ speziell: Objekt-relationale Datenbanksysteme (etwa
Illustra, UniSQL, jetzt auch viele RDBS wie DB2)
■
Neuentwicklungen
◆ eigenes OO Datenmodell (etwa O2 , Itasca, OSCAR)
VL Datenbanken I – 3–16
Strukturteil
Strukturteil II
■
Typen und Typkonstruktoren
◆ Standard-Datentypen wie INTEGER und STRING
◆ Typkonstruktoren wie SET OF und TUPLE OF:
kompliziertere Typen
■
Klassen
◆ beschreiben Objekte mit ähnlichen Eigenschaften
◆ Typ, Objektvorrat und Objektbehälter
◆ Methoden
■
Objektidentität
◆ vom System vergeben
◆ eindeutig
◆ unveränderbar
◆ für den Benutzer unsichtbar
■
Komponenten-Beziehungen bei Klassen (VERLAGE
Komponente von BÜCHERN)
VL Datenbanken I – 3–17
Definition eines Objekttyps
Strukturteil III
■
VL Datenbanken I – 3–18
Is-A-Beziehungen
◆ Klassenhierarchie: Objektmenge der Unterklasse ist
Teilmenge der Objektmenge der Oberklasse
(STUDENTEN sind eine Teilmenge der PERSONEN)
◆ Typhierachie: Typ der Unterklasse hat mehr
Eigenschaften als Typ der Oberklasse
(STUDENTEN haben neben den Eigenschaften von
Personen auch noch MATRIKELNUMMER und
STUDIENFACH)
VL Datenbanken I – 3–19
set of(tuple of(PANr: integer,
Name: tuple of(Vorname: string,
Nachname: string),
Adresse: tuple of(PLZ: integer,
Ort: string,
Strasse: string,
Hausnummer: integer ),
Telefone: set of(Telefon: string),
Geburtsdatum: date))
VL Datenbanken I – 3–20
Beispiel Objektrelation
Bücher
α1
ISBN
3-8931-
Titel
DB2
Verlag
β1
Klassendeklarationen im O2-Modell I
Autoren
Stichworte
Autor
Stichwort
Vossen
RDB
...
...
Witt
α2
0-8053-
Princ. of DBS
β2
Elmasri
RDB
...
Navathe
Lehrbuch
...
...
...
ER
...
...
...
...
...
class Personen
type tuple(PANr: integer,
Name: tuple(Vorname: string,
Nachname: string),
Adresse: tuple(PLZ: integer,
Ort: string,
Straße: string,
Hausnummer: integer ),
Telefone: set(Telefon: string),
Geburtsdatum: date)
VL Datenbanken I – 3–21
Klassendeklarationen im O2-Modell II
class Studenten inherits Personen
type tuple(Matrikelnummer: integer,
Studienfach: string,
Vater: Personen,
Mutter: Personen,
Zeugnis: set(tuple(Fach: string,
Note: real)))
VL Datenbanken I – 3–23
VL Datenbanken I – 3–22
Operationen
■
mindestens die Möglichkeiten wie in Relationenalgebra /
SQL
■
relationale Semantik: Extraktion von Werten aus
Zuständen von Objekten
; geschachtelte Relationen
■
objekterzeugende Semantik: Erzeugung neuer Objekte
als Anfrageergebnis mit Zuständen, die von
vorhandenen Objekten extrahiert wurden
; Ergebnis ist eine dynamisch erzeugte Klasse
■
objekterhaltende Semantik: Auswahl der in der
Datenbank vorkommenden Objekte mit neuen
Zuständen
; Ergebnis ist dynamisch erzeugte Ober- / Unterklasse
VL Datenbanken I – 3–24
Operationen II
Höhere Konzepte
schwach ausgeprägt bei OOPL-Erweiterungen
■
Standard-Methoden auf COLLECTION-Klassen
(Selektionen mit sehr einfachen Selektionsprädikaten)
■
„OSQL“ mit relationaler Semantik (nicht so mächtig wie
Standard-SQL)
■
objekt- oder klassenspezifische Operationen
■
werden wie Eigenschaften von Ober- zu Unterklassen
vererbt
■
Implementierung einer Methode kann bei Vererbung
noch verändert werden (Overriding)
■
System wählt selbständig zur Laufzeit passende
Implementierung (dynamisches Binden)
VL Datenbanken I – 3–25
Klassendeklarationen im O2-Modell III
class Studenten inherits Personen
type tuple(Matrikelnummer: integer,
Studienfach: string,
Vater: Personen,
Mutter: Personen,
Zeugnis: set(tuple(Fach: string,
Note: real)))
method Zur_Verfuegung: money
VL Datenbanken I – 3–27
VL Datenbanken I – 3–26
Methodendeklaration im O2-Modell
method body Zur Verfuegung: real in class Studenten
{ return ( self → Vater → Zur_Verfuegung
+ self → Mutter → Zur_Verfuegung)
∗ 0.1 }
VL Datenbanken I – 3–28
Der ODMG-Standard
Historie
■
ODBMS seit Ende der 80er Jahre kommerziell verfügbar
◆ Entwicklung ohne Anlehung an Standards
◆ unterschiedliche Datenmodelle, DDL und DML
■
Probleme für Portabilität von Anwendungen
■
Gründung der Object Database Management Group
(ODMG) als Untergruppe der OMG
◆ Hersteller von ODBMS
◆ kein offizielles Standardisierungskomitee
◆ Industriestandard
◆ Abdeckung eines Großteils des ODBMS-Marktes
■
Anfang 1994: Veröffentlich des ersten Entwurfs
(ODMG-93)
◆ Verpflichtung der Hersteller zur Implementierung des
Standards
■
1994: korrigierte Version ODMG-93 1.1
■
1996: ODMG-93 1.2
◆ Änderungen verhindern Aufwärtskompatibilität
■
1998: ODMG 2.0
◆ erstmals Java-Binding
■
2000: Veröffentlichung der aktuellen Version 3.0
VL Datenbanken I – 3–29
VL Datenbanken I – 3–30
Umfang des Standards
Ziele
■
Portabilität von Anwendungen
■
Unabhängigkeit von einzelnen Herstellern
■
Portabilität auf Quellcode-Ebene
■
Überwindung des „impedance mismatch“
■
Berücksichtigung von
◆ ODBMS: DBMS, das Datenbankfunktionalität mit
OOP-Features verbindet
◆ ODM: System, das relationale oder nicht-oo DBMS
mit OOP-Features verbindet (objektrelationales
Mapping)
VL Datenbanken I – 3–31
■
„Kompromiss“ zwischen existierenden ODBMS, OOPL
und Forschungsprototypen
■
Objektmodell inkl. DB-Konzepte (Persistenz,
Transaktions- und Datenbankverwaltung)
■
Objektdefinitionssprache ODL (Erweiterung der
OMG-IDL)
■
Objektanfragesprache OQL als Anpassung/Erweiterung
von SQL
■
Programmiersprachenanbindung (Binding): C++,
Smalltalk, Java
■
Objektaustauschformat OIF
VL Datenbanken I – 3–32
Objektmodell
■
Objekte
■
Kapselung
■
Objektidentität
■
Typen, Klassen und Beziehungen
■
Spezialisierung
■
Persistenz, Transaktionen und DB-Operationen
Objekte und Werte
■
Unterscheidung zwischen Objekten und Literalen
(Werten)
■
für jeden Datentyp existiert Literal Null (Semantik analog
SQL-92)
■
Zustand eines Objektes ist durch Werte der Attribute
(inkl. der Referenzattribute definiert)
VL Datenbanken I – 3–33
Datentypen
Verhalten
■
Atomare Datentypen wie float, boolean, string und
enum
■
Kollektionsdatentypen wie set, bag, list und array inkl.
Iteratoren
■
■
■
VL Datenbanken I – 3–34
■
Für Objekte können Operationen festgelegt werden
■
Operationsausführung kann Ausnahmen erzeugen, die
durch geeignete Mechanismen abgefangen und
behandelt werden können
strukturierter Datentyp struct
■
vordefinierte Datentypen date, interval, time,
timestamp
Parameter der Operationen werden mittels in, out bzw.
inout näher spezifiziert
■
Schlüsselwort readonly bzgl. Attribut legt gleichnamige
Operation fest, die das Attribut nur liest
■
Für Operationen können keine Zusicherungen bzgl.
Verhältnis zum Objektzustand gemacht werden
Referenzdatentyp
VL Datenbanken I – 3–35
VL Datenbanken I – 3–36
Kapselung
■
■
Objektidentität
Unterscheidung zwischen
◆ Schnittstelle: umfasst öffentliche Attribute und
Operationen und wird mittels ODL festgelegt
◆ Implementierung:
– umfasst Methodenrümpfe entsprechend der
Signaturen
– es können private Attribute und Operationen
definiert werden
– Implementierung in C++, Smalltalk, Java
– zu einer Schnittstelle sind mehrere
Implementierungen (bzgl. PS) möglich
· Programmiersprachenunabhängigkeit
· aber auch redundante Implementierung
■
Generierung OID bei Objekterzeugung
■
OID ist datenbankweit eindeutig
■
OID ändert sich nicht bzgl. Objekt
■
keine Aussage, ob OIDs nach Objektlöschung
wiederverwendet werden
■
OID werden vor Anwendungen verborgen
■
Wertebereiche von Referenzdatentypen umfassen
Menge von OID
ODMG unterstützt keine Sichten
VL Datenbanken I – 3–37
Objektidentität
VL Datenbanken I – 3–38
Typen und Klassen
■
Operation same_as zum Test auf identische Objekte
■
keine Unterstützung zum Test auf tiefe und flache
Gleichheit
■
Operation copy realisiert flaches Kopieren
■
Identifizierung über Objektnamen wird unterstützt →
Abbildung auf OID
VL Datenbanken I – 3–39
■
Typspezifikationen (ODL)
◆ Schnittstellendefinition: spezifiziert ausschließlich
abstraktes Verhalten
◆ Klassendefinitionen: sowohl abstraktes Verhalten als
auch abstrakten Zustand
◆ Literaldefinition: abstrakten Zustand von
Nicht-Objekttypen
■
interface: abstrakter, nicht instantiierbarer Typ
■
class: Klasse, von der Instanzen erzeugt werden können
VL Datenbanken I – 3–40
Klassen: Beispiel
Klassen
■
ODL definiert Schnittstellenbeschreibung (Attribute,
Beziehungen, Methodensignaturen)
■
Implementierung von Klassen ausschließlich in
Programmiersprachenanbindung
■
optionales Schlüsselwort extent legt persistente
Extension fest
◆ bei Instantiierung wird Objekt automatisch in
Extension eingetragen
◆ wichtig für: Anfragen, Eindeutigkeitsbedingungen,
Indexverwaltung, . . .
class Mitarbeiter (
extent MitarbeiterExtension) {
attribute long mitarbNr;
attribute struct Name {
string vorname;
string nachname } name;
attribute Date geburtstag;
attribute List<string> telefone;
...
void gehalt_erhoehen (in short betrag);
};
VL Datenbanken I – 3–41
Schlüsselbedingungen
VL Datenbanken I – 3–42
Klassenbeziehungen
class Mitarbeiter (
extent MitarbeiterExtension,
keys mitarbNr, (name, geburtstag)) {
attribute long mitarbNr;
attribute string name;
attribute date geburtstag;
attribute short gehalt;
...
};
VL Datenbanken I – 3–43
■
ODMG = Implementierungsmodell
◆ Beziehungen zwischen Objekten über
Referenzattribute
◆ Schlüsselwort relationship
◆ nur binäre Beziehungen
◆ keine Beziehungsattribute
◆ keine Aggregationsbeziehungen → existentielle
Abhängigkeiten und Propagierung müssen
operational definiert werden
■
uni- und bidirektionale Beziehungen
◆ Schlüsselwort inverse
◆ Referentielle Integrität
■
Kardinalitäten über Kollektionstypen
VL Datenbanken I – 3–44
Beziehungen: Beispiel
Spezialisierung
class Mitarbeiter (
extent MitarbeiterExtension,
key mitarbNr) {
attribute long mitarbNr;
attribute Projekt leitet;
relationship list<Projekt>
ist_beteiligt_an
inverse Projekt::beteiligte;
...
};
■
intensionaler und extensionaler Aspekt (über Extents) in
kombinierter Spezialisierungshierarchie
■
Spezialisierung von Subtypen über Tupelerweiterung
bzw. Redefinition von Operationen (dynamisches
Binden)
■
Unterstützung der Substituierbarkeit
■
keine Aussage über tiefe/flache Extensionen
■
Namenskonflikte bei Mehrfachspezialisierung müssen in
PS-Anbindung aufgelöst werden
■
Unterstützung von Overloading, Overriding und
Inklusionspolymorphie
VL Datenbanken I – 3–45
Spezialisierung (II)
VL Datenbanken I – 3–46
Persistenz
■
Schnittstellen:
◆ Mehrfachvererbung (isA-Beziehung)
interface Object { ...};
interface Product : Object { ...};
■
Klassen:
◆ mehrere Schnittstellen
◆ Einfachvererbung zwischen Klassen
(extends-Beziehung)
class Book : Product { ...};
class Customer { ...};
classBusinessCustomer
extends Customer { ...};
VL Datenbanken I – 3–47
■
Unterscheidung zwischen
◆ transienten und
◆ persistenten Objekten
■
Persistenzfähige Klassen
◆ können sowohl transiente als auch persistente
Objekte enthalten
◆ konkrete Realisierung abhängig von System und
Sprachanbindung
■
Beispiel:
◆ C++: persistente Wurzelklasse d_Object
(typabhängig)
◆ Java: Verarbeitung durch Prozessor (typorthogonal)
VL Datenbanken I – 3–48
Semistrukturierte Daten
Datenmodell für semistrukturierte Daten
■
Semistrukturierte Daten/Dokumente
◆ Daten mit einer internen, oft wechselnden und nicht
streng typisierten Struktur
◆ oft im Web-Umfeld eingesetzt
■
Merkmale
◆ Kein zentrales Schema, sondern implizit in jedem
Dokument („selbstbeschreibend“)
◆ Wechselnde Struktur
◆ Daten ohne weitere Struktur
◆ Keine Datentypen bzw. Datentypen nicht als
Integritätsbedingungen
◆ große Anzahl (möglicher) Attribute
◆ Unscharfe Trennung von Daten und Schema
■
Graphenbasierte Modelle
◆ Beispiele: OEM, XML
◆ Dokument modelliert als Graph mit
– Kanten bezeichnet mit Element-Tag-Bezeichnern
– Knoten bezeichnet mit Attribut-Wert-Paaren
– Blätter bezeichnet mit Werten (Strings)
– Wurzelknoten
◆ Knoten = Objekt
VL Datenbanken I – 3–49
Beispielgraph
Repräsentation relationaler Strukturen
Einfache Abbildung anderer Datenmodelle möglich:
R2 c
d
R1 a
b
c
c2 d2
a1 b1 c1
c3 d3
a2 b2 c2
c4 d4
Buch
Titel
Data on the Web
ISBN
1-55860-622-X
Name
Morgan Kaufmann
VL Datenbanken I – 3–50
Verlag
Autor
Vorname
Adresse
SF, CA
Serge
Autor
Vorname
Nachname
Abiteboul
Peter
Nachname
Buneman
R2
R1
Tupel
Tupel
Tupel
Tupel
Tupel
b
a1
VL Datenbanken I – 3–51
b1
c
a
c
a
c
d
c
d
c
d
b
c1
a2
b2
c2
c2
d2
c3
d3
c4
d4
VL Datenbanken I – 3–52
Formale Definition
XML - Überblick
■
Graph G = (N, E) mit Menge N von Knoten (nodes),
Menge E von Kanten (edges)
■
XML = Extensible Markup Language
◆ Metasprache als Weiterentwicklung von SGML
■
zu jeder Kante e ∈ E ist geordnetes Paar von Knoten
assoziiert: Quellknoten s(e), Zielknoten t(e)
■
Metasprache: Definition von Dokumenttypen
◆ XML-Dokument = Definition (DTD) + Instanz
■
Pfad ist Sequenz e1 , e2 , . . . , ek mit
t(ei ) = s(ei+1 ), 1 ≤ i ≤ k − 1
■
■
Knoten r ist Wurzel von G, wenn es einen Pfad von r zu
allen Knoten n ∈ N, n 6= r gibt
■
Blatt ist Knoten, der nicht Quelle irgendeiner Kante ist
DTD (Document Type Definition):
◆ formale Grammatik zur Definition einer bestimmten
XML-Sprache
◆ Namen der in Instanzen erlaubten Tags sowie deren
mögliche Schachtelung
■
hier: Kanten mit Bezeichnern (labels):
◆ Label-Funktion FE : E → LE
◆ LE : Wertebereich von Kantenbezeichnern
VL Datenbanken I – 3–53
VL Datenbanken I – 3–54
XML - Beispiel einer DTD
XML - Strukturen
■
Elemente: „eingerahmt“ durch Tags
(nicht Kantenbezeichner sondern Knotenbezeichner !)
■
Attribute: Eigenschaften zu Elementen
■
Schachtelung von Elementen möglich
■
Sequenz: (E1, E2)
■
Alternative: (E1 | E2)
■
Iteration:
◆ 0 . . . n Wiederholungen: E*
◆ 1 . . . n Wiederholungen: E+
■
Optionales Element: E?
VL Datenbanken I – 3–55
<!element buch (titel, verlag, autor*,
abstrakt?)>
<!attlist buch isbn cdata #required>
<!element titel (#PCDATA)>
<!element verlag (name, adresse)>
<!element name (#PCDATA)>
<!element adresse (#PCDATA)>
<!element autor (vorname?, nachname)>
<!element abstrakt (#PCDATA)>
VL Datenbanken I – 3–56
XML - Beispieldokument
XML-Instanzen
■
Instanz = Dokument, dessen Inhalt mit Tags einer
bestimmten DTD ausgezeichnet ist
■
Wohlgeformt: enthalten Tags, die XML-Regeln
entsprechen
■
Gültig: enthalten DTD und dürfen Inhaltsmodell nicht
verletzen
■
DTD intern (im Dokument definiert) oder extern (Verweis
auf DTD)
VL Datenbanken I – 3–57
XML - Anwendungen
■
(Semi-)strukturierte Dokumente
◆ Dokumentation
◆ Web-Inhalte (erfordert Stylesheets: Zuordnung der
Präsentationsform)
■
Datenaustausch
◆ Import/Export von Daten aus Datenbanken
◆ Austausch von Geschäftsdaten (Rechnungen,
Bestellungen etc.)
◆ erfordert standardisierte DTDs
■
Informationsintegration
VL Datenbanken I – 3–59
<?xml version="1.0" ?>
<!DOCTYPE buch SYSTEM "buch.dtd" >
<buch isbn= "1-55860-622-X" >
<titel>Data on the Web</titel>
<verlag>
<name>Morgan Kaufmann</name>
<adresse>San Francisco</adresse>
</verlag>
<autor>
<vorname>Serge</vorname>
<nachname>Abiteboul</nachname>
</autor>
<autor>
<vorname>Peter</vorname>
<nachname>Buneman</nachname>
</autor>
</buch>
VL Datenbanken I – 3–58