3. Tiedon mallintaminen ER-mallin avulla

Esitys aiheesta: "3. Tiedon mallintaminen ER-mallin avulla"— Esityksen transkriptio:

1 3. Tiedon mallintaminen ER-mallin avulla
Tietokannan käyttöönottovaihetta edeltävät aina suunnittelu, toteutus ja sovellusohjelmien testaus. Tietokannan suunnitteluvaihe muistuttaa jonkin verran yleistä ohjelmien suunnittelua. Käsitteellinen mallinnus on tärkeää tietokantasovellusten suunnittelussa. ER ( Entity Relationship ) tarkoittaa kokonaisuuksien välisiä suhteita. ER-malli on korkean tason käsitemalli, jota käytetään yleisesti hyväksi tietokantaa suunniteltaessa.

2 3.1. Korkean tason käsitemalli tietokannan suunnittelun apuvälineenä

3 Eteneminen alkutekijöistä kohti valmista tietokantaa
Tarpeiden kartoittaminen ja analysointi selvitetään käyttäjiltä kysymällä, mitä kaikkia tietoja tietokannassa tulisi olla saatavilla tarpeelliset tiedot ja toiminnot pitäisi selvittää niin tarkoin kuin mahdollista käytetään apuna tietovuokaavioita yms. suunnittelua helpottavia menetelmiä  tavoitteena muodostaa kokonaiskäsitys tiedon ja toimintojen tarpeesta tietokannassa Muodostetaan tietokannan käsitekaava käyttämällä korkean tason tietomallia tarvittavat kokonaisuudet, suhteet ja säännöt määritellään fyysiseen toteutukseen ei oteta tässä vaiheessa kantaa selvitetään, että kaikkien osapuolten tietotarpeet esiintyvät käsitekaavassa ja etteivät eri käyttäjäryhmien asettamat vaatimukset ole ristiriitaisia keskenään jos käsitekaava osoittautuu virheelliseksi tai puutteelliseksi, tehdään tarvittavat muutokset

4 Rinnakkaisesti tai hieman jälkeenpäin voidaan käsitekaavaan perustuen yrittää hahmottaa toiminnallisessa eli funktionaalisessa analyysissä todetut käyttäjien tarvitsemat operaatiot. Jos käsitekaava on riittämätön toimintojen mallintamiseen, sitä voidaan uusia. Kun kaikki tahot ovat tyytyväisiä tietokannan määriteltyihin ominaisuuksiin, on aika aloittaa sen käytännön toteuttaminen ( implementointi ). Tätä vaihetta kutsutaan tietokannan loogiseksi suunnitteluksi. Siinä muunnetaan korkean tason tietomallin mukainen kuvaus TKHJ:lle sopivaan muotoon ( esimerkiksi relaatiomallin mukaiseksi ). Loogisen kaavan valmistuttua voidaan aloittaa kyseiseen kaavaan perustuva sovellusohjelmien suunnittelu sekä tietokannan fyysisen tallennusrakenteen suunnittelu, jonka tuloksena saadaan tietokannan sisäinen kaava.

5 3.2. Esimerkki tietokantasovelluksesta
Sisäiseen kaavaan perustuen voidaan optimoida tietokantaa hyödyntävät valmiit sovellusohjelmat. Sovellusohjelmien valmistuttua tietokannan pitäisi nyt ihannetilanteessa vastata täysin sen kaikkien käyttäjätahojen sille asettamia odotuksia. 3.2. Esimerkki tietokantasovelluksesta Tavoitteena on rakentaa toimiva tietokantasovellus yhtä yritystä varten. Yritys edustaa tapauksessamme siten sovelluksen kohteena olevaa "pienoismaailmaa". Oletetaan, että seuraavat tiedot on saatu selville kartoitettaessa tietokannalle asetettavia vaatimuksia: Yritys on jakautunut osastoihin. Kullakin osastolla on yksikäsitteinen nimi ja yksi johtaja. Johtajan tehtävässään aloittamispäivämäärä kirjataan muistiin. Yksittäisellä osastolla voi olla toimintaa usealla paikkakunnalla.

6 Osasto kontrolloi projekteja, joilla kullakin on yksikäsitteinen nimi ja koodinumero sekä yksi sijaintipaikka. Jokaisesta yrityksen työntekijästä kirjataan nimi, henkilötunnus, osoite, kuukausipalkka, sukupuoli ja syntymäaika. Lisäksi oletetaan, että kukin työntekijä on kirjoilla tarkalleen yhdellä osastolla, mutta hän voi työskennellä usean eri osaston kontrolloimassa projektissa. Lisäksi halutaan pitää yllä tietoa työntekijän viikoittaisista työtunneista kussakin eri projektissa, joissa hän työskentelee. Myös tieto kunkin työntekijän lähimmästä esimiehestä pitää olla saatavilla. Vielä halutaan pitää kirjaa kunkin työntekijän mahdollisista perheenjäsenistä. Heistä on tiedettävä etunimi, sukupuoli, syntymäaika sekä asema perheessä työntekijään nähden. Kirjan esimerkissä 3.2. on nähtävillä tietokannan suunnittelutyön lopputuloksena syntynyt ER-mallin mukainen käsitekaava. Jatkossa tullaan käymään läpi vaiheet, miten kyseiseen kaavaan on päädytty. Samoin esitellään kaavassa esiintyvien merkintöjen tulkinta.

7 3.3. Entiteettityypit, entiteettijoukot, attribuutit ja avaimet
Entiteetit ja attribuutit ER-malli perustuu datan kuvaamiseen entiteettien, attribuuttien ja liittymien eli suhteiden avulla. Entiteetti on jokin reaalimaailmassa esiintyvä itsenäinen käsite, joka voi olla joko fyysinen tai käsitteellinen. esimerkiksi henkilö, auto, työntekijä jne. ovat fyysisiä entiteettejä vastaavasti yliopiston kurssi, luennointikerta jne. ovat käsitteellisiä entiteettejä entiteettiä relaatiotietokannassa edustaa yksittäinen taulu ( esimerkiksi opiskelijan ja kurssin perustietotaulu jne. ), ja entiteetin nimike pyrkii kuvaamaan sitä osuvasti.

8 Entiteetille tyypillisiä ominaisuuksia kutsutaan attribuuteiksi
Entiteetille tyypillisiä ominaisuuksia kutsutaan attribuuteiksi. Attribuutit ovat siten entiteettiin kuuluvia tietokenttiä. Esimerkiksi nimi, ikä, osoite ja puhelinnumero ovat tyypillisiä yksittäiseen työntekijään liittyviä ominaisuuksia. Attribuutti voi olla joko yksinkertainen tai koottu: yksinkertaisen attribuutin arvo on selkeästi jakamaton ( esimerkiksi henkilön pituus ) koottua attribuuttia voidaan käsitellä kulloisenkin tarpeen mukaisesti joko kokonaisena tai ositettuna ( esimerkiksi henkilön nimen voidaan olettaa koostuvan etunimestä, toisen nimen alkukirjaimesta ja sukunimestä ) Lisäksi attribuutti voi olla joko yksi- tai moniarvoinen yksiarvoinen attribuutti tarkoittaa ominaisuutta, joka ei voi saada kuin yhden arvon kerrallaan ( esimerkiksi ikä ) moniarvoinen attribuutti voi saada samanaikaisesti useita eri arvoja ( esimerkiksi henkilön suorittamat tutkinnot )

9 Attribuutti voi olla joko tallennettu tai johdettu.
Tallennetun attribuutin arvo ei ole pääteltävissä muiden attribuuttien avulla ( esimerkiksi henkilön kotiosoite ) Johdetun attribuutin arvo on pääteltävissä tai laskettavissa tallennettujen attribuuttien perusteella ( esimerkiksi ikä voidaan laskea, jos tiedetään nykyinen päivämäärä ja henkilön syntymäaika ) Johdettu attribuutti voi liittyä myös koko entiteetin ominaisuuteen eikä välttämättä erikseen jokaiseen tietueeseen ( esimerkiksi opiskelijoiden kokonaismäärä saadaan laskemalla tietueiden lukumäärä opiskelijataulusta ) Toisinaan myös puuttuvat arvot attribuutille ovat sallittuja, kunhan kyseessä ei ole ns. avainattribuutti. puuttuvan arvon tulkinta on joko 'ei ole olemassa/ laskettavissa' ( esimerkiksi henkilön esimies, jos hän sattuu olemaan yrityksen toimitusjohtaja ) tai 'tuntematon' ( ei ole jostain syystä tallennettu ) ryhmä 'tuntematon' jakaantuu vielä kahteen alaryhmään:

10 3.3.2. Entiteettityypit ja -joukot, avaimet ja arvojoukot
"tieto varmasti olemassa, muttei tiedossa" ( esimerkiksi henkilön pituus ja paino ) "ei tietoa, onko olemassa" ( esimerkiksi puhelinnumero - voi olla salainen ) kompleksiset attribuutit yhdistelmä koottuja ja moniarvoisia attribuutteja (esimerkiksi tilanne, jossa henkilöllä on useampia asuntoja, joihin voi olla lisäksi useita puhelinnumeroita). Entiteettityypit ja -joukot, avaimet ja arvojoukot Entiteettityyppi määrittelee kokoelman entiteetin edustajia, joilla on samat attribuutit ( esimerkiksi tyyppi, joka kuvaa opiskelijan perustietoja ). Entiteettijoukko kuvaa tietyn entiteettityypin kaikkia edustajia ( esimerkiksi kaikkia yksittäisiä opiskelijoita esittäviä tietueita ).

11 Usein termiä entiteetti käytetään kummassakin edellä mainitussa merkityksessä, eli tarkoittamaan sekä kokonaisuutta kuvaavia ominaisuuksia että sen yksittäistä edustajaa Entiteettityyppiä kuvaa ER-kaaviossa yksinkertaisilla viivoilla merkitty suorakulmio, jonka sisällä on entiteetin nimi, joka merkitään pelkkiä isoja kirjaimia käyttämällä. Sellaista attribuuttia tai niiden yhdistelmää, joka yksikäsitteisesti identifioi entiteettijoukon yksittäisen jäsenen ( tietueen ), kutsutaan entiteettityypin avaimeksi. Avainattribuutti on usein yksittäinen attribuutti ( esimerkiksi henkilötunnus), mutta yksikäsitteisyyden saavuttaminen saattaa vaatia useamman attribuutin yhdistelmän valitsemista avaimeksi ( esimerkki: projektit, joissa henkilö työskentelee ). Entiteettijoukon nykytilassa vallitseva yksikäsitteisyys on attribuutin avaimeksi kelpaamisen kannalta välttämätön, muttei riittävä ehto ( kts. yliopistotietokannan opiskelijoiden perustiedot ). Pitää kiinnittää huomiota tietokannan määrittelyssä asetettuihin ehtoihin sen rakenteesta.

12 Avaimeksi voi kelvata useampiakin kuin yksi attribuutti tai niiden yhdistelmä ( esimerkiksi auton rekisteri- tai valmistenumero ). Avaimen on oltava minimaalinen. Tämä tarkoittaa, ettei avaimeen pidä ottaa mukaan muita kuin sellaisia attribuutteja, jotka ovat välttämättömiä yksikäsitteisyyden saavuttamiseksi. Entiteettityyppiä, jolla ei ole lainkaan omaa avainattribuuttia, kutsutaan heikoksi entiteetiksi. Entiteettityypin avaimeen kuuluvat attribuutit merkitään ER-kaavioon alleviivattuina. Jokaiseen attribuuttiin liittyy ns. arvojoukko, joka määrää, millaisia arvoja sillä voi esiintyä ( esimerkiksi rajoitettu kokonaislukualue, enintään tietyn mittainen merkkijono jne. ). Arvojoukko on matemaattisesti ymmärrettävissä kuvauksena entiteettityypiltä arvojoukon potenssijoukkoon ( kaikkien mahdollisten alijoukkojen joukkoon ).

13 3.3.3. Yrityksen tietokannan alustava käsitteellinen suunnittelu
puuttuvaa arvoa edustaa tyhjä joukko yksiarvoista attribuuttia yksittäisten laillisten arvojen joukko moniarvoista attribuuttia kaikki yhdistelmät, joita esiintyy entiteettijoukossa yhdistettyä attribuuttia sen kaikkien osakomponenttien välinen karteesinen tulo Yrityksen tietokannan alustava käsitteellinen suunnittelu Lähdetään rakentamaan ER-kaaviota kappaleessa 3.2. esiteltyjen vaatimusten mukaiselle tietokannalle. Osasto sisältää attribuutit Nimi, Numero, Toimipisteet, Johtaja ja JohtajanAloituspäivä. Koska sekä Nimi että Numero vaadittiin yksikäsitteisiksi, kumpikin näistä kelpaa erilliseksi avaimeksi. Projektiin tarvitaan attribuutit Nimi, Numero, Sijaintipaikka ja KontrolloivaOsasto. Sekä Nimi että Numero kelpaavat avaimeksi.

14 Työntekijästä tallennetaan attribuutit Nimi, Hetu, Sukupuoli, Osoite, Kuukausipalkka, Syntymäaika, Osasto ja Esimies. Nimi ja Osoite voitaisiin esittää sekä yksinkertaisina että koottuina attribuutteina: ---> kysyttävä lisätietoa käyttäjiltä. Perheenjäsenistä tarvitaan attribuuteiksi Työntekijä, Perheenjäsenen nimi, Sukupuoli, Syntymäaika ja Perhesuhde työntekijään. Edelleen pitäisi pystyä esittämään, että työntekijä voi toimia useassa eri projektissa, ja myös tehdyt työtunnit pitäisi kirjata. ---> olisi lisättävä työntekijä-entiteettityyppiin moniarvoinen koottu attribuutti Työskentelee( Projekti, Tunnit ) tai projekti entiteettityyppiin moniarvoinen attribuutti Työsuoritukset( Työntekijä, Tunnit ). ---> kysytään taas lisää käyttäjiltä, jotka kertovat haluavansa mieluummin ensimmäisen vaihtoehdon.

15 3.4. Relaatiotyypit ja -joukot, roolit ja rakenteelliset rajoitukset
Tällä kurssilla liittymä  suhde  relaatio. Edellisissä määrityksissä on useita implisiittisiä riippuvuuksia, eli tietyn entiteettityypin attribuutti viittaa selkeästi johonkin toiseen entiteettiin (esimerkiksi Osaston johtaja --> Työntekijä, Projektia kontrolloiva osasto --> Osaston tiedot, Työntekijän esimies --> Työntekijä, Työntekijän osasto --> Osaston tiedot). Implisiittiset riippuvuudet kannattaa esitellä pikemminkin suhteina kuin attribuutteina, vaikka aluksi niiden esittely attribuutteina onkin mahdollista --> käsitekaava tarkentuu asteittain.    Liittymien tyypit, joukot ja esiintymät Relaatioon osallistuu vähintään kaksi entiteettityyppiä. Kahden entiteettityypin välinen relaatiota sanotaan binääriseksi, kolmen ternääriseksi jne.

16 Sama entiteettityyppi voi osallistua relaatioon useammin kuin yhden kerran.
Suhteen esiintymällä ri tarkoitetaan kokoelmaa (e1, e2, e3, ..., en), jossa ei:t ovat siihen osallistuvien entiteettityyppien E1, E2, ..., En yksittäisiä esiintymiä). Jos kyseessä on binäärinen relaatio, n=2. Jokainen entiteettityypeistä E1, E2, ..., En osallistuu niiden välille määriteltyyn relaatioon. Esimerkki binäärisestä relaatiosta: työntekijän työskenteleminen osastolla --> työntekijäentiteettiä edustava esiintymä liitetään osastoa esittävän esiintymän kanssa ( kts. kirjan esimerkki 3.9. ) Esimerkki ternäärisestä relaatiosta: tavaran, sen toimittajan ja toimituksen kohteena olevan projektin liittäminen toisiinsa ( kts. kirjan esimerkki ) Relaatiota voidaan kuvailla attribuuttien avulla. Esimerkiksi työntekijän työskentelyä jonkin osaston laskuun voidaan kuvata työntekijän mahdollisena yksiarvoisena attribuuttina Osasto. Sama toimii myös toisin päin: yhtäläisesti kutakin osastoa kohti voisi olla määriteltynä moniarvoinen attribuutti nimeltä OsastonTyöntekijät, joka olisi luettelo työntekijöistä, jotka ovat töissä tietyllä osastolla.

17 3.4.3. Rajoitukset suhteiden tyypeille
Roolinimellä tarkoitetaan ominaisuutta, jollaisessa entiteettityyppi osallistuu liittymään ( esimerkiksi relaatio työntekijän työskenteleminen osastolla ). Roolinimet ovat melko selkeät, mikäli sama entiteettityyppi ei osallistu siihen useita kertoja. Muussa tapauksessa on kyseessä ns. rekursiivinen relaatio, jossa sama entiteettityyppi osallistuu siihen kahdessa ( tai useammassa ) eri roolissa ( esimerkiksi työntekijöiden esimiehet ). Rajoitukset suhteiden tyypeille Relaatioon osallistuvien entiteetin esiintymien kombinaatioiden lukumäärää voidaan tarpeen mukaan rajoittaa ( esimerkiksi työntekijä voi olla kirjoilla vain yhdellä osastolla, jokaisella osastolla on vain yksi johtaja jne. ). Kaksi tyypillisintä suhteen tyypin rajoitetta ovat ns. lukumääräsuhde ja osallistumiskriteeri.

18 Binäärisen relaation lukumääräsuhde määrää, monenko esiintymän kanssa entiteetti voi osallistua relaation. Esimerkki: osasto-työntekijä -relaation lukumääräsuhde on 1:N. Tämä tarkoittaa sitä, että yhdellä osastolla voi olla kirjoilla monta työntekijää, mutta yksi työntekijä voi edustaa vain yhtä osastoa. Muut lukumääräsuhteet ovat 1:1, N:1 ja M:N. Esimerkki 1:1 -lukumääräsuhteesta: osaston johtaminen. Jokaisella osastolla voi olla vain yksi johtaja, ja jokainen henkilö voi johtaa vain yhtä osastoa. Esimerkki M:N -lukumääräsuhteesta: työskenteleminen eri projekteissa. Jokainen työntekijä voi toimia useassa eri projektissa, ja yhdessä projektissa voi olla useita työntekijöitä. Relaation osallistumisrajoite ( participation constraint ) ilmaisee, onko yksittäisen entiteettityypin esiintymän olemassaolo riippuvainen suhteesta toisen entiteettityypin esiintymään ( Esimerkki: voiko yrityksessä olla työntekijää, joka ei ole kirjoilla millään osastolla ).

19 Osallistumisrajoite voi olla osittainen tai täydellinen.
Relaation osallistumisvaatimuksen ollessa täydellinen pitää tietyn entiteetin kaikkien edustajien osallistua kyseiseen relaatioon. Täydellistä osallistumisrajoitetta kutsutaan myös olemassaoloriippuvuudeksi ( existence dependency ). Esimerkiksi täydellisestä osallistumisesta voitaisiin mainita suhde kirjoilla_osastolla( työntekijä ---> osasto ): jokaisen työntekijän pitää kuulua johonkin osastoon. Jos puolestaan osallistumisrajoite on osittainen, ei kaikkien relaation muodostavan entiteettityypin edustajien tarvitse osallistua relaatioon. Esimerkki osittaisesta osallistumisesta: osaston johtaminen, eli johtaa(työntekijä ---> osasto): jokaisen työntekijän ei tarvitse johtaa jotakin osastoa. Kannattaa huomioida, että sama osallistumisrajoite ei välttämättä ole voimassa relaation käänteisrelaatiossa ( Esimerkki: johtaja( osasto ---> työntekijä ): jokaisella osastolla pitää olla johtaja, vaikkei kaikkien työntekijöiden tarvitsekaan toimia jonkin osaston johtajana )!

20 3.4.4. Liittymätyypin attribuutit
Täydellinen osallistumisrajoite merkitään ER-kaavioon kaksinkertaisena ja osittainen osallistumisrajoite yksinkertaisena viivana ( kts. kirjan kuva 3.2. ). Liittymätyypin attribuutit Paitsi entiteettityypeille, myös liittymille voidaan määritellä attribuutteja. Toisinaan attribuutti liittyy luonnollisemmin kahden ( tai useamman ) entiteettityypin väliseen suhteeseen kuin jompaan kumpaan ( johonkin ) yksittäisistä entiteettityypeistä. Toistaiseksi keskitytään jatkossa vain binäärisiin relaatioihin. Esimerkki suhteen attribuutista: työntekijän yhdessä projektissa tekemät työtunnit ( kuvaa paremmin henkilön ja projektin välistä yhteyttä kuin itse työntekijää tai projektia sinänsä ). Mikäli relaation lukumääräsuhde on 1:1, voidaan suhteen attribuutti esittää haluttaessa kumman tahansa entiteettityypin attribuuttina. Esimerkki: osaston johtajan aloittamispäivämäärä voitaisiin yhtäläisesti sijoittaa osaston tai työntekijän attribuutiksi, mutta käsitteellisesti se kuitenkin liittyy selvästi itse johtamisrelaatioon johtaa( henkilö ---> osasto ).

21 3.5. Heikot entiteettityypit
Jos lukumääräsuhde on 1:N, voidaan suhteeseen liittyvä attribuutti sijoittaa luontevasti vain relaation N-puolella olevaan entiteettiin. Esimerkki: jos työntekijän työsuhteen alkamispäivä osastolla haluttaisiin kirjata, se voitaisiin viedä haluttaessa työntekijän perustietoihin yksinkertaisena attribuuttina. Sen sijaan osaston attribuutiksi se sopii erittäin huonosti, sillä siitä olisi tehtävä moniarvoinen koosteinen attribuutti 'Työntekijät+Aloituspäivät', jossa selvästi kaksi eri attribuuttia jouduttaisiin kombinoimaan yhdeksi. Mikäli relaation lukumääräsuhde on M:N, eivät suhteen attribuutit enää mielekkäästi liity yksistään jompaankumpaan entiteettiin. Tällöin ne pitää esittää suhteen attribuutteina (esimerkiksi työntekijän tekemät työtunnit eri projekteissa). Vaihtoehtoinen esittely työntekijän tai projektin moniarvoisena attribuuttina olisi paljon vaikeaselkoisempi. 3.5. Heikot entiteettityypit Entiteettityyppi, jolla ei ole omia avainattribuutteja, on nimeltään heikko entiteetti( tyyppi ). Heikon entiteettityypin tietueet on tunnistettavissa ainoastaan niiden tunniste- eli omistajatyypin kautta.

22 Heikon entiteettityypin osallistumisrajoite on aina täydellinen, eli sen esiintymien olemassaolo on täysin riippuvaa omistajatyypistä. Esimerkki: työntekijän perheenjäsenet ovat tunnistettavissa ainoastaan työntekijän henkilötunnuksen kautta. On kuitenkin mahdollista, että olemassaoloriippuvuutta esiintyy myös muillakin kuin heikoilla entiteeteillä. Tällöin entiteetillä on olemassa jokin oma avainattribuutti, mutta ilman yhteyttä tunnistetyyppinsä edustajaan entiteetin edustajilla ei ole mielekästä asemaa tietokannassa. Esimerkki: ajokorttitiedot ( ajokorteilla on olemassa numero, joka identifioi yksittäisesti ajokortin − eli kyseessä ei siten ole heikko entiteetti − mutta tiedot ovat melko lailla hyödyttömiä ilman yhteyttä ajokortin haltijaan ). Heikolla entiteettityypillä on yleensä osittaisavain, jonka turvin tyypin esiintymät ovat tunnistettavissa, kun tietueiden omistaja tiedetään. Osittaisavain voi huonossa tapauksessa muodostua kaikista heikon entiteettityypin attribuuttien yhdistelmästä. Esimerkki: tarkastellaan työntekijän perheenjäseniä. Jos voidaan olettaa, ettei samalla työntekijällä ole kahta etunimeltään saman nimistä perheenjäsentä, perheenjäsenen etunimi on tällöin osittaisavain. Osittaisavaimeen kuuluvat attribuutit alleviivataan katko- tai pisteviivalla. Heikot entiteetit merkitään ER-kaavioon kahdella viivalla rajatuin suorakulmioin. Samoin relaatiot, joihin heikko entiteetti osallistuu, merkitään kaksin reunaviivoin piirretyin ruuduin.

23 3.6. Yrityksen tietokannan tarkentaminen
Heikon entiteetin perustaminen voidaan haluttaessa kiertää lisäämällä sen attribuutit omistajatyyppinsä moniarvoiseksi koosteiseksi attribuutiksi. Esimerkki: työntekijän perheenjäseniä kuvaavat tiedot voisivat yhtenä attribuuttina työntekijän perustiedoissa { Perheenjäsenet( Nimi, Sukupuoli, Syntymäaika, Perhesuhde ) }. On kuitenkin suositeltavaa käyttää heikkoa entiteettityyppiä moniarvoisen attribuutin asemesta, jos heikkoon entiteettiin kuuluvia attribuutteja on 'tarpeeksi monta', jotta käsittely moniarvoisena attribuuttina tulisi hankalaksi mikäli heikko entiteettityyppi muodostaa relaatioita myös jonkin muun kuin omistajaentiteettinsä kanssa 3.6. Yrityksen tietokannan tarkentaminen Tavoitteena on tarkentaa tähän mennessä aikaansaatua yrityksen tietokannan ER-mallia ( kirjan esimerkki 3.8.) täydentämällä sitä lukumääräsuhteiden ja osallistumisrajoitusten avulla sekä muuntamalla osa attribuuteista suhdetyyppisiksi. Luettelo tarpeellisista muutoksista: Osaston johtaminen attribuutista relaatioksi: työntekijän osallistuminen on osittaista, osaston osallistuminen pitää selvittää käyttäjiltä ---> lopputulos: osastolla oltava aina yksi johtaja

24 Johtajan aloituspäivämäärä suhteen attribuutiksi
Osastolle kuuluminen attribuutista relaatioksi, lukumääräsuhteeksi 1:N osaston ja työntekijän välille Projektin kontrolloiminen osaston ja projektin väliseksi suhteeksi. lukumääräsuhteeksi 1:N osaston ja projektin välille. Projektin osallistumisen pitää olla täydellinen ( kysytty käyttäjiltä ). Työntekijä - Esimies -suhde: lukumääräsuhde 1:N esimiehestä työntekijään. Työntekijäentiteetti osallistuu relaatioon kahdesti. Molempiin suuntiin osittainen osallistuminen. Työskenteleminen projekteissa: M:N-suhde työntekijän ja projektin välille. Molempiin suuntiin täydellinen osallistuminen. Suhteelle attribuutiksi työntekijän työtunnit projektissa. Perheenjäsenet: 1:N-suhde työntekijän ja perheenjäsenen välille, mikä on samalla identifioiva suhde heikolle entiteetille perheenjäsen. Perheenjäsenen osallistuminen täydellistä, työntekijän osittaista. Mihin edellä mainittujen suhteiden määrittely johti? poistettiin attribuutit esimies ja esimiehen aloituspäivä OSASTOsta, kontrolloiva osasto PROJEKTIsta, Osasto, Esimies ja Työskentelee ( Projekti, Tunnit ) TYÖNTEKIJÄstä ja työntekijä PERHEENJÄSENestä. saavutuksena toiston minimoituminen käsitekaaviossa

25 3.7. ER-kaavioihin liittyviä nimeämiskäytäntöjä ja suunnittelunäkökohtia
Yhteenveto ER-kaavioiden merkinnöistä ER-kaavio kuvaa ainoastaan tietokannan rakennetta, ei sen sisältämää dataa. Attribuuttien tietotyyppiä ja arvoaluetta ei esitellä. Luettelo ER-kaavioissa käytettävistä symboleista löytyy kirjan kuvasta ( esitellään luennolla ). Tietokannan kaavan rakenneosien nimeämisestä Entiteettityyppien nimet esitetään yksikkömuodossa ( esimerkiksi työntekijä, osasto jne. ). Entiteettityyppien ja relaatioiden nimet merkitään kokonaisuudessaan ISOILLA KIRJAIMILLA. Attribuuttien nimet merkitään Isolla alkukirjaimella.

26 3.7.3. Ohjeistusta ER-mallin mukaiseen käsitteelliseen suunnitteluun
Roolinimet merkitään kokonaisuudessaan pienin kirjaimin. Entiteettityyppien ja attribuuttien tunnukset ovat käytännössä substantiiveja ( esim. työntekijä, etunimi ), kun taas relaatioita pyritään kuvaamaan yleensä verbeillä ( johtaa, työskentelee ). ER-kaavio rakennetaan yleensä siten, että se on luontevasti luettavissa vasemmalta oikealle ja ylhäältä alas. Kirjan esimerkissä 3.2. on tästä kuitenkin yksi poikkeus, joka liittyy työntekijän ja perheenjäsenen väliseen relaatioon. Ohjeistusta ER-mallin mukaiseen käsitteelliseen suunnitteluun Usein esille tuleva kysymys: "Milloin tietokantaan liittyvä käsite pitäisi esitellä entiteettinä, milloin attribuuttina ja milloin entiteettityyppien välisenä suhteena?” Muutamia ratkaisuun vaikuttavia tekijöitä: 1.  Käsite voidaan aluksi esitellä attribuuttina, mutta tarvittaessa se voidaan myöhemmin kuvata suhteeksi, jos se liittyy kiinteästi johonkin toiseen entiteettityyppiin ( esimerkiksi osaston johtaja --> osaston johtaminen ).

27 3.7.4. Vaihtoehtoisia merkintätapoja ER-kaaviolle
Mikäli useassa entiteettityypissä esiintyy yhteinen attribuutti, voi olla aiheellista perustaa sitä varten oma uusi entiteettityyppi. Esimerkki: Kuvan 1.2. yliopistotietokannassa viitataan useassa paikassa oppiaineeseen. Voisi olla mielekästä perustaa oppiainetta varten oma entiteettityyppi, jolle voidaan määritellä myöhemmin tarvittavat lisäattribuutit. 3.  Jos puolestaan entiteettityyppi sisältää ainoastaan yhden attribuutin, ja siihen viitataan vain yhdessä muussa entiteetissä, se kannattaa liittää kyseisen entiteetin attribuutiksi. Muita erikoistamis- / yleistämismenetelmiä käsitellään myöhemmin kappaleessa 4. Vaihtoehtoisia merkintätapoja ER-kaaviolle Voidaan merkitä aikaisempaa kuvausta tarkemmat rajat relaation lukumääräsuhteelle ja osallistumisrajoituksella tyyliin ( alaraja, yläraja ). Aina on voimassa epäyhtälöpari 0 ≤ alaraja ja yläraja ≥ 1. Esimerkki: TyöntekijöitäOsastolla(4, N) tarkoittaisi, että kullakin osastolla on oltava vähintään 4 työntekijää. Mikäli relaatioon osallistuminen voi olla osittaista, alaraja on 0.

28 3.8. UML:n luokkadiagramminotaatio
Kaavioon merkitään myös relaation suuntaa kuvaava nimitys ( esimerkiksi kirjoilla_osastolla, osaston_työntekijä ). Parin ( alaraja, yläraja ) merkitsemiskohta yleensä päinvastainen kuin aikaisemmassa kaaviotyypissä. 3.8. UML:n luokkadiagramminotaatio Objektimallinnusmenetelmät on alun perin kehitetty ohjelmistojen suunnittelua varten, mutta ne ovat yleistyneet sittemmin myös tietokantojen suunnittelussa. Luokkadiagrammit ovat tärkeä osa kyseisiä menetelmiä, ja ne muistuttavat monessa suhteessa EER-kaavioita. Tunnetuimpia objektimallinnusmenetelmiä ovat OMT ( Object Modeling Technique ) sekä UML ( Universal Modeling Language ). Tällä kurssilla rajoitutaan UML:n lyhyeen esittelyyn. Vaikka UML:ssä on paljon samoja piirteitä kuin EER:ssä, niistä käytettävä terminologia eroaa toisistaan monissa kohdin.

29 Luokkaa ( entiteettityyppiä ) merkitään laatikolla, joka on jaettu kolmeen eri lokeroon: luokan nimeen, attribuuttilistaan mahdollisine tietotyyppien kuvauksineen sekä operaatioihin. Suhdetyypistä käytetään UML:ssä nimitystä assosiaatio ja sen esiintymistä nimitystä linkki. Binääristä assosiaatiota ( relaatiotyyppiä ) merkitään yksinkertaisella viivalla, joka yhdistää relaatioon osallistuvat luokat. Assosiaation nimeä ei välttämättä merkitä näkyviin. Suhteeseen liittyvät attribuutit, eli UML-terminologian mukaisesti linkkiattribuutit, merkitään laatikkoon, joka yhdistetään katkoviivalla relaatiota kuvaavaan viivaan. lukumääräsuhdetta ja osallistumisrajoitetta kutsutaan yhdessä osallistumisen rajaluvuiksi ( multiplicities ), joita merkitään esityksellä ( alaraja, yläraja ). Rajaluvut merkintään kuitenkin toiselle puolelle relaatiota kuin kohdassa 3.7. kuvatussa ER-mallin vaihtoehtoisessa merkintätavassa. Rajaluvuissa ylärajasymboli * edustaa ylhäältä rajoittamatonta osallistumista.

30 Yksinäinen symboli. tarkoittaa lyhenteenä rajalukuja ( 0,
Yksinäinen symboli * tarkoittaa lyhenteenä rajalukuja ( 0, * ) sekä 1 rajalukuja ( 1, 1 ). Rekursiivisesta relaatiosta käytetään nimitystä refleksiivinen assosiaatio, ja siihen liittyvät roolinimet merkitään myös päinvastoin kuin ER-mallin vaihtoehtoisessa esitystavassa. Tarkastellaan kirjan esimerkkiä UML:n merkintöjen havainnollistamiseksi. Toisin kuin EER:ssä, UML:ssä erotellaan kahden eri tyypin relaatioita: assosiaatioita ja aggregaatioita. Aggregaatiolla (  keräymä ) tarkoitetaan relaatiotyyppiä, joka liittää yhteen objektin ja sen rakenneosat. Esimerkki: Osasto ja sen toimipisteet ( moniarvoinen attribuutti ), projektin sijaintipaikka. Assosiaatio ja aggregaatio eivät kuitenkaan eroa rakenteellisesti toisistaan, joten valinta eri suhdetyyppien välillä on melko vapaa. Aggregaation omistajaluokkaa  eli minkä luokan komponentteja relaatio kerää  kuvaa pieni ruutusymboli (◇).

31 UML:ssä on myös operaatioiden tarkka kuvaaminen sekä niiden vaatimien argumenttien esittäminen mahdollista. Heikot entiteettityypit esitetään todennettuna assosiaationa tai aggregaationa ( qualified association / aggregation ). Identifioivan relaation osittaisavain merkitään omistajaluokkaa kuvaavan laatikon jatkeeksi piirrettyyn suorakulmioon.