Relationelle databaser og XML

Præsentationer af emnet: "Relationelle databaser og XML"— Præsentationens transcript:

1 Relationelle databaser og XML
11 trin til at mappe en relationel database til XML. Inspireret af www-106.ibm.com/developerworks/library/x-struct

2 Trinene Udvælg de data, der skal mappes til XML Bestem rod-elementet
Modeller indholdstabellerne som elementer Modeller de felter, der ikke er fremmednøgler Tilføj id som nøgle til elementerne Modeller opslagstabeller og fremmednøgler til disse Modeller rodelementets indhold Modeller relationer gennem understrukturer Modeller relationer vha. nøgler Tilføj manglende elementer til rod elementet Fjern id'er der ikke er blevet refereret til

3 Gennemgående eksempel – et faktureringssystem

4 Trin 1: Vælg de data, der er nødvendige
Eksempel: Data til opgørelse af salg pr. kunde pr. måned De tabeller, der er nødvendige er Customer, MonthlyTotal og MonthlyCustomerTotal

5 Trin 2: Find rod-elementet
Elementet skal beskrive hvad dokumentet indeholder. Rod-elementet kommer altså ikke (nødvendigvis) fra en del af databasen. Her vælges at kalde det for SalesData. Elementet kan også indeholde oplysninger, som f.eks status for dokumentet, eller hvornår det er opdateret Her vælges at indføre en statusattribut, som kan være enten 'NewVersion', 'UpdatedVersion' eller CourtesyCopy

6 Trin 2: Schema <?xml version="1.0" encoding="iso-8859-1"?>
<xs:schema targetNamespace= xmlns= xmlns:xs=" <xs:simpleType name="StatusType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="NewVersion"/> <xs:enumeration value="UpdatedVersion"/> <xs:enumeration value="CourtesyCopy"/> </xs:restriction> </xs:simpleType> <xs:element name="SalesData"> <xs:complexType> <xs:attribute name="Status" type="StatusType"/> </xs:complexType> </xs:element> </xs:schema>

7 Trin 3: Modeller indholdstabeller
Alle tabeller, undtagen ShipMethod, er indholdstabeller. Relationstabeller (for at undgå mange – til - mange relationer) modelleres som indholdstabeller I første omgang puttes der ikke indhold i typen. Og minOccur sættes til nu til 0, men kan blive ændret senere

8 Trin 3: Schema <xs:element name="SalesData">
<xs:complexType> <xs:sequence> <xs:element name="Invoice" minOccurs="0"></xs:element> <xs:element name="Customer" minOccurs="0"> </xs:element> <xs:element name="Part" minOccurs="0"> </xs:element> <xs:element name="MonthlyTotal" minOccurs="0"></xs:element> <xs:element name="MonthlyCustomerTotal" minOccurs="0"></xs:element> <xs:element name="MonthlyPartTotal" minOccurs="0"></xs:element> <xs:element name="LineItem" minOccurs="0"> </xs:element> </xs:sequence> <xs:attribute name="Status" type="StatusType"/> </xs:complexType> </xs:element>

9 Trin 4: Modeller felter som ikke er fremmednøgler
De enkelte kolonner modelleres som attributter Ved f.eks tekstblokke kan det være ide at bruge elementer istedet. Det vælges at bruges AttributeGroup

10 Trin 4: Schema <xs:attributeGroup name="InvoiceAttributes">
<xs:attribute name="InvoiceId" type="xs:number" use="required"/> <xs:attribute name="InvoiceNumber" type="xs:number" use="required"/> <xs:attribute name="TrackingNumber" type="xs:number" use="required"/> <xs:attribute name="OrderDate" type="xs:date" use="required"/> <xs:attribute name="ShipDate" type="xs:date" use="required"/> </xs:attributeGroup> .... <xs:element name="SalesData"> <xs:complexType> <xs:sequence> <xs:element name="Invoice" minOccurs="0"> <xs:attributeGroup ref="InvoiceAttributes"/> </xs:complexType> </xs:element> ..... </xs:sequence>

11 Trin 5: Tilføj id som nøgle til elementerne
ID'et kaldes tabelnavnID, og tilføjes bare til attributgruppen Samtidig defineres nøglen med <key> Den defineres under <SalesData>, da den samme værdi godt kan forekomme hvis der er flere sæt af <SalesData>

12 Trin 5: Schema <xs:attributeGroup name="InvoiceAttributes">
<xs:attribute name="InvoiceId" type="xs:number" use="required"/> <xs:attribute name="InvoiceNumber" type="xs:number" use="required"/> <xs:attribute name="TrackingNumber" type="xs:number" use="required"/> <xs:attribute name="OrderDate" type="xs:date" use="required"/> <xs:attribute name="ShipDate" type="xs:date" use="required"/> </xs:attributeGroup> .... <xs:element name="SalesData"> <xs:complexType> ... </xs:complexType <xs:key name="InvoiceKey"> <xs:selector xpath="Invoice"/> <xs:field xpath="InvoiceID"/> </xs:key>

13 Håndtering af fremmednøgler
I en relationel database bliver referencer beskrevet vha. fremmednøgler I XML kan fremmdnøgler mappes som: en understruktur under tabelelementet (parent –child) en reference (dvs. <keyref> hvis man bruger schema) Brug af parent-child er mest XML-agtig. Brug af referencer er mere fleksibel, men typisk vil referencer kun pege i en retning. Traversering vha. referencer er som regel langsommere end gennem parent-child relationer Min anbefaling: Brug kun referencer, når parent-child ikke er mulig. F.eks ved relationstabeller (mange – mange).

14 Navigation mellem tabeller (et eksempel)
Ved et system til månedsrapportering kunne referencerne retning se således ud.

15 Trin 6: Modeller opslagstabeller og fremmednøgler til disse
Definer en attribut i den tabel, hvor fremmednøglen er (her Invoice) Giv attributen det samme navn som opslagstabellen (ShipMethod), og gør den obligatorisk Gør den til en enumeration liste med værdierne fra opslagstabellen.

16 Trin 6: Schema <xs:simpleType name="ShipMethodType">
<xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="USPS"/> <xs:enumeration value="FedEx"/> <xs:enumeration value="UPS"/> </xs:restriction> </xs:simpleType> ...... <xs:attributeGroup name="InvoiceAttributes"> <xs:attribute name="InvoiceId" type="xs:number" use="required"/> <xs:attribute name="InvoiceNumber" type="xs:number" use="required"/> <xs:attribute name="TrackingNumber" type="xs:number" use="required"/> <xs:attribute name="OrderDate" type="xs:date" use="required"/> <xs:attribute name="ShipDate" type="xs:date" use="required"/> <xs:attribute name="ShipMethod" type="ShipMethodType" use="required"/> </xs:attributeGroup>.....

17 Trin 7: Modeller rodelementets indhold
Overvej hvilke elementer der skal være under rod elementet. Og hvor ofte elementet kan forekomme Men andre elementer kan komme til senere F.eks kan vi her sige at det dokumentet skal bruges til oftest relateres til Invoice og MonthlyTotal, som begge kan forekomme flere gange i vilkårlig rækkefølge

18 Trin 8: Schema <xs:element name="SalesData"> <xs:complexType mixed="false"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Invoice" minOccurs="0"> <xs:complexType> <xs:attributeGroup ref="InvoiceAttributes"/> </xs:complexType> </xs:element> <xs:element name="MonthlyTotal" minOccurs="0"> <xs:attributeGroup ref="MonthlyTotalAttributes"/> </xs:sequence> <xs:attribute name="Status" type="StatusType"/> Alle elementer, undtagen Invoice og MonthlyTotal er nu (midlertidigt) fjernet fra SalesData

19 Trin 8: Modeller relationer gennem understrukturer
1 – mange og 1 – 1 relationer, og hvis et child kun har en parent, kan modelleres gennem understrukturer. MonthlyPartTotal og MonthlyCustomerTotal kan være børn til MonthlyTotal LineItem kan være barn til Invoice

20 Trin 8: Schema Her er LineItem indført som en 1 – mange relation
<xs:element name="Invoice" minOccurs="0"> <xs:complexType> <xs:sequence maxOccurs="unbounded> <xs:element name="LineItem" maxOccurs="unbounded> <xs:attributeGroup ref="LineItemAttributes"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attributeGroup ref="InvoiceAttributes"/> Her er LineItem indført som en 1 – mange relation

21 Trin 9: Modeller relationer vha. nøgler
Mange – mange relationer og børn som ville få flere forældre (f.eks relationstabeller) kan ikke modelleres gennem understrukturer. Her må vi bruge key referencer

22 Trin 9: Schema Her er PartID fremmednøgle i MonthlyPartTotal
<xs:element name="MonthlyPartTotal"> <xs:complexType> <xs:attributeGroup ref="MonthlyPartTotalAttributes"/> </xs:complexType> <xs:keyref name="PartIDRef" refer="PartKey"> <xs:selector xpath="Part"/> <xs:field xpath="PartID"/> </xs:keyref> </xs:element> Her er PartID fremmednøgle i MonthlyPartTotal

23 Trin 10: Tilføj manglende elementer til rod elementet
Customer og Part er pt. ikke en del af xml-træet. De sættes derfor ind under SalesData (roden)

24 Trin 11: Fjern ubrugte ID keys
Det er kun PartID og CustomerID, der kom i brug. Derfor fjernes de andre 5 ID'er

25 Træet

26 Eksempel på en valid xml-fil
<?xml version="1.0"?> <n:SalesData xmlns:n=" xmlns:xsi=" xsi:schemaLocation=" D:\db2F04\SalesData.xsd" Status="NewVersion"> <Customer CustomerID="2" Name="BobSmith" Address="2AnyStreet" City="Anytown" State="AS" PostalCode="ANYCODE"/> <Invoice InvoiceNumber="1" TrackingNumber="1" OrderDate=" " ShipDate=" " ShipMethod="FedEx" CustomerID="2"> <LineItem Quantity="2" Price="5" PartID="2"/> </Invoice> <Part PartID="2" PartNumber="13" Name="Winkle" Color="Red" Size="10"/> <MonthlyTotal Month="January" Year="2000" VolumeShipped="2" PriceShipped="10"> <MonthlyCustomerTotal VolumeShipped="5" PriceShipped="25" CustomerID="2"/> <n:MonthlyPartTotal VolumeShipped="8" PriceShipped="40" PartID="2"/> </MonthlyTotal> </n:SalesData>