Structured Query Language - SQL 8.1-8.3 Tiedon määrittely Data Definition Language (DDL) 8.4-8.7, 9.1-9.2 Tiedon käyttö Data Manipulation Language (DML) Kyselyt Päivitykset Näkymät (view) + Lukemistoa

Historiaa 1970-luvulla IBM’n kokeellisessa järjestelmässä Alkuperäinen nimi SEQUEL (Structured English QUEry Language) Kaupallisia toteutuksia 1980-luvulta lähtien Useita standardeja: SQL1 (1986; suppea) SQL2 (1992; laaja) SQL3 (1999; moniosainen, erittäin laaja) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Ominaisuudet (kuva 8.1 ja taulu 8.2) Tiedon määrittely CREATE, DROP, ALTER Kyselyt: SELECT-lause Korkean tason käsitteellinen ilmaus eli ”mitä?” Käyttäjän on määriteltävä haluttu tulos DBMS hoitaa optimoinnin ja kyselyn toteutuksen Päivitysoperaatiot INSERT, DELETE, UPDATE Näkymien (VIEW) määrittely 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Käyttötavat (ks. luku 8.7 ja 9.3-9.6) Itsenäisenä kysely- ja päivityskielenä Upotettuna johonkin isäntäkieleen Ongelmana ns. impedance mismatch eli tieto-rakenteiden yhteensopimattomuus DBMS:n ja ohjelmointikielen välillä Metodi- eli rutiinikutsuina isäntäkielestä käsin (ns. CLI = Call Level Interface). Talletettuina moduuleina palvelimella (PSM = Persistent Stored Modules) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Muita ominaisuuksia Tietokanta koostuu kaavoista (schema), jotka puolestaan koostuvat tauluista (table) Taulu eroaa relaatiosta siinä, että duplikaatti-rivit ovat sallittuja Turvallisuutta ylläpidetään määrittelemällä kaavoille omistaja, joka voi antaa ja myös peruuttaa käyttöoikeuksia muille käyttäjille 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Käyttäjien määrittely Vain tietokannan valvoja (DBA) voi luoda ja poistaa käyttäjiä CREATE USER ... DROP USER ... Salasanan vaihto: ALTER USER ... 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Tiedon määrittely Kaavan määrittely: CREATE SCHEMA <tietokannan_nimi> Kantataulun määrittely: CREATE TABLE <taulun_nimi> ( <sarakemäärittely 1> <sarakemäärittely 2> ... [ <rajoitus 1> <rajoitus 2> ... ] ) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Sarakkeiden määrittely <sarakenimi> <tyyppi> [NOT NULL] [DEFAULT <oletusarvo>] [<sarakerajoitukset>] Esimerkiksi: DNUMBER INT NOT NULL CHECK (DNUMBER >0 AND DNUMBER <21); Tai määritellään tietotyyppi ehtoineen erikseen: CREATE DOMAIN D_NUM AS INTEGER CHECK (D_NUM > 0 AND D_NUM < 21); Tietotyyppejä: Merkkijonot: CHAR, VARCHAR Numeeriset: INTEGER, SMALLINT, NUMERIC, DECIMAL, REAL, FLOAT, DOUBLE Boolean Bittijonot: BIT Aikatyypit: DATE, TIME, TIMESTAMP, INTERVAL 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Sarakkeita koskevat rajoitukset Sarakemäärittelyn yhteyteen (koskee vain ko. saraketta) Erikseen sarakemäärittelyjen jälkeen (koskee useampaa saraketta) Pääavain: PRIMARY KEY (<sarakelista>) Ehdokasavain: UNIQUE (<sarakelista>) Viiteavain: FOREIGN KEY (<sarakelista>) REFERENCES <taulu>(<sarakelista>) [ON DELETE | ON UPDATE {RESTRICT | CASCADE | SET NULL | SET DEFAULT}] Rajoitus voidaan nimetä, esim. CONSTRAINT <rajoituksen nimi> FOREIGN KEY (...) ... Lisärajoituksia tietueille Esim. CREATE TABLE DEPARTMENT -lauseen loppuun: CHECK (DEPT_CREATE_DATE < MGRSTARTDATE); Eli jos osastolla olisi “syntyhetki”, niin johtaja voidaan nimittää vain ko. ajankohdan jälkeen 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Määrittelyn poistaminen Tietokantakaavan poistaminen: DROP SCHEMA <tietokannan_nimi> Cascade (kaikki poistetaan viittauksineen) Restrict (vain jos kannassa EI ole yhtään elementtiä) Kantataulun poistaminen: DROP TABLE <taulun_nimi> Restrict (vain jos tauluun EI viitata mistään) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Määrittelyn muutos Kantataulun määrittelyn muutos: ALTER TABLE <taulun_nimi> Sarakkeen lisäys: ADD Sarakkeen poisto: DROP CASCADE, RESTRICT Oletusarvon määrittely tai poisto: SET DEFAULT, DROP DEFAULT Sääntöjen lisäys tai poisto: ADD CONSTRAINT, DROP CONSTRAINT 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Tiedon käyttö = kyselyt SQL vs. Relaatioalgebra Relaatioalgebra: Määritellään käsittelyoperaatioiden järjestys yksikäsitteisesti SQL: Määritellään vain haluttu lopputulos Hallintajärjestelmä sisältää optimoijan Uudemmissa SQL-versioissa myös ’algebra-maisia’ piirteitä (mm. eksplisiittinen liitos) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Yksinkertaiset kyselyt (kuva 8.3) SELECT (”valitse”) Mitä tietoja haluat tulokseen (nimi, osoite, jne.)? FROM (”tauluista”) Mitä tauluja tarvitset tuloksen ”löytämiseksi”? WHERE (”jossa”) Minkä ehtojen täytyy olla tosia haettujen tietojen osalta? Vihje: Kuvittele FROM-osalle ristitulo. Saatu valtava tulos vertaillaan tiettyjen kenttien suhteen Esim. vertailu Employee.SSN=Works_on.ESSN 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

SELECT-lause vs. relaatioalgebra SELECT-osa vastaa projektiota (), eli määritellään tulokseen halutut sarakkeet FROM-osa edustaa kohderelaatiota, useamman relaation karteesista tuloa tai liitosta WHERE-osa edustaa valintaa (), mutta mukana voi olla myös liitosehtoja, jos FROM-osassa oli useita relaatioita 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Esimerkkikyselyjä (1/2) Etsi John B. Smithin syntymäaika ja osoite SELECT BDATE, ADDRESS FROM EMPLOYEE WHERE FNAME='John' AND MINIT='B' AND LNAME='Smith' Etsi tutkimusosaston työntekijöiden nimet ja osoitteet SELECT FNAME, LNAME, ADDRESS FROM EMPLOYEE, DEPARTMENT WHERE DNAME='Research' AND DNUMBER=DNO 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Esimerkkikyselyjä (2/2) Etsi Staffordissa toimivien projektien numerot, vastaavat osastonumerot, ja ko. osastojen johtajien sukunimi, osoite ja syntymäaika Mieti vastausta ensin itse ja sitten katso vastaus: SELECT PNUMBER, DNUM, LNAME, ADDRESS, BDATE FROM PROJECT, DEPARTMENT, EMPLOYEE WHERE DNUM=DNUMBER AND MGRSSN=SSN AND PLOCATION='Stafford' 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Erikoistapauksia WHERE-osa voi puuttua; etsi osastonimet: SELECT DNAME FROM DEPARTMENT Projektio voi puuttua; etsi osaston 5 työntekijöiden kaikki tiedot: SELECT * FROM EMPLOYEE WHERE DNO = 5 Duplikaattirivien poisto: SELECT DISTINCT ... Samannimisten attribuuttien tarkennus: <relaationimi>.<attribuuttinimi> Tätä voi käyttää kaikkialla, missä attribuuttinimi voi esiintyä (lähinnä SELECT- ja WHERE-osat) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Uudelleenimeämisestä FROM-osassa voidaan nimetä taulut uudelleen joko helppokäyttöisyyden takia tai koska samaan tauluun viitataan monta kertaa (esim. rekursio, sisäkkäiset kyselyt) Operaattori AS valinnainen Etsi kunkin työntekijän ja hänen esimiehensä etu- ja sukunimet SELECT E.FNAME, E.LNAME, S.FNAME, S.LNAME FROM EMPLOYEE AS E, EMPLOYEE AS S WHERE E.SUPERSSN=S.SSN Myös attribuuteille voidaan antaa uusi nimi Uudelleennimeäminen voidaan tehdä SELECT- tai FROM-osassa Esim. etsi osaston 5 projektinimet: SELECT PNIMI AS PROJEKTINIMI FROM PROJECT AS P(PNIMI, PNUMERO, PAIKKA, OSNRO) WHERE P.OSNRO = 5 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Joukko-operaatiot SQL:ssä Operandeina SELECT-lausekkeet, tulossarakkeiden on oltava yhteensopivia UNION (unioni) INTERSECT (leikkaus) EXCEPT (erotus) Joukko-operaatioista usein vain osa (yleensä UNION) toteutettu käytännön järjestelmissä 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Esimerkki joukko-operaatiosta Etsi niiden projektien numerot, joissa Smith on joko työntekijänä tai vastaavan osaston johtajana (SELECT PNUMBER FROM PROJECT, DEPARTMENT, EMPLOYEE WHERE DNUM=DNUMBER AND MGRSSN=SSN AND LNAME='Smith') UNION (SELECT PNUMBER FROM PROJECT, WORKS_ON, EMPLOYEE WHERE PNUMBER=PNO AND ESSN=SSN AND LNAME='Smith') 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Merkkijonovertailut Huom! Merkkijonot ovat ”case-sensitive”, avainsanat eivät Osittainen täsmäys: LIKE-operaattori _ = mikä tahansa yksittäinen merkki % = mikä tahansa merkkijono Esim. Etsi työntekijät, joiden osoitteessa on ainakin teksti: Houston, Texas SELECT FNAME, LNAME FROM EMPLOYEE WHERE ADDRESS LIKE ’%Houston, Texas%’ 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Aritmetiikka Numeerisilla arvoilla voidaan laskea, esim. SELECT FNAME, LNAME, 1.1*SALARY FROM EMPLOYEE Lyhennysmerkintä arvovälitestille: BETWEEN SELECT * WHERE SALARY BETWEEN 30000 AND 40000 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Tulosrivien lajittelu ORDER BY –määre kyselyn lopussa Järjestys nouseva (ASC) tai laskeva (DESC) Tulosta työntekijöiden ja heidän osastojensa nimet osastonimen mukaan laskevassa ja työntekijän nimen mukaan nousevassa järjestyksessä SELECT DNAME, LNAME, FNAME FROM DEPARTMENT, EMPLOYEE WHERE DNUMBER = DNO ORDER BY DNAME DESC, LNAME ASC, FNAME ASC 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Kertausta (E)ER:stä SQL-määrittelyihin (E)ER-mallin luominen Reaalimaailman kuvaus Relaatiokuvauksen tekeminen Käsitteellinen malli RDBMS:ssä SQL:n DDL-määrittelyt Näin luot relaatiojoukon oikeasti

CASE-esimerkki (1/6) (Mikko Savela) Eräs palveluja tuottava ja myyvä yhdistys tarvitsi käyttöönsä tietokantaa, jonka avulla pidettiin kirjaa yhdistyksen jäsenistä, asiakkaista sekä annetuista palveluista. Järjestelmän suunnitteli ja toteutti tietokantoihin erikoistunut tietotekniikan palveluyritys. 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

CASE-esimerkki (2/6) (Mikko Savela) Järjestelmän tietokantaan oli suunniteltu henkilö-entiteetti, joka sisälsi asiakkaiden henkilötietoja. Etunimi ja sukunimi oli jaettu kahteen attribuuttiin. Aluksi yhdistyksen toiminta oli varsin pienimuotoista ja palveluja myytiin vain jäsenille. Hieman myöhemmin palvelumyynti ulotettiin kattamaan myös yhdistyksen ulkopuolisia asiakkaita. Oletus tietokannassa: Asiakas on luonnollinen henkilö, joka on ko. yhdistyksen jäsen Alkuperäinen tiedon käyttötarkoitus muuttui Vastaako tietokanta enää reaalimaailman tilannetta? Pyrittiinkö tulevaisuuden tarpeet ottamaan huomioon alun perin? 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

CASE-esimerkki (3/6) (Mikko Savela) Myöhemmin asiantuntijayritys teki yhdistyksen käyttöön kyselyn, jonka avulla voitiin luoda helposti postitustarrat asiakkaille tehtävää postittamista varten. Kyselyssä tarkistettiin, ettei postitustarroihin oteta mukaan kahta kertaa samoja osoitteita (postitusta ei haluttu tehdä moninkertaisina esimerkiksi yhden perheen kaikille jäsenille) sekä varmistettiin, ettei mikään postitukseen tarvittavista kentistä ole tyhjä (Etunimi, Sukunimi, Osoite, Postinumero ja Postitoimipaikka). Asiantuntijayritys päätti toteuttaa tyhjien kenttien tarkistuksen kyselyssä, koska yhdistyksessä oli käytössä tapa poistaa järjestelmästä sellaiset tiedot, joiden oikeellisuudesta ei voitu olla varmoja. Esimerkiksi kun posti palautti jonkin mainoksen tai kirjeen virheellisen osoitteen vuoksi, poistettiin kyseinen väärä tieto tietokannasta. 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

CASE-esimerkki (4/6) (Mikko Savela) Myöhemmin yhdistys laajensi toimintaansa edelleen koskemaan myös asiakasyrityksiä. Nopeasti tilauksia käsittelevät henkilöt omaksuivat tavan tallentaa asiakasyrityksen nimitiedon etunimikenttään ja mahdollisen yhteyshenkilön nimen sukunimikenttään. Kaikissa asiakasyrityksissä ei kuitenkaan ollut yhteyshenkilöä, jolloin sukunimikenttä jäi tyhjäksi. Viimeistään aiheellista päivittää tietokannan rakennetta Postitustarrojen tekoon käytettiin edelleen vanhaa, hyvin toimivaksi todettua tarrakyselyä. Tiedon tallentamisen periaatteet olivat kuitenkin muuttuneet, joten kysely jätti automaattisesti pois myös ne yritykset, joilla ei ollut nimettyä yhteyshenkilöä. 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

CASE-esimerkki (5/6) (Mikko Savela) Kyselyn pyynnöstä suorittanut toimistosihteeri ei missään vaiheessa epäillyt järjestelmän toimivuutta, vaikka osa asiakkaista jäikin ilman postitusta. Edellä esitetyssä esimerkissä käy ilmi mahdollisten virheiden ilmenemisen riskejä sekä niiden havaitsemisen vaikeus. Käyttäjät käyttivät järjestelmää totutunlaisesti, mutta tiedon tallentamisen periaatteissa tapahtui kuitenkin muutos. Tietokantaan ei tehty muutoksia ja käyttäjien oletus oli, että järjestelmää voidaan käyttää edelleen halutunlaisesti. Todellisuudessa kentän tyhjänä olemisen merkitys ei enää uudessa tilanteessa ollut yksiselitteinen ja tulosjoukosta (postitustarrat) jäi puuttumaan tarroja. 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

CASE-esimerkki (6/6) (Mikko Savela) Kysymyksiä Kuka oli vastuussa tarrojen puuttumisesta? Keillä kaikilla oli mahdollisuus vaikuttaa virheen havaitsemiseen? Miksi virhe tapahtui? Miten virheen olisi voinut estää? Miten tietokanta olisi voitu suunnitella ja toteuttaa siten, ettei esitetty ilmiö olisi aiheuttanut virhetilannetta? Miten postitustarrojen tulostaja olisi voinut havaita virheen? Eräs opetus: mikäli tietokannassa on tietoja tai merkityksiä, joista voidaan päätellä ohjelmallisesti asioita, niin silloin tietokanta on suunniteltava ja toteutettava siten, ettei ohjelmointirajapintaa voi vahingossa ohittaa! DBMS 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

(E)ER-mallinnus (1/4) Täydellistä ratkaisua ei ole, vain hyviä ja huonoja Enemmän taidetta kuin tiedettä Pohdi vain kohteen luonnetta ja käyttäytymistä, älä toteutusta! Jos et tunne kohdetta, mallintaminen on miltei mahdotonta Kerää tietoa kohteesta Tietokannan voi rakentaa ilman (E)ER-mallia Mallinnus on vain työkalu kohteen ja sovellustarkoituksen pohtimiseen sekä sen muutoksen ennakointiin Ilman työkalua ratkaisun laatu lienee keskimäärin heikompi Kuinka paljon haluat maksaa laadusta? Virhe voi olla katastrofaalinenkin (vrt. Challenger) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

(E)ER-mallinnus (2/4) Vaikeita asioita mallinnustekniikassa Entiteetti vs. liittymä? Attribuuttien määrä Avaimen valinta Luonnollisuus (ei mielellään ”ID”) Ei redundanssia (pvm) tai NULL-arvoja Vrt. avainkäsite relaatiomallin yhteydessä Täydellinen liittymä Kaikki ko. entiteetin instanssit mukana liittymässä Aliluokka vs. kategoria ”Vehicle” vs. ”Registered_vehicle” 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

(E)ER-mallinnus (3/4) Heikko entiteetti Kokonaisuus, jolla ei ole riittävästi identifioivia attribuutteja, mutta jonka sisäinen rakenne tai käyttäytyminen puoltaa oman entiteetin kuvaamista “Heikkous” on siis oikeasti entiteetin ominaisuus, joka halutaan kuvata Kirjan COMPANY-kaavion DEPENDENT on oiva esimerkki heikosta entiteetistä: firman tarkoitus ei ole ylläpitää lähiomaisista kattavaa rekisteriä, vaan ainoastaan tarpeelliset tiedot suhteessa työntekijään Toki DEPENDENT voitaisiin mallintaa myös moniarvoisena yhdistelmäattribuuttina, mutta oma rakenne puoltaa heikon entiteetin esittämistä 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

(E)ER-mallinnus (4/4) Tiedon ja toiminnan mallintamisen sekoittaminen Malli kuvaa tietoa, jota kannassa on tai tulee olemaan Mallinnuksen tarkoituksen unohtaminen Tieto on peräisin todellisesta maailmasta Kohteen rajaus tapahtuu viimeistään tietomallia luotaessa Tietoa, jota tarvitaan jostakin syystä, halutaan tallentaa ja ylläpitää 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Relaatiomalli (1/2) Vain yksi mahdollinen tietomalli kolmikaava-arkkitehtuurin käsitetasolle Suosittu Säännöt, joita noudattamalla homma pysyy kasassa Arvojoukkorajoite  attribuutit ovat arvojoukossaan Avainrajoite  pääavaimissa ei duplikaatteja Olioeheys  pääavaimissa ei NULL-arvoa Viite-eheys  viiteavain viittaa olemassa olevaan pääavaimeen tai viiteavain on NULL (pääavain ei NULL) 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto

Relaatiomalli (2/2) (E)ER-malli Relaatiomalli Entiteetti  Relaatio 1:1 tai 1:N –liittymä  Vierasavain M:N –liittymä  Relaatio ja 2 vierasavainta N-asteinen liittymä  Relaatio ja N kpl vierasavaimia Attribuutti  Attribuutti Koosteinen attr.  Kokoelma yksink. attribuutteja Moniarvoinen attr.  Relaatio ja vierasavain Arvojoukko  Arvojoukko Avainattr.  Pää- tai toisioavain 2004 © Antti Tuomisto, 2001 © Jukka Teuhola muokattu 2005 (Tommi Tapanainen) Tietojenkäsittelytieteet, Turun yliopisto