;;00// HHQQ ’’DDWWDDPPRRGGHHOOOOHHUULLQQJJgerp/IS0/dictaat/8_XMLenDatamodellering.pdf ·...

IS0-cursus: XML en Datamodellering

1

;;00/�/�HHQ�Q�''DDWWDDPPRRGGHHOOOOHHUULLQQJJ�� Inhoudsopgave:

8.0 Inleiding 8.1 XML: ‘eXtensible Markup Language’ 8.2 Functie en gebruik van DTD (Document Type Definition) 8.2.1 DTD-ELEMENT-definities 8.2.2 Externe DTS’s 8.2.3 DTD-ATTLIST-definities 8.2.4 DTD-ENTITY- en DTD-NOTATION-definities 8.3 XML-querytalen en XSL: eXtensible Stylesheet Language 8.4 Mapping van XML(/DTD) naar relationele tabel(structuur)

8.0 Inleiding De inhoud van documenten is vaak niet expliciet gestructureerd. Zo kun je op WWW weliswaar via trefwoorden zoeken, maar het is daarbij niet mogeli jk om aan te geven wat dat trefwoord in dat document voor functie moet hebben. Als voorbeeld geven we de gevonden NAW-gegevens: “Saskia van Tilburg woont in Amsterdam op de ‘Hof van Hoorn 27’ .” Zochten we op plaatsnaam ‘Tilburg’ , ‘Amsterdam’ of ‘Hoorn’? Duidt dat ‘Hoorn’ nu op een plaats, een adres of een materiaalsoort? Ook om via het Internet aangeleverde gegevens correct te kunnen verwerken, zul je vaak de structuur van die gegevens will en meegeven. XML kan daarbij helpen (XML staat voor ‘eXtensible Markup Language’ ). In XML zouden we de eerder gegeven zin als volgt kunnen modelleren:

<NAWgegeven> <Naam>Saskia van Tilburg</Naam> <Adres>Hof van Hoorn 27</Adres> <Plaats>Amsterdam</Plaats> </NAWgegeven>

Ook zonder verdere kennis van XML is nu van de woorden ‘Tilburg’ en ‘Hoorn’ de functie te zien. We citeren [1] :

“XML is rapidly establishing itself as the metagrammar for interorganizational communication around the Internet. It is becoming increasingly urgent that business analysts, systems analysts, and software developers be able to:

• model the information to be represented in XML • describe the relationships between the XML and the systems to process it.

Having done so, they must also be able to rapidly generate the boilerplate code associated with implementing these processes.”

Het is mogeli jk maar weinig zinvol om XML ‘geïsoleerd’ te gebruiken. Het krijgt pas zijn kracht als we voorafgaand aan XML-gebruik eerst een structuurdefinitie vastleggen via DTD (‘Document Type Definition’ ) en een check [laten] doen om te controleren of het XML-datadeel wel voldoet aan de via een DTD vastgelegde grammatica. Pas daarna kunnen we aan de slag om via speciale XML-querytaal relevante gegevens op te vragen en/of op een speciale manier te presenteren. Voor die presentatie is het gebruik van XSL (‘eXtensible Stylesheet Language’ ) mogeli jk. We behandelen deze onderwerpen in de volgorde:

1. XML (‘eXtensible Markup Language’ ) ; 2. DTD (‘Document Type Definition’ ) ; 3. XSL (‘eXtensible Stylesheet Language’ ) .

Veel informatie over XML en bijbehorende zaken (zoals DTD, XSL etc.) is te vinden via de Home page van XML 101 (URL: www.xml101.com ).

1 G. Booch, M. Christerson, M. Fuchs, J. Koistinen. UML for XML Schema Mapping Specification. 12/08/99.


2

8.1 XML: ‘eXtensible Markup L angu age’ XML wordt gebruikt om zowel documenten als gegevens te modelleren/structureren. Daarbij moeten we via een ‘open’- en een ‘sluit’ -tag aangeven wat onze XML-elementen zijn en hoe die genest zijn. We lezen [2]:

“An XML document is a tree-like structure. This tree consists of nodes that possess a hierarchical relationship to each other. To promote or demote a node is to raise or lower that node to a different level within that hierarchy.”

Schematisch zal een XML-model er steeds als volgt uitzien:

<root> <child> <subchild> </subchild> </child> </root>

Elk ‘kind’ -element kan weer een of meer ‘ sub-kind’ -elementen bevatten. Zo zou je in XML de gegevens bij een verenigingslid als volgt kunnen modelleren 3:

<LID> <Naam> <Voornaam>Jan</Voornaam> <Achternaam>Janssen</Achternaam> </Naam> <Adres>Annastraat 123</Adres> <Plaats>Nijmegen</Plaats> </LID>

Duideli jk is hier te zien, dat een LID-element bli jkbaar een ‘Naam’-, een ‘Adres’ - en een ‘Plaats’ -onderdeel kent, waarvan het ‘Naam’-deel beschouwd kan worden als een samengesteld kind-element met een voornaam- en een achternaam-subkind, terwijl ‘Adres’ en ‘Plaats’ als directe kind -elementen beschouwd kunnen worden. In ORM-terminologie zouden we dit XML-verenigingslid-model (ruwweg; we komen er later op terug waarom we hier geen details geven) op een van de hieronder getoonde manieren kunnen modelleren (hetzij via een ‘primary reference’ -combinatie van rollen, hetzij via een ‘nesting’):

Behalve met een nesting van (kind)elementen is het bij XML ook mogeli jk om met attributen te werken. Door sommige auteurs wordt het gebruik van attributen binnen XML sterk ontmoedigd. We vatten hier op een ‘vrije manier’ een aantal punten samen zoals verwoordt door Jan Egil Refsnes in zijn ‘XML Basics’ (via de home page van XML101 bereikbaar). Attributen worden vooral gebruikt voor het geven van ‘aanvullende informatie’ bij een bepaald element; meestal gaat het dan om gegevens die voor een menseli jke gebruiker niet zo interessant zijn, maar die wel nodig zijn voor het door een computer [efficiënt] laten verwerken van de gegevens. Denk hierbij aan zaken als identificerende lidnummers, codes e.d..

2 Help-functie van de XML-Notepad. 3 Laat je niet ontmoedigen door de overvloed aan ‘ tags’ (tussen ‘<’ en ‘>’) die blij kbaar nodig zijn voor het aanbrengen van XML-structuur; die zul je maar zelden zelf hoeven in te tikken. Daarvoor gebruik je normaal gesproken een tool, of je laat het XML-document genereren (bijvoorbeeld vanuit een database-systeem), of je laat door wat ‘Javascriptcode’ door een gebruiker ingevulde gegevens op een Web-pagina voorzien van XML-tags.

heeft

Lid

Naam

woont op

Adres

woont in

Plaats

met als

Voornaam

met als

Achternaam

P

"Naam"

heeft

Lid

woont op

Adres

woont in

Plaats

Voornaam

Achternaam

Pen


3

Eventuele attributen worden als volgt in de element-openings-tag opgenomen:

<Elementnaam attribuutnaam = “attribuutwaarde”> Let op de spatie tussen ‘Elementnaam’ en ‘attribuutnaam’ en op de [verplichte!] dubbele aanhalingstekens rond de “attribuutwaarde”. In ORM-terminologie is de ‘attribuutnaam’ soms te zien als de reference-code voor ‘Elementnaam’, maar kan hij ook vaak vergeleken worden meteen ORM-‘value-type’ (bij de bespreking van DTD -ATTLIST gaan we hier verder op in). Hierna is (rechts) een scherm weergegeven van de freeware XML-Notepad-editor, waarmee we het hierna (links) weergegeven XML-document hebben gemaakt (alle tags zijn gegenereerd!). We hebben in dit voorbeeld ervoor gekozen het ‘ lidnummer’ als attribuutwaarde bij ‘LID’ te nemen.

<LEDEN> <LID lidnummer="12345"> <Naam> <Voornaam>Jan</Voornaam> <Achternaam>Janssen</Achternaam> </Naam> <Adres>Annastraat 123</Adres> <Plaats>Nijmegen</Plaats> </LID> <LID lidnummer="13579"> <Naam> <Voornaam>Els</Voornaam> <Achternaam>Pietersen</Achternaam> </Naam> <Adres>Molenweg 33</Adres> <Plaats>Nijmegen</Plaats> </LID> </LEDEN>

Uit dit voorbeeld komt duidelij k het alti jd benodigde ‘root’-element naar voren (hier: onder de naam ‘LEDEN’). Let in het ‘ Structure’-deel van de figuur op het gebruik van de verschillende symbolen. Hiernaast tonen we hoe het XML-bestand getoond kan worden via een Web-browser als Internet Explorer 5. Het ziet er niet erg WWW-appetijteli jk uit, maar dat is ook niet de bedoeling van een kaal XML-bestand (later komt dit aspect bij XSL terug). In ieder geval is Internet Explorer 5 bli jkbaar in staat de XML-code correct te interpreteren. Voor elk (sub)element staat een ‘+’ of een ‘ -‘ -teken om aan te geven of de waarden en/of dieper geneste inhoud niet dan wel aangegeven is. Met een eenvoudige muisklik kun je ‘+’ en ‘ -‘ in elkaar laten overgaan. Getoond is, dat als een LID-element dichtgeklapt is, van dat LID alleen de attribuutwaarde getoond wordt. Als zo’n element méér attribuutwaarden heeft, worden attribuutnamen+waarden achter elkaar in de <LID>openingstag opgenomen; bijvoorbeeld: <LID lidnummer ="12345" sofinummer ="4334343433"> N.B. Indien we bij het aanmaken van het XML-document een fout tegen de XML-syntax maken, dan

zal bij het inladen van het document door de internet-browser een foutboodschap worden gegenereerd als bijvoorbeeld (met hier een tikfout in de ‘eind’-tag):

The XML page cannot be displayed Cannot view XML input using XSL style sheet. Pleas e correct the error and then click the Refresh button, or try again later. End tag 'Achternam' does not match the start tag 'Achternaam'. Line 5, Position 31 <Achternaam>Janssen</Achternam> ------------------------------ ^


4

N.B. Een free XML-parser is o.a. te downloaden van de MicroSoft-pagina (zie verderop in deze tekst). Met zo’n parser kunnen we vooraf controleren of de ingetikte XML -code aan de syntaxregels voldoet. Indien we (handmatig, met een eenvoudige editor zoals NotePad) in het hiervoor gegeven, met XML-tags gestructureerde LEDEN-gegevens toevoegen:

<LID kleur = "bruin" > <Wielen> 2 </Wielen> </LID>

en de inhoud van het bestand daarna inladen in een XML-geschikte Web-browser, dan worden de gegevens van dat vreemde derde ‘ lid’ zonder protest getoond. We kunnen via XML bli jkbaar wel een bestaande structuur van gegevens duideli jk aangeven, maar niet de gegevensstructuur binnen een UoD modelleren, noch te respecteren beperkingsregels afdwingen.

8.2 Functie en gebruik van DTD (Document Type Definition) Een DTD (Document Type Definition) bestaat uit een formele set van regels waaraan een XML-document moet voldoen. Het definieert de elementen die gebruikt mogen worden en legt vast waar ze in relatie tot elkaar gebruikt mogen worden. Je kunt een DTD beschouwen als een soort (tekstueel) conceptueel schema van de datastructuur binnen een UoD en de bijbehorende constraints. De modelleringsmogeli jkheden via DTD zijn echter veel beperkter dan die van het ons bekende ORM. Een DTD bevat een aantal declaraties, die allen aan de volgende opmaakstructuur: <! . . . . . . > moeten voldoen en waarin [onmiddelli jk na het uitroepteken] een van de volgende sleutelwoorden moet staan:

• ELEMENT (voor de al eerder bij het XML-deel besproken element-‘ tag’ definities) • ATTLIST (idem de attribuut definities) • ENTITY (nieuw: entiteit definities; zie verderop) • NOTATION (nieuw: datatype notation definities; zie verderop)

Deze declaraties worden gegroepeerd en geplaatst binnen een document type declaration die de volgende structuur heeft:

<!DOCTYPE doctypeNAAM [ <!ELEMENT doctypeNAAM ( . . en hier volgt dan een 1e deel van de DTD -definitie . .) > <! . . . . en verder . . . > <! . . . . en verder . . . >

] > N.B. Een XML-document hoeft voor de specificatie van zijn structuur niet per se een bijbehorende

DTD te hebben. Toch wordt het opstellen van zo’n DTD vaak aanbevolen om zekerheid af te dwingen over het naleven van de gedefinieerde structuur. Een speciale DTD/XML-parser kan worden gebruikt om eerst de DTD te lezen en daarna te bepalen of het XML-document wel aan dat DTD-sjabloon voldoet.

Een geschikte DTD/XML-parser (met een boel Javascript-code) is onder de naam ‘XML Validator’ via de volgende URL: http://msdn.microsoft.com/downloads/samples/internet/xml/xml_validator bij MicroSoft te downloaden (met bestandsnaam: validate_js.htm ) of van daar af te activeren. 8.2.1 DTD-ELEMENT-definities ELEMENTs : dit zijn de primaire eenheden om XML-documenten mee op te bouwen. De ‘ tag’ definities via ELEMENT kunnen ‘nonterminal’ of ‘ terminal’ zijn, dat wil zeggen: er kan mee aangegeven worden, dat een bepaald ELEMENT op zijn beurt verder opgebouwd is uit een of meer andere ELEMENTs, maar ook, dat zo’n verdere opsplitsing niet gebeurt. Dat laatste geval (dus bij ‘ terminal’) wordt meestal gebruikt om het gegevenstype ‘PCDATA’ (lees: ‘ parsable character data’, een [getal]string e.d., waarin opmaaktekens als ‘<’,’>’, ‘ ”’, ‘& ’ e.d. als (html -) markup zullen worden geïnterpreteerd) van dat ELEMENT aan te geven.

5

Voor het door ons eerder besproken XML-voorbeeld met een ‘LEDEN’-document geven we als mogelijk/voorlopig DTD (en daarnaast een zo veel mogelijk vergelijkbaar ORM-schema):

<!DOCTYPE LEDEN [ <!ELEMENT LEDEN ( LID+ ) > <!ELEMENT LID ( Naam, Adres, Plaats ) > <!ELEMENT Naam ( Voornaam, Achternaam ) > <!ELEMENT Voornaam ( #PCDATA ) > <!ELEMENT Achternaam ( #PCDATA ) > <!ELEMENT Adres ( #PCDATA ) > <!ELEMENT Plaats ( #PCDATA ) >

]> De komma’s in het DTD geven tevens aan, dat de daarbij gebruikte volgorde moet worden aangehouden. Een voorbeeld van een ‘nonterminal’ ELEMENT-declaratie hierin is <!ELEMENT Lid (Naam, Adres, Plaats)>. Een voorbeeld van een ‘terminal’ ELEMENT-declaratie is: <!ELEMENT Plaats ( #PCDATA)>. (N.B. Naast #PCDATA komen ook de aanduidingen #CDATA, #EMPTY en #ANY voor.) We hebben de ‘nonterminal’ elementen in het ORM -schema als ‘ORM-entiteiten’ aangegeven en de ‘terminal’ als ‘ORM -value-types’. Via het ‘|’-symbool kunnen we keuzes aangeven ( <!ELEMENT Dessert ( ijs | vrucht ) > ). Indien bepaalde onderdelen vaker kunnen voorkomen en/of optioneel zijn, kunnen we als occurrence indicator de volgende symbolen gebruiken:

Symbool Beschrijving + Een [verplicht!] element kan een of meer keren voorkomen (>=1) * Een [optioneel!] element kan nul of meer keren voorkomen (>=0) ? Een [optioneel!] element kan hoogstens een keer voorkomen (0, 1)

Voor een XML-voorbeeld met een [of een hele verzameling] boek[en], geven we de volgende DTD:

<!DOCTYPE BOEK [ <!ELEMENT BOEK ( Titel, Auteur+, Hoofdstuk+ )> <!ELEMENT Hoofdstuk ( Titel, Inhoud )> <!ELEMENT Inhoud ( Paragraaf+ )> <!ELEMENT Titel (#PCDATA)> <!ELEMENT Auteur (#PCDATA)> <!ELEMENT Paragraaf (#PCDATA)>

]> Een volgens deze DTD mogelijk geldig XML-document is:

 <BOEK> <Titel>Over XML</Titel> <Auteur>Jansen, Jan</Auteur> <Auteur>Pietersen, Els</Auteur> <Hoofdstuk> <Titel>1. Inleiding</Titel> <Inhoud> <Paragraaf>Hier staat de inhoud van de eerste paragraaf</Paragraaf> <Paragraaf>En hier staat de inhoud van de tweede paragraaf</Paragraaf> </Inhoud> </Hoofdstuk> <Hoofdstuk> <Titel>2. Titel van het tweede hoofdstuk</Titel> <Inhoud> <Paragraaf>Inhoud paragraaf 2.1</Paragraaf> <Paragraaf>Inhoud paragraaf 2.2</Paragraaf> <Paragraaf>Inhoud paragraaf 2.3</Paragraaf> </Inhoud> </Hoofdstuk> </BOEK>

In dit voorbeeld, heeft het betreffende boek naast een titel ook de namen van 2 auteurs en vervolgens 2 hoofdstukken (elk bestaande uit een (hoofdstuk)titel + een uit 2 en 3 paragrafen opgebouwde ‘inhoud’).

heeft / van

Lid

woont op

Adres

woont in

Plaats

Voornaam

Achternaam

Naammet / van

met / van


6

We geven hiernaast een ruw, mogeli jk niet geheel correct voorbeeld van een vergeli jkbaar ORM-schema dat dezelfde structuur beschrijft. Met ‘ * ’ is aangegeven, dat de daar aangegeven uniciteitsregel niet hoeft te kloppen. Zo wordt uit het DTD niet mogeli jk of een auteur al dan niet meerdere boeken kan hebben (mee-) geschreven. Misschien zou een bepaald hoofdstuk wel in meerdere boeken kunnen voorkomen e.d.. Ook totaliteitsregels zijn door het DTD niet geheel gedefinieerd; mag bijvoorbeeld een ‘hoofdstuk’ voorkomen, zonder dat het tot een ‘boek’ behoort? Ook hier (b)li jkt ORM veel krachtigere modelleringsmogelijkheden te bezitten dan DTD. Het bovenstaande is geheel in overeenstemming met het eerder genoemde ‘ tree-like’ karakter van XML/DTD: in de richting van de ‘wortel’ naar de terminal -bladeren toe, kunnen via een DTD een aantal soorten constraints (zoals enkelvoudige uniciteiten en totaliteiten) ‘ redeli jk’ worden beschreven. De meeste gebruikte (‘normale’, tree-based) parsers controleren inderdaad alleen in deze richting van ‘wortel’ naar bladeren. 8.2.2 Externe DTS’s Omdat DTDs meestal als een ‘standaard’ voor meerdere XML -documenten worden gemaakt, bestaat ook de mogeli jkheid zo’n DTD -standaard in een apart bestand op te slaan en er vanuit relevante [XML-] documenten als volgt naar te verwijzen (let op het gebruik van het woord SYSTEM):

<!DOCTYPE LEDEN SYSTEM "D:/IS0/XML/Leden.DTD" > [ <! . . . met hier eventuele aanvullende definities voor dit ene document . . > <! . . . . . . . > ] >

N.B. Er moet dan géén ‘<!DOCTYPE LEDEN . . . ’ -regel meer in dat aparte DTD-bestand staan. 8.2.3 DTD-ATTL IST-definities ATTLIST : via attribuut definities kunnen we aangeven dat een ELEMENT een of meer attributen kan hebben, die echter in een andere volgorde kunnen voorkomen dan in die ATTLIST staat (N.B. een ELEMENT hoeft niet per se attributen te hebben!). De syntax voor een ATTLIST-declaratie is: <!ATTLIST element-naam attribuut-naam attribuut-type ‘default-value’ > Bij het eerder gegeven voorbeeld <!ELEMENT BOEK (Titel, Auteur+, Hoofdstuk+ )> zou je als attribuutli jst kunnen hebben: <!ATTLIST BOEK isbnnr CDATA #REQUIRED > . Attributen kunnen vereist (#REQUIRED ), optioneel (#IMPLIED ) of ‘ vast’ ( #FIXED) zijn (de z.g. attribute defaults). Een van deze drie mogeli jke default-values moet ingevuld worden. Let er op, dat deze attribute defaults wél voorafgegaan worden door een ‘#’, terwijl de eraan voorafgaande type-aanduiding (hier: CDATA) géén ‘#’ heeft. Let er ook op, dat bij definiëring van een ATTLIST onmiddelli jk nà het woord ATTLIST steeds eerst de naam van het XML-element genoemd wordt en pas daarna de naam van het ‘bijbehorende’ attribuut. Daarnaast bestaan een viertal z.g. ‘ tokenized attribute types’ ( ID, IDREF, ENTITY en NMTOKEN ), waarmee de opsteller van de DTD in staat is de toegestane waarden voor een bepaald attribuut te bewaken. ID moet een unieke identifier voor het bewuste ELEMENT zijn. Attributen van het type IDREF verwijzen naar een ELEMENT met een ID-attribuut; elke IDREF-waarde moet naar een gelijke ID waarde in het XML-document verwijzen. Door gebruik te maken van een ID-attribuut kunnen we dus [als tenminste de XML-data terdege geparsed/gecontroleerd worden op naleving van de eisen van het betreffende DTD], een -in NIAM/FCO-IM/ORM-terminologie- uniciteitsregel afdwingen. Via een IDREF-attribuut is een soort foreign key-verwijzing te simuleren, zij het dat zowel de ID- als de ernaar verwijzende IDREF-attribuutwaarde in eenzelfde XML-document moeten voorkomen.

heeft / schreef

Boek

Auteur

heeft

Titel

heeft

Hoofdstuk

heeft

heeft

Inhoud

met

Paragraaf

*

*

*

7

Uit het boek ‘XML, How to program’ van Deitel, Deitel, Nieto, Lin & Sadhu halen we het volgende voorbeeld met betrekking tot het gebruik van ID/IDREF:

<?xml version = "1.0"?>  <!DOCTYPE bookstore [ <!ELEMENT bookstore ( shipping+, book+ )> <!ELEMENT shipping ( duration )> <!ATTLIST shipping shipID ID #REQUIRED> <!ELEMENT book ( #PCDATA ) > <!ATTLIST book shippedBy IDREF #IMPLIED> <!ELEMENT duration ( #PCDATA ) > ] > <bookstore> <shipping shipID = "s1"> <duration>2 to 4 days</duration> </shipping> <shipping shipID = "s2"> <duration>1 day</duration> </shipping> <book shippedBy = "s2"> Java How to Program 3rd edition. </book> <book shippedBy = "s2"> C How to Program 3rd edition. </book> <book shippedBy = "s1"> C++ How to Program 3rd edition. </book> </bookstore>

In het rechts aangegeven ORM-schema, waarbij geprobeerd is een ORM-model te maken van de door het DTD beschreven situatie, zijn weer een aantal zaken onzeker, zoals: “Kan een levering ook voor meerdere boekwinkels tegelijk zijn?”. Ook is het vreemd dat ‘Boek’ van een value -type lijkt te zijn. Als we voorgaande DTD/XML-tekst [via Copy/Paste] invoeren in MicroSofts ‘XML Validator’ en we veranderen bij het laatste book-element de shippedBy-attribuutwaarde in “s5”, dan verschijnt de melding:

The attribute ' shippedBy' references the ID ' s5' which is not defined anywhere in the document. Line: 31, Position: 28, ErrorCode: 0xC00CE00E

Ook mogelijk bij het gebruik van attributen zijn de z.g. ‘enumerated attribute types’, waarbij een lijst van mogelijke waarden aangegeven wordt, die een attribuut mag hebben. Dat kan iets zijn van de vorm: <!ATTLIST person gender ( M | F ) “F” #REQUIRED> waarbij “F” als default-waarde is aangegeven. Via dergelijke ‘enumerated attribute types’ zijn de voor ons van ORM bekende ‘waarderegels’ aan te geven en af te dwingen. 8.2.4 DTD-ENTITY- en DTD-NOTATION-definities Over betekenis en gebruik van deze twee sleutelwoorden willen we hier weinig vermelden. Een ‘entity’ is in XML -terminologie eigenlijk een ‘variabele’ waar een waarde aan toegekend kan worden en waarvan de waarde door referentie via ‘&’+entity-naam+’;’ opgevraagd kan worden. Ook in HTML hebben we dat al ongemerkt toegepast; omdat in HTML opmaaktekens als ‘>’ niet rechtstreeks kunnen worden afgedrukt, zijn die tekens impliciet in entities/variabelen opgeslagen. Daarom kunnen we via HTML dat ‘>’-teken toch op het beeldscherm krijgen via de referentie > . Als voorbeeld van hetgebruik van een ENTITY-definitie geven we hier:

<!DOCTYPE EntityProbeersel [ <!ELEMENT EntityProbeersel ( #PCDATA ) > <!ENTITY variabelenaam "haar hond Tarzan" > ]>

krijgt of kreeg

Boekwinkel

Levering(ShipID)

krijgt of kreeg

Boek

met

Levertijd

geleverd bij

*


8

<EntityProbeersel> Els en &variabelenaam; met nog wat! </EntityProbeersel>

Als we dit bestand in Internet Explorer 5 laden, dan zien we dat de substitutie heeft plaatsgevonden:

<!DOCTYPE EntityProbeersel (View Source for full doctype...)> <EntityProbeersel>Els en haar hond Tarzan met nog wat!</EntityProbeersel>

Door gebruik te maken van de ‘SYSTEM’-optie is het ook mogeli jk de waarde voor een ENTITY uit een ander bestand te laten ophalen. Dat kan via een constructie als:

<!ENTITY variabelenaam SYSTEM "D:/is0/xml/Varwaarde.txt" > Op het gebruik van <!NOTATION ... > gaan we hier niet in. N.B. een (krachtiger) alternatief voor DTD’s zijn de z.g. XML Schema’s (o.a. afkomstig van en

gepropageerd/ondersteund door Microsoft) waarbij het o.a. ook mogelij k is om het vereiste gegevenstype (int, date, char, string e.d.) aan te geven! ! Mede door hun ‘ tekstuele aard’ zijn deze schema’s al snel zo complex, dat je ze eigenlij k alleen door een tool kunt laten genereren.

8.3 XML-querytalen en XSL: eXtensible Stylesheet Language Tot nu toe hebben we ons gericht op het via XML aangeven van de structuur van gegevens en het via DTD definiëren van hoe die structuur kan en moet zijn. Zoals we al eerder aangaven is de bedoeling van dat structuren, dat expliciet aangegeven wordt wat de betekenis van bepaalde gegevens is. Herinner je uit de inleiding dat voorbeeld van: “Saskia van Tilburg woont in Amsterdam op de ‘Hof van Hoorn 27’.” en dat we ons daarbij afvroeg en wat de functie van de verschijnende plaatsnamen dan wel was. Via de aangebrachte XML-tags moet het nu ook mogeli jk zijn om in een XML-document gewenste gegevens te selecteren. Vaak worden op het Internet via XML gestructureerde gegevens (b.v. van een bestelli ng via WWW) aangeleverd en vervolgens door een speciale applicatie geanalyseerd en ingebracht in een ‘grote’ relationele database. Voor het kunnen bewerken van XML-data zou een standaard XML-querytaal (zoals SQL voor relationele databasesystemen) erg nuttig zijn. Zo’n defacto standaard bestaat echter [nog] niet. W3C is bezig met het ontwikkelen van een specificatie voor XQuery (de voorziene off iciële XML-querytaal). 4 Een aantal bestaande XML-querytalen zijn: XML-QL (van AT&T Labs), XQL (van Microsoft), Lorel, UnQL, Quilt en YaTL. Een aantal interessante mogelij kheden voor het selecteren van XML-data zijn reeds aanwezig in XSL [eXtensible Stylesheet Language]. We tonen hierna een voorbeeld van het gebruik van XSL. We gaan daarbij uit van de eerder besproken, via XML gestructureerde ‘LEDEN’-verzameling. Omdat we van plan zijn ze via een Web-browser op een bepaalde manier te laten zien, vermelden we op regel 2 van het volgende bestand, volgens welk ‘ .XSL’ -bestand [XSL: eXtensible Stylesheet Language] ze getoond moeten worden:

<?xml version="1.0" ?> <?xml:stylesheet type="text/xsl" href="Leden.xsl" ?> <LEDEN> <LID> <Naam> <Voornaam>Jan</Voornaam> <Achternaam>Janssen</Achternaam> </Naam> <Adres>Annastraat 123</Adres> <Plaats>Nijmegen</Plaats> </LID> <LID>

4 Zie: Quering XML-data door Ikram Abasov, (KUN-student) 30/03/2001


9

<Naam> <Voornaam>Els</Voornaam> <Achternaam>Pietersen</Achternaam> </Naam> <Adres>Molenweg 33</Adres> <Plaats>Nijmegen</Plaats> </LID> </LEDEN>

We geven nu de inhoud van de genoemde Leden.xsl-stylesheet:

<?xml version="1.0" ?> <html xmlns:xsl="http://www.w3.org/TR/WD-xsl" > <H3>Ledenoverzicht</H3> <body> <xsl:for-each select="LEDEN/LID">

<h4> <xsl:value-of select = "Naam/Voornaam" /> <xsl:value-of select = "Naam/Achternaam" /> </h4> <I> <xsl:value-of select ="Adres" /> <xsl:value-of select ="Plaats" /> </I>

</xsl:for-each> </body> </html>

N.B. waar de 2e regel in dit XLS-bestand voor dient, is mij (GP) een raadsel (functioneert ook zonder internet-verbinding!) Via XSL-selectie-opdrachten als <xsl:value-of select = “. . . .” /> is het mogelijk om de gewenste attributen te selecteren en de hen toebedachte behandeling te geven. Via de XSL-iterator-functie <xsl:for-each select = “. . . .” /> is het mogelijk om door het gehele ‘gegevensbestand’ heen te gaan en bij elk lid op de gewenste wijze de genoemde attribuut -waarden te tonen. Indien we het Leden.xml-bestand nu in een Web-browser (die XML aankan!) laden, krijgen we voor dit voorbeeld het volgende overzicht:

Ledenoverzicht

Jan Janssen

Annastraat 123 Nijmegen

Els Pietersen

Molenweg 33 Nijmegen Bij gebruik van een ander .XSL-bestand kan dit overzicht op een totaal andere manier verschijnen.

8.4 Mapping van XML(/DTD) naar relationele tabel(structuur) Voorlopige versie: De voor ons gemakkelijkste wijze om een XML/DTD gegevensstructuur te ‘mappen’ naar een relationele tabelstructuur, is die via ORM. Maak eerst een ‘zo goed mogelijk’ (de reden daarvoor hebben we hiervoor gezien) met de XML/DTD-structuur corresponderend ORM-schema en bepaal daaruit de benodigde relationele database-structuur. Er wordt her en der voor deze mapping aan directe transformatie-algoritmen gewerkt, maar die werken nog niet optimaal. Zie als voorbeeld Mapping DTDs to Databases, by Ronald Bourret, May 09, 2001 via URL: http://www.xml.com/pub/a/2001/05/09/dtdtodbs.html


10

Met daarin o.a. To start, notice that there is an obvious mapping between the following XML document, object, and row in a table:

Similarly, there is an obvious mapping between the following element type definition, class, and table schema:

Bij het gebruik van complexere DTD’s (met ATTLIST e.d.) worden deze transformaties eveneens complexer zoals bijvoorbeeld:

Waarbij in de relationele tabellen de uitgang ‘_pk’ staat voor primary key en de uitgang ‘_fk’ voor foreign key. Er wordt ook een algoritme besproken voor het omzetten van XML/DTD naar relationele database-schema’s, ofschoon bij de hierna geschetste transformatie als opmerking wordt geplaatst:

A generated schema isn' t going to be the same as a human would have written. In addition to naming problems (for example, a person might have called the tables Orders, Items, and Parts), the generation algorithm was unable to determine that the relationship between Items and Parts was many-to-one. The algorithm was also unable to recognize that OrderNum and PartNum could be used as primary keys.

Als we ‘onze eigen aanpak’ (via het eerst opstellen van een zo goed mogeli jk overeenkomstig ORM -schema en het vervolgens mappen naar een relationele structuur) loslaten op het voorbeeld van de laatste hiervoor gegeven transformatie, dan komen we eigenli jk tot een andere uitkomst. Het meest voor de hand liggende ORM-schema is hiernaast weergegeven. A heeft verplichte rollen met B en C, maar de rol naar D is optioneel (immers: een ‘ implied’ attribuut). Mapping daarvan naar een relationele structuur levert één enkele tabel op, met ‘D’ als optionele kolom (hetgeen dus afwijkend is van de door henzelf gevonden structuur met 2 tabellen, waarbij de waarde van ‘d’ alleen via een foreign key gekoppeld mag zijn aan een waarde van ‘a’ die ook in de andere tabel voorkomt). Ons resultaat li jkt dus heel wat beter en op een elegantere wijze verkregen.

XML Objects Tables ============= ============ =============== Table A <A> object A { ------- <B>bbb</B> B = "bbb" B C D <C>ccc</C> <=> C = "ccc" <=> --- --- --- <D>ddd</D> D = "ddd" ... ... ... </A> } bbb ccc ddd ... ... ...

DTD Classes Table Schema ====================== ============ ========================== class A { CREATE TABLE A String B; B VARCHAR(10) NOT NULL, <!ELEMENT A (B, C, D)> <=> String C; <=> C VARCHAR(10) NOT NULL, String D; D VARCHAR(10) NOT NULL } )

DTD Classes Tables ======================== ============== ============== <!ELEMENT A (B, C)> class A { Table A <!ATTLIST A String b; Column a_pk D IDREFS #IMPLIED> ==> String c; ==> Column b <!ELEMENT B (#PCDATA)> String[] d; Column c <!ELEMENT C (#PCDATA)> } Table D Column a_fk Column d

met

A

B

met

C

met

D

;;00// HHQQ ’’DDWWDDPPRRGGHHOOOOHHUULLQQJJgerp/IS0/dictaat/8_XMLenDatamodellering.pdf ·...

Documents

Transcript of ;;00// HHQQ ’’DDWWDDPPRRGGHHOOOOHHUULLQQJJgerp/IS0/dictaat/8_XMLenDatamodellering.pdf ·...