10. Funktionaaliset riippuvuudet ja relaatiotietokannan normalisointi

Esitys aiheesta: "10. Funktionaaliset riippuvuudet ja relaatiotietokannan normalisointi"— Esityksen transkriptio:

1 10. Funktionaaliset riippuvuudet ja relaatiotietokannan normalisointi
Tähän mennessä olemme ehtineet suunnitella tietokannan käsitteellistä ER- ja EER-mallinnusta käyttäen ja muuntaneet sittemmin mallin mukaisen lopputuloksen relaatiomalliin sopivaksi mm. esittelemällä vahvat entiteettityypit relaatiotauluina, purkamalla moniarvoiset attribuutit omiksi relaatioikseen sekä esittelemällä suhteet pää- ja vierasavainkenttien välisinä liitoksina ( lukumääräsuhteet 1:1, 1:N ) tai lisätauluina ( lukumääräsuhde M:N ). Kuitenkaan emme ole ottaneet kantaa siihen, minkä tähden jokin tietty attribuuttien ryhmittely eri relaatiotauluihin on parempi kuin jokin toinen. Relaatiokaavojen hyvyyttä voidaan tarkastella joko loogisella eli käsitetasolla tai fyysisellä eli toteutustasolla. Käsitetasolla voidaan selvittää, miten käyttäjät tulkitsevat relaatiokaavat sekä niihin kuuluvien attribuuttien merkityksen. Mitä selkeämpiä relaatiokaavat ovat, sitä helpompaa on käyttäjien muodostaa virheettömiä kyselyitä tietokantaan. Toteutustasolla ollaan puolestaan kiinnostuneita siitä, miten varsinaisten relaatiotaulujen sisältämät tuplat on tallennettu.

2 Tietokannan suunnittelu voi edetä kahteen suuntaan: joko yksittäisistä attribuuteista alkaen kohti entiteettityyppien muodostamista ( alhaalta ylöspäin – suunnittelu synteesin avulla ) tai hahmottelemalla suoraan relaatiokaavoja ja tekemällä siihen tarkennuksia ja korjauksia tarpeen mukaan ( ylhäältä alaspäin – suunnittelu analyyttisesti ). Ensimmäinen vaihtoehto tuottaa aluksi liian pieniä relaatiotauluja, s. o. kaikkia tarvittavia attribuutteja ei koota heti samaan kaavaan, kun taas jälkimmäisessä saatetaan kerätä liikaa attribuutteja yhdelle entitettityypille. Jatkossa keskitytään lähinnä ylhäältä alaspäin etenevään suunnitteluun. Tarkoituksena on tarkastella relaatiokaavojen laadukkuutta ensin neljällä ei-formaalilla kriteereillä. Myöhemmin määritellään funktionaalisen riippuvuuden käsite, joka on formaalisti määritelty ja joka mittaa attribuuttien ryhmittelyn kelvollisuutta eri relaatiokaavojen välillä. Myös funktionaalisen riippuvuuden eri lajeja analysoidaan. Lopuksi tarkastellaan relaatiokaavojen hyvyyden astetta tietokannan ns. normaalimuotojen avulla.

3 10.1 Ei-formaalit ohjesäännöt relaatiokaavojen suunnittelua varten
Seuraavassa tarkastellaan neljää ei-formaalia kriteeriä relaatiokaavan laadukkuudelle, jotka ovat: 1. Attribuuttien semantiikka 2. Redundanttien arvojen minimointi tuplissa 3. Puuttuvien arvojen minimointi 4. Valetuplien generoinnin estäminen Relaation attribuuttien semantiikka Semantiikalla tarkoitetaan tässä yhteydessä, miten käyttäjä tulkitsee relaation tuplan attribuuttien arvot. Mikäli käsitteellinen suunnittelu on tehty huolellisesti, ja sitä on seurannut kuvaus relaatiomalliin luvun 7.1 algoritmin mukaisesti, saadun relaatiomallin mukaisen esityksen pitäisi olla tulkittavissa yksikäsitteisesti ongelmitta.

4 Yleisesti ottaen, mitä helpompaa on relaatiokaavan tulkitseminen, sitä parempana relaatiokaavaa voidaan pitää. Tarkastellaan kirjan esimerkkiä 10.1 yksinkertaistetusta yrityksen tietokannasta sekä esimerkissä 10.2 esitettyä yhtä mahdollista kyseisen tietokannan tilaa. Selvästikin relaation EMPLOYEE merkitys on helposti ymmärrettävissä: jokainen taulun tupla esittää yksittäistä työntekijää, ja hänestä tallennetaan etunimi, henkilötunnus, syntymäaika, osoite ja osastonumero, jolla hän työskentelee. Pääavaimena taulussa toimii henkilötunnus, joka erottelee työntekijät toisistaan. Samoin relaatioiden DEPARTMENT ja PROJECT tulkinta on hyvin suoraviivainen. Taulujen DEPT_LOCATIONS ja WORKS_ON tulkinta on jossain määrin monimutkaisempi. Ensin mainitun jokainen tupla edustaa yhden osaston yhtä toimipistettä. Jokaista toimipistettä kohti muodostetaan tupla kunkin osaston osalta. Jälkimmäisessä puolestaan yksi tupla edustaa yhden työntekijän työtunteja yhteen projektiin. Jokaista työntekijää kohti muodostuu niin monta tuplaa kuin on projekteja, joissa hän työskentelee. Taulu WORKS_ON edustaa suhdetta M:N työntekijän ja projektin välillä. Hieman monimutkaisemmasta tulkinnastaan huolimatta myös nämä kaksi kaavaa ovat hyvin määriteltyjä ja tulkittavissa yksikäsitteisesti.

5 10.1.2 Tuplien redundantti tieto sekä päivityksiin liittyvät anomaliat
OHJESÄÄNTÖ 1: Suunnittele relaatiokaava siten, että sen merkitys on helppo selittää. Ei pidä sekoittaa eri entiteettityyppien attribuutteja samaan relaatioon. Merkitys pysyy selkeänä, kun taulu sisältää tarkalleen yhdelle entiteettityypille tai suhdetyypille ominaisia attribuutteja. Tarkastellaan kirjan esimerkkiä Kohdassa ( a ) työntekijän tietoihin on lisätty taulusta DEPARTMENT attribuutit, jotka kuvaavat hänen osastonsa nimeä ja sen johtajaa. Vastaavasti kohdassa ( b ) suhdetyypin taulua WORKS_ON on täydennetty taulun EMPLOYEE attribuutilla ENAME sekä taulun PROJECT attribuuteilla PNAME ja PLOCATION. Vaikkakin kummankin taulun attribuuttien merkitys on helposti tulkittavissa, taulut rikkovat kuitenkin ohjesääntöä 1, sillä eri entiteettityyppien attribuutteja ei pidä sekoittaa toisiinsa. Esimerkin 10.3 mukaiset taulut voisivat kuitenkin hyvin esiintyä tietokannan näkyminä tietyille käyttäjille. Tuplien redundantti tieto sekä päivityksiin liittyvät anomaliat Tarkastellaan kirjan esimerkkiä 10.4 relaatioiden EMP_DEPT ja EMP_PROJ tilasta, ja verrataan sitä esimerkin 10.2 mukaiseen, jossa sekä työntekijää, osastoa ja projektia koskevat tiedot on säilötty erilleen toisistaan.

6 Vaikkakin esimerkin 10.2 tauluissa EMPLOYEE ja DEPARTMENT sisältävät yhteenlaskettuna enemmän tuplia kuin esimerkin 10.4 mukaisessa yhdistelmärelaatiossa EMP_DEPT, näyttää taulu EMP_DEPT kuitenkin paljon kookkaammalta, sillä jokaista työntekijää kohti joudutaan tallentamaan myös osastoa kuvaavat attribuutit. Siten saman osaston tiedot toistuvat taulussa niin monta kertaa kuin sillä on kirjoilla työntekijöitä. Tämä ei ole tarpeen esimerkissä 10.2 työntekijän ja osaston tietojen ollessa erillisiä. Mikäli verrataan puolestaan tauluja EMP_PROJ tauluihin EMPLOYEE, WORKS_ON ja PROJECT niiltä osin, kuin niissä esiintyy samoja attribuutteja, vaikuttaa taulu EMP_PROJ varsin täyteiseltä mihin tahansa viimeksi mainittuun erillistauluun verrattuna. Sijoitettaessa usean entiteettityypin attribuutteja samaan tauluun muodostuu päivitysten anomalioiden ongelma tehtäessä tauluun lisäyksiä, poistoja ja muutoksia. Tarkastellaan seuraavassa taulua EMP_DEPT, jonka pääavaimena on henkilötunnus. Uuden työntekijän lisääminen tauluun edellyttää myös osaston tietojen sijoittamista tuplaan samalla. Osaston tietoja syötettäessä pitää olla tarkkana, että ne syötetään samalla tavalla kuin aikaisemmin samalle osastolle kirjattujen työntekijöiden kohdalla. Muutoin kyseisien osaston tiedoista tulee inkonsistentteja. Tällaista ongelmaa ei ilmenisi, jos osaston tiedot pidettäisiin erillään työntekijää kuvaavista tiedoista. Jos osastoa ei heti tiedetä, jätetään osastoa koskevat tiedot puuttuviksi.

7 Erityisen ikävä tilanne muodostuisi silloin, kun haluttaisiin perustaa yritykseen uusi osasto, jolle ei kuitenkaan voitaisi samalla nimetä ketään työntekijää. Tällöin pitäisi syöttää tauluun EMP_DEPT tupla, jossa työntekijää koskevat attribuutit jätettäisiin tyhjiksi, mutta koska henkilötunnus on taulun pääavain, ei NULL-arvojen salliminen kenttään tuntuisi järkevältä ( ad hoc -ratkaisu: perustetaan jokin ’haamutyöntekijä’ uudelle osastolle. Kun osastolle ilmestyy ensimmäinen aito työntekijä, korjataan perustetun pseudotietueen henkilötiedot järkeviksi. ). Tietueen tuhoamiseen liittyvä anomalia: voidaan menettää vahingossa tietoa, jota ei olisi ollut tarkoitus poistaa. Osaston ainoan työntekijän irtisanoutuminen veisi mennessään myös osaston tiedot, vaikkei tätä ( välttämättä ) olisikaan haluttu! Näin ei kävisi esimerkin 10.2 mukaisessa tietokannassa. Tiedon muuttamisen anomalia: riski tiedon muuttumisesta inkonsistentiksi. Mikäli vaikkapa osaston 5 johtaja vaihtuisi, pitäisi tieto uuden johtajan henkilötunnuksesta sijoittaa kaikkiin niihin taulun EMP_DEPT tupliin, joissa osastonumerona on 5. Tällainen menettely ei olisi tarpeen esimerkin 10.2 tietokannassa. OHJESÄÄNTÖ 2: Suunnittele relaatiokaavat siten, ettei anomalioita voi esiintyä päivityksissä. Mikäli niitä kaikesta huolimatta siinä esiintyy, varmistu sovellusohjelmien oikeellisuudesta.

8 10.1.3 Puuttuvat arvot tuplissa
Muodostettaessa tietokantaa analyyttisellä suunnittelulla ( ylhäältä alas ) valitaan johonkin entiteettityyppiin toisinaan attribuutteja, jotka ovat siihen liiaksi erikoistettuja. Tällöin syntyy tilanne, jossa yhtä tuplaa kohti useita attribuutteja saattaa jäädä puuttuviksi, mikä saattaa aiheuttaa harmia mm. erityyppisiä liitoksia tehtäessä tai aggregaattifunktioita käytettäessä. Puuttuvilla arvoilla on lisäksi erilaisia tulkintoja: Attribuutti ei koske lainkaan taulun jotain tuplaa Attribuutin arvo on tuntematon – ei tietoa, onko arvo saatavilla Attribuutin arvon tiedetään olevan saatavilla, mutta sitä ei jostain syystä ole tallennettu. OHJESÄÄNTÖ 3: Yritä mahdollisimman tarkoin rajoittaa sellaisten usein NULL-arvoja sisältävien attribuuttien sijoittaminen relaatiokaavaan. NULL-arvojen tulee olla poikkeuksia. Esimerkki: jos vain 10%:lla työntekijöistä on oma työhuone, ei työhuonetta kuvaavaa attribuuttia kannata sijoittaa työntekijöiden perustietoihin, vaan erilliseen relaatiotauluun.

9 10.1.4 Valetuplien generointi
Tarkastellaan kirjan esimerkkiä 10.5 hyvin huonosta relaatiokaavan suunnittelusta. Oletetaan, että on perustettuna taulu EMP_PROJ, joka sisältää kaikki taulun WORKS_ON attribuutit ja niiden lisäksi tiedon työntekijän nimestä, projektin nimestä ja sen sijaintipaikasta. Ositetaan tämä relaatio tauluiksi EMP_LOCS, joka sisältää tiedot työntekijän nimestä sekä sen projektin sijaintipaikasta, jossa hän työskentelee, sekä EMP_PROJ1, joka sisältää taulun WORKS_ON attribuutit sekä lisäksi attribuutit PNAME ja PLOCATION. Mikäli nyt muodostettaisiin liitos taulujen EMP_LOCS ja EMP_PROJ1 välille, ainoa mahdollinen liitosattribuutti olisi PLOCATION. Taulujen välinen luonnollinen liitos ei kuitenkaan muodostaisi alkuperäistä taulua EMP_PROJ, sillä liitosattribuutti ei koostu päävain-vierasavain -parista. Tuloksena olisi isokokoinen tulostaulu, joka sisältäisi paljon virheellisiä tuplia, sillä esimerkiksi John Smithiä kuvaavat tietueet taulussa EMP_PROJ1 liitettäisiin kaikkien niiden taulun EMP_LOCS tuplien kanssa, joissa projektin sijaintipaikka on sama. Täten esimerkiksi taulun EMP_PROJ1 toisen tuplan perään liitettäisiin vuoron perään paitsi Smithiä itseään niin myös Franklin Wongin ja Joyce Englishin tiedot, koska jokainen heistä työskentelee Sugarlandissa toimivassa projektissa 2 ( kts. kirjan esimerkki 10.6 )!

10 10.2 Funktionaaliset riippuvuudet
OHJESÄÄNTÖ 4: Suunnittele relaatiokaavat siten, että niiden välille voidaan muodostaa liitos pääavain-vierasavain paria käyttämällä siten, että liitoksella saatujen tuplien oikeellisuus on taattu Älä muodosta liitosta attribuuttien välille, jotka eivät täytä em. vaatimusta. Alkuperäisen relaation osittamisen pitää tapahtua siten, että liitosten avulla voidaan alkuperäinen taulu rekonstruoida ositteistaan. 10.2 Funktionaaliset riippuvuudet Funktionaalisen riippuvuuden käsite on tärkein yksittäinen relaatiokaavan suunnitteluteoriaan liittyvä käsite. Funktionaalisen riippuvuuden määritelmä Kuvitellaan aluksi, että kaikki tietokannassa tarvittavat attribuutit on sijoitettu yhteen ainoaan isoon tauluun R = { A1, A2, …, An }. Merkitään tunnuksilla X ja Y R:ään kuuluvien attribuuttien mielivaltaisia osajoukkoja ( = komponentteja ). Relaatiossa R vallitsee funktionaalinen riippuvuus attribuuttijoukkojen X ja Y välillä, eli X --> Y, mikäli taulun R mitä tahansa kahta tuplaa kohti on aina voimassa ehto t1[X] = t2[X] --> t1[Y] = t2[Y].

11 Funktionaalinen riippuvuus X --> Y tarkoittaa, että komponentin X arvo(t) määräävät yksikäsitteisesti komponentin Y arvo(n/t). Funktionaalinen riippuvuus ( lyhennetään FR ) on attribuuttien semantiikan ominaisuus. Kun X --> Y on voimassa tietyssä relaatiokaavassa R, ei voi esiintyä sellaista laillista tietokannan tilaa r(R) siten, että kahdessa eri tuplassa komponentin X arvot olisivat samat, mutta komponentin Y arvot eroaisivat toisistaan. Jos X on R:n ehdokasavain, määräytyvät Y:n arvot väistämättä yksikäsitteisesti X:n perusteella, sillä X ei sisällä duplikaatteja. Funktionaalisen riippuvuuden X --> Y ollessa voimassa ei päinvastainen eli Y --> X ( välttämättä ) toteudu ( vrt. taulussa TYÖNTEKIJÄ hetu --> osastonumero ). Tarkastellaan relaatiokaavaa EMP_PROJ kuvassa 10.3 (b). Seuraavat funktionaaliset riippuvuudet ovat voimassa: 1. SSN --> ENAME 2. PNUMBER --> { PNAME, PLOCATION } 3. { SSN, PNUMBER } --> HOURS Siten henkilötunnus määrää yksikäsitteisesti työntekijän nimen, projektinumero projektin nimen ja sen sijaintipaikkakunnan sekä yhdistelmä hetu-projektinumero yksittäisen työntekijän työtunnit yhtä projektia kohti viikossa.

12 10.2.2 Päättelysäännöt funktionaalisille riippuvuuksille
Kannattaa huomioida, että funktionaalinen riippuvuus on relaatiokaavan eikä sen tilan määräämä ominaisuus, eli relaation tilasta ei voida päätellä funktionaalisen riippuvuuden olemassaoloa kahden attribuuttijoukon välillä. Sen sijaan sellaisen olemassaolon kiistäminen voidaan tehdä yhden vastaesimerkin turvin Tarkastellaan kirjan esimerkkiä 10.7 edelliseen aiheeseen liittyen. On selvää, ettei luennoitava kurssi määräydy yksikäsitteisesti tiedettäessä opettajan nimi. Sen sijaan on mahdollista, että kurssikirja voisi ilmaista, mistä kurssista on kyse, mutta pelkän relaation tilan perusteella tätä ei voida todentaa! Päättelysäännöt funktionaalisille riippuvuuksille Tietyn attribuuttijoukon X kaikkien funktionaalisten riippuvuuksien transitiivinen sulkeuma F+ muodostuu kaikista tietokannan attribuuttien joukosta, joiden arvo määräytyy yksikäsitteisesti X:n perusteella – joko suoraan tai ’mutkan kautta’. Jos on esimerkiksi voimassa funktionaalisten riippuvuuksien joukko F = { SSN --> { ENAME, ADDRESS, DNUMBER }, DNUMBER --> { DNAME, MGRSSN } } voidaan johtaa seuraavat lisäriippuvuudet F:stä SSN --> { DNAME, MGRSSN}, SSN --> SSN, DNUMBER --> DNAME

13 Funktionaalisten riippuvuuksien johtamiseksi voidaan käyttää apuna seuraavia logiikan ja joukko-opin päättelysääntöjä ( IR = inference rule ). Merkintä ᅣ tarkoittaa ”on johdettavissa”. IR1 ( refleksiivisyys ): Jos X  Y, niin X --> Y IR2 ( laajentaminen ): { X --> Y } ᅣXZ --> YZ IR3 ( transitiivisuus ): { X --> Y, Y --> Z} ᅣ X --> Z IR4 ( dekompositio ): { X --> XZ } ᅣ X --> Z IR5 ( additiivisuussääntö ): { X --> Y, X --> Z } ᅣ X --> YZ IR6 ( pseudotransitiivisuus ): { X --> Y, WY --> Z} ᅣ WX --> Z Säännöistä kolme ensimmäistä ovat terveitä ja riittäviä, eli niiden avulla pystytään etsimään kaikki X:stä funktionaalisesti riippuvat komponentit. Edellä esitetyt päättelysäännöt voidaan todistaa oikeaksi, mutta todistukset sivuutetaan tässä ( löytyvät kirjasta, mutta esitetään kuitenkin luennolla ). Esimerkki: mikäli F sisältää funktionaaliset riippuvuudet { SSN --> ENAME, PNUMBER --> { PNAME, PLOCATION} {SSN, PNUMBER} --> HOURS }

14 10.2.3 Funktionaalisten riippuvuusjoukkojen ekvivalenssi
saataisiin { SSN }+ = { SSN, ENAME } { PNUMBER }+ = { PNUMBER, PNAME, PLOCATION } { SSN, PNUMBER }+ = { SSN, PNUMBER, ENAME, PNAME, PLOCATION, HOURS } Funktionaalisten riippuvuusjoukkojen ekvivalenssi Määritelmä: Funktionaalisten riippuvuuksien joukon F sanotaan peittävän toisen funktionaalisten riippuvuuksien joukon E, mikäli jokainen E:hen kuuluva FR kuuluu myös joukkoon F+, eli jokainen E:n sisältämä FR voidaan johtaa F:stä. Toisin sanoen F peittää E:n. Määritelmä: Kaksi funktionaalisten riippuvuuksien joukkoa E ja F ovat ekvivalentit, mikäli E+ = F+. Tällöin jokainen E:n sisältämä FR voidaan johtaa F:stä ja vastaavasti jokainen F:ään kuuluva FR on johdettavissa E:stä. On mahdollista testata, peittääkö funktionaalisten riippuvuuksien joukko F joukon E generoimalla joukko X+ jokaista E:hen kuuluvaa FR:ää X --> Y kohti ja tutkimalla, kuuluuko jokainen Y tällä tavoin muodostettuun X+:aan. Mikäli näin on, tällöin F peittää E:n.

15 10.2.4 Funktionaalisten riippuvuuksien minimaalinen joukko
F on E:n funktionaalisten riippuvuuksien minimaalinen peittävän joukko, jos seuraavat ominaisuudet ovat voimassa: F:n sulkeuma F+ sisältää kaikki E:ssä esiintyvät funktionaaliset riippuvuudet Poistamalla yksikin F:ään kuuluva FR ei peittävyysominaisuus ole enää voimassa. Minimaalinen peittävä joukko F voidaan formaalisti määritellä seuraavanlaisesti: 1) Jokainen F:ään kuuluva FR sisältää oikealla puolella ainoastaan yhden attribuutin, eli A on yksinkertainen attribuutti ilmauksessa X --> A. 2) Ei ole mahdollista korvata mitään F:ään kuuluvaa FR:ää X --> A toisella FR:llä Y --> A, missä Y on X:n aito osajoukko siten, että tällöin muodostuva funktionaalisten riippuvuuksien joukko F' olisi yhä ekvivalentti F:n kanssa. 3) F:stä ei voida poistaa mitään FR:ää siten, että poiston seurauksena muodostuva joukko F' olisi yhä ekvivalentti F:n kanssa.

16 Edellisessä formaalissa määrittelyssä ehto 1) takaa sen, ettei FR:n oikealla puolella esiinny kuin yksinkertaisia attribuutteja riippuvuuksien esitysmuodon yksinkertaistamiseksi. Ehdon 2) mukaisesti FR:n vasemmalla puolella ei saa esiintyä turhia attribuutteja, ja ehto 3) hävittää funktionaaliset riippuvuudet, jotka ovat lausuttavissa jo F:ssä ennestään esiintyvien FR:ien avulla. Funktionaalisten riippuvuuksien minimaalinen peittävän joukko on ns. standardi- eli kanoninen muoto, joka ei sisällä redundanssia. Tällaisia standardimuotoja voi olla useita, ja ainakin yksi tällainen voidaan löytää käyttämällä seuraavassa esitettävää algoritmia 10.2. Algoritmi 10.2: Selvitetään FR:ien joukon E minimaalinen peitto F: 1. Aseta F := E 2. Korvaa jokainen F:n funktionaalinen riippuvuus X --> { A1, A2, ..., An } funktionaalisilla riippuvuuksilla X --> A1, X --> A2, ..., X --> An. 3. Toista jokaista F:n funktionaalista riippuvuutta X --> A kohti Toista jokaista X:ään kuuluvaa attribuuttia B kohti Jos { { F - { X --> A } } U { X - { B } ) --> A } on ekvivalentti F:n kanssa, korvaa X --> A FR:llä ( X - { B } ) --> A joukossa F. 4. Toista jokaista F:ssä jäljellä olevaa FR:ää X --> A kohti Jos { F - { X --> A } } on ekvivalentti F:n kanssa, poista FR X --> A joukosta F.

17 10.3 Pääavaimeen perustuvat normaalimuodot
Seuraavassa oletetaan, että jokaisen tarkasteltavan relaation funktionaaliset riippuvuudet ovat tiedossa, ja jokaiselle relaatiolle on asetettu pääavain. Tämän jälkeen on mahdollista käynnistää relaatiokaavan normalisointi. Tässä yhteydessä tarkastellaan normaalimuotoja 1 - 3, jotka perustuvat pääavainkenttiin. Relaatioiden normalisointi Normaalimuodot toimivat relaatiokaavan yksinä laadukkuuden mittareina: Mitä korkeampaa normaalimuotoa relaation kaava edustaa, sitä laadukkaampi sen sanotaan olevan. Tärkeimmät normaalimuodoista ovat 1., 2. ja 3. normaalimuoto ( 1NF, 2NF ja 3NF ) sekä Boyce-Coddin normaalimuoto ( BCNF ). Lisäksi on olemassa vielä normaalimuodot 4NF ja 5NF, jotka käsitellään luvussa 11. Normaalimuotojen toteutumista relaatiokaavassa voidaan testata. Ellei kaava toteuta tarkasteltavaa normaalimuotoa, kaava muotoillaan uudelleen eli ns. normalisoidaan.

18 Relaatiokaavan ollessa tietyn normaalimuodon täyttävä, esimerkiksi NFX, se on myös kaikkien alempaa järjestyslukua olevien normaalimuotojen mukainen. Esimerkiksi, jos relaatio on normaalimuotoa NF2, se on täyttää myös NF1:n vaatimukset. BCNF on 3. normaalimuotoa tiukempi vaatimus. Datan normalisointi voidaan ymmärtää prosessina, jossa tarkastelemalla annettujen relaatiokaavojen pääavaimia ja kaavan funktionaalisia riippuvuuksia pyritään relaatio muotoilemaan tarpeen mukaan uudelleen ns. dekompositiolla siten, että Tietokannassa esiintyvä redundanssi minimoituisi Tietueiden lisäämiseen, niiden tietosisällön muuttamiseen sekä tuhoamiseen liittyvät anomaliat karsiutuisivat mahdollisimman hyvin Mikäli relaatiokaava ei toteuta vaadittavaa normaalimuotoa, se jaetaan kahdeksi tai useammaksi pienemmäksi relaatioksi, jotka ovat vaaditun normaalimuodon täyttäviä. Kannattaa kuitenkin huomioida, että normalisointi ei muista laadukkuuteen vaikuttavista tekijöistä eristettynä takaa, että tietokanta olisi hyvin suunniteltu! Vaadittujen normaalimuotojen toteutumisen ohella pitää kiinnittää huomiota seuraavien ominaisuuksien toteutumiseen: Häviöttömän eli ei-additiivisen liitoksen ominaisuus, joka edellyttää, ettei relaatiokaavan uudelleen järjestäminen voi johtaa valetuplien generointiin

19 10.3.4 Ensimmäinen normaalimuoto
Relaation sisältämien funktionaalisten riippuvuuksien säilyminen myös tehdyn dekomposition jälkeen Näistä ehdoista ensin mainitun toteutuminen on ehdoton edellytys dekompostion onnistumiselle. Jälkimmäisestä vaatimuksesta voidaan tietyissä tapauksissa joustaa. Ensimmäinen normaalimuoto Relaatiokaava toteuttaa 1. normaalimuodon kriteerit, mikäli se sisältää ainoastaan atomisia attribuutteja ( ei koosteisia eikä moniarvoisia ). Mikäli ei-atomisia attribuutteja esiintyy, pitää koosteiset attribuutit jakaa osiinsa ja moniarvoiset attribuutit esitellä uutena relaationa ( kts. kohdassa 7.1 esitetty algoritmi). Myös moniarvoisen attribuutin arvojen maksimimäärään varautuminen on mahdollista perustamalla riittävän monta attribuuttia. Usein tuloksena on kuitenkin tarpeettomia NULL-arvoja. Tarkastellaan kirjan esimerkkiä 10.8, jossa poistetaan osaston toimipisteitä edustanut moniarvoinen attribuutti. Esimerkin mukainen taulu ei ole oikeastaan edes relaatiomallin vaatimuksia täyttävä ( sisältää moniarvoisen attribuutin ).

20 Koska relaaatiotaulun OSASTO attribuutti Toimipisteet on moniarvoinen, se ei ole funktionaalisesti täysin riippuva pääavaimesta ( voi esiintyä useita mahdollisia arvoja ). Pulma ratkeaa poistamalla 1NF:ää rikkonut attribuutti Toimipisteet taulusta Osasto. Toimipisteiden kuvaamiseksi perustetaan erillinen taulu, jonka pääavain muodostuu osastonumerosta ( taulun OSASTO pääavaimesta ) sekä toimipisteen sijaintipaikkakunnasta. Pulma olisi vaihtoehtoisesti voitu ratkaista varautumalla osastokohtaisten toimipisteiden maksimimäärään perustamalla riittävän monta attribuuttia toimipisteitä varten ( Toimipiste1, Toimipiste2, ..., ToimipisteN ) tauluun OSASTO, mutta ratkaisu olisi kömpelö, sillä Toimipisteiden tarve osastoittain saattaa vaihdella suuresti, jolloin seurauksena olisi useiden NULL-arvojen ilmestyminen tietokantaan. Onko eri toimipisteattribuuteilla tulkinnassa jotain aste-eroja? Kyselyiden rakentaminen vaikeutuu huomattavasti, kun pitää huomioida paikkakunnan nimen esiintyminen missä tahansa toimipisteen nimeä edustavassa attribuutissa.

21 Toinen normaalimuoto Relaatiokaava on toisessa normaalimuodossa, mikäli taulun kaikki avaimeen kuulumattomat attribuutit ovat funktionaalisesti täydellisesti riippuvia koko avainattribuuttien yhdistelmästä – ei pelkästään avaimen osasta. Toisen normaalimuodon testaaminen on tarpeellista silloin, jos jokin taulun ehdokasavaimista koostuu useammasta kuin yhdestä attribuutista. Tarkastellaan kirjan esimerkkiä Todetaan, että relaatio EMP_PROJ ei ole 2NF, sillä työntekijän nimi määräytyy pelkän henkilötunnuksen perusteella ( pääavaimen osa ) ilman projektinumeroa. Samoin projektinumero määrää yksikäsitteisesti projektin nimen ja sijaintipaikan ilman, että henkilötunnuksella on mitään merkitystä. Relaatio, joka ei ole 2NF, pitää osittaa siten, että yksistään avaimen osasta riippuvat attribuutit sijoitetaan riittävän avaimen osan kanssa toiseen relaatiotauluun. Sen sijaan koko pääavaimesta täysin riippuvat attribuutit jäävät alkuperäiseen relaatiotauluunsa. Tarkastellaan kirjan esimerkkiä

22 Kolmas normaalimuoto Relaatiokaava on kolmannessa normaalimuodossa, mikäli se on 2NF:n mukainen eikä sisällä transitiivisia riippuvuuksia pääavaimesta. Jos relaatio R sisältää funktionaalisen riippuvuuden Y --> Z siten, että Y ei ole taulun R superavain tai Z jonkin avaimen osa, ei relaatio ole 3NF:n mukainen. Tarkastellaan kirjan esimerkkiä Relaatio EMP_DEPT ei ole kolmatta normaalimuotoa, koska taulun ei-avainattribuutti DNUMBER määrää yksikäsitteisesti attribuuttien DNAME ja DMGRSSN arvot. Kyseiset kaksi attribuuttia ovat siten transitiivisesti riippuvia pääavaimesta kentän DNUMBER kautta. Tilanne korjataan muodostamalla uusi taulu, johon asetetaan avaimeksi transitiivisen riippuvuuden aiheuttanut attribuutti sekä ne attribuutit, joiden arvot määräytyivät tämän perusteella. Aikaisemman taulun EMP_DEPT sisältämät tuplat pystytään toteutetun dekomposition jälkeen rekonstruoimaan tekemällä luonnollinen liitos taulujen ED1 ( sisältää vain työntekijän attribuutteja + vierasavaimena osastonumeron ) ja ED2 ( sisältää vain osaston attribuutteja ) välille käyttämällä liitosattribuuttina osastonumeroa.

23 10.4 Toisen ja kolmannen normaalimuodon yleiset määritelmät
Kappaleessa 10.3 tarkasteltiin 2NF:n ja 3NF:n yhteydessä riippuvuutta pääavaimen osasta ( 2NF ) ja transitiivista riippuvuutta pääavaimesta jonkin ei-avainattribuutin kautta ( 3NF ). Seuraavassa tarkastelu laajennetaan koskemaan kaikkia relaation avainattribuutteja ( ei rajoituta yksinomaan pääavaimeen ). Toisen normaalimuodon yleinen määritelmä Relaatio on normaalimuodossa 2NF silloin, kun mikään sen avaimiin kuulumattomista attribuuteista ei ole osittain riippuvainen minkään avaimen osasta. Tarkastellaan kirjan esimerkkiä 10.11, jossa tontteja kuvaavassa relaatiotaulussa TONTIT ( LOTS ) esiintyy pääavaimen Omaisuustunniste ( PROPERTY_ID ) lisäksi toinenkin ehdokasavain, joka koostuu attribuuttien LääninNimi ( COUNTY_NAME ) ja Tonttinumero ( LOT# ) yhdistelmästä.

24 10.4.2 Kolmannen normaalimuodon yleinen määritelmä
Oletetaan lisäksi, että attribuutti Veroaste ( TAX_RATE ) on funktionaalisesti riippuva vaihtoehtoisavaimen kentästä LääninNimi. Merkitään kyseistä funktionaalista riippuvuutta tunnisteella FD3. Edelleen oletetaan, että attribuutti Pinta-ala ( AREA ) määrää yksikäsitteisesti tontin Verotusarvon ( PRICE ). Merkitään tätä ominaisuutta FD4:llä. Tällöin koko relaatio ei täytä vaatimusta 2NF, kun osittainen riippuvuus myös vaihtoehtoisavaimesta huomioidaan. Siten taulu TONTIT pitää jakaa kahdeksi erilliseksi tauluksi TONTIT1 ja TONTIT2, jotta osittaisen riippuvuuden aiheuttanut attribuuttipari { LääninNimi, Veroaste } saadaan syrjään alkuperäisestä relaatiosta. Alkuperäisen taulun TONTIT sisältämät tuplat voidaan rekonstruoida uusista tauluista TONTIT1 ja TONTIT2 käyttämällä luonnollista liitosta. Kannattaa huomioida, että FD4:stä ei ole mitään haittaa NF2:n toteutumista ajatellen, joten attribuutteja Pinta-ala ja Verotusarvo ei tarvitse siirtää pois taulusta TONTIT1. Kolmannen normaalimuodon yleinen määritelmä Relaatio on normaalimuodossa 3NF silloin, kun taulun R jokaiselle ei-triviaalille ( ei siis muotoa X --> X olevalle ) funktionaaliselle riippuvuudelle X --> A on voimassa joko X on taulun R superavain tai A on taulun R avainattribuutin osa

25 Tarkastellaan jälleen esimerkkiä 10. 11
Tarkastellaan jälleen esimerkkiä Kohdassa ( b ) oleva taulu TONTIT1 ei ( eikä myöskään kohdan ( a ) taulu TONTIT ) täytä vaatimusta 3NF, koska tontin pinta-ala määrää yksikäsitteisesti sen verotusarvon. Sen sijaan taulu TONTIT2 on 3NF:n mukainen. Ongelma ratkeaa perustamalla erillinen taulu TONTIT1B, joka sisältää transitiivisen riippuvuuden aiheuttaneen attribuutin Pinta-ala sekä sen perusteella määräytyvän verotusarvon. Nyt taulut TONTIT1A, TONTIT1B ja TONTIT2 ovat kaikki 3NF:ssä, ja niiden avulla pystytään rekonstruoimaan alkuperäisen taulun TONTIT sisältämät tuplat luonnollisin liitoksin. Kannattaa huomioida, että ei ole välttämätöntä normalisoida relaatiota ensinnä 2NF:n ja vasta sitten 3NF:n mukaiseksi. Yhtäläisesti voitaisiin normalisoida suoraan 3NF:ään, jolloin 2NF tulisi huomioitua samalla. Normalisointijärjestys 2NF --> 3NF on siten lähinnä normaalimuotojen historialliseen kehitykseen perustuva. Siten voidaan 3NF:n yleinen vaihtoehtoinen määrittely lausua seuraavasti: Relaatio R on kolmannessa normaalimuodossa, mikäli sen jokainen avaimeen kuulumaton attribuutti täyttää kummankin seuraavista vaatimuksista: Se on funktionaalisesti täysin riippuvainen jokaisesta R:n avaimesta Se on ei-transitiivisesti riippuvainen jokaisesta R:n avaimesta

26 10.5 Boyce-Coddin normaalimuoto
Boyce-Coddin normaalimuoto on normaalimuotoa 3NF tiukempi vaatimus, jonka mukaan funktionaalinen riippuvuus X --> A voi esiintyä taulussa R ainoastaan silloin, kun X on taulun R superavain. 3NF:n sisältämä toinen vaihtoehto, joka sallisi FR:n olemassaolon myös silloin, kun A on avaimen osa, ei kelpaa toteuttamaan BCNF:ää. Tarkastellaan kirjan esimerkkiä 10.12a tonttitietoihin liittyen. Lisätään esimerkin mukaiseen tilanteeseen vielä uusi funktionaalinen riippuvuus FD5, jonka mukaan tontin pinta-ala määräisi yksikäsitteisesti läänin, jossa tontti sijaitsee ( ! ). Taulu TONTIT1A on kylläkin 3NF:n mukainen, sillä LääninNimi on vaihtoehtoisavaimen osa, mutta se ei täytä enää BCNF:ää, sillä Pinta-ala ei ole kyseisen taulun superavain. Ongelman ratkaisemiseksi tehdään vielä taululle TONTIT1A dekompositio, jossa siitä irrotetaan attribuutti LääninNimi, joka sijaitsi oikealla puolella FR:ssä Pinta-ala --> LääninNimi.

27 Oikean dekomposition valinnassa pitää olla huolellinen, sillä nyrkkisääntönä tulee pitää sitä, että kaikki alkuperäisen taulun sisältämä informaatio pitää pystyä rekonstruoimaan, eikä valetuplia saa syntyä. Tarkastellaan esimerkkinä seuraavia funktionaalisia riippuvuuksia, joiden oletetaan olevan olemassa tietokannassa: FR1: { OPISKELIJA, KURSSI } --> OPETTAJA FR2: { OPETTAJA } --> KURSSI FR1:n mukaan jokaista opiskelija-kurssi -paria kohti on yksikäsitteinen opettaja. Vastaavasti FR2 sanoo, että yksi opettaja voi opettaa ainoastaan yhtä kurssia. Tarkastellaan kirjan kuvaa 10.12b, joka esittää em. funktionaaliset riippuvuudet taulussa R, missä A kuvaa opiskelijaa, B kurssia ja C opettajaa. Kyseessä oleva relaatio ei selvästikään ole BCNF:n mukainen FD2:n takia. Se on kuitenkin 3NF:n mukainen. Pulma: miten relaatio R pitäisi purkaa, jotta se saataisiin BCNF:n mukaiseksi ilman, että mitään alkuperäisen taulun tiedoista menetetään ja generoidaan virheellisiä tuplia.

28 BCNF:ään päästäisiin millä tahansa dekompositiolla, joka purkaa nykyisen tilanteen ( HUOM! Jokainen relaatio, jossa on vain kaksi attribuuttia, on samalla myös BCNF:ssä !!! [ voidaan todistaa helposti ] ). Vaihtoehtoja olisivat vaikkapa: 1. { OPISKELIJA, OPETTAJA } ja { OPISKELIJA, KURSSI } 2. { KURSSI, OPETTAJA } ja { KURSSI, OPISKELIJA } 3. { OPETTAJA, KURSSI } ja { OPETTAJA, OPISKELIJA } Dekompositiovaihtoehto 1 selvittäisi kylläkin, mitä eri kursseja opiskelijat käyvät ja keiden opettajien kursseille eri opiskelijat osallistuvat. Kyseisen vaihtoehdon valitseminen jättäisi nyt kuitenkin hämärän peittoon, kuka opettajista luennoi mitäkin kurssia ( ei pystytä yhdistämään opettajaa siihen kurssiin, jota hän luennoi ). Vaihtoehto 2 selvittäisi edellisen tapaan, mille eri kursseille opiskelijat osallistuvat. Samoin kävisi nyt selville, kuka opettajista luennoi mitäkin kurssia. Sen sijaan hämäräksi jäisi, kuka opettajista luennoisi juuri sitä kurssia, jolle opiskelija osallistuu ( usea opettaja saattaa pystyä luennoimaan samaa kurssia ).

29 Vaihtoehto 3 osuisi tällä kertaa oikeaan, sillä jos tiedetään, mitä kurssia opettaja luennoi, ja keitä kaikkia opiskelijoita hänen kurssillaan on, pystytään samalla tietämään, mille eri kursseille opiskelijat osallistuvat. Tällöin funktionaalisten riippuvuuksien ketju ei pääse katkeamaan. Tarkastellaan kirjan esimerkkiä 10.13, joka havainnollistaa alkuperäisen taulun R mahdollista tietosisältöä. Oikeellisen tiedon täydellisen säilyvyyden takaamiseksi pitää huolehtia siitä, että dekomposition tuloksena saatujen taulujen välisillä luonnollisilla liitoksilla pystytään rekonstruoimaan kaikki alkuperäisen taulun tuplat ja vain ne - mitään valetuplia ei saa tulla generoiduiksi! Seuraavan luvun algoritmia 11.1 voidaan käyttää häviöttömän liitosominaisuuden toteutumiseen tehdyssä taulujen dekompositiossa.