7. ER- ja EER-mallin kuvaaminen relaatiotietokannaksi

Transkriptio

1 7. ER- ja EER-mallin kuvaaminen relaatiotietokannaksi Tähän m ennessä olem me käsitelleet, m iten tietokannan kuvaus esitetään ER- tai EER-m allinnusta käyttäm ällä luvuissa 3 ja 4. Lisäksi olem m e esitelleet relaatiom allin teoreettisen perustan luvussa 6. esittelem ällä relaatioalgebran sekä tupla- ja määrittelyjoukkoon perust uvan relaat iok alky ylin. Sen sijaan menettely, m iten käsitteellisestä tietomallista päästään siirtym ään relaatiomalliin, on toistaiseksi jäänyt vaille huom iota. Seuraavassa tarkastellaan, m iten ER-mallinnuksen avulla hahmoteltu tietokanta voidaan kuvata relaatiom allin m ukaiseksi. Kyseessä on tietokannan suunnitteluvaihe, jossa siirrytään TKHJ: stä riippumattomasta osuudesta TKHJ: n asettamien reunaehtojen m ukaiseen ( vertaa kirjan kuvaan 3.1 ). Kuvauksen eri vaiheet on esitelty kirjan 7. luvun kappaleessa 7.1. Kappaleessa 7.2 käsit ellään EER- m allin kuvaam ist a relaat iom alliin.

2 7.1 ER-mallin mukaisen tietokannan suunnitelman kuvaaminen relaatiomallia vastaavaksi ER-m allia noudatteleva tietokannan kuvaus voidaan muuntaa relaatiom allin m ukaiseksi käyttämällä 7-vaiheista algoritm ia. Tarkastellaan eri vaiheita esimerkeissä käytetyssä yrityksen tietokannassa Algoritmi ER-mallin kuvaamiseksi relaatiomalliin VAI HE 1: Perustetaan ER-m allin jokaista vahvaa entiteettityyppiä ( kohti relaatiotaulu 5, johon sijoitetaan kaikki (: n yksinkertaiset attribuutit. Koosteiset attribuutit esitetään ositettuina yksinkertaisiksi attribuuteiksi. Valitaan jokin (: n avainattribuuteista 5: n pääavaim eksi. Pääavain voi tarvittaessa koostua usean attribuutin yhdistelmästä. Vierasavain- ja suhteiden attribuutit jätetään tässä vaiheessa vielä kirjaam atta.

3 Yritystä koskevassa esim erkissä perustetaan relaatiotaulut EMPLOYEE, DEPARTMENT ja PROJECT, koska ne edustavat kaikki vahvoja entiteettityyppejä. Tässä vaiheessa jätetään taulusta EMPLOYEE kirjaam atta vierasavainattribuutit SUPERSSN JA DNO. Samalla perusteella taulusta PROJECT kirjaam atta osastonumero. Taulusta DEPARTMENT jätetään tässä vaiheessa pois tieto osaston johtajan henkilötunnuksesta ( vierasavain ) ja hänen aloituspäivästään ( osaston johtam issuhteen attribuutti ). VAI HE 2: Jokaista heikkoa entiteettityyppiä : varten perustetaan myös oma relaatiotaulu 5, johon kerätään kaikki kyseiseen entiteettityyppiin liittyvät yksinkertaiset attribuutit. Koosteiset attribuutit esitetään yksinkertaisiksi ositettuina. Lisäksi tauluun otetaan mukaan :: n omistajatyypin pääavain =. Taulun pääavaimeksi valitaan W: n osittaisavaimen ja =: n yhdistelmä. Huonoim massa tapauksessa W: n osittaisavain koostuu sen kaikkien om ien attribuuttien yhdistelmästä. Koska heikon entiteettityypin edustaja on olem assaoloriippuva om istajatyyppi(e)nsä edustajasta, kannattaa vyöryttää om istajaentiteetin tuplassa tapahtuvat muutokset sekä m ahdollinen tuplan poisto optiolla CASCADE kaikkiin siihen liittyviin heikon entiteettityypin edustajatupliin. Yritysesim erkissä perustetaan taulu DEPENDENT, johon otetaan mukaan kaikki sen omat attribuutit sekä lisäksi työntekijän henkilötunnusta kuvaava identifioiva attribuutti ESSN.

4 VAI HE 3: Jokaista lukum ääräsuhteeltaan tyyppiä 1: 1 olevaa liittymää 5 kohti selvitetään aluksi suhteeseen osallistuvat taulut 6 ja 7. Mikäli jom maltakum malta taululta vaaditaan täydellistä osallistum ista suhteeseen 5, valitaan kyseinen taulu 6: n paikalle ( m enettelyllä vältetään turhien NULL-arvojen tallentamista ). Tämän jälkeen sijoitetaan taulun 6 vierasavaimeksi taulun 7 pääavain, ja lisäksi kaikki liittym älle 5 ominaiset attribuutit viedään sam oin tauluun 6. Yritystä kuvaavassa esim erkissä osaston johtamiseen liittyvä suhde on tyyppiä 1: 1. Koska osaston osallistuminen suhteeseen on täydellistä m utta työntekijän osittaista, valitaan tauluksi S DEPARTMENT ja tauluksi 7 EMPLOYEE. Tällöin joudutaan tauluun DEPARTMENT lisääm ään suhteen 5 attribuutti MGRSTARTDATE sekä taulun EMPLOYEE vierasavain MGRSSN. Mikäli olisi toim ittu päinvastoin eli valittu taulu EMPLOYEE 6: n paikalle, olisi kyseiseen tauluun jouduttu lisääm ään tieto siitä, mitä osastoa työntekijä johtaa sekä johtajana toim im isen aloituspäivämäärä. Täm ä ratkaisu olisi kuitenkin köm pelöm pi, sillä suurin osa työntekijöistä ei johda mitään osastoa, kun taas jokaisella osastolla pitäisi olla johtaja. Jos osallistum inen relaatioon 5 on m olem piin suuntiin täydellistä, olisi mahdollista koota siihen osallistuvat entiteettityypit yhdeksi laajem m aksi entiteettityypiksi.

5 VAI HE 4: Jokaista lukum ääräsuhteeltaan 1: N olevaa taulujen 6 ja 7 välillä vallitsevaa suhdetta 5 kohti valitaan 6: n paikalle tauluista se, johon lukumääräsuhde N liittyy. Sijoitetaan tauluun 6 taulun 7 ( eli 5: n 1-puolen ) vierasavainkenttä sekä kaikki suhteelle ominaiset lisäattribuutit. Yrityksessä lukumääräsuhdetta 1: N edustavat relaatiot OSASTOLLA_KI RJOI LLAOLO, PROJEKTI N_KONTROLLOI NTI sekä ESI MI EHENÄ_TOI MI MI NEN. Täten lisätään tauluun EMPLOYEE attribuutti, joka kuvaa osastonumeroa ( DNO ), koska yhdellä osastolla voi olla monta työntekijää ( m utta yksikään työntekijä ei voi olla kirjoilla usealla eri osastolla ). Samasta syystä tauluun PROJECT attribuutti DNUM. Lisäksi tauluun EMPLOYEE on lisättävä tieto esim iehestä eli attribuutti SUPERSSN. Viimeksi m ainittu relaatio ESI MI EHENÄ_TOI MI MI NEN on refleksiivinen, joten taulu EMPLOYEE esiintyy suhteessa sekä 6: nä että 7: nä. VAI HE 5: Jokaista liittymää 5 kohti, jonka lukumääräsuhteena on M: N, on tietokantaan perustettava uusi relaatiotaulu 6, johon sijoitetaan attribuuteiksi kum m ankin suhteeseen osallistuvan taulun 8 ja 9 pääavaimen muodostavat attribuutit. Näiden attribuuttien yhdistelmästä m uodostuu taulun 6 pääavain. Lisäksi 6: ään sijoitetaan kaikki suhteelle 5 tyypilliset attribuutit. Kannattaa huom ioida, että uuden taulun 6 perustam inen on välttäm ätöntä lukumääräsuhteen ollessa M: N, sillä moniarvoisia attribuutteja ei relaat iom allissa hyv äksyt ä.

6 Esimerkissäm me entiteettityyppien TYÖNTEKI JÄ ja PROJEKTI välinen suhde TYÖTUNNI T on lukum ääräsuhteeltaan M: N, sillä yksittäinen työntekijä voi tehdä työsuorituksia useassa eri projektissa, joissa voi puolestaan olla useita työntekijöitä kerrallaan. Täten perustetaan taulu TYÖTUNNI T ( WORKS_ON ), jonka pääavain koostuu taulujen TYÖNTEKI JÄ ja PROJEKTI pääavainten yhdistelmästä { henkilötunnus, projektinum ero }. Lisäksi työntekijän eri projekteihin tekem ien työtuntien lukumäärä kirjataan taulun kolm anneksi attribuutiksi. Tyypin 0: 1 m ukaisten suhteiden esittämiseksi perustettuun tauluun 6 kannattaa asettaa muutoksien ja poistojen varalta optio CASCADE kullekin taulun pääavaimeen kuuluvalle vierasavainkentälle, sillä taulun 6 tuplat ovat olem assaoloriippuvia 6: n taustalla olevaan relaatioon 5 osallistuvien entiteettien edustajista. Jos esim erkiksi jokin työntekijä lopettaa työskentelynsä yrityksessä, ei hänen työtunneillaan ole sen jälkeen enää m itään relevanttia tulkintaa. Samoin käy, jos jokin sellainen projekti lakkautetaan, johon työntekijä on osallistunut. VAI HE 6: Jokaista relaatiotaulun 5 m oniarvoista attribuuttia $ varten on perustettava uusi relaatiotaulu 6. Kyseiseen tauluun pitää sijoittaa attribuutti %, joka esittää kerrallaan yhtä $: n saam ista arvoista yhtä 5: n tuplaa kohti. Lisäksi 6: ään pitää sijoittaa vierasavaimeksi taulun 5 pääavain =, jotta tiedetään, mihin tuplaan taulussa 5 uuden taulun 6 tuplat liittyvät. Taulun 6 pääavain koostuu siten attribuuttien = ja % yhdistelmästä.

7 Yrityksen tietokannassa osastoon liittyvä attribuutti TOI MI PI STEET oli ERmallissa moniarvoinen: yhdellä osastolla voi olla m onta toim ipistettä. Koska moniarvoisia attribuutteja ei hyväksytä relaatiom allissa, pitää perustaa uusi taulu DEPT_LOCATI ONS, joka sisältää kaksi attribuuttia: osastonumeron sekä sijaintipaikan. Tuplia tauluun tulee jokaista osastoa kohti niin monta, kuin sillä on toimipisteitä eri paikkakunnilla. Moniarvoisten attribuuttien esittämiseksi perustetuissa tauluissa kannattaa jälleen vierasavaimen päivitystä ja poistoa varten asettaa vyörytysoptio CASCADE on turhaa säilyttää osaston toim ipisteitä tietokannassa, jos koko osasto lakkautetaan! Esimerkkiyrityksessäm me ei esiintynyt laisinkaan astetta 2 korkeampia asteita olevia relaatioita. Viim einen mallin kuvausvaiheista koskee tällaisten suhteiden kuvaam ista relaatiomalliin sopiviksi. VAI HE 7: Jokaista vähintään astetta 3 olevaa suhdetta 5 varten perustetaan uusi relaatiotaulu 6, johon sijoitetaan kaikkien suhteeseen 5 osallistuvien taulujen ( pääavainattribuutit. Lisäksi 5: lle om inaiset lisäattribuutit sijoitetaan 6: ään. Taulun 6 pääavain m uodostuu kaikkien taulujen ( pääavainten yhdistelmästä pois lukien kuitenkin ne taulut, joiden kohdalla lukum ääräsuht eena on 1.

8 Tarkastellaan kirjan kuvaa 7.3, joka kuvaa esim erkin 4.11 mukaista tilannetta, jossa m uodostettiin astetta 3 oleva relaatio tavaran, sen toimittajan ja sitä tarvitsevan projektin välillä relaation pääavain m uodostuu jokaisen suhteeseen osallistuvan taulun pääavainten yhdistelmästä. Jos kuitenkin tiedettäisiin esimerkiksi, että vain yksi toim ittaja pystyy toimittamaan kutakin osaa, ei tietoa toimittajasta ole tarpeen sisällyttää suhdetta kuvaavan relaatiotaulun pääavaim een, sillä toimittaja pystytään identifioimaan toimitettavan osan num erosta. Vastaava tilanne syntyisi, jos yhteen projektiin tarvittaisiin ainoastaan yhtä osaa ( osan numero voitaisiin päätellä projektin nimen perusteella ) tai tietylle projektille pystyisi välittämään osia vain yksi toim ittaja ( projekti voitaisiin päätellä toim ittajan perusteella ). ER- ja relaatiomallien välinen pääasiallinen ero on, että ER-mallissa entiteettityyppien väliset suhteet esitellään aina eksplisiittisesti, kun taas relaatiom allissa suhde ilmaistaan attribuuttien välillä, joiden arvot edustavat keskenään samaa arvojoukkoa. Toinen attribuuteista on taulun pääavain ja toinen puolestaan vierasavain ( vrt. taulun DEPARTMENT kenttä DNUMBER ja taulun PROJECT kenttä DNUM, taulun EMPLOYEE kentät SSN ja SUPERSSN jne. ). Suhteeseen 5 osallistuvat entiteettityyppien 6 ja 7 esiintym ät yhdistetään toisiinsa yhtäsuuruusliitoksen avulla S: n attribuutille $ ja 7: n attribuutille %. Liitosehto toteutuu, kun 6.$ = 7.%, ja 6.$ NULL.

9 Jos binäärisen relaation lukumääräsuhde on 1: 1 tai 1: N, tarvitaan sen esittämiseksi yleensä 1 liitos ( vrt. OSASTO-JOHTAJA, PROJEKTI -OSASTO ). Lukumääräsuhteeltaan M: N olevan binäärisen relaation esittäm iseen vaaditaan 2 liitosta ( vrt. TYÖTUNNI T ). Astetta Q olevan suhteen esittäm istä varten tarvitaan Q liitosta. Liitosten muodostam isessa kannattaa olla varovainen. Pitää huolehtia siitä, että liitosattribuuteista toinen on taulun 6 pääavain ja toinen taulun 7 vierasavain. Muulla tavalla toteutettu liitos saattaa tuottaa tulostauluun virheellistä tietoa sisältäviä ns. valetuplia. Esimerkki: m uodostetaan liitos taulujen PROJEKTI ja TOI MI PI STEET välille käyttämällä liitosattribuuttina sijaintipaikkakuntaa, eli PLOCATI ON = DLOCATI ON. Koska kyseiset attribuutit eivät m uodosta pääavainvierasavain paria, päätyy tulostauluun järjettömiä tuplien yhdistelmiä, joissa eri tauluista valitut tuplat eivät m illään m ielekkäällä tavalla liity toisiinsa. Kannattaa lisäksi huom ioida, että jokaista tietokannassa esiintyvää moniarvoista attribuuttia varten pitää perustaa oma taulunsa.

10 Rakenneosien vastaavuus ER- ja relaatiomallin välillä Seuraavassa yhteenveto, miten ER-mallin rakenneosat m uunnetaan vastaamaan relaatiomallia. (5PDOOL 5HODDWLRPDOOL Entiteettityyppi Entiteettityyppiä kuvaava relaatiotaulu Suhde 1: 1 tai 1: N Vierasavain ( tai erillinen relaatiotaulu ) Suhde M: N Erillinen relaatiotaulu, jossa 2 vierasavainta Astetta Q oleva suhde ( Q > 2 ) Erillinen relaatiotaulu, jossa n vierasavainta Yksinkertainen attribuutti Attribuutti Koosteinen attribuutti Joukko yksinkertaisia attribuutteja Entiteettityypin ( m oniarvoinen attribuutti $ Relaatiotaulu, jossa avainattribuutteina $: n sekä taulun ( pääavaimen yhdistelmä Arvoj oukko Määrit t elyj oukko Avainattribuutti Pää- tai toisioavain

11 7.2. EER-mallin rakenneosien kuvaaminen relaatiomalliin Kirjan luvussa 7.1 tarkasteltiin ER-mallin rakenneosien kuvaam ista relaatiomalliin sopiviksi. Tässä luvussa tarkastellaan EER-malliin m ukaisten lisäom inaisuuksien kuvaamista relaatiom alliin. Näitä om inaisuuksia ovat luokkaaliluokkarelaat iot sekä kat egoriat Yleistämisen ja erikoistamisen kuvaaminen relaatiomalliin Aloitetaan EER-mallin muuntam isen tarkastelu tutkimalla kirjan esim erkkien 4.5 ja 4.6 mukaisia tilanteita. Käytettäessä EER-m allin mukaista käsitteellistä kuvausta pitää kohdassa 7.1 esitetty 7-vaiheinen algoritmi pidentää 9-vaiheiseksi. VAI HE 8: Esitellään neljä optiota, joiden avulla voidaan luokka-aliluokkasuhteet m uuntaa relaatiomalliin sopiviksi. Olkoot EER-mallin mielivaltaisen luokan & attribuutit { N, D, D,..., D Q }, missä N on kyseisen luokan avainattribuutti, ja edustakoon luokan & aliluokkia joukko { 6, 6, 6,..., 6 P }. Tällöin jokainen &: n erikoistam inen aliluokkiinsa pitää m uuntaa relaatiomallin m ukaiseksi jollain seuraavista tavoista:

12 ¾ Optio 8A: Useita relaatiotauluja, joista yksi yliluokkaa C varten ƒ Perustetaan relaatiotaulu /, johon sijoitetaan kaikki &: n attribuutit. Taulun pääavaim eksi t ulee selväst ikin &: n pääavain. ƒ Jokaista &: n aliluokkaa 6 L ( 1 L P ) kohti perustetaan relaatiotaulu / L, johon sijoitetaan attribuuteiksi &: n pääavain N sekä kaikki kyseisen aliluokan erikoisattribuutit. Taulun pääavaimeksi valitaan N. ƒ Tätä optiota voidaan soveltaa aina riippum atta erikoistam isen t yypist ä ( t äydellinen t ai osit t ainen HULOOLQHQWDLSäällekk äinen ) ¾ Optio 8B: Useita relaatiotauluja, mutta yksistään aliluokkia varten ƒ Perustetaan relaatiotaulu / L jokaista luokan C aliluokkaa 6 L ( 1 L P ) kohti. Attribuuteiksi tauluun / L valitaan kaikki &: n sekä sen erikoistetun aliluokan 6 L attribuutit. Kunkin perustettavan taulun pääavaimeksi valitaan N. ƒ Optiota 8B voidaan soveltaa vain, jos erikoistam inen on täydellistä, eli jokainen luokan & edustaja kuuluu ainakin yhteen sen aliluokista, sillä pelkästään yliluokkaan kuuluvat &: n edustajat jäisivät tässä ratkaisum allissa kirjaamatta kokonaan. ƒ Lisäksi, jos erikoistam inen ei ole erillistä, aiheutuu redundanssia, koska C: n attribuuttien arvot joudutaan toistam aan kaikille niille aliluokille, joita sen tupla edustaa.

13 ¾ Optio 8C: Yksi relaatiotaulu, joka sisältää yhden tyyppiattribuutin ƒ Perustetaan relaatiotaulu /, johon sijoitetaan kaikki &: n sekä kaikki sen aliluokkien 6 L ( 1 L P ) attribuutit. Taulun pääavaimeksi valitaan N. ƒ Näiden lisäksi tauluun sijoitetaan yksi ns. tyyppiattribuutti W, jonka saam a arvo väliltä [ 1..P] osoittaa, m ihin &: n aliluokkaan entiteetin tupla kuuluu. Ellei tupla ole edustettuna muualla kuin yliluokassa, tulee kyseisen attribuutin arvoksi puuttuva ( = NULL ). ƒ Erillistä tyyppiattribuuttia ei ole kuitenkaan tarpeen esitellä, m ikäli erikoistam inen määräytyy suoraan jonkin yliluokan attribuutin saam an arvon perusteella. ƒ Tätä optiota voidaan soveltaa ainoastaan silloin, kun erikoistam inen aliluokkiin on tyypiltään erillistä, eli yksi yliluokan edustaja voi kuulua ker rallaan vain yht een aliluokk aan. ƒ Ratkaisu tuottaa useita NULL-arvoja, m ikäli luokalla on useita aliluokkia ja / tai aliluokilla on useita paikallisia attribuutteja. Optiolla saavutettava etu on kuitenkin se, ettei tauluja tarvita luokka-aliluokkarelaation esittäm iseksi yhtä enempää.

14 ¾ Optio 8D: Yksi relaatiotaulu, jossa useita tyyppiattribuutteja ƒ Perustetaan relaatiotaulu /, johon sijoitetaan kaikki &: n sekä kaikki sen aliluokkien 6 L ( 1 L P ) attribuutit. Taulun pääavaimeksi valitaan N. ƒ Lisäksi jokaista &: n aliluokkaa 6 L ( 1 L P ) kohti perustetaan tyyppiattribuutti W L, jonka arvo on loogista tyyppiä ( tosi / epätosi ) ja joka osoittaa, edustaako entiteetin tupla aliluokkaa 6 L vai ei. ƒ Usean tyyppiattribuutin asem esta voitaisiin optiota 8D varten ottaa käyttöön yksi m -bittinen tyyppiattribuutti, jonka L. bitti kertoo, kuuluuko tupla &: n L: nteen aliluokkaan 6 L vai ei ( 0 = epätosi, 1 = tosi ). ƒ Tätä optiota on tarkoitettu sovellettavaksi lähinnä päällekkäistä erikoistam ista ajatellen, mutta se kelpaa yhtäläisesti erilliseen erikoistam iseen. ƒ Myös tämän ratkaisun etuna on yhden taulun riittävyys relaation esittämiseen, m utta nytkin NULL-arvojen m äärä tulee suureksi, m ikäli on yleistä, että yksittäinen &: n edustaja ei kuulu m oneen aliluok kaan sam anaikaisest i.

15 Optioista 8A ja 8B käytetään toteutustapansa m ukaisesti nim itystä usean relaation optiot, kun taas vaihtoehdot 8C ja 8D ovat yhden relaation optioita. Optiossa 8A m uodostetaan relaatio yliluokan ja jokaisen aliluokkansa välillä yhtäsuuruusliitoksella pääavaimen N arvon m ukaisesti. Tarkastellaan kirjan esimerkkiä 7.4a. Option 8B mukainen ratkaisu sisältää yhtäsuuruusliitoksen jo valmiina, joten luokan ja sen yksittäisen aliluokan attribuutit löytyvät samasta taulusta. Etsittäessä m ielivaltaista &: n tuplaa joudutaan haku kohdistam aan kaikkiin tauluihin / L, jotka edustavat &: n luokka-aliluokka -relaatioita. Kaikki &: n tuplat saadaan m uodostamalla kaikkien taulujen / L täysi ulkoinen liitos tai ulkoinen unioni. Tällä tavoin saatu tulostaulu näyttäisi samalta kuin optioiden 8C ja 8D mukainen, m utta ilman tyyppiattribuutteja. Tarkastellaan kirjan esimerkkiä 7.4b. Option 8C mukainen toteutus on nähtävillä kirjan esim erkissä 7.4c. Siinä aliluokkaan kuulum inen määräytyy yksikäsitteisesti attribuutin 'TyönTyyppi'm ukaisest i.

16 Optio 8C ei kuitenkaan kelpaa ratkaisuksi, jos työntekijä voisi kuulua useaan am m attiryhm ään sam anaikaisesti. Tällöin jokaista erikoistettua työtyyppiä varten pitäisi olla tyyppiattribuutti seuraavaan tapaan: 'OnkoI nsinööri?', 'OnkoTeknikko?', 'OnkoSihteeri?'jne. Tähän tarkoitukseen kelpaa optio 8D. Tarkastellaan vielä kirjan esimerkkiä 7.4d. Mikäli erikoistam isella on useita tasoja, ei ole m itenkään välttämätöntä käyttää jokaisella tasolla sam aa optiota. Tarkastellaan kirjan esimerkkiä 7.5 yliopistotietokannasta, jossa on käytetty luokalle henkilö kolmea eri optiota eri erikoistamisvaiheissa ( HUOM! kirjan kuvateksti on virheellinen, viittaus tapahtuu todellisuudessa kirjan esimerkkiin 4.7 ). Luokan 'HENKI LÖ'ylim mälle erikoistam istasolle on sovellettu optiota 8A ( täydellinen osittainen erikoistam inen ), luokalle TYÖNTEKI JÄ optiota 8C ( täydellinen erillinen erikoistam inen ) ja luokalle OPI SKELI JA optiota 8D ( sekä täydellistä että osittaista erikoistam ista ) Kategorioiden ( eli unionityyppien ) kuvaaminen relaatiomalliin Entiteettityyppiä kutsutaan kategoriaksi, m ikäli se on m uodostettu usean eri entiteettityypin unionioperaatiolla. Kategoriat esiteltiin edellä kappaleessa 4.4. Kategorioiden esittämiseksi relaatiomallin avulla tarvitaan kappaleen algoritm iin vielä yksi lisäkohta vaihe 9.

17 VAI HE 9: Jokaista sellaista kategoriaa kohti, joka koostuu entiteettityypeistä, joilla on eri avainattribuutti, perustetaan taulu, jonka pääavaimeksi asetetaan ns. VLMDLVDYDLQ, jonka turvin kategorian eri edustajat pystytään identifioimaan. Sijaisavain on otettava käyttöön, jotta kategorian eri edustajat voitaisiin yhdistää toisiinsa käsitteellisesti, vaikka ne voivatkin itsenäisinä edustaa keskenään eri entiteettityyppejä. Sijaisavainta kuvaava vierasavainattribuutti pitää lisätä myös kaikkiin unioniin osallistuviin entiteettityyppeihin. Tarkastellaan kirjan esimerkkiä 7.6, jossa kuvan 4.8 ( kirjassa jälleen väärä kuvateksti ) mukainen kategoria m uunnetaan relaatiom alliin kelvolliseksi. Perustetaan taulu OMI STAJA, joka sisältää pelkästään tunnistenum eron, jota tarvitaan unionin ylläpitäm iseksi. Vierasavainkenttä kyseistä tunnistenumeroa varten lisätään kaikkiin unionin muodostaviin entiteettityyppeihin eli tyypeille HENKI LÖ, PANKKI ja YHTI Ö. Relaation OMI STAMI NEN esittäm iseksi perustetaan myös erillinen relaatiotaulu, jossa pääavain muodostuu om istajan tunnistenum eron ja kulkuneuvon valm istenumeron yhdistelmästä. Kannattaa huom ioida, että om istajan tunnistenumeroksi tulee NULL jokaisella sellaisella henkilöllä, pankilla ja yhtiöllä, jotka eivät satu om istamaan m itään kulkuneuvoa. Lisäksi kannattaa huom ioida, ettei henkilö- ja kuorm a-autoista m uodostetun kategorian esittäm iseksi tarvita erillistä sijaisavaintaulua, sillä kum mankin unioniin osallistuvan entiteettityypin pääavain on keskenään yht eensopiva.