How-to: 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 Ă&#x17D; 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