XML und Datenbanken Relationales Datenmodell
Werbung
6/2/2004 Heutige Vorlesung XML und Datenbanken weites Feld Heutige Vorlesung konzentriert sich auf die Frage, was XML von relationalen Datenbanken lernen kann: Was sollte beachtet werden, wenn XML zur Datenspeicherung verwendet wird? XML und Datenbanken vollständigeDarstellung Darstellungdes desThemas: Themas: vollständige Î www.rpbourret.com/xml/XMLAndDatabases.htm Î www.rpbourret.com/xml/XMLAndDatabases.htm Î www.rpbourret.com/xml/XMLDatabaseProds.htm www.rpbourret.com/xml/XMLDatabaseProds.htm Î © Klaus Schild 2004 1 © Klaus Schild 2004 2 Übersicht relationales Datenmodell Abbildung relationales Datenmodell Î XML Datenmodellierung mit XML Relationales Datenmodell Normalformen als Hilfsmittel zur Datenmodellierung © Klaus Schild 2004 3 © Klaus Schild 2004 4 Relationales Datenmodell PrimärPrimär- und Fremdschlüssel 1970 von Codd eingeführt Daten in Tabellen organisiert mindestens eine Spalte einer Tabelle als Primärschlüssel ausgezeichnet Tabelle repräsentiert n-stellige Beziehung (Relation) zwischen primitiven Daten. bei mehreren Spalten: zusammengesetzter Primärschlüssel Tabelle besteht aus Spalten (Felder Felder) und Zeilen (Tupel Tupel). Fremdschlüssel: Fremdschlüssel referenziert Primärschlüssel einer anderen Tabelle Zeilen und Spalten ungeordnet Tabellen haben eindeutige Namen. Customers Spalten haben Namen, der innerhalb der Tabelle eindeutig ist. Customers © Klaus Schild 2004 Name, Abteilung CustomerNo FirstName LastName CityId 1 Brian Thompson NYC 2 Sally Henderson NYC CustomerNo FirstName LastName CityId 1 Brian Thompson NYC 2 Sally Henderson NYC Orders 5 © Klaus Schild 2004 OrderNo CustomerNo ItemNo 121 1 FX100 5 1 FX200 6 1 6/2/2004 Eindeutigkeit und Existenz Typen von Beziehungen Tabellen (Relationen) repräsentieren Beziehungen zwischen primitiven Daten. Customers CustomerNo FirstName LastName CityId 1 Brian Thompson NYC 2 Sally Henderson NYC CustomerNo ItemNo 121 1 FX100 5 1 FX200 CustomerNo FirstName LastName CityId 1 Brian Thompson NYC 2 Sally Henderson NYC Tabellen repräsentieren meist Objekte der realen Welt, wie z.B. Kunden oder Aufträge. Orders OrderNo Customers Zwischen Objekte der realen Welt können unterschiedliche Typen von Beziehungen bestehen, wie 1:N- oder N:M-Beziehungen. Primärschlüssel (d.h. deren Werte) müssen existieren Primärschlüssel müssen innerhalb der Tabelle eindeutig sein. Wie werden werden 1:N1:N- und und N:MN:MWie Beziehungen zwischen zwischen Tabellen Tabellen Beziehungen ausgedrückt? ausgedrückt? Für jeden Fremdschlüssel muss ein zugehöriger Primärschlüssel existieren. © Klaus Schild 2004 7 1:N1:N-Beziehung © Klaus Schild 2004 8 1:N1:N-Beziehung im relationalen Modell Primärschlüssel Kunde 1 * 1 Auftrag Bestimmter Kunde kann mehrere Aufträge erteilen. : Umgekehrt ist aber jedem Auftrag immer genau ein Kunde zugeordnet. N Zwischen Kunden und Aufträgen besteht eine 1:NBeziehung. © Klaus Schild 2004 9 1:11:1-Beziehung Kunde 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 nicht eindeutig © Klaus Schild 2004 10 1:11:1-Beziehung im relationalen Modell 1 1 Customers Kunde (ausführlich) CustomerNo FirstName LastName CityId 1 Brian Thompson NYC 2 Sally Henderson NYC 1:1-Beziehungen eher selten Customers (details) Beispiel: zwei unterschiedliche Kunden-Tabellen kompakte Version für Außendienstmitarbeiter CustomerNo LastName FirstName CityId CreditCard CreditCardNo 1 Brian Thompson NYC Amex 100900402344 2 Sally Henderson NYC Visa 100800402e33 ausführlichere Version für die interne Verwaltung beide Schlüssel gleichzeitig Primär- und Fremdschlüssel Zwischen den beiden Tabellen sollte eine 1:1Beziehung bestehen. © Klaus Schild 2004 Name, Abteilung 11 © Klaus Schild 2004 12 2 6/2/2004 N:MN:M-Beziehung N:MN:M-Beziehung im relationalen Modell * * Kunde Kunde Angestellter Bestimmter Angestellter kann mehrere Kunden betreuen. Umgekehrt kann ein Kunde gleichzeitig von mehreren Angestellten betreut werden. * * 1 Angestellter im relationalen Datenmodell N:M-Bezeiehung nicht direkt darstellbar muss in zwei 1:N-Beziehungen aufgebrochen werden Zwischen Kunden und Angestellten besteht eine N:MBeziehung. © Klaus Schild 2004 1 Dritte Tabelle enthält Fremdschlüssel beider Tabellen. 13 © Klaus Schild 2004 14 N:MN:M-Beziehung im relationalen Modell Customers CustomerNo FirstName LastName CityId 1 Brian Thompson NYC 2 Sally Henderson NYC Abbildung relationales Datenmodell Î XML N:M-Relationship Key CustomerNo EmployeeNo 121 1 4 5 1 5 Employees EmployeeNo FirstName LastName CityId Type 4 Mark Whitehorn NYC Sales person 5 Bill Marklyn NYC Human Resources © Klaus Schild 2004 15 XML & Datenbanken: Drei Alternativen Anwendung Tabellen/SQL Anwendung © Klaus Schild 2004 16 Wrapper Abbildung relationales Modell Î XML nötig Anwendung XML XML Anwendung XML Wrapper Tabellen/SQL Wrapper Tabellen/SQL relationale Datenbank XMLals als XML unstrukturierte unstrukturierte Strings Strings abspeichern abspeichern © Klaus Schild 2004 Name, Abteilung XMLDatenbank XMLals als XML strukturierte strukturierte XML-Dokumente XML-Dokumente abspeichern abspeichern Relationales Datenmodell kann einfach in XML kodiert werden. Kodierung könnte auch als Standard für relationale Datenbanken dienen. 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 Customers CustomerNo Customers relationale Datenbank FirstName LastName CityId 1 CustomerNo 2 1 Brian Thompson NYC FirstName LastName CityId Sally Henderson NYC Brian Thompson NYC 2 Sally Henderson NYC relationale Datenbank XMLals alsTabellen Tabellen XML abspeichern abspeichern 17 © Klaus Schild 2004 Hierfür gibt es allerdings keinen etablierten Standard. inoffizieller Vorschlag: http://www.w3.org/XML/RDB.html 18 3 6/2/2004 Abbildung Relationales Modell Î XML Kodierung von Null Values <Database> <Database> <EmployeeTable> <EmployeeTable> <EmployeeTuple> <EmployeeTuple> <EmployeeNo>k1</EmployeeNo> <EmployeeNo>k1</EmployeeNo> <FirstName>Mark</FirstName> <FirstName>Mark</FirstName> <LastName>Whitehorn</LastName> <LastName>Whitehorn</LastName> <CityId>NYC</CityId> <CityId>NYC</CityId> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> <EmployeeTuple> <EmployeeTuple> <EmployeeNo>k2</EmployeeNo> <EmployeeNo>k2</EmployeeNo> <FirstName>Bill</FirstName> <FirstName>Bill</FirstName> <LastName>Marklyn</LastName> <LastName>Marklyn</LastName> <CityId>NYC</CityId> <CityId>NYC</CityId> <Type>HumanResources</Type> Resources</Type> <Type>Human </EmployeeTuple> </EmployeeTuple> </EmployeeTable> </EmployeeTable> ...... <Database> <Database> <EmployeeTable> <EmployeeTable> <EmployeeTuple> <EmployeeTuple> <EmployeeNo>k1</EmployeeNo> <EmployeeNo>k1</EmployeeNo> <FirstName>Mark</FirstName> <FirstName>Mark</FirstName> <LastName>Whitehorn</LastName> <LastName>Whitehorn</LastName> <CityId>NYC</CityId> <CityId>NYC</CityId> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> <EmployeeTuple> <EmployeeTuple> <EmployeeNo>k2</EmployeeNo> <EmployeeNo>k2</EmployeeNo> <FirstName>Bill</FirstName> <FirstName>Bill</FirstName> <LastName>Marklyn</LastName> <LastName>Marklyn</LastName> Wurzel-Element = Name der Datenbank für jede Tabelle genau ein KindElement darunter für jedes Tupel genau ein Kind-Element darunter für jede Spalte ein KindElement © Klaus Schild 2004 <Type></Type> <Type></Type> </EmployeeTuple> </EmployeeTuple> </EmployeeTable> </EmployeeTable> … … 19 Das zugehörige XMLXML-Schema Leerwerte (null values) sind undefinierte Werte. Kodierung: entsprechendes Element (Feld) einfach weglassen dadurch Unterscheidung zu leerem Inhalt © Klaus Schild 2004 20 Kodierung von Schlüssel Primärschlüssel vom Typ xs:ID. Fremdschlüssel vom Typ xs:IDREF. Probleme xs:sequence keine zusammengesetzten Primärschlüssel darstellbar xs:all Statt Eindeutigkeit innerhalb der Tabelle, erzwingt xs:ID Eindeutigkeit in gesamter Datenbank xs:all Zwei Tabellen dürfen also niemals identischen Primärschlüssel haben. Statt eines ganz bestimmten Primärschlüssels, referenziert xs:IDREF beliebigen Primärschlüssel mit Typ xs:ID. minOccurs="0" Reihenfolge der Tabellen, Tupel und Spalten egal © Klaus Schild 2004 21 Beispiel <Database> <Database> <EmployeeTable> <EmployeeTable> <EmployeeTuple> <EmployeeTuple> <EmployeeNo>ID4</EmployeeNo> <EmployeeNo>ID4</EmployeeNo> <FirstName>String</FirstName> <FirstName>String</FirstName> <LastName>String</LastName> <LastName>String</LastName> <CityId>ID5</CityId> <CityId>ID5</CityId> <Type>String</Type> <Type>String</Type> </EmployeeTuple> </EmployeeTuple> </EmployeeTable> </EmployeeTable> <CustomerTable> <CustomerTable> <CustomerTuple> <CustomerTuple> <EmployeeNo>ID5</EmployeeNo> <EmployeeNo>ID5</EmployeeNo> … … </CustomerTuple> </CustomerTuple> </CustomerTable> </CustomerTable> </Database> </Database> © Klaus Schild 2004 Name, Abteilung © Klaus Schild 2004 22 Kodierung von Primärschlüssel mit key <xs:elementname="Database"> name="Database"> <xs:element <xs:complexType> <xs:complexType> Definitionder derTabellen Tabellen Definition </xs:complexType> </xs:complexType> <xs:keyname="EmployeeKey"> name="EmployeeKey"> <xs:key <xs:selectorxpath="EmployeeTable/EmployeeTuple"/> xpath="EmployeeTable/EmployeeTuple"/> <xs:selector <xs:fieldxpath="EmployeeNo"/> xpath="EmployeeNo"/> <xs:field </xs:key> </xs:key> Î EmployeeNo EmployeeNo innerhalb innerhalb Î </xs:element> </xs:element> Primärschlüssel müssen in gesamter Datenbank eindeutig sein. Fremdschlüssel kann sich auf einen beliebigen Primärschlüssel beziehen. Employee-Tabelle eindeutig eindeutig Employee-Tabelle name: name eindeutiger Namen des Primärschlüssels xs:selector: xs:selector spezifiziert Kontext, auf die die Eindeutigkeitsbedingung angewandt wird. ein oder mehrere xs:field-Elemente: Elemente/Attribute, xs:field die zusammen eindeutig sein sollen. 23 © Klaus Schild 2004 24 4 6/2/2004 Kodierung von Fremdschlüssel mit keyref Fazit Abbildung relationale Datenbank Î XML ohne Informationsverlust möglich (einschl. Primär- und Fremdschlüssel) <xs:elementname="Database"> name="Database"> <xs:element <xs:complexType> <xs:complexType> Definitionder derTabellen Tabellen Definition </xs:complexType> </xs:complexType> <xs:keyrefname="CityIDKeyRef" name="CityIDKeyRef"refer="CityIDKey"> refer="CityIDKey"> <xs:keyref <xs:selectorxpath="*/*"/> xpath="*/*"/> <xs:selector <xs:fieldxpath="CityID"/> xpath="CityID"/> <xs:field </xs:keyref> Î Wert Wert von von CityId CityId </xs:keyref> Î </xs:element> </xs:element> immer definiert Instanz kodiert Datenbank XML-Schema kodiert Datenbankschema immer definiert refer: refer referenzierter Primärschlüssel xs:selector: xs:selector spezifiziert Kontext, auf die die Existenzbedingung angewandt wird. ein oder mehrere xs:field-Elemente: Elemente/Attribute, für xs:field die Primärschlüssel (mit passendem Typ) existieren muss © Klaus Schild 2004 25 © Klaus Schild 2004 26 XML zur Datenmodellierung Relationales Modell kann einfach in XML kodiert werden. Im Vergleich zum relationalen Model ist XML aber wesentlich flexibler: Datenmodellierung mit XML Relationales Modell erlaubt in Tabellen nur primitive Daten, geschachtelte Tabellen nicht erlaubt. XML erlaubt solche geschachtelten Strukturen. Warum nicht nicht die die hierarchische hierarchische Warum Strukturierungsmöglichkeiten von von Strukturierungsmöglichkeiten XML voll voll ausnutzen? ausnutzen? XML © Klaus Schild 2004 27 Beispiel <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <City> <City> <Name>NewYork YorkCity</Name> City</Name> <Name>New <CityId>NYC</CityId> <CityId>NYC</CityId> </City> </City> <Type>SalesPerson</Type> Person</Type> <Type>Sales <Orders> <Orders> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems>…</OrderIntems> <OrderItems>…</OrderIntems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Orders> </Orders> </Employee> </Employee> © Klaus Schild 2004 Name, Abteilung © Klaus Schild 2004 28 Löschanomalie Könnte zwischen Vertriebsund Gehaltsabteilung ausgetauscht werden. als Austauschformat OK auch als Speicherformat OK? 29 <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <City> <City> <Name>NewYork YorkCity</Name> City</Name> <Name>New <CityId>NYC</CityId> <CityId>NYC</CityId> </City> </City> <Type>SalesPerson</Type> Person</Type> <Type>Sales <Orders> <Orders> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems>…</OrderItems> <OrderItems>…</OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Orders> </Orders> </Employee> </Employee> © Klaus Schild 2004 Wird ein Angestellter gelöscht, dann werden auch alle Aufträge gelöscht, die er vermittelt hat. Gefahr, ungewollt Informationen zu löschen Daher Order-Relation auslagern und hier durch Fremdschlüssel OrderNo ersetzen (Referenz). 30 5 6/2/2004 Verbesserte Modellierung <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <City> <City> <Name>NewYork YorkCity</Name> City</Name> <Name>New <CityId>NYC</CityId> <CityId>NYC</CityId> </City> </City> <Type>SalesPerson</Type> Person</Type> <Type>Sales <Orders> <Orders> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> </Orders> </Orders> </Employee> </Employee> Änderungsanomalie <Order-DB> <Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems>…</OrderItems> <OrderItems>…</OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Order-DB> </Order-DB> © Klaus Schild 2004 <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <City> <City> <Name>NewYork YorkCity</Name> City</Name> <Name>New <CityId>NYC</CityId> <CityId>NYC</CityId> </City> </City> <Type>SalesPerson</Type> Person</Type> <Type>Sales <Orders> <Orders> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> </Orders> </Orders> </Employee> </Employee> 31 Verbesserte Modellierung <Employee-DB> <Employee-DB> <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales <Orders> <Orders> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> </Orders> </Orders> </Employee> </Employee> </Employee-DB> </Employee-DB> Gefahr von Inkonsistenzen Daher City-Relation auslagern und hier durch Fremdschlüssel ersetzen. © Klaus Schild 2004 32 <Order-DB> <Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems> <OrderItems> <OrderItem> <OrderItem> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItem> </OrderItem> </OrderItems> </OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Order-DB> </Order-DB> <City-DB> <City-DB> <City> <City> <CityKey>C123></CityKey> <CityKey>C123></CityKey> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New </City> </City> </City-DB> </City-DB> 33 Verbesserte Modellierung <Order-DB> <Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems> <OrderItems> <OrderItem> <OrderItem> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItem> </OrderItem> </OrderItems> </OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Order-DB> </Order-DB> unnötiger Verwaltungsaufwand Noch eine Änderungsanomalie <Order-DB> <Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems>…</OrderItems> <OrderItems>…</OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Order-DB> </Order-DB> © Klaus Schild 2004 Wird CityId geändert, dann muss diese Änderung in allen AngestelltenDatensätzen nachvollzogen werden. Wird ItemName geändert, dann muss diese Änderung in allen Order-Datensätzen nachvollzogen werden. Deshalb Zuordnung ItemNo/ItemName auslagern und durch Fremdschlüssel ersetzen. © Klaus Schild 2004 34 Anfrageoptimierung <Inventory-DB> <Inventory-DB> <Item> <Item> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </Item> </Item> </Inventory-DB> </Inventory-DB> <Order-DB> <Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems> <OrderItems> <OrderItem> <OrderItem> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItem> </OrderItem> </OrderItems> </OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> </Order> </Order> </Order-DB> </Order-DB> Hier fehlt Verweis auf Vermittler (EmployeeNo). Vermittler aber normalerweise Ansprechpartner für Kundenauftrag Wer ist ist Vermittler? Vermittler? Wer Angestellten-Datenbank muss durchsucht werden, um Vermittler eines Auftrages zu ermitteln. © Klaus Schild 2004 Name, Abteilung 35 © Klaus Schild 2004 36 6 6/2/2004 Anfrageoptimierung Endgültige Modellierung <Order-DB> <Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems> <OrderItems> <OrderItem> <OrderItem> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItem> </OrderItem> </OrderItems> </OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </Order> </Order> </Order-DB> </Order-DB> <Order> <Order> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItems> <OrderItems> <OrderItem> <OrderItem> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItem> </OrderItem> </OrderItems> </OrderItems> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </Order> </Order> <Employee-DB> <Employee-DB> <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales <Orders> <Orders> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> </Orders> </Orders> </Employee> </Employee> </Employee-DB> </Employee-DB> <Item> <Item> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </Item> </Item> statt Verweis Angestellter Î Auftrag: Verweis Auftrag Î Vermittler © Klaus Schild 2004 37 Vergleich mit relationalem Modell <CityTuple> <CityTuple> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <ItemTuple> <ItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </ItemTuple> </ItemTuple> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New </CityTuple> 9 </CityTuple> 9 © Klaus Schild 2004 39 Relationale Modellierung <OrderSpecTuple> <OrderSpecTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderSpecTuple> </OrderSpecTuple> 9 <OrderTuple> <OrderTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </OrderTuple> </OrderTuple> 9 <ItemTuple> <ItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </ItemTuple> </ItemTuple> 9 © Klaus Schild 2004 Name, Abteilung <City> <City> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New </City> </City> © Klaus Schild 2004 38 Relationale Modellierung <EmployeeTuple> <EmployeeTuple> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <CityKey>NYC</CityKey> <CityKey>NYC</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> <OrderTuple> <OrderTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItemTable> <OrderItemTable> <OrderItemTuple> <OrderItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItemTuple> </OrderItemTuple> </OrderItemTable> </OrderItemTable> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </OrderTuple> </OrderTuple> <Employee> <Employee> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales </Employee> </Employee> <OrderTuple> <OrderTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItemTable> <OrderItemTable> N:M <OrderItemTuple> <OrderItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItemTuple> </OrderItemTuple> </OrderItemTable> </OrderItemTable> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </OrderTuple> </OrderTuple> <ItemTuple> <ItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </ItemTuple> </ItemTuple> 9 <EmployeeTuple> <EmployeeTuple> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <FirstName>Mark</FirstName> <FirstName>Mark</FirstName> <LastName>Whitehorn</LastName> <LastName>Whitehorn</LastName> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> 9 <CityTuple> <CityTuple> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New </CityTuple> 9 </CityTuple> N:M-Beziehung muss in eigener Relation kodiert werden! © Klaus Schild 2004 40 Fazit <EmployeeTuple> <EmployeeTuple> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> 9 <CityTuple> <CityTuple> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New </CityTuple> 9 </CityTuple> N:M-Beziehung als Relation OrderSpec mit zusammengesetztem Primärschlüssel 41 Ausgangspunkt strukturiertes XML-Dokument als Speicherformat Transformationen zur Beseitigung von Lösch- und Änderungsanomalien Ergebnis mehrere, wesentlich flachere XML-Strukturen relationalem Datenmodell ähnlich Ausnahme: N:M-Beziehungen als geschachtelte Strukturen © Klaus Schild 2004 42 7 6/2/2004 Normalformen Hilfsmittel zur Datenmodellierung für relationales Modell formal definiert Ziele Eigenschaften zu passenden Objekten gruppieren Normalformen Redundante Informationen eliminieren Sicherstellen, dass jede Information eindeutig identifiziert werden kann Mittel Verständnis der Bedeutung der Daten Verständnis funktionaler Abhängigkeiten zwischen Feldern Auf XML XML übertragbar? übertragbar? Auf © Klaus Schild 2004 43 © Klaus Schild 2004 44 Beispiel Funktionale Abhängigkeiten Beispiel: Fläche = Höhe X Breite Orders Fläche funktional abhä abhängig von der Höhe und Breite OrderNo ItemNo EmployeeNo CustomerNo ItemName Quantity D.h. die Höhe zusammen mit der Breite bestimmen eindeutig die Fläche. 121 3 4 1024 Nut 3 121 4 4 1024 Bolt 67 122 3 9 176 Nut 9 Im relationalem Modell sind funktionale Abhängigkeiten zwischen Feldern relevant. Annahme: jedem Auftrag genau ein Angestellter (Vermittler) zugeordnet EmployeeNo funktional abhängig von OrderNo. Funktionale Abhängigkeiten Abhängigkeiten nicht nicht an an Daten Daten selbst selbst zu zu Funktionale erkennen, sondern sondern daran, daran, wie wie sie sie verwendet verwendet werden. werden. erkennen, © Klaus Schild 2004 45 Weitere funktional Abhängigkeiten © Klaus Schild 2004 46 1. Normalform (NF) Eine relationale Datenbank ist in 1. Normalform, falls alle Tabellen 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 1) einen Primärschlüssel haben und 2) nur primitive Daten enthalten. Entspricht der Definition des relationalen Modells Quantity vom gesamten Primärschlüssel funktional abhängig alle andere Felder nur von Teilen des Primärschlüssels funktional abhängig © Klaus Schild 2004 Name, Abteilung 47 © Klaus Schild 2004 48 8 6/2/2004 2. Normalform (NF) 3. Normalform (NF) Eine relationale Datenbank ist in 2. Normalform, falls Eine relationale Datenbank ist in 3. Normalform, falls 1) sie in 1. Normalform ist, 1) sie in 2. Normalform ist und 2) alle Nicht-Schlüssel-Felder vom Primärschlüssel funktional abhängig sind und 2) alle Nicht-Schlüssel-Felder direkt (d.h. nicht transitiv) vom Primärschlüssel funktional abhängig sind. 3) kein Nicht-Schlüssel-Feld bereits von einem Teil des Primärschlüssels funktional abhängig ist. nicht in in 2. 2. NF NF nicht 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 © Klaus Schild 2004 XMLXML-Modellierung nicht in 1. NF <ItemTuple> <ItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </ItemTuple> </ItemTuple> 9 FirstName LastName CityId City 1 Brian Thompson NYC New York City 2 Sally Henderson NYC New York City © Klaus Schild 2004 50 Relationales Modell in 3. NF <EmployeeTuple> <EmployeeTuple> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <Name> <Name> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> </Name> </Name> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> <OrderSpecTuple> <OrderSpecTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderSpecTuple> </OrderSpecTuple> 9 <OrderTuple> <OrderTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </OrderTuple> </OrderTuple> 9 <CityTuple> <CityTuple> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New 9 </CityTuple> </CityTuple> © Klaus Schild 2004 CustomerNo Durch Normalformbildung können unerwünschte funktionale Abhängigkeiten eliminiert werden. 49 <OrderTuple> <OrderTuple> <OrderNo>121</OrderNo> <OrderNo>121</OrderNo> <OrderItemTable> <OrderItemTable> <OrderItemTuple> <OrderItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <Quantity>1000</Quantity> <Quantity>1000</Quantity> </OrderItemTuple> </OrderItemTuple> </OrderItemTable> </OrderItemTable> <CustomerNo>999</CustomerNo> <CustomerNo>999</CustomerNo> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> </OrderTuple> </OrderTuple> nicht in in 3. 3. NF NF nicht Customers 51 <ItemTuple> <ItemTuple> <ItemNo>FX100</ItemNo> <ItemNo>FX100</ItemNo> <ItemName>Black-Bag</ItemName> <ItemName>Black-Bag</ItemName> </ItemTuple> </ItemTuple> <EmployeeTuple> <EmployeeTuple> <EmployeeNo>4</EmployeeNo> <EmployeeNo>4</EmployeeNo> <First>Mark</First> <First>Mark</First> <Last>Whitehorn</Last> <Last>Whitehorn</Last> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <Type>SalesPerson</Type> Person</Type> <Type>Sales </EmployeeTuple> </EmployeeTuple> 9 <CityTuple> <CityTuple> <CityKey>C123</CityKey> <CityKey>C123</CityKey> <CityId>NYC</CityId> <CityId>NYC</CityId> <Name>NewYork YorkCity</Name> City</Name> <Name>New </CityTuple> </CityTuple> 9 9 © Klaus Schild 2004 Normalformbildung für XML Fazit XML-Daten normalerweise nicht in 1. NF unterschiedliche Anforderungen für Austausch- und Speicherformate: Normalformbildung aus dem relationalem Modell nicht auf XML übertragbar Austauschformate: sollten kompakt und einfach zu parsen sein Für XML bisher kein rigoroses Verfahren der Normalformbildung Speicherformate: sollten Lösch- und Änderungsanomalien vermeiden und wichtigsten Anfragen optimieren informelles Modellierungsverfahren für XML: Asset-Oriented Modeling (Daum & Merten, System Architecture with XML, 2003). © Klaus Schild 2004 Name, Abteilung 52 Austausch- und Speicherformat deshalb häufig sehr unterschiedlich, auch wenn XML verwendet wird. 53 © Klaus Schild 2004 54 9 6/2/2004 Fazit Wie geht es weiter? Für Daten mit vielen funktionalen Abhängigkeiten besser gleich professionelle Speicherformate (wie relationale Datenbanken) wählen. heutige Vorlesung Für Text-Dokumente ohne funktionale Abhängigkeiten kann XML als Speicherformat benutzt werden. heute 16:15 ; Was sollte beachtet werden, wenn XML zur Datenspeicherung verwendet wird? betreute Rechnerübung nächste Woche Web Services (insgesamt 4 Termine) © Klaus Schild 2004 Name, Abteilung 55 © Klaus Schild 2004 56 10
