Esitys aiheesta: ""— Esityksen transkriptio:

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

52 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

53 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

54 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

55 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

56 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

57 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

58 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

59 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

60 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

61 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

62 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

63 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

64 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

65 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

66 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

67 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

68 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

69 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

70 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

71 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

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

73 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

74 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

75 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

76 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

77 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

78 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

79 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

80 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

81 (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

82 (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

83 (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

84 (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

85 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

86 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