HELIA 1 (19) Outi Virkki Tietokantasuunnittelu

Transkriptio

1 HELIA 1 (19) Luento 7 Normaalimuodot jatkuu... 2 Boyce/Codd normaalimuoto BCNF normaalimuoto 4NF... 4 Itsenäisyys normaalimuoto 5NF... 7 Yhteenveto... 9 Esimerkki Denormalisointi? Riskit... 18

2 HELIA 2 (19) Normaalimuodot jatkuu 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

3 HELIA 3 (19) 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 HELIA 4 (19) 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

5 HELIA 5 (19) 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)

6 HELIA 6 (19) 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

7 HELIA 7 (19) 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

8 HELIA 8 (19) 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

9 HELIA 9 (19) 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)

10 HELIA 10 (19) 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

11 HELIA 11 (19) 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.

12 HELIA 12 (19) 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

13 HELIA 13 (19) 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

14 HELIA 14 (19) 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

15 HELIA 15 (19) 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

16 HELIA 16 (19) 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

17 HELIA 17 (19) 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

18 HELIA 18 (19) 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

19 HELIA 19 (19) 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