Transcript Relaatiomalli

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
2001 © Jukka Teuhola
2004 © Antti Tuomisto
Tietojenkäsittelytieteet
Turun yliopisto
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
52
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
53
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 tietorakenteiden 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
54
Muita ominaisuuksia



Tietokanta koostuu kaavoista (schema), jotka
puolestaan koostuvat tauluista (table)
Taulu eroaa relaatiosta siinä, että duplikaattirivit 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
55
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
56
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
57
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
58
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
59
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>
Cascade (kaikki poistetaan viittauksineen)
 Restrict (vain jos tauluun EI viitata mistään)

2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
60
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
61
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 ’algebramaisia’ piirteitä (mm. eksplisiittinen liitos)
2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
62
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
63
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
64
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
FROM
WHERE
FNAME, LNAME, ADDRESS
EMPLOYEE, DEPARTMENT
DNAME='Research' AND DNUMBER=DNO
2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
65
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
66
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
67
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
68
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
69
Esimerkki joukko-operaatiosta
 Etsi niiden projektien numerot, joissa Smith on joko
työntekijänä tai vastaavan osaston johtajana
(SELECT
FROM
WHERE
UNION
(SELECT
FROM
WHERE
PNUMBER
PROJECT, DEPARTMENT, EMPLOYEE
DNUM=DNUMBER AND MGRSSN=SSN AND
LNAME='Smith')
PNUMBER
PROJECT, WORKS_ON, EMPLOYEE
PNUMBER=PNO AND ESSN=SSN AND
LNAME='Smith')
2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
70
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
FROM
WHERE
FNAME, LNAME
EMPLOYEE
ADDRESS LIKE ’%Houston, Texas%’
2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
71
Aritmetiikka
 Numeerisilla arvoilla voidaan laskea, esim.
SELECT FNAME, LNAME, 1.1*SALARY
FROM
EMPLOYEE
 Lyhennysmerkintä arvovälitestille: BETWEEN
SELECT *
FROM EMPLOYEE
WHERE SALARY BETWEEN 30000 AND 40000
2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
72
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
73
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

2001 © Jukka Teuhola
2004 © Antti Tuomisto
Tietojenkäsittelytieteet
Turun yliopisto
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
75
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
76
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
77
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
78
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
79
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
80
(E)ER-mallinnus (1/4)

Täydellistä ratkaisua ei ole, vain hyviä ja huonoja



Jos et tunne kohdetta, mallintaminen on miltei mahdotonta


Enemmän taidetta kuin tiedettä
Pohdi vain kohteen luonnetta ja käyttäytymistä, älä toteutusta!
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
81
(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
82
(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
83
(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
84
Relaatiomalli (1/2)

Vain yksi mahdollinen tietomalli kolmikaavaarkkitehtuurin 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
85
Relaatiomalli (2/2)
(E)ER-malli
Entiteetti
1:1 tai 1:N –liittymä
M:N –liittymä
N-asteinen liittymä
Attribuutti
Koosteinen attr.
Moniarvoinen attr.
Arvojoukko
Avainattr.
Relaatiomalli
 Relaatio
 Vierasavain
 Relaatio ja 2 vierasavainta
 Relaatio ja N kpl vierasavaimia
 Attribuutti
 Kokoelma yksink. attribuutteja
 Relaatio ja vierasavain
 Arvojoukko
 Pää- tai toisioavain
2004 © Antti Tuomisto, 2001 © Jukka Teuhola
muokattu 2005 (Tommi Tapanainen)
Tietojenkäsittelytieteet, Turun yliopisto
86