XML und Datenbanken

XML und
Datenbanken
© K. Schild 2006/M. Mochol 2007
1
Heutige Vorlesung
letzte Woche
; Warum XML-Dokumente transformieren?
; XML-Dokumente mit XSLT transformieren
; XSL-FO zur Erzeugung von druckfähigem Layout
heutige Vorlesung
ƒ XML und Datenbanken
© K. Schild 2006/M. Mochol 2007
2
Übersicht
ƒ Daten vs. Dokumente
ƒ Wie XML persistent speichern?
ƒ Vergleich XML mit relationalem Modell
ƒ Exkurs: relationales Modell
- Darstellung von N:M-Beziehungen
- funktionale Abhängigkeiten, Normalformen
ƒ Wie Daten mit XML modellieren?
© K. Schild 2006/M. Mochol 2007
3
Daten & Dokumente
© K. Schild 2006/M. Mochol 2007
4
Daten vs. Dokumente
ƒ Auswahl der Datenbank hängt von den zu speichernden
„Objekt“
ƒ Daten- vs. Dokumentspezifische Dokumente
(data-centric vs. document-centric documents)
documents
© K. Schild 2006/M. Mochol 2007
5
Datenspezifische Dokumente
ƒ reguläre Struktur (hoher Strukturierungsgrad)
ƒ feinkörnige Daten
ƒ wenig bzw. keine gemischte Inhalte
ƒ leichte Verarbeitung für Maschinen
ƒ Beispiele: Kataloge, Verkaufsaufträge, Flugpläne, etc.
Ö traditionelle Datenbanken (relationale, objekt-orientierte)
Ö XML-fähige Datenbanken (XML-enabled databases)
© K. Schild 2006/M. Mochol 2007
6
Dokumentspezifische Dokumente
ƒ weniger reguläre Struktur /irreguläre Struktur
ƒ grobkörnige Daten
ƒ viele gemischte Inhalte
ƒ Dokument als Ganzes von Bedeutung
ƒ entwickelt für Menschen
ƒ Beispiele: Bücher, E-Mails, Werbung, etc.
Ö CMS
Ö XML Datenbanken (nativ XML databases)
© K. Schild 2006/M. Mochol 2007
7
Wie XML persistent
speichern?
© K. Schild 2006/M. Mochol 2007
8
XML vs. relationale Datenbanken
XML
relationale Datenbanken
Book
book
edition
Beginning XML 2nd
Authorship
author
author
David Hunter
Curt Cagle
Title
Edition
1
Beginning XML
2nd
Author
authors
title
BookKey
author
Chris Dix
AuthorKey
FirstName
LastName
1
David
Hunter
2
Kurt
Cagle
3
Chris
Dix
Key
BookKey
AuthorKey
1
1
1
2
1
2
3
1
3
ƒ Hierarchie (Baum)
ƒ Tabellen mit Schlüssel
ƒ Kind-Elemente:
Reihenfolge relevant
ƒ Spalten und Zeilen:
Reihenfolge egal
ƒ Anfragen: XPath
ƒ Anfragen: SQL
© K. Schild 2006/M. Mochol 2007
9
Wie XML persistent speichern?
Anwendung
Tabellen/SQL
Anwendung
Anwendung
XML
XML/XPath
Wrapper
Tabellen/SQL
relationale
Datenbank
XML als
einfachen String
speichern
© K. Schild 2006/M. Mochol 2007
XMLDatenbank
XML als
strukturiertes
XML-Dokument
speichern
Customers
CustomerNo
Customers
FirstName
LastName
CityId
1
CustomerNo
2
1
Brian
FirstName
Sally
Brian
Thompson NYC
LastName CityId
Henderson NYC
Thompson NYC
2
Sally
Henderson
NYC
relationale
Datenbank
XML als Tabellen
speichern
10
1. XML als String speichern
ƒ hierarchische XML-Struktur als Wert eines
Feldes in einer Tabelle speichern
ƒ XML-Struktur als String serialisieren
Vor- und Nachteile
Anwendung
Tabellen/SQL
+ vorhandenes relationales
Datenbanksystem (RDBMS) kann genutzt
werden
+ triviale Schnittstelle zwischen XML und
RDBMS
relationale
Datenbank
- keine komplexen Anfragen (z.B. mit XPath)
auf XML-Struktur
© K. Schild 2006/M. Mochol 2007
11
2. XML in XML-Datenbank speichern
ƒ Internes Model basiert auf XML
ƒ Übersicht XML-Datenbanken:
www.rpbourret.com/xml/XMLDatabaseProds.htm
Vorteile
+ komplexe Anfragen auf XML-Struktur
möglich
Anwendung
XML/ XPath
+ XPath wird unterstützt
+ Schnell bei einheitlichen Views
XMLDatenbank
© K. Schild 2006/M. Mochol 2007
12
2. XML in XML-Datenbank speichern
Nachteile
- neue Datenbank nötig
- XML-Datenbanken nicht interoperabel
- XML-Datenbanken liefern nur XML zurück
- schwierige Integration mit bestehenden
relationalen Datenbanken (RDB)
- keine Systematik der Datenmodellierung
- Langsam bei Anfragen, die unterschiedliche
Views verlangen
© K. Schild 2006/M. Mochol 2007
13
3. XML als Tabellen speichern
ƒ Abbildung XML ÎTabellen möglich
ƒ Abbildung Tabellen Î XML problemlos
ƒ Anfragen: SQL mit XML-Funktionen (z.B.
SQL/XML)
Vor- und Nachteile
Anwendung
XML
Wrapper
Tabellen/SQL
+ vorhandene RDB kann genutzt werden
+ von modernen RDBMS unterstützt
+ Systematik der Datenmodellierung für
Tabellen
Customers
CustomerNo
FirstName
LastName
CityId
Customers
1
Brian
Thompson
NYC
CustomerNo
FirstName
LastName
CityId
2
Sally
Henderson
NYC
1
Brian
Thompson
NYC
2
Sally
Henderson
NYC
relationale
Datenbank
- Abbildung XML ÎTabellen Î XML liefert
nicht unbedingt ursprüngliche XML-Struktur
© K. Schild 2006/M. Mochol 2007
14
Fazit: Wie XML speichern?
ƒ Sollen Daten oder Dokumente gespeichert werden?
ƒ Wie tief XML-Strukturen in die Datenbank integrieren?
1. XML als einfachen String in Feld einer Tabelle
speichern: gar nicht integrieren
2. XML-Datenbanken: voll integrieren
3. XML als Tabellen speichern: soweit wie möglich
integrieren
ƒ nur zu beantworten, wenn XML mit relationalem
Datenmodell verglichen wird
© K. Schild 2006/M. Mochol 2007
15
Exkurs: Relationales
Modell
© K. Schild 2006/M. Mochol 2007
16
Relationales Modell
Customers
ƒ 1970 von Codd eingeführt
CustomerNo
FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson
NYC
ƒ Daten in Tabellen organisiert
ƒ Tabelle repräsentiert n-stellige Beziehung (Relation)
Relation
zwischen primitiven Daten.
Ö keine geschachtelten Tabellen
ƒ Tabelle besteht aus Spalten (Felder)
Felder und Zeilen (Tupel).
Tupel
ƒ Zeilen und Spalten ungeordnet
ƒ Tabellen haben eindeutige Namen.
© K. Schild 2006/M. Mochol 2007
17
Primär- und Fremdschlüssel
ƒ mindestens eine Spalte einer Tabelle ist Primärschlüssel:
ssel
eindeutiger Repräsentant einer bestimmten Zeile
ƒ bei mehreren Spalten: zusammengesetzter
Primärschlüssel
ƒ Fremdschlüssel:
ssel referenziert Primärschlüssel anderer
Tabelle
Customers
CustomerNo
FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson
NYC
Orders
© K. Schild 2006/M. Mochol 2007
OrderNo
CustomerNo
ItemNo
121
1
FX100
5
1
FX200
18
Eindeutigkeit und Existenz
Customers
CustomerNo
FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson
NYC
Orders
OrderNo
CustomerNo
ItemNo
121
1
FX100
5
1
FX200
ƒ Primärschlüssel
ƒ müssen für jede Zeile einen Wert haben.
ƒ müssen innerhalb der Tabelle eindeutig sein.
ƒ Für jeden Fremdschlüssel muss ein zugehöriger
Primärschlüssel existieren.
© K. Schild 2006/M. Mochol 2007
19
Typen von Beziehungen
Tabellen (Relationen):
Customers
CustomerNo
FirstName
LastName
CityId
1
Brian
Thompson NYC
ƒ Beziehungen zwischen
2
Sally
Henderson NYC
primitiven Daten
ƒ meist Objekte der realen Welt, wie z.B. Kunden oder
Aufträge.
ƒ Zwischen zwei Objekten der realen Welt kann 1:1-,
1:1 1:N1:N
oder N:M-Beziehung
bestehen.
N:M
Wie werden 1:1-, 1:N- und N:M-Beziehungen
im relationalem Modell ausgedrückt?
© K. Schild 2006/M. Mochol 2007
20
1:N-Beziehung
Kunde
1
*
Auftrag
ƒ Bestimmter Kunde kann mehrere Aufträge erteilen.
ƒ Umgekehrt ist aber jedem Auftrag immer genau ein
Kunde zugeordnet.
Ö Zwischen Kunden und Aufträgen besteht eine 1:NBeziehung.
© K. Schild 2006/M. Mochol 2007
21
1:N-Beziehung im relationalen Modell
Primärschlüssel
1
:
N
Customers
CustomerNo FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson NYC
eindeutig
Fremdschlüssel
Orders
OrderNo
CustomerNo
ItemNo
121
1
FX100
5
1
FX200
© K. Schild 2006/M. Mochol 2007
nicht eindeutig
22
1:1-Beziehung
Kunde
1
1
Kunde
(ausführlich)
ƒ 1:1-Beziehungen eher selten
ƒ Beispiel:
ƒ zwei unterschiedliche Kunden-Tabellen
ƒ kompakte Version für Außendienstmitarbeiter
ƒ ausführlichere Version für die interne Verwaltung
ÖZwischen den beiden Tabellen besteht eine 1:1Beziehung.
© K. Schild 2006/M. Mochol 2007
23
1:1-Beziehung im relationalen Modell
Customers
CustomerNo FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson NYC
Customers (detailed)
CustomerNo
LastName FirstName
CityId
CreditCard CreditCardNo
1
Brian
Thompson
NYC
Amex
100900402344
2
Sally
Henderson
NYC
Visa
100800402e33
ƒ beide Schlüssel gleichzeitig Primär- und
Fremdschlüssel
© K. Schild 2006/M. Mochol 2007
24
N:M-Beziehung
Kunde
*
*
Angestellter
ƒ Angestellter kann mehrere Kunden betreuen.
ƒ Umgekehrt kann Kunde gleichzeitig von mehreren
Angestellten betreut werden.
Ö Zwischen Kunden und Angestellten besteht eine N:MBeziehung.
© K. Schild 2006/M. Mochol 2007
25
N:M-Beziehung im relationalen Modell
Kunde
1
*
*
1
Angestellter
ƒ im relationalen Modell N:M-Bezeiehung nicht direkt
darstellbar
ƒ muss in zwei 1:N-Beziehungen aufgebrochen werden
ƒ Dritte Tabelle enthält Fremdschlüssel beider Tabellen.
© K. Schild 2006/M. Mochol 2007
26
N:M-Beziehung im relationalen Modell
Customers
1
CustomerNo FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson NYC
:
N:M-Relationship
N
N
:
Key
CustomerNo
EmployeeNo
121
1
4
5
1
5
Employees
1
EmployeeNo FirstName LastName CityId
Type
4
Mark
Whitehorn
NYC
Sales person
5
Bill
Marklyn
NYC
Human Resources
© K. Schild 2006/M. Mochol 2007
27
Alternative Darstellung
Customers
1
CustomerNo FirstName
LastName
CityId
1
Brian
Thompson
NYC
2
Sally
Henderson NYC
:
N:M-Relationship
N
N
:
CustomerNo
EmployeeNo
1
4
1
5
Employees
1
EmployeeNo FirstName LastName CityId
Type
4
Mark
Whitehorn
NYC
Sales person
5
Bill
Marklyn
NYC
Human Resources
© K. Schild 2006/M. Mochol 2007
28
Normalformen
ƒ Hilfsmittel zur Modellierung von Daten
ƒ für relationales Modell formal definiert
Ziel
ƒ Eigenschaften (Felder) zu passenden Objekten
(Tabellen) gruppieren
ƒ redundante Informationen eliminieren
ƒ sicherstellen, dass jede Information eindeutig
identifiziert werden kann
Mittel
ƒ Verständnis der Bedeutung der Daten
ƒ Verständnis funktionaler Abhängigkeiten
© K. Schild 2006/M. Mochol 2007
29
Funktionale Abhängigkeiten
ƒ Beispiel: Fläche = Höhe X Breite
ƒ Fläche funktional abhängig von der Höhe und Breite:
ƒ Fläche = f(Höhe, Breite), für eine Funktion f
ƒ es gibt auch funktionale Abhängigkeiten zwischen
Feldern einer Tabelle
© K. Schild 2006/M. Mochol 2007
30
Beispiel
Orders
OrderNo ItemNo
EmployeeNo CustomerNo
ItemName
Quantity
121
3
4
1024
Nut
3
121
4
4
1024
Bolt
67
122
3
9
176
Nut
9
ƒ Annahme: jedem Auftrag genau ein Angestellter
(Vermittler) zugeordnet
Ö EmployeeNo = f(OrderNo)
Ö EmployeeNo funktional abhängig von OrderNo.
Wichtig: Funktionale Abhängigkeiten nicht an Daten
selbst zu erkennen, sondern an ihrer Verwendung.
© K. Schild 2006/M. Mochol 2007
31
Weitere funktionale Abhängigkeiten
Orders
OrderNo ItemNo
EmployeeNo CustomerNo
ItemName
Quantity
121
3
4
1024
Nut
3
121
4
4
1024
Bolt
67
122
3
9
176
Nut
9
ƒ Quantity = f1(OrderNo, ItemNo)
ƒ ItemName = f2(ItemNo)
ƒ CustomerNo = f3(OrderNo)
© K. Schild 2006/M. Mochol 2007
32
Normalformen
ƒ verschiedene Stufen, die aufeinander aufbauen:
1., 2., 3. Normalform (Ö Anhang)
Grundidee
ƒ Unterscheidung funktionaler Abhängigkeiten in
notwendige und nicht erlaubte
ƒ Sei P der Primärschlüssel einer Tabelle.
ƒ Seien Fi ein beliebiges Nicht-Schlüssel-Feld der Tabelle.
notwendig:
nicht erlaubt:
ƒ Fi = f(P)
ƒ Fi = f(P'), P' echte Teilmenge von P
ƒ Fi = f(P), jedoch Fi = f(Fj), Fj = f(P) für
ein weiteres Nicht-Schlüssel-Feld Fj
© K. Schild 2006/M. Mochol 2007
33
Beispiel
Orders
OrderNo ItemNo
EmployeeNo CustomerNo
ItemName Quantity
121
3
4
1024
Nut
3
121
4
4
1024
Bolt
67
122
3
9
176
Nut
9
notwendig
ƒ Fi = f(OrderNo,ItemNo), Fi = EmployeeNo,…,Quantity
nicht erlaubt
ƒ ItemName = f(ItemNo)
ƒ CustomerNo = f(OrderNo)
ƒ EmployeeNo = f(OrderNo)
© K. Schild 2006/M. Mochol 2007
34
Weiteres Beispiel
Customers
CustomerNo
FirstName LastName
CityId
City
1
Brian
Thompson
NYC
New York City
2
Sally
Henderson
NYC
New York City
notwendig
ƒ Fi = f(CustomerNo), Fi = FirstName,…,CityId, City
nicht erlaubt
ƒ City = f(CityId)
© K. Schild 2006/M. Mochol 2007
35
Abbildung
relationales Modell Î
XML
© K. Schild 2006/M. Mochol 2007
36
Relationales Modell Î XML
Relationales Modell kann einfach und ohne
Informationsverlust in XML kodiert werden.
werden
Ö Kodierung könnte als Standard für RDBMS dienen.
ƒ Hierfür gibt es allerdings keinen etablierten Standard.
ƒ inoffizieller Vorschlag: http://www.w3.org/XML/RDB.html
Ö XML mindestens so ausdrucksstark wie relationales
Modell
© K. Schild 2006/M. Mochol 2007
37
Mapping-Verfahren
Geeignete Abbildungen und Transformationsmechanismen
zwischen beiden ”Informationsträgern“ finden
Mapping-Verfahren
ƒ Template-driven Mapping: Datenbankinhalte Æ XML
ƒ Model-driven Mapping: Datenbank Æ XML &
XMLÆ Datenbank
© K. Schild 2006/M. Mochol 2007
38
Template-driven Mapping
<?xml version="1.0"?>
<FlightInfo>
<Intro>
the following flights have available seats:
</Intro>
<SelectStmt>
SELECT Airline, FltNumber, Depart, Arrive
FROM Flights
</SelectStmt>
</FlightInfo>
© K. Schild 2006/M. Mochol 2007
ƒ keine fest definierte
Abbildung
ƒ Verwendung von
XML-Dokumenten,
die als Templates
dienen
ƒ Einbettung von
Anweisungen (z.B.
SELECTStatements)
39
Template-driven Mapping – Beispiel
<?xml version="1.0"?>
<FlightInfo>
<Intro>
the following flights have available seats:
</Intro>
<SelectStmt>
SELECT Airline, FltNumber, Depart, Arrive
FROM Flights
<?xml version="1.0"?>
</SelectStmt>
<FlightInfo>
</FlightInfo>
<Intro>
XML-Template mit
Select-Anweisung
Ergebnis
© K. Schild 2006/M. Mochol 2007
the following flights have available seats:
</Intro>
<Flights>
<Row>
<Airline>ACME</Airline>
<FltNumber>123</FltNumber>
<Depart>Dec 12, 2001 13:43</Depart>
<Arrive>Dec 13, 2001 01:21</Arrive>
</Row>
...
</Flights>
</FlightInfo>
40
Model-driven Mapping
ƒ Mapping: Datenbank Æ XML & XMLÆ Datenbank
ƒ festes Model
ƒ Table Model
ƒ wenig flexibel aber intuitive Abbildung
ƒ nur für sehr flache XML-Dokumente
ƒ Einsatzbereich beschränkt auf relationale Strukturen
ƒ Data Specific Object Model
ƒ Modellierung der Daten
ƒ Abbildung: Daten Ækorrespondierende Objekte Æ
hierarchische Baumstruktur
© K. Schild 2006/M. Mochol 2007
41
Table Model
<database>
<table>
<row>
<column1>...</column1>
<column2>...</column2>
<column3>...</column3>
...
</row>
...
</table>
<table>
...
</table>
</database>
© K. Schild 2006/M. Mochol 2007
Vorteile
+ einfach
+ leicht zu implementieren
+ schneller und effizienter
Datenaustausch
Nachteil
- nicht anwendbar bei
komplexeren Datenmodellen
und tiefer verschachtelten
XML-Dokumenten
42
Data Specific Object Model
<Orders>
Daten-spezifischer Objektbaum
<SalesOrder SONumber="12345">
Orders
<Customer CustNumber="543">
...
</Customer>
SalesOrder
<OrderDate>150999</OrderDate>
<Line LineNumber="1">
<Product Name="Cherries">
Customer
Line
...
</Product>
<Quantity Unit="ton">2</Quantity>
Product
</Line>
</SalesOrder>
</Orders>
object SalesOrder {
soNumber = "12345";
customer = { custPtr};
abgeleitete Objekte
line = { linePtr};
orderDate = "150999";
object Line {
}
lineNumber = "1";
product = { prodPtr};
quantity = { quantPtr};
© K. Schild 2006/M. Mochol 2007
43
}
Quelle: http://www-is.informatik.uni-oldenburg.de/~grawund/Lehre/Seminare/WWD_2000_2001/Texte/DB_und_XML.pdf
Abbildung
relationales Modell Î
XML
Type Model
© K. Schild 2006/M. Mochol 2007
44
Kodierung einer RDB in XML
<Database>
<database>
ƒ Wurzel-Element =
<EmployeeTable>
<table>
Name der
<EmployeeTuple>
<row>
<EmployeeNo>k1</EmployeeNo>
<column1>...</column1>
Datenbank
<FirstName>Mark</FirstName>
<column2>...</column2>
für jede Tabelle
<LastName>Whitehorn</LastName> ƒ <column3>...</column3>
...
<CityId>NYC</CityId>
genau
ein Kind</row>
<Type>Sales Person</Type>
Element
...
</EmployeeTuple>
</table>
<EmployeeTuple>
ƒ darunter für jedes
<table>
<EmployeeNo>k2</EmployeeNo>
Tupel genau ein
...
<FirstName>Bill</FirstName>
Kind-Element
</table>
<LastName>Marklyn</LastName>
</database>
<CityId>NYC</CityId>
ƒ darunter für jede
<Type>Human Resources</Type>
Spalte ein Kind</EmployeeTuple>
Element
</EmployeeTable>
...
© K. Schild 2006/M. Mochol 2007
45
Kodierung von Null Values
<Database>
<EmployeeTable>
<EmployeeTuple>
<EmployeeNo>k1</EmployeeNo>
<FirstName>Mark</FirstName>
<LastName>Whitehorn</LastName>
<CityId>NYC</CityId>
<Type>Sales Person</Type>
</EmployeeTuple>
<EmployeeTuple>
<EmployeeNo>k2</EmployeeNo>
<FirstName>Bill</FirstName>
<LastName>Marklyn</LastName>
ƒ Leerwerte (null
values):
values undefinierte
Werte
ƒ Kodierung:
entsprechendes
Element (= Feld)
einfach weglassen
ƒ dadurch
Unterscheidung zu
leerem Inhalt
<Type></Type>
</EmployeeTuple>
</EmployeeTable>
…
© K. Schild 2006/M. Mochol 2007
46
Das zugehörige XML-Schema
xsd:sequence
xsd:all
xsd:all
minOccurs="0"
ƒ Reihenfolge der Tabellen, Tupel und Spalten egal
© K. Schild 2006/M. Mochol 2007
47
Kodierung von Schlüssel
ƒ Primärschlüssel: Typ xsd:ID.
ƒ Fremdschlüssel: Typ xsd:IDREF.
Probleme dieser Kodierung
ƒ keine zusammengesetzten Primärschlüssel darstellbar
ƒ Statt Eindeutigkeit innerhalb der Tabelle, erzwingt xsd:ID
Eindeutigkeit aller Attribute mit Typ xsd:ID
ÖZwei Tabellen dürfen keine identischen Primärschlüssel
haben.
ƒ Statt eines ganz bestimmten Primärschlüssels,
referenziert xsd:IDREF beliebigen Primärschlüssel mit
Typ xsd:ID.
© K. Schild 2006/M. Mochol 2007
48
Beispiel
<Database>
<EmployeeTable>
<EmployeeTuple>
<EmployeeNo>ID4</EmployeeNo>
<FirstName>String</FirstName>
<LastName>String</LastName>
<CityId>ID5</CityId>
<Type>String</Type>
</EmployeeTuple>
</EmployeeTable>
<CustomerTable>
<CustomerTuple>
<CustomerNo>ID5</CustomerNo>
…
</CustomerTuple>
</CustomerTable>
</Database>
© K. Schild 2006/M. Mochol 2007
ƒ Primärschlüssel
müssen in gesamter
Datenbank (nicht
nur in Tabelle)
eindeutig sein.
ƒ Fremdschlüssel kann
sich auf beliebigen
Primärschlüssel
beziehen
49
Primärschlüssel als key
<xsd:element name="Database">
<xsd:complexType>
Definition der Tabellen
</xsd:complexType>
<xsd:key name="EmployeeKey">
<xsd:selector xpath="EmployeeTable/EmployeeTuple"/>
<xsd:field xpath="EmployeeNo"/>
</xsd:key>
Ö EmployeeNo innerhalb
</xsd:element>
EmployeeTable eindeutig
ƒ name:
name eindeutiger Namen des Primärschlüssels
ƒ xsd:selector:
xsd:selector spezifiziert Kontext, auf die die
Eindeutigkeitsbedingung angewandt wird.
ƒ ein oder mehrere xsd:field-Elemente:
Elemente/Attribute,
xsd:field
die zusammen eindeutig sind
© K. Schild 2006/M. Mochol 2007
50
Fremdschlüssel als keyref
<xsd:element name="Database">
<xsd:complexType>
Definition der Tabellen
</xsd:complexType>
<xsd:keyref name="CityIDKeyRef" refer="CityIDKey">
<xsd:selector xpath="*/*"/>
<xsd:field xpath="CityID"/>
</xsd:keyref>
</xsd:element>
Ö Wert von CityId
immer definiert
ƒ refer:
refer Auf welchen Primärschlüssel wird verwiesen?
ƒ xsd:selector:
xsd:selector Wo ist der Fremdschlüssel zu finden?
ƒ xsd:field:
xsd:field Aus welchen Feldern besteht der
Fremdschlüssel?
© K. Schild 2006/M. Mochol 2007
51
Fazit: Relationales Modell Î XML
ƒ einfach und ohne Informationsverlust möglich
ƒ gilt auch für Primär- und Fremdschlüssel
ƒ XML mindestens so ausdrucksstark wie relationales
Modell
ƒ XML-Dokument (Instanz) kodiert Datenbank
ƒ XML-Schema kodiert Datenbankschema
© K. Schild 2006/M. Mochol 2007
52
Datenmodellierung
mit XML
© K. Schild 2006/M. Mochol 2007
53
XML zur Datenmodellierung
ƒ XML flexibler als relationales Model:
Relationales Modell
ƒ keine geschachtelten Tabellen
ƒ N:M-Beziehungen müssen in eigenen Tabellen
ausgelagert werden.
XML
ƒ erlaubt geschachtelte Strukturen
ƒ N:M-Beziehungen können unkompliziert ausgedrückt
werden.
Warum also die Möglichkeiten von
XML nicht voll ausnutzen?
© K. Schild 2006/M. Mochol 2007
54
Beispiel
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<City>
<Name>New York City</Name>
<CityId>NYC</CityId>
</City>
<Type>Sales Person</Type>
<Orders>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>…</OrderIntems>
<CustomerNo>999</CustomerNo>
</Order>
</Orders>
</Employee>
© K. Schild 2006/M. Mochol 2007
ƒ Könnte so zwischen Vertriebsund Gehaltsabteilung
ausgetauscht werden
ƒ als Austauschformat OK
ƒ auch als Speicherformat OK?
55
Löschanomalie
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<City>
<Name>New York City</Name>
<CityId>NYC</CityId>
</City>
<Type>Sales Person</Type>
<Orders>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>…</OrderIntems>
<CustomerNo>999</CustomerNo>
</Order>
</Orders>
</Employee>
© K. Schild 2006/M. Mochol 2007
ƒ Wird ein AngestelltenDatensatz gelöscht, dann
werden auch alle Aufträge
gelöscht, die er vermittelt hat.
ƒ Gefahr, ungewollt
Informationen zu löschen
Ö Order-Informationen
auslagern und durch
Fremdschlüssel OrderNo
ersetzen.
56
Verbesserte Modellierung
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<City>
<Name>New York City</Name>
<CityId>NYC</CityId>
</City>
<Type>Sales Person</Type>
<Orders>
<OrderNo>121</OrderNo>
</Orders>
</Employee>
© K. Schild 2006/M. Mochol 2007
<Order-DB>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>…</OrderItems>
<CustomerNo>999</CustomerNo>
</Order>
</Order-DB>
57
Änderungsanomalie
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<City>
<Name>New York City</Name>
<CityId>NYC</CityId>
</City>
<Type>Sales Person</Type>
<Orders>
<OrderNo>121</OrderNo>
</Orders>
</Employee>
© K. Schild 2006/M. Mochol 2007
ƒ Wird CityId oder Name
geändert, dann muss diese
Änderung in allen
Angestellten-Datensätzen
nachvollzogen werden.
ƒ unnötiger
Verwaltungsaufwand
ƒ Gefahr von Inkonsistenzen
Ö City-Informationen
auslagern und hier durch
Fremdschlüssel ersetzen.
58
Verbesserte Modellierung
<Employee-DB>
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<CityKey>C123</CityKey>
<Type>Sales Person</Type>
<Orders>
<OrderNo>121</OrderNo>
</Orders>
</Employee>
</Employee-DB>
© K. Schild 2006/M. Mochol 2007
<Order-DB>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>…</OrderItems>
<CustomerNo>999</CustomerNo>
</Order>
</Order-DB>
<City-DB>
<City>
<CityKey>C123</CityKey>
<CityId>NYC</CityId>
<Name>New York City</Name>
</City>
</City-DB>
59
Noch eine Änderungsanomalie
<Order-DB>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>
<OrderItem>
<ItemNo>FX100</ItemNo>
<ItemName>Black-Bag</ItemName>
<Quantity>1000</Quantity>
</OrderItem>
</OrderItems>
<CustomerNo>999</CustomerNo>
</Order>
</Order-DB>
© K. Schild 2006/M. Mochol 2007
ƒ Wird ItemName
geändert, dann muss
diese Änderung in allen
Order-Datensätzen
nachvollzogen werden.
Ö Zuordnung
ItemNo/ItemName
auslagern und hier
durch Fremdschlüssel
ItemNo ersetzen.
60
Verbesserte Modellierung
<Order-DB>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>
<OrderItem>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
</OrderItem>
</OrderItems>
<CustomerNo>999</CustomerNo>
</Order>
</Order-DB>
© K. Schild 2006/M. Mochol 2007
<Inventory-DB>
<Item>
<ItemNo>FX100</ItemNo>
<ItemName>Black-Bag</ItemName>
</Item>
</Inventory-DB>
61
Anfrageoptimierung
<Order-DB>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>
<OrderItem>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
</OrderItem>
</OrderItems>
<CustomerNo>999</CustomerNo>
</Order>
</Order-DB>
ƒ Hier fehlt Verweis auf
Vermittler (EmployeeNo).
ƒ Vermittler normalerweise
Ansprechpartner für
Kundenauftrag
Wer ist Vermittler?
Ö Angestellten-Datenbank muss durchsucht
werden, um Vermittler zu ermitteln.
© K. Schild 2006/M. Mochol 2007
62
Anfrageoptimierung
<Order-DB>
<Order>
<OrderNo>121</OrderNo>
<OrderItems>
<OrderItem>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
</OrderItem>
</OrderItems>
<CustomerNo>999</CustomerNo>
</Order>
<EmployeeNo>4</EmployeeNo>
</Order>
</Order-DB>
</Order-DB>
© K. Schild 2006/M. Mochol 2007
<Employee-DB>
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<CityKey>C123</CityKey>
<Type>Sales Person</Type>
<Orders>
<OrderNo>121</OrderNo>
</Orders>
</Employee>
</Employee-DB>
statt Verweis Angestellter Î Auftrag
Verweis Auftrag Î Vermittler
63
Endgültige Modellierung
<Order>
<OrderNo>121</OrderNo>
<OrderItems>
<OrderItem>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
</OrderItem>
</OrderItems>
<CustomerNo>999</CustomerNo>
<EmployeeNo>4</EmployeeNo>
</Order>
<Item>
<ItemNo>FX100</ItemNo>
<ItemName>Black-Bag</ItemName>
</Item>
© K. Schild 2006/M. Mochol 2007
<Employee>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<CityKey>C123</CityKey>
<Type>Sales Person</Type>
</Employee>
<City>
<CityKey>C123</CityKey>
<CityId>NYC</CityId>
<Name>New York City</Name>
</City>
64
Vergleich mit relationalem Modell
<OrderTuple>
<OrderNo>121</OrderNo>
<OrderItemTable>
<OrderItemTuple>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
</OrderItemTuple>
</OrderItemTable>
<CustomerNo>999</CustomerNo>
<EmployeeNo>4</EmployeeNo>
</OrderTuple>
<ItemTuple>
<ItemNo>FX100</ItemNo>
<ItemName>Black-Bag</ItemName>
</ItemTuple>
9
© K. Schild 2006/M. Mochol 2007
<EmployeeTuple>
<EmployeeNo>4</EmployeeNo>
<Name>
<First>Mark</First>
<Last>Whitehorn</Last>
</Name>
<CityKey>NYC</CityKey>
<Type>Sales Person</Type>
</EmployeeTuple>
<CityTuple>
<CityKey>C123</CityKey>
<CityId>NYC</CityId>
<Name>New York City</Name>
</CityTuple>
9
65
Vergleich mit relationalem Modell
<OrderTuple>
<OrderNo>121</OrderNo>
<OrderItemTable>
N:M
<OrderItemTuple>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
</OrderItemTuple>
</OrderItemTable>
<CustomerNo>999</CustomerNo>
<EmployeeNo>4</EmployeeNo>
</OrderTuple>
<ItemTuple>
<ItemNo>FX100</ItemNo>
<ItemName>BlackBag</ItemName>
</ItemTuple>
© K. Schild 2006/M. Mochol 2007
9
<EmployeeTuple>
<EmployeeNo>4</EmployeeNo>
<FirstName>Mark</FirstName>
<LastName>Whitehorn</LastName>
<CityKey>C123</CityKey>
<Type>Sales Person</Type>
</EmployeeTuple>
9
<CityTuple>
<CityKey>C123</CityKey>
<CityId>NYC</CityId>
<Name>New York City</Name>
</CityTuple>
9
N:M-Beziehung zwischen
OrderNo und ItemNo als
Hierarchie
66
Relationale Modellierung
<OrderSpecTuple>
<OrderNo>121</OrderNo>
<ItemNo>FX100</ItemNo>
<Quantity>1000</Quantity>
9
</OrderSpecTuple>
<OrderTuple>
<OrderNo>121</OrderNo>
<CustomerNo>999</CustomerNo>
<EmployeeNo>4</EmployeeNo>
</OrderTuple>
9
<ItemTuple>
<ItemNo>FX100</ItemNo>
<ItemName>Black-Bag</ItemName>
</ItemTuple>
9
© K. Schild 2006/M. Mochol 2007
<EmployeeTuple>
<EmployeeNo>4</EmployeeNo
>
<First>Mark</First>
<Last>Whitehorn</Last>
<CityKey>C123</CityKey>
<Type>Sales Person</Type>
9
</EmployeeTuple>
<CityTuple>
<CityKey>C123</CityKey>
<CityId>NYC</CityId>
<Name>New York City</Name>
9
</CityTuple>
N:M-Beziehung als Relation
OrderSpec mit
zusammengesetztem
Primärschlüssel
67
Fazit aus dem Beispiel
Ausgangspunkt
ƒ strukturiertes XML-Dokument als Speicherformat
Transformationen
ƒ Beseitigung von Lösch- und Änderungsanomalien
Ergebnis
ƒ mehrere, wesentlich flachere XML-Strukturen
ƒ relationalem Modell (in 3. NF) sehr ähnlich
ƒ Ausnahme: N:M-Beziehungen als geschachtelte
Strukturen
© K. Schild 2006/M. Mochol 2007
68
Systematik der Datenmodellierung
relationales Modell
ƒ schrittweise Normalformbildung: Ergebnis formal
definiert
XML
ƒ Normalformen aus relationalem Modell nicht auf XML
übertragbar
ƒ Grund: relationales Model erlaubt keine geschachtelten
Tabellen
ƒ bisher keine Systematik der Datenmodellierung
ƒ informelles Verfahren:
Asset-Oriented Modeling (Daum & Merten, System
Architecture with XML, 2003).
© K. Schild 2006/M. Mochol 2007
69
Fazit aus heutiger Vorlesung
Daten mit vielen funktionalen Abhängigkeiten
ƒ bewährte Speicherformate wie relationale Datenbanken
besser
ƒ Tabellen als XML serialisieren
Text-Dokumente mit nur wenigen funktionalen
Abhängigkeiten
ƒ XML auch als Speicherformat geeignet
© K. Schild 2006/M. Mochol 2007
70
Wie geht es weiter?
heutige Vorlesung
; Daten vs. Dokumente
; Wie XML persistent speichern?
; Vergleich XML mit relationalem Modell
www.rpbourret.com/xml/XMLAndDatabases.htm
; Wie Daten mit XML modellieren?
nächste Übung
ƒ XML und Datenbanken
Vorlesung nächste Woche
ƒ Web Services (insgesamt 4 Termine)
© K. Schild 2006/M. Mochol 2007
71
Anhang
© K. Schild 2006/M. Mochol 2007
72
1. Normalform (NF)
ƒ Eine relationale Datenbank ist in 1. Normalform,
Normalform falls
alle Tabellen
1) einen Primärschlüssel haben und
2) nur primitive Daten enthalten.
ƒ Entspricht der Definition des relationalen Modells
© K. Schild 2006/M. Mochol 2007
73
2. Normalform (NF)
ƒ Eine relationale Datenbank ist in 2. Normalform,
Normalform falls
1) sie in 1. Normalform ist,
2) alle Nicht-Schlüssel-Felder vom Primärschlüssel
funktional abhängig sind und
3) kein Nicht-Schlüssel-Feld bereits von einem Teil des
Primärschlüssels funktional abhängig ist.
nicht in 2. NF
Orders
OrderNo ItemNo
EmployeeNo CustomerNo
ItemName
Quantity
121
3
4
1024
Nut
3
121
4
4
1024
Bolt
67
122
3
9
176
Nut
9
© K. Schild 2006/M. Mochol 2007
74
3. Normalform (NF)
ƒ Eine relationale Datenbank ist in 3. Normalform,
Normalform falls
1) sie in 2. Normalform ist und
2) alle Nicht-Schlüssel-Felder direkt (d.h. nicht transitiv)
vom Primärschlüssel funktional abhängig sind.
nicht in 3. NF
Customers
CustomerNo
FirstName LastName
CityId
City
1
Brian
Thompson
NYC
New York City
2
Sally
Henderson
NYC
New York City
© K. Schild 2006/M. Mochol 2007
75