7. ER- ja EER-mallin kuvaaminen relaatiotietokannaksi

Esitys aiheesta: "7. ER- ja EER-mallin kuvaaminen relaatiotietokannaksi"— Esityksen transkriptio:

1 7. ER- ja EER-mallin kuvaaminen relaatiotietokannaksi
Tähän mennessä olemme käsitelleet, miten tietokannan kuvaus esitetään ER- tai EER-mallinnusta käyttämällä luvuissa 3 ja 4. Lisäksi olemme esitelleet relaatiomallin teoreettisen perustan luvussa 6. esittelemällä relaatioalgebran sekä tupla- ja määrittelyjoukkoon perustuvan relaatiokalkyylin. Sen sijaan menettely, miten käsitteellisestä tietomallista päästään siirtymään relaatiomalliin, on toistaiseksi jäänyt vaille huomiota. Seuraavassa tarkastellaan, miten ER-mallinnuksen avulla hahmoteltu tietokanta voidaan kuvata relaatiomallin mukaiseksi. Kyseessä on tietokannan suunnitteluvaihe, jossa siirrytään TKHJ:stä riippumattomasta osuudesta TKHJ:n asettamien reunaehtojen mukaiseen ( vertaa kirjan kuvaan 3.1 ). Kuvauksen eri vaiheet on esitelty kirjan 7. luvun kappaleessa 7.1. Kappaleessa 7.2 käsitellään EER-mallin kuvaamista relaatiomalliin.

2 7.1 ER-mallin mukaisen tietokannan suunnitelman kuvaaminen relaatiomallia vastaavaksi
ER-mallia noudatteleva tietokannan kuvaus voidaan muuntaa relaatiomallin mukaiseksi käyttämällä 7-vaiheista algoritmia. Tarkastellaan eri vaiheita esimerkeissä käytetyssä yrityksen tietokannassa. Algoritmi ER-mallin kuvaamiseksi relaatiomalliin VAIHE 1: Perustetaan ER-mallin jokaista vahvaa entiteettityyppiä E kohti relaatiotaulu R, johon sijoitetaan kaikki E:n yksinkertaiset attribuutit. Koosteiset attribuutit esitetään ositettuina yksinkertaisiksi attribuuteiksi. Valitaan jokin E:n avainattribuuteista R:n pääavaimeksi. Pääavain voi tarvittaessa koostua usean attribuutin yhdistelmästä. Vierasavain- ja suhteiden attribuutit jätetään tässä vaiheessa vielä kirjaamatta.

3 Yritystä koskevassa esimerkissä perustetaan relaatiotaulut EMPLOYEE, DEPARTMENT ja PROJECT, koska ne edustavat kaikki vahvoja entiteettityyppejä. Tässä vaiheessa jätetään taulusta EMPLOYEE kirjaamatta vierasavainattribuutit SUPERSSN JA DNO. Samalla perusteella taulusta PROJECT kirjaamatta osastonumero. Taulusta DEPARTMENT jätetään tässä vaiheessa pois tieto osaston johtajan henkilötunnuksesta ( vierasavain ) ja hänen aloituspäivästään ( osaston johtamissuhteen attribuutti ). VAIHE 2: Jokaista heikkoa entiteettityyppiä W varten perustetaan myös oma relaatiotaulu R, johon kerätään kaikki kyseiseen entiteettityyppiin liittyvät yksinkertaiset attribuutit. Koosteiset attribuutit esitetään yksinkertaisiksi ositettuina. Lisäksi tauluun otetaan mukaan W:n omistajatyypin pääavain Z. Taulun pääavaimeksi valitaan W:n osittaisavaimen ja Z:n yhdistelmä Huonoimmassa tapauksessa W:n osittaisavain koostuu sen kaikkien omien attribuuttien yhdistelmästä. Koska heikon entiteettityypin edustaja on olemassaoloriippuva omistajatyyppi(e)nsä edustajasta, kannattaa vyöryttää omistajaentiteetin tuplassa tapahtuvat muutokset sekä mahdollinen tuplan poisto optiolla CASCADE kaikkiin siihen liittyviin heikon entiteettityypin edustajatupliin. Yritysesimerkissä perustetaan taulu DEPENDENT, johon otetaan mukaan kaikki sen omat attribuutit sekä lisäksi työntekijän henkilötunnusta kuvaava identifioiva attribuutti ESSN.

4 VAIHE 3: Jokaista lukumääräsuhteeltaan tyyppiä 1:1 olevaa liittymää R kohti selvitetään aluksi suhteeseen osallistuvat taulut S ja T Mikäli jommaltakummalta taululta vaaditaan täydellistä osallistumista suhteeseen R, valitaan kyseinen taulu S:n paikalle ( menettelyllä vältetään turhien NULL-arvojen tallentamista ). Tämän jälkeen sijoitetaan taulun S vierasavaimeksi taulun T pääavain, ja lisäksi kaikki liittymälle R ominaiset attribuutit viedään samoin tauluun S. Yritystä kuvaavassa esimerkissä osaston johtamiseen liittyvä suhde on tyyppiä 1:1. Koska osaston osallistuminen suhteeseen on täydellistä mutta työntekijän osittaista, valitaan tauluksi S DEPARTMENT ja tauluksi T EMPLOYEE. Tällöin joudutaan tauluun DEPARTMENT lisäämään suhteen R attribuutti MGRSTARTDATE sekä taulun EMPLOYEE vierasavain MGRSSN. Mikäli olisi toimittu päinvastoin eli valittu taulu EMPLOYEE S:n paikalle, olisi kyseiseen tauluun jouduttu lisäämään tieto siitä, mitä osastoa työntekijä johtaa sekä johtajana toimimisen aloituspäivämäärä. Tämä ratkaisu olisi kuitenkin kömpelömpi, sillä suurin osa työntekijöistä ei johda mitään osastoa, kun taas jokaisella osastolla pitäisi olla johtaja. Jos osallistuminen relaatioon R on molempiin suuntiin täydellistä, olisi mahdollista koota siihen osallistuvat entiteettityypit yhdeksi laajemmaksi entiteettityypiksi.

5 VAIHE 4: Jokaista lukumääräsuhteeltaan 1:N olevaa taulujen S ja T välillä vallitsevaa suhdetta R kohti valitaan S:n paikalle tauluista se, johon lukumääräsuhde N liittyy. Sijoitetaan tauluun S taulun T ( eli R:n 1-puolen ) vierasavainkenttä sekä kaikki suhteelle ominaiset lisäattribuutit. Yrityksessä lukumääräsuhdetta 1:N edustavat relaatiot OSASTOLLA_KIRJOILLAOLO, PROJEKTIN_KONTROLLOINTI sekä ESIMIEHENÄ_TOIMIMINEN. Täten lisätään tauluun EMPLOYEE attribuutti, joka kuvaa osastonumeroa ( DNO ), koska yhdellä osastolla voi olla monta työntekijää ( mutta 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 esimiehestä eli attribuutti SUPERSSN. Viimeksi mainittu relaatio ESIMIEHENÄ_TOIMIMINEN on refleksiivinen, joten taulu EMPLOYEE esiintyy suhteessa sekä S:nä että T:nä. VAIHE 5: Jokaista liittymää R kohti, jonka lukumääräsuhteena on M:N, on tietokantaan perustettava uusi relaatiotaulu S, johon sijoitetaan attribuuteiksi kummankin suhteeseen osallistuvan taulun U ja V pääavaimen muodostavat attribuutit. Näiden attribuuttien yhdistelmästä muodostuu taulun S pääavain. Lisäksi S:ään sijoitetaan kaikki suhteelle R tyypilliset attribuutit. Kannattaa huomioida, että uuden taulun S perustaminen on välttämätöntä lukumääräsuhteen ollessa M:N, sillä moniarvoisia attribuutteja ei relaatiomallissa hyväksytä.

6 Esimerkissämme entiteettityyppien TYÖNTEKIJÄ ja PROJEKTI välinen suhde TYÖTUNNIT 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ÖTUNNIT ( WORKS_ON ), jonka pääavain koostuu taulujen TYÖNTEKIJÄ ja PROJEKTI pääavainten yhdistelmästä { henkilötunnus, projektinumero }. Lisäksi työntekijän eri projekteihin tekemien työtuntien lukumäärä kirjataan taulun kolmanneksi attribuutiksi. Tyypin M:N mukaisten suhteiden esittämiseksi perustettuun tauluun S kannattaa asettaa muutoksien ja poistojen varalta optio CASCADE kullekin taulun pääavaimeen kuuluvalle vierasavainkentälle, sillä taulun S tuplat ovat olemassaoloriippuvia S:n taustalla olevaan relaatioon R osallistuvien entiteettien edustajista. Jos esimerkiksi jokin työntekijä lopettaa työskentelynsä yrityksessä, ei hänen työtunneillaan ole sen jälkeen enää mitään relevanttia tulkintaa. Samoin käy, jos jokin sellainen projekti lakkautetaan, johon työntekijä on osallistunut. VAIHE 6: Jokaista relaatiotaulun R moniarvoista attribuuttia A varten on perustettava uusi relaatiotaulu S. Kyseiseen tauluun pitää sijoittaa attribuutti B, joka esittää kerrallaan yhtä A:n saamista arvoista yhtä R:n tuplaa kohti. Lisäksi S:ään pitää sijoittaa vierasavaimeksi taulun R pääavain Z, jotta tiedetään, mihin tuplaan taulussa R uuden taulun S tuplat liittyvät. Taulun S pääavain koostuu siten attribuuttien Z ja B yhdistelmästä.

7 Yrityksen tietokannassa osastoon liittyvä attribuutti TOIMIPISTEET oli ER-mallissa moniarvoinen: yhdellä osastolla voi olla monta toimipistettä. Koska moniarvoisia attribuutteja ei hyväksytä relaatiomallissa, pitää perustaa uusi taulu DEPT_LOCATIONS, 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 toimipisteitä tietokannassa, jos koko osasto lakkautetaan! Esimerkkiyrityksessämme ei esiintynyt laisinkaan astetta 2 korkeampia asteita olevia relaatioita. Viimeinen mallin kuvausvaiheista koskee tällaisten suhteiden kuvaamista relaatiomalliin sopiviksi. VAIHE 7: Jokaista vähintään astetta 3 olevaa suhdetta R varten perustetaan uusi relaatiotaulu S, johon sijoitetaan kaikkien suhteeseen R osallistuvien taulujen E pääavainattribuutit. Lisäksi R:lle ominaiset lisäattribuutit sijoitetaan S:ään. Taulun S pääavain muodostuu kaikkien taulujen E pääavainten yhdistelmästä pois lukien kuitenkin ne taulut, joiden kohdalla lukumääräsuhteena on 1.

8 Tarkastellaan kirjan kuvaa 7. 3, joka kuvaa esimerkin 4
Tarkastellaan kirjan kuvaa 7.3, joka kuvaa esimerkin 4.11 mukaista tilannetta, jossa muodostettiin astetta 3 oleva relaatio tavaran, sen toimittajan ja sitä tarvitsevan projektin välillä – relaation pääavain muodostuu jokaisen suhteeseen osallistuvan taulun pääavainten yhdistelmästä. Jos kuitenkin tiedettäisiin esimerkiksi, että vain yksi toimittaja pystyy toimittamaan kutakin osaa, ei tietoa toimittajasta ole tarpeen sisällyttää suhdetta kuvaavan relaatiotaulun pääavaimeen, sillä toimittaja pystytään identifioimaan toimitettavan osan numerosta. 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 toimittaja ( projekti voitaisiin päätellä toimittajan perusteella ). ER- ja relaatiomallien välinen pääasiallinen ero on, että ER-mallissa entiteettityyppien väliset suhteet esitellään aina eksplisiittisesti, kun taas relaatiomallissa 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 R osallistuvat entiteettityyppien S ja T esiintymät yhdistetään toisiinsa yhtäsuuruusliitoksen avulla S:n attribuutille A ja T:n attribuutille B. Liitosehto toteutuu, kun S.A = T.B, ja S.A  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ämiseen vaaditaan 2 liitosta ( vrt. TYÖTUNNIT ). Astetta n olevan suhteen esittämistä varten tarvitaan n liitosta. Liitosten muodostamisessa kannattaa olla varovainen. Pitää huolehtia siitä, että liitosattribuuteista toinen on taulun S pääavain ja toinen taulun T vierasavain. Muulla tavalla toteutettu liitos saattaa tuottaa tulostauluun virheellistä tietoa sisältäviä ns. ’valetuplia’. Esimerkki: muodostetaan liitos taulujen PROJEKTI ja TOIMIPISTEET välille käyttämällä liitosattribuuttina sijaintipaikkakuntaa, eli PLOCATION = DLOCATION. Koska kyseiset attribuutit eivät muodosta pääavain-vierasavain –paria, päätyy tulostauluun järjettömiä tuplien yhdistelmiä, joissa eri tauluista valitut tuplat eivät millään mielekkäällä tavalla liity toisiinsa. Kannattaa lisäksi huomioida, että jokaista tietokannassa esiintyvää moniarvoista attribuuttia varten pitää perustaa oma taulunsa.

10 7.1.2. Rakenneosien vastaavuus ER- ja relaatiomallin välillä
Seuraavassa yhteenveto, miten ER-mallin rakenneosat muunnetaan vastaamaan relaatiomallia. ER-malli Relaatiomalli Entiteettityyppi Entiteettityyppiä kuvaava relaatiotaulu Suhde 1:1 tai 1:N Vierasavain ( tai erillinen relaatiotaulu ) Suhde M:N Erillinen relaatiotaulu, jossa 2 vierasavainta Astetta n oleva suhde ( n > 2 ) Erillinen relaatiotaulu, jossa n vierasavainta Yksinkertainen attribuutti Attribuutti Koosteinen attribuutti Joukko yksinkertaisia attribuutteja Entiteettityypin E moni Relaatiotaulu, jossa avainattribuutteina A:n arvoinen attribuutti A sekä taulun E pääavaimen yhdistelmä Arvojoukko Määrittelyjoukko Avainattribuutti Pää- tai toisioavain

11 7.2. EER-mallin rakenneosien kuvaaminen relaatiomalliin
Kirjan luvussa 7.1 tarkasteltiin ER-mallin rakenneosien kuvaamista relaatiomalliin sopiviksi. Tässä luvussa tarkastellaan EER-malliin mukaisten lisäominaisuuksien kuvaamista relaatiomalliin. Näitä ominaisuuksia ovat luokka- aliluokkarelaatiot sekä kategoriat. Yleistämisen ja erikoistamisen kuvaaminen relaatiomalliin Aloitetaan EER-mallin muuntamisen tarkastelu tutkimalla kirjan esimerkkien 4.5 ja 4.6 mukaisia tilanteita. Käytettäessä EER-mallin mukaista käsitteellistä kuvausta pitää kohdassa 7.1 esitetty 7-vaiheinen algoritmi pidentää 9-vaiheiseksi. VAIHE 8: Esitellään neljä optiota, joiden avulla voidaan luokka-aliluokka suhteet muuntaa relaatiomalliin sopiviksi. Olkoot EER-mallin mielivaltaisen luokan C attribuutit { k, a1, a2, ..., an }, missä k on kyseisen luokan avainattribuutti, ja edustakoon luokan C aliluokkia joukko { S1, S2, S3, ..., Sm }. Tällöin jokainen C:n erikoistaminen aliluokkiinsa pitää muuntaa relaatiomallin mukaiseksi jollain seuraavista tavoista:

12 Optio 8A: Useita relaatiotauluja, joista yksi yliluokkaa C varten
Perustetaan relaatiotaulu L, johon sijoitetaan kaikki C:n attribuutit. Taulun pääavaimeksi tulee selvästikin C:n pääavain. Jokaista C:n aliluokkaa Si ( 1 ≤ i ≤ m ) kohti perustetaan relaatiotaulu Li, johon sijoitetaan attribuuteiksi C:n pääavain k sekä kaikki kyseisen aliluokan erikoisattribuutit. Taulun pääavaimeksi valitaan k. Tätä optiota voidaan soveltaa aina riippumatta erikoistamisen tyypistä ( täydellinen tai osittainen ― erillinen tai päällekkäinen ) Optio 8B: Useita relaatiotauluja, mutta yksistään aliluokkia varten Perustetaan relaatiotaulu Li jokaista luokan C aliluokkaa Si ( 1 ≤ i ≤ m ) kohti. Attribuuteiksi tauluun Li valitaan kaikki C:n sekä sen erikoistetun aliluokan Si attribuutit. Kunkin perustettavan taulun pääavaimeksi valitaan k. Optiota 8B voidaan soveltaa vain, jos erikoistaminen on täydellistä, eli jokainen luokan C edustaja kuuluu ainakin yhteen sen aliluokista, sillä pelkästään yliluokkaan kuuluvat C:n edustajat jäisivät tässä ratkaisumallissa kirjaamatta kokonaan. Lisäksi, jos erikoistaminen ei ole erillistä, aiheutuu redundanssia, koska C:n attribuuttien arvot joudutaan toistamaan kaikille niille aliluokille, joita sen tupla edustaa.

13 Optio 8C: Yksi relaatiotaulu, joka sisältää yhden tyyppiattribuutin
Perustetaan relaatiotaulu L, johon sijoitetaan kaikki C:n sekä kaikki sen aliluokkien Si ( 1 ≤ i ≤ m ) attribuutit. Taulun pääavaimeksi valitaan k. Näiden lisäksi tauluun sijoitetaan yksi ns. tyyppiattribuutti t, jonka saama arvo väliltä [1..m] osoittaa, mihin C: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ä, mikäli erikoistaminen määräytyy suoraan jonkin yliluokan attribuutin saaman arvon perusteella. Tätä optiota voidaan soveltaa ainoastaan silloin, kun erikoistaminen aliluokkiin on tyypiltään erillistä, eli yksi yliluokan edustaja voi kuulua kerrallaan vain yhteen aliluokkaan. Ratkaisu tuottaa useita NULL-arvoja, mikäli luokalla on useita aliluokkia ja / tai aliluokilla on useita paikallisia attribuutteja. Optiolla saavutettava etu on kuitenkin se, ettei tauluja tarvita luokka-aliluokkarelaation esittämiseksi yhtä enempää.

14 Optio 8D: Yksi relaatiotaulu, jossa useita tyyppiattribuutteja
Perustetaan relaatiotaulu L, johon sijoitetaan kaikki C:n sekä kaikki sen aliluokkien Si ( 1 ≤ i ≤ m ) attribuutit. Taulun pääavaimeksi valitaan k. Lisäksi jokaista C:n aliluokkaa Si ( 1 ≤ i ≤ m ) kohti perustetaan tyyppiattribuutti ti, jonka arvo on loogista tyyppiä ( tosi / epätosi ) ja joka osoittaa, edustaako entiteetin tupla aliluokkaa Si vai ei. Usean tyyppiattribuutin asemesta voitaisiin optiota 8D varten ottaa käyttöön yksi m-bittinen tyyppiattribuutti, jonka i. bitti kertoo, kuuluuko tupla C:n i:nteen aliluokkaan Si vai ei ( 0 = epätosi, 1 = tosi ). Tätä optiota on tarkoitettu sovellettavaksi lähinnä päällekkäistä erikoistamista ajatellen, mutta se kelpaa yhtäläisesti erilliseen erikoistamiseen. Myös tämän ratkaisun etuna on yhden taulun riittävyys relaation esittämiseen, mutta nytkin NULL-arvojen määrä tulee suureksi, mikäli on yleistä, että yksittäinen C:n edustaja ei kuulu moneen aliluokkaan samanaikaisesti.

15 Optioista 8A ja 8B käytetään toteutustapansa mukaisesti nimitystä usean relaation optiot, kun taas vaihtoehdot 8C ja 8D ovat yhden relaation optioita. Optiossa 8A muodostetaan relaatio yliluokan ja jokaisen aliluokkansa välillä yhtäsuuruusliitoksella pääavaimen k arvon mukaisesti. 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ä mielivaltaista C:n tuplaa joudutaan haku kohdistamaan kaikkiin tauluihin Li, jotka edustavat C:n luokka-aliluokka -relaatioita. Kaikki C:n tuplat saadaan muodostamalla kaikkien taulujen Li täysi ulkoinen liitos tai ulkoinen unioni. Tällä tavoin saatu tulostaulu näyttäisi samalta kuin optioiden 8C ja 8D mukainen, mutta ilman tyyppiattribuutteja. Tarkastellaan kirjan esimerkkiä 7.4b. Option 8C mukainen toteutus on nähtävillä kirjan esimerkissä 7.4c. Siinä aliluokkaan kuuluminen määräytyy yksikäsitteisesti attribuutin 'TyönTyyppi' mukaisesti.

16 7.2.2 Kategorioiden ( eli unionityyppien ) kuvaaminen relaatiomalliin
Optio 8C ei kuitenkaan kelpaa ratkaisuksi, jos työntekijä voisi kuulua useaan ammattiryhmään samanaikaisesti. Tällöin jokaista erikoistettua työtyyppiä varten pitäisi olla tyyppiattribuutti seuraavaan tapaan: 'OnkoInsinööri?', 'OnkoTeknikko?', 'OnkoSihteeri?' jne. Tähän tarkoitukseen kelpaa optio 8D. Tarkastellaan vielä kirjan esimerkkiä 7.4d. Mikäli erikoistamisella on useita tasoja, ei ole mitenkään välttämätöntä käyttää jokaisella tasolla samaa 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 'HENKILÖ' ylimmälle erikoistamistasolle on sovellettu optiota 8A ( täydellinen osittainen erikoistaminen ), luokalle TYÖNTEKIJÄ optiota 8C ( täydellinen erillinen erikoistaminen ) ja luokalle OPISKELIJA optiota 8D ( sekä täydellistä että osittaista erikoistamista ). Kategorioiden ( eli unionityyppien ) kuvaaminen relaatiomalliin Entiteettityyppiä kutsutaan kategoriaksi, mikäli se on muodostettu usean eri entiteettityypin unionioperaatiolla. Kategoriat esiteltiin edellä kappaleessa 4.4. Kategorioiden esittämiseksi relaatiomallin avulla tarvitaan kappaleen algoritmiin vielä yksi lisäkohta ― vaihe 9.

17 VAIHE 9: Jokaista sellaista kategoriaa kohti, joka koostuu entiteettityypeistä, joilla on eri avainattribuutti, perustetaan taulu, jonka pääavaimeksi asetetaan ns. sijaisavain, 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 muunnetaan relaatiomalliin kelvolliseksi. Perustetaan taulu OMISTAJA, joka sisältää pelkästään tunnistenumeron, jota tarvitaan unionin ylläpitämiseksi. Vierasavainkenttä kyseistä tunnistenumeroa varten lisätään kaikkiin unionin muodostaviin entiteettityyppeihin eli tyypeille HENKILÖ, PANKKI ja YHTIÖ. Relaation OMISTAMINEN esittämiseksi perustetaan myös erillinen relaatiotaulu, jossa pääavain muodostuu omistajan tunnistenumeron ja kulkuneuvon valmistenumeron yhdistelmästä. Kannattaa huomioida, että omistajan tunnistenumeroksi tulee NULL jokaisella sellaisella henkilöllä, pankilla ja yhtiöllä, jotka eivät satu omistamaan mitään kulkuneuvoa. Lisäksi kannattaa huomioida, ettei henkilö- ja kuorma-autoista muodostetun kategorian esittämiseksi tarvita erillistä sijaisavaintaulua, sillä kummankin unioniin osallistuvan entiteettityypin pääavain on keskenään yhteensopiva.