luento l: normalisointi - haaga-helia...

HAAGA-HELIA / TIKO 1 (40) Outi Virkki Tietokantasuunnittelu 4.9.2008

tks_L3_normalisointi.doc 4.9.2008 18:01:00

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 .................................................................... 7

1. Normaalimuoto ................................................................................ 10

Miksi 1NF ? .......................................................................................... 11

2. Normaalimuoto ................................................................................ 12

Miksi 2NF ? .......................................................................................... 13

3. Normaalimuoto ................................................................................ 14

Miksi 3NF ? .......................................................................................... 15

Normalisointiprosessi ............................................................................ 16

3NF = Normalisoinnin tavoitetaso ! ................................................ 17

Normalisointiesimerkki: Kurssihallinto ................................................. 18

Avaimista ............................................................................................... 22

Boyce/Codd –normaalimuoto BCNF .............................................. 23

4. normaalimuoto 4NF ........................................................................ 25

Itsenäisyys .......................................................................................... 27

5. normaalimuoto 5NF ........................................................................ 28

Yhteenveto ............................................................................................ 30

Esimerkki ................................................................................................. 33

Denormalisointi ? ...................................................................................... 39

Riskit ........................................................................................................ 39



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



~ 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

5NF 4NF BCNF 3NF 2NF 1NF

Kaikki relaatiot

~ 3.normaalimuoto on normalisoinnin 'minimitaso' /

tavoitetaso ~ Ylempiä normaalimuotoja käsitellään syventävillä

kursseilla



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ö



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



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



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



Normalisoinnissa tavoitellaan riippuvuuksia, jotka ovat

1. Funktionaalisia 2. Suoria 3. Täydellisiä



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ä)



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)



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




~ 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,…)



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ä ?





~ 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 ei-

avaimena 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)



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ää ?




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)



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)



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)



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)



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)



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 !



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



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 …



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 !



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, 120-125.

http://home.earthlink.net/~billkent/Doc/simple5.htm 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



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)



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



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



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



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)



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



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.



Esimerkki Tiedonhallintaseuran jäsenluettelo

Nimi Tietokannat … Outi Virkki 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 … 1 Outi Virkki 1 2 Oracle 2 Martti Laiho 1 3 Access 3 Leena Lahti 2 1 Solid 2 4 Allbase 3 1 Solid 3 3 Access



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



JÄSEN Hlö_id Hlö_nimi Yritys Kunta 1 Outi Virkki 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 Outi Virkki HELIA HELIA HKI 2 Martti Laiho HELIA TAY TRE 3 Leena Lahti HELIA 4 Kaati Karkimo TAY



DB_KOKEMUS Hlö_id Db_id taso arvioija … 1 2 Hyvä OUGF 1 3 Hyvä Tieturi 2 1 Hyvä @B 2 4 Hyvä HP 3 1 Hyvä @B 3 3 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 @B 1 Tieturi Hyvä 2 OUGF 2 @B Hyvä 3 Tieturi 2 4 Hyvä 4 HP 3 @B Hyvä 1 Tieto 3 Tieturi Hyvä 1 Tieto Huono



TAPAHTUMA Tap_id Päivä Aihe … 1 2.3.1999 Tietoturva 1 2.3.1999 Hajautus 1 3.3.1999 Tietoturva 1 3.3.1999 Hajautus 2 1.5.1999 Vappu 3 1.10.1999 Rekrytointi 3 2.10.1999 Rekrytointi 4 1.11.1999 DW 4 1.11.1999 tilastotieto 4 1.11.1999 tietopalvelu

Päivällä ja aiheella ei ole keskinäistä riippuvuutta.

4NF

TAP_PAIVA TAP_AIHE Tap_id Päivä … Tap_id Aihe … 1 2.3.1999 1 Tietoturva 1 3.3.1999 1 Hajautus 2 1.5.1999 2 Vappu 3 1.10.1999 3 Rekrytointi 3 2.10.1999 4 DW 4 1.11.1999 4 tilastotieto 4 tietopalvelu



• 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



Denormalisointi ? Parempi suorituskyky Yksinkertaisemmat kyselyt

Riskit 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



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

luento l: normalisointi - haaga-helia...

Documents