Luento L: Normalisointi

Transkriptio

1 HAAGA-HELIA / TIKO 1 (40) Luento L: Normalisointi Normalisointi... 2 Tavoitteet... 2 Attribuuttien väliset riippuvuudet... 4 Funktionaalinen / moniarvoinen riippuvuus... 4 Funktionaalinen riippuvuus... 4 Moniarvoinen riippuvuus... 5 Yhteenveto: funktionaalinen / moniarvoinen riippuvuus... 5 Suora / transitiivinen riippuvuus... 6 Transitiivinen riippuvuus... 6 Suora riippuvuus... 6 Täydellinen / osittainen riippuvuus... 7 Osittainen riippuvuus... 7 Täydellinen riippuvuus Normaalimuoto Miksi 1NF? Normaalimuoto Miksi 2NF? Normaalimuoto Miksi 3NF? Normalisointiprosessi NF = Normalisoinnin tavoitetaso! Normalisointiesimerkki: Kurssihallinto Avaimista Boyce/Codd normaalimuoto BCNF normaalimuoto 4NF Itsenäisyys normaalimuoto 5NF Yhteenveto Esimerkki Denormalisointi? Riskit... 39

2 HAAGA-HELIA / TIKO 2 (40) Normalisointi (Normalization) Tavoitteet Relaatiotietokannasta saadaan relaatiomallin mukainen Relaatioiden ja kohdealueen objektien välille pyritään saamaan läheinen rakenteellinen vastaavuus Minimoidaan tietokantaan sisältyvää käsitteellistä ja talletettavista tiedoista aiheutuvaa redundanssia (=toistoa) Tietokannan päivitysten yhteydessä mahdollisten anomalioiden välttäminen (lisäys-, muutos- ja poistoanomalia) Relaatioiden riveistä pyritään tekemään lisäysten, poistojen ja muutosten kannalta itsenäisiä kokonaisuuksia Tietokannan mahdollisimman suuri rakenteellinen joustavuus tulevien muutosten mahdollistamiseksi

3 HAAGA-HELIA / TIKO 3 (40) ~ Normalisointi perustuu normaalimuotoihin (normal form) ~ Normaalimuodot ovat asteittain tiukkenevia ehtoja, jotka relaatioiden on täytettävä ~ Relaatio on tietyssä normaalimuodossa, mikäli se täyttää tietyt rajoitusehdot Kaikki relaatiot 1NF 2NF 3NF BCNF 4NF 5NF ~ 3.normaalimuoto on normalisoinnin 'minimitaso' / tavoitetaso ~ Ylempiä normaalimuotoja käsitellään syventävillä kursseilla

4 HAAGA-HELIA / TIKO 4 (40) Attribuuttien väliset riippuvuudet Funktionaalinen / moniarvoinen riippuvuus ~ Vastaako attribuuttia a yksi vai useampi attribuutin b arvo Funktionaalinen riippuvuus ~ Jos attribuutin A arvo määrää yksikäsitteisesti attribuutin B arvon niin ~ B on funktionaalisesti riippuva A:sta ~ A määrää B:n funktionaalisesti A -> B ~ Vrt. Funktion käsite: funktio palauttaa aina yhden arvon Esim: Henkilötunnus --> hlo_nimi Rekisterinumero --> auton merkki ~ Yleistys: A, B -> C Esim: Tilausno, tuoteno --> tilausmäärä Projektino, henkilono, kk --> työajankäyttö

5 HAAGA-HELIA / TIKO 5 (40) Moniarvoinen riippuvuus ~ Jos ominaisuuden A arvoon voi liittyä useita ominaisuuden B arvoja tavalla, joka ei riipu mistään 3. ominaisuudesta A ->> B Esim. projektino -->> henkilono osastono -->> projektino Yhteenveto: funktionaalinen / moniarvoinen riippuvuus ~ Funktionaalinen riippuvuuden X -> Y voimassaolo ei merkitse funktionaalisen riippuvuuden Y -> X voimassaoloa ~ Riippuvuus voi olla (ja yleensä on) ~ Toisesta suunnasta funktionaalinen ~ Toisesta suunnasta moniarvoinen Esim: Henkilötunnus <<--> nimi Rekisterinumero <<--> auton merkki

6 HAAGA-HELIA / TIKO 6 (40) Suora / transitiivinen riippuvuus ~ Määrääkö attribuutti A attribuutin C suoraan vai välillisesti ominaisuuden B kautta Transitiivinen riippuvuus ~ attribuutti C on transitiivisesti riippuva attribuutista A, jos ja vain jos A -> B ja B -> C ja lisäksi B -/-> A ja C-/-> A Esim. Henkilötunnus --> hlo_nimi, os_tunnus, os_nimi Suora riippuvuus ~ Attribuutti A määrää attribuutin C suoraan, (ilman välittäviä attribuutteja) Esim. Henkilötunnus --> hlo_nimi, os_tunnus Os_tunnus --> os_nimi

7 HAAGA-HELIA / TIKO 7 (40) Täydellinen / osittainen riippuvuus ~ Onko jokainen pääavaimen elementti mukana riippuvuudessa? Osittainen riippuvuus ~ Pääavaimen osa riittää identifioiman osan relaation avaimeen kuulumattomista attribuuteista Esim. Tilausno, tuoteno --> tuotenimi, tilaus_maara Täydellinen riippuvuus ~ Kaikki relaation avaimeen kuulumattomat attribuutit määräytyvät koko pääavaimen perusteella Esim. Tilausno, tuoteno --> tilaus_maara Tuoteno --> tuotenimi

8 HAAGA-HELIA / TIKO 8 (40) Normalisoinnissa tavoitellaan riippuvuuksia, jotka ovat 1. Funktionaalisia 2. Suoria 3. Täydellisiä

9 HAAGA-HELIA / TIKO 9 (40) Funktionaalisten riippuvuuksien ominaisuuksia / päättelysääntöjä 1. Refleksiivisyys Jos Y X niin X -> Y Esim: otsake, vuosi -> otsake Esim: otsake -> otsake Ns. triviaali riippuvuus (riippuvuuden olemassaolo on itsestään selvää) 2. Täydentäminen Jos X -> Y niin XZ -> YZ 3. Ositus Jos X -> YZ niin X-> Y 4. Unioni Jos X -> Y ja X -> Z niin X -> YZ 5. Transitiivisuus Jos X -> Y ja Y-> Z niin X -> Z Päättelysääntöjä voi käyttää relaatioiden yhdistämiseksi, (tavoitteena on sovellusalueen kuvaus pienimmällä mahdollisella relaatiomäärällä)

10 HAAGA-HELIA / TIKO 10 (40) 1. Normaalimuoto ~ 1NM (1 Normal Form, 1NF) ~ Relaatio R on 1. normaalimuodossa jos ja vain jos sen jokainen arvoalue sisältää ainoastaan atomaarisia arvoja ~ Relaatiomalli perustuu arvojoukon määritelmän kautta olettamukseen, jonka mukaan attribuuttien arvot ovat atomisia ~ Ts. relaation on oltava kaksiulotteinen, 1. Relaatiossa ei saa olla toistuvia attribuutteja Moniarvoiset ominaisuudet on purettava omiksi relaatioikseen 2. Relaation jokainen attribuutti on jakamaton kokonaisuus Esim. JULKAISU(julkaisuno, tekijat, otsake, ) JULKAISU(julkaisuno, tekija1, tekija2,.., otsake, ) ei 1NF! 1NF: JULKAISU(julkaisuno, otsake, ) J_TEKIJA(julkaisuno, tekija, tekijan _i)

11 HAAGA-HELIA / TIKO 11 (40) Miksi 1NF? Minkälaisen kyselyn joutuisit tekemään etsiäksesi Mielosen julkaisut? (normalisoimattomissa vaihtoehdoissa) Mitä, jos tietyn julkaisun 2. tekijä halutaan poistaa (esim. kirjoitusvirheen takia)? Mitä, jos tekijöitä onkin useampi, kuin mihin on varauduttu? ~ Normalisoimattomaan relaatioon liittyviä anomalioita

12 HAAGA-HELIA / TIKO 12 (40) 2. Normaalimuoto ~ 2NM (2 Normal Form, 2NF) ~ Relaatio R on 2. normaalimuodossa jos ja vain jos se on 1NF:ssa ja jokainen avaimeen kuulumaton ominaisuus on täydellisesti riippuvainen avaimesta ~ Ts. avaimen osa ei saa riittää identifioimaan jotakin relaation attribuuteista ~ Avaimen osasta riippuvat ominaisuudet esitetään omana relaationaan Esim: TYOPANOS(projno, hlono, vuosi, kk, hnimi, tunnit) ei 2NF 2NF: TYOPANOS(projno, hlono, vuosi, kk, tunnit) HLO(hlono, hnimi, )

13 HAAGA-HELIA / TIKO 13 (40) Miksi 2NF? Kuinka moneen kertaan henkilön nimi pitää tallentaa tietokantaan? Miten tallennetaan henkilön nimi, jos hänelle ei ole kertynyt vielä lainkaan projektityötunteja? Jos henkilön nimi muuttuu, moneenko relaatioon muutos on tallennettava? Jos työpanostiedot päätetään poistaa projektin päättyessä, miten käy tiedolle henkilön nimestä? ~ Normalisoimattomaan relaatioon liittyviä anomalioita

14 HAAGA-HELIA / TIKO 14 (40) 3. Normaalimuoto ~ 3NM (3 Normal Form, 3NF) ~ Relaatio R on 3. normaalimuodossa jos ja vain jos se on 2NF:ssa ja mikään sen avaimeen kuulumattomista ominaisuuksista ei ole avaimesta transitiivisesti riippuvainen ~ Relaatio R on 3. normaalimuodossa jos jokaisessa funktionaalisessa riippuvuudessa X -> A joko a) attribuuttijoukko X on relaation R yliavain tai b) A on avainattribuutti ~ Ts. ei-avaimena oleva ominaisuus ei saa riippua avaimen lisäksi jostakin muusta, ei-avaimena olevasta ominaisuudesta ~ Siirrä attribuutit, jotka riippuvat avaimen lisäksi jostakin eiavaimena olevasta ominaisuudesta omaksi relaatiokseen Esim: HLON_TYO(hlono, tyopaikan_nimi, tyopaikan_os) Ei 3 NF.. 3NF: HLON_TYO(hlono, tyopaikan_nimi) TYOPAIKKA(tyopaikan_nimi, tyopaikan_os)

15 HAAGA-HELIA / TIKO 15 (40) Miksi 3NF? Jos työpaikka muuttaa, moneenko kertaan uusi osoite joudutaan kirjoittamaan? Kun lisätään henkilö vanhalle työpaikalle, joudutaan työpaikan osoite kirjoittamaan yhä uudelleen Jos tietyn työpaikan henkilöstö irtisanoutuu, miten käy tiedon työpaikan osoitteesta? Miten lisätään uusi työpaikka, jos siellä ei vielä ole ensimmäistäkään työntekijää? ~ Normalisoimattomaan relaatioon liittyviä anomalioita

16 HAAGA-HELIA / TIKO 16 (40) Normalisointiprosessi Normalisoimaton muoto Pura rakenteiset attribuutit. Poista toistuvat ryhmät, ts. Siirrä moniarvoiset attribuutit omaksi relaatiokseen 1NF (ei toistuvia eikä rakenteisia attribuutteja) Poista epätäydellinen funktionaalinen riippuvuus ts. Siirrä attribuutit jotka riippuvat pääavaimen osasta omaksi relaatiokseen, Jäljelle jäävät attribuutit riippuvat koko pääavaimesta täydellisesti 2NF (täydellinen riippuvuus koko avaimesta) Poista transitiivinen riippuvuus ts. Siirrä attribuutit, jotka riippuvat pääavaimen lisäksi jostakin pääavaimeen kuulumattomasta ominaisuudesta omaksi relaatiokseen 3NF (ominaisuudet keskenään riippumattomia)

17 HAAGA-HELIA / TIKO 17 (40) 3NF = Normalisoinnin tavoitetaso! 1. Yksilöivä avain 2. Ei toistuvia tai rakenteellisia attribuutteja 3. Ei epätäydellistä funktionaalista riippuvuutta 4. Ominaisuudet keskenään riippumattomia "The rules leading to and including the 3. normal form can be summed up in a single statement: Each attribute must be a fact about the key, the whole key, and nothing but the key." [Wiorkowski, Kull. DB2 Design and Development Guide] ~ Coddin alkuperäisessä määrittelyssä mukana vain 1NF, 2NF, 3NF ~ Lisäksi myös Boyce-Codd normaalimuoto (BCNF) 4. Normaalimuoto (4NF) 5. normaalimuoto (5 NF)

18 HAAGA-HELIA / TIKO 18 (40) Normalisointiesimerkki: Kurssihallinto OPETTAJA(openo, ope_nimi, ope_tutkinto, ope_puh1, ope_puh2) OPISKELIJA(opino, opi_nimi, aloitus_vuosi, osoite(katuos, postino, kunta)) KURSSI(kurssino, toteutusno, kurssin_nimi, vastuu_openo, opettava_openo, laajuus, aloitus_pvm) OSALLISTUMINEN(kurssino, opino, arvosana)

19 HAAGA-HELIA / TIKO 19 (40) 1NF: 1. Pääavain määrää funktionaalisesti muut attribuutit 2. Ei rakenteellisia attribuutteja OPETTAJA(openo, ope_nimi, ope_tutkinto) OPE_PUH(openo, ope_puh) OPISKELIJA(opino, opi_nimi, aloitus_vuosi, katuos, postino, kunta) KURSSI(kurssino, toteutusno, kurssin_nimi, vastuu_openo, opettava_openo, laajuus, aloitus_pvm) OSALLISTUMINEN(kurssino, opino, arvosana)

20 HAAGA-HELIA / TIKO 20 (40) 2NF: ~ Jokainen attribuutti riippuu koko pääavaimesta (ei sen osasta) OPETTAJA(openo, ope_nimi, ope_tutkinto) OPE_PUH(openo, ope_puh) OPISKELIJA(opino, opi_nimi, aloitus_vuosi, katuos, postino, kunta) KURSSITOTEUTUS(kurssino, toteutusno, opettava_openo, aloitus_pvm) KURSSI(kurssino, kurssin_nimi, vastuu_openo, laajuus) OSALLISTUMINEN(kurssino, opino, arvosana)

21 HAAGA-HELIA / TIKO 21 (40) 3NF: ~ Jokainen attribuutti riippuu vain pääavaimesta (ei muista attribuuteista) OPETTAJA(openo, ope_nimi, ope_tutkinto) OPE_PUH(openo, ope_puh) OPISKELIJA(opino, opi_nimi, aloitus_vuosi, katuos, postino) POSTITMPK(postino, kunta) KURSSITOTEUTUS(kurssino, toteutusno, opettava_openo, aloitus_pvm) KURSSI(kurssino, kurssin_nimi, vastuu_openo, laajuus,) OSALLISTUMINEN(kurssino, opino, arvosana) Huolehdi että viiteavaimet (=yhteydet) säilyvät normalisoinnissa!

22 HAAGA-HELIA / TIKO 22 (40) Avaimista Yliavain (Superkey) Attribuuttijoukko S on relaation R yliavain, mikäli X määrää funktionaalisesti relaation attribuuttien joukon Avain (Key) Attribuuttijoukko K on relaation R avain, mikäli K on relaation R yliavain, eikä attribuuttijoukosta K voida pudottaa pois yhtään attribuuttia siten, että K olisi edelleen relaation R yliavain Relaation avain on siis pienin relaation yliavaimista Jokaisella relaatiolla on ainakin yksi avain Relaatiolla voi olla myös useampia avaimia Pääavain (Primary key) Relaation avain tai mikäli niitä on useampia pääavaimeksi valittu avain Pääavaimen arvo ei voi olla tyhjä Avainehdokas (Key kandidate) Mikäli relaatiolla on useita avaimia, niitä nimitetään attribuuttijoukkoja avainehdokkaiksi Avainattribuutti (Prime attribute) Kaikki avainehdokkaisiin sisältyvät attribuutit

23 HAAGA-HELIA / TIKO 23 (40) Boyce/Codd normaalimuoto BCNF Ns. vahva 3NF Relaatio R on Boyce-Codd -normaalimuodossa, jos jokaisessa (ei-triviaalissa) funktionaalisessa riippuvuudessa X -> A attribuuttijoukko X on relaation R yliavain Relaatio R on 3. normaalimuodossa, jos jokaisessa funktionaalisessa riippuvuudessa X -> A joko a) attribuuttijoukko X on relaation R yliavain tai b) A on avainattribuutti Attribuuttijoukko X on relaation R yliavain, mikäli X määrää funktionaalisesti relaation attribuuttien joukon Avainattribuutti on jokainen avainehdokkaisiin sisältyvä attribuutti Relaatio R on BC-normaalimuodossa jos sen on 3NF:ssa ja jokainen determinantti on avainehdokas Determinantti = attribuutti tai attribuuttiryhmä, josta joku muu ominaisuus on täysin funktionaalisesti riippuvainen Mikään funktionaalisen riippuvuuden oikealla puolella ei määrää mitään funktionaalisen riippuvuuden vasemmalla puolella

24 HAAGA-HELIA / TIKO 24 (40) Esim 1: 3NF ei BCNF R(A, B, C) AB on yliavain C ei ole yliavain, A on avainattribuutti Esim 2: 3NF ei BCNF Kussakin tiimissä kutakin oppilasta ohjaa vain 1 ohjaaja oppilas_id, tiimi_id -> ohjaaja_id Kukin ohjaaja ohjaa vain yhden tiimin jäseniä Ohjaaja_id -> tiimi_id OPPILAS_ID TIIMI_ID OHJAAJA_ID Totti Tekniikka Väätäinen Totti Talous Vihanti Tuuteri Tekniikka Väätäinen Tuuteri Hallinto Vakka Tapiainen Hallinto Vakkuri Jos jossakin tiimissä on vain vain1 jäsen ja ko. ainokainenkin päättää lopettaa, mitä tapahtuu tiedolle ko. tiimin ohjaajasta? Ratkaisu? R2(ohjaaja_id, tiimi_id) R12(oppilas_id, ohjaaja_id) Informaatiota voi kadota!

25 HAAGA-HELIA / TIKO 25 (40) 4. normaalimuoto 4NF Mielekäs vain jos ER-mallissa on 3 - n asteen suhteita muissa tapauksissa BCNF on automaattisesti myös 4NF (ja 5NF) Tulee yleensä tehtyä intuitiivisesti jo suunnittelun alkuvaiheessa R(X, Y, Z) X ->> Y ja X >> Z X ja Y voivat olla joko yksittäisiä attribuutteja tai attribuuttijoukkoja William Kent, "A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM 26(2), Feb.1983, Relaatio R on 4 normaalimuodossa joss se on BCNF ja sillä on korkeintaan yksi itsenäinen moniarvoinen riippuvuus Moniarvoinen riippuvuus N:M henkilö ->> julkaisu Julkaisu ->> henkilö 1:N äiti ->> lapsi

26 HAAGA-HELIA / TIKO 26 (40) Esim: Kurssin opet ja materiaali Kurssi ->> Ope Kurssi ->> Kirja OPPI Kurssi Ope Kirja Tietovarastot 1 Lahtinen Access 1 Tietovarastot 1 Lahtinen SQL 1 Tietovarastot 1 Virkki Access 1 Tietovarastot 1 Virkki SQL 1 Tietovarastot 2 Lahtinen SQL 1 Tietovarastot 2 Lahtinen SQL 2 Tietovarastot 2 Lahtinen SQL 3 Jos Tietovarastot 2 kurssille tulee 2. Opettaja, montako riviä relaatioon on lisättävä? Mitä pitää tehdä, jos Lahtinen lopettaa Tietovarastot 2 kurssin opetuksen? Ratkaisu? R1(kurssitunnus, opetunnus) R2(kurssitunnus, kirjatunnus)

27 HAAGA-HELIA / TIKO 27 (40) Itsenäisyys Esim: 1 itsenäiset ominaisuudet Taidon ja kielen välillä on yhteys vain henkilön kautta ts. se. ne liittyvät samaan henkilöön HLÖ Hlo_tunnus Taito Kieli Väinö Luku Suomi Väinö Luku Englanti Väinö Kirjoitus Suomi Väinö Kirjoitus Englanti Väinö Opetus Suomi Väinö Opetus Englanti Esim: 2 keskenään riippuvat ominaisuudet Taidon ja kielen välillä on yhteys ts. se. henkilöllä on tietty taito vain tietyllä kielellä HLÖ Hlo_tunnus Taito Kieli Väinö Luku Suomi Väinö Luku Englanti Väinö Kirjoitus Suomi Väinö Kirjoitus Englanti Väinö Opetus Suomi

28 HAAGA-HELIA / TIKO 28 (40) 5. normaalimuoto 5NF Relaatio on 5. Normaalimuodossa joss se on 4NF eikä sitä voi jakaa pienemmiksi osiksi informaation katoamatta. Esim: MYYJÄ YRITYS TUOTE Myyjä edustaa useampaa yritystä Yritys valmistaa useampia tuotteita ja Myyjä myy useita tuotteita Kuka myy mitäkin tuotetta minkäkin yrityksen lukuun? MYYNTI Myyjä_tunnus Yritys_tunnus Tuote_tunnus Väinö Renault Henkilöauto Väinö Renault Traktori Väinö Volvo Henkilöauto Risto Volvo Traktori Risto Volvo Bussi

29 HAAGA-HELIA / TIKO 29 (40) Mikäli on olemassa sovellusalueen sisäinen eheyssääntö, Jos myyjä myy tietyn tuotteen ja edustaa tiettyä yritystä, joka valmistaa ko. tuotetta, niin hän myy ko. tuotetta ko. yrityksen lukuun. Relaatio voidaan jakaa osiin: R1(myyjä, yritys) R2(myyjä, tuote) R3(yritys, tuote) Mikäli tämäntyyppistä eheyssääntöä ei ole määritelty 4NF on automaattisesti myös 5NF 5NF-normalisointi tulee harkittavaksi, mikäli relaation R(A,B,C) ominaisuudet eivät ole keskenään riippumattomia 5NF-normalisoinnin tuloksena on siten aina 3 tai useampia relaatioita

30 HAAGA-HELIA / TIKO 30 (40) Yhteenveto Relaatioiden ja kohdealueen objektien välille pyritään saamaan läheinen rakenteellinen vastaavuus Minimoidaan tietokantaan sisältyvää käsitteellistä ja talletettavista tiedoista aiheutuvaa redundanssia Tietokannan päivitysten yhteydessä mahdollisten anomalioiden välttäminen (lisäysanomalia, päivitysanomalia, poistoanomalia)

31 HAAGA-HELIA / TIKO 31 (40) Poista toistuvat ryhmät: Siirrä moniarvoiset attribuutit omiksi relaatioikseen Määritä kullekin relaatiolle pääavain 1NF Ei toistuvia ryhmiä kaikki attribuutit riippuvat pääavaimesta Poista osittaiset riippuvuudet: Siirrä pääavaimen osasta riippuvat attribuutit omiksi relaatioikseen 2NF 1NF + ei osittaisia riippuvuuksia pääavaimesta Poista transitiiviset riippuvuudet: Siirrä avaimesta epäsuorasti riippuvat ominaisuudet omiksi relaatioikseen 3NF 2NF + ei transitiivisia riippuvuuksia avaimesta Erota determinantti, joka ei ole avainehdokas omaksi relaatiokseen BCNF 3 NF + jokainen determinantti on avainehdokas Erota itsenäiset moniarvoiset riippuvuudet: Siirrä toisistaan riippumattomat moniarvoiset riippuvuudet omiksi relaatiokseen 4NF BCNF + korkeintaan 1 moniarvoinen riippuvuus Erota epäitsenäiset moniarvoiset riippuvuudet, mikäli se on mahdollista informaation katoamatta sovellukseen määritellyn eheyssäännön perusteella 5NF 4NF + ei ole jaettavissa osiin informaation katoamatta

32 HAAGA-HELIA / TIKO 32 (40) 1. Eliminate Repeating Groups Make a separate table for each set of related attributes, and give each table a primary key. 2. Eliminate Redundant Data If an attribute depends on only part of a multi-valued key, remove it to a separate table. 3. Eliminate Columns Not Dependent On Key If attributes do not contribute to a description of the key, remove them to a separate table. 4. Isolate Independent Multiple Relationships No table may contain two or more 1:n or n:m relationships that are not directly related. 5. Isolate Semantically Related Multiple Relationships There may be practical constrains on information that justify separating logically related many-to-many relationships.

33 HAAGA-HELIA / TIKO 33 (40) Esimerkki Tiedonhallintaseuran jäsenluettelo Nimi Tietokannat Oracle, Access Martti Laiho Solid, Allbase Leena Lahti Solid, Access Normalisoimatonta tietoa 1NF JÄSEN DB_KOKEMUS Hlö_id Hlö_nimi Hlö_id Db_id Db_nimi Oracle 2 Martti Laiho 1 3 Access 3 Leena Lahti 2 1 Solid 2 4 Allbase 3 1 Solid 3 3 Access

34 HAAGA-HELIA / TIKO 34 (40) DB_KOKEMUS Hlö_id Db_id Db_nimi 1 2 Oracle 1 3 Access 2 1 Solid 2 4 Allbase 3 1 Solid 3 3 Access 1 1 Solid 2NF DB_KOKEMUS DB Hlö_id Db_id taso Db_id Db_nimi 1 2 Hyvä 1 Solid 1 3 Hyvä 2 Oracle 2 1 Hyvä 3 Access 2 4 Hyvä 4 Allbase 3 1 Hyvä 3 3 Hyvä 1 1 Huono

35 HAAGA-HELIA / TIKO 35 (40) JÄSEN Hlö_id Hlö_nimi Yritys Kunta 1 HELIA HKI 2 Martti Laiho HELIA HKI 3 Leena Lahti HELIA HKI 4 Kaati Karkimo TAY TRE Kukin yritys sijaitsee vain yhdessä kunnassa 3NF JÄSEN YRITYS Hlö_id Hlö_nimi Y_id Y_id Y_kunta 1 HELIA HELIA HKI 2 Martti Laiho HELIA TAY TRE 3 Leena Lahti HELIA 4 Kaati Karkimo TAY

36 HAAGA-HELIA / TIKO 36 (40) DB_KOKEMUS Hlö_id Db_id taso arvioija 1 2 Hyvä OUGF 1 3 Hyvä Tieturi Hyvä HP Hyvä Tieturi 1 1 Huono Tieto Tietyn tietokantatuotteen arviointioikeus on annettu monelle yritykselle. Samalla yrityksellä voi olla vain 1 tuotteen arviointioikeudet. BCNF DB_KOKEMUS DB_ARVIOIJA Hlö_id arvioija taso Db_id arvioija 1 OUGF Hyvä 1 Tieturi Hyvä 2 OUGF Hyvä 3 Tieturi 2 4 Hyvä 4 HP Hyvä 1 Tieto 3 Tieturi Hyvä 1 Tieto Huono

37 HAAGA-HELIA / TIKO 37 (40) TAPAHTUMA Tap_id Päivä Aihe Tietoturva Hajautus Tietoturva Hajautus Vappu Rekrytointi Rekrytointi DW tilastotieto tietopalvelu Päivällä ja aiheella ei ole keskinäistä riippuvuutta. 4NF TAP_PAIVA TAP_AIHE Tap_id Päivä Tap_id Aihe Tietoturva Hajautus Vappu Rekrytointi DW tilastotieto 4 tietopalvelu

38 HAAGA-HELIA / TIKO 38 (40) tietty henkilö voi edustaa useita tiimejä tietty tiimi on edustettuna useassa tapahtumassa tietyssä tapahtumassa edustavat useat henkilöt EDUSTUS Hlö_id T_id Tap_id 1 Sanasto DB-98 1 Sanasto DB-99 2 Sanasto DB-97 2 Koulutus DB-98 2 Koulutus Koulu-97 2 Koulutus Koulu-98 Jos on voimassa sääntö (constraint), että Jos hlö on mukana tietyssä tapahtumassa ja edustaa jotakin tiimiä, joka on mukana ko. tapahtumassa, hän edustaa ko. tiimiä ko. tapahtumassa 5NF Hlö_id T_tap Hlö_tap Hlö_id T_id T_id Tap_id Hlö_id Tap_id 1 Sanasto Sanasto DB-98 1 DB-98 2 Sanasto Sanasto DB-99 1 DB-99 2 Koulutus Sanasto DB-97 2 DB-97 Koulutus DB98 2 DB98 Koulutus Koulu-97 2 Koulu-97 Koulutus Koulu-98 2 Koulu-98

39 HAAGA-HELIA / TIKO 39 (40) Denormalisointi? Riskit Parempi suorituskyky Yksinkertaisemmat kyselyt Esim. 1 1NF Kurssin perustietoihin kirjataan vastuuhenkilön nimi varaudutaan 3 vastuuhenkilöön. Entä kun joskus tulee 4-n.? Sovellusohjelmaa joudutaan muuttamaan Esim. 2 2NF & 3 NF & 4NF Projektin perustietoihin kirjataan osastonumeron lisäksi osaston nimi, jotta ad hoc kyselyjä tekevät saisivat kyselyihinsä mukaan myös osaston nimen. Entä kun osaston nimi muuttuu Kaikkien ko. tiedon päivitysten yhteydessä on (ohjelmoijan) muistettava päivittää ko. tieto kaikkiin sen kopioihin! Mikäli sama tieto kopioidaan vielä 2. Paikkaan, on muutettava kaikkia ohjelmia, joissa ko. tietoa päivitetään. + Mikäli tiedosta on kopioita, ristiriitaisen tiedon mahdollisuus kasvaa + Mikäli samasta tiedosta on kopioita useissa tauluissa, ko. tiedon päivitys synnyttää kirjoituslukituksia kaikkiin ko. tauluihin ja todennäköisesti hidastaa järjestelmän toimintaa mikäli ko. tietoa päivitetään usein

40 HAAGA-HELIA / TIKO 40 (40) Ohjelmien tietoriippumattomuus menetetään Tietokannan ristiriidattomuus ja luotettavuus riskeerataan Suorituskyky saattaa heiketä Loogisen suunnittelun vaiheessa ei denormalisointia edes harkita Tavoitetila: 3NF Tietokannan suunnittelun ja testauksen yhteydessä denormalisointia voi harkita mikäli suorituskyky näyttää huonolta Loppukäyttäjän kyselyjen helpottamiseksi kannattaa tuottaa näkymä, joka kokoaa yhteen tietoja useammasta relaatiosta