Relaatiomalli ja -tietokanta > Edgar. F. (Ted) Codd, IBM, 1969 < A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387. > 70-luvun lopulla ensimmäiset relaatiokantaso-vellukset (IBM System-R, Ingress, Oracle, Informix, Sybase) > Coddin artikkeli nykyiset relaatiojärjestelmät Juha Iisakka, marraskuu 2013, page: 1
teoriaa > relaatio (relation) on joukko > koostuu monikoista (tuple) > yksi monikko kuuluu vain kerran relaatioon > monikkojen järjestys merkityksetön > monikko koostuu arvoista > arvot edustavat attribuutteja > attribuuteilla arvoalue (domain) > toistuvat jokaisessa monikossa Juha Iisakka, marraskuu 2013, page: 2
attribuutti joukko-opin relaatio Osasto relaation nimi relaatio nimi:markkinointi budjetti: 100 nimi:tuotanto budjetti: 9900 nimi:hallinto budjetti: 90 arvo nimi:r&d budjetti: 400 Juha Iisakka, marraskuu 2013, monikko page: 3
teoriaa.. > Relaatio on arvo-attribuutti-parien joukko > Relaatiokaava (relation schema) < millaisia attribuutteja relaation monikoille kuuluu > R relaatio > R(A 1,A 2,A 3,A 4,...,A n ) relaatiokaava > A 1 relaation monikkojen 1. attribuutin roolinimi > jokaisella attribuutilla A i on arvoalueensa dom(a i ) Juha Iisakka, marraskuu 2013, page: 4
teoriaa... > jokainen monikko t on järjestetty joukko arvoja t=<v 1,v 2,v 3,...v n >, jossa jokainen arvo v i kuuluu arvoalueeseen dom(a i ) tai sillä ei ole arvoa > esimerkki: < OSASTO relaation nimi < OSASTO(NIMI,BUDJETTI) relaation kaava < {"markkinointi",90} monikko < 90 arvo jonkin monikon toiselle attribuutille, jonka roolinimi on BUDJETTI Juha Iisakka, marraskuu 2013, page: 5
teoriaa... > arvot ovat: < tunnisteita < kuvaavia ominaisuuksia > Todellisuuden entiteettejä edustavat relaatiot ovat yksilötauluja > Entiteettien keskinäisiä yhteyksiä edustavat taas yhteystauluja Juha Iisakka, marraskuu 2013, page: 6
Relaatiotaulu (relation table) > relaatiot toteutetaan tauluna > rivi (row) = monikko > sarake (column) = attribuutti > rivit voivat toistua > mallissa arvoalue vapaa, todellisuudessa ei täydellisesti > attribuutin arvoalue tarkoittaa myös, missä muodossa arvot saadaan tallettaa. Juha Iisakka, marraskuu 2013, page: 7
1. normaalimuoto (1NF) > "Relaation sisällä ei saa esiintyä relaatioita" > Atribuutin arvoalue tulee koostua vain atomisista arvoista. > Monikon kentällä ei saa olla arvonaan arvojen joukkoa > "Normaalien" relaatioiden tulee täyttää 1NF Juha Iisakka, marraskuu 2013, page: 8
relaatio OSASTO(NIMI,BUDJETTI) tauluna Osasto nimi budjetti taulun nimi sarakenimi relaation kaava taulu markkinointi 100 hallinto 90 R&D 400 tuotanto 9900 sarake arvo rivi Juha Iisakka, marraskuu 2013, page: 9
Avainehdokas > candidate key > attribuutti tai -yhdistelmä, jolla monikko voidaan tunnistaa muista saman relaation monikoista Juha Iisakka, marraskuu 2013, page: 10
perusavain > primary key, pääavain > joku avainehdokas > valinnan jälkeen tunnistamiseen > alleviivataan roolinimi OSASTO(NIMI, BUDJETTI) > usein keksitty tunnus < sopivan lyhyt < varmasti yksiselitteinen < automaattisesti generoitavissa! Juha Iisakka, marraskuu 2013, page: 11
entiteetin eheysvaatimus > (entity constraint)!perusavaimella on oltava jokaisella rivillä tyhjästä poikkeava yksilöllinen arvo! > sääntö koskee myös muita eksplisiittisesti määriteltyjä avainehdokkaita! > tietokantajärjestelmät valvovat! Juha Iisakka, marraskuu 2013, page: 12
viiteavain > (foreign key) > attribuutti, jolla viitataan johonkin monikkoon > toisen tai oman relaation monikkoon > ei yleensä järkevää käyttää muuta kuin perusavainta viittauksen kohteena > periaatteessa muutkin avainehdokkaat käyvät > viiteavaimella voi olla tyhjä arvo Juha Iisakka, marraskuu 2013, page: 13
esimerkki relaatiotietokannan kaavasta työntekijä nimi tunnus esimies osasto projekti osasto nimi johtaja projekti tunnus nimi osasto päällikkö Juha Iisakka, marraskuu 2013, page: 14
viiteavain... > Yhteystaulussa eivät viiteavaimet saa olla tyhjiä > viittaava taulu l. lapsitaulu > viite-eheyssääntö (foreign key constraint): viiteavaimen tulee viitata johonkin olemassaolevaan riviin tai sen tulee olla tyhjä Juha Iisakka, marraskuu 2013, page: 15
viiteavain... > kolme strategiaa hoitaa viite-eheys: > estosääntö: ei saa poistaa riviä, johon viitataan. Rivin perusavainta ei saa muuttaa > tyhjäyssääntö: jos rivi, johon viitataan poistetaan, tyhjätään kaikki ko. viiteavainkentät > vyörytyssääntö: poistettaessa viitattu rivi, poistetaan kaikki ne rivit, joista siihen viitataan. Muutettaessa rivin perusavainta päivitetään muutos myös viiteavainkenttiin.! Juha Iisakka, marraskuu 2013, page: 16
Korvikeavaimet > (surrogates, surrogate keys) > Jos tietokanta sisältää tietoa todellisista entiteeteistä, on aina olemassa tunnistettavuusongelma. (Pyhäjärvi->Pyhäsalmi->Pyhäjärvi) > Suomessa ihmisillä on henkilötunnus, mutta sen käyttöä rajoitetaan. > Näille tosin voidaan generoida geneerinen perusavaintunniste, mutta sen käyttö ei ole ongelmatonta. Juha Iisakka, marraskuu 2013, page: 17
Korvikeavaimet... > Nimet tms. vaihtuvat ja niitä käytetään eri tavoin tai jollakin entiteetillä ei jostain syystä ole vielä tunnistetta. > Perusavainta käytettäessä viiteavaimena, on sen arvon muuttuminen vaarallista. > Perusavaimen arvon muuttuminen tulisi olla suhteellisen harvinaista > Korvikeavaimen käytöllä voidaan suojata tietokantaa "todellisuudelta" > Korvikeavain on välttämätön joskus myös viiteavaimen valinnaisessa käytössä Juha Iisakka, marraskuu 2013, page: 18
Korvikeavaimet... > Se on tietokannan itsensä iselleen generoima tunniste. > Aina kun tietokantaan talletetaan uusi entiteetti, saa tämä surrogaatin, < jota mikään muu entiteetti ei ole koskaan saanut < eikä tule koskaan saamaan. < surrogaattia ei koskaan vaihdeta < eikä sitä koskaan unohdeta, vaikka entiteetti poistettaisiin. Juha Iisakka, marraskuu 2013, page: 19
Korvikeavaimet... > Käyttäjän ei ole tarpeen tietää surrogaatista, eikä hänen koskaan tulisi niitä nähdä. > Tietokannan sisällä kaikki entiteettiä koskeva tieto talletetaan surrogaatin avulla; > perus- ja viiteavaimena käytetään surrogaattia. > Käyttäjän näkemä perusavain on "attribuutti muiden avainehdokasattribuuttien joukossa." > Tietenkin käyttäjän näkemän "perusavaimen" eheyttä valvotaan Juha Iisakka, marraskuu 2013, page: 20
Esimerkki... Työläinen Osasto Omainen tnro nimi katuos pnro ptmp hetu palkka ohjaaja osasto Työskentelee nimi projekti sukulaisuus työläinen työläinen tuntia Juha Iisakka, marraskuu 2013, page: 21 onro nimi johtaja sijainti Projekti nimi nro päällikkö osasto
Kyselymenetelmät > relaatiotietokanta > kaksi menetelmäparadigmaa > (relaatio)algebra > (relaatio)kalkyyli Juha Iisakka, marraskuu 2013, page: 22
Relaatiokalkyylit > perustuvat predikaattilogiikkaan >,, > tulosrelaatiota varten määritetään kaava, jonka tulee olla voimassa > kaksi lähestymistapaa: > rivikalkyyli < muuttujana monikko > sarakekalkyyli < muuttujana attribuutti Juha Iisakka, marraskuu 2013, page: 23
sarakekalkyyli > domain oriented relational calculus > Lacroix & Pirotte 1977 > qbe > { r OSASTO("Hallinto",qrs) } nimi onro johtaja sijainti "Hallinto" x x = "12345" Juha Iisakka, marraskuu 2013, page: 24
rivikalkyyli > (tuple oriented relational calculus) > E.F.Codd 1971 (relaatiomallin isä) > SQL, QUEL > "kohtisuorassa" sarakekalkyyliin > monikot itsenäisiä, kuuluvat johonkin relaatioon. > monikot rivimuuttujia > { p.johtaja p ( OSASTO(p) and p.nimi="hallinto" ) } SELECT P.JOHTAJA FROM OSASTO P WHERE P.NIMI="HALLINTO"; Juha Iisakka, marraskuu 2013, page: 25