Relaatiomalli
Download
Report
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