5. Relaatiomalli, relaatioiden rajoitukset ja relaatioalgebra

Esitys aiheesta: "5. Relaatiomalli, relaatioiden rajoitukset ja relaatioalgebra"— Esityksen transkriptio:

1 5. Relaatiomalli, relaatioiden rajoitukset ja relaatioalgebra
5.1 Relaatiomallin käsitteitä Relaatio R kuvataan taulukkona ( table ) , jonka kukin yksittäinen rivi ( row ) – tupla ( tuple ) – edustaa kokoelmaa toisiinsa liittyviä arvoja. Arvoalue ( domain ) D on attribuuttiin liittyvien yksittäisten atomisten ( jakamattomien ) arvojen joukko. Jokaista arvojoukkoa kohti on määritelty nimi, tietotyyppi ja esitysmuoto. Attribuutin tunnus tarkoittaa, miten sen arvojoukko on tulkittavissa relaatiossa. Attribuutin A arvoalueeseen viitataan merkinnällä dom( A ). Sama arvojoukko voi esiintyä usealla attribuutilla, jolloin attribuutin nimi kertoo sen roolin relaatiossa. Relaation kaavaa (relation schema) merkitään tunnuksella R( A1, A2, ... An ), missä R on relaation nimi.

2 Relaation asteella ( degree ) n tarkoitetaan relaatiotaulun attribuuttien lukumäärää.
Relaatiokaavaan R( A1, A2, ... An ) liittyvä tila r, merkitään r( R ), muodostuu tauluun kuuluvien n-tuplien joukosta, eli r = { t1, t2, ..., tm }. Jokainen n-tupla t koostuu arvoista <v1, v2, ..., vn>, missä vi ( 1  i  n ) edustaa tuplan i:nnen attribuutin t[Ai] arvoa joukossa dom( Ai ) tai on puuttuva arvo ( null value ). Relaation tila on relaatiokaavan sisäistys ( intension ) ja vastaavasti relaatiokaava on relaation tilan ulkoistus ( extension ). Tarkastellaan kirjan esimerkkiä 5.1 edellä esiteltyjen käsitteiden selkeyttämiseksi. Formaalisti määriteltynä relaatio R voidaan tulkita n-asteiseksi matemaattiseksi relaatioksi määrittelyjoukoille dom( A1 ), dom( A2 ), ..., dom( An ) eli R:n määrittelevien arvoalueiden karteesisen tulon osajoukkona. r( R )  ( dom( A1 ) x dom( A2 ) x ... x dom( An ) ).

3 5.1.2 Relaatioiden piirteitä
Karteesinen tulo tarkoittaa kaikkia mahdollisia attribuuttien arvojen yhdistelmiä, jotka voidaan relaation R tuplille muodostaa. Merkitään yhteen arvoalueeseen kuuluvien arvojen lukumäärää merkinnällä D. Jos R:n kaikkien attribuuttien arvojoukot ovat äärellisiä, R:n karteesiseen tuloon kuuluu yhteensä dom(A1) * dom(A2) * ... * dom(An) erilaista tuplaa. Relaatioiden piirteitä Relaation riippumattomuus tuplien järjestyksestä: koska relaatio tarkoittaa tuplien joukkoa, ei relaation tilan kannalta ole merkitystä, missä järjestyksessä tuplat esitetään. Relaatioon liittyvä tiedosto on kuitenkin aina järjestetty fyysisesti jollain tavalla. Esimerkki: kirjan kuvien 5.1 ja 5.2 relaatiot ovat samat, vaikka niiden tietueet ovatkin eri järjestyksessä.

4 5.1.3. Relaatiomallin merkinnöistä
Myöskään ei ole merkitystä sillä, missä järjestyksessä relaation kentät on kaavassa esitelty ( kirjan esimerkki 5.3 ). Relaatiomallissa ei hyväksytä moniarvoisia ja koosteisia attribuutteja, vaan lähdetään siitä, että kaikkien attribuuttien arvot ovat atomisia ( s.o. relaatio on ns. ensimmäisessä normaalimuodossa, tähän palataan myöhemmin ). Sen sijaan puuttuvat arvot hyväksytään. Jokainen tupla voidaan tulkita relaation faktana eli esiintymänä. Kannattaa huomioida, että relaatio voi esittää faktoja sekä entiteeteistä että niiden välisistä suhteista! Relaatiomallin merkinnöistä Astetta n olevaa relaatiokaavaa R kuvaa merkintä R( A1, A2, ..., An ). Relaation r( R ) n-tuplaa t merkitään t = <v1, v2, ..., vn>, missä vi viittaa attribuutin Ai arvoon.

5 Sekä t[Ai] että t.Ai viittaavat attribuutin Ai arvoon vi.
Sekä t[Au, Aw, ..., Az] että t.(Au, Aw, ..., Az), missä Au, Aw, ..., Az ovat R:n attribuutteja, viittaavat t:n alituplan kyseisten attribuuttien arvoihin <vu, vw, ..., vz>. Kirjaimet Q, R ja S tarkoittavat relaatioiden nimiä. Kirjaimet q, r ja s tarkoittavat relaation tiloja. Kirjaimet t, u ja v tarkoittavat tuplia. Yleisesti, relaatiokaavan nimi yksinään kirjoitettuna ( esimerkiksi OPISKELIJA ) viittaa relaation nykyisiin tupliin, kun taas nimi täydennettynä attribuuttilistalla viittaa ainoastaan relaation kaavaan ( esimerkiksi OPISKELIJA( Nimi, Hetu, ... ) ). Attribuutin yhteydessä voidaan käyttää pistenotaatiota RELAATIO.Attribuutti korostamaan, minkä relaation attribuutista on kyse. On nimittäin mahdollista, että usealla relaatiolla on samanniminen attribuutti.

6 5.2. Relaatioiden rajoitukset
Esimerkki: oletetaan, että opiskelijatiedostossa esiintyy tupla t = <'Tahvo Löppönen', ’ ’, ’ ’, ’Torvitie 8’, ’ ’, 100, 1.16>, Tällöin t[Nimi] = <'Tahvo Löppönen'> t[Hetu, OpsKeskiarvo, Ikä] = ’ ’, 1.16, 100 5.2. Relaatioiden rajoitukset Relaation sisältämälle datalle voidaan asettaa erilaisia rajoituksia, jotka voivat kohdistua määrittelyjoukkoihin, avaimille, entiteetin eheyteen ja viite-eheyteen. Muita mahdollisia rajoituksia, joita kutsutaan tietoriippuvuuksiksi (kuten funktionaaliset ja moniarvoiset riippuvuudet), käsitellään tietokannan normalisoinnin yhteydessä.

7 5.2.1 Arvoalueen rajoitukset
Attribuuttien arvojen oltava atomisia (ei hyväksytä moniarvoisia eikä koosteisia attribuutteja). Tyypillisiä rajauksia attribuutin arvoalueille ovat eri tyyppiset kokonaisluvut (tavalliset, pitkät, lyhyet) ja niiden rajoitetut alueet, reaaliluvut, merkit ja kiinteän ja vaihtelevan mittaiset merkkijonot, sekä päivämäärä, aika, aikaleima ja rahayksikkö. Tarjolla olevia tietotyyppejä tarkastellaan tarkemmin SQL2:n standardin yhteydessä. Avainten rajoitukset ja puuttuvat arvot Koska relaatio muodostuu joukosta tuplia, ei kahden identtisen tuplan esiintyminen relaatiossa ole laillista.

8 Mikäli relaation R tiettyjen attribuuttien yhdistelmälle SK, joka koostuu 1..n kappaleesta attribuutteja, ei voi esiintyä duplikaattiarvoja, SK on tällöin relaation R superavain ( superkey ). Toisin sanoen, relaation tilassa r on aina voimassa ti[SK]  tj[SK], kun i  j. Superavain SK voi sisältää redundantteja ( turhia ) attribuutteja, eli siitä voidaan mahdollisesti muodostaa supistettu attribuuttien yhdistelmä SK' poistamalla vähintään yksi SK:n attribuuteista siten, että myös SK' täyttää superavaimen yksikäsitteisyyskriteerin. Superavainta, joka on minimaalinen, kutsutaan lyhyesti relaation avaimeksi ( key ). Poistamalla yksikin avaimeen kuuluvista attribuuteista yksikäsitteisyysvaatimus relaatiotaulussa rikkoutuu. Jokainen attribuuttien joukko, joka sisältää avaimen, on samalla myös superavain. Tarkastellaan uudelleen kirjan esimerkkiä 5.1. Joukko Z={ Hetu, Nimi, Ikä } on relaation superavain, muttei kuitenkaan avain, sillä poistamalla Z:sta attribuutit Nimi ja Ikä saadaan joukko Z'={ Hetu }, joka kelpaa relaation avaimeksi. Täten Z ei ole minimaalinen superavain. Sitä vastoin Hetu on myös superavain.

9 Avaimen avulla jokainen relaation tuplista pystytään tunnistamaan yksikäsitteisesti.
Avain on luonteeltaan aikainvariantti ( time-invariant ). Tämä tarkoittaa sitä, että relaation tilasta riippumatta avaimessa ei esiinny duplikaatteja. Täten esimerkiksi nimi ei välttämättä kelpaisi esimerkin 5.1. avaimeksi, vaikka esimerkissä ei esiinnykään kahta saman nimistä henkilöä. Myöhemmin tällaisia voi kuitenkin ilmestyä relaatioon ( tai sellaisia on saattanut olla jossain aikaisemmassa relaation tilassa ). Mikäli relaatiolla on useita avaimia, kaikista näistä käytetään nimitystä ehdokasavain. Jokin ehdokasavaimista valitaan relaation pääavaimeksi. Pääavaimeksi pyritään valitsemaan mahdollisimman yksinkertainen ehdokasavain: s. o. koostuu mahdollisimman vähistä attribuuteista ja on useasta yhtä monesta attribuutista koostuvasta ehdokasavaimesta mahdollisimman lyhyt. Pääavain merkitään relaatiokaavaan alleviivattuna. Attribuutteihin liittyy myös rajoitus siitä, hyväksytäänkö sille puuttuvat arvot ( = null value ). Ellei näitä sallita, asetetaan attribuutille rajoitukseksi NOT NULL.

10 5.2.3. Relaatiotietokannat ja niiden tietokantakaavat
Relaatiotietokanta koostuu yleensä useista relaatioista, jotka edustavat joko entiteettiä tai niiden välisiä suhteita. Relaatiotietokannan kaava S muodostuu tietokantaan kuuluvien relaatioiden kaavoista eli S={ R1, R2, ..., Rm } sekä eheysrajoituksista ( =integrity constraint=IC ). S:n mukaisen relaatiotietokannan tila ( = relational database state ) on relaatioiden tilojen joukko { r1, r2, ..., rm } siten, että jokainen ri on Ri:n sellainen tila, että se täyttää tietokannan eheysvaatimukset. Tarkastellaan kirjan esimerkkiä 5.5, joka esittää yrityksen tietokannan kaavaa. Tarkastellaan esimerkkiä 5.6 yrityksen tietokannan tietynhetkisestä tilasta. Tähän esimerkkiin viitataan jatkossa erittäin usein. Kirjan kolmannessa painoksessa samainen esimerkki on numeroltaan 7.6.

11 5.2.4 Entiteetin eheys, viite-eheys ja vierasavaimet
Saman relaatiotietokannan eri tauluissa samaan taustalla olevan reaalimaailman käsitteeseen voidaan viitata useilla eri nimillä ( esimerkiksi sekä DNUMBER että DNO tarkoittavat sisällöllisesti osaston numeroa ). Vastaavasti samannimisen attribuutin esiintyminen kahdessa ( tai useammassa ) taulussa ei takaa, että ne edustaisivat tulkinnallisesti samaa reaalimaailman objektia. Esimerkiksi sekä osaston että henkilön nimeä voisi kuvata attribuutti NAME. Saman relaation sisällä voi olla useita attribuutteja, jotka viittaavat samaan reaalimaailman kohteeseen, mutta tällöin niiden roolit ovat erilaiset ( esimerkiksi henkilö ja hänen esimiehensä ). Eheysrajoitusten ( =arvoalue- ja avaimeen liittyvät rajoitukset ) oletetaan olevan voimassa kaikissa tietokannan tiloissa. Entiteetin eheys, viite-eheys ja vierasavaimet Entiteetin eheysrajoitus merkitsee, ettei pääavaimen arvo saa olla puuttuva; muutoin ei sen avulla pystyttäisi tunnistamaan tietueita yksikäsitteisesti, jos puuttuvaa arvoa esiintyisi ainakin kahdella tietueella.

12 Viite-eheysrajoituksen (=referential integrity constraint) tarkoituksena on ylläpitää tietokannan kahden taulun välistä konsistenssia. Mikäli relaatiossa esiintyy attribuutti, joka viittaa jossakin toisessa taulussa olevaan attribuuttiin, pitää ensimmäisen taulun attribuutin arvon olla edustettuna jossakin toisen taulun tietueessa. Tarkastellaan kirjan esimerkkiä 5.6: työntekijän osastonumerona voi esiintyä ainoastaan sellainen numero, jota vastaava osasto on olemassa relaatiotaulussa, joka kuvaa osastojen tietoja. Määritellään seuraavaksi viite-eheyteen kiinteästi liittyvä vierasavaimen käsite relaatioiden R1 ja R2 välille: R1:n relaatiokaavassa esiintyvä attribuuttien joukko FK, joka viittaa relaatioon R2, on R1:n vierasavain ( =viiteavain, referenssiavain) , jos seuraavat kriteerit toteutuvat: 1. FK:hon kuuluvilla attribuuteilla on samat arvoalueet relaation R pääavaimen attribuuttien PK kanssa, eli FK:n attribuutit viittaavat relaatioon R2.

13 2. FK:n arvo tuplassa t1i, joka kuuluu relaation R1, joko esiintyy jonkin tuplan t2j pääavaimen arvona relaatiossa R2, tai muutoin FK:n arvo on puuttuva ( =null ). Toisin sanoen, jokaiselle i:lle, missä i  [1, tietueiden määrä R1:ssä] on voimassa joko t1i[FK]=t2j[PK], missä j  [1, tietueiden määrä R2:ssa], tai t1i[FK]= null. Tietokannassa, joka koostuu monesta relaatiosta, esiintyy yleensä useita viittauksia taulusta toiseen. Viittauksia muodostettaessa pitää olla selkeä kuva siitä, missä roolissa kumpikin viiteyhteyteen osallistuva attribuutti (attribuuttien yhdistelmä) esiintyy. Tarkastellaan esimerkin 5.6 viiteyhteyttä henkilön osastonumeron ja osastorelaation pääavaimen välillä: henkilörelaation osastonumeroa vastaava tietue pitää löytyä osastorelaatiosta. Selvästikin henkilötaulun kenttä DNO on nyt osastotaulun DNUMBER kenttään viiteyhteydessä oleva vierasavain. Vierasavaimen arvo voi olla myös puuttuva: olisi periaatteessa mahdollista, ettei työntekijä olisi kirjoilla millään osastolla. Vierasavain voi viitata myös samaan tauluun. Tällainen tilanne voi syntyä, kun on olemassa yhteys kahden saman entiteettityypin edustajan välillä ( esimerkiksi työntekijä-esimies –suhde ). Esimerkissä 5.6. henkilön John Smith esimieskentän arvo on , mikä viittaa henkilöön nimeltä Franklin Wong: viimeksi mainittu on edellä mainitun esimies.

14 5.2.5 Muita rajoitustyyppejä
Vierasavaimet voidaan merkitä näkyviin tietokannan kaavaan merkitse-mällä vierasavainkentästä lähtevä nuoli sen relaatiotaulun siihen attri-buuttiin, johon vierasavain on viiteyhteydessä ( kts. kirjan esimerkki 5.7 ). Useimmat tietokannan hallintajärjestelmät tukevat avaimeen liittyviä ja entiteetin eheysrajoituksia, monet lisäksi tukevat viite-eheysrajoituksia. Nämä ovat osa datan määrittelyä. Muita rajoitustyyppejä Edellisten rajoitusten lisäksi voidaan asettaa tietokannalle vielä ns. semanttisia eheysrajoituksia, kuten estää mahdollisuus, että työntekijä tekisi kaikkiin projekteihin työtunteja yhteensä enemmän kuin 56 viikkoa kohti, työntekijän palkan korottaminen ohi hänen esimiehensä palkan jne. Semanttisia eheysrajoituksia varten käytetään ns. rajoitusten määrittely-kieltä ( constraint specification language ), joka sisältää ns. liipaisimia ( triggers ) ja määräyksiä ( assertions ). Edellä esitetyt rajoitukset olivat ns. tilaan liittyviä rajoituksia, koska ne määräävät laillisen tilan, jota tietokanta voi noudattaa. Näistä käytetään myös nimitystä staattiset rajoitukset.

15 5.3. Päivitysoperaatiot ja toiminta yritettäessä rikkoa rajoituksia
Yhtenä rajoituksen lajina voidaan pitää myös ns. funktionaalista riippuvuutta X ---> Y, missä sekä X että Y ovat attribuutteja. Merkintä tarkoittaa, että attribuutin X arvo määrää yksikäsitteisesti attribuutin Y saaman arvon kyseisessä relaatiossa. Funktionaalisia riippuvuuksia tarkastellaan enemmälti luvussa 10, eli tietokannan normalisoinnin yhteydessä. Lisäksi on olemassa ns. siirtymärajoituksia ( transition constraints ), jotka kuvaavat, miten tietokannan tila voi muuttua joidenkin attribuuttien kohdalla. Esimerkiksi voitaisiin vaatia, että kuukausipalkkaa ei milloinkaan voida pienentää. Näitä kutsutaan myös ns. dynaamisiksi rajoituksiksi. 5.3. Päivitysoperaatiot ja toiminta yritettäessä rikkoa rajoituksia Päivitysoperaatioihin lasketaan kuuluviksi tuplan lisäys, tuhoaminen ja sisällön muuttaminen. Tarkastellaan seuraavaksi kutakin operaatiota erikseen tarkastelemalla arvoalueen ja avaimen rajoituksia sekä entiteetin ja viite-eheysrajoituksia.

16 Lisäysoperaatio Lisäysoperaatiossa ( Insert ) lisätään uusi tupla relaatioon. Lisääminen voi rikkoa mitä tahansa tarkastelemistamme neljästä rajoituksesta, sillä Jonkin attribuutin arvo voi olla laiton, eli väärää tietotyyppiä tai sallitun arvoalueen ulkopuolella. Avainrajoitusta rikotaan, jos lisättävän tuplan avainkentän arvo esiintyy jo jossakin toisessa tuplassa relaation nykytilassa r( R ). Entiteetin eheysrajoitusta rikotaan, mikäli lisättävällä tuplalla avainattribuutin arvo on puuttuva. Viite-eheyttä rikotaan, mikäli lisättävän tuplan vierasavaimen ei-puuttuvalle arvolle ei löydy vastinetta sen relaation pääavaimesta, mihin vierasavain viittaa.

17 Tarkastellaan kirjan sivulla 141 olevia esimerkkejä, joissa henkilötauluun yritetään sijoittaa neljää erilaista uutta tuplaa. Toipumistapoja sääntöjen rikkomisesta: lisäyksen peruuttaminen, syötetietojen korjaaminen sekä lisäyksen vyöryttäminen ( =cascade ). Peruuttaminen: tietueen lisäysyritys torjutaan suoralta kädeltä. Tällöin olisi hyödyllistä ilmoittaa käyttäjälle, minkä tähden operaatio epäonnistui. Peruuttamista ei tosin sovelleta usein lisäysten yhteydessä. Syötetietojen korjaaminen: annetaan käyttäjälle mahdollisuus muuntaa alun perin annettu tupla kelvolliseksi tekemällä tarpeelliset muutokset ( esimerkissä tarjottaisiin mahdollisuutta antaa laillinen arvo SSN- tai DNO-kentälle ). Vyörytys: syötetietojen korjaaminen voi aiheuttaa jatkotoimenpiteitä toisaalla. Menettelyä jatketaan niin pitkään kuin se on tarpeen. Esimerkki: Syötetään alun perin laiton osastonumero henkilölle. Tällöin voidaan antaa käyttäjälle tilaisuus joko syöttää osastonumero uudelleen tai käydä perustamassa kyseinen osastotietue. Jos valitaan jälkimmäinen, ja osastolle annetaan johtajan koodiksi tunnus, joka ei ole minkään henkilön henkilötunnus, voidaan päivityksiä vyöryttää takaisin henkilötauluun.

18 Tuhoamisoperaatio Tuplan poistamista varten asetetaan kriteeri, jonka mukaisesti poisto kohdistetaan tarkoitettuihin tupliin. Tuplan poistaminen voi rikkoa viite-eheyttä, mikäli jokin toinen tietokannan tuplista viittaa siihen. Tarkastellaan kirjassa sivulla 142 olevia esimerkkejä, jotka perustuvat kaikki kuvan 5.6 mukaiseen yrityksen tietokannan tilaan ( operaatiot eivät siis ole perättäisiä ): 1.  Relaatiosta WORKS_ON yritetään poistaa tupla, jossa ESSN = ' ' ja PNO = '10'. ---> Tämä onnistuu, sillä mihinkään poistettavan tietueen kenttään ei kohdistu viitettä toisaalta. Poiston tulkintana on, että työntekijä nimeltä 'Alicia Zelaya' lopettaa työskentelynsä projektissa 10.

19 2.  Yritetään poistaa relaatiosta EMPLOYEE tupla, jossa ESSN = ' ' > Poisto rikkoisi viite-eheyttä, sillä kyseinen henkilö ( Alicia Zelaya ) on vielä töissä kahdessa projektissa, ja poistettavan henkilön projekteissa toimimista kuvaavat tietueet jäisivät siten irrallisiksi tietokantaan. Relaatiossa WORKS_ON toimii kenttä ESSN vierasavaimena relaatiolle EMPLOYEE, joten viite-eheyden säilyvyys pitää tarkastaa. 3.  Yritetään poistaa relaatiosta EMPLOYEE tupla, jossa ESSN = ' '. ---> Poisto aiheuttaisi melkoisesti harmia, sillä kyseiseen henkilöön ( Franklin Wong ) viitataan sekä relaatioissa WORKS_ON, DEPARTMENT, EMPLOYEE että DEPENDENT. Franklin Wong työskentelee peräti neljässä projektissa, johtaa osastoa 5, toimii kolmen työntekijän esimiehenä, ja lisäksi hänellä on kolme perheenjäsentä!

20 Toipumistapoja rikottaessa rajoituksia tuplan poistamisen yhteydessä:
Estäminen: estetään tietueen poistaminen. Tuhoamisen vyörytys: Poistetaan kaikki tuplat, joissa viitataan poistettavaan tuplaan. Tämä toimisi hyvin esimerkissä 2, jossa Alicia Zelaya lähtee pois yrityksestä, koska hän ei toimi yrityksessä esimiesasemassa. Vierasavainten päivittäminen: jos viittauksen kohteena oleva tupla poistetaan, muutetaan siihen viittaavat vierasavaimet kelvollisiksi arvoiksi tai asetetaan ne puuttuviksi ( =null ). Puuttuvaksi kenttää ei kuitenkaan saa asettaa, mikäli vierasavain toimii samalla relaationsa pääavaimen osana. Eri toipumistapoja voidaan myös kombinoida. Esimerkiksi työntekijän lopettaessa työt yrityksessä voitaisiin hänen osallistumistietonsa eri projekteihin poistaa saman tien. Jos henkilö toimii lisäksi osaston johtajana, voidaan kenttään Osaston_johtaja asettaa arvo 'null' tai sijoittaa poistuneen henkilön hetun tilalle jonkin toisen henkilön hetu. Samaa menettelyä voitaisiin käyttää esimieskentälle EMPLOYEE-taulussa.  

21 Sitä vastoin olisi varsin outo ja epätarkoituksenmukainen ratkaisu lopettaa koko osaston toiminta sen johtajan lopettaessa työt ja/tai antaa lopputili kaikille johtajan alaisille! Muutosoperaatio Muutosoperaatio muuttaa tuplan yhden tai useamman attribuutin arvoa. Mikäli muutos kohdistuu muuhun kuin pääavain- tai vierasavainattribuuttiin, ei operaatio yleensä aiheuta hankaluuksia: välttämättä ei tehdä muuta kuin tarkastetaan arvoalueen ja tyypin oikeellisuus. Pääavaimen arvon muuttaminen ei ole (yleensä) järkevää, sillä se voitaisiin tulkita aikaisemman tietueen poistamiseksi ja samalla uuden lisäämiseksi. Vierasavainattribuutin päivittäminen edellyttää, että kentän uusi arvo on viite-eheyden säilyvyyden kannalta hyväksyttävä. Tarkastellaan lopuksi kirjan sivulla 143 olevia esimerkkejä muutosoperaatioista.