XML and databases 246

A three-tier model of application development: Tier 1: a Web browser or a client application Tier 2: a Web server or an application server Tier 3: a database system or a transaction system Tier 1 HTML/ Tier 2 XML e.g., a client application e.g., application running in Tomcat e.g., a JDBC query result set Tier 3 e.g., RDBMS Java provides a common API called Database Connectivity (JDBC) for accessing a data base system. It provides a highlevel interface for database interactions. 247 Sekä internet- että intranetympäristöissä hajautettujen järjestelmien toteutuksessa on yleisesti käytetty kolmikerrosmallia, joka koostuu seuraavista toiminnallisista yksiköistä: Kerros 1: selain, joka toimiin käyttöliittymänä Kerros 2: Web-palvelimella oleva sovellusohjelma Kerros 3: tietokanta (tai esim. transaktiopalvelut) Vastaavaa mallia käytetään myös Web-palvelukonseptissa erityisesti silloin kun sovellukset (Webpalvelut) käyttävät erillistä tietokantaa. Tällöin asiakasohjelma voi Web-selaimen ohella edustaa ensimmäistä kerrosta. Web-palvelimella sijaitseva palvelu edustaa toista kerrosta. Tietokanta puolestaan edustaa kolmatta kerrosta kuten edellä esitetyssä mallissakin. Tietokanta itsessäänkin voi tarjota Web-palvelun toiminnallisuuden. Tietokantainteraktioiden toteuttamiseksi (esim. kyselyt) on tarjolla korkean tason rajapintoja. Esimerkiksi Java tarjoaa Database Connectivity (JDBC) APIn tähän tarkoitukseen. JDBC on osana (standardi-) JDK:ta. Se tarjoaa esimerkiksi rajapinnan SQL-kyselyille. Useat tietokannat tarjoavat JDBC-ajureita, jotka toteuttavat ko. API:n. Nämä ajurit muuttavat JDBC-operaatiot natiivioperaatioiksi, mutta eivät kaikissa tapauksissa toteuta kaikkia JDBC:n piirteitä. Tällä kurssilla ei käsitellä JDBC API tai muutakaan vastaavaa APIa vaan keskitytään lähinnä siihen problematiikkaan, joka koskee XML-pohjaisen tiedon tallettamista tietokantaan. Aiheesta voi opiskella lisää esim. osoitteessa http://www.rpbourret.com/xml/xmlanddatabases.htm, josta löytyy kattava ja päivitetty selvitys aiheeseen. Tätä lähdettä on käytetty hyväksi myös tätä kurssimateriaalia (luku XML and databases ) kehitettäessä.

Storing XML-based data in databases 1. Storing an XML document as a structured document an XML (or SGML) native database no need to design mappings between an XML document and tables storing, retrieval, and quering using standard methods XPath and XQuery 2. Storing an XML document as a DOM tree object Object-Oriented Database (OODB) systems can be used no need to design mappings between an XML document and tables pointing using XPath with possible extensions 248 Seuraavaksi käsitellään kolmea tietokantatyyppiä XML-pohjaisen tiedon tallentamisen kannalta: natiivi XML-tietokanta, oliotietokanta ja relaatiotietokanta. Talletettaessa natiiviin XML-tietokantaan, XML-dokumentin sisällölle ei tarvitse tehdä muutoksia. Kyselyitä ko. tietokannasta voidaan tehdä esimerkiksi XML-pohjaisen tiedon käsittelyyn tarkoitetuilla kielillä kuten XPath. XML-tietokannasta voidaan tehdä kyselyitä myös käyttäen template-pohjaisia (template on XML-dokumentti, joka sisältää kyselyn) kyselykieliä kuten XQuery. Tällaiset kyselykielet ovat usein hyvin joustavia. Talletettaessa XML-dokumentin tieto oliotietokantaan ei sille myöskään tarvitse muutoksia. Tällöin DOM-puu voidaan tallettaa sellaisenaan. Tietoalkioihin osoittaminen tapahtuu tässäkin XPath-kielen avulla.

Storing XML-based data in databases 3. Storing an XML document as a set of relational tables in a relational database management system (RDBMS) mappings needed between an XML document and tables (XML is semi-structured data) retrieving data from a RDBMS an application-specific query language XPath + possible extensions XPath expressions can also be converted to SQL queries XQuery Structured Query Language (SQL) 249 Kolmas tapa on tallettaa XML-pohjainen tieto relaatiotietokantaan. Jatkossa keskitymme tähän vaihtoehtoon. Tällöin XML-dokumentin sisältö (ja joissain tapauksissa osa merkkauksesta) talletetaan tavalla tai toisella - relaatiotietokannan tauluihin. Tähän liittyvät ongelmat (joihin palaamme myöhemmin) johtuvat periaatteessa siitä, että XML on osittain rakenteista (semi-structured) tietoa. Osittain rakenteisella tiedolla tarkoitetaan tässä karkeasti ottaen tietoa, jolle täsmällisen ja tarkan skeeman määrittäminen on vaikeaa tai mahdotonta. XML esimerkiksi sallii iteroinnin mielivaltaiselle määrälle elementtejä (mikäli niin halutaan määritellä). Tällainen joustavuus tekee joissain tapauksissa vaikeaksi kuvata XML-pohjaista tietoa relaatiotietokannan taulujen avulla (tai päinvastoin). Lisäksi elementtien, jotka sisältävät sekä merkkidataa että elementtejä (mixed content), sisältö on usein hankalaa tallettaa relaatiotietokannan tauluihin. Kyselyitä relaatiotietokannasta voidaan tehdä esimerkiksi JDBC:n kaltaisella kyselykielellä (JDBC on toki muutakin kuin kyselykieli). Joissain tapauksissa voidaan käyttää myös XPath-kieltä. Sen ilmaisut voidaan konvertoida myös SQL-kyselyiksi. Tällöin voidaan usein myös käyttää XPath-ilmaisuihin perustuvaa XQuery-kieltä.

Choosing a DBMS Storing document-centric information data is of coarse granuality and has irregular structure the smallest data item can be an element with mixed content or even the whole document itself the order of elements is typically important examples: books, emails,.. OODBs and XML databases could be used 250 Tietokantaratkaisua valittaessa yksi peruskysymys koskee XML-muotoisen informaation luonnetta. Tällöin tehdään usein ero dokumenttikeskeisen ja datakeskeisen informaation välillä. Dokumenttikeskeinen tieto on usein rakenteeltaan epäsäännöllistä ja talletettu tietosisältö on karkeajakoista. Esimerkiksi kirjaa tai artikkelia koskeva tieto voidaan tallettaa hyvinkin vähäisellä merkkauksella. Tällöin esimerkiksi lukujen kappaleet voivat kokonaisuudessaan olla yhden elementin sisällä (<paragraph> </paragraph>). Toinen luonteenomainen piirre dokumenttikeskeiselle tiedolle on elementtien järjestyksen tärkeys. Tämä pätee esimerkiksi edellä mainittuun esimerkkiin. Dokumenttikeskeistä tietoa talletettaessa oliotietokanta tai natiivi XML-tietokanta on yleensä paras ratkaisu. Tällöin DOM-puu voidaan tallettaa sellaisenaan säilyttäen elementtejä koskeva järjestys.

Choosing a DBMS (cont d) Storing data-centric information data is of fine graduality and has a regular structure the smallest data item can be a PCDATA element, CDATA attribute, or CDATA block only few or no mixed content elements the order among sibling element is often insignificant examples: time tables, purchase orders,... RDBMSs could be used a middleware is needed (mappings) between RDBMSs and XML documents 251 Datakeskeinen tieto on puolestaan yleensä hienojakoista, jolloin myös merkkaus on yksityiskohtaisempaa. Lisäksi tieto on rakenteeltaan säännöllistä. Esimerkiksi tilaustiedot voivat olla talletettu XML-dokumenttiin datakeskeisesti. Tällöin jokaisella yksittäisellä tilauksella on sama rakenne. Käytännössä tiedon pienen yksikkö on merkkijonon sisältävä elementti (PCDATA), attribuutti (CDATA) tai CDATA-lohko. Datakeskeisessä dokumentissa tulisi olla mahdollisimman vähän osittain merkattua tietoa (mixed content), jossa siis elementin sisältä on osin merkkijonopohjaista (ja rakenteetonta) ja osin rakenteista. Toisin kuin dokumenttikeskeisen tiedon tapauksessa, datakeskeisen dokumentin sisarelementtien järjestyksellä ei ole merkitystä. Esimerkiksi tilaustiedot sisältävä XML-dokumentti sisältää joukon tilaustietoja, jotka on talletettu dokumenttiin mielivaltaisessa järjestyksessä tai joiden järjestyksellä ei tietosisällön kannalta ole merkitystä. Datakeskeinen tieto voidaan tallettaa esimerkiksi relaatiotietokantaan. Vaikka dokumentti olisikin hyvin ja tarkkaan merkattu, ei sisällön tallettaminen tietokannan tauluihin ole yksinkertaista. Näihin ongelmiin paneudumme seuraavaksi. Ero datakeskeisen ja dokumenttikeskeisen tietomallin välillä ei ole aina selkeä. Esimerkiksi kirja voi sisältää metadataa (kirjoittaja, julkaisija, julkaisuvuosi, kustantaja jne.), joka on datakeskeistä, vaikka dokumentti on muuten dokumenttikeskeinen. Lisäksi kannattaa muistaa, että tietty tieto voidaan merkata monella eri tavalla. Käytetyllä merkkauksella on siis myös suuri merkitys sille kuinka dokumentti- tai datakeskeistä merkattu tieto on.

Problematic types All data in an XML document is text (i.e., no real types ) conversions of data from text to other types (used in databases) is needed...and vice versa Dates many different formats Binary data many data transfer (XML<->database) products do not support binary data strict rules used in relational databases for managing binary data might cause problems 252 Yksi syy käytännön ongelmiin XML-dokumentin tiedon tallettamiseksi relaatiotietokannan tauluihin liittyy käytettyihin tyyppeihin: XML-dokumentti sisältää tekstiä (silloinkin kun teksti esittää toista tietotyyppiä) eikä siinä käytetä samoja tyyppejä kuin tietokannassa. Mikäli kuitenkin XMLdokumentin kielioppi on määritelty XML Schman avulla ja ko. skeema on käytettävissä, on tilanne huomattavasti helpompi, koska ainakin perustyypit on käytettävissä. Myös päivämäärien esittämiselle on olemassa monia eri tapoja, edellyttäen myös konversioita. Lisäksi binääridata saattaa aiheuttaa ongelmia. Suurin ongelma liittyy siihen, että useat ohjelmat, joita käytetään konvertoimaan tietoa XML-dokumenttien ja relaatiotietokannan välillä, eivät tue binääridatan esittämistä. Lisäksi tietokannassa voi olla käytössä sellaisia sääntöjä binääridatan esittämiseksi, jotka saattavat aiheuttaa ongelmia. XML-dokumenteissa esimerkiksi yleinen (mutta ei ainoa) tapa tallettaa binääridataa on base64 (MIME koodaus, jolla binääridata esitetään US-ASCIIn alijoukkona [0-9a-zA-Z+/]).

Problematic types (cont d) XML documents use Unicode while many databases offer limited (if any) support for Unicode Null data null/zero values vs. data that does not exist in a database, the non-existing data is marked as null data, destinguishing from zero value data XML supports null data through optional elements and attributes if the value of an optional element/attribute is null, it is often just left out Processing instructions and comments not actual data can appear almost anywhere in the XML document often ignored in data transfer XML markup 253 XML-dokumentit tukevat unicode standardia, kuten aiemmin on todettu. Vaikka se onkin varsin kätevää tiedonsiirronkannalta yleisesti, saattaa se aiheuttaa ongelmia talletettaessa tietoa tietokantaan. Tämä johtuu siitä, että tietokannat saattavat tarjota vain rajoitettua tukea unicoden käytölle. Lisäksi ne saattavat vaatia erityistä konfigurointia, jotta ASCII merkistöön kuulumattomia merkkejä voitaisiin käsitellä. Yksi suurista ongelmista koskee pois jätetyn tiedon ja arvoltaan tyhjän (tai nolla) tiedon erottelua. Pois jätetty tieto merkitään tietokannassa usein eksplisiittisesti (ns. null data ). Arvoltaan 0 (numerot) tai pituudeltaan (string) 0 oleva tieto tarkoittaa eri asiaa ja merkitään myös eri tavoin. XML:ssä voidaan myös jokin tieto jättää pois käyttäen optionaalisia elementtejä tai attribuutteja. Jos optionaalisen elementin arvo on nolla, se kuitenkin usein jätetään pois XML-dokumentista. Nämä erilaiset tavat käsitellä arvoltaan 0 olevaa tietoa ja toisaalta tyhjää/pois jätettyä tietoa aiheuttaa luonnollisesti ongelmia.

XML:n prosessointiohjeet eivät ole osa varsinaista XML-dokumentin tietosisältöä ja ne jätetäänkin usein pois tietoa talletettaessa tietokantaan. Joskus myös merkkauksen tallettaminen tietokantaan voi olla aiheellista (jäsentämättä sitä tarkemmin). Näin saattaa olla esimerkiksi osittain merkatun tiedon (mixed content) tapauksessa. Aina ei kuitenkaan ole helppoa määritellä onko XML-dokumentin merkkaus relevanttia tietoa talletettavaksi tietokantaan vai ei. Ajatellaan esimerkiksi XMLdokumentin seuraavaa osaa: <description> confusing example: <foo/> </description> Tietokantaan voitaisiin talletettaa description kenttään esim. confusing example: <foo/> Ovatko ja <foo> näin ollen tietokannalle merkkausta vai tekstiä? Lisäksi, esimerkiksi </foo> merkkijonon etsiminen ei ole yksinkertaista kyselykielillä, jotka eivät ole XML-pohjaisia (esim. SQL). Ko. kielen tulee tietää, että itse asiassa etsitään merkkijonona <foo/>.

RDBMS schema -> DTD/XML Schema nested approach 1. For each table, create an element type 2. For each data (non-key) column in that table, as well as for the primary key column(s), add an attribute to the element type or a child element of PCDATA type to its content model 3. For each primary key/foreign key relationship in which a column of the table contributes the primary key, add a child element to the content model and process the table recursively. In addition, use wrapper elements, if needed or desired e.g., and <address> element may capture <street>, <areacode>, <city>, etc. elements 254 be aware not to create name collisions Seuraavassa on esitetty yksi suoraviivainen ja melko yksinkertainen proseduuri DTD/XML Schema - kieliopin määrittämiseksi relaatiotietokannan skeemasta. Tästä proseduurista käytetään nimitystä nested approach, koska se muodostaa joissain tapauksissa hyvinkin syviä sisäkkäisiä elementtirakenteita. Myöhemmin esitämme toisen tavan, joka tarjoaa mahdollisuuden esittää tietokannan taulujen sisältämä tieto hieman kompaktimmin XML-dokumenttina. 1) Luo jokaista taulua kohden elementtityyppi. 2) Luo jokaista tavallista saraketta sekä perusavainsaraketta kohden joko attribuutti (CDATA) tai lapsielementti (PCDATA) edellä luodulle elementtityypille. 3) Lisää jokaista perusavain-vierasavain suhdetta kohden lapsielementti, ja käsittele linkitetty taulu (vierasavain) rekursiivisesti Edellä olevan proseduurin lisäksi voidaan tarpeen mukaan luoda erillisiä säiliöelementtejä. Tämä voidaan tehdä mikäli halutaan hienojakoisempi rakenne XML-dokumentteihin. Vaikka nämä säiliöelementit ovatkin hyödyllisiä XML:n kannalta, saattavat ne aiheuttaa turhaa monimutkaisuutta relaatiotietokannan skeemoissa tehtäessä käänteistä konversiota (DTD->RDBMS). Edellä esitetyssä menetelmässä kuten muissakin menetelmissä relaatiotietokannan tietojen konvertoimiseksi XML-pohjaiseksi tiedoksi tulee huolehtia siitä, ettei elementtien nimien kanssa tule ongelmia.

Example: invoice_id VARCHAR(32) name VARCHAR(128) area code INTEGER street VARCHAR(32) 2004-01-05-1234 Tarja Systä 33820 Neulask. 2004-01-05-1235 Oskari Onnenkantamoinen 33720 Teekkarink. item_id VARCHAR(32) product_id VARCHAR(128) quantity INTEGER invoice_id VARCHAR(32) 00001 abc0010 2 2004-01-05-1234 00002 abc0011 1 2004-01-05-1234 00003 abc0010 8 2004-01-05-1235 product_id VARCHAR(128) abc0010 abc0011 PName VARCHAR(128) Product X Product Y 255 Kalvolla esitetystä taulusta voidaan edellä esitetyllä proseduurilla tuottaa alla olevan kaltainen DTDmäärittely. <?xml version= 1.0?> <!DOCTYPE purchaseorderlist [ <!ELEMENT purchaseorderlist (invoice*)> <!ELEMENT invoice (areacode, name,street, items)> <!ATTLIST invoice invoiceno CDATA #REQUIRED> <!ELEMENT name (#PCDATA)> <!ELEMENT street (#PCDATA> <!ELEMENT items (item*)> <!ELEMENT item (product)> <!ATTLIST item quantity CDATA #REQUIRED itemid CDATA #REQUIRED productid CDATA #REQUIRED> <!ELEMENT product (pname)> <!ELEMENT pname (#PCDATA)> ]>

Tämän jälkeen tietokannan taulujen sisältö voidaan tallettaa ko. kieliopin mukaiseen XMLdokumenttiin. <?xml version= 1.0?> <purchaseorderlist> <invoice invoiceno= 2004-01-05-1234 > <areacode>33820</areacode> <name>tarja Systä</street> <street>neulask.</street> <items> <item quantity= 2 itemid= 00001 productid= abc0010 > <product> <pname>product X</pname> </product> </item> <item quantity= 1 itemid= 00002 productid= abc0011 > <product> <pname>product Y</pname> </product> </item> </items> </invoice> <invoice invoiceno= 2004-01-05-1235 > <areacode>33720</areacode> <name>oskari Onnenkantamoinen</street> <street>teekkarink.</street> <items> <item quantity= 8 itemid= 00003 productid= abc0010 > <product> <pname>product X</pname> </product> </item> </items> </invoice> </purchaseorderlist>

RDBMS tables -> XML flat approach Elements appearing multiple times can be referred using the ID and IDREF type attributes... <!ELEMENT product (pname)> <!ATTLIST product productid ID #IMPLIED> e.g. in the purchase order example, information for each product appears once in the document Advantage: more compact XML documents, since elements need not be repeated as heavily as in the nested approach 256 Edellä esitetylle runsaasti sisäkkäisiä rakenteita luovalle tavalle ( nested approach ) vaihtoehtoinen tapa on nk. flat approach, jossa käytetään hyväksi ID ja IDREF attribuutteja. Tarkoituksena on välttää kirjoittamasta samoja elementtejä useampaan kertaan XML-dokumenttiin ja siten pyrkiä kompaktimpaan esitysmuotoon. Edellä esitetyssä esimerkissä elementti ProductX ja sitä koskeva tieto kirjoitetaan uudelleen aina kun jokin tilaus sisältää vastaavan elementin. Tämä ei ole XMLdokumentin ylläpidettävyyden kannalta paras mahdollinen ratkaisu; selkeämpää olisi, jos ProductX kuvattaisiin vain kerran ja siihen vain viitattaisiin eri item-elementeistä aina tarvittaessa. flat approach tähtää juuri siihen. Viittaus saadaan aikaan ID ja IDREF attribuuttien avulla. Muista, että IDREF-tyyppisen attribuutin arvon tulee olla ID-tyyppinen attribuutti.

Esimerkki: <?xml version= 1.0?> <purchaseorderlist> <invoice invoiceno= 2004-01-05-1234 > <areacode>33820</areacode> <name>tarja Systä</street> <street>neulask.</street> <items> <item quantity= 2 itemid= 00001 productidref= abc0010 /> <item quantity= 1 itemid= 00002 productidref= abc0011 /> </items> </invoice> <invoice invoiceno= 2004-01-05-1235 > <areacode>33720</areacode> <name>oskari Onnenkantamoinen</street> <street>teekkarink.</street> <items> <item quantity= 8 itemid= 00003 productidref= abc0010 /> </items> </invoice> <products> <product product_id= abc0010 > <pname>product X</pname> </product> <product product_id= abc0011 > <pname>product </pname> </product> </products> </purchaseorderlist>

From XML document to RDBMS It is often acceptable to loose a part of XML document information DTD entities: definitions and usage physical structure, e.g. the order of sibling elements (data-centric information) converting structured and ordered data (XML document) to a table data that is unordered Many tables are typically needed to store all the information in the XML document XML documents are semi-structured it is often impossible to map an XML document to a single table e.g. for queries, the tables need to be joined (using primary and foreign keys) there are many ways to do this! XML Schema/DTD is not available decompose XML documents by using XPath and store a pair of 257 an XPath expression and the content addressed by the expression Talletettaessa XML-dokumentin tietoja tietokantaan, ei kaikkea dokumentin sisältämää tietoa aina tarvitse tai ole mahdollistakaan siirtää. Esimerkiksi dokumentin fyysistä rakennetta erityisesti, jos kyseessä on datakeskeistä tietoa ei yleensä tarvitse tallettaa. Järjestetyn tiedon, kuten sisarelementtien järjestys, tallettaminen järjestämättömään tietokannan tauluun olisi joka tapauksessa hankalaa. Myös mahdollisesti käytettyjä entiteettejä koskeva tieto ja dokumentin sisäinen DTDmäärittely jätetään yleensä huomioimatta. Mikäli kielioppimäärittely (DTD tai XML Schema) on saatavilla, sitä voidaan käyttää apuna päätettäessä miten ja kuinka moneen tauluun dokumentin tieto tulee tallettaa. Tämä ei kuitenkaan ole yleensä suoraviivaista. XML-dokumentin tietoa ei tyypillisesti voida tallettaa yhteen tauluun. Tämä johtuu pääosin siitä, että XML on osittain rakenteista tietoa. Toisaalta XML-dokumentin rakenteen kannalta voi muutenkin olla mielekkäämpää esittää tieto useana tauluna. Toisaalta tiedon haun (esim. kyselyt) kannalta on oleellista, että ko. taulut on tavalla tai toisella linkitettyjä. Tämä linkitys toteutetaan käytännössä perusavaimien (primary key, suom. myös pääavain) ja vierasavaimien (foreign key, suom. myös viiteavain) avulla. Koska linkitys XML-pohjaisen tiedon ja toisaalta relaatiotietokannan taulujen välillä ei ole suoraviivaista ja koska se voidaan tehdä monella eri tavalla, tarjoavatkin tietokantojen tuottajat tukea ko. relaation määräämiseksi ja yleisesti XML:ää ja tietokantoja hyödyntävien sovellusten toteuttamiseksi. Esimerkiksi tällaisista työkaluista ovat Oraclen XML Developer s Kit (XDK) ja IBM:n DB2 XML Extender.

Mikäli kielioppimääritystä (XML Schema tai DTD) ei ole olemassa, yksi suoraviivainen tapa tallettaa XML-dokumentin tieto on käyttää XPath-kieltä yksittäisten tietoelementtien osoittamiseen ja tallettaa aina kullekin riville sekä XPath-polku että ko. kohdasta löytyvä tieto (eri sarakkeisiin). Esimerkki: Content XPath Primary Key Tarja /R[1]/P[1]/A[1] 001 tarja.systa@tut.fi /R[1]/P[1]/A[1]/@email 002 TF111 /R[1]/P[1]/B[1] 003.........

DTD/XML Schema -> RDBMS schema 1. For each complex element type, create a table and a primary key column When an XML element can contain a subelement, the subelement contains a foreign key corresponding to the parent's primary key 2. For each element type with mixed content, create a table in which PCDATA is stored and link it to the parent table with the parent table s primary key 3. For each single-valued attribute of that element type, and for each simple child element that may occur (max) once, create a column in that table. If the child element type or attribute is optional, make the column nullable. 4. For each multi-valued attribute and for each simple child element occuring multiple times, create a separate table to store values, linked to the parent table through the parent table's primary key. 5. For each complex child element, link the table corresponding to the parent element type to the table corresponding to the child element type with the parent table's primary key 258 Mikäli XML-dokumentin kielioppimääritys on olemassa, voidaan talletus tehdä vaikkapa (huom! tämä voidaan tehdä monella eri tavalla) käyttäen kalvolla (suom. alla) kuvattua proseduuria. Proseduuri on periaatteessa käänteinen edellä esitetylle RDBMS->DTD proseduurille. Harjoitus: tuottaako tässä kuvattu proseduuri edellä esitetystä DTD-määrittelystä ( nested approach esimerkki) ko. esimerkin mukaiset relaatiotietokannan taulut? 1. Luo jokaista kompleksista elementtityyppiä (sisältää alirakenteita) kohden taulu, jossa on yksi sarake perusavaimia varten. Jos elementillä voi olla alielementti, tulee ko. alielementillä olla vierasavain, joka vastaa isätaulun perusavainta. 2. Luo jokaista sekarakenteista (mixed content) tyyppiä kohden taulu, johon merkkijonopohjainen tieto (PCDATA) talletetaan. Linkitä ko. taulu isätauluun käyttäen sen perusavainta. 3. Luo jokaista elementtityypin yksiarvoista attribuuttia ja korkeintaan kerran esiintyvää lapsielementtiä kohden sarake edellä luotuun tauluun. Mikäli lapsielementti on optionaalinen, merkitse optionaalisuus myös ko. sarakkeeseen (nullable) 4. Luo jokaista elementtityypin moniarvoista attribuuttia (esim. XML HTML SGML ) ja mahdollisesti useamman kerran (*) esiintyvää yksinkertaista lapsielementtiä kohden uusi taulu. Linkitä tämä taulu käyttäen vierasavainta ja isätaulun perusavainta. 5. Jokaista kompleksista elementtityyppiä kohden linkitä isäelementtiä vastaava taulu tätä (kompleksista) elementtityyppiä vastaavaan tauluun käyttäen isätaulun perusavainta.