Heutige Vorlesung Heutige Vorlesung

(1)

XML und XML und

Datenbanken

(2)

Heutige Vorlesung Heutige Vorlesung

letzte Woche letzte Woche

;; Warum XMLWarum XML--DokumenteDokumente transformieren?transformieren?

;; XML-XML-DokumenteDokumente mit XSLT transformierenmit XSLT transformieren

;; XSLXSL--FO zur Erzeugung von druckfäFO zur Erzeugung von druckfähigem Layouthigem Layout heutige Vorlesung

heutige Vorlesung

XML und Datenbanken

(3)

Ü Ü bersicht bersicht

Daten vs. Dokumente

Wie XML persistent speichern?

Vergleich XML mit relationalem ModellVergleich XML mit relationalem Modell

Exkurs: relationales Modell

- Darstellung von N:M-Beziehungen

- funktionale Abhängigkeiten, Normalformen

Wie Daten mit XML modellieren?

(4)

Daten & Dokumente

(5)

Daten vs. Dokumente Daten vs. Dokumente

Auswahl der Datenbank hängt von den zu speichernden

„Objekt“

Daten- vs. Dokumentspezifische Dokumente (datadata--centric vs. documentcentric document--centric documents)centric documents

(6)

Datenspezifische Dokumente Datenspezifische Dokumente

regulreguläärere Struktur (hoher Strukturierungsgrad)

feinkfeinköörnigernige Daten

wenigwenig bzw. keine gemischtekeine gemischte Inhalte

leichte Verarbeitung für MaschinenMaschinen

Beispiele: Kataloge, Verkaufsaufträge, Flugpläne, etc.

ÖÖtraditionelle Datenbanken (relationale, objekt-orientierte)traditionelle Datenbanken ÖÖXML-XML-fäfähigehige Datenbanken (XML-enabled databases)Datenbanken

(7)

Dokumentspezifische Dokumente Dokumentspezifische Dokumente

weniger reguläre Struktur /irregulirreguläärere Struktur

grobkgrobköörnigernige Daten

viele gemischteviele gemischte Inhalte

Dokument als Ganzes von Bedeutung

entwickelt für MenschenMenschen

Beispiele: Bücher, E-Mails, Werbung, etc.

ÖÖCMSCMS

ÖÖXML Datenbanken (nativ XML databases)XML Datenbanken

(8)

Wie XML

Wie XML persistent persistent speichern?

speichern?

(9)

2 1

2

3 1

3

1 1

1

AuthorKey BookKey

Key

Authorship

2 1

2

3 1

3

1 1

1

AuthorKey BookKey

Key

Authorship

XML vs. relationale Datenbanken XML vs. relationale Datenbanken

book

title

edition

2nd

authors

Beginning XML

book

title

edition

2nd

authors

Beginning XML

David Hunter Curt Cagle Chris Dix

author author author

David Hunter Curt Cagle Chris Dix

author author author

Hunter David

1

Dix Chris

3

Cagle Kurt

2

LastName FirstName

AuthorKey Author

Hunter David

1

Dix Chris

3

Cagle Kurt

2

AuthorKey Author

XMLXML

Hierarchie (Baum)

Kind-Elemente:

Reihenfolge relevant

relationale Datenbanken relationale Datenbanken

Tabellen mit Schlüssel

Spalten und Zeilen:

Reihenfolge egal

2nd Beginning XML 1

Edition Title

BookKey Book

2nd Beginning XML 1

Edition Title

BookKey Book

(10)

Wie XML

Wie XML persistent persistent speichern? speichern?

Anwendung

relationale Datenbank

Tabellen/SQL

Anwendung

XML- Datenbank

XML/XPath

Wrapper

Tabellen/SQL Anwendung

XML

XML als

einfachen String speichern

XML als strukturiertes XML-Dokument

speichern

XML als Tabellen speichern

NYC Henderson Sally 2

NYC Thompson Brian 1

CityId LastName FirstName CustomerNo Customers

(11)

1. XML als String speichern 1. XML als String speichern

hierarchische XML-Struktur als Wert eines Feldes in einer Tabelle speichern

XML-Struktur als String serialisieren VorVor-- und Nachteileund Nachteile

+ vorhandenes relationales

Datenbanksystem (RDBMS) kann genutzt werden

+ triviale Schnittstelle zwischen XML und RDBMS

- keine komplexen Anfragen (z.B. mit XPath)

Anwendung

Tabellen/SQL

(12)

2. XML in

2. XML in XML XML - - Datenbank Datenbank speichern speichern

Internes Model basiert auf XML

Übersicht XML-Datenbanken:

www.rpbourret.com/xml/XMLDatabaseProds.htm

Vorteile Vorteile

+ komplexe Anfragen auf XML-Struktur möglich

+ XPath wird unterstützt

+ Schnell bei einheitlichen Views

Anwendung

XML- Datenbank

XML/ XPath

(13)

2. XML in

2. XML in XML XML - - Datenbank Datenbank speichern speichern

Nachteile 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

(14)

3. XML als Tabellen speichern 3. XML als Tabellen speichern

Abbildung XML ÎTabellen möglich

Abbildung Tabellen Î XML problemlos

Anfragen: SQL mit XML-Funktionen (z.B.

SQL/XML)

VorVor-- und Nachteileund Nachteile

+ vorhandene RDB kann genutzt werden + von modernen RDBMS unterstützt

+ Systematik der Datenmodellierung für Tabellen

- Abbildung XML ÎTabellen Î XML liefert nicht unbedingt ursprüngliche XML-Struktur

Wrapper

Tabellen/SQL

Anwendung

XML

(15)

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 integrierengar nicht integrieren

2. XML-Datenbanken: voll integrierenvoll integrieren

3. XML als Tabellen speichern: soweit wie msoweit wie mööglich glich integrieren

integrieren

nur zu beantworten, wenn XML mit relationalem Datenmodell verglichen wird

(16)

Exkurs: Relationales Exkurs: Relationales

Modell

(17)

Relationales Modell Relationales Modell

NYC Henderson

Sally 2

NYC Thompson

Brian 1

CityId LastName

FirstName CustomerNo

Customers

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

1970 von Codd eingeführt

Daten in TabellenTabellen organisiert

Tabelle repräsentiert n-stellige Beziehung (RelationRelation) zwischen primitivenprimitiven Daten.

Ö keine geschachtelten Tabellen

Tabelle besteht aus Spalten (FelderFelder) und Zeilen (TupelTupel).

Zeilen und Spalten ungeordnet

Tabellen haben eindeutige Namen.

(18)

Primä Prim ä r r - - und Fremdschlü und Fremdschl ü ssel ssel

mindestens eine Spalte einer Tabelle ist PrimäPrimärschlrschlüsselüssel:

eindeutiger Repräsentant einer bestimmten Zeile

bei mehreren Spalten: zusammengesetzter zusammengesetzter PrimPrimäärschlrschlüsselüssel

FremdschlFremdschlüüssel: referenziert Primärschlüssel anderer ssel Tabelle

FX200 1

5

FX100 1

121

ItemNo CustomerNo

OrderNo Orders

FX200 1

5

FX100 1

121

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

(19)

Eindeutigkeit und Existenz Eindeutigkeit und Existenz

PrimäPrimärschlrschlüüsselssel

müssen für jede Zeile einen Wert haben.

müssen innerhalb der Tabelle eindeutig sein.

Für jeden FremdschlFremdschlüüssel muss ein zugehöriger ssel Primärschlüssel existieren.

FX200 1

5

FX100 1

121

FX200 1

5

FX100 1

121

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

(20)

Typen von Beziehungen Typen von Beziehungen

NYC Henderson Sally

2

NYC Thompson

Brian 1

Customers

NYC Henderson Sally

2

NYC Thompson

Brian 1

Customers

Tabellen (Relationen):

Beziehungen zwischen primitiven Daten

Wie werden 1:1-, 1:N- und N:M-Beziehungen im relationalem Modell ausgedrückt?

meist Objekte der realen Welt, wie z.B. Kunden oder Aufträge.

Zwischen zwei Objekten der realen Welt kann 1:1-, 1:1 1:N-1:N oder N:MN:M-Beziehung bestehen.

(21)

1:N 1:N -Beziehung - Beziehung

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:N- Beziehung.

Auftrag

1 *

Kunde

(22)

1:N 1:N -Beziehung im relationalen Modell - Beziehung im relationalen Modell

Orders

OrderNo CustomerNo ItemNo

121 1 FX100

5 1 FX200

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

11

:: NN

Fremdschl

Fremdschlüsselüssel PrimäPrimärschlrschlüüsselssel

eindeutig

nicht eindeutig

(23)

1:1- 1:1 - Beziehung Beziehung

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:1- Kunde

(ausführlich)

1 1

Kunde

(24)

1:1- 1:1 - Beziehung im relationalen Modell Beziehung im relationalen Modell

Customers (detailed)

CustomerNo LastName FirstName CityId CreditCard CreditCardNo

Amex 100900402344

100800402e33 Visa

NYC NYC

1 Brian Thompson

2 Sally Henderson

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

beide Schlüssel gleichzeitig Primär- und Fremdschlüssel

(25)

N:M- N:M - Beziehung Beziehung

Angestellter kann mehrere Kunden betreuen.

Umgekehrt kann Kunde gleichzeitig von mehreren Angestellten betreut werden.

Ö Zwischen Kunden und Angestellten besteht eine N:M- Beziehung.

Angestellter

* *

Kunde

(26)

N:M- N:M - Beziehung Beziehung im relationalen Modell im relationalen Modell

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.

1 * * 1

Angestellter Kunde

(27)

N:M- N:M - Beziehung Beziehung im relationalen Modell im relationalen Modell

N:M-Relationship

Key CustomerNo EmployeeNo

121 1 4

5 1 5

NYC Henderson

Sally 2

NYC Thompson

Brian 1

Customers

Sales person Type

NYC CityId Whitehorn

Mark 4

EmployeeNo Employees

11

:: NN ::

11 NN

(28)

Alternative Darstellung Alternative Darstellung

N:M-Relationship

CustomerNo EmployeeNo

1 4

1 5

Customers

CustomerNo FirstName LastName CityId

1 Brian Thompson NYC

2 Sally Henderson NYC

Human Resources Sales person

Type NYC

NYC CityId Marklyn

Bill 5

Whitehorn Mark

4

EmployeeNo Employees

11

:: NN ::

11 NN

(29)

Normalformen Normalformen

Hilfsmittel zur Modellierung von Daten

für relationales Modell formal definiert ZielZiel

Eigenschaften (Felder) zu passenden Objekten (Tabellen) gruppieren

redundante Informationen eliminieren

sicherstellen, dass jede Information eindeutig identifiziert werden kann

Mittel Mittel

Verständnis der Bedeutung der Daten

Verständnis funktionaler Abhfunktionaler Abhäängigkeitenngigkeiten

(30)

Funktionale Abh

Funktionale Abh ä ä ngigkeiten ngigkeiten

Beispiel: Fläche = Höhe ^X Breite

Fläche funktional abhfunktional abhäängigngig 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

(31)

Beispiel Beispiel

Orders

OrderNo ItemNo EmployeeNo CustomerNo ItemName Quantity

Nut 3

67

122 3 9 176 Nut 9

Bolt

121 3 4 1024

121 4 4 1024

Annahme: jedem Auftrag genau ein Angestellter (Vermittler) zugeordnet

Ö EmployeeNo = f(OrderNo)

Ö EmployeeNo funktional abhfunktional abhäängigngig von OrderNo.

Wichtig: Funktionale Abhängigkeiten nicht an Daten

(32)

Weitere funktionale Abh

Weitere funktionale Abhä ä ngigkeiten ngigkeiten

Orders

OrderNo ItemNo EmployeeNo CustomerNo ItemName Quantity

Nut 3

67

122 3 9 176 Nut 9

Bolt

121 3 4 1024

121 4 4 1024

Quantity = f₁(OrderNo, ItemNo)

ItemName = f₂(ItemNo)

CustomerNo = f₃(OrderNo)

(33)

Normalformen Normalformen

verschiedene Stufen, die aufeinander aufbauen:

1., 2., 3. Normalform (Ö Anhang) Grundidee

Grundidee

Unterscheidung funktionaler Abhängigkeiten in notwendige

notwendige und nicht erlaubtenicht erlaubte

Sei P der Primärschlüssel einer Tabelle.

Seien F_i ein beliebiges Nicht-Schlüssel-Feld der Tabelle.

notwendig:

F_i = f(P)

nicht erlaubt:

F_i = f(P'), P' echte Teilmenge von P

F_i = f(P), jedoch F_i = f(F_j), F_j = f(P) für ein weiteres Nicht-Schlüssel-Feld F

(34)

Beispiel Beispiel

notwendig notwendig

F_i = f(OrderNo,ItemNo), F_i = EmployeeNo,…,Quantity nicht erlaubt

nicht erlaubt

ItemName = f(ItemNo)

CustomerNo = f(OrderNo)

EmployeeNo = f(OrderNo)

Orders

OrderNo ItemNo EmployeeNo CustomerNo ItemName Quantity

Nut 3

67

122 3 9 176 Nut 9

Bolt

121 3 4 1024

121 4 4 1024

(35)

Weiteres Beispiel Weiteres Beispiel

notwendig notwendig

F_i = f(CustomerNo), F_i = FirstName,…,CityId, City nicht erlaubt

nicht erlaubt

City = f(CityId)

Customers

CustomerNo FirstName LastName CityId City

1 Brian Thompson NYC New York City

New York City

(36)

Abbildung Abbildung

relationales Modell

relationales Modell Î Î

XML XML

(37)

Relationales Modell Î Î XML

Relationales Modell kann einfach und ohne Relationales Modell kann einfach und ohne

Informationsverlust in XML kodiert werden Informationsverlust in XML kodiert 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 XML mindestens so ausdrucksstark wie relationales

Modell Modell

(38)

Mapping-Verfahren

Geeignete Abbildungen und Transformationsmechanismen Geeignete Abbildungen und Transformationsmechanismen

zwischen beiden

zwischen beiden ””InformationstrInformationsträägerngern““ findenfinden

Mapping-Verfahren

TemplateTemplate--drivendriven Mapping: Datenbankinhalte Æ XML

ModelModel--drivendriven Mapping: Datenbank Æ XML &

XMLÆ Datenbank

(39)

Template-driven Mapping

keine fest definierte Abbildung

Verwendung von XML-Dokumenten, die als Templates dienen

Einbettung von Anweisungen (z.B.

SELECT- Statements)

<?xml version="1.0"?>

<Intro>

the following flights have available seats:

</Intro>

SELECT Airline, FltNumber, Depart, Arrive FROM Flights

</SelectStmt>

</FlightInfo>

(40)

Template-driven Mapping – Beispiel

<Intro>

</Intro>

SELECT Airline, FltNumber, Depart, Arrive FROM Flights

</SelectStmt>

</FlightInfo>

<Intro>

</Intro>

<Row>

</Row>

...

</Flights>

</FlightInfo>

Ergebnis XML-Template mit

Select-Anweisung

(41)

Model-driven Mapping

Mapping: Datenbank Æ XML & XMLÆ Datenbank

festes Model

Table ModelTable Model

wenig flexibel aber intuitive Abbildung

nur für sehr flache XML-Dokumente

Einsatzbereich beschränkt auf relationale Strukturen

DataData SpecificSpecific ObjectObject ModelModel

Modellierung der Daten

Abbildung: Daten Ækorrespondierende Objekte Æ hierarchische Baumstruktur

(42)

Table Model

Vorteile Vorteile + einfach

+ leicht zu implementieren + schneller und effizienter

Datenaustausch

Nachteil Nachteil

- nicht anwendbar bei

komplexeren Datenmodellen und tiefer verschachtelten XML-Dokumenten

<table>

<row>

...

</row>

...

</table>

<table>

...

</table>

</database>

(43)

Data Specific Object Model

...

</Customer>

...

</Product>

</Line>

</SalesOrder>

</Orders>

Orders

SalesOrder

Line Product Customer

Daten-spezifischer Objektbaum

object SalesOrder {

soNumber = "12345";

customer = { custPtr};

line = { linePtr};

orderDate = "150999";

} object Line {

lineNumber = "1";

abgeleitete Objekte

(44)

Abbildung Abbildung

relationales Modell

relationales Modell Î Î XML XML

Type Model

(45)

Kodierung einer RDB in XML Kodierung einer RDB in XML

<LastName>Whitehorn</LastName>

<Type>Sales Person</Type>

</EmployeeTuple>

<LastName>Marklyn</LastName>

<Type>Human Resources</Type>

</EmployeeTuple>

</EmployeeTable>

Wurzel-Element = Name der

Datenbank

für jede Tabelle genau ein Kind- Element

darunter für jedes Tupel genau ein Kind-Element

darunter für jede Spalte ein Kind- Element

<table>

<row>

...

</row>

...

</table>

<table>

...

</table>

</database>

(46)

Kodierung von Null

Kodierung von Null Values Values

</EmployeeTuple>

<LastName>Marklyn</LastName>

</EmployeeTuple>

</EmployeeTable>

…

LeerwerteLeerwerte (null null values

values): undefinierte Werte

Kodierung:

entsprechendes Element (= Feld) einfach weglassen

dadurch

Unterscheidung zu leerem Inhalt

(47)

Das zugeh

Das zugehö örige rige XML XML -Schema - Schema

xsd:all

xsd:all xsd:sequence

minOccurs="0"

(48)

Kodierung von Schl

Kodierung von Schlü ü ssel ssel

Primärschlüssel: Typ xsd:ID.

Fremdschlüssel: Typ xsd:IDREF.

Probleme dieser Kodierung 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.

(49)

Beispiel Beispiel

<EmployeeNo>ID4</EmployeeNo>

<FirstName>String</FirstName>

<LastName>String</LastName>

<CityId>ID5</CityId>

<Type>String</Type>

</EmployeeTuple>

</EmployeeTable>

<CustomerNo>ID5</CustomerNo>

…

</CustomerTuple>

</CustomerTable>

</Database>

Primärschlüssel

müssen in gesamter Datenbank (nicht nur in Tabelle) eindeutig sein.

Fremdschlüssel kann sich auf beliebigen Primärschlüssel beziehen

(50)

Primä Prim ä rschl rschl ü ü ssel als ssel als key key

name: eindeutiger Namen des Primärschlüsselsname

xsd:selector: spezifiziert Kontext, auf die die xsd:selector Eindeutigkeitsbedingung angewandt wird.

ein oder mehrere xsd:field-Elemente: Elemente/Attribute, xsd:field die zusammen eindeutig sind

<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>

</xsd:element> Ö EmployeeNo innerhalb

EmployeeTable eindeutig

(51)

Fremdschl

Fremdschl ü ü ssel als ssel als keyref 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>

refer: Auf welchen Primärschlüssel wird verwiesen?refer

xsd:selector: Wo ist der Fremdschlüssel zu finden?xsd:selector

xsd:field: Aus welchen Feldern besteht der xsd:field

Ö Wert von CityId immer definiert

(52)

Fazit:

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

(53)

Datenmodellierung Datenmodellierung

mit XML

(54)

XML zur Datenmodellierung XML zur Datenmodellierung

XML flexibler als relationales Model:

Relationales Modell Relationales Modell

keine geschachtelten Tabellen

N:M-Beziehungen müssen in eigenen Tabellen ausgelagert werden.

XMLXML

erlaubt geschachtelte Strukturen

N:M-Beziehungen können unkompliziert ausgedrückt werden.

Warum also die Möglichkeiten von XML nicht voll ausnutzen?

(55)

Beispiel Beispiel

<Name>

<Last>Whitehorn</Last>

</Name>

<City>

</City>

<Order>

</Order>

</Orders>

</Employee>

Könnte so zwischen Vertriebs- und Gehaltsabteilung

ausgetauscht werden

als Austauschformat OK

auch als Speicherformat OK?

(56)

L L ö ö schanomalie schanomalie

<Name>

</Name>

<City>

</City>

<Order>

</Order>

</Orders>

</Employee>

Wird ein Angestellten- Datensatz 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.

(57)

Verbesserte Modellierung Verbesserte Modellierung

<Name>

</Name>

<City>

</City>

<OrderNo>121</OrderNo>

</Orders>

</Employee>

<Order-DB>

<Order>

</Order>

</Order-DB>

(58)

Ä Ä nderungsanomalie nderungsanomalie

<Name>

</Name>

<City>

</City>

</Orders>

</Employee>

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.

(59)

Verbesserte Modellierung Verbesserte Modellierung

<Employee-DB>

<Name>

</Name>

<CityKey>C123</CityKey>

</Orders>

</Employee>

</Employee-DB>

<City-DB>

<City>

<CityKey>C123</CityKey>

</City>

</City-DB>

<Order-DB>

<Order>

</Order>

</Order-DB>

(60)

Noch eine

Noch eine Ä Ä nderungsanomalie nderungsanomalie

<Order-DB>

<Order>

<ItemName>Black-Bag</ItemName>

</OrderItem>

</OrderItems>

</Order>

</Order-DB>

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.

(61)

Verbesserte Modellierung Verbesserte Modellierung

<Order-DB>

<Order>

<ItemNo>FX100</ItemNo>

</OrderItem>

</OrderItems>

</Order>

</Order-DB>

<Inventory-DB>

<Item>

</Item>

</Inventory-DB>

(62)

Anfrageoptimierung Anfrageoptimierung

<Order-DB>

<Order>

</OrderItem>

</OrderItems>

</Order>

</Order-DB>

Hier fehlt Verweis auf

Vermittler (EmployeeNo).

Vermittler normalerweise Ansprechpartner für

Kundenauftrag

Ö Angestellten-Datenbank muss durchsucht werden, um Vermittler zu ermitteln.

Wer ist Vermittler?

(63)

<Order-DB>

<Order>

</OrderItem>

</OrderItems>

</Order>

</Order-DB>

Anfrageoptimierung Anfrageoptimierung

<Order-DB>

<Order>

</OrderItem>

</OrderItems>

<EmployeeNo>4</EmployeeNo>

</Order>

</Order-DB>

<Employee-DB>

<Name>

</Name>

</Orders>

</Employee>

</Employee-DB>

statt Verweis Angestellter Î Auftrag

(64)

Endg Endg ü ü ltige Modellierung ltige Modellierung

<Order>

</OrderItem>

</OrderItems>

</Order>

<Name>

</Name>

</Employee>

<Item>

</Item>

<City>

</City>

(65)

Vergleich mit relationalem Modell Vergleich mit relationalem Modell

</OrderItemTuple>

</OrderItemTable>

</OrderTuple>

<Name>

</Name>

</EmployeeTuple>

</ItemTuple>

</CityTuple>

9 9

(66)

Vergleich mit relationalem Modell Vergleich mit relationalem Modell

</OrderItemTuple>

</OrderItemTable>

</OrderTuple>

</EmployeeTuple>

<ItemName>Black- Bag</ItemName>

</ItemTuple>

</CityTuple>

9

9 9

N:M

N:M-Beziehung zwischen OrderNo und ItemNo als

Hierarchie

(67)

Relationale Modellierung Relationale Modellierung

</OrderSpecTuple>

<EmployeeNo>4</EmployeeNo

>

</EmployeeTuple>

</ItemTuple>

</CityTuple> 9

N:M-Beziehung als Relation OrderSpec mit

9

9 9

</OrderTuple> 9

(68)

Fazit aus dem Beispiel Fazit aus dem Beispiel

Ausgangspunkt Ausgangspunkt

strukturiertes XML-Dokument als Speicherformat Transformationen

Transformationen

Beseitigung von Lösch- und Änderungsanomalien Ergebnis

Ergebnis

mehrere, wesentlich flachere XML-Strukturen

relationalem Modell (in 3. NF) sehr ähnlich

Ausnahme: N:M-Beziehungen als geschachtelte Strukturen

(69)

Systematik der Datenmodellierung Systematik der Datenmodellierung

relationales Modell relationales Modell

schrittweise Normalformbildung: Ergebnis formal definiert

XMLXML

Normalformen aus relationalem Modell nicht auf XML übertragbar

Grund: relationales Model erlaubt keine geschachtelten Tabellen

bisher keine Systematik der Datenmodellierungkeine Systematik der Datenmodellierung

informelles Verfahren:

Asset-Oriented Modeling (Daum & Merten, System

(70)

Fazit aus heutiger Vorlesung Fazit aus heutiger Vorlesung

Daten mit vielen funktionalen Abh

Daten mit vielen funktionalen Abhäängigkeitenngigkeiten

bewährte Speicherformate wie relationale Datenbanken besser

Tabellen als XML serialisieren

Text-Text-Dokumente mit nur wenigen funktionalen Dokumente mit nur wenigen funktionalen AbhAbhäängigkeitenngigkeiten

XML auch als Speicherformat geeignet

(71)

Wie geht es weiter?

heutige Vorlesung heutige Vorlesung

; Daten vs. Dokumente

; Wie XML persistent speichern?

; Vergleich XML mit relationalem Modell

; Wie Daten mit XML modellieren?

nänächste chste ÜÜbungbung

XML und Datenbanken Vorlesung n

Vorlesung näächste Woche chste Woche

Web Services (insgesamt 4 Termine)

www.rpbourret.com/xml/XMLAndDatabases.htm

(72)

Anhang

(73)

1. Normalform (NF) 1. Normalform (NF)

Eine relationale Datenbank ist in 1. Normalform, falls 1. Normalform alle Tabellen

1) einen Primärschlüssel haben und 2) nur primitive Daten enthalten.

Entspricht der Definition des relationalen Modells

(74)

2. Normalform (NF) 2. Normalform (NF)

Eine relationale Datenbank ist in 2. Normalform, falls2. Normalform 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.

Orders

OrderNo ItemNo EmployeeNo CustomerNo ItemName Quantity

Nut 3

67

122 3 9 176 Nut 9

Bolt

121 3 4 1024

121 4 4 1024

nicht in 2. NF nicht in 2. NF

(75)

3. Normalform (NF) 3. Normalform (NF)

Customers

CustomerNo FirstName LastName CityId City

1 Brian Thompson NYC New York City

New York City

Eine relationale Datenbank ist in 3. Normalform, falls3. Normalform 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