Käsitteellinen mallintaminen

Tietokantajärjestelmän suunnittelun ensimmäisiin vaiheisiin kuuluu käsitteellinen mallintaminen. Käsitteellistä mallintaminen voidaan mieltää kuuluvaksi tietojärjestelmän elinkaaren analyysi- ja suunnitteluvaiheisiin. Tässä vaiheessa kohdealueen vaatimusmäärittelyn perusteella mallinnetaan, mitä tietoa tietokantaan tallennetaan ja miten eri tieto liittyy toisiinsa. Käsitteellinen mallintaminen on tietomalliriippumaton, eli tässä vaiheessa ei vielä mietitä, mitä DBMS:ää tai tietomallia lopullinen tietokantajärjestelmä käyttää.

Tässä alaluvussa tarkastellaan käsitteellistä mallintamista käyttäen ER-mallia (Entity-Relationship model). ER-notaatio on suosittu tietokantojen alustavan suunnittelun työkalu. Luvussa oletetaan, että lukija tuntee analyysivaiheen UML-luokkakaavion (Unified Modeling Language) perusperiaatteet ja osaa luoda sellaisen.

ER-mallien merkintätavalle ei ole virallista standardia. Tästä huolimatta miltei kaikki käsitteellisen mallin merkintätavat pohjautuvat Chenin [5] esittämään notaatioon. Tällä kurssilla tutustutaan ja käytetään Jukić ym. [22] esittämää notaatiota, joka hieman yhdistetty ja selkeytetty versio Chenin [5], Elmasrin ja Navathen [15] sekä Hoffer, Prescott ja McFaddenin [19] notaatiosta.

Huomautus

Käsitteellisen mallintamisen ydintavoite on erottaa, mikä data on tietokannan kannalta oleellinen ja mikä ei.

Käsitteellinen mallintaminen on siten joksikin yksilöllistä; eri suunnittelijat saattavat tuottaa samalle vaatimusmäärittelylle hieman erilaisia käsitteellisiä malleja.

Kohdetyypit ja attribuutit

ER-malli koostuu kohdetyypeistä (entity set), suhdetyypeistä (relationship set) ja attribuuteista (attribute). Kohdetyypit muistuttavat luokkakaavion luokkia: ne kuvaavat jotakin itsenäistä, reaalimaailman konkreettista tai käsitteellistä asiaa eli kohdetta, esimerkiksi opiskelijaa, kurssia tai opintosuoritusta. Kohdetyyppi on kohdealueen kannalta mielenkiintoinen, eli siitä halutaan tallentaa tietoa tietokantaan. Kohdetyyppi ei ole vain yksi reaalimaailman asia, kuten "Matti" tai "Pankkitili #123", vaan kuvaa abstrahoidun asioiden joukon, kuten "Ihminen" tai "Pankkitili", ominaisuuksineen kuten luokkakaavion luokka.

Kohdetyypeillä voi olla attribuutteja, jotka ovat kohteiden kohdealueen kannalta mielenkiintoisia ominaisuuksia. Esimerkiksi opiskelijalla voi olla opiskelijatunnus, nimi ja syntymäaika. Attribuutin arvo on yksittäisen kohteen tai suhteen ominaispiirre.

Kuvio: Kohdetyyppi OPISKELIJA attribuutteineen. Tämä kohdetyyppi opiskelija kuvaa siis kaikkien tietokantaan tallennettavien opiskelijoiden joukon ominaisuuksineen. — Kuvio: Kohdetyyppi `OPISKELIJA` attribuutteineen. Tämä kohdetyyppi *opiskelija* kuvaa siis kaikkien tietokantaan tallennettavien opiskelijoiden joukon ominaisuuksineen.

Kohdetyyppiä merkitään suorakulmiolla, jonka sisällä on kohdetyypin nimi. Kohdetyypin attribuutteja merkitään soikiolla, jonka sisällä on attribuutin nimi. Kohdetyyppien tai attribuuttien nimien kirjoitusasulla ei ole väliä. Selkeyden vuoksi tässä materiaalissa kohdetyypit pyritään kirjoittamaan isolla (esim. OPISKELIJA) ja attribuutit isolla alkukirjaimella ilman välilyöntiä (ns. PascalCase; esim. Etunimi, SyntAika). Pieniä eroja voi olla kuvissa ja videoissa; kirjoitusasulla ei loppujen lopuksi ole merkitystä tietokannan suunnittelun tai toiminnan kannalta.

Avainattribuutti

Jokaisen kohdetyypin kuvaaman kohteen on oltava yksiselitteisesti tunnistettavissa toisistaan. Tunnistaminen tehdään tavallisesti jonkin sellaisen attribuutin perusteella, jonka arvo on jokaisella kohteella yksikäsitteinen.

Esimerkki

Esimerkiksi yliopiston opiskelijarekisterissä (vrt. Sisu) opiskelijoita mallintavassa OPISKELIJA-kohdetyypissä opiskelijan nimi ei ole tarpeeksi yksikäsitteinen yksittäisen opiskelijan tunnistamiseksi.

Sen sijaan opiskelijatunnus tai Suomessa käytetty opiskelijan numero voi sen sijaan olla tietokannan laajuudesta riippuen riittävä tieto opiskelijan tunnistamiseksi.

Tällaista attribuuttia tai -joukkoa, joiden avulla kohdetyypin yksittäistä kohdetta voi yksilöllisesti tunnistaa, kutsutaan avainattribuutiksi (key attribute). Jos yhden attribuutin arvo ei riitä tunnistamaan kohteita toisistaan, voidaan käyttää useampaa kuin yhtä attribuuttia kuitenkin niin, että avainattribuuttien aito osajoukko ei riitä tunnistamaan kohteita toisistaan.

Esimerkki

Yliopiston opiskelijarekisterissä opiskelijoita mallintavassa OPISKELIJA-kohdetyypissä opiskelijan tunnus Optun on sopiva avainattribuutti, sillä opiskelijan tunnus voi yksilöidä opiskelijaa rekisterin sisällä. Sen sijaan attribuuttijoukko {Optun, Etunimi} ei ole hyvä avainattribuuttijoukko, sillä sen aito osajoukko {Optun} riittää jo opiskelijan yksilöimiseksi.

Huomaa, että yksilöiminen riittää aina kohdealueen tietokannan tasolla: eri yliopiston rekisterissä toisella opiskelijalla voisi periaatteessa olla sama tunnus. Olennaista on, että avainattribuutti yksilöi opiskelijan saman tietokannan sisällä.

Avainattribuutin arvo ei voi olla tyhjäarvo. Kohdetyypin avainattribuutit tunnistetaan niiden nimien alleviivauksesta.

Koottu attribuutti

Kootulla (composite) attribuutilla tarkoitetaan attribuuttia, jonka arvo voidaan jakaa tunnistettaviin osiin. Osiin jakaminen on erityisen perusteltua silloin, kun attribuuttiin viitataan sekä kokonaisuutena että osina. Esimerkiksi attribuutti Osoite voidaan alla olevan kuvion mukaan jakaa osiin Katu, PostiNro ja Kaup. Jos esimerkiksi osoitteeseen viitattaisiin aina kokonaisuutena, ei osiin jakaminen olisi perusteltua.

Jos attribuutti ei ole koottu, se on yksinkertainen (simple). Kootut attribuutit voivat muodostaa syvempiäkin hierarkioita.

Johdettu attribuutti

Johdetulla (derived) attribuutilla tarkoitetaan attribuuttia, jonka arvo on johdettu joko

toisen attribuutin tai attribuuttien arvoista tai
siihen liittyvän kohdetyypin kohteiden lukumäärästä.

Kuvio: Kohdetyypin OPISKELIJA johdetut attribuutit Ikä ja OpiskLkm. Attribuutti Ikä on johdettu attribuutista SyntAika ja OpiskLkm kohteiden lukumäärästä. — Kuvio: Kohdetyypin `OPISKELIJA` johdetut attribuutit `Ikä` ja `OpiskLkm`. Attribuutti `Ikä` on johdettu attribuutista `SyntAika` ja `OpiskLkm` kohteiden lukumäärästä.

Jos attribuutti ei ole johdettu, se on tallennettu (stored).

Moniarvoinen attribuutti

Tavallisesti attribuuteilla on yksi arvo, ja tällaisia attribuutteja kutsutaan atomisiksi (atomic). On kuitenkin mahdollista, että kohdetyypin kohteiden attribuuteilla voi olla useampia arvoja, esimerkiksi opiskelijalla voi olla useita puhelinnumeroita tai sähköpostiosoitteita. Jos attribuutilla voi olla useampia arvoja, sitä kutsutaan moniarvoiseksi (multivalued).

Kuvio: Kohdetyypin OPISKELIJA moniarvoiset attribuutit Puh ja Sposti. — Kuvio: Kohdetyypin `OPISKELIJA` moniarvoiset attribuutit `Puh` ja `Sposti`.

Moniarvoista attribuuttia merkitään yllä olevan kuvion mukaisesti kaksinkertaisella soikiolla.

Suhdetyypit

Kohteilla kuten reaalimaailman asioillakin on tyypillisesti jonkinlaisia suhteita keskenään. Suhde (relationship) on mikä tahansa yhden tai useamman kohteen välillä vallitseva riippuvuus tai muu kohdealueen kannalta kiinnostava asiayhteys. Suhteiden joukot muodostavat suhdetyyppejä (relationship set). Tietokantaa suunnitellessa relevantit suhteet kohteiden välillä on tunnistettava ja kuvattava ne ER-kaavioon.

Suhdetyyppejä kuvataan ER-notaatiossa vaakasuunnassa käännetyllä salmiakkikuviolla, joka on liitetty suhteeseen osallistuviin kohdetyyppeihin. Suhdetta kuvataan tavallisesti jollakin yksikön 3. persoonan verbillä. Tässä materiaalissa suhteet pyritään kirjoittamaan samalla kirjoitusasulla kuin attribuutit, eli isolla alkukirjaimella ja ilman välilyöntejä (ns. PascalCase). Kuten aiemminkin, pieniä eroja voi löytyä kuvissa ja videoissa; käytännön merkitystä kirjoitusasulla ei ole.

Kuvio: Kohdetyyppien OPISKELIJA ja KURSSI välinen suhdetyyppi Suorittaa. Suhdetyyppiin liittyy attribuutti SuoritusPvm kuvaamaan kurssin suorituksen päivämäärää. — Kuvio: Kohdetyyppien `OPISKELIJA` ja `KURSSI` välinen suhdetyyppi `Suorittaa`. Suhdetyyppiin liittyy attribuutti `SuoritusPvm` kuvaamaan kurssin suorituksen päivämäärää.

Myös suhdetyypeillä voi olla attribuutteja. Suhdetyypin attribuutit kuvaavat jotakin suhteen ominaisuutta, esimerkiksi yllä olevan esimerkin SuoritusPvm. Suorituspäivämäärä ei liity kohdetyyppiin KURSSI, eikä kohdetyyppiin OPISKELIJA, vaan kohdetyyppien väliseen suhteeseen.

Suhteen asteluku

Suhdetyypin, johon osallistuu kohdetyyppiä, sanotaan olevan asteluvultaan (degree) . Yllä kuvatun suhdetyypin asteluku on 2, ts. suhdetyyppi on binäärinen. Kahdella kohdetyypillä voi olla keskenään useampi kuin yksi binäärinen suhdetyyppi. Suhdetyypin asteluku voi olla mikä tahansa kokonaisluku 1..n. Alla on kuvattu unaarinen (asteluku 1) ja tertiäärinen (asteluku 3) suhdetyyppi.

Kuvio: Kaksi erillistä ER-kaaviota. Vasemmalla unaarinen suhde (suhteeseen kuuluu yksi kohdetyyppi) ja oikealla tertiäärinen suhde (suhteeseen kuuluu kolme kohdetyyppiä).

Yllä olevan kuvion mukaan työntekijä voi olla esimies muille työntekijöille. Toisessa esimerkissä kohdealueen kannalta on tärkeää, että tiedetään kuka opettaja opiskelijan kurssisuorituksen on arvostellut.

Huomautus

Asteluvultaan kahta korkeammilla suhdetyypeillä on omat ongelmansa, eikä niitä juurikaan tässä materiaalissa käsitellä.

Yllä olevan esimerkin voisi toteuttaa heikolla kohdetyypillä ARVOSTELU. Heikkoa kohdetyyppiä käsitellään hieman myöhemmin.

Kardinaliteetti

Kardinaliteetti (tai kardinaalisuus) kertoo, kuinka moneen tietyn tyyppiseen suhteeseen kohde osallistuu tai voi osallistua. Kardinaalisuuksia on kahdenlaista: minimikardinaalisuus (eli pakollisuus) kertoo pienimmän tarvittavan kohteiden määrä suhteeseen, kun taas maksimikardinaalisuus kertoo suurimman sallitun kohteiden määrän.

Tässä materiaalissa käsitellään notaatio, jossa minimikardinaalisuus on joko 0 tai 1 ja maksimikardinaalisuus on joko 1 tai N. Toisin sanoin kohdetyypin kardinaalisuus suhteessa voi esittää neljällä tavalla:

	Max. 1	Max. N
Min. 0
Min. 1

Kohdetyypin kardinaalisuus merkitään sille puolelle suhdetta, johon päin luetaan.

Esimerkki

Mietitään kardinaalisuuksia seuraavassa kohdealueessa: halutaan suunnitella autorekisteri, jossa pidetään kirjaa autoista ja niistä omistavista henkilöistä.

Tässä tapauksessa on kaksi kohdetyyppiä HENKILÖ ja AUTO sekä niiden välinen suhde Omistaa. Suhteen kardinaliteetti on kohdealueen perusteella järkevintä valita seuraavasti:

Henkilö ei välttämättä omista autoa, mutta voi omistaa useita. Siispä minimikardinaalisuus on 0 ja maksimikardinaalisuus on N.
Auton voi omistaa vain yksi henkilö ja tasan yksi henkilö. Minimikardinaalisuus siten 1 ja maksimikardinaalisuus on 1.

Käyttämällä yllä olevaa taulukkoa avuksi saadaan seuraava ER-malli:

Kuvio: Kohteiden HENKILÖ ja AUTO välinen suhde Omistaa kardinaliteettimerkintöineen. — Kuvio: Kohteiden `HENKILÖ` ja `AUTO` välinen suhde `Omistaa` kardinaliteettimerkintöineen.

Huomioi lukusuunta:

Vasemmalta oikealle: "Henkilö omistaa nollasta moneen autoa"
Oikealta vasemmalle: "Autoa voi omistaa vähintään yksi ja korkeintaan yksi henkilö"

Lukusuunta on merkitty selkeämmin alle:

Merkintöjä voi miettiä esimerkkikohteiden kautta. Kuvitellaan seuraava esimerkki, jossa on kolme henkilöä ja neljä autoa. Tällöin auton ja henkilön omistussuhde voisi näyttää seuraavalta:

Koska jokaisesta autosta mene aina yksi viiva johonkin henkilöön, valitaan HENKILÖ-kohdetyypin puolelle minimikardinaalisuus 1 (pystyviiva) ja maksimikardinaalisuus 1 (pystyviiva). Vastaavasti, koska jostain henkilöstä ei lähde mitään viivaa autoon, valitaan AUTO-kohdetyypin puolelle minimikardinaalisuus 0 (ympyrä). Koska yhdestä henkilöstä lähtee useampi viiva eri autoon, maksimikardinaalisuus on N (haarautuvat viivat).

Huomautus

Yllä kuvattu kardinaliteetin merkintätapa on ns. Hoffer-Prescott-McFadden notaatio, joka on suosittu monissa tietokannanhallintajärjestelmien rinnalla käytetyissä 3. osapuolen suunnittelutyökaluissa.

Muita yleisesti käytettyjä kardinaalisuusnotaatiota on kuvattu alla: vasemmalla Chenin notaatio, keskellä UML:ää muistuttava notaatio ja oikealla materiaalissa käytetty Hoffer, Prescott & McFaddenin notaatio.

Kuvio: Erilaisia kardinaalisuusnotaatioita: Chen [5]; UML [32]; Hoffer, Prescott & McFadden [19].

Heikko kohdetyyppi ja tunnistava suhdetyyppi

Jos kohdetyypin mukaisia kohteita ei voida tunnistaa sen omien attribuuttien avulla, sitä sanotaan heikoksi kohdetyypiksi (weak entity set). Heikkoa kohdetyyppiä merkitään kaksoissuorakulmiolla. Heikon kohdetyypin mukaiset kohteet tunnistetaan toisen kohdetyypin avainattribuutteja hyväksi käyttäen, ja tällaista kohdetyyppiä kutsutaan tunnistavaksi kohdetyypiksi (identifying entity set). Tunnistava kohdetyyppi kuvataan tunnistavan suhdetyypin (identifying relationship set) avulla. Tunnistava suhdetyyppi kuvataan kaksoissalmiakilla.

Kuvio: Heikko kohdetyyppi OSASTO ja tunnistava kohdetyyppi YRITYS. — Kuvio: Heikko kohdetyyppi `OSASTO` ja tunnistava kohdetyyppi `YRITYS`.

Yllä olevassa kuviossa heikko kohdetyyppi OSASTO tunnistetaan vahvan kohdetyypin YRITYS avulla. Heikon kohdetyypin avainattribuutin nimi alleviivataan katkoviivalla. Yllä kuvatun kohdealueen osastot tunnistetaan siis osaston tunnuksen ja yritystunnuksen yhdistelmällä. Toisin sanoin tietokannassa voi olla kaksi osastoa, jolla on sama osastotunnus Ostun, mutta ne kuuluvat eri yritykseen. Siispä attribuuttijoukolla {YTun, Ostun} voi tunnistaa osasto yksikäsitteisesti.

Huomautus

Heikon kohdetyypin maksimikardinaalisuus tunnistavassa suhdetyypissä yleensä tulee olla aina korkeintaan 1.

Tämä ei ole rajoite, vaan pikemmin vahva suositus. Yllä olevassa kuviossa osasto voi kuulua aina korkeintaan yhteen yritykseen, ja osasto voidaan yksilöllisesti tunnistaa sen yrityksen tunnuksen ja osaston tunnuksen kautta.

Mitä jos osasto saisikin kuulua kahteen eri yritykseen? Miten osasto silloin tunnistettaisiin? Voidaanko osasto silloin yksilöllisesti tunnistaa kahdella tavalla: {YTun1, Ostun} ja {YTun2, Ostun}? Vai tarvitaanko osaston tunnistamiseksi kummankin yrityksen tunnukset: {YTun1, YTun2, Ostun}. ER-notaatio ei tarjoa eri vaihtoehdoille selkeitä merkintöjä, eikä näitä saa helposti muunnettua tietokannan loogiseksi rakenteeksi. Siispä on parempi ottaa nyrkkisääntö, että heikko kohdetyyppi voi kuulua korkeintaan 1 kertaa tunnistavaan suhteeseen.

Vältä tätä: ER-mallin mukaan OSASTO-kohdetyypin tunnistamiseksi voidaan tarvita N yritystä. Tämän mallintaminen loogisella tasolla on hankalaa. — **Vältä tätä**: ER-mallin mukaan `OSASTO`-kohdetyypin tunnistamiseksi voidaan tarvita N yritystä. Tämän mallintaminen loogisella tasolla on hankalaa.

Tällaisissa tapauksissa voi olla helpompaa muutta heikko kohdetyyppi tavalliseksi kohdetyypiksi.

Abstraktiorakenteet

ER-notaatiota on myöhemmin täydennetty. Yksi tällaisista täydennyksistä on nk. EER-notaatio (extended tai enhanced ER), joka lisää notaatioon mm. abstraktiorakenteet. Abstraktiorakenteiden avulla voidaan mallintaa hierarkioita ja oliosuuntautuneisuuden mukaista perintää: alikohdetyypit perivät ylikohdetyyppinsä attribuutit. Kohdetyyppien välistä perintää merkitään seuraavan kuvion mukaisesti.

Kuvio: Alikohdetyypit HENKILÖKUNTA ja OPISKELIJA perivät ylikohdetyypin HENKILÖ attribuutit. — Kuvio: Alikohdetyypit `HENKILÖKUNTA` ja `OPISKELIJA` perivät ylikohdetyypin `HENKILÖ` attribuutit.

Ylikohdetyyppinä on kuviossa HENKILÖ, alikohdetyyppeinä OPISKELIJA ja HENKILÖKUNTA. U-kirjaimen muotoiset merkinnät osoittavat alikohdetyyppeihin. Ympyrän yhdistää ylikohdetyyppiin joko yksi tai kaksi viivaa riippuen alikohteiden kattavuudesta. Abstraktiorakenteet voivat muodostaa monimutkaisempiakin hierarkioita.

Ympyrän sisälle on merkitty joko kirjain d tai o riippuen siitä, onko abstraktio erillinen (disjoint) tai leikkaava (overlapping). Tarkastellaan seuraavaksi näitä kahta erilaista EER-notaation mukaista yleistysrakennetta.

Erillinen

Erillisellä (disjoint) abstraktiorakenteella tarkoitetaan, että alikohteet voivat kuulua korkeintaan yhteen alikohdetyyppiin (ns. joko-tai -abstraktio). Esimerkiksi AJONEUVO voi olla joko AUTO tai VENE. Erillistä abstrahointia merkitään ympyrän sisälle sijoitetulla kirjaimella d.

Alikohdetyyppijoukon kattavuutta kuvataan yhdellä tai kahdella viivalla ympyrän ja ylikohdetyypin välillä:

yksi viiva (osittainen abstraktio): tietyn kohteen ei tarvitse olla yhdenkään alikohdetyypin mukainen kohde (esim. kohdealueessa voi esiintyä ajoneuvoja, jotka eivät ole autoja eikä veneitä, kuten moottoripyörät);
kaksi viivaa (kattava abstraktio): kaikki kohteet kuuluvat johonkin kohdetyyppiin (esim. kohdealueessa kaikki esiintyvät ajoneuvot ovat joko autoja tai veneitä).

Alla oleva kuvio kiteyttää, mitä kohteita erillinen ja kattava sekä erillinen ja osittainen abstraktiorakenne voi mallintaa.

Kuvio: Vasemmalla erillinen ja kattava yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet A voi olla joko B tai C"). Oikealla erillinen ja osittainen yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet A voi olla B tai C tai jotakin muuta"). — Kuvio: Vasemmalla erillinen ja kattava yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet `A` voi olla joko `B` tai `C`"). Oikealla erillinen ja osittainen yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet `A` voi olla `B` tai `C` tai jotakin muuta").

Leikkaava

Leikkaavalla (overlapping) abstraktiorakenteella tarkoitetaan, että alikohteet voivat kuulua useampaan kuin yhteen alikohdetyyppiin (ns. "sekä-että" -abstraktio). Esimerkiksi huone sekä keittiö että ruokasali. Leikkaavaa abstraktiorakennetta kuvataan ympyrän sisään sijoitetulla kirjaimella o. Kuten erillinen, myös leikkaava abstraktiorakenne on joko kattava tai osittainen. Esimerkiksi:

yksi viiva (osittainen abstraktio): kohdealueessa voi esiintyjä ajoneuvoja, jotka ovat joko autoja, veneitä tai molempia tai jotakin muuta;
kaksi viivaa (kattava abstraktio): kohdealueessa kaikki ajoneuvot ovat joko autoja, veneitä tai molempia.

Kuvio: Vasemmalla leikkaava ja kattava yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet A voivat olla B tai C tai molempia samaan aikaan"). Oikealla leikkaava ja osittainen yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet A voivat olla B, C, molempia tai jotakin muuta"). — Kuvio: Vasemmalla leikkaava ja kattava yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet `A` voivat olla `B` tai `C` tai molempia samaan aikaan"). Oikealla leikkaava ja osittainen yleistyssuhde ja kohteiden suhde toisiinsa ("kohteet `A` voivat olla `B`, `C`, molempia tai jotakin muuta").

Monivalintatehtävät liittyvät seuraavaan ER-kaavioon:

# monierm

Käsitteellisen mallintamisen vaiheet

Käsitteelliselle mallintamiselle ei ole tarkkaan standardoitua prosessia. Alla on joitain vinkkejä siitä, miten mallintamista kannattaa lähestyä:

Tee vaatimusmäärittely ellei sitä ole jo. Vaatimusmäärittelystä tulee käydä selväksi kohdealue, toteutettavan järjestelmän tarpeet ja siihen liittyvät keskeiset käsitteet.
Aloita tunnistamalla peruskohdetyypit vaatimusmäärittelystä.
- Etsi muun muassa toistuvia käsitteitä, jotka ovat konkreettiset asiat (esim. tuote, asiakas) taikka käsitteelliset asiat (esim. tilaus, tilausrivi)
- Liittyykö käsitteeseen sellaista tietoa, jota oikeasti halutaan tallentaa tietokantaan?
- Anna kohdetyypeille selkeät nimet ja tarvittaessa kuvaile niiden merkitys.
- Huom: jos jokin tieto on johdettavissa jonkun muun tietokannan tiedon kautta, sitä ei kannata mallintaa. Esimerkiksi erilaiset raportit, tulosteet ja analytiikat voidaan johtaa suoraan muista kohdetyypeistä.
Tunnista seuraavaksi keskeiset suhdetyypit ja niiden kardinaliteetit.
- Keskity suhteisiin, jotka ovat tietokannan kannalta relevantteja.
- Yleisimmät suhteet koskevat olemassaoloa, toimintaa tai tapahtumaa.
- Onko suhde merkillistä tallentaa tietokantaan (esim. kuka tulosti minkä raportin, kuka osti mitäkin)?
- Joudut tekemään mahdollisesti lisäoletuksia kardinaliteettien määrittämiseksi.
Tunnista attribuutit.
- Mitä ominaisuuksia halutaan oikeasti tallentaa tietokantaan?
- Jotkin ominaisuudet voi olla johdettavissa muista ominaisuuksista.
- Valitse sopiva avainattribuutti. Jos sellaista ei löydy, luo jokin Tunnus-attribuutti (esim. juokseva numero, joka yksilöi kohteet).
- Merkitse erikoisattribuutit oikein (moniarvoiset, johdetut, kootut).
Iteroi ja refaktoroi.
- Lisää uusia kohteita, attribuutteja tai suhteita, jotka ilmenevät mallintamisprosessin aikana. Muista tarvittaessa täydentää myös vaatimusmäärittely.
- Voiko kohdetyyppejä ja attribuutteja nimetä paremmin?
- Kuuluvatko jotkin attribuutit paremmin suhteeseen kuin kohdetyyppiin?
- Ovatko kardinaliteetit merkitty kohdealueen kannalta järkevästi?
- Käytä tarvittaessa abstraktiorakenteita selventämään mallia, erityisesti jos usealla kohteella on samoja attribuutteja.

Esimerkki

Tehdään alla olevan kuvauksen mukainen ER-kaavio, josta ilmenevät kohdetyypit, suhdetyypit, olennaisimmat attribuutit, avainattribuutit sekä minimi- ja maksimikardinaalisuudet.

Tietokanta sisältää tietoja asiakkaista: asiakastunnus, nimi, osoite.
Asiakkaan tilaavat tiettyinä päivinä tuotteita, joilla on tuotenumero, tuotenimi ja hinta.
Tilaus tunnistetaan tilausnumerolla.
Tilaus voi koskea useampia tuotteita (tiettyjä määriä).

Tunnistetaan alkuun kaikki peruskohdetyypit (käsitteet, asiat, käsitteelliset asiat), suhdetyypit (käsitteisiin liittyvät relevantit verbit) ja attribuutit (käsitteisiin liittyvät ominaisuudet).

Tunnistetut ER-kaavion osat (avaa klikkaamalla)

Tunnistetut KOHTEET, Attribuutit ja Suhteet merkittynä kuvaukseen:

Tietokanta sisältää tietoja ASIAKAS:ista: Asiakastunnus, Nimi, Osoite.
Asiakkaat Tilaavat tiettyinä päivinä TUOTE:ita, joilla on Tuotenumero, Tuotenimi ja Hinta.
TILAUS tunnistetaan Tilausnumerolla.
Tilaus voi Koskea useampia tuotteita:ita (tiettyjä Määriä).

Kardinaalisuuksia ei voi täysin päätellä annetun kuvauksen perusteella. Tässä tapauksessa tehdään muutama kohdealueen kannalta järkevä lisäoletus:

Asiakas voi olla olemassa ilman tilauksia (esim. verkkokauppa).
Jokaista tilausta tekee tasan yksi asiakas.
Tilauksessa on aina joku tuote (toisaalta: voisiko olla järkevää, että voisi olla? Mieti esim. verkkokauppa, jossa ostoskori on alussa tyhjä.)
Tuotetta ei välttämättä ole ikinä tilattu ennen, eli se ei ole missään tilauksessa.

Näiden perusteella saadaan mallinnettua lopullinen ER-kaavio.

Valmis ER-kaavio (avaa klikkaamalla)

Huomioita:

Pyri pitämään malleja yksinkertaisina. Heikot kohdetyypit, koostetut attribuutit, tertiääriset suhteet usein vaikeuttavat suunnittelua. Paras ratkaisu on yleensä yksinkertaisin!
Vastaavasti, samalle vaatimusmäärittelylle voisi olla moni eri pätevä ER-kaavio. Myöhemmissä luvussa huomataan, että erilaisetkin ER-kaaviot voivat tuottaa lopuksi samanlaisen tietokannan rakenteen.
Vaatimusmäärittelyt ovat harvoin täydellisiä. Mieti, mitä tietoa puuttuu ja tarkenna vaatimusmäärittelyä. Tarvittaessa joudut tekemään kohdealueen tai sovelluksen kannalta järkeviä lisäoletuksia. Tässä esimerkissä esim. TILAUS ei voi olla ilman tuotteita, mutta jossain sovelluksissa tämä voisi olla taas järkevääkin.