Transcript Dias nummer 1 - This is not the page you are looking for

Tietokannat II
Aineopintokurssi, 5 op, syksy 2006
Turun yliopisto / ohjelmistotekniikka / Salo
Lasse Bergroth
_____________________________________
Kurssi perustuu kirjaan Elmasri - Navathe: Fundamentals of Database Systems,
Addison-Wesley 2004, 4. painos
Kurssin aikataulu
•
Luennot yhteensä 24 tuntia
o tiistaisin alkaen 2006-11-07, kello 09.00-10.45, sali D234
o maanantaisin alkaen 2006-11-13, kello 12.15-14.00, sali D234
o lisäksi maanantaina 2006-11-06, kello 14.00-15.45,
keskiviikkona 2006-12-13, kello 17.30-19.00 ja
torstaina 2006-12-14, kello 15.45-17.30, sali tällöinkin D234
o kurssin viimeinen luento torstaina 2006-12-14
•
Demonstraatiot maanantaisin kello 14.00-15.45, yhteensä 8 tuntia
o ensimmäinen kerta 2006-11-20, ja samoin 2 seuraavalla viikolla,
sali D234
o lisäksi torstaina 2006-12-14 kello 17.30-19.00 salissa D234
Kurssin suoritustavat

Kurssi koostuu luennoista, demonstraatioista, harjoitustyöstä ja tentistä.

Demonstraatiotehtäviä yhteensä 4∙5 = 20 tehtävää.
o 8 tehtävää ( 40% ): tenttioikeus
o 16 tehtävää ( 80% ): yhden numeron hyvitys tenttiarvosanaan
•
Hyvitys tulevat aina hyväksytyn tenttiarvosanan ( 1 - 4 ) päälle.
•
Tehtävät ovat saatavilla noin viikkoa ennen demonstraatiotilaisuutta.
•
Kysymykset löytyvät verkosta kurssin kotisivulta osoitteesta
http://staff.cs.utu.fi/opinnot/kurssit/Salo/syksy2006/bergroth/tietokannat2.htm.
•
Kaikkiin tentteihin pitää ilmoittautua viimeistään 5 päivää etukäteen 3. kerroksen
ilmoitustaululla olevalle listalle!
•
Tenttiin vastaamisaikaa käytettävissä 4 tuntia.
o 5 kysymystä, jotka kaikki arvostellaan 6 pisteen arvoisesti
o maksimipistemäärä 30
o hyväksyttyyn arvosanaan riittää 13 pistettä
•
Kurssin ensimmäinen tenttimistilaisuus on tarjolla 2006-12-19 kello 14.00 – 18.00
salissa D114.
Kurssin tavoitteet
•
Selvittää, miten korkean tason tietokannan kuvaus voidaan muuntaa
algoritmisesti relaatiomalliin sopivaksi.
•
Esitellä tietokantojen yleisimmin käytetty SQL-kieli, jota voidaan käyttää
sekä tietokannan määrittelyyn, kyselyiden muodostamiseen, päivityksiä
varten sekä rajoitusten ja näkymien esittämiseksi.
•
Esitellä, miten tietokannan normalisointi eri asteisiin normaalimuotoihin
tapahtuu. Vähintään kolmannen normaalimuodon täyttämistä pidetään
tärkeänä tietokannan toteutuksen laatukriteerinä.
•
Antaa lyhyt katsaus tietokannan talletusrakenteisiin.
•
Tarjota perustiedot jatko-opintoja varten ( mm. syventävät kurssit,
kurssia sivuavat aihealueet ja alan tutkimuskohteet )
1. Tietokannat ja tietokantojen käyttäjät
1.1. Tietokannan määritelmä ja ominaisuudet
•
Tietokannalla tarkoitetaan kokoelmaa tietoja, joilla on ilmeinen yhteys toisiinsa ( esimerkiksi
kirjaston asiakkaita ja sieltä lainattavaa materiaalia koskevat tiedot, yliopiston opiskelijarekisteri,
yrityksen asiakas- ja tuotantotiedot, pankin asiakas- ja tilitiedot, sairaalan potilastiedot, autojen
rekisteritiedot jne. ).
•
Tietokannan osien välillä pitää olla looginen yhteys, eli sinne säilöttyjen tietojen pitää olla
riittävän voimakkaasti sidoksissa toisiinsa. Esimerkiksi kirjan yksittäisen sivun sisältämistä
sanoista koottu luettelo ei täytä tietokannan kriteeriä.
•
Tietokanta edustaa siten jotain selkeästi määriteltyä ja rajattua kohdetta reaalimaailmassa.
Muutokset tällaisessa 'minimaailmassa' heijastuvat muutoksina kyseistä kohdetta kuvaavaan
tietokantaan.
•
Menettelytavat, joilla tietokannan sisältämät tiedot on kerätty, ovat hyvin määritellyt eivätkä
sattumanvaraisesti valitut ( esimerkiksi asiakastietojen / kirjastossa tarjolla olevan
nidevalikoiman päivittä-minen ).
•
Tietokannan sisältämät tiedot ovat ainakin jonkin intressiryhmän kannalta hyödyllisiä tai
mielenkiintoisia. Muutoin ei olisi mielekästä edes perustaa kyseistä tietokantaa saatikka ylläpitää
sitä.
•
Tietokannat voivat nykyisin yhä enenevässä määrin sisältää — paitsi perinteistä tekstimuotoista,
numeerista ja loogista tietoa — niin myös esimerkiksi videokuvaleikkeitä ja karttatietoa.
•
Tietokannat voivat vaihdella kooltaan erittäin suuresti. Yksinkertaisimmillaan se muodostuu
yhdestä ainoasta tiedostosta, joka sisältää pienehkön määrän tietueita. Esimerkiksi kelpaisi
vaikkapa yksityishenkilön puhelinmuistioon tallennetut nimi-, osoite ja puhelin-numerotiedot.
Toisessa ääripäässä ovat puolestaan valtion ja suuryritysten ylläpitämät massiiviset tietovarastot
( esimerkiksi Yhdysvaltain kansalaisten verotiedot viimeisten viiden vuoden ajalta, kts. oppikirjan
sivu 5 ).
•
Tietokannan ei välttämättä tarvitse olla sähköisessä muodossa, vaan pieniä tietokantoja voidaan
ylläpitää myös manuaalisesti ( vrt. puhelinmuistiot, kalenterit yms. ).
•
Ohjelmistoa, joka mahdollistaa tietokannan perustamisen ja ylläpitämisen, kutsutaan tietokannan
hallintajärjestelmäksi ( TKHJ ). Se sisältää työvälineet, joiden avulla käyttäjän muodostamat kyselyt
ja päivitykset saadaan toteutettua itse tietokantaan.
•
Tietokannan sisältämä data sekä sen kuvailemiseksi tehdyt määrittelyt ( ns. metadata ) pidetään
toisistaan fyysisesti erillään.
•
Tietokoneympäristöön toteutettu tietokanta ei
mutta usein tietokannan määritteleminen,
työpanoksen, jos TKHJ halutaan ohjelmoida
erityisesti muutettaessa tietokannan rakennetta
•
Tietokannan sovellusohjelmien, TKHJ:n, sekä levylle tallennetut data- ja määrittelytiedot muodostavat
yhdessä ns. tietokantajärjestelmän.
vaadi välttämättä tuekseen kaupallista ohjelmistoa,
toteuttaminen ja käsittely vaativat suuremman
kokonaan itse. Työmäärän lisääntyminen korostuu
uusien tiedon ylläpitotarpeiden mukaiseksi.
1.2. Esimerkki tietokannasta
•
Yliopiston opiskelijoiden opintotiedot ( kts. oppikirjan sivu 7 )
•
Viisi
o
o
o
o
o
eri kokonaisuutta, jotka ovat omina tiedostoinaan
Opiskelijan tiedot
Kurssin yleistiedot
Kurssin yksittäisen luentokerran tiedot
Tiedot opintosuorituksista
Kurssin esitietovaatimukset
•
Jokainen tiedosto muodostuu tietueista, jotka sisältävät tietokenttiä.
•
Jokainen tietokenttä edustaa jotain tiettyä yksikäsitteistä tietotyyppiä ( merkkijono, kokonaisluku,
reaaliluku, looginen tieto jne. ).
•
Lueteltua tyyppiä, jolla on verrattain suppea arvojoukko, voidaan esittää myös koodaamalla
ominaisuudet esimerkiksi kokonaislukujen tai lyhenteiden avulla ( esimerkiksi pääaineet:
1=matematiikka, 2=fysiikka, 3=tietojenkäsittelytiede jne. ).
•
Jokaisella tietokannan sisältämällä tiedostolla on looginen yhteys ainakin yhteen muuhun tiedostoon
tietokannan sisällä ( esim. kurssi - kurssin esitiedot, opiskelija - opintosuoritusote, kurssi - kurssin
luennointikerrat jne. ).
•
Yhteydet eri tiedostojen välillä mahdollistavat monimutkaistenkin kyselyjen ja operaatioiden
suorittamisen. Esimerkiksi listataan kaikkien niiden opiskelijoiden tiedot, jotka suorittivat vuonna
1999 pidetyn tietokantojen kurssin.
1.3. Miksi perustaa tietokanta?
1.3.1. Tietokantajärjestelmän kyky kuvailla itseään
•
•
Vaihtoehtona voitaisiin ajatella yksittäisten tiedostojen ylläpitoa yhden yhtenäisen tietokannan
asemesta.
Vaikka tiedostorakenne on hyvin yksinkertainen, käytännön pulmat tulevat usein kuitenkin nopeasti
esiin
o samoja tietoja saatetaan tarvita yksikössä usealla taholla ( esimerkiksi opintosuoritusten ja
lukukausimaksujen hallinta: molemmissa tarvitaan opiskelijan perustietoja )
----> samoja tietoja joudutaan ylläpitämään useassa paikassa, mikä johtaa moninkertaiseen
samojen tietojen ylläpitoon: hukataan sekä työtunteja että tietokoneiden
muistitilaresursseja
•
Tietokantalähestymistapa estää tiedon tarpeettoman moninkertaisen ylläpidon, kunhan tietokanta
määritellään huolellisesti ennen sen perustamista.
•
Määrittelyn yhteydessä kuvataan tietokantaan kuuluvien tiedostojen sisältämät kentät, niiden
tyypit sekä rajoitukset kenttiin tallennettavalle datalle. Määrittelyistä käytetään nimitystä
metadata, ja se tallennetaan ns. systeemiluetteloon ( system catalog ).
•
Metadata sisältää kaiken tarpeellisen tiedon tietokannan rakenteellisista ominaisuuksista.
•
Tietokannan
selkeänä
etuna
yksittäisten
tiedostojen
käsittelemiselle
on
fyysisen
tallennusrakenteen näkymättömyys käyttäjälle. Riittää tietää, minkä nimiseen tiedostoon ja sen
kenttään viitataan. Yksittäistä tiedostoa käsiteltäessä pitää sen rakenne tietää tarkoin, ja
muutokset tiedoston tietuerakenteessa voivat edellyttää suuria muutoksia sitä käsitteleviin
ohjelmiin.
•
Kaupallisilla sovelluskehittimillä voidaan rakentaa useita toisistaan täysin riippumattomia
tietokantasovelluksia. Edellytyksenä on ainoastaan, että sekä tietokanta että sen määrittelyt ovat
ohjelman luettavissa.
1.3.2. Ohjelmien ja datan eristäminen toisistaan; tietoabstraktio
•
Tietokantajärjestelmässä tietokannan rakenteen muuttuminen ei yleensä
muutostoimenpiteisiin, sillä data ja määrittelyt sijaitsevat toisistaan erillään
----> tiedon riippumattomuus ohjelmista
johda
suuriin
•
Esimerkki: uuden kirjattavan ominaisuuden ( vaikkapa syntymäajan ) lisääminen opiskelijaa
kuvaavaan tietueeseen ----> vain opiskelijataulua kuvaava määritys pitää uusia ( ongelmia voi
kuitenkin esiintyä, jos ei esimerkiksi sallita kyseiselle kentälle puuttuvaa arvoa, sillä vanhoista
tietueista syntymäaikatieto puuttuu määrittelyä muutettaessa ).
•
Oliokeskeisissä sekä ns. olio-relaatiotietokannoissa voidaan määritellä tietokannan sisältämälle
datalle myös operaatioita ( funktioita ). Funktiosta pitää tietää käyttöliittymä ( nimi + parametrit ),
mutta niiden toteutus kätketään käyttäjältä ----> ohjelmien operaatioriippumattomuus.
•
Esimerkkinä operaatiosta voitaisiin
arvosanojen keskiarvon laskeminen.
mainita
vaikkapa
opiskelijan
opintosuoritusten
•
Ohjelmien riippumattomuutta datasta ja operaatioista kutsutaan tietoabstraktioksi.
•
Tietomalli on tietoabstraktion tyyppi, joka mahdollistaa tietokannan käsitteellisen kuvaamisen
ilman, että on tiedettävä tiedon fyysisestä tallennusrakenteesta tai funktioiden
toteutustavasta.
•
Korkean tason tietomalli kuvaa tietokannan sisältämien kokonaisuuksien ( esimerkiksi
opiskelijan tiedot, kurssitiedot jne. ) ominaisuuksia ja niiden välisiä riippuvuuksia siten, että
käyttäjä pystyy ne ymmärtämään helpommin kuin tietokannan fyysisen tallennusrakenteen.
1.3.3. Erilaiset näkymät tietokannan sisältämään dataan
•
Suurissa tietokantasovelluksissa ei ole yleensä mielekästä, että kaikki käyttäjät saavat käyttöönsä
kaiken mahdollisen kantaan tallennetun tiedon, vaan ainoastaan käyttäjälle itselleen tarpeellisen.
•
Näkymää voidaan rajata poistamalla
( kts. kirjan esimerkki 1.4. ).
•
Tarpeen mukaan voidaan lisäksi yhdistellä useaan eri kokonaisuuteen
( esimerkiksi ne kirjaston asiakkaat, joilla on sakkoja maksamatta ).
yksittäisestä
kokonaisuudesta
tarpeettomia
kuuluvia
kenttiä
tietoja
1.3.4. Tiedon jakaminen ja monen käyttäjän tapahtumien käsittely
•
TKHJ:n pitää pystyä huolehtimaan päivitysten oikeellisuudesta, kun useampi kuin yksi henkilö
kerrallaan pyrkii päivittämään samaa tiedostoa ( esimerkki: kulkunevojen paikanvarausjärjestelmät ).
•
On varmistuttava, etteivät jo hetkeä aikaisemmin tehdyt päivitykset jää huomioimatta esimerkiksi
paikkoja varattaessa.
o Päivitysten oikeellisuuden takaamista tarkastellaan lisää Tietokantojen jatkokurssilla.
1.4. Tietokannan varsinaiset toimijat
•
Pienen tietokannan sekä suunnittelija, toteuttaja että päivittäjä voivat olla yksi ja sama henkilö.
•
Tilanne muuttuu ratkaisevasti, kun tietokanta on suuri, ja sillä on paljon erilaisia käyttäjiä ja
käyttötarkoituksia.
•
Tietokantoja käsittelevät työntekijät voidaan karkeasti jakaa kahteen ryhmään: ns. varsinaisiin
toimijoihin ja taustavoimiin.
•
Varsinaisiin toimijoihin lasketaan tietokannan valvojat, suunnittelijat ja loppukäyttäjät.
•
Varsinaiset toimijat ovat kiinnostuneita itse tietokannan ominaisuuksista ja/tai sisällöstä.
1.4.1. Tietokannan valvoja
•
Tarvitaan organisaatioissa, joissa tietokannalla on useita samanaikaisia käyttäjiä.
•
Vastaa ensisijaisesti tietokannan sisältämän tiedon hallinnasta, toissijaisesti
hallintajärjestelmän sekä sovellusohjelmien toimivuudesta ja tehokkuudesta.
•
Huolehtii lisäksi käyttöoikeuksien jakamisesta henkilöstölle sekä järjestelmän tietoturvasta.
•
Huolehtii lisäksi tarvittavien ohjelmistojen ja laitteistojen hankinnasta.
•
Suurissa organisaatioissa voi tietokannan valvojalla olla tukenaan avustavaa henkilökuntaa.
tietokannan
1.4.2. Tietokannan suunnittelija
•
Vastaa tietokannan rakenteellisesta määrittelystä.
•
Toimii tiiviissä yhteistyössä kaikkien tietokannan tulevien käyttäjien kanssa ennen tietokannan
toteuttamista, jotta tietokanta vastaisi mahdollisimman tarkoin käyttäjien tarpeita ja
toivomuksia.
•
Räätälöi eri käyttäjäryhmille erilaiset näkymät tietokantaan.
o Valitsee näkymiin tarkalleen niitä tietoja, joita käyttäjät työtehtävissään tarvitsevat.
1.4.3. Loppukäyttäjät
•
Loppukäyttäjät voidaan jaotella neljään eri ryhmään kuuluviksi tietotarpeen mukaan:
•
Satunnaiset käyttäjät
o tarvitsevat tietokannasta tietoa silloin tällöin
o haettavat tiedot saattavat vaihdella
----> tarvetta ainakin osittaiselle kyselykielen osaamiselle
o yleensä yrityksen keski- tai ylemmän johdon edustajia
•
Peruskäyttäjät ( naiivit eli parametriset käyttäjät )
o tarve ymmärtää tietokannan rakennetta hyvin vähäinen
o valmiiksi määritellyt sovellusohjelmat
----> kyselykielen opetteleminen ei tarpeen
o esimerkiksi toimisto- ja paikanvaraussovellusten käyttäjät, pankkivirkailijat jne.
•
Kehittyneet loppukäyttäjät
o tiedonsaannin tarpeet usein monimutkaisia ja vaihtelevia
o kyselykielen ja myös tietokannan rakenteen ymmärtäminen oleellisen tärkeää
o insinöörit, tiedemiehet, analyytikot jne.
•
Yksinäiskäyttäjät
o ylläpitävät jotain rajattua osaa tietokannasta
o pystyvät kehittämään itse kyseiseen sovellusalueeseen tarpeellisia ohjelmia
1.4.4. Tietojärjestelmäanalyytikot ja sovellusohjelmoijat
•
Tietojärjestelmäanalyytikot kartoittavat valmiiden sovellusohjelmien tarpeen loppukäyttäjille ja
suunnittelevat tarvittavat ohjelmat.
•
Sovellusohjelmoijien tehtävänä on toteuttaa tietojärjestelmä-analyytikon suunnittelemat
sovellusohjelmat
1.5. Tietokantojen taustavoimat
•
Toisin kuin varsinaiset toimijat, taustavoimat eivät suoranaisesti ole kiinnostuneita itse
tietokannasta.
•
Tietokannan hallintajärjestelmän systeeminsuunnittelijat suunnittelevat ja toteuttavat TKHJ:n
moduulit. Moduuleja ovat mm. systeemiluettelo, kyselykieli, kilpailevien tapahtumien hallinta,
toipuminen virhetilanteista, turvallisuus, käyttöliittymät sekä tietoihin käsiksi pääseminen.
•
Työvälineiden kehittäjät pyrkivät saamaan aikaan välineitä, joilla tietokannan suunnittelua ja
käyttöä voidaan helpottaa.
•
Operaattorit huolehtivat yrityksen ATK-laitteiston yleisestä toimivuudesta.
1.6. Tietokannan hallintajärjestelmästä saatavia hyötyjä
•
Redundanssin ( tiedon toistamisen ) kontrolli
o
Tiedon toistamista tapahtuu perinteisessä tiedostojärjestelmässä, kun usealla taholla
joudutaan syöttämään samoja tietoja ( vrt. yliopiston opiskelijoiden opintomaksut ja
opintosuoritukset: kummassakin paikassa tarvitaan opiskelijan perustietoja ).
o
Seurauksena ylimääräistä tiedon syöttö- ja päivitystyötä sekä levytilan tarpeetonta
tuhlausta.
o
Virhe tallennuksessa ( esimerkiksi syntymäajan kohdalla ) johtaa siihen, että opiskelijan
tiedot näkyvät erilaisina eri toimipisteissä
----> tiedon vastaamattomuus eli inkonsistenssi
o
Käytettäessä tietokantalähestymistapaa eri käyttäjäryhmät integroidaan tietokannan
suunnitteluvaiheessa
----> samat tiedot tallennetaan vain yhteen kertaan
o
Hyvin perustelluista syistä voidaan tietoa kuitenkin toistaa useaan tiedostoon. Näin voidaan
tehdä esimerkiksi kyselyjen nopeuttamiseksi.
o
Esimerkki: opintosuorituksia kuvaavaan tiedostoon voidaan mennä lisäämään opiskelijan
nimi ja kurssin tunnus, sillä niiden näkyminen opintosuoritusotteessa on varsin tarpeellista.
o
Tällöin on kuitenkin määriteltävä metadataan säännöt, jotka vaativat vastaavuutta
opiskelijan nimen ja opiskelijanumeron sekä vastaavasti kurssin nimen ja sen
luennointikerran välille, jotta tietokanta pysyisi konsistenttina. Tällaista menettelyä
kutsutaan kontrolloiduksi redundanssiksi.
•
Tiedon käyttöoikeuksien jakaminen
o
Tietokannan valvoja pystyy määrittelemään erilaisia käyttäjäprofiileja, joiden mukaan
määräytyy, mihin tietoihin kukin käyttäjä saa saantioikeudet
----> käyttäjätunnukset ja salasanat.
o
Tämä edellyttää tietystikin rajattua
perustamaan uusia käyttäjätunnuksia.
pääsyä
tiettyihin
TKHJ:n
moduuleihin,
kuten
o
Lisäksi voidaan rajata tietokantaan pääsy ainoastaan valmiiden loppukäyttäjäsovellusten
kautta, tavoitteena loppukäyttäjien tekemien virheiden välttäminen
----> loppukäyttäjän ei tarvitse välttämättä saada tietokannan relaatiotauluja näkyviin.
•
Olioiden ja tietorakenteiden tallentaminen pysyvästi
o
•
Oliokeskeisissä tietokannoissa voidaan ohjelmointikielten objekteja tallentaa suoraan
tietokantaan rikkomatta niiden rakennetta toisin kuin tiedostoon tallennettaessa ( ns.
pysyvät objektit ).
Päättelyä tukevat ( deduktiiviset ) tietojärjestelmät
o
Loogiseen päättelyyn perustuvat tietokannat, joissa tietyn ominaisuuden olemassaolo
perustuu hyvin määriteltyihin sääntöihin.
o
Logiikkatietokannoista lisää mm. logiikkaohjelmoinnin kurssilla.
o
Päättelysääntöjen muuttaminen yleensä helpompaa kuin sovellusohjelmien uusiminen uusia
sääntöjä vastaaviksi.
•
•
•
Erilaiset käyttöliittymät eri käyttäjäryhmille
o
Lomake- ja valikkotyyppiset näytöt sekä opastavat graafiset käyttöliittymät peruskäyttäjille
o
Edellisten lisäksi kyselykielet edistyneemmille käyttäjille
Tietokannan tietojen välisten suhteiden esittäminen
o
Pystytään helpohkosti määrittelemään tietokannan eri kokonaisuuksien väliset yhteydet
toisiinsa ( esim. kurssin perustietojen ja sen luentokertojen välillä, opiskelijan perustietojen
ja opintosuoritusraportin välillä jne. ).
o
Helpottaa huomattavasti monimutkaisten hakujen ja päivitysten suorittamista.
Tietokannan eheyssääntöjen kontrollointi
o
Tyypin ja arvoalueen
tietokantaan estetään.
o
Avaintietokenttien yksikäsitteisyys ( esim. samaa opiskelijanumeroa ei saa esiintyä
kahdella eri rivillä opiskelijoiden perustietoja kuvaavassa taulussa )
o
Riippuvuudet tietokannan taulujen välillä: estetään viittausten katkeaminen

tietokentille:
laittomien
arvojen
tallentaminen
Esimerkin yliopistotietokannan tapauksessa voitaisiin vaatia, että luentoja voi
järjestään ainoastaan sellaisesta kurssista, jonka perustiedot on jo tallennettu
---->

määrääminen
ei perusteta
tuntematon
sellaisia
luentotietueita,
joissa
esiintyvä
kurssi
on
Vastaavasti sellaisen kurssin tietojen poistaminen, josta on luentokertatietueita
tai opintosuorituksia olemassa, olisi laitonta ilman kaikkien niiden tietojen
tuhoamista tai muuttamista, jotka viittaavat kyseiseen kurssiin
o
•
•
Tietokanta ei ole kuitenkaan mikään 'ihmerakennelma' kaiken virheellisen tiedon
eliminoimiseksi, sillä:

Tietokannan suunnittelu voi olla puutteellinen, jolloin on mahdollista, ettei
edellä mainittuja tarpeellisia eheys-sääntöjä välttämättä asetettukaan.

Voidaan syöttää laillinen mutta virheellinen arvo johonkin tietokenttään, jonka
arvoalue on rajoitettu.
Turvakopioinnin ja virheistä toipumisen tuki
o
Tietokannan hallintajärjestelmä mahdollistaa tallennettujen tietojen palauttamisen, mikäli
jostain syystä ( esimerkiksi sähkökatkon takia ) ohjelman suoritus yllättäen keskeytyy.
o
Helpottaa tietokannan turvakopiointia erilaisten katastrofaalisten tilanteiden ( levyrikko,
fataali käyttövirhe, ilkivalta yms. ) kannalta.
o
Mahdollisuus standardien valvontaan
o
Keskitetysti hallitulle tietokannalle voidaan määritellä käytännöt, jonka mukaisesti mm.
taulut nimetään, raportit ja näkymät muotoillaan, mitä terminologiaa käytetään jne.
Tämä ei onnistuisi, jos käyttäjät voisivat määritellä omat tiedostonsa ja ohjelmansa itse.
Sovelluskehityksen nopeutuminen
o
Kun tietokanta on kertaalleen määritelty ja perustettu, on uusien sovelluksien
rakentaminen verrattain helppoa, koska fyysistä talletus-rakennetta ei tarvitse tietää
( sovelluksia rakennettaessa käytettävät käsitteet lähellä itse sovellusta ).
•
•
Rakenteellinen joustavuus
o
Uusien tiedon ylläpitotarpeiden aiheuttamat muutokset ( esimerkiksi yksittäisten tietokenttien
lisääminen tauluihin tai uusien taulujen perustaminen ) helpommin toteutettavissa kuin
tiedosto-järjestelmässä.
o
Yksittäisen kentän lisäys ei kuitenkaan ole välttämättä yksinkertaista, jos kenttään halutaan
liittyvän sääntöjä ( esimerkiksi ei sallittaisi puuttuvaa tietoa ).
Ajan tasalla olevan tiedon saatavuus
o
•
Tehdyt päivitykset näkyvät heti kaikkialla, koska samaa tietoa ei ( kontrolloimattomasti )
säilötä useaan paikkaan.
Mittakaavaedut
o
Voidaan hankkia keskitetysti tehokas kone, jossa tietokanta fyysisesti sijaitsee.
o
Myöskään ei tarvita moninkertaista ylläpitotyötä.
1.7. Lyhyesti tietokantasovellusten historiasta
•
Ensimmäisiä tietokantasovellusten käyttäjiä olivat lähinnä suuret organisaatiot, kuten yliopistot,
sairaalat ja pankit.
•
Kaikki yksittäistä henkilöä koskevat tiedot pyrittiin tallentamaan fyysisesti lähelle toisiaan ( ns.
hierarkkinen tietokantamalli )





•
henkilötunnisteen perusteella tapahtuva haku toimi hyvin nopeasti
( esimerkiksi tietyn opiskelijan kaikki opintosuoritukset )
hakukriteerin muuttuessa suorituskyky kuitenkin hidastui merkittävästi ( esimerkiksi
haettaessa tiettynä vuonna aloittaneiden opiskelijoiden opintosuorituksia )
käsitteellisesti eri kokonaisuuksiin kuuluvia tietueita tallennettu
toistensa perään ( henkilötiedot, opintosuoritukset jne. )
myöskään mitään erityistä kyselykieltä ei ollut käytettävissä, vaan kaikki kyselyt oli
toteutettava ohjelmointikieltä käyttämällä!
tietokannan rakenteen muuttaminen erittäin työlästä
Verkkomallin myötä tietojen fyysisestä sidonnaisuudesta päästiin eroon, mutta edelleen
käyttäjäystävällinen kyselykieli puuttui.

Verkkomallissa yhteen kuuluvat tietueet linkitetään toisiinsa osoittimien avulla.
•
Relaatiotietokannat alkoivat yleistyä 1980-luvulla




•
Oliokeskeisissä tietokannoissa sallitaan myös ns. abstraktien tietotyyppien ja operaatioiden liittämistä
osaksi tietokantaa.



•
etuna yhteensopivuus olio-ohjelmointikielten objektien kanssa
relaatiomallia laajempi tietotyyppivalikoima
standardoinnin puute ja järjestelmän monimutkaisuus kuitenkin käytön laajemman yleistymisen
hidastajina.
WWW-teknologian myötä voidaan fyysisesti eri paikoissa sijaitsevia dokumentteja liittää toisiinsa
hyperlinkkien avulla


•
alkuperäisenä kannustimena oli kyselyjen yksinkertaistaminen
samalla päästiin eroon kyselyiden sidonnaisuudesta tiedon fyysiseen tallennusrakenteeseen
mahdollisti käsitteellisesti samantyyppisen tiedon pitämisen yhdessä
( mm. opiskelijoiden perustiedot, kurssien perustiedot jne. )
edelleen yleisin tietokantamalli nykypäivänä
Sähköisessä kaupankäynnissä verkkosivujen sisältö kootaan usein dynaamisesti eri
tietokannanhallintajärjestelmistä.
XML-kieli työvälineenä tiedonsiirrossa eri tyyppisten tietokantojen ja verkkosivujen välillä
Uusimmilla sovellusalueilla puhdas relaatiomalli saattaa osoittautua liian rajoittuneeksi mm. sen
riittämättömien tietorakenteiden ja tietotyyppien sekä ilmaisuvoimaltaan liian heikon kyselykielen
takia. Tällaisia sovellusalueita ovat mm.






tieteelliset sovellukset, joissa tietomäärät ovat suuria
röntgen- ja magneettikuvien tallennus
videokuvan ja –leikkeiden tallennus
tiedonlouhinta ( esimerkiksi hahmontunnistus suuresta tietopankista )
sää- ja karttatietokannat ( satelliittikuvien varastointi )
aikasarja- ja muut tilastolliset ja taloustieteelliset mittaussovellukset
1.8. Milloin TKHJ:tä ei kannata käyttää?
•
Saattaa olla perusteltua olla käyttämättä tietokannanhallinta-järjestelmää, mikäli
o
TKHJ:n hankinta-, koulutus- sekä TKHJ:tä varten tarvittavan laitteiston tuomien
lisäkustannusten ollessa kohtuuttoman suuret rakennettavan sovelluksen kokoon nähden.
o
Tiedon hallintamekanismien yleisyys ----> tehottomuus
o
TKHJ:n tuottaman tietoturvan, kilpailevien tapahtumien kontrolloinnin, toipumisen
varmistamisen ja eheyssääntöjen tarkastusten aiheuttama ylläpidon monimutkaisuus
o
Tietokannan suunnitteluun
riittämättömyys.
o
Tietokanta ja sen sovellukset ovat yksinkertaisia, ja tietokannan
luonteeltaan stabiilia ( ei juuri muutoksia kannan määrittelyihin ).
sisältämä
o
Vaaditaan tiukkaa pitäytymistä
hidastuttavat elementit ).
karsia
o
Haluttaessa perustaa vain yhden käyttäjän järjestelmä.
ja
kunnolliseen
toteutukseen
reaaliaikaisuudessa
(
panostettavien
haluttaessa
voimavarojen
tieto
pois
on
kaikki
2. Tietokannan käsitteitä ja arkkitehtuuri
•
Aikaisemmin tietokannanhallintajärjestelmät olivat suuria, tiiviisti integroituja järjestelmiä.
•
Nykyisille TKHJ:lle on tyypillistä ns. asiakas-palvelin -arkkitehtuuri.
----> sovellusohjelmat toimivat käyttäjän omalla koneella, itse tietokanta palvelimella toisaalla.
2.1. Tietomallit, kaavat ja esiintymät
•
Tietomalli on kokoelma käsitteitä, joiden avulla pystytään kuvaamaan tietokannan rakennetta
( tietotyypit, rajoitukset ja tietojen väliset suhteet ).
o Tarjoaa välineet tiedon abstrahointiin.
o Käyttäjän itsensä määrittelemiä operaatioita tietokannan datalle kuten keskiarvon
laskenta jonkin tietokentän arvoille esiintyy etenkin oliokeskeisessä tietomallissa,
nykyisin myös ns. objekti-relaatiomallissa, joka on relaatio- ja oliotietomallin
välimuoto.
o Sisältää usein myös perusoperaatiot tiedon hakua ja päivittämistä varten.
2.1.1. Tietomallien eri kategoriat
• Korkean tason eli käsitteellisissä tietomalleissa tietokannan rakennetta kuvataan käsittein, jotka
ovat käyttäjille luontevia ymmärrettäviksi ( entiteetti, attribuutti, liittymä ).
• Matalan tason eli fyysisissä tietomalleissa kuvaillaan, miten data on tallennettuna tietokoneelle.
Ne on tarkoitettu lähinnä tietokannan laitteistoa lähellä oleviin ominaisuuksiin erikoistuneille
asiantuntijoille, ei niinkään tavallisille loppukäyttäjille ( tietueiden talletusmuoto, järjestys,
saantipolut ).
• Näiden kahden tason 'kompromissina' voidaan nähdä ns. toteutusmalli, joka on vielä
loppukäyttäjänkin hahmotettavissa, muttei samalla kuitenkaan kohtuuttoman kaukana matalan
tason tiedon organisointimallista ( piilottaa osan rakenteiden yksityis-kohdista, mutta voidaan silti
käyttää suoraan TKHJ:ssä; useimmat kaupalliset TKHJ:t tukevat ).
• Käsitteellisissä tietomalleissa entiteetti edustaa jotain reaalimaailman kohdetta tai käsitettä
( esimerkiksi opiskelijaa ). Attribuutti tarkoittaa jotain entiteettiin kuuluvaa ominaisuutta
( esimerkiksi opiskelijan nimi ). Liittymä puolestaan kuvaa kahden tai useamman entiteetin välistä
yhteyttä ( esimerkiksi kurssin numero on kurssin perustiedot ja sen luennointikerrat toisiinsa
liittävä attribuutti ).
•
Relaatiotietomallin ja yleistymässä olevan oliokeskeisen tietokantamallin lisäksi toteutusmalleihin
luetaan aikaisemmat verkko- ja hierarkkinen malli, jotka tällä kurssilla sivuutetaan oliokeskeisen
mallin lisäksi.
2.1.2. Kaavat, esiintymät ja tietokannan tila
•
Kaikissa tietomalleissa itse tietokanta ja sen kuvaus pidetään erillään toisistaan.
•
Tietokannan kuvausta kutsutaan tietokannan kaavaksi ( database schema ).
•
Tietokannan kaava määritellään tietokannan suunnitteluvaiheessa, joten kaavaan odoteta
tehtävän muutoksia kovin usein.
•
Kaavan yksittäistä objektia ( kuten yliopistoa kuvaavassa esimerkissä opiskelijaa, kurssia jne. )
kutsutaan kaavan rakenneosaksi ( schema construct ).
•
Kaavadiagrammi selvittää vain osan tietokannan kaavan sisällöstä, kuten taulujen nimet ja
tietokentät sekä yksinkertaisia rajoituksia (esimerkiksi avainattribuutit). Monimutkaisia
rajoituksia ei kaavadiagrammilla pystytä esittämään.
•
Tietokannan datasisältöä tietyllä hetkellä kutsutaan tietokannan tilaksi.
•
Tietokanta on määrittelyn jälkeen tyhjässä tilassa ( ei vielä sisällä dataa ).
•
Ensimmäisen syöttövaiheen päätyttyä tietokanta on alkutilassaan.
•
Tehtäessä päivityksiä tietokantaan sen tila muuttuu.
•
Jokaisella tietokannan kaavan rakenneosalla on tietty nykyinen esiintymien joukko ( tietyssä
taulussa yhtenä ajankohtana esiintyvien tietueiden sisältö ).
•
TKHJ:n tehtävänä on huolehtia, että jokainen tietokannan tila on laillinen sille asetetut säännöt
huomioon ottaen. Täten on tietokannan käyttökelpoisuuden ja virheettömyyden kannalta hyvin
tärkeää, että sen määrittely tehdään huolellisesti. Tietokannan määrittelyvaiheessa ratkeaa
melko lailla kannan laadukkuus.
•
Tietokannan kaava voidaan tulkita tietokannan sisäisenä tarkennuksena, tietokannan tila
puolestaan kaavan laajennukseksi.
2.2. Tietokannan hallintajärjestelmän arkkitehtuuri
2.2.1. Kolmitasoarkkitehtuuri
•
Sisäinen taso ( kaava ), joka kuvaa tietokannan fyysistä tallennusrakennetta ja saantipolkuja.
Sisäisellä tasolla käytetään matalan tason tietomallia.
•
Käsitetaso, jossa kuvaillaan koko tietokannan rakenne käyttäjille fyysistä tallennusrakennetta
lukuun ottamatta, eli entiteetit, tietotyypit, säännöt, taulujen väliset suhteet ja käyttäjän
määrittelemät operaatiot. Tason kuvaamisessa käytetään joko korkean tai toteutustason tietomallia.
•
Ulkoinen eli näkymätaso kuvaa sitä, millaisena kukin käyttäjäryhmä näkee tietokannan. Se sulkee
ulkopuolelleen kaikki heille tarpeettomat osat, ja sen kuvaamiseksi käytetään korkean tason
tietomallia.
•
Eri tasojen välillä käytetään kuvauksia, jotta esimerkiksi tehdyt tietokantakyselyt ja niihin saadut
tulokset voidaan välittää tasolta toiselle kullekin tasolle ominaiseen esitysmuotoon.
•
Useimmat TKHJ:t eivät  lähinnä tehokkuussyistä  tue kahden ylimmän tason erottamista
toisistaan, sillä kuvauksien suorittaminen tasojen välillä hidastuttaa tietokantaan kohdistuvien
operaatioiden toteuttamista.
•
Varsinainen data sijaitsee aina fyysisellä tasolla.
2.2.2. Tietoriippumattomuus
•
Kolmitasoarkkitehtuuri tukee tietoriippumattomuutta. Tämä tarkoittaa sitä, että tietokannan
kaavan muutos alemmalla tasolla ei aiheuta muutoksia ylemmälle tasolle. Ainoastaan tasojen
välinen kuvaus muuttuu.
•
Looginen tietoriippumattomuus tarkoittaa mahdollisuutta tehdä lisäyksiä käsitekaavaan ilman
tarvetta muuttaa samalla ulkoista kaavaa tai sovellusohjelmia ( kts. esimerkkiä kirjan kuvista 1.2,
1.4 ja 1.5 ). Mikäli tietokantaa puolestaan supistetaan eli redusoidaan, muuttumattomiin
rakenteisiin viittaavissa ulkoisissa näkymissä ei tapahdu muutoksia.
•
Fyysinen tietoriippumattomuus takaa, että fyysisten datatiedostojen uudelleenorganisointi ei
aiheuta muutoksia ylemmillä tasoilla. Tämä mahdollistaa sen, että dataan voidaan lisätä esim.
uusia saantipolkuja ilman, että kyselyitä tai sovellusohjelmia jouduttaisiin uusimaan. Muutos
fyysisellä tasolla vaikuttaa vain operaatioiden suoritusaikaan.
2.3. Tietokannan kielet ja käyttöliittymät
•
Tietokannoissa voidaan käyttää erilaisia kieliä ja käyttöliittymiä eri tarkoituksiin.
2.3.1. TKHJ:n kielet
•
Tiedonmäärittelykieli DDL ( Data Definition Language ) on tarkoitettu tietokannan kaavan
määrittelyä varten.
o TKHJ:hin sisältyy DDL-kääntäjä, joka muuntaa tehdyn määrityksen systeemiluettelon
käyttämään muotoon.
2.3.1. TKHJ:n kielet
•
Sisäisellä tasolla käytetään tietovaraston määrittelykieltä eli SDL:ää ( Storage Definition
Language ).
o
•
Fyysisen ja käsitetason välinen kuvaus tehdään jommallakummalla kielistä DDL ja SDL.
Täydellisessä kolmitasoarkkitehtuurissa tarvittaisiin vielä näkymienmäärittelykieli VDL ( View
Definition Language )
o
Normaalisti käytetään kuitenkin DDL:ää sekä tiedon- että näkymienmäärittelykielenä.
•
Tiedon syöttöä ja tietokannan ylläpitoa varten tarvitaan edelleen datan käsittelykieli DML (
Data Manipulation Language ).
•
Nykyisissä tietokannan hallintajärjestelmissä kieliä ei sinänsä pidetä erillisinä SDL:ää lukuun
ottamatta, vaan samaa kieltä voidaan käyttää sekä tietokannan että näkymien määrittelyyn ja
datan käsittelyyn. Aikaisemmin myös SDL-ominaisuus sisältyi tietokannoille yleiseen SQLkieleen, mutta sittemmin SQL:ää käytetään vain kahden ylimmän tason määrittelyyn.
•
Datan käsittelykieli voi olla luonteeltaan korkean tai matalan tason DML.
o
Korkean tason eli ei-proseduraalinen DML on luonteeltaan deklaratiivinen, eli se kuvaa,
mitä tietoa kulloinkin tietokannasta käsitellään ( "joukko kerrallaan” ). Se on
käyttökelpoinen sellaisenaan, mutta sitä voidaan käyttää myös upotettuna yleiseen
ohjelmointikieleen. Tällöin tarvitaan DML-esikääntäjä avuksi, jotta DML-lauseet
käännettäisiin erillään muusta ohjelmasta.
o
Matalan tason eli proseduraalinen DML voi toimia ainoastaan upotettuna yleiseen
ohjelmointi-kieleen. Toisin kuin korkean tason DML, se kuvaa, miten tieto haetaan
tietokannasta. Haku tapahtuu aina tietue kerrallaan, eli avuksi tarvitaan
silmukkarakenteita.
•
Käytettäessä apuna yleistä ohjelmointikieltä datan käsittelyä varten siitä käytetään nimitystä
isäntäkieli ja DML:stä puolestaan nimitystä data-alikieli. Käytettäessä korkean tason DML:ää
yksinään sitä kutsutaan usein kyselykieleksi, vaikkakin sitä voidaan käyttää myös
päivitysoperaatioihin.
2.3.2. TKHJ:n käyttöliittymät
•
Peruskäyttäjät eivät turvaudu tietokannan erityiskieliin, vaan heitä varten perustetaan erilaisia
käyttöliittymiä käyttöä helpottamaan.
•
Erilaisia käyttöliittymätyyppejä:
o
Valikkoperustaiset

o
Lomakepohjaiset


o
kyselyjen muodostamiseen
tiedon syöttöön
Graafiset

o
lähinnä tietokannan selailua varten
voidaan käyttää hyödyksi hiirtä
Luonnolliseen kieleen perustuvat


komennot muistuttavat luonnollista kieltä
viitataan tietokannassa esiintyviin kenttiin
o
Peruskäyttäjille suunnatut
 toimintojen 'avauduttava' nopeasti
 funktionäppäimet, lyhyet komennot yms.
o
Tietokannan valvojalle suunnatut
 valmiudet luoda uusia käyttäjäprofiileja, tietokannan näkyvyyden rajoittamiseen ja
tiedon fyysiseen uudelleenorganisointiin
2.4 Tietokantajärjestelmäympäristö
2.4.1 TKHJ:n komponenttimoduulit
•
Tallennetun datan järjestelijä ( stored data manager )
o kontrolloi, onko viittauksen kohteena oleva tieto varsinaista dataa vai metadataa
o käyttää avukseen käyttöjärjestelmän toimintoja järjestellessään tiedon siirtämistä
levyltä keskusmuistiin
o huolehtii puskureiden hallinnasta keskusmuistissa
•
Tiedonmäärittelykielen eli DDL-kääntäjä
o prosessoi tietokannan kaavamäärittelyjä ja tallentaa kuvaukset
( metadatan ) systeemiluetteloon
•
Ajonaikainen tietokantaprosessori
o käsittelee tietokantaan kohdistetut operaatiot
o levyoperaatiot kulkevat tallennetun datan järjestelijän kautta
•
Kyselyiden kääntäjä
o
jäsentää, analysoi ja kääntää käyttäjän tuottaman kyselyn sekä generoi siitä koodin
tietokantaprosessorille
•
Esikääntäjä erottelee datan käsittelykielen yleisen ohjelmointikielen keskeltä
•
DML-kääntäjä kääntää DML-osuuden, minkä jälkeen ohjelman osat linkitetään valmiiksi
sovellusohjelmaksi
2.4.2. Tietokantajärjestelmän palveluja
•
Tiedon lataaminen tietokantaan
o
•
Turvakopiointi
o
o
•
lukeminen tekstitiedostosta tai konversio joltakin muulta tiedostotyypiltä nykyisen TKHJ:n
ymmärtämään muotoon
tarkoittaa yleensä koko tietokannan tallentamista nauhalle
voidaan tehdä joko täydellisenä tai inkrementaalisesti – s. o. pelkästään edellisen kopioinnin
jälkeen muuttuneiden tietojen osalta
Tiedostojen uudelleenorganisointi
o tehokkuuden lisäämiseksi
•
Suorituskyvyn seuranta
o
•
tilastotietoa tietokannan valvojan käyttöön
Muita palveluja ovat mm. mahdollisuus tiedostojen lajitteluun, tiedon tiivistämiseen,
käytettävyys verkon kautta jne.
2.4.3 Työkaluja, sovelluskehitysympäristöt ja etäyhteydet
•
Tietokoneavusteinen ohjelmistosuunnittelu, ns. CASE-välineet ( CASE = Computer Aided Software
Engineering )
o hyödyksi tietokannan suunnitteluprosessissa
•
Tietohakemisto
o pitää sisällään TKHJ:n systeemiluettelon sisältämät tiedot, mutta on käyttötarkoitukseltaan
laajempi sisältää tietoja mm. tietokannan suunnittelua koskevista päätöksistä,
käyttöstandardeista, sovellusohjelmien kuvauksen ja tietoa käyttäjistä palvelee etupäässä
käyttäjiä pikemmin kuin TKHJ:n ohjelmistoa
•
Sovelluskehitysympäristöt
o helpottavat valmiiden sovellusohjelmien, graafisten käyttöliittymien ja kyselyiden
muodostamista ( mm. PowerBuilder, JBuilder )
•
Yhteysohjelmistot
o tarvitaan, kun tietokanta on toteutettu asiakas-palvelin -arkkitehtuurilla ( tietokanta
sijaitsee fyysisesti palvelinkoneella ) tai tietokanta on hajautettu ( jaettu usean koneen
kesken )
o usein erillismoduuleina TKHJ:ssä
o yhdistetystä tietokanta- ja tietoliikennesysteemistä käytetään lyhennettä DB/DC
( Database / Data communications )
2.5. Tietokannanhallintajärjestelmien keskitetty / asiakas-palvelin -arkkitehtuuri
2.5.1. Keskitetty TKHJ:N arkkitehtuuri
•
Varhaisimmissa tietokannanhallintajärjestelmissä käytetty arkkitehtuuri
•
Tietokanta sijoitettuna suurtietokoneelle, johon käyttäjät olivat yhteydessä ’tyhmien’ päätteiden
välityksellä
•
Mikrotietokoneiden yleistyessäkin useat tietokantasovellukset pyörivät edelleen keskuskoneissa,
koska mikrotietokoneiden laskentavoima oli edelleen riittämätön tietokantasovelluksille
•
Koneiden tehon kasvaessa alkoi asiakas-palvelin –arkkitehtuuri vähitellen yleistyä
tietokantasovelluksissa
•
Tarkastellaan kirjan kuvaa 2.4.
2.5.2. Yleistä asiakas – palvelin -arkkitehtuureista
•
Useita mikrotietokoneita, työasemia, tiedostopalvelimia, kirjoittimia, tietokantapalvelimia ja
verkkopalvelimia on kytketty toisiinsa verkkoyhteyden avulla
•
Palvelinkoneiden, kuten tietokanta-, tiedosto-, verkko- ja sähköpostipalvelinkoneiden on tarkoitus
huolehtia kyseisten palveluiden tarjonnasta verkkoon liitetyille asiakaskoneille, jotka on tarkoitettu
yksittäisille käyttäjille.
•
Asiakaskoneille on asennettuna käyttöliittymät palvelimilla olevien sovellusten käyttöön
saamiseksi.
•
Käyttäjät voivat lisäksi suorittaa omilla asiakaskoneillaan omia erikoissovelluksiaan, joissa em.
palvelimia ei tarvita ja joita ei tarvitse tarjota kaikkien käyttäjien saataville.
•
On tyypillistä, että lähiverkkoon kytketty kone toimii ainoastaan asiakkaana tai palvelimena,
mutta koneella voi olla samanaikaisesti myös molemmat ominaisuudet.
2.5.3 Kaksitahoinen asiakas – palvelin -ratkaisu
•
Asiakkaan koneella voidaan suorittaa tietokantaan kuuluvia sovellusohjelmia ja esittää
kyselyjä, joiden prosessointi tapahtuu palvelinkoneella.
•
Tarvitaan yhteysohjelmisto, jonka avulla kommunikointi tietokannan datapalvelimen kanssa
tapahtuu.
•
Mahdollistaa TKHJ:n hajautuksen: palvelin toimii puhtaasti datan käsittelijänä, kilpailevien
tapahtumien kontrolloijana sekä virhetilanteista toipumisen toteuttajana.
•
Kyselyiden optimointi, käyttöliittymät ja tietohakemistojen käsittely tapahtuu puolestaan
asiakkaan koneella.
2.5.3 Kolmitahoinen asiakas – palvelin -ratkaisu
•
Internetin yleistyttyä asiakas-palvelin ratkaisuihin on tullut mukaan kolmas taso
•
Asiakkaalla on käytössään graafinen käyttöliittymä, jonka kautta hän ottaa yhteyttä
sovelluspalvelimeen tai verkkopalvelimeen, joka käsittelee asiakkaan lähettämän pyynnön tai
kyselyn ja lähettää sen eteenpäin varsinaiselle tietokantapalvelimelle.
•
Tietokantapalvelin palauttaa ainakin osittain käsitellyt tulokset takaisin edelliselle tasolle, jossa
tulosta mahdollisesti vielä muokataan asiakkaan käyttöliittymälle sopivaksi.
•
Täten käyttöliittymä, sovelluksen säännöt ja varsinainen datan saanti tapahtuvat kolmella eri
taholla.
•
Tietoliikenne asiakkaan ja sovelluspalvelimen välillä tapahtuu salatusti tietoturvan
parantamiseksi.
2.6. Tietokannan hallintajärjestelmien luokittelutavat
•
Tärkein kriteeri on tietomalli ( relaatio-, olio-, verkko-, hierarkkinen vai olio-relaatiotietokanta )
•
Muita kriteerejä:
o yhden vai monen käyttäjän järjestelmä?
o keskitetty vai hajautettu?

jos hajautettu, niin onko tietokannan hallintajärjestelmä homogeeninen vai
heterogeeninen?
 käytetäänkö samaa vai eri TKHJ-ohjelmistoa tietokannan eri sijaintipisteissä?
 hajautettu heterogeeninen TKHJ on ainakin jossain määrin paikallisesti
autonominen, jolloin puhutaan ns. liittomuotoisesta TKHJ:stä ( federated DBMS )
o
TKHJ:n kustannukset
o
datan saantipolkujen tyypit
o
yleiskäyttöinen vai erikoiskäyttöön tarkoitettu

erikoiskäyttöön tarkoitettua TKHJ:tä ei voida helposti muuntaa muuhun tarkoitukseen
käytettäväksi ( esim. lentoyhtiöiden paikanvarausjärjestelmät )
 lyhyt vasteaika tärkeä kriteeri TKHJ:n
käyttökelpoisuuden kannalta
•
Relaatiotietokannat perustuvat kokonaisuuksien esittämiseen taulumuodossa
•
Oliotietokannat perustuvat objekteihin, jotka edustavat jotain luokkaa, jonka edustajilla on
voimassa tietyt ominaisuudet.
•
Olio-relaatiotietokannat ovat relaatiomallin laajennus, joka hyödyntää oliotietomallin piirteitä (
mm. objektien tallentaminen dataan ).
•
Verkkomallissa data esitetään joukkotyyppisenä linkitettyjen tietueiden avulla
o
•
riippuvuussuhde 1:N ( yksi tietue liittyy N:ään tietueeseen )
Hierarkkisessa mallissa data esitetään hierarkkisena puurakenteena.
o
o
o
jokainen hierarkiataso kuvaa toisiinsa liittyviä tietueita
ei standardoitua kyselykieltä
käsitellään yleensä tietue kerrallaan
3. Tiedon mallintaminen ER-mallin avulla
•
Tietokannan käyttöönottovaihetta edeltävät aina suunnittelu, toteutus ja sovellusohjelmien
testaus.
•
Tietokannan suunnitteluvaihe muistuttaa jonkin verran yleistä ohjelmien suunnittelua.
•
Käsitteellinen mallinnus on tärkeää tietokantasovellusten suunnittelussa.
•
ER ( Entity Relationship ) tarkoittaa kokonaisuuksien välisiä suhteita.
•
ER-malli on korkean tason käsitemalli, jota käytetään yleisesti hyväksi tietokantaa
suunniteltaessa.
3.1. Korkean tason käsitemalli tietokannan suunnittelun apuvälineenä
Eteneminen alkutekijöistä kohti valmista tietokantaa
•
Tarpeiden kartoittaminen ja analysointi
o
o
o
•
Muodostetaan tietokannan käsitekaava käyttämällä korkean tason tietomallia
o
o
o
o
•
tarvittavat kokonaisuudet, suhteet ja säännöt määritellään
fyysiseen toteutukseen ei oteta tässä vaiheessa kantaa
selvitetään, että kaikkien osapuolten tietotarpeet esiintyvät käsitekaavassa ja etteivät eri
käyttäjäryhmien asettamat vaatimukset ole ristiriitaisia keskenään
jos käsitekaava osoittautuu virheelliseksi tai puutteelliseksi, tehdään tarvittavat
muutokset
Rinnakkaisesti tai hieman jälkeenpäin voidaan käsitekaavaan perustuen yrittää hahmottaa
toiminnallisessa eli funktionaalisessa analyysissä todetut käyttäjien tarvitsemat operaatiot.
o
•
selvitetään käyttäjiltä kysymällä, mitä kaikkia tietoja tietokannassa tulisi olla saatavilla
tarpeelliset tiedot ja toiminnot pitäisi selvittää niin tarkoin kuin mahdollista
käytetään apuna tietovuokaavioita yms. suunnittelua helpottavia menetelmiä
----> tavoitteena muodostaa kokonaiskäsitys tiedon ja toimintojen tarpeesta
tietokannassa
Jos käsitekaava on riittämätön toimintojen mallintamiseen, sitä voidaan uusia.
Kun kaikki tahot ovat tyytyväisiä tietokannan määriteltyihin ominaisuuksiin, on aika aloittaa
sen käytännön toteuttaminen ( implementointi ). Tätä vaihetta kutsutaan tietokannan
loogiseksi suunnitteluksi. Siinä muunnetaan korkean tason tietomallin mukainen kuvaus
TKHJ:lle sopivaan muotoon ( esimerkiksi relaatiomallin mukaiseksi ).
•
Loogisen kaavan valmistuttua voidaan aloittaa kyseiseen kaavaan perustuva
sovellusohjelmien suunnittelu sekä tietokannan fyysisen tallennusrakenteen suunnittelu,
jonka tuloksena saadaan tietokannan sisäinen kaava.
•
Sisäiseen kaavaan perustuen voidaan optimoida tietokantaa hyödyntävät valmiit
sovellusohjelmat.
•
Sovellusohjelmien valmistuttua tietokannan pitäisi nyt ihannetilanteessa vastata täysin sen
kaikkien käyttäjätahojen sille asettamia odotuksia.
3.2. Esimerkki tietokantasovelluksesta
•
Tavoitteena on rakentaa toimiva tietokantasovellus yhtä yritystä varten. Yritys edustaa
tapauksessamme siten sovelluksen kohteena olevaa "pienoismaailmaa". Oletetaan, että
seuraavat tiedot on saatu selville kartoitettaessa tietokannalle asetettavia vaatimuksia:
o Yritys on jakautunut osastoihin. Kullakin osastolla on yksikäsitteinen nimi ja yksi
johtaja. Johtajan tehtävässään aloittamispäivämäärä kirjataan muistiin.
Yksittäisellä osastolla voi olla toimintaa usealla paikkakunnalla.
o Osasto kontrolloi projekteja, joilla kullakin on yksikäsitteinen nimi ja
koodinumero sekä yksi sijaintipaikka.
o Jokaisesta yrityksen työntekijästä kirjataan nimi, henkilötunnus, osoite,
kuukausipalkka, sukupuoli ja syntymäaika. Lisäksi oletetaan, että kukin
työntekijä on kirjoilla tarkalleen yhdellä osastolla, mutta hän voi työskennellä
usean eri osaston kontrolloimassa projektissa. Lisäksi halutaan pitää yllä tietoa
työntekijän viikoittaisista työtunneista kussakin eri projektissa, joissa hän
työskentelee. Myös tieto kunkin työntekijän lähimmästä esimiehestä
pitää olla saatavilla.
o
Vielä halutaan pitää kirjaa kunkin työntekijän mahdollisista perheenjäsenistä. Heistä on
tiedettävä etunimi, sukupuoli, syntymäaika sekä asema perheessä työntekijään nähden.
•
Kirjan esimerkissä 3.2. on nähtävillä tietokannan suunnittelutyön lopputuloksena syntynyt
ER-mallin mukainen käsitekaava.
•
Jatkossa tullaan käymään läpi vaiheet, miten kyseiseen kaavaan on päädytty. Samoin
esitellään kaavassa esiintyvien merkintöjen tulkinta.
3.3. Entiteettityypit, entiteettijoukot, attribuutit ja avaimet
3.3.1. Entiteetit ja attribuutit
•
ER-malli perustuu datan kuvaamiseen entiteettien, attribuuttien ja liittymien eli suhteiden avulla.
•
Entiteetti on jokin reaalimaailmassa esiintyvä itsenäinen käsite, joka voi olla joko fyysinen tai
käsitteellinen.
o
o
o
esimerkiksi henkilö, auto, työntekijä jne. ovat fyysisiä entiteettejä
vastaavasti yliopiston kurssi, luennointikerta jne. ovat käsitteellisiä entiteettejä
entiteettiä relaatiotietokannassa edustaa yksittäinen taulu
( esimerkiksi opiskelijan ja kurssin perustietotaulu jne. ), ja entiteetin nimike pyrkii
kuvaamaan sitä osuvasti.
•
Entiteetille tyypillisiä ominaisuuksia kutsutaan attribuuteiksi. Attribuutit ovat siten entiteettiin
kuuluvia tietokenttiä.
o
Esimerkiksi nimi, ikä, osoite ja puhelinnumero ovat tyypillisiä yksittäiseen työntekijään
liittyviä ominaisuuksia.
o
Attribuutti voi olla joko yksinkertainen tai koottu:
 yksinkertaisen attribuutin arvo on selkeästi jakamaton
( esimerkiksi henkilön pituus )
 koottua attribuuttia voidaan käsitellä kulloisenkin tarpeen mukaisesti joko
kokonaisena tai ositettuna ( esimerkiksi henkilön nimen voidaan olettaa koostuvan
etunimestä, toisen nimen alkukirjaimesta ja sukunimestä )
o
Lisäksi attribuutti voi olla joko yksi- tai moniarvoinen
 yksiarvoinen attribuutti tarkoittaa ominaisuutta, joka ei voi saada kuin yhden arvon
kerrallaan ( esimerkiksi ikä )
 moniarvoinen attribuutti voi saada samanaikaisesti useita eri arvoja ( esimerkiksi
henkilön suorittamat tutkinnot )
o
Attribuutti voi olla joko tallennettu tai johdettu.
 Tallennetun attribuutin arvo ei ole pääteltävissä muiden attribuuttien avulla (
esimerkiksi henkilön kotiosoite )
 Johdetun attribuutin arvo on pääteltävissä tai laskettavissa tallennettujen
attribuuttien perusteella ( esimerkiksi ikä voidaan laskea, jos tiedetään nykyinen
päivämäärä ja henkilön syntymäaika )
 Johdettu attribuutti voi liittyä myös koko entiteetin ominaisuuteen eikä välttämättä
erikseen jokaiseen tietueeseen ( esimerkiksi opiskelijoiden kokonaismäärä saadaan
laskemalla tietueiden lukumäärä opiskelijataulusta )
o
Toisinaan myös puuttuvat arvot attribuutille ovat sallittuja, kunhan kyseessä ei ole ns.
avainattribuutti.
 puuttuvan arvon tulkinta on joko 'ei ole olemassa/ laskettavissa' ( esimerkiksi
henkilön esimies, jos hän sattuu olemaan yrityksen toimitusjohtaja ) tai
'tuntematon' ( ei ole jostain syystä tallennettu )
 ryhmä 'tuntematon' jakaantuu vielä kahteen alaryhmään:
 "tieto varmasti olemassa, muttei tiedossa" ( esimerkiksi henkilön pituus ja
paino )
 "ei tietoa, onko olemassa" ( esimerkiksi puhelinnumero - voi olla salainen )
o
kompleksiset attribuutit
 yhdistelmä koottuja ja moniarvoisia attribuutteja (esimerkiksi tilanne, jossa
henkilöllä on useampia asuntoja, joihin voi olla lisäksi useita puhelinnumeroita).
3.3.2. Entiteettityypit ja -joukot, avaimet ja arvojoukot
•
Entiteettityyppi määrittelee kokoelman entiteetin edustajia, joilla on samat attribuutit ( esimerkiksi
tyyppi, joka kuvaa opiskelijan perustietoja ).
•
Entiteettijoukko kuvaa tietyn entiteettityypin kaikkia edustajia ( esimerkiksi kaikkia yksittäisiä
opiskelijoita esittäviä tietueita ).
•
Usein termiä entiteetti käytetään kummassakin edellä mainitussa merkityksessä, eli tarkoittamaan
sekä kokonaisuutta kuvaavia ominaisuuksia että sen yksittäistä edustajaa.
•
Entiteettityyppiä kuvaa ER-kaaviossa yksinkertaisilla viivoilla merkitty suorakulmio, jonka sisällä on
entiteetin nimi, joka merkitään pelkkiä isoja kirjaimia käyttämällä.
•
Sellaista attribuuttia tai niiden yhdistelmää, joka yksikäsitteisesti identifioi entiteettijoukon
yksittäisen jäsenen ( tietueen ), kutsutaan entiteettityypin avaimeksi.
•
Avainattribuutti on usein yksittäinen attribuutti ( esimerkiksi henkilötunnus), mutta
yksikäsitteisyyden saavuttaminen saattaa vaatia useamman attribuutin yhdistelmän valitsemista
avaimeksi ( esimerkki: projektit, joissa henkilö työskentelee ).
•
Entiteettijoukon nykytilassa vallitseva yksikäsitteisyys on attribuutin avaimeksi kelpaamisen
kannalta välttämätön, muttei riittävä ehto ( kts. yliopistotietokannan opiskelijoiden perustiedot ).
Pitää kiinnittää huomiota tietokannan määrittelyssä asetettuihin ehtoihin sen rakenteesta.
•
Avaimeksi voi kelvata useampiakin kuin yksi attribuutti tai niiden yhdistelmä ( esimerkiksi auton
rekisteri- tai valmistenumero ).
•
Avaimen on oltava minimaalinen. Tämä tarkoittaa, ettei avaimeen pidä ottaa mukaan muita kuin
sellaisia attribuutteja, jotka ovat välttämättömiä yksikäsitteisyyden saavuttamiseksi.
•
Entiteettityyppiä, jolla ei ole lainkaan omaa avainattribuuttia, kutsutaan heikoksi entiteetiksi.
Entiteettityypin avaimeen kuuluvat attribuutit merkitään ER-kaavioon alleviivattuina.
•
Jokaiseen attribuuttiin liittyy ns. arvojoukko, joka määrää, millaisia arvoja sillä voi esiintyä
( esimerkiksi rajoitettu kokonaislukualue, enintään tietyn mittainen merkkijono jne. ).
•
Arvojoukko on matemaattisesti ymmärrettävissä kuvauksena entiteettityypiltä arvojoukon
potenssijoukkoon ( kaikkien mahdollisten alijoukkojen joukkoon ).
o
puuttuvaa arvoa edustaa tyhjä joukko
o
yksiarvoista attribuuttia edustaa attribuutin laillisten arvojen joukko
o
moniarvoista attribuuttia edustavat kaikki yhdistelmät, joita esiintyy entiteettijoukossa
o
yhdistettyä attribuuttia edustaa sen kaikkien osakomponenttien välinen karteesinen tulo
3.3.3. Yrityksen tietokannan alustava käsitteellinen suunnittelu
•
Lähdetään rakentamaan ER-kaaviota kappaleessa 3.2. esiteltyjen vaatimusten mukaiselle
tietokannalle.
•
Osasto sisältää attribuutit Nimi, Numero, Toimipisteet, Johtaja ja JohtajanAloituspäivä.
Koska sekä Nimi että Numero vaadittiin yksikäsitteisiksi, kumpikin näistä kelpaa erilliseksi
avaimeksi.
• Projektiin tarvitaan attribuutit Nimi, Numero, Sijaintipaikka ja KontrolloivaOsasto. Sekä Nimi
että Numero kelpaavat avaimeksi.
• Työntekijästä tallennetaan attribuutit Nimi, Hetu, Sukupuoli, Osoite, Kuukausipalkka,
Syntymäaika, Osasto ja Esimies. Nimi ja Osoite voitaisiin esittää sekä yksinkertaisina että
koostettuina attribuutteina:
---> kysyttävä lisätietoa käyttäjiltä.
• Perheenjäsenistä tarvitaan attribuuteiksi Työntekijä, Perheenjäsenen nimi, Sukupuoli,
Syntymäaika ja Perhesuhde työntekijään.
• Edelleen pitäisi pystyä esittämään, että työntekijä voi toimia useassa eri projektissa, ja
myös tehdyt työtunnit pitäisi kirjata.
---> olisi lisättävä työntekijä-entiteettityyppiin moniarvoinen koottu attribuutti
Työskentelee( Projekti, Tunnit ) tai projekti-entiteettityyppiin moniarvoinen attribuutti
Työsuoritukset( Työntekijä, Tunnit ).
---> kysytään taas lisää käyttäjiltä, jotka kertovat haluavansa mieluummin ensimmäisen
vaihtoehdon.
3.4. Relaatiotyypit ja -joukot, roolit ja rakenteelliset rajoitukset
• Tällä kurssilla liittymä  suhde  relaatio.
• Edellisissä määrityksissä on useita implisiittisiä riippuvuuksia, eli tietyn entiteettityypin
attribuutti viittaa selkeästi johonkin toiseen entiteettiin
( esimerkiksi Osaston johtaja --> Työntekijä,
Projektia kontrolloiva osasto --> Osaston tiedot,
Työntekijän esimies --> Työntekijä,
Työntekijän osasto --> Osaston tiedot).
• Implisiittiset riippuvuudet kannattaa esitellä pikemminkin suhteina kuin attribuutteina,
vaikka aluksi niiden esittely attribuutteina onkin mahdollista
----> käsitekaava tarkentuu asteittain.
3.4.1. Liittymien tyypit, joukot ja esiintymät
• Relaatioon osallistuu vähintään kaksi entiteettityyppiä. Kahden entiteettityypin välistä
relaatiota sanotaan binääriseksi, kolmen ternääriseksi jne. Sama entiteettityyppi voi
osallistua relaatioon useammin kuin yhden kerran.
• Suhteen esiintymällä ri tarkoitetaan kokoelmaa ( e1, e2, e3, ..., en ), jossa ei:t ovat siihen
osallistuvien entiteettityyppien E1, E2, ..., En yksittäisiä esiintymiä. Jos kyseessä on
binäärinen relaatio, n = 2.
•
•
Jokainen entiteettityypeistä E1, E2, ..., En osallistuu niiden välille määriteltyyn relaatioon.
Esimerkki binäärisestä relaatiosta: työntekijän työskenteleminen osastolla
--> työntekijäentiteettiä edustava esiintymä liitetään osastoa esittävän
esiintymän kanssa ( kts. kirjan esimerkki 3.9. )
•
Esimerkki ternäärisestä relaatiosta: tavaran, sen toimittajan ja toimituksen kohteena olevan projektin
liittäminen toisiinsa ( kts. kirjan esimerkki 3.10. )
•
Relaatiota voidaan kuvailla attribuuttien avulla. Esimerkiksi työntekijän työskentelyä jonkin osaston
laskuun voidaan kuvata työntekijän mahdollisena yksiarvoisena attribuuttina Osasto. Sama toimii myös
toisin päin: yhtäläisesti kutakin osastoa kohti voisi olla määriteltynä moniarvoinen attribuutti nimeltä
OsastonTyöntekijät, joka olisi luettelo työntekijöistä, jotka ovat töissä tietyllä osastolla.
•
Roolinimellä tarkoitetaan ominaisuutta, jollaisessa entiteettityyppi osallistuu liittymään ( esimerkiksi
relaatio työntekijän työskenteleminen osastolla ).
o
o
Roolinimet ovat melko selkeät, mikäli sama entiteettityyppi ei osallistu siihen useita kertoja.
Muussa tapauksessa on kyseessä ns. rekursiivinen relaatio, jossa sama entiteettityyppi osallistuu
siihen kahdessa ( tai useammassa ) eri roolissa ( esimerkiksi työntekijöiden esimiehet ).
3.4.3. Rajoitukset suhteiden tyypeille
•
Relaatioon osallistuvien entiteetin esiintymien kombinaatioiden lukumäärää voidaan tarpeen
mukaan rajoittaa ( esimerkiksi työntekijä voi olla kirjoilla vain yhdellä osastolla, jokaisella
osastolla on vain yksi johtaja jne. ).
•
Kaksi tyypillisintä suhteen tyypin rajoitetta ovat ns. lukumääräsuhde ja osallistumiskriteeri.
•
Binäärisen relaation lukumääräsuhde määrää, monenko esiintymän kanssa entiteetti voi osallistua
relaation. Esimerkki: osasto-työntekijä
-relaation lukumääräsuhde on 1:N. Tämä tarkoittaa sitä, että yhdellä osastolla voi olla kirjoilla
monta työntekijää, mutta yksi työntekijä voi edustaa vain yhtä osastoa.
•
Muut lukumääräsuhteet ovat 1:1, N:1 ja M:N.
•
Esimerkki 1:1 -lukumääräsuhteesta: osaston johtaminen. Jokaisella osastolla voi olla vain yksi
johtaja, ja jokainen henkilö voi johtaa vain yhtä osastoa.
•
Esimerkki M:N -lukumääräsuhteesta: työskenteleminen eri projekteissa. Jokainen työntekijä voi
toimia useassa eri projektissa, ja yhdessä projektissa voi olla useita työntekijöitä.
•
Relaation osallistumisrajoite ( participation constraint ) ilmaisee, onko yksittäisen entiteettityypin
esiintymän olemassaolo riippuvainen suhteesta toisen entiteettityypin esiintymään
( Esimerkki: voiko yrityksessä olla työntekijää, joka ei ole kirjoilla millään osastolla ).
•
Osallistumisrajoite voi olla osittainen tai täydellinen.
•
Relaation osallistumisvaatimuksen ollessa täydellinen pitää tietyn entiteetin kaikkien edustajien
osallistua kyseiseen relaatioon. Täydellistä osallistumisrajoitetta kutsutaan myös
olemassaoloriippuvuudeksi ( existence dependency ).
•
Esimerkiksi täydellisestä osallistumisesta voitaisiin mainita suhde
kirjoilla_osastolla( työntekijä ---> osasto ): jokaisen työntekijän pitää kuulua johonkin osastoon.
•
Jos puolestaan osallistumisrajoite on osittainen, ei kaikkien relaation muodostavan entiteettityypin
edustajien tarvitse osallistua relaatioon.
•
Esimerkki osittaisesta osallistumisesta: osaston johtaminen, eli johtaa( työntekijä ---> osasto ):
jokaisen työntekijän ei tarvitse johtaa jotakin osastoa.
•
Kannattaa huomioida, että sama osallistumisrajoite ei välttämättä ole voimassa relaation
käänteisrelaatiossa ( Esimerkki: johtaja( osasto ---> työntekijä ): jokaisella osastolla pitää olla
johtaja, vaikkei kaikkien työntekijöiden tarvitsekaan toimia jonkin osaston johtajana )!
•
Täydellinen osallistumisrajoite merkitään ER-kaavioon kaksinkertaisena ja osittainen
osallistumisrajoite yksinkertaisena viivana ( kts. kirjan kuva 3.2. ).
3.4.4. Liittymätyypin attribuutit
•
Paitsi entiteettityypeille, myös liittymille voidaan määritellä attribuutteja.
•
Toisinaan attribuutti liittyy luonnollisemmin kahden ( tai useamman ) entiteettityypin väliseen
suhteeseen kuin jompaankumpaan ( johonkin ) yksittäisistä entiteettityypeistä. Toistaiseksi
keskitytään jatkossa vain binäärisiin relaatioihin.
•
Esimerkki suhteen attribuutista: työntekijän yhdessä projektissa tekemät työtunnit ( kuvaa
paremmin henkilön ja projektin välistä yhteyttä kuin itse työntekijää tai projektia sinänsä ).
•
Mikäli relaation lukumääräsuhde on 1:1, voidaan suhteen attribuutti esittää haluttaessa kumman
tahansa entiteettityypin attribuuttina.
Esimerkki: osaston johtajan aloittamispäivämäärä voitaisiin yhtäläisesti sijoittaa osaston tai
työntekijän attribuutiksi, mutta käsitteellisesti se kuitenkin liittyy selvästi itse johtamisrelaatioon
johtaa( henkilö ---> osasto ).
•
Jos lukumääräsuhde on 1:N, voidaan suhteeseen liittyvä attribuutti sijoittaa luontevasti vain
relaation N-puolella olevaan entiteettiin.
Esimerkki: jos työntekijän työsuhteen alkamispäivä osastolla haluttaisiin kirjata, se voitaisiin viedä
haluttaessa työntekijän perustietoihin yksinkertaisena attribuuttina. Sen sijaan osaston attribuutiksi
se sopii erittäin huonosti, sillä siitä olisi tehtävä moniarvoinen koosteinen attribuutti
'Työntekijät+Aloituspäivät', jossa selvästi kaksi eri attribuuttia jouduttaisiin kombinoimaan yhdeksi.
•
Mikäli relaation lukumääräsuhde on M:N, eivät suhteen attribuutit enää mielekkäästi liity yksistään
jompaankumpaan entiteettiin. Tällöin ne pitää esittää suhteen attribuutteina (esimerkiksi työntekijän
tekemät työtunnit eri projekteissa). Vaihtoehtoinen esittely työntekijän tai projektin moniarvoisena
attribuuttina olisi paljon vaikeaselkoisempi.
3.5. Heikot entiteettityypit
•
Entiteettityyppi, jolla ei ole omia avainattribuutteja, on nimeltään heikko entiteetti( tyyppi ).
•
Heikon entiteettityypin tietueet on tunnistettavissa ainoastaan niiden tunniste- eli omistajatyypin
kautta. Heikon entiteettityypin osallistumisrajoite on aina täydellinen, eli sen esiintymien olemassaolo
on täysin riippuvaa omistajatyypistä.
Esimerkki: työntekijän perheenjäsenet ovat tunnistettavissa ainoastaan työntekijän
henkilötunnuksen kautta.
•
On kuitenkin mahdollista, että olemassaoloriippuvuutta esiintyy myös muillakin kuin heikoilla
entiteeteillä. Tällöin entiteetillä on olemassa jokin oma avainattribuutti, mutta ilman yhteyttä
tunnistetyyppinsä edustajaan entiteetin edustajilla ei ole mielekästä asemaa tietokannassa.
Esimerkki: ajokorttitiedot ( ajokorteilla on olemassa numero, joka identifioi yksittäisesti ajokortin —
eli kyseessä ei siten ole heikko entiteetti — mutta tiedot ovat melko lailla hyödyttömiä ilman yhteyttä
ajokortin haltijaan ).
•
Heikolla entiteettityypillä on yleensä osittaisavain, jonka turvin tyypin esiintymät ovat
tunnistettavissa, kun tietueiden omistaja tiedetään. Osittaisavain voi huonossa tapauksessa
muodostua kaikista heikon entiteettityypin attribuuttien yhdistelmästä.
Esimerkki: tarkastellaan työntekijän perheenjäseniä. Jos voidaan olettaa, ettei samalla työntekijällä
ole kahta etunimeltään saman nimistä perheenjäsentä, perheenjäsenen etunimi on tällöin
osittaisavain. Osittaisavaimeen kuuluvat attribuutit alleviivataan katko- tai pisteviivalla.
•
Heikot entiteetit merkitään ER-kaavioon kahdella viivalla rajatuin suorakulmioin.
•
Samoin relaatiot, joihin heikko entiteetti osallistuu, merkitään kaksin reunaviivoin piirretyin
ruuduin.
•
Heikon entiteetin perustaminen voidaan haluttaessa kiertää lisäämällä sen attribuutit
omistajatyyppinsä moniarvoiseksi koosteiseksi attribuutiksi.
Esimerkki: työntekijän perheenjäseniä kuvaavat tiedot voisivat yhtenä attribuuttina työntekijän
perustiedoissa { Perheenjäsenet( Nimi, Sukupuoli, Syntymäaika, Perhesuhde ) }.
•
On kuitenkin suositeltavaa käyttää heikkoa entiteettityyppiä moniarvoisen attribuutin asemesta, jos
o
heikkoon entiteettiin kuuluvia attribuutteja on 'tarpeeksi monta', jotta käsittely moniarvoisena
attribuuttina tulisi hankalaksi
o
mikäli heikko entiteettityyppi muodostaa relaatioita myös jonkin muun kuin
omistajaentiteettinsä kanssa
3.6. Yrityksen tietokannan tarkentaminen
•
Tavoitteena on tarkentaa tähän mennessä aikaansaatua yrityksen tietokannan ER-mallia ( kirjan
esimerkki 3.8.) täydentämällä sitä lukumääräsuhteiden ja osallistumisrajoitusten avulla sekä
muuntamalla osa attribuuteista suhdetyyppisiksi.
•
Luettelo tarpeellisista muutoksista:
o
Osaston johtaminen attribuutista relaatioksi: työntekijän osallistuminen on osittaista, osaston
osallistuminen pitää selvittää käyttäjiltä
----> lopputulos: osastolla oltava aina yksi johtaja
o
Johtajan aloituspäivämäärä suhteen attribuutiksi
o
Osastolle kuuluminen attribuutista relaatioksi, lukumääräsuhteeksi 1:N osaston ja työntekijän
välille
o
Projektin kontrolloiminen osaston ja projektin väliseksi suhteeksi. lukumääräsuhteeksi 1:N
osaston ja projektin välille. Projektin osallistumisen pitää olla täydellinen ( kysytty käyttäjiltä ).
o
Työntekijä - Esimies -suhde: lukumääräsuhde 1:N esimiehestä työntekijään. Työntekijäentiteetti
osallistuu relaatioon kahdesti. Molempiin suuntiin osittainen osallistuminen.
o
Työskenteleminen projekteissa: M:N -suhde työntekijän ja projektin välille. Molempiin suuntiin
täydellinen osallistuminen. Suhteelle attribuutiksi työntekijän työtunnit projektissa.
o
Perheenjäsenet: 1:N-suhde työntekijän ja perheenjäsenen välille, mikä on samalla identifioiva
suhde heikolle entiteetille perheenjäsen. Perheenjäsenen osallistuminen täydellistä, työntekijän
osittaista.
•
Mihin edellä mainittujen suhteiden määrittely johti?
o
poistettiin attribuutit esimies ja esimiehen aloituspäivä OSASTOsta, kontrolloiva osasto
PROJEKTIsta, Osasto, Esimies ja Työskentelee( Projekti, Tunnit ) TYÖNTEKIJÄstä ja työntekijä
PERHEENJÄSENestä.
o
saavutuksena toiston minimoituminen käsitekaaviossa
3.7. ER-kaavioihin liittyviä nimeämiskäytäntöjä ja suunnittelunäkökohtia
3.7.1. Yhteenveto ER-kaavioiden merkinnöistä
•
ER-kaavio kuvaa ainoastaan tietokannan rakennetta, ei sen sisältämää dataa.
•
Attribuuttien tietotyyppiä ja arvoaluetta ei esitellä.
•
Luettelo ER-kaavioissa käytettävistä symboleista löytyy kirjan kuvasta 3.14. ( esitellään luennolla ).
3.7.2. Tietokannan kaavan rakenneosien nimeämisestä
•
Entiteettityyppien nimet esitetään yksikkömuodossa ( esimerkiksi työntekijä, osasto jne. ).
•
Entiteettityyppien ja relaatioiden nimet merkitään kokonaisuudessaan ISOILLA KIRJAIMILLA.
•
Attribuuttien nimet merkitään Isolla alkukirjaimella.
•
Roolinimet merkitään kokonaisuudessaan pienin kirjaimin.
•
Entiteettityyppien ja attribuuttien tunnukset ovat käytännössä substantiiveja ( esim. työntekijä,
etunimi ), kun taas relaatioita pyritään kuvaamaan yleensä verbeillä ( johtaa, työskentelee ).
•
ER-kaavio rakennetaan yleensä siten, että se on luontevasti luettavissa vasemmalta oikealle ja
ylhäältä alas. Kirjan esimerkissä 3.2. on tästä kuitenkin yksi poikkeus, joka liittyy työntekijän ja
perheenjäsenen väliseen relaatioon.
3.7.3. Ohjeistusta ER-mallin mukaiseen käsitteelliseen suunnitteluun
•
Usein esille tuleva kysymys: "Milloin tietokantaan liittyvä käsite pitäisi esitellä entiteettinä,
milloin attribuuttina ja milloin entiteettityyppien välisenä suhteena?”
•
Muutamia ratkaisuun vaikuttavia tekijöitä:
1.
Käsite voidaan aluksi esitellä attribuuttina, mutta tarvittaessa se voidaan myöhemmin
kuvata suhteeksi, jos se liittyy kiinteästi johonkin toiseen entiteettityyppiin
( esimerkiksi osaston johtaja --> osaston johtaminen ).
2.
Mikäli useassa entiteettityypissä esiintyy yhteinen attribuutti, voi olla aiheellista
perustaa sitä varten oma uusi entiteettityyppi.
Esimerkki: Kuvan 1.2. yliopistotietokannassa viitataan useassa paikassa
oppiaineeseen. Voisi olla mielekästä perustaa oppiainetta varten oma entiteettityyppi,
jolle voidaan määritellä myöhemmin tarvittavat lisäattribuutit.
3.
Jos puolestaan entiteettityyppi sisältää ainoastaan yhden attribuutin, ja siihen
viitataan vain yhdessä muussa entiteetissä, se kannattaa liittää kyseisen entiteetin
attribuutiksi.
4.
Muita erikoistamis- / yleistämismenetelmiä käsitellään myöhemmin kappaleessa 4.
3.7.4 Vaihtoehtoisia merkintätapoja ER-kaaviolle
•
Voidaan merkitä aikaisempaa kuvausta tarkemmat rajat relaation lukumääräsuhteelle ja
osallistumisrajoituksella tyyliin ( alaraja, yläraja ). Aina on voimassa epäyhtälöpari
0 ≤ alaraja ja yläraja ≥ 1.
Esimerkki: TyöntekijöitäOsastolla(4, N) tarkoittaisi, että kullakin osastolla on oltava vähintään
4 työntekijää.
•
Mikäli relaatioon osallistuminen voi olla osittaista, alaraja on 0.
•
Kaavioon merkitään myös relaation suuntaa kuvaava nimitys ( esimerkiksi kirjoilla_osastolla,
osaston_työntekijä ).
•
Parin ( alaraja, yläraja ) merkitsemiskohta yleensä päinvastainen kuin aikaisemmassa
kaaviotyypissä.
3.8. UML:n luokkadiagramminotaatio
•
Objektimallinnusmenetelmät on alun perin kehitetty ohjelmistojen suunnittelua varten, mutta ne
ovat yleistyneet sittemmin myös tietokantojen suunnittelussa.
•
Luokkadiagrammit ovat tärkeä osa kyseisiä menetelmiä, ja ne muistuttavat monessa suhteessa
EER-kaavioita.
•
Tunnetuimpia objektimallinnusmenetelmiä ovat OMT ( Object Modeling Technique ) sekä UML
( Universal Modeling Language ). Tällä kurssilla rajoitutaan UML:n lyhyeen esittelyyn.
•
Vaikka UML:ssä on paljon samoja piirteitä kuin EER:ssä, niistä käytettävä terminologia eroaa
toisistaan monissa kohdin.
•
Luokkaa ( entiteettityyppiä ) merkitään laatikolla, joka on jaettu kolmeen eri lokeroon: luokan
nimeen, attribuuttilistaan mahdollisine tietotyyppien kuvauksineen sekä operaatioihin.
•
Suhdetyypistä käytetään UML:ssä nimitystä assosiaatio ja sen esiintymistä nimitystä linkki.
•
Binääristä assosiaatiota ( relaatiotyyppiä ) merkitään yksinkertaisella viivalla, joka yhdistää
relaatioon osallistuvat luokat. Assosiaation nimeä ei välttämättä merkitä näkyviin.
•
Suhteeseen liittyvät attribuutit, eli UML-terminologian mukaisesti linkkiattribuutit, merkitään
laatikkoon, joka yhdistetään katkoviivalla relaatiota kuvaavaan viivaan.
•
lukumääräsuhdetta ja osallistumisrajoitetta kutsutaan yhdessä osallistumisen rajaluvuiksi
( multiplicities ), joita merkitään esityksellä ( alaraja, yläraja ). Rajaluvut merkintään kuitenkin
toiselle puolelle relaatiota kuin kohdassa 3.7. kuvatussa ER-mallin vaihtoehtoisessa merkintätavassa.
•
Rajaluvuissa ylärajasymboli * edustaa ylhäältä rajoittamatonta osallistumista. Yksinäinen symboli *
tarkoittaa lyhenteenä rajalukuja ( 0, * ) sekä 1 rajalukuja ( 1, 1 ).
•
Rekursiivisesta relaatiosta käytetään nimitystä refleksiivinen assosiaatio, ja siihen liittyvät roolinimet
merkitään myös päinvastoin kuin ER-mallin vaihtoehtoisessa esitystavassa.
•
Tarkastellaan kirjan esimerkkiä 3.16. UML:n merkintöjen havainnollistamiseksi.
•
Toisin kuin EER:ssä, UML:ssä erotellaan kahden eri tyypin relaatioita: assosiaatioita ja
aggregaatioita.
•
Aggregaatiolla (  keräymä ) tarkoitetaan relaatiotyyppiä, joka liittää yhteen objektin ja sen
rakenneosat.
Esimerkki: Osasto ja sen toimipisteet ( moniarvoinen attribuutti ), projektin sijaintipaikka.
•
Assosiaatio ja aggregaatio eivät kuitenkaan eroa rakenteellisesti toisistaan, joten valinta eri
suhdetyyppien välillä on melko vapaa.
•
Aggregaation omistajaluokkaa  eli minkä luokan komponentteja relaatio kerää  kuvaa pieni
ruutusymboli ( □ ).
•
UML:ssä on myös operaatioiden tarkka kuvaaminen sekä niiden vaatimien argumenttien
esittäminen mahdollista.
•
Heikot entiteettityypit esitetään todennettuna assosiaationa tai aggregaationa ( qualified
association / aggregation ). Identifioivan relaation osittaisavain merkitään omistajaluokkaa
kuvaavan laatikon jatkeeksi piirrettyyn suorakulmioon.
4. Laajennettu ER- (= EER-) ja objektimallinnus
•
Monissa liike-elämän ja teollisuuden perinteisissä tietokantasovelluksissa ER-malli on riittävän
voimakas kuvaamaan tietokannan kaavaa.
•
Nykyisin on kuitenkin paljon sovellusalueita, joissa perinteinen ER-mallinnus on riittämätön. Tällaisia
sovelluksia ovat mm. CAD/CAM-tietokannat, tiedonlouhinta ( data mining ), tietovarastointi ja
multimediatietokannat. Näihin tietokantoihin kohdistuvien vaatimusten esittämiseksi mahdollisimman
tarkoin ja selkeästi tarvitaan ns. semanttista datan mallinnusta.
•
Näitä sovelluksia varten kehitetään usein oliokeskeisiä tietokantoja, joiden hahmottamiseksi esitellään
aluksi laajennettu ER-malli eli EER-malli ( EER = enhanced entity relationship ).
4.1 Aliluokat, yliluokat ja periytyvyys
•
Tietokannan funktionaalisia vaatimuksia voidaan kuvata myös OMT- ( Object Modeling Technique ) ja
UML-kuvauskielen ( Universal Modeling Language ) avulla. EER-malli sisältää kaikki ER-malliin
sisällytetyt ominaisuudet tietokannan kaavan kuvaamiseksi.
•
Lisäominaisuuksia ovat mm. erikoistaminen ja yleistäminen, joihin liittyvät tiiviisti ali- ja yliluokkien
käsitteet, kategoriat sekä attribuuttien ja suhteiden periytyminen.
•
EER-mallin avulla muodostettavaa tietokannan kaaviota kutsutaan laajennetuksi ER-kaavioksi tai
EER-kaavioksi.
•
Entiteetin aliluokalla tarkoitetaan tietyn kriteerin mukaisesti rajoitettua entiteettityypin edustajien
osajoukkoa. Esimerkiksi työntekijä-entiteetti voitaisiin jakaa ositteisiin vaikkapa ammattinimikkeen
( mm. sihteerit, insinöörit, johtajat, teknikot ) tai palkkaustyypin ( mm. tuntipalkka, kuukausipalkka,
urakkapalkka ) mukaisesti.
•
Jokaisella tietyn entiteettityypin aliluokan edustajalla on myös sen kantaentiteettityypin eli yliluokan
ominaisuudet.
•
Tiettyyn aliluokkaan liittyvistä lisäominaisuuksista käytetään nimitystä spesifiset eli paikalliset
attribuutit. Yliluokan ja minkä tahansa sen aliluokan välistä suhdetta kutsutaan yli- ja aliluokan tai
lyhyemmin luokan ja sen aliluokan väliseksi relaatioksi.
Esimerkki: työntekijän ja sihteerin tai työntekijän ja teknikon välinen relaatio.
•
Edustaessaan yliluokkaansa aliluokan jäsen esiintyy samanlaisessa asemassa kuten kaikki muutkin
yliluokan edustajat.
•
Toimiessaan aliluokkansa edustajana aliluokan jäsen erottuu aliluokkaan kuulumattomista
yliluokkansa edustajista ainakin jonkin erityispiirteen osalta. Vaikka aliluokan esiintymät ovat
yliluokkansa tarkennuksia, ne edustavat kuitenkin käsitteellisesti samaa esiintymää kuin niiden
yliluokassa oleva vastine.
•
Mikäli esiintymä kuuluu johonkin aliluokkaan, sen on kuuluttava myös kyseisen aliluokan yliluokkaan
eli ns. kantaentiteettiin.
Esimerkki: jos henkilö on teknikko, hän on samalla myös työntekijä.
•
Entiteetin tyyppi = entiteetin attribuutit + relaatiot, joihin se osallistuu.
•
Tyypin periytyvyys: aliluokan edustaja perii kaikki yliluokkansa attribuutit arvoineen sekä relaatiot,
joihin yliluokka osallistuu.
4.2. Erikoistaminen ja yleistäminen
•
Erikoistamisella tarkoitetaan entiteettityypin aliluokkien määrittelyä. Erikoistamisen kohteena olevaa
entiteettityyppiä kutsutaan erikoistamisen yliluokaksi.
•
Erikoistaminen aliluokkiin voi tapahtua erilaisin kriteerein.
Esimerkki: työntekijä-entiteettityypille muodostettava aliluokkien joukko { sihteeri, insinööri,
teknikko } on työntekijän erikoistus ammattinimikkeen suhteen. Vastaavasti työntekijät
voitaisiin erikoistaa palkkaustyypin mukaan vaikkapa joukkoon { tuntipalkatut,
kuukausipalkatut }.
•
Aliluokilla voi olla erilaisia paikallisia attribuutteja ( esimerkiksi sihteereillä konekirjoitusnopeus,
insinööreillä insinööritutkinnon toimiala jne. ).
•
Lisäksi voidaan määritellä aliluokille erityisiä relaatioita, jotka eivät ole voimassa yliluokassa
( esimerkiksi tuntityöntekijöiden kuuluminen ammattiliittoon jne. ).
•
Kirjan esimerkki 4.1. selkeyttää käsitteitä.
•
Aliluokkaan kuuluminen voidaan tulkita toimimiseksi jossain tarkennetussa roolissa ( vrt. kuka
tahansa työntekijä vs. insinööri yms.).
•
Luokan ja sen aliluokan välinen yhteys muistuttaa 1:1 -suhdetta niiden esiintymien välillä. Aliluokan
edustaja on sama tapaus kuin luokkatasoa korkeammalla oleva, mutta se esiintyy aliluokassa
tarkennettuna, erikoistuneena johonkin rajoitettuun alijoukkoon kuuluvaksi.
•
Perusteita erikoistamiselle:
o joitain attribuutteja ei välttämättä tarvita luokan kaikille edustajille, vaan ainoastaan johonkin
luokan tiettyyn alijoukkoon kuuluville ( esimerkiksi konekirjoitusnopeus: vain sihteerit )
o
voidaan muodostaa relaatioita, jotka on tarpeen määritellä vain tietyn
aliluokan edustajille ( esimerkiksi ammattiliittoon kuuluminen )
•
Yleistäminen on erikoistamiselle käänteinen abstrahointiprosessi, jossa yritetään löytää luokkien
yhteisiä piirteitä ja koota niistä luokille yhteinen yliluokka.
•
Esimerkki: henkilö- ja kuorma-autoille voitaisiin muodostaa yliluokka kulkuneuvo. Yhtäläisesti
voitaisiin yleistää sihteeri, teknikko ja insinööri työntekijäksi.
•
Sekä luokkaa että sen aliluokkia esitetään EER-kaaviossa entiteettityyppeinä, sillä ne voivat
kumpikin osallistua relaatioihin.
4.3. Erikoistamisen ja yleistämisen rajoitteet ja piirteet
•
Koska erikoistaminen ja yleistäminen ovat toisilleen käänteiset lähestymistavat, puhutaan jatkossa
yleensä vain erikoistamisesta.
•
Samasta entiteettityypistä voidaan tehdä useita erikoistuksia ( vrt. työn-tekijän luokitteleminen
ammattinimikkeen tai palkkaustyypin mukaan ).
•
On myös mahdollista, että aliluokkia on määritelty ainoastaan yksi ( esimerkiksi johtajien erottelu
muista työntekijöistä ).
•
Erittely aliluokkiin tapahtuu yleensä joidenkin attribuuttien arvojen yhdistelmän mukaan. Tällöin on
kyseessä predikaatti- tai ehtomääritteinen aliluokka ( predicate- / condition-defined subclass ).
Edelleen, jos vain yhden attribuutin arvo määrää aliluokan, on erittely attribuutti-määritteinen.
•
Erittelykriteerinä oleva attribuutti merkitään EER-kaavioon näkyviin luokan ja sen
erikoistumisjaottelua kuvaavan pallukan väliin.
•
On myös mahdollista, että käyttäjä itse tekee jaottelun eri aliluokkiin, jolloin jaottelu ei tapahdu
automaattisesti jonkin attribuutin arvon perusteella. Tällä tavoin määritellystä aliluokasta käytetään
nimitystä käyttäjän määrittelemä aliluokka ( user-defined subclass ).
•
Erikoistamiseen liittyy läheisesti ns. erillisyysrajoitus. On mahdollista vaatia, että erikoistettaessa
sama entiteettityypin esiintymä voi kuulua ainoastaan yhteen kriteerin mukaiseen aliluokkaan.
Tällöin on kyse erillisistä aliluokista ( disjoint subclasses ). Tätä ominaisuutta merkitään kaaviossa
d-symbolilla erikoistamista kuvaavassa pallukassa.
Esimerkki erillisistä ositteista: työntekijän luokittelu palkkaustavan mukaan.
•
Mikäli aliluokkien ei tarvitse olla erillisiä osituskriteerin suhteen, ne voivat olla päällekkäisiä.
Esimerkki: insinööri voi olla samalla myös tekninen johtaja.
•
Erikoistaminen voi osallistumisen tapaan olla osittaista tai täydellistä.
•
Mikäli tietyn luokan esiintymän on kuuluttava ainakin johonkin sen aliluokista, on kyseessä
täydellinen erikoistaminen ( esimerkiksi työntekijän palkkaustyyppi ).
•
Jos puolestaan aliluokkaan kuuluminen ei ole välttämätöntä, on kyseessä osittainen erikoistaminen.
Esimerkki: kaikilla ammattiryhmillä ei välttämättä ole erityispiirteitä, jotka olisivat mielenkiintoisia.
•
Erikoistamisen erillisyys- ja täydellisyyskriteerit ovat toisistaan riippumattomia, joten kaikki niiden
neljä kombinaatiota ovat mahdollisia:
o
erillinen ja täydellinen ( esimerkiksi työntekijän palkkaustapa yrityksessä: jokaisella henkilöllä
on oltava joko kuukausi- tai tuntipalkka, muttei molempia )
o
erillinen ja osittainen ( esimerkiksi työntekijän ammattinimikkeen mukainen tarkentava erittely
sihteereihin, insinööreihin ja teknikoihin: henkilöllä voi olla vain jokin em. ammattinimikkeistä,
muttei välttämättä mitään, sillä henkilö voisi olla vaikkapa tutkija, jota varten ei ole perustettu
erillistä aliluokkaa )
o
päällekkäinen ja täydellinen ( esimerkiksi yrityksen tuotannossa tarvittavat osat: ne on
väistämättä hankittava jollain tavalla joko ostamalla ja/tai valmistamalla itse )
o
päällekkäinen ja osittainen ( em. kolmen ammattinimikkeen valikoima lisättynä valikoiman
erillisyysrajoituksen ulkopuolisella johtajalla ( kts. kirjan kuva 4.6 ): henkilön ammattinimike
voisi olla – paitsi joko johtaja tai yksi kolmikosta {sihteeri, insinööri, teknikko} – myös
kumpikin samanaikaisesti, muttei välttämättä mikään näistä ( esim. tutkija ) )!
•
Vaikka erikoistaminen ja yleistäminen ovat näennäisesti toisilleen vastakkaisia operaatioita, on
erikoistaminen kuitenkin useammin osittaista kuin yleistäminen, sillä yleistettäessä kaikki
yleistämisen kohteena olevat luokat ovat jo usein määritellyt, kun taas erikoistettaessa kaikkia
tapauksia ei välttämättä ole vielä ehditty huomioida.
•
Tietueiden lisääminen ja poistaminen tietokannasta, jossa on luokka-aliluokkarakenteita:
o
Jos yliluokan tietue poistetaan, kyseinen tietue tuhotaan automaattisesti myös kaikista niistä
aliluokista, joissa se on edustettuna.
o
Mikäli yliluokkaan lisätään uusi tietue, se lisätään automaattisesti myös kaikkiin niihin
predikaatti- ( tai attribuuttimääritteisiin ) aliluokkiin, joihin kuulumisehdot tietue täyttää.
o
Mikäli aliluokkiin kuulumisrajoite on täydellinen, tietueen lisääminen yliluokkaan edellyttää, että
tietue lisätään ainakin yhteen sen aliluokista.
•
Erikoistamiselle ( yleistämiselle ) muodostuu joko hierarkia- tai hiladiagrammi.
•
Hierarkia muodostuu silloin, kun jokainen aliluokka osallistuu aliluokkana ainoastaan yhteen
luokka/aliluokka-relaatioon ( kts. kirjan esimerkki 4.4: työntekijöiden luokitteleminen
ammattiryhmiin )
•
Jos puolestaan luokka osallistuu aliluokkana useampaan kuin yhteen luokka/aliluokka-relaatioon,
muodostuu hila ( = lattice ).
•
Kirjan esimerkki 4.6: tekninen johtaja ( = engineering manager ) on paitsi johtaja, niin samalla myös
insinööri ja kuukausipalkkaa nauttiva työntekijä. Se on niin sanottu jaettu aliluokka. Teknisellä
johtajalla on siten ominaisuuksinaan työntekijän perusattribuutit, insinööriin, johtajaan ja
kuukausipalkkaiseen työntekijään liittyvät erikoisattribuutit sekä lisäksi omat paikalliset
attribuuttinsa.
•
Mikäli luokka perii ominaisuuksia kahdelta tai useammalta yliluokalta, kyseessä on ns. moniperintä.
•
Kirjan esimerkki 4.7 on laajempi ja monimutkaisempi esimerkki yliopiston tietokannasta. Kannattaa
huomioida, että sama entiteetin esiintymä voi esiintyä tietokannan graafin useassa eri alimman tason
solmussa eli ns. lehtisolmussa.
Esimerkki: valmis opiskelija voi olla lisäksi myös vaikkapa tutkimusassistentti.
•
Mikäli samat attribuutit peritään yliluokilta useammin kuin kertaalleen, niitä ei enää toisteta
aliluokassa.
Esimerkki: henkilön attribuuttien periytyminen opiskelija-assistentille sekä luokan ’opiskelija’ että
’työntekijä’ kautta
•
Jos järjestelmä ei tue moniperintää, joudutaan ne aliluokat, joissa sitä tarvittaisiin, osittamaan niin
moneen ositteeseen, että kaikki mahdolliset yliluokkien kombinaatiot saadaan esitettyä. Tämä voi
aiheuttaa melkoista aliluokkien määrän kasvua.
•
Esimerkki: Henkilö voisi olla samanaikaisesti vaikkapa työntekijä, alumni ja opiskelija. Mikäli kaikkia
näiden luokkien kombinaatiot haluttaisiin esittää ilman moniperintää, olisi perustettava näiden
rinnalle aliluokat { työntekijä + alumni }, {työntekijä + opiskelija }, { alumni + opiskelija } sekä
{ työntekijä + alumni + opiskelija }.
•
Samantyyppinen tilanne syntyisi, vaikka järjestelmä tukisikin moniperintää, mutta ei hyväksyisi
kahden eri alkuperäisen entiteettityypin yhdistämistä ( tähän palataan myöhemmin ).
•
Yliopiston tietokannan erikoistaminen eli mallintaminen ylhäältä alaspäin ( yksityiskohtaisempi
kuvaus kirjan esimerkissä 4.7 ):
•
Yhtäläisesti lähestymistapa olisi voinut olla alhaalta ylöspäin, eli yleistäminen.
•
Käytännön suunnittelussa etenemistä tapahtuu molempiin suuntiin, eli tarpeen mukaan joko
erikoistetaan tai yleistetään.
4.4 Unionityypin mallinnus kategorioiden avulla
•
Tähän mennessä olemme käsitelleet ainoastaan sellaisia moniperintä-tilanteita, joissa luokan kaikkien
yliluokkien ominaisuudet on peritty yhdeltä ja samalta entiteettityypiltä. Esimerkki: teknistä johtajaa
kuvaava aliluokka: kaikki matkan varrella perityt luokat ovat olleet HENKILÖn aliluokkia.
•
Mikäli luokalla perii usealta alkuperäiseltä entiteettityypiltä ominaisuuksia, on kyseessä unionityyppi
eli kategoria.
•
Esimerkki unionityypin tarpeellisuudesta: auton omistajan kuvaaminen. Omistaja voi olla joko yritys,
pankki tai yksityishenkilö. Siten kategoria OMISTAJA muodostuu em. entiteettityyppien unionista.
Tarkastellaan kirjan esimerkkiä 4.8.
•
Unionia merkitään entiteettien yhdistymistä kuvaavassa renkaassa -symbolilla.
•
Unionityypin eli kategorian edustajan tarvitsee sijaita vain yhdessä sen yliluokista ( esimerkiksi
kulkuneuvon omistaja on yleensä vain yksi kolmesta edellä mainitusta ) - päinvastoin kuin silloin, kun
yliluokka ei muodostu unionista, jolloin aliluokan edustajan pitää löytyä kaikista sen yliluokista
( vrt. tekninen johtaja, jonka pitää olla sekä johtaja, insinööri että kuukausipalkkainen ).
•
Jos kategoria on täydellinen, se edellyttää, että kaikkien unioniin osallistuvien entiteettityyppien
esiintymät ovat edustettuina kategoriassa (vrt. kirjan 3. painoksen esimerkki 4.9 ( b ) ).
•
Täydellinen kategoria merkitään kaksinkertaisella viivoituksella kategoriasta unionia kuvaavaan
renkaaseen.
•
Mikäli kategoria on täydellinen, se voidaan esittää yhtäläisesti täydellisenä erikoistamisena
( vrt. kirjan esimerkki 4.9. ( b ): jokaisen rakennuksen ja tontin on oltava samalla myös kategoriassa
OMAISUUSLAJI ( property ) ).
•
Jos kategoria on puolestaan osittainen, ei kaikkien unioniin kuuluvien entiteettien tietueiden tarvitse
olla edustettuna kategoriassa ( vrt. kirjan esimerkki 4.9 ( a ) ).
•
Tällöin ei kategorian korvaaminen erikoistamisella onnistu, sillä kaikkien unionin edustajien ei
tarvitse enää kuulua kategoriaan. Tällöin aliluokkaan päätyisi tietueita, joilla ei ole edustajaa
yliluokassaan ( vrt. kirjan 3. painoksen esimerkki 4.9. ( a ): kaikki yhtiöt ja yksityishenkilöt eivät
välttämättä ole tilinomistajia ).
4.5 Esimerkki yliopiston tietokannasta EER-mallinnuksella ja mallin käsitteiden
formaaleja määritelmiä
•
Käsitellään kirjan esimerkin 4.9 mukainen EER-kaavio yliopiston tietokannasta.
•
EER-mallin käsitteiden formaalit määrittelyt:
o
luokka on yleisnimitys entiteettien kokoelmalle, joka koostuu entiteettityypeistä, ali- ja
yliluokista sekä kategorioista
o
aliluokka S on luokka, jonka kaikki esiintymät ovat jonkin sen yliluokan C osajoukkona,
eli S  C
o
Erikoistus Z = { S1, S2, ..., Sn } on aliluokkien joukko, joilla on sama yliluokka G, eli G/Si on
luokka-/aliluokkarelaatio, kun i = 1, 2, ..., n. Vastaavasti G on aliluokkien Si yleistetty
entiteettityyppi eli yliluokka.
o
Erikoistus on täydellinen, jos Si:tten unioni on G.
o
Jos Si  Sj = , kun i  j, niin erikoistus on erillinen, muutoin se on päällekkäinen.
o
C:n aliluokka S on predikaattimääritteinen, jos C:n attribuuttien ominaisuuksista voidaan
päätellä, mitkä sen esiintymistä kuuluvat S:ään. Jos predikaattiin kuuluu vain yksi attribuutti,
S on samalla attribuuttimääritteinen. Muutoin S on käyttäjän määrittelemä erikoistus.
o
Attribuuttimääritteinen erikoistus on erillinen, mikäli attribuutti on yksiarvoinen.
o
Kategoria T on unioni, jonka määräävät n kappaletta yliluokkia
D1, D2, ..., Dn, n > 1, seuraavasti:
T  ( D1  D2  ...  Dn ).
4.6 Erikoistamisen / yleistämisen ja perinnän esittäminen UML:n
luokkadiagrammien avulla
•
Yksittäisen luokan kaikki aliluokat yhdistetään pystysuoran viivan avulla vaakasuoraan viivaan,
jonka keskellä sijaitsee erikoistamisen lajia kuvaava kolmio. Tämä kolmio on puolestaan yhdistetty
pystysuoralla viivalla yliluokkaan. Valkoinen kolmio kuvaa erillistä erikoistamista ja musta kolmio
päällekkäistä ( tarkastellaan aiheeseen liittyvää kirjan esimerkkiä 4.10. ).
•
Yliluokasta käytetään myös nimitystä perusluokka ja alimman tason aliluokista nimitystä
lehtiluokka.
•
Sekä yksinkertainen että moniperintä pystytään esittämään.
4.7 Astelukua 2 korkeamman asteen liittymätyypit
•
Tarkastellaan kertauksen vuoksi ternääristä relaatiota kuvaavaa kirjan esimerkkiä 3.10.
•
Kolmen entiteettityypin välinen relaatio tavaratoimitus ( = supply ) toimittajan, osan ja projektin
välillä pitää sisällään kolme binääristä relaatiota: toimittaja — osa, toimittaja — projekti ja osa —
projekti. Ternääristä relaatiota merkitään argumentteineen merkinnällä tavaratoimitus( t, o, p ),
missä t, o ja p viittaavat suhteeseen osallistuviin entiteettityyppeihin. Vastaavasti siihen sisältyviä
binäärisiä relaatioita merkitään seuraavasti: toimittaa_osaa( t, o ), osien_käyttö( o, p ) sekä
toimittaa_projektille( t, p ).
•
Binääristen relaatioiden merkitys:
o
toimittaa_osaa( t, o ) sisältää kaikkien valmistajien toimittamat osat mille projektille tahansa.
o
toimittaa_projektille( t, p ) sisältää kaikkien valmistajien eri projekteille tekemät minkä
tahansa osan toimitukset.
o
osien_käyttö( o, p ) sisältää kaikkien osien toimitukset eri projekteille riippumatta siitä, mikä
toimittaja on milloinkin kyseessä.
•
Binääristen relaatioiden esiintymien toimittaa_osaa( t, o ), osien_käyttö( o, p ) ja
toimittaa_projektille( t, p ) olemassaolo EI TAKAA, että myös ternäärinen relaatio
tavaratoimitus( t, o, p ) olisi olemassa, sillä ternäärinen relaatio sitoo kaikki kolme entiteettityyppiä
toisiinsa, kun taas binäärisissä yksi entiteettityypeistä jää huomiotta.
•
Esimerkki: toimittaa_osaa( t, o ):
TOIMITTAJA
T1
T1
T2
T2
T3
OSA
kuulalaakeri
pultti
hammaspyörä
kuulalaakeri
venttiili
toimittaa_projektille( t, p ):
TOIMITTAJA
T1
T1
T2
T3
PROJEKTI
risteilijä
säiliöalus
säiliöalus
risteilijä
osien_käyttö( o, p ):
OSA
kuulalaakeri
kuulalaakeri
pultti
pultti
hammaspyörä
PROJEKTI
risteilijä
säiliöalus
risteilijä
säiliöalus
säiliöalus
Selvästikin ovat voimassa toimittaa_osaa( T1, kuulalaakeri ), toimittaa_projektille( T1, säiliöalus )
ja lisäksi osien_käyttö( kuulalaakeri, säiliöalus ), mutta sen sijaan ei välttämättä pidä paikkaansa,
että juuri toimittaja T1 huolehtisi kuulalaakerien toimittamisesta säiliöaluksiin, sillä yhtäläisesti
sen voisi tehdä myös toimittaja T2.
•
Kaikki tietokantojen suunnitteluvälineet eivät salli ternääristen tai sitä korkeamman asteisten
relaatioiden esittämistä, vaan on turvauduttava heikon entiteettityypin käyttöön. Esimerkissämme
toimitustapahtuma esitettäisiin heikkona entiteettityyppinä, jolla olisi attribuuttina toimitettu
tavaramäärä. Omistajatyyppejä olisivat kaikki kolmikosta projekti, osa ja toimittaja.
Toimitustapahtumalla ei olisi lainkaan osittaisavainta.
•
Tarkastellaan seuraavaksi kirjan esimerkkiä 4.12, jossa on muodostettu ternäärinen relaatio
luennoitsijan, kurssin ja lukukauden välille.
•
Kannattaa huomioida, että ternäärisen relaation esiintymän luentokurssi( luennoitsija, kurssi,
lukukausi ) olemassaolo takaa myös sen, että samoihin yksittäisten entiteettityyppien edustajiin
liittyvät binääristen relaatioiden esiintymät luennoi( luennoitsija, kurssi ), luennoidaan( kurssi,
lukukausi ) sekä pystyy_opettamaan( luennoitsija, kurssi ) ovat myös samalla olemassa.
Esimerkki: ternäärisen relaation esiintymä luentokurssi( Tietäväinen, kryptografia, sl98 )
takaisi myös, että
1) luennoitsija nimeltä Tietäväinen opettaa jotakin kurssia syyslukukaudella 1998!
2) joku luennoi kurssia kryptografia syyslukukaudella 1998!
3) luennoitsija Tietäväinen pystyy opettamaan kurssia kryptografia!
•
Kuten jo edellä todettiin, binääristen relaatioiden esiintymien olemassaolo ei takaa ternäärisen
relaation esiintymän olemassaoloa, ellei jokin binäärisistä relaatioista ole lukumääräsuhteeltaan 1:1.
Esimerkki: mikäli tiedetään, että kurssi 'Kryptografia' luennoidaan syyslukukaudella 1998,
luennoitsija nimeltä 'Tietäväinen' pitää kyseisellä lukukaudella opetusta, luennoitsija
'Tietäväinen' pystyy opettamaan kryptografiaa ja kutakin kurssia pystyy opettamaan
vain yksi opettaja, on voimassa myös ternäärisen relaation esiintymä
luentokurssi( Tietäväinen, kryptografia, sl98 ).
•
Myös astelukua 2 korkeammille relaatioille voidaan esittää lukumääräsuhde ja osallistumisrajoite.
•
Mikäli ternäärisen relaation lukumääräsuhde on muotoa 1 : ( M : N ), ei relaatioon kuuluvien
esiintymien avaimeen tarvita tietokenttää siitä entiteettityypistä, johon arvo 1 kohdistuu.
Esimerkki: Oletetaan, että relaation tavarantoimitus( toimittaja, osa, projekti ) lukumääräsuhde on
1 : ( M :N ). Tällöin tiettyä osaa yksittäiselle projektille pystytään tilaamaan vain yhdeltä
toimittajalta. Siten jokainen osa - projekti -pari määrää yksikäsitteisesti relaatioon
kuuluvat esiintymät, joten toimittajaa ei tarvita avaimeksi relaatioon.
4.8. Tiedon abstrahointiin ja tietämyksen esittämiseen liittyviä käsitteitä
•
Tietämyksen esittämisen ( knowledge representation, lyh. KR ) tavoitteena on mallintaa tarkastelun
kohteena olevaa pienoismaailmaa niin tarkoin, että mallin perusteella voidaan johtaa tiettyjä
tuloksia, tehdä päätelmiä tai pelkästään vastata kysymyksiin.
•
Tietämyksen esittämisen tavoitteet ovat pitkälti samoja kuin semanttisissa tietomalleissa, mutta
joitakin erojakin löytyy.
•
Yhtäläisyyksiä: Molemmissa lähestymistavoissa pyritään hahmottamaan tietokannan keskeiset
kokonaisuudet ja niiden piirteet samalla, kun merkityksettömät yksityiskohdat
jätetään huomiotta.
Kummassakin lähestymistavassa on käytettävissä käsitteitä, operaatioita, ja
rajoituksia sekä kieliä tiedon mallintamiseen.
•
Eroavuuksia:
Toisin kuin semanttisissa tietomalleissa, KR:ssä pystytään esittämään tietoa
laajemmin, kuten sääntöinä ( johtamista, deduktiota ja hakustrategioita varten ),
käsittelemään puuttuvaa ja oletuksen mukaista tietoa, aikaan ja paikkaan
sidoksissa olevaa tietoa jne.
KR:ssä on tarjolla päättelyvälineet, joiden avulla voidaan johtaa uusia faktoja
tietokannassa jo paraikaa olevista, kun taas semanttisen tietomallin mukaisessa
tietokannassa tyydytään usein pelkästään kyselyihin vastaamiseen.
KR:ssä myös tiedon instanssien esittäminen mallinnuksen yhteydessä on
mahdollista.
4.8.1. Luokittelu ja instantiointi
•
Luokittelun tavoitteena on koota yhteen samankaltaiset entiteetit ( objektit ) entiteettityypiksi
( luokaksi ).
•
Yhteen entiteettityyppiin kuuluvilla esiintymillä on saman tyyppiset attribuutit, relaatiot ja
rajoitukset.
•
Instantiointi on luokittelulle päinvastainen tarkastelu. Sillä tarkoitetaan yksittäisten
entiteettityyppien esiintymien tarkastelua.
•
Luokan yksittäisen objektin ja itse luokan välillä vallitsee suhde Y_ON_LUOKAN_X_ESIINTYMÄ.
•
Luokan kaikkia yleisiä ominaisuuksia täyttämättömiä objekteja, poikkeavia objekteja, voidaan
hyväksyä KR:ssä vapaammin kuin EER:ssä.
•
EER:ssä esiintyvät eri luokkatyypit ovat entiteettityyppi, aliluokka, kategoria ja suhdetyyppi.
•
EER:ssä ainoa suhde kahden eri luokan välillä on luokka-aliluokkasuhde, mutta KR:ssä myös ns.
metaluokat ovat laillisia. Metaluokassa luokka voi toimia jonkin toisen luokan esiintymänä.
4.8.2 Tunnistaminen
•
Tunnistamisella tarkoitetaan abstrahointiprosessia, jossa luokat ja objektit pystytään erottelemaan
toisistaan jonkin tunnisteen perusteella.
•
Tietokannan eri luokat pitää pystyä erottamaan toisistaan, samoin luokkiin kuuluvat objektit.
•
Jokaisella EER-mallin luokalla on oltava erillinen nimi riippumatta siitä, onko kyseessä
entiteettityyppi, aliluokka, kategoria tai suhdetyyppi.
•
Luokan nimi riittää erottelemaan eri luokat toisistaan.
•
Kahden tietueen tunnistaminen samaa reaalimaailman objektia tarkoittaviksi: yhteys tietueiden
välille määriteltävä suunnitteluvaiheessa.
Esimerkki: Henkilö-entiteettityypin tietue
< Matti Meikäläinen, 7944162, 249-1122 >
sekä opiskelija-entiteettityypin tietue
< 89446, TKO, 1997 >
voivat edustaa samaa reaalimaailman henkilöä, mutta tietueiden tunnistaminen
toisiinsa liittyviksi on sellaisenaan mahdotonta yhteisten tietokenttien puuttuessa.
•
Luokan sisällä attribuuttien nimeämisen on oltava yksikäsitteinen.
•
Yhden luokan sisällä tietueet tunnistetaan avainattribuuttien arvojen yhdistelmän mukaan.
•
Mikäli kyseessä on heikko entiteetti, tietueet tunnistetaan osittaisavaimen ja omistajaentiteettien
avainkenttien mukaan.
4.8.3 Erikoistaminen ja yleistäminen
•
Erikoistamalla pyritään luokan objektit jakamaan aliluokkiin mielekkään kriteerin mukaisesti.
•
Yleistäminen tuottaa puolestaan korkeamman tason abstraktion usean luokan yhteisille piirteille.
•
Erikoistaminen tarkoittaa käsitteellistä hienosäätöä, yleistäminen puolestaan käsitteellistä
synteesiä.
•
Luokan ja sen yliluokan välillä vallitsee suhde Y_ON_X:N_ALILUOKKA.
4.8.4 Aggregaatio ja assosiaatio
•
Aggregaatio tarkoittaa koosteisen objektin muodostamista komponenteistaan.
•
Aggregaatiota esiintyy kolmessa eri kohdin:
1.
Objektin attribuuttien arvojen kerääminen koko objektin
muodostamiseksi.
1.
Aggregaation esittäminen normaalina relaationa.
1.
Muodostettaessa korkean tason koosteinen objekti. Tätä ominaisuutta ei EER:ssä
tueta.
•
Assosiaatiolla tarkoitetaan toisistaan riippumattomien luokkien välistä yhteyttä. Tätä kuvataan
EER:ssä relaatioina (UML:ssä käytetään assosiaatio-nimitystä).
•
Assosiaation tulkinta on 'X_ON_RELAATIOSSA_Y Z:N_KANSSA'.
•
Esimerkkejä aggregaation eri lajeista (kirjassa esimerkki 4.14.):
1.
Luokka YHTIÖ on attribuuttien YhtiönNimi ja Osoite aggregaatio.
2.
Luokkien YHTIÖ ja TYÖNHAKIJA välinen suhde: suhteen attribuutit YhteyshenkilönNimi ja
YhteyshenkilönPuhelin liittyvät siihen yhtiön työntekijään, joka vastaa haastatteluista.
3.
Uuden, korkeamman tason koosteisen objektin muodostaminen: haastattelutapahtuma.
Esitettävä EER-mallissa kiertoteitse heikon entiteetin kautta, mikäli halutaan, että kaikki
työpaikkahaastattelut eivät johda työtarjouksen syntymiseen, mikä on varsin ilmeistä.
•
Kahden entiteetin välisen assosiaation purkautuminen ei välttämättä johda entiteettien poistamiseen
tietokannasta, mutta aggregaatiossa tulkinta on yleensä päinvastainen.
Esimerkki: Alainen-esimies -suhteen olemassaolon lakkaaminen kahden työntekijän väliltä ei
välttämättä tarkoita, ettei kyseisistä henkilöistä kumpainenkaan olisi enää yrityksessä
töissä. Sen sijaan koosteisen objektin, esimerkiksi auton, poistaminen tietokannasta
aiheuttaa usein myös sen kaikkien rakenneosien, kuten moottorin, korin ja renkaiden
poistamisen tietokannasta samalla.
4.8.5. Ontologiat ja semanttinen verkko
•
Monet verkosta ( www ) saatavilla olevat tiedot ovat dokumenttimuotoisia, joten niiden rakenne on
huomattavasti vaikeammin hahmotettavissa kuin tietokannalla.
•
Semanttisella verkolla tarkoitetaan tutkimusprojektia, jonka tavoitteena on kehittää tietämyksen
esittämismalleja, joita voitaisiin hyödyntää haettaessa johonkin yksittäiseen aihepiiriin kuuluvaa
tietoa verkosta.
•
Semanttisten verkkojen kannalta keskeinen käsite on ns. ontologian käsite, joka voidaan tulkita
käsitteellistämisen tarkentamisena.
•
Käsitteellistäminen pitää sisällään kaikki käsitteet, jotka ovat tietyn käyttäjäryhmän mielenkiinnon
kohteena.
•
Haluttaessa etsiä tietyn aihepiirin mukaisia dokumentteja vaikkapa kahdella eri kielellä kirjoitettuina
pitää käsitteellistäminen tarkentaa erikseen kummallekin haun kohteena olevalle kielelle
---> muodostuu kaksi erillistä ontologiaa.
•
Ontologian kuvaustekniikoina voidaan käyttää mm. sanakirjoja, taksonomioita, tietokannan kaavaa
tai logiikan teoriaa.
5. Relaatiomalli, relaatioiden rajoitukset ja relaatioalgebra
5.1 Relaatiomallin käsitteitä
•
Relaatio R kuvataan taulukkona ( table ), jonka kukin yksittäinen rivi ( row ) – tupla ( tuple ) –
edustaa kokoelmaa toisiinsa liittyviä arvoja.
•
Arvoalue ( domain ) D on attribuuttiin liittyvien yksittäisten atomisten
( jakamattomien ) arvojen joukko. Jokaista arvojoukkoa kohti on määritelty nimi, tietotyyppi ja
esitysmuoto.
•
Attribuutin tunnus tarkoittaa, miten sen arvojoukko on tulkittavissa relaatiossa. Attribuutin A
arvoalueeseen viitataan merkinnällä dom( A ). Sama arvojoukko voi esiintyä usealla attribuutilla,
jolloin attribuutin nimi kertoo sen roolin relaatiossa.
•
Relaation kaavaa ( relation schema ) merkitään tunnuksella R( A1, A2, ... An ), missä R on relaation
nimi.
•
Relaation asteella ( degree ) n tarkoitetaan relaatiotaulun attribuuttien lukumäärää.
•
Relaatiokaavaan R( A1, A2, ... An ) liittyvä tila r, merkitään r( R ), muodostuu tauluun kuuluvien
n-tuplien joukosta, eli r = { t1, t2, ..., tm }.
•
Jokainen n-tupla t koostuu arvoista <v1, v2, ..., vn>, missä vi ( 1  i  n ) edustaa tuplan i:nnen
attribuutin t[Ai] arvoa joukossa dom( Ai ) tai on puuttuva arvo ( null value ).
•
Relaation tila on relaatiokaavan sisäistys ( intension ) ja vastaavasti relaatiokaava on relaation tilan
ulkoistus ( extension ).
•
Tarkastellaan kirjan esimerkkiä 5.1 edellä esiteltyjen käsitteiden selkeyttämiseksi.
•
Formaalisti määriteltynä relaatio R voidaan tulkita n-asteiseksi matemaattiseksi relaatioksi
määrittelyjoukoille dom( A1 ), dom( A2 ), ..., dom( An ) eli R:n määrittelevien arvoalueiden
karteesisen tulon osajoukkona.
r( R )  ( dom( A1 ) x dom( A2 ) x ... x dom( An ) ).
Karteesinen tulo tarkoittaa kaikkia mahdollisia attribuuttien arvojen yhdistelmiä, jotka voidaan
relaation R tuplille muodostaa.
•
Merkitään yhteen arvoalueeseen kuuluvien arvojen lukumäärää merkinnällä D. Jos R:n kaikkien
attribuuttien arvojoukot ovat äärellisiä, R:n karteesiseen tuloon kuuluu yhteensä dom( A1 ) *
dom( A2 ) * ... * dom( An ) erilaista tuplaa.
5.1.2 Relaatioiden piirteitä
•
Relaation riippumattomuus tuplien järjestyksestä: koska relaatio tarkoittaa tuplien joukkoa, ei
relaation tilan kannalta ole merkitystä, missä järjestyksessä tuplat esitetään.
•
Relaatioon liittyvä tiedosto on kuitenkin aina järjestetty fyysisesti jollain tavalla.
Esimerkki: kirjan kuvien 5.1 ja 5.2 relaatiot ovat samat, vaikka niiden tietueet ovatkin eri
järjestyksessä.
•
Myöskään ei ole merkitystä sillä, missä järjestyksessä relaation kentät on kaavassa esitelty ( kirjan
esimerkki 5.3 ).
•
Relaatiomallissa ei hyväksytä moniarvoisia ja koosteisia attribuutteja, vaan lähdetään siitä, että
kaikkien attribuuttien arvot ovat atomisia ( s.o. relaatio on ns. ensimmäisessä normaalimuodossa,
tähän palataan myöhemmin luvussa 10 ). Sen sijaan puuttuvat arvot hyväksytään.
•
Jokainen tupla voidaan tulkita relaation faktana eli esiintymänä.
•
Kannattaa huomioida, että relaatio voi esittää faktoja sekä entiteeteistä että niiden välisistä
suhteista!
5.1.3. Relaatiomallin merkinnöistä
•
Astetta n olevaa relaatiokaavaa R kuvaa merkintä R( A1, A2, ..., An ).
•
Relaation r( R ) n-tuplaa t merkitään t = < v1, v2, ..., vn >, missä vi viittaa attribuutin Ai arvoon.
•
Sekä t[Ai] että t.Ai viittaavat attribuutin Ai arvoon vi.
•
Sekä t[Au, Aw, ..., Az] että t.(Au, Aw, ..., Az), missä Au, Aw, ..., Az ovat R:n attribuutteja, viittaavat
t:n alituplan kyseisten attribuuttien arvoihin < vu, vw, ..., vz >.
•
Kirjaimet Q, R ja S tarkoittavat relaatioiden nimiä. Kirjaimet q, r ja s tarkoittavat relaation tiloja.
•
Kirjaimet t, u ja v tarkoittavat tuplia.
•
Yleisesti, relaatiokaavan nimi yksinään kirjoitettuna ( esimerkiksi OPISKELIJA ) viittaa relaation
nykyisiin tupliin, kun taas nimi täydennettynä attribuuttilistalla viittaa ainoastaan relaation kaavaan
( esimerkiksi OPISKELIJA( Nimi, Hetu, ... ) ).
•
Attribuutin yhteydessä voidaan käyttää pistenotaatiota RELAATIO.Attribuutti korostamaan, minkä
relaation attribuutista on kyse. On nimittäin mahdollista, että usealla relaatiolla on samanniminen
attribuutti.
•
Esimerkki: oletetaan, että opiskelijatiedostossa esiintyy tupla
t = < 'Tahvo Löppönen', ’010203+7890’, ’010-5536155’, ’Torvitie 8’, ’3338634’, 100, 1.16 >.
Tällöin
t[Nimi] = <'Tahvo Löppönen'>
t[Hetu, OpsKeskiarvo, Ikä] = ’010203+7890’, 1.16, 100
5.2 Relaatioiden rajoitukset
•
Relaation sisältämälle datalle voidaan asettaa erilaisia rajoituksia, jotka voivat kohdistua
määrittelyjoukkoihin, avaimille, entiteetin eheyteen ja viite-eheyteen.
•
Muita mahdollisia rajoituksia, joita kutsutaan tietoriippuvuuksiksi ( kuten funktionaaliset ja
moniarvoiset riippuvuudet ), käsitellään tietokannan normalisoinnin yhteydessä.
5.2.1 Arvoalueen rajoitukset
•
Attribuuttien arvojen oltava atomisia ( ei hyväksytä moniarvoisia eikä koosteisia attribuutteja ).
•
Tyypillisiä rajauksia attribuutin arvoalueille ovat eri tyyppiset kokonaisluvut ( tavalliset, pitkät,
lyhyet ) ja niiden rajoitetut alueet, reaaliluvut, merkit ja kiinteän ja vaihtelevan mittaiset
merkkijonot, sekä päivämäärä, aika, aikaleima ja rahayksikkö.
•
Tarjolla olevia tietotyyppejä tarkastellaan tarkemmin SQL-99:n standardin yhteydessä.
5.2.2 Avainten rajoitukset ja puuttuvat arvot
•
Koska relaatio muodostuu joukosta tuplia, ei kahden identtisen tuplan esiintyminen relaatiossa ole
laillista.
•
Mikäli relaation R tiettyjen attribuuttien yhdistelmälle SK, joka koostuu 1..n kappaleesta
attribuutteja, ei voi esiintyä duplikaattiarvoja, SK on tällöin relaation R superavain ( superkey ).
Toisin sanoen, relaation tilassa r on aina voimassa ti[SK]  tj[SK], kun i  j.
•
Superavain SK voi sisältää redundantteja ( turhia ) attribuutteja, eli siitä voidaan mahdollisesti
muodostaa supistettu attribuuttien yhdistelmä SK' poistamalla vähintään yksi SK:n attribuuteista
siten, että myös SK' täyttää superavaimen yksikäsitteisyyskriteerin.
•
Superavainta, joka on minimaalinen, kutsutaan lyhyesti relaation avaimeksi ( key ). Poistamalla
yksikin avaimeen kuuluvista attribuuteista yksikäsitteisyysvaatimus relaatiotaulussa rikkoutuu.
•
Jokainen attribuuttien joukko, joka sisältää avaimen, on samalla myös superavain.
•
Tarkastellaan uudelleen kirjan esimerkkiä 5.1. Joukko Z = { Hetu, Nimi, Ikä } on relaation
superavain, muttei kuitenkaan avain, sillä poistamalla Z:sta attribuutit Nimi ja Ikä saadaan joukko
Z' = { Hetu }, joka kelpaa relaation avaimeksi. Täten Z ei ole minimaalinen superavain. Sitävastoin
Z' on myös superavain.
•
Avaimen avulla jokainen relaation tuplista pystytään tunnistamaan yksikäsitteisesti.
•
Avain on luonteeltaan aikainvariantti ( time-invariant ). Tämä tarkoittaa sitä, että relaation tilasta
riippumatta avaimessa ei esiinny duplikaatteja. Täten esimerkiksi nimi ei välttämättä kelpaisi
esimerkin 5.1. avaimeksi, vaikka esimerkissä ei esiinnykään kahta saman nimistä henkilöä.
Myöhemmin tällaisia voi kuitenkin ilmestyä relaatioon ( tai sellaisia on saattanut olla jossain
aikaisemmassa relaation tilassa ).
•
Mikäli relaatiolla on useita avaimia, kaikista näistä käytetään nimitystä ehdokasavain.
•
Jokin ehdokasavaimista valitaan relaation pääavaimeksi. Pääavaimeksi pyritään valitsemaan
mahdollisimman yksinkertainen ehdokasavain: s. o. koostuu mahdollisimman vähistä attribuuteista
ja on useasta yhtä monesta attribuutista koostuvasta ehdokasavaimesta mahdollisimman lyhyt.
•
Pääavain merkitään relaatiokaavaan alleviivattuna.
•
Attribuutteihin liittyy myös rajoitus siitä, hyväksytäänkö sille puuttuvat arvot ( = null value ). Ellei
näitä sallita, asetetaan attribuutille rajoitukseksi NOT NULL.
5.2.3 Relaatiotietokannat ja niiden tietokantakaavat
•
Relaatiotietokanta koostuu yleensä useista relaatioista, jotka edustavat joko entiteettiä tai niiden
välisiä suhteita.
•
Relaatiotietokannan kaava S muodostuu tietokantaan kuuluvien relaatioiden kaavoista eli
S = { R1, R2, ..., Rm } sekä eheysrajoituksista ( =integrity constraint = IC ).
•
S:n mukaisen relaatiotietokannan tila ( = relational database state ) on relaatioiden tilojen joukko
{ r1, r2, ..., rm } siten, että jokainen ri on Ri:n sellainen tila, että se täyttää tietokannan
eheysvaatimukset.
•
Tarkastellaan kirjan esimerkkiä 5.5, joka esittää yrityksen tietokannan kaavaa.
•
Tarkastellaan esimerkkiä 5.6 yrityksen tietokannan tietynhetkisestä tilasta. Tähän esimerkkiin
viitataan jatkossa erittäin usein. Kirjan kolmannessa painoksessa samainen esimerkki on
numeroltaan 7.6.
•
Saman relaatiotietokannan eri tauluissa samaan taustalla olevan reaalimaailman käsitteeseen
voidaan viitata useilla eri nimillä ( esimerkiksi sekä DNUMBER että DNO tarkoittavat sisällöllisesti
osaston numeroa ).
•
Vastaavasti samannimisen attribuutin esiintyminen kahdessa ( tai useammassa ) taulussa ei takaa,
että ne edustaisivat tulkinnallisesti samaa reaalimaailman objektia. Esimerkiksi sekä osaston että
henkilön nimeä voisi kuvata attribuutti NAME.
•
Saman relaation sisällä voi olla useita attribuutteja, jotka viittaavat samaan reaalimaailman
kohteeseen, mutta tällöin niiden roolit ovat erilaiset ( esimerkiksi henkilö ja hänen esimiehensä ).
•
Eheysrajoitusten ( = arvoalue- ja avaimeen liittyvät rajoitukset ) oletetaan olevan voimassa kaikissa
tietokannan tiloissa.
5.2.4 Entiteetin eheys, viite-eheys ja vierasavaimet
•
Entiteetin eheysrajoitus merkitsee, ettei pääavaimen arvo saa olla puuttuva; muutoin ei sen
avulla pystyttäisi tunnistamaan tietueita yksikäsitteisesti, jos puuttuvaa arvoa esiintyisi ainakin
kahdella tietueella.
•
Viite-eheysrajoituksen ( = referential integrity constraint ) tarkoituksena on ylläpitää
tietokannan kahden taulun välistä konsistenssia.
•
Mikäli relaatiossa esiintyy attribuutti, joka viittaa jossakin toisessa taulussa olevaan attribuuttiin,
pitää ensimmäisen taulun attribuutin arvon olla edustettuna jossakin toisen taulun tietueessa.
•
Tarkastellaan kirjan esimerkkiä 5.6: työntekijän osastonumerona voi esiintyä ainoastaan
sellainen numero, jota vastaava osasto on olemassa relaatiotaulussa, joka kuvaa osastojen
tietoja.
•
Määritellään seuraavaksi viite-eheyteen kiinteästi liittyvä vierasavaimen käsite relaatioiden R1
ja R2 välille:
R1:n relaatiokaavassa esiintyvä attribuuttien joukko FK, joka viittaa relaatioon R2, on R1:n
vierasavain ( = viiteavain, referenssiavain ) , jos seuraavat kriteerit toteutuvat:
1. FK:hon kuuluvilla attribuuteilla on samat arvoalueet relaation R2 pääavaimen attribuuttien
PK kanssa, eli FK:n attribuutit viittaavat relaatioon R2.
2. FK:n arvo tuplassa t1i, joka kuuluu relaation R1, joko esiintyy jonkin tuplan t2j pääavaimen
arvona relaatiossa R2, tai muutoin FK:n arvo on puuttuva ( =null ). Toisin sanoen,
jokaiselle i:lle, missä i  [1, tietueiden määrä R1:ssä] on voimassa joko t1i[FK]=t2j[PK],
missä j  [1, tietueiden määrä R2:ssa], tai t1i[FK] = null.
•
Tietokannassa, joka koostuu monesta relaatiosta, esiintyy yleensä useita viittauksia taulusta
toiseen. Viittauksia muodostettaessa pitää olla selkeä kuva siitä, missä roolissa kumpikin
viiteyhteyteen osallistuva attribuutti (attribuuttien yhdistelmä) esiintyy.
•
Tarkastellaan esimerkin 5.6 viiteyhteyttä henkilön osastonumeron ja osastorelaation
pääavaimen välillä: henkilörelaation osastonumeroa vastaava tietue pitää löytyä
osastorelaatiosta. Selvästikin henkilötaulun kenttä DNO on nyt osastotaulun DNUMBER
kenttään viiteyhteydessä oleva vierasavain.
•
Vierasavaimen arvo voi olla myös puuttuva: olisi periaatteessa mahdollista, ettei työntekijä
olisi kirjoilla millään osastolla.
•
Vierasavain voi viitata myös samaan tauluun. Tällainen tilanne voi syntyä, kun on olemassa
yhteys kahden saman entiteettityypin edustajan välillä ( esimerkiksi työntekijä-esimies
–suhde ). Esimerkissä 5.6. henkilön John Smith esimieskentän arvo on 333445555, mikä
viittaa henkilöön nimeltä Franklin Wong: viimeksi mainittu on edellä mainitun esimies.
•
Vierasavaimet voidaan merkitä näkyviin tietokannan kaavaan merkitsemällä vierasavainkentästä
lähtevä nuoli sen relaatiotaulun siihen attribuuttiin, johon vierasavain on viiteyhteydessä ( kts. kirjan
esimerkki 5.7 ).
•
Useimmat tietokannan hallintajärjestelmät tukevat avaimeen liittyviä ja entiteetin eheysrajoituksia,
monet lisäksi tukevat viite-eheysrajoituksia. Nämä ovat osa datan määrittelyä.
5.2.5 Muita rajoitustyyppejä
•
Edellisten rajoitusten lisäksi voidaan asettaa tietokannalle vielä ns. semanttisia eheysrajoituksia,
kuten estää mahdollisuus, että työntekijä tekisi kaikkiin projekteihin työtunteja yhteensä enemmän
kuin 56 viikkoa kohti, työntekijän palkan korottaminen ohi hänen esimiehensä palkan jne.
•
Semanttisia eheysrajoituksia varten käytetään ns. rajoitusten määrittely-kieltä ( constraint
specification language ), joka sisältää ns. liipaisimia ( triggers ) ja määräyksiä ( assertions ).
•
Edellä esitetyt rajoitukset olivat ns. tilaan liittyviä rajoituksia, koska ne määräävät laillisen tilan, jota
tietokanta voi noudattaa. Näistä käytetään myös nimitystä staattiset rajoitukset.
•
Yhtenä rajoituksen lajina voidaan pitää myös ns. funktionaalista riippuvuutta X ---> Y, missä sekä X
että Y ovat attribuuttien yhdistelmiä. Merkintä tarkoittaa, että attribuuttiyhdistelmän X arvo määrää
yksikäsitteisesti attribuuttiyhdistelmän Y saaman arvon kyseisessä relaatiossa.
•
Funktionaalisia riippuvuuksia tarkastellaan enemmälti luvussa 10, eli tietokannan normalisoinnin
yhteydessä.
•
Lisäksi on olemassa ns. siirtymärajoituksia ( transition constraints ), jotka kuvaavat, miten
tietokannan tila voi muuttua joidenkin attribuuttien kohdalla. Esimerkiksi voitaisiin vaatia, että
kuukausipalkkaa ei milloinkaan voida pienentää. Näitä kutsutaan myös ns. dynaamisiksi rajoituksiksi.
5.3 Päivitysoperaatiot ja toiminta yritettäessä rikkoa rajoituksia
•
Päivitysoperaatioihin lasketaan kuuluviksi tuplan lisäys, tuhoaminen ja sisällön muuttaminen.
•
Tarkastellaan seuraavaksi kutakin operaatiota erikseen tarkastelemalla arvoalueen ja avaimen
rajoituksia sekä entiteetin ja viite-eheysrajoituksia.
5.3.1 Lisäysoperaatio
•
Lisäysoperaatiossa ( Insert ) lisätään uusi tupla relaatioon.
•
Lisääminen voi rikkoa mitä tahansa tarkastelemistamme neljästä rajoituksesta, sillä
o
Jonkin attribuutin arvo voi olla laiton, eli väärää tietotyyppiä tai sallitun arvoalueen ulkopuolella.
o
Avainrajoitusta rikotaan, jos lisättävän tuplan avainkentän arvo esiintyy jo jossakin toisessa
tuplassa relaation nykytilassa r( R ).
o
Entiteetin eheysrajoitusta rikotaan, mikäli lisättävällä tuplalla avainattribuutin arvo on puuttuva.
o
Viite-eheyttä rikotaan, mikäli lisättävän tuplan vierasavaimen ei-puuttuvalle arvolle ei löydy
vastinetta sen relaation pääavaimesta, mihin vierasavain viittaa.
•
Tarkastellaan kirjan sivulla 141 olevia esimerkkejä, joissa henkilötauluun yritetään sijoittaa neljää
erilaista uutta tuplaa.
•
Toipumistapoja sääntöjen rikkomisesta: lisäyksen peruuttaminen, syötetietojen korjaaminen sekä
lisäyksen vyöryttäminen ( = cascade ).
•
o
Peruuttaminen: tietueen lisäysyritys torjutaan suoralta kädeltä. Tällöin olisi hyödyllistä
ilmoittaa käyttäjälle, minkä tähden operaatio epäonnistui. Peruuttamista ei tosin sovelleta
usein lisäysten yhteydessä.
o
Syötetietojen korjaaminen: annetaan käyttäjälle mahdollisuus muuntaa alun perin annettu
tupla kelvolliseksi tekemällä tarpeelliset muutokset ( esimerkissä tarjottaisiin mahdollisuutta
antaa laillinen arvo SSN- tai DNO-kentälle ).
o
Vyörytys: syötetietojen korjaaminen voi aiheuttaa jatkotoimenpiteitä toisaalla. Menettelyä
jatketaan niin pitkään kuin se on tarpeen.
Esimerkki: Syötetään alun perin laiton osastonumero henkilölle. Tällöin voidaan antaa käyttäjälle
tilaisuus joko syöttää osastonumero uudelleen tai käydä perustamassa kyseinen
osastotietue. Jos valitaan jälkimmäinen, ja osastolle annetaan johtajan koodiksi
tunnus, joka ei ole minkään henkilön henkilötunnus, voidaan päivityksiä vyöryttää
takaisin työntekijätauluun.
5.3.2 Tuhoamisoperaatio
•
Tuplan poistamista varten asetetaan kriteeri, jonka mukaisesti poisto kohdistetaan tarkoitettuihin
tupliin.
•
Tuplan poistaminen voi rikkoa viite-eheyttä, mikäli jokin toinen tietokannan tuplista viittaa siihen.
•
Tarkastellaan kirjassa sivulla 142 olevia esimerkkejä, jotka perustuvat kaikki kuvan 5.6 mukaiseen
yrityksen tietokannan tilaan ( operaatiot eivät siis ole perättäisiä ):
1.
Relaatiosta WORKS_ON yritetään poistaa tupla, jossa ESSN = '999887777' ja PNO = '10'.
----> Tämä onnistuu, sillä mihinkään poistettavan tietueen kenttään ei kohdistu viitettä toisaalta.
Poiston tulkintana on, että työntekijä nimeltä Alicia Zelaya lopettaa työskentelynsä
projektissa 10.
2. Yritetään poistaa relaatiosta EMPLOYEE tupla, jossa ESSN = '999887777'.
----> Poisto rikkoisi viite-eheyttä, sillä kyseinen henkilö ( Alicia Zelaya ) on vielä töissä kahdessa
projektissa, ja poistettavan henkilön projekteissa toimimista kuvaavat tietueet jäisivät siten
irrallisiksi tietokantaan. Relaatiossa WORKS_ON toimii kenttä ESSN vierasavaimena
relaatiolle EMPLOYEE, joten viite-eheyden säilyvyys pitää tarkastaa.
3.
Yritetään poistaa relaatiosta EMPLOYEE tupla, jossa ESSN = '333445555'.
----> Poisto aiheuttaisi melkoisesti harmia, sillä kyseiseen henkilöön ( Franklin Wong ) viitataan
sekä relaatioissa WORKS_ON, DEPARTMENT, EMPLOYEE että DEPENDENT. Franklin Wong
työskentelee peräti neljässä projektissa, johtaa osastoa 5, toimii kolmen työntekijän
esimiehenä, ja lisäksi hänellä on kolme perheenjäsentä!
•
Toipumistapoja rikottaessa rajoituksia tuplan poistamisen Estäminen: estetään tietueen poistaminen.
o
Tuhoamisen vyörytys: Poistetaan kaikki tuplat, joissa viitataan poistettavaan tuplaan. Tämä
toimisi hyvin esimerkissä 2, jossa Alicia Zelaya lähtee pois yrityksestä, koska hän ei toimi
yrityksessä esimiesasemassa.
o
Vierasavainten päivittäminen: jos viittauksen kohteena oleva tupla poistetaan, muutetaan
siihen viittaavat vierasavaimet kelvollisiksi arvoiksi tai asetetaan ne puuttuviksi ( = null ).
Puuttuvaksi kenttää ei kuitenkaan saa asettaa, mikäli vierasavain toimii samalla relaationsa
pääavaimen osana.
o Vierasavainten päivittäminen: jos viittauksen kohteena oleva tupla poistetaan,
muutetaan siihen viittaavat vierasavaimet kelvollisiksi arvoiksi tai asetetaan ne
puuttuviksi ( =null ). Puuttuvaksi kenttää ei kuitenkaan saa asettaa, mikäli vierasavain
toimii samalla relaationsa pääavaimen osana.
•
Eri toipumistapoja voidaan myös kombinoida.
Esimerkiksi työntekijän lopettaessa työt yrityksessä voitaisiin hänen osallistumistietonsa eri
projekteihin poistaa saman tien. Jos henkilö toimii lisäksi osaston johtajana, voidaan kenttään
Osaston_johtaja asettaa arvo 'null' tai sijoittaa poistuneen henkilön hetun tilalle jonkin toisen
henkilön hetu. Samaa menettelyä voitaisiin käyttää esimieskentälle EMPLOYEE-taulussa.
•
Sitä vastoin olisi varsin outo ja epätarkoituksenmukainen ratkaisu lopettaa koko osaston toiminta
sen johtajan lopettaessa työt ja/tai antaa lopputili kaikille johtajan alaisille!
5.3.3 Muutosoperaatio
•
Muutosoperaatio muuttaa tuplan yhden tai useamman attribuutin arvoa.
•
Mikäli muutos kohdistuu muuhun kuin pääavain- tai vierasavainattribuuttiin, ei operaatio yleensä
aiheuta hankaluuksia: välttämättä ei tehdä muuta kuin tarkastetaan arvoalueen ja tyypin
oikeellisuus.
•
Pääavaimen arvon muuttaminen ei ole (yleensä) järkevää, sillä se voitaisiin tulkita aikaisemman
tietueen poistamiseksi ja samalla uuden lisäämiseksi.
•
Vierasavainattribuutin päivittäminen edellyttää, että kentän uusi arvo on viite-eheyden säilyvyyden
kannalta hyväksyttävä.
•
Tarkastellaan lopuksi kirjan sivulla 143 olevia esimerkkejä muutosoperaatioista.
6. Relaatioalgebra ja relaatiokalkyyli
•
Relaatioalgebra pitää sisällään relaatiotietokantamallin perusoperaatiot.
•
Relaatioalgebran avulla voidaan tietokantaan kohdistaa kyselyitä.
•
Kyselyiden tuloksiksi saadaan uusia relaatioita, joita voidaan käyttää hyväksi myöhemmissä
kyselyissä.
•
Relaatioalgebran operaatiot voidaan jakaa karkeasti kahteen ryhmään:
•
1.
Matemaattiset joukko-opilliset operaatiot, joihin kuuluvat joukkojen
unioni, leikkaus, erotus ja karteesinen tulo. Nämä ovat käyttökelpoisia, koska relaatiot määriteltiin edellä tuplien joukoksi.
•
2.
Erityisesti relaatiotietokantoja varten määritellyt operaatiot, joita ovat
muun muassa valinta, projektio ja liitos.
6.1 Unaariset relaatio-operaatiot: valinta ja projektio
•
Relaatio-operaation unaarisuudella tarkoitetaan sitä, että kyseiseen operaatioon osallistuu
kerrallaan vain yksi relaatio ( vrt. binäärisyys, ternäärisyys jne. ).
6.1.1 Valintaoperaatio
•
Valintaoperaatiolla ( = select ) pystytään relaatiosta suodattamaan tietyn valintaehdon täyttävät
tietueet ( esimerkiksi henkilöt, jotka ovat kirjoilla osastolla 4 ).
•
Valintaehdossa voi esiintyä vakioarvoja, attribuuttien nimiä ja matemaattisia operaattoreita { =, , <,
>, ,  }. Ehtoja voidaan yhdistää toisiinsa loogisilla operaattoreilla AND, OR ja NOT.
•
Mikäli vertailua tehdään kentän mukaan, joka on lueteltua tyyppiä (esimerkiksi värien nimet), vain
yhtä- ja erisuuruusvertailut ovat mahdollisia.
•
Merkkijonoille on käytettävissä vielä erikoisoperaattoreita, kuten merkkijonon toisen merkkijonon
osajonona esiintymisen testaus ( SUBSTRING_OF ). Valinnasta käytetään relaatioalgebrassa
symbolia σ.
•
Valintaoperaatio merkitään yleisesti:
σ<valintaehto>(R), missä valintaehto on muotoa
<attribuutin nimi> <vertailuoperaattori> <vakio> tai
<attribuutin nimi> <vertailuoperaattori> <attribuutin nimi>
•
Valintaehtoa testataan jokaiselle relaation R tuplalle niiden attribuuttien osalta, joita valintaehdossa
esiintyy.
•
Esimerkkejä valintaoperaatioista:
σDNO = 4( EMPLOYEE ) : valitsee osaston 4 työntekijät
σSALARY > 30000( EMPLOYEE ) : valitsee ne työntekijät, joiden palkka on yli 30000 €.
σ(DNO = 4 AND SALARY > 25000) OR ( DNO = 5 AND SALARY > 30000)( EMPLOYEE ):
valitsee osastolla 4 olevat yli 25000 € palkatut ja osastolla 5 olevat yli 30000 €:n palkatut työntekijät.
•
Tarkastellaan kirjan esimerkin 6.1 a)-kohtaa.
•
Valinnan tuloksena saatavan relaation aste on sama kuin sen relaation, johon valinta on kohdistettu
( = R ). Toisin sanoen, valinnan tulosrelaatio sisältää kaikki samat attribuutit kuin sen kohderelaatio.
•
Tulosrelaatiossa tuplien määrä on korkeintaan yhtä suuri kuin tuplien määrä kohderelaatiossa.
•
Tulosrelaation tuplien lukumäärän suhdetta kohderelaation tuplien määrään kutsutaan valintaehdon
selektiivisyydeksi.
•
Valintaoperaatio on kommutatiivinen, eli
σ<ehto1>( σ<ehto2>( R ) ) = σ<ehto2>( σ<ehto1>( R ) ).
Tämä tarkoittaa sitä, että perättäiset n valintaa voidaan koota yhdeksi valinnaksi, jossa esiintyy n-1
kappaletta JA-operaattoreita osaehtojen välillä.
6.1.2 Projektio-operaatio
•
Toisin kuin valintaoperaatio valitsi relaatiosta tuplia ( = rivejä ), projektio (= project ) valitsee
attribuutteja ( = sarakkeita ).
•
Projektiolla pystytään valitsemaan relaatiosta tarkalleen ne sarakkeet, joista ollaan kiinnostuneita.
•
Projektiota kuvaa relaatioalgebrassa merkintä .
•
Projektio-operaatio merkitään yleisesti tapaan
<attribuuttilista>( R ).
•
Tulosrelaatiossa esiintyy relaation R attribuuteista tarkalleen ne, jotka esiintyvät attribuuttilistassa, ja
kenttien esiintymisjärjestys tulosrelaatiossa on attribuuttilistassa annetun mukainen.
•
Mikäli tulosrelaatioon ilmestyy samansisältöinen tupla useammin kuin kerran, moninkertaiset
esiintymät hävitetään tuloksesta, jotta tulosrelaationkin tuplat voitaisiin mieltää joukoksi.
•
Projektion tulosrelaation tuplien määrä on korkeintaan yhtä suuri kuin sen kohderelaation R tuplien
määrä. Jos projektion attribuuttilista sisältää R:n superavaimen, tietueita esiintyy tulosrelaatiossa
yhtä monta kuin R:ssä.
•
Esimerkkejä projektioista:
LNAME, FNAME, SALARY(EMPLOYEE) : valitsee tulosrelaatioon relaation EMPLOYEE attribuutit LNAME, FNAME
ja SALARY.
SALARY, FNAME, LNAME(EMPLOYEE) : kuten edellinen, mutta kenttien järjestys tulosrelaatiossa on eri.
•
Projektio ei ole kommutatiivinen, sillä
<attribuuttilista1>( <attribuuttilista2>( R ) ) = <attribuuttilista1>( R ),
ja tämäkin pitää paikkansa vain, jos attribuuttilista2 sisältää kaikki attribuuttilistassa1 esiintyvät
attribuutit. Muutoin vasemmanpuoleinen projektioilmaus on virheellinen.
•
Tarkastellaan kirjan esimerkin 6.1 b)- ja c)-kohtia.
6.1.3 Perättäiset operaatiot ja uudelleennimeäminen: RENAME-operaatio
•
Jokainen relaatioalgebralla muodostettu tulosrelaatio voidaan tarvittaessa nimetä ( aikaisemmissa
esimerkeissä näin ei toimittu ).
•
Ellei operaatiojonoa haluta kirjoittaa yhdeksi ketjutetuksi operaatioksi, on nimeämistä käytettävä
välitulosten säilömiseksi. Välitulosrelaatiolle annetaan tällöin jokin sopiva nimi, joka kuvaa
välituloksen tulkintaa ( esimerkiksi OSASTONJOHTAJAT ).
•
Esimerkki: halutaan etsiä tutkimusosastolla työskentelevien henkilöiden etu- ja sukunimi sekä
palkka
----> tarvitaan avuksi sekä valinta että projektio.
Ketjutettuna yhdeksi operaatioksi saataisiin muoto
FNAME, LNAME, SALARY( DNO = 5( EMPLOYEE ) ).
Sisempi, valintaoperaatio, valitsee kaikki osaston 5 työntekijät kaikkine attribuutteineen. Ulompi,
projektio, pudottaa tuloksesta tarpeettomat attribuutit pois.
•
Toinen vaihtoehto olisi antaa sisemmän operaation tulokselle nimi, vaikkapa OSASTOLLA5. Tällöin
saadaan:
OSASTOLLA5 <-- DNO=5( EMPLOYEE )
TULOS <-- FNAME, LNAME, SALARY( OSASTOLLA5 ).
•
Haluttaessa voidaan myös tulosrelaation attribuutit nimetä uudelleen. Tästä on hyötyä esimerkiksi
unioni- ja liitosoperaatioita muodostettaessa. Tällöin pitää tulosrelaation nimen perään esitellä
sulkujen sisällä uudet attribuuttinimet tulosrelaatiolle.
Esimerkki: TULOS( ETUNIMI, SUKUNIMI, PALKKA )
<---- FNAME, LNAME, SALARY( OSASTOLLA5 ).
•
Tarkastellaan kirjan esimerkkiä 6.2.
•
Uudelleennimeämisoperaattoria  voidaan käyttää tarpeen mukaan kuten valinta- ja projektiooperaattoreitakin. Samalla kerralla voidaan haluttaessa nimetä sekä tulosrelaatio että attribuutit.
S(B1, B2, ..., Bn)( R ) - nimeää sekä tulosrelaation että sen attribuutit
S( R )
- nimeää ainoastaan tulosrelaation
(B1, B2, ..., Bn)( R ) - nimeää ainoastaan tuloksen attribuutit
6.2 Joukkoteoreettiset operaatiot
6.2.1 Unioni-, leikkaus- ja erotusoperaatiot
•
Unionioperaation avulla voidaan kahteen relaation kuuluvat tuplat yhdistää.
•
Unionioperaattorista käytetään merkintää .
•
Esimerkki: halutaan löytää niiden henkilöiden henkilötunnukset, jotka ovat itse töissä osastolla 5
tai toimivat jonkin osastolla 5 työskentelevän henkilön välittömänä esimiehenä.
1. Etsitään osaston 5 työntekijät
OSASTOLLA5 = σDNO = 5( EMPLOYEE )
2. Poimitaan osaston 5 työntekijöiden hetu (haetun vastauksen ensimmäinen osa):
TULOS1 <-- SSN( OSASTOLLA5 )
3. Etsitään osastolla 5 työskentelevien henkilöiden esimiehet (haetun vastauksen toinen osa):
TULOS2 <-- SUPERSSN( OSASTOLLA5 )
4. Yhdistetään kohtien 2 ja 3 tulokset:
TULOS <-- TULOS1  TULOS2
•
Unionin tulosrelaatiosta hävitetään duplikaatit saman tuplan kuuluessa molempiin osatuloksiin.
•
Tarkastellaan kirjan esimerkkiä 6.3. Unioni on binäärinen operaatio, s. o. kahden relaation R ja S
välinen, eli R  S.
•
Unioniin osallistuvien relaatioiden R ja S tuplien pitää olla tyypiltään yhteensopivia, eli R:n ja S:n
asteluvut ovat samat ja jokaista i:n arvoa kohti dom( Ai ) = dom( Bi ), kun 1  i  n, ja Ai:t viittaavat
R:n ja Bi:t S:n attribuutteihin.
•
Tyyppien yhteensopivuusvaatimus koskee unionin lisäksi myös leikkaus- ja erotusoperaatioita.
•
Relaatioiden R ja S leikkaukseen R  S kuuluvat tuplat, jotka kuuluvat sekä R:ään että S:ään.
Relaatioiden erotukseen R - S kuuluvat puolestaan tuplat, jotka löytyvät relaatiosta R mutta eivät
relaatiosta S.
•
Mikäli unioniin, leikkaukseen tai erotukseen osallistuvien relaatioiden R ja S vastinattribuutit ovat
erinimiset, käytetään sopimuksen mukaisesti tulosrelaatiossa relaation R mukaista nimeämistä.
•
Tarkastellaan kirjan esimerkkiä 6.4.
•
Unioni ja leikkaus ovat kommutatiivisia ( vaihdannaisia ) ja lisäksi myös assosiatiivisia ( liitännäisiä )
operaatioita.
•
Erotus ei ole kommutatiivinen, joten yleensä R - S  S - R.
6.2.2 Karteesinen tulo -operaatio
•
Karteesinen tulo R x S ( ristitulo, ristiliitos ) on myös binäärinen operaatio, mutta siihen osallistuvien
relaatioiden ei tarvitse olla tyypiltään yhteensopivia.
•
Karteesisessa tulossa jokainen R:n tietue yhdistetään jokaisen S:n tietueen kanssa siten, että
tulosrelaatiossa S:n attribuutit liitetään R:n attribuuttien jatkeeksi. Jos R:n asteluku on n ja S:n
asteluku on m, on R x S:n asteluku n + m. Vastaavasti, jos R:ssä on tuplia nR kappaletta ja S:ssä
vastaavasti nS kappaletta, tällöin tulosrelaatio R x S sisältää nR * nS tuplaa järjestyksessä r1s1, r1s2,
..., r1sm, r2s1, r2s2, .., r2sm, ..., rns1,rns2, ..., rnsm. Karteesinen tulo on sinänsä yleensä hyödytön,
mutta sille saadaan käyttöä kohdistamalla siihen valintaoperaatioita.
•
Esimerkki: halutaan löytää kaikkien naispuolisten työntekijöiden perheenjäsenet. Hyödyntämällä
karteesista tuloa voitaisiin suorittaa seuraavat perättäiset operaatiot:
1. NAISPUOLISET_TYÖNTEKIJÄT <-- SEX = 'F'( EMPLOYEE )
2. NAISP_TT_NIM <-- FNAME, LNAME, SSN( NAISPUOLISET_TYÖNTEKIJÄT )
3. KAIKKIEN_TYÖNTEK_PERHEENJ <-- NAISP_TT_NIM x DEPENDENT
4. ETSITT_PERHEENJ <-- SSN=ESSN( KAIKKIEN_TYÖNTEK_PERHEENJ )
5. TULOS <-- FNAME, LNAME, DEPENDENT_NAME( ETSITT_PERHEENJ )
•
Tarkastellaan kirjan esimerkkiä 6.5.
•
Käytännössä edellisen esimerkin kaltaisissa tilanteissa käytetään karteesisen tulon sijasta
liitosoperaatiota.
6.3 Binääriset relaatio-operaatiot: liitos ja jakolasku
6.3.1 Liitosoperaatio
•
Liitosoperaatiolla ( join operation ) voidaan yhdistää eri relaatioissa sijaitsevia tuplia toisiinsa.
•
Tietokannoissa, joissa esiintyy useita relaatioita, liitosoperaatio toimii tärkeänä tiedon linkittäjänä
taulujen välillä.
•
Kahden relaation R( A1, A2, ... An ) ja S( B1, B2, ..., Bm ) välinen liitosoperaatio on yleisesti muotoa:
RX<liitosehto>S, missä liitosehto koostuu perättäisistä JA-operaatioista, ja se on muotoa Ai  Bj, missä
Ai on R:n ja Bj S:n attribuutti, joiden arvoalueet ovat samat, ja  on jokin operaattoreista { =, <,
>,
, ,  }. Jos liitokseen osallistuvassa relaatiossa R on n ja relaatiossa S on m attribuuttia, on
tulosrelaatiossa m + n attribuuttia ( liitosattribuutti esiintyy kahdesti ).
•
Mikäli liitosattribuutin arvona on NULL, kyseinen tupla ei tule valituksi liitoksen tulosrelaatioon.
Esimerkki: etsitään kaikkien niiden työntekijöiden nimet, jotka toimivat jonkin osaston johtajina.
JOHTAA_OS <-- DEPARTMENTXMGRSSN = SSNEMPLOYEE
TULOS <-- DNAME, LNAME, FNAME( JOHTAA_OS )
Liitos tehdään osaston vierasavainkentän MGRSSN mukaan, joka viittaa työntekijärelaatioon.
•
Tarkastellaan kirjan esimerkkiä 6.6.
6.3.2 Liitosoperaation kaksi erikoistapausta: luonnollinen liitos ja yhtäsuuruusliitos
•
Kun liitosehdossa esiintyy muitakin kuin yhtäsuuruusoperaattoreita, käytetään liitoksesta nimitystä
theta-liitos, muutoin kyseessä on yhtäsuuruusliitos ( = equijoin ).
•
Haluttaessa olla toistamatta liitosattribuuttia voidaan käyttää ns. luonnollista liitosta ( natural join ),
joka hävittää liitosehtoattribuuttien duplikaatit tuloksesta.
•
Standardin mukaisessa luonnollisessa liitoksessa liitosattribuuttien nimien pitää olla kummassakin
relaatiossa samat. Esimerkiksi tehtäessä luonnollinen liitos projektin ja osaston välille pitäisi
osastonumeroa kuvaava attribuutti muuntaa osastorelaatiossa projektin vastaavan kentän nimiseksi
( tai päinvastoin ).
•
Esimerkki: OS_PROJ <-- PROJECT * (DNAME, DNUM, MGRSSN, MGRSTARTDATE)( DEPARTMENT )
•
Nimeäminen ei tietystikään ole tarpeen, jos liitosattribuutit ovat jo alun perin saman nimiset
( vrt. luonnollinen liitos osaston ja sen toimipisteiden välillä ).
•
Epästandardissa esityksessä voidaan luonnollisen liitoksen liitosattribuutit esittää kahtena listana,
joiden pareittaisten attribuuttien arvojen pitää vastata toisiaan. Liitosattribuuteista ainoastaan
1. listan attribuutit näkyvät tuloksessa. Epästandardi esitys on muotoa:
Q <--- R *(<lista1>),(<lista2>)S
•
Ellei yksikään tuplien yhdistelmä täytä liitosehtoa, tulokseksi saadaan tyhjä relaatio.
•
Jos puolestaan kaikki yhdistelmät toteuttavat liitosehdon tai liitosehto puuttuu kokonaan, tuloksena
on karteesinen tulo, jolloin tuplia ilmestyy tulosrelaatioon nr * ns kappaletta.
•
Liitoksen selektiivisyyttä mittaa tulosrelaation tuplien ja karteesisen tulon tuplien lukumäärän
suhde.
•
Liitokseen voi osallistua kerralla myös useampia kuin kaksi relaatiota.
•
Esimerkki: Etsitään kullekin projektille sitä kontrolloivan osaston tiedot, ja tälle edelleen osaston
johtajan tiedot.
( ( PROJECT
XDNUM = DNUMBERDEPARTMENT
) XMGRSSN = SSNEMPLOYEE )
6.3.3 Relaatioalgebran operaatioiden täydellinen joukko
•
Voidaan todistaa, että kaikki relaatioalgebran operaatiot voidaan esittää operaatioiden
{ , , , -, x } avulla. Täten kyseisten operaatioiden joukko on täydellinen.
•
Esimerkiksi leikkaus voitaisiin esittää kahden joukon unionin ja niiden molempiensuuntaisten
erotusten unionin erotuksena:
RS(RS)-((R-S)(S-R))
•
Kuitenkin, leikkausoperaatio on sen verran yleinen, että sen esittäminen unionin ja erotuksen
avulla olisi turhan työlästä käytännössä.
•
Samoin liitos voitaisiin esittää karteesisen tulon ja valinnan yhdistelmänä:
R
X<liitosehto>S
 <valintaehto> ( R x S )
•
Edelleen, luonnollinen liitos voitaisiin esittää karteesisena tulona, jota edeltää
uudelleennimeäminen ja operaatiot valinta ja projektio.
•
Myös seuraavaksi esiteltävä jakolaskuoperaatio ( division ) voitaisiin esittää projektion ja
karteesisen tulon avulla.
6.3.4 Jakolaskuoperaatio
•
Jakolaskuoperaatiota tarvitaan, kun tulosrelaatioon halutaan tietueita, joilla on kaikki samat
tarkastelun kohteena olevat ominaisuudet kuin jollain tietyn entiteettityypin yksittäisellä edustajalla.
•
Tarkastellaan esimerkin 6.8 a)-kohtaa, jossa halutaan löytää ne henkilöt, jotka työskentelevät
kaikissa niissä projekteissa, joissa John Smith työskentelee.
1. Selvitetään John Smithin henkilötunnus
SMITH <-- FNAME='John' AND LNAME='Smith'( EMPLOYEE )
2. Tutkitaan, missä projekteissa hän työskentelee.
SMITH_PNOS <-- PNO( WORKS_ONXESSN = SSNSMITH )
3. Projisoidaan WORKS_ON -taulusta henkilötunnus ja projektinumero.
SSN_PNOS <-- ESSN, PNO( WORKS_ON )
4. Suoritetaan jakolasku SSN_PNOS  SMITH_PNOS, joka jättää jäljelle ne
henkilötunnukset, joilla esiintyy SSN_PNOS -välituloksessa kaikki ne
projektinumerot kuin John Smithillä.
SSNS( SSN ) <-- SSN_PNOS  SMITH_PNOS
5. Muodostetaan 4. kohdan tulosrelaation luonnollinen liitos työntekijätaulun kanssa,
niin saadaan valmista.
TULOS <-- FNAME, LNAME( SSNS * EMPLOYEE )
•
Kahden relaation R ja S välinen jakolaskuoperaatio R  S on mahdollinen silloin, kun
S:n attribuutit ovat R:n attribuuttien (aito) osajoukko.
•
Oletetaan, että R:ään kuuluvien attribuuttien joukko on Z ja S:ään kuuluvien
attribuuttien joukko on X. Tällöin jakolaskun tuloksen T attribuuttien joukko Y sisältää
ne Z:n attribuutit, joita ei esiinny X:ssä, eli Y = Z - X.
•
Jotta tupla t kuuluisi relaatioiden R ja S jakolaskun tulosrelaatioon T, pitää relaatiossa
R esiintyä jokaista S:n arvoa kohti attribuuttijoukon Y arvona t.
•
Tarkastellaan kirjan esimerkkiä 6.8 b)-kohtaa. Relaatio R sisältää attribuutit A ja B, ja relaatio S
attribuutin A. Tällöin R:n ja S:n jakolaskuun kuuluu yksistään attribuutti B. Koska relaation S ainoa
attribuutti A sisältää arvot a1, a2 ja a3, pitää kutakin A:n arvoa kohti R:stä löytyä vähintään yksi
tupla siten, että näiden tuplien attribuutin B arvo olisi sama. Tällöin kyseisen vaatimuksen täyttävä
B:n arvo esiintyy jakolaskun R  S tulosrelaation T tuplana. Koska R sisältää tuplat ( a1, b1 ),
( a2, b1 ) ja ( a3, b1 ), niin tällöin tupla b1 kuuluu tulosrelaatioon. Vastaavasti, koska R sisältää
tuplat ( a1, b4 ), ( a2, b4 ) ja ( a3, b4 ), myös b4 kelpaa tulosrelaation T tuplaksi. Sen sijaan b2 ja
b3 eivät kelpaa, koska sekä a1, a2 että a3 eivät kaikki muodosta R:ssä tuplaa b2:n eikä b3:n kanssa
( esimerkiksi yhdistelmät ( a2, b2 ) ja ( a1, b3 ) puuttuvat ).
•
Relaatioiden välinen jakolasku korvautuu projektion, karteesisen tulon ja erotuksen avulla
seuraavasti:
T <---- R  S  T1 <---- Y( R )
T2 <---- Y( ( S x T1) - R )
T <--- T1 - T2
6.4 Muita relaatioihin kohdistuvia operaatioita
•
Joitakin relaatiotietokantoihin liittyviä kyselyitä ei pystytä esittämään relaatioalgebran turvin.
•
Tällaiset kyselyt tuottavat ns. koostettua ja ryhmiteltyä tietoa tietokannan ominaisuuksista.
6.4.1 Aggregaattifunktiot ja ryhmittely
•
Toisinaan on tarpeen kohdistaa relaatioon matemaattisten tunnuslukujen laskentaa tai selvittää
tietyn ehdon täyttävien tietueiden tai arvojen lukumäärä.
•
Tähän tarkoitukseen voidaan käyttää ns. aggregaattifunktioita, joista tyypillisimmät ovat summa
( sum ), keskiarvo ( average ), maksimin ( maximum ) ja minimin ( minimum ) määrääminen sekä
lukumäärä ( count ).
•
Aggregaattifunktio esitellään tyyliin
<ryhmittelyattribuutit> F <funktiolista> ( R ),
missä ryhmittelyattribuutit ovat lista R:n attribuutteja, joiden mukaan tietueet halutaan ryhmitellä ja
funktiolista puolestaan koostuu <funktio, attribuutti> -pareista, missä funktio on jokin seuraavista:
SUM, AVERAGE, MAXIMUM, MINIMUM ja COUNT, ja attribuutti puolestaan se, johon kyseinen funktio
halutaan kohdistaa.
•
Tarkastellaan kirjan esimerkkiä 6.9: lasketaan osastokohtainen työntekijämäärä ja heidän
keskipalkkansa, sekä koko yrityksen työntekijämäärä ja keskipalkka.
R(DNO, NO_OF_EMPLOYEES, AVERAGE_SAL) ( DNO F COUNT SSN, AVERAGE SALARY( EMPLOYEE ) )
a)-kohdan operaatiossa on nimetty uudelleen tulostettavat kentät, joista ensimmäinen on
osastonumero ja seuraavat kuvaavat työntekijöiden lukumäärää osastolla ja osastokohtaista
keskipalkkaa.
Uudelleennimeäminen ei kuitenkaan ole välttämätöntä, kuten b)-kohdassa nähdään. Tällöin
aggregaattikenttien nimiksi tulostuvat tyyliin operaatio_attribuutti ( esimerkiksi COUNT_SSN,
AVERAGE_SALARY ).
•
Duplikaatteja ei eliminoida aggregaattifunktioita käytettäessä.
•
Myös aggregaattifunktion tulokseksi saadaan aina relaatio, vaikka se voikin näyttää yksittäiseltä
luvulta ( vrt. kohta c )!
6.4.2 Rekursiiviset sulkeumaoperaatiot
•
Joskus saattaa olla tarpeen soveltaa tietokannan relaatiolle ns. rekursiivista sulkeumaoperaatiota,
jossa tarkastellaan toistuvia riippuvuuksia samaa tyyppiä olevien tuplien välillä.
•
Esimerkiksi kelpaisi työntekijän 'esimiesketjun' selvittäminen: ensiksi lähin esimies, tämän
jälkeen esimiehen lähin esimies jne., kunnes korkeimmalla hierarkiassa olevalla ei enää ole
esimiestä.
•
Relaatioalgebran avulla täydellistä sulkeumaa ei voida ilmaista, mutta tietylle ennalta määrätylle
syvyydelle asti rekursiossa pystytään etenemään.
•
SQL-99:n syntaksi kuitenkin tukee rekursiivista sulkeumaoperaatiota. Tarkastellaan esimerkkiä,
jossa etsitään työntekijät, joiden välitön esimies on James Borg, sekä henkilöt, joiden esimiehen
lähin esimies on James Borg ( ts. James Borgin välittömät tai 'toisen tason alaiset' ).
•
Ensinnä henkilöt, joille Borg on lähin esimies:
BORG <--- SSN( FNAME='James' AND LNAME='Borg'( EMPLOYEE ) )
HLÖ_ESIM( SSN1, SSN2 ) <--- SSN, SUPERSSN( EMPLOYEE )
TULOS1( SSN ) <--- SSN1( HLÖ_ESIM XSSN2=SSN BORG )
Sitten henkilöt, joille TULOS1:n henkilö toimii esimiehenä (toisen asteen alaiset):
TULOS2(SSN) <--- SSN1( HLÖ_ESIM XSSN2=SSN TULOS1 )
Lopuksi yhdistetään välitulokset:
TULOS <--- TULOS1  TULOS2
•
Tarkastellaan tilanteen kehittymistä esimerkin 6.10 avulla.
6.4.3 Ulkoinen liitos
•
Ulkoisiin liitoksiin ( outer join ) tulee valituksi ainakin jommastakummasta relaatiosta R tai S tuplia,
jotka eivät täytä liitosehtoa.
•
Mikäli kaikki ( siis liitosehtoa toteuttamattomatkin ) R:n tuplat halutaan näkyviin, mutta S:n tuplien
pitää täyttää esitetty liitosehto, käytetään ns. vasenta ulkoista liitosta.
•
Jos puolestaan kaikki S:n tuplat halutaan näkyviin, mutta R:n tuplista vain liitosehdon täyttävät
halutaan mukaan tulokseen, käytetään oikeaa ulkoista liitosta.
•
Mikäli sekä R:n että S:n kaikkien tuplien halutaan näkyvän tulosrelaatiossa riippumatta asetetun
liitosehdon toteutumisesta, tarvitaan käyttöön ns. täysi ulkoinen liitos.
•
Vasemmassa ulkoisessa liitoksessa ( merkitään ]X ) S:n attribuutit jäävät puuttuviksi tuplassa R:n
tuplaa t kohti, mikäli tupla t ei täytä liitosehtoa.
•
Oikeassa ulkoisessa liitoksessa ( merkitään
•
Täydessä ulkoisessa liitoksessa ( merkitään ]X|[ ) jäävät tilanteesta riippuen joko R:n tai S:n
attribuutit puuttuviksi, jos liitosehto relaatioiden välillä ei toteudu.
•
Esimerkki: halutaan listata kaikkien työntekijöiden nimet ja niiden jatkeeksi vielä
heidän mahdollisesti johtamansa osaston nimi ( s. o. kaikki työntekijät
tulostetaan väistämättä, ja lisäksi osastotiedot osastojen johtajilta ).
X[
) tilanne on tarkalleen päinvastainen.
Otetaan avuksi vasen ulkoinen liitos:
TILAP <--- ( EMPLOYEE ]XSSN = MGRSSN DEPARTMENT )
TULOS <--- FNAME, MINIT, LNAME, DNAME ( TILAP )
•
Tarkastellaan kirjan kuvaa 6.11, joka esittää edellisen esimerkin tulosrelaatiotaulua.
6.4.4 Ulkoinen unioni
•
Ulkoinen unioni voidaan muodostaa kahden osittain yhteensopivan relaation välille.
•
Tällöin osa kentistä on kummallekin relaatiolle yhteisiä, mutta näiden lisäksi ulkoiseen unioniin
osallistuvissa relaatioissa esiintyy kenttiä, jotka löytyvät vain toisesta ulkoiseen unioniin osallistuvasta
relaatiosta R ja S.
•
Yhteensopivat attribuutit sisältävät kummassakin relaatiossa sen avaimen.
•
Tarkastellaan esimerkkiä: yliopiston opiskelijoilla ja virkamiehillä on yhteisinä kenttinään nimi, hetu ja
laitos. Tämän lisäksi opiskelijoilla voisi olla tallennettuna tieto hänen ohjaajastaan, kun taas
virkamiehillä olisi omana erillisenä attribuuttinaan virka-asema.
Opiskelijoiden ja virkamiesten ulkoiseen unioniin tulisi yhteisten kenttien jatkeeksi kummankin
relaation ei-yhteiset kentät. Jos sama henkilö esiintyy sekä opiskelijana että virkamiehenä, häntä
kuvaavassa tuplassa voi esiintyä ei-puuttuva arvo kaikilla attribuuteilla. Muussa tapauksessa
virkamiehen ohjaajatiedoksi ja opiskelijan virka-asemaksi asetetaan arvo NULL.
•
Ulkoinen unioni vastaa sellaista täyttä ulkoista liitosta, jonka liitosattribuutteina toimivat kaikki siihen
osallistuvien relaatioiden yhteiset attribuutit.
•
Kannattaa huomioida, ettei myöskään relaatioiden tuplien sisältämien arvojen manipulointi esimerkiksi
aritmeettisten operaatioiden avulla ole mahdollista relaatioalgebran avulla.
6.5 Esimerkkejä relaatioalgebran mukaisista kyselyistä
•
Tarkastellaan kirjassa olevia seitsemää esimerkkiä sivuilla 171-173 ( luennolla jaetaan niistä
paperikappale ).
6.6 Tupla - relaatiokalkyyli
•
Relaatioalgebrassa pyrittiin kuvaamaan, miten kyselyn toteuttamiseksi tarvittavat tiedot haetaan
eri relaatioista. Toisin sanoen - relaatioalgebraa voidaan pitää proseduraalisena tietokantakielenä.
•
Relaatiokalkyyleissä puolestaan on tarkoituksena kuvata, mitä tietoja halutaan kyselyssä etsiä.
Siten relaatiokalkyylit voidaan tulkita ei-proseduraalisiksi tietokantakieliksi.
•
Relaatiokalkyyleissä ei kiinnitetä tarkalleen eri ilmausten evaluointijärjestystä toisin kuin
relaatioalgebrassa
•
Relaatioalgebran ilmaisuvoima on identtinen relaatiokalkyylien kanssa. Siten kaikki relaatioalgebran ja
ilmaukset ovat muunnettavissa relaatiokalkyyleillä esitettävään muotoon ja vastaavasti päinvastoin.
•
Relaatiotietokannan kyselykielen sanotaan olevan relationaalisesti täydellinen, mikäli sillä on sama
ilmaisuvoima relaatiokalkyylin kanssa.
•
Monilla relaatiotietokannan varsinaisilla ns. kyselykielillä on kuitenkin tätä suurempi ilmaisuvoima,
koska niihin on lisätty mukaan relaatioalgebraan kuulumattomia piirteitä, kuten koostefunktiot,
ryhmittely ja lajittelu.
6.6.1 Tuplamuuttujat ja arvoaluerelaatiot
•
Tupla-relaatiokalkyyli perustuu ns. tuplamuuttujien määrittelyyn.
•
Tuplamuuttujan arvoalueena käsittää yleensä yksittäisen relaation kaikki esiintymät eli tuplat. Siten
tuplamuuttuja voi saada arvokseen minkä tahansa kyseisessä relaatiossa olevan tuplan.
•
Yksinkertainen tupla-relaatiokalkyylin kysely on muotoa
{ t | EHTO ( t ) },
missä t on tuplamuuttuja ja EHTO ( t ) siihen liittyvä ehdollinen ilmaus.
•
Kyselyn tulokseen päätyvät kaikki ne tuplat, jotka toteuttavat niille esitetyn ehdon.
•
Attribuutteihin kohdistuvat ehdot esitetään käyttämällä pistenotaatiota.
•
Esimerkki:

{ t | EMPLOYEE ( t ) AND t.salary > 50000 }
Valitsee sellaiset työntekijätaulun tuplat, joissa palkka on yli 50000.
•
Myös projektio-operaatio voidaan esittää pistenotaation avulla.
•
Esimerkki: { t.FNAME, t.LNAME | EMPLOYEE ( t ) AND t.salary > 50000 }

•
•
Kuten edellisessä esimerkissä, mutta vain etu- ja sukunimi tulostuvat
Jokaista tuplamuuttujaa t kohti on esiteltävä sen

määrittelyrelaatio R tyyliin R( t ).

ehto, jonka perusteella tuplat kelpuutetaan kyselyn vastaukseen

luettelo attribuuteista, jotka halutaan listata
Esimerkki Q0: Etsitään kaikkien John B. Smith -nimisten työntekijöiden
osoite ja syntymäaika
{ t.BDATE, t.ADDRESS | EMPLOYEE ( t ) AND t.FNAME = 'John' AND t.MINIT = 'B' AND
t.LNAME = 'Smith' }
•
Tuplamuuttujien ja listattavien attribuuttien esittelyosa päättyy pystyviivaan ( | ), jota seuraa
kyselylle asetettava valintaehto.
6.6.2 Ilmaukset ja kaavat tupla-relaatiokalkyylissä
•
Tupla-relaatiokalkyylin yleinen ilmaus on muotoa
{ t1.At1, t2.At2, ..., tn.Atn | EHTO ( t1, t2, ..., tn, tn+1, tn+2, ..., tm ) }, missä
t1, t2, ..., tm ovat tuplamuuttujia, At1, At2, ... Atn ovat lista sen
relaation attribuutteja, joita kukin ti valitsee. Ehto on puolestaan relaatiokalkyylin mukainen
kaava, ja siinä voi esiintyä sellaisiakin tuplamuuttujia, joita ei tarvita lopullisessa tuloksessa.
•
Kaava koostuu predikaattikalkyylin atomeista, jotka ovat jotain seuraavaa muotoa olevia:



R( ti ), missä R on relaation nimi ja ti tuplamuuttuja
ti.A <operaattori> tj.B, missä ti ja tj ovat tuplamuuttuja ja operaattori jokin
vertailuoperaattoreista { =, <, ≤, >, ≥, ≠ } sekä A on jokin tuplamuuttujan ti ja vastaavasti B
jokin tuplamuuttujan tj kohderelaation attribuuteista
ti.A <operaattori> c tai c <operaattori> tj.B, missä ti, tj, A, B ja operaattori ovat kuten edellä
ja c on vakioarvo.
•
Jokainen edeltäneistä atomeista saa totuusarvokseen joko TOSI tai EPÄTOSI kutakin yksittäistä
tuplien kombinaatiota kohti.
•
Yleisesti tuplamuuttuja t vaihtelee ylitse kaikkien käsillä olevien tietokannan tietueiden, ellei sitä
erityisesti rajoiteta edustamaan jotain tiettyä relaatiota R ilmauksella R( t ). Tällöin tuplamuuttujan
totuusarvoksi tulee TOSI tarkalleen kaikilla relaatioon R kuuluvilla tuplilla; muualla t saa arvokseen
EPÄTOSI.
•
Kaava voidaan muodostaa paitsi yksittäisestä atomista niin myös yhdistelemällä atomeja loogisilla
operaattoreilla AND, OR ja NOT. Rekursiivinen määrittely on seuraavanlainen:


•
1. Jokainen atomi on kaava.
2. Jos F1 ja F2 ovat kaavoja, niin myös ( F1 AND F2 ), ( F1 OR F2 ),
NOT( F1 ) ja NOT( F2 ) ovat kaavoja.
Kaavojen totuusarvot määräytyvät normaalin propositiologiikan sääntöjen mukaisesti ( säännöt
kerrataan luennolla, mikäli tarpeen ).
6.6.3 Olemassaolo- ja universaalikvanttori
•
Kaavoissa voi esiintyä atomien ja loogisilla konnektiiveilla toisiinsa liitettyjen kaavojen lisäksi myös
kvanttoreita, joita on kahta lajia: olemassaolo- ( eli eksistenssi- ) ja kaikki- ( eli universaalikvanttori ).
•
Olemassaolokvanttoria merkitään symbolilla (  ), ja universaalikvanttoria edustaa merkintä (  ).
•
Ennen kvanttorien tarkempaa esittelyä määritellään vapaan ja sidotun tuplamuuttujan käsitteet:
•

Tuplamuuttujan t esiintymä atomikaavassa F on vapaa.

Tuplamuuttujan t esiintymä loogisin konnektiivein yhdistetyssä kaavassa tyyppiä
( F1 AND F2 ), ( F1 OR F2 ), NOT( F1 ) tai NOT( F2 ) on vapaa tai sidottu sen mukaan, millainen
sen esiintymä on kaavassa F1 ja F2. On mahdollista, että kaavoissa ( F1 AND F2 ) ja
( F1 OR F2 ) tuplamuuttuja voi esiintyä eri osissa eri asemassa ( esimerkiksi F1:ssä sidottuna ja
F2:ssa vapaana tai päinvastoin ).

Kaikki kaavassa F esiintyvän tuplamuuttujan t esiintymät ovat sidottuja kvanttori-ilmauksissa
F' = (  t )( F ) tai F' = (  t )( F ). Kvanttoria seuraava tuplamuuttuja on aina sidottuna
kvanttorin sen vaikutusalueella.
Esimerkki:
F1: d.OSASTONNIMI = 'TUTKIMUS'
F2: (  t )( d.OSASTONUMERO = t.OSASTONUMERO )
F3: (  d )( d.OSASTONJOHTAJA = '333445555' )

Kaavoissa F1 ja F2 tuplamuuttuja d on vapaa, mutta kaavassa F3 se
on sidottu universaalikvanttoriin.

Vastaavasti tuplamuuttuja t on sidottu olemassaolokvanttoriin kaavassa F2.
•
Olemassaolokvanttorin sisältävä ilmaus on tosi, mikäli ilmauksessa esitetty ehto toteutuu ainakin
yhdelle tarkastelun kohteena olevalle tuplalle.
•
Universaalikvanttorin sisältävä ilmaus on puolestaan tosi silloin ja vain silloin, kun kvanttoriilmauksen ehto toteutuu kaikille tarkastelun kohteina oleville tuplille.
6.6.4 Olemassaolokvanttorin käyttöesimerkkejä
•
Kysely 1:
Etsitään kaikkien tutkimusosastolla työskentelevien
henkilöiden etu- ja sukunimi sekä osoite:
Q1: { t.FNAME, t.LNAME, t.ADDRESS | EMPLOYEE ( t ) AND
(  d )( DEPARTMENT ( d ) AND d.NAME = 'Research' AND d.DNUMBER = t.DNO ) }
 Kyselyn ainoa vapaa tuplamuuttuja on t. Sen sijaan tuplamuuttuja d on sidottu
olemassaolokvanttoriin.
 EMPLOYEE ( t ) ja DEPARTMENT ( d ) määräävät relaatiot, joiden tuplat kelpaavat
tuplamuuttujien d ja t arvoiksi.
 Ehto d.NAME = 'Research' on kyselyn valintaehto
 Ehto d.DNUMBER = t.DNO toimii puolestaan liitosehtona
•
Yleisestikin tupla-relaatiokalkyylin mukaisessa ilmauksessa kaikki vapaat muuttujat tulisi sijoittaa
pystyviivan vasemmalle puolelle.
•
Kysely 2:
Etsitään jokaista Staffordissa käynnissä olevaa projektia kohti projektin numero, sitä
kontrolloivan osaston numero ja kyseisen osaston johtajan sukunimi, syntymäaika ja
osoite:
Q2: { p.PNUMBER, p.DNUM, m.LNAME, m.BDATE, m.ADDRESS | PROJECT ( p ) AND
EMPLOYEE ( m ) AND p.LOCATION = 'Stafford' AND
( (  d )( DEPARTMENT ( d ) AND p.DNUM = d.DNUMBER AND d.MGRSSN = m.SSN ) ) }
 Kyselyssä on kaksi vapaata tuplamuuttujaa: p ja m.
 Kyselyssä asetettuja ehtoja testataan kaikille mahdollisille tuplamuuttujien p ja m
kombinaatioille, ja ainoastaan kaikki asetetut ehdot täyttävät tuplat päätyvät tulokseen.
•
Samaan relaatioon voi viitata tarvittaessa useampikin kuin yksi tuplamuuttuja kerrallaan.
•
Kysely: Etsitään kunkin työntekijän ja hänen esimiehensä etu- ja sukunimi:
Q8: { e.FNAME, e.LNAME, s.FNAME, s.LNAME | EMPLOYEE ( e ) AND
EMPLOYEE ( s ) AND e.SUPERSSN = s.SSN }
•
Kysely 3': Etsitään niiden työntekijöiden nimi, jotka työskentelevät vähintään yhdessä osastolle 5
kuuluvassa projektissa:
Q3': { e.LNAME, e.FNAME | EMPLOYEE ( e ) AND (  x ) (  w ) ( PROJECT ( x ) AND
WORKS_ON ( w ) AND x.DNUM = 5 AND w.ESSN = e.SSN AND x.PNUMBER = w.PNO ) ) }
•
Kysely 4: Etsitään niiden projektien numerot, joissa joko työskentelee työntekijä nimeltä Smith, tai
projektia kontrolloivaa osastoa johtaa 'Smith'-niminen henkilö:
Q4: { p.PNUMBER | PROJECT ( p ) AND ( ( (  e ) (  w ) ( EMPLOYEE ( e ) AND WORKS_ON ( w )
AND w.PNO = p.PNUMBER AND e.LNAME = 'Smith' AND e.SSN = w.ESSN ) ) OR ( ( (  m )
(  d ) ( EMPLOYEE ( m ) AND DEPARTMENT ( d ) AND p.DNUM = d.DNUMBER AND
d.MGRSSN = m.SSN AND m.LNAME = 'Smith' ) ) ) }
•
Kuten edellisestä esimerkistä nähdään, korvautuu relaatioalgebran unionioperaatio tuplarelaatiokalkyylissä loogisella TAI-operaatiolla.
6.6.5 Muuntosäännöt eri kvanttorityyppien välillä
•
Predikaattilogiikan sääntöjä käyttäen pystytään olemassaolokvanttorin sisältävä lauseke
muuntamaan lausekkeeksi, jossa esiintyy universaalikvanttori ja päinvastoin.
•
•
Muunnokselle kvanttorityypiltä toiselle pätevät seuraavat säännöt:

Uutta tyyppiä olevan kvanttorin eteen tulee negaatio NOT, ellei aikaisempi kvanttori sisältänyt
negaatiota, muulloin uuden kvanttorin eteen ei tule negaatiota.

Jokainen AND-operaatio muutetaan OR-operaatioksi.

Jokainen OR-operaatio muutetaan AND-operaatioksi.

Jokainen ilmauksen kaava muunnetaan sisällöltään negaatiokseen.
Muuntosäännöt ovat seuraavanlaiset:
1. (  x ) ( P( x ))  NOT (  x ) ( NOT ( P( x ) ) )
Tulkinta: vasen puoli = "Jokaisella x:llä on ominaisuus P".
oikea puoli = "Ei ole sellaista x:ää, jolla ei olisi ominaisuutta P".
2. (  x ) ( P( x ))  NOT (  x ) ( NOT ( P( x ) ) )
Tulkinta: vasen puoli = "Ainakin yhdellä x:llä on ominaisuus P".
oikea puoli = "Ei pidä paikkaansa, ettei millään x:llä ole
ominaisuutta P".
3. (  x ) ( P( x ) AND Q( x ))  NOT (  x ) ( NOT ( P( x ) ) OR NOT Q( x ) )
Tulkinta: vasen puoli = "Jokaisella x:llä on sekä ominaisuus P että Q".
oikea puoli = "Ei ole olemassa x:ää, jolta puuttuu ominaisuus P tai Q".
4. (  x ) ( P( x ) OR Q( x ))  NOT (  x ) ( NOT ( P( x ) ) AND NOT Q( x ) )
Tulkinta: vasen puoli = "Jokaisella x:llä on ainakin jompikumpi ominaisuuksista P tai Q".
oikea puoli = "Ei löydy sellaista x:ää, joilla ei ole kumpaakaan ominaisuuksista P ja Q".
5. (  x ) ( P( x ) OR Q( x ))  NOT (  x ) ( NOT ( P( x ) ) AND NOT Q( x ) )
Tulkinta: vasen puoli = "Ainakin yhdellä x:llä on ominaisuus P tai Q".
oikea puoli = "Jokaiselta x:ltä ei puutu molempia ominaisuuksista P ja Q".
6. (  x ) ( P( x ) AND Q( x ))  NOT (  x ) ( NOT ( P( x ) ) OR NOT Q( x ) )
Tulkinta: vasen puoli = "Ainakin yhdellä x:llä on sekä ominaisuus P että Q".
oikea puoli = "Ei pidä paikkaansa, että jokaiselta x:ltä puuttuu ainakin toinen
ominaisuuksista P ja Q".
6.6.6 Universaalikvanttorin käyttöön liittyviä esimerkkejä
•
Kysely 3: Etsitään työntekijät, jotka työskentelevät kaikissa osaston 5 kontrolloimissa projekteissa:
Q3: { e.LNAME, e.FNAME | EMPLOYEE ( e ) AND ( (  x ) ( NOT ( PROJECT ( x ) ) OR
NOT ( x.DNUM = 5 ) OR ( (  w ) ( WORKS_ON ( w ) AND w.ESSN = e.SSN AND
x.PNUMBER = w.PNO ) ) ) }
•
Kyselyä 3 voidaan analysoida pätkimällä se eri komponentteihinsa seuraavasti:
Q3: { e.LNAME, e.FNAME | EMPLOYEE ( e ) AND F' }
F' =
( (  x ) ( NOT ( PROJECT ( x ) ) OR F1 ) )
F1 = NOT ( x.DNUM = 5 ) OR F2
F2 = ( (  w ) ( WORKS_ON ( w ) AND w.ESSN = e.SSN AND x.PNUMBER = w.PNO ) ) }
•
Koska universaalikvanttoriin sidotun tuplamuuttujan x pitää toteutua kaikille mahdollisille hakuavaruuden
tuplille, pitää huomioida, että esitetty vaatimus toteutuu erityisesti silloin, kun x joko ei edusta laisinkaan
mielenkiinnon kohteena olevan entiteetin tuplaa, tai sitten x:n viittaaman tuplan valintaehto tietyn
attribuutin suhteen ei täyty.
•
Siten, jos x ei edusta entiteettityyppiä PROJECT, voidaan x jättää huomiotta kokonaan, eli
universaalikvanttoriin sidotun väitteen pitää toteutua aina, jos x ei ole projekti-entiteetin esiintymä. Tätä
osuutta edustaa kyselyssä TAI-operaattoriin liitetty ensimmäinen kaava NOT ( PROJECT ( x ) ).
•
Vastaavasti ne projekti-entiteettityypin tuplat, joissa projektista vastaavan osaston numerona on jotain
muuta kuin 5, pitää sulkea pois evaluoimalla kaava todeksi TAI-operaattoriin sidotulla kaavalla NOT (
x.DNUM = 5 ).
•
Nyt on universaalikvanttoriin sidottu väite aina tosi, jos joko x ei ole projekti, tai projektia x kontrolloivan
osaston numero ei ole 5.
•
Jotta työntekijä päätyisi kyselyn vastausrelaatioon, pitää hänen nyt työskennellä kaikissa niissä
projekteissa, joita ei vielä ole suljettu pois. Tämä tarkoittaa suomennettuna sitä että
"Jokaista tarkastelun kohteena olevaa projektia ( siis sellaista, jota kontrolloi osasto 5 ) kohti pitää
löytyä taulusta WORKS_ON tupla, jossa projektinumerot täsmäävät keskenään, ja lisäksi saman
työntekijän on työskenneltävä jokaisessa näistä projekteista ( esimerkin 5.6 mukaisessa tietokannassa
projekteissa 1, 2 ja 3 )."
•
Haluttaessa päästä eroon universaalikvanttorin käyttämisestä voidaan kysely Q3 muuntaa kappaleen
6.6.5 muunnossääntöjä käyttäen seuraavanlaiseksi:
Q3A: { e.LNAME, e.FNAME | EMPLOYEE ( e ) AND ( NOT (  x ) ( PROJECT ( x ) ) AND
( x.DNUM = 5 ) AND ( NOT (  w ) ( WORKS_ON ( w ) AND w.ESSN = e.SSN AND
x.PNUMBER = w.PNO ) ) ) ) }
•
Kysely 6: Etsitään niiden työntekijöiden nimet, joilla ei ole perheenjäseniä:
Q6: { e.FNAME, e.LNAME | EMPLOYEE ( e ) AND ( NOT (  d ) ( DEPENDENT ( d ) ) AND
( e.SSN = d.ESSN ) ) }
Edellinen kysely voitaisiin haluttaessa muuntaa universaalikvanttorin sisältäväksi seuraavanlaisesti:
Q6A: { e.FNAME, e.LNAME | EMPLOYEE ( e ) AND ( (  d ) ( NOT DEPENDENT ( d ) ) OR
NOT ( e.SSN = d.ESSN ) ) ) }
•
Kysely 7: Tulostetaan nimet kaikilta sellaisilta osastonjohtajilta, joilla on ainakin yksi perheenjäsen:
Q7: { e.FNAME, e.LNAME | EMPLOYEE ( e ) AND ( (  d ) (  p ) ( DEPARTMENT ( d ) AND
DEPENDENT ( p ) ) AND ( e.SSN = d.MGRSSN AND p.ESSN = e.SSN ) ) }
Kysely on toteutettu käyttämällä tulkintaa "Listaa osastonjohtajat, joita kohti löytyy ainakin yksi
perheenjäsen taulusta DEPENDENT".
6.6.7 Turvalliset ilmaukset
•
Käytettäessä tupla-relaatiokalkyylin ilmauksissa universaali- tai olemassaolokvanttoreita tai
predikaattien negaatioita pitää olla tarkkana, että kirjoitettu ilmaus on järkevä, ts. sen voivat
toteuttaa ainoastaan haluttua entiteettiä edustavat tuplat.
•
Ilmauksen sanotaan olevan turvallinen, jos sen vastausrelaatioon kuuluvien tuplien lukumäärä on
äärellinen.
•
Esimerkki: ilmaus { t | NOT ( EMPLOYEE ( t ) ) } ei ole sellaisenaan turvallinen, koska ilmauksessa
esitetyn vaatimuksen täyttävät kaikki muut tuplat paitsi työntekijöitä edustavat.
•
Kirjoitettaessa ilmauksia pitää aina selvittää, mikä on ilmauksen vastausrelaation määrittelyjoukko.
Ei ole mielekästä, että vastaukseen voisi kuulua tuplia, jotka edustavat eri entiteettityyppejä.
6.7 Määrittelyjoukkoon perustuva relaatiokalkyyli
•
Määrittelyjoukkoon perustuva relaatiokalkyyli sai alkunsa IBM:n kehittämästä QBE-kyselykielestä
( tulee sanoista Query By Example ), jota kehitettiin samanaikaisesti SQL:n kanssa, mutta eri
toimipisteessä.
•
QBE-kyselykielen pohjalta esiteltiin myöhemmin teoreettinen tausta määrittelyjoukkoon perustuvalle
relaatiokalkyylille.
•
Toisin kuin tupla-relaatiokalkyylissä, jossa muuttujat viittaavat relaatioiden sisältämiin tupliin,
määrittelyjoukkokalkyylissä muuttujat viittaavat attribuuttien saamiin arvoihin.
•
Määrittelyjoukkokalkyylin yleinen ilmaus on muotoa
{ x1, x2, ..., xn | EHTO( x1, x2, ..., xn, xn+1, xn+2, ..., xn+m },
missä x1, x2, ..., xn, xn+1, xn+2, ..., xn+m ovat määrittelyjoukkomuuttujia, jotka saavat arvoja yli
attribuuttien määrittelyjoukkojen, ja EHTO on puolestaan määrittelyjoukkokalkyylin mukainen kaava.
•
Kaavan rakenneosina ovat atomit kuten tupla-relaatiokalkyylissäkin, mutta atomien määrittely poikkea
hieman tupla-kalkyylin mukaisesta.
•
1. Muotoa R( x1, x2, ..., xn ) oleva atomi, jossa R on astetta j olevan relaation tunnus, ja kukin xi,
1 ≤ i ≤ j, on määrittelyjoukkomuuttuja. Atomin tulkintana on, että attribuuttien < x1, x2, ..., xj >
arvolistan pitää esiintyä relaatiossa R, jossa jokainen xi on relaation i:nnen attribuutin arvo.
•
Yleensä määrittelyjoukkokalkyylin ilmauksen ehto esitetään tiivistetysti ilman pilkuilla erottelua tapaan
{ x1, x2, ... , xn | R( x1 x2 x3 ) }
•
2. Atomi voi olla myös muotoa xi < operaattori > xj, missä operaattori on jokin vertailuoperaattoreista
{ =, <, ≤, >, ≥, ≠ }, ja xi ja xj ovat määrittelyjoukkomuuttujia.
•
3. Lisäksi atomi voi olla tyyppiä xi < operaattori > c tai c < operaattori > xj, missä xi ja xj ovat
määrittelyjoukkomuuttujia ja c on vakioarvo.
•
Jokainen atomi saa totuusarvon TOSI tai EPÄTOSI tiettyä atomien arvojoukkoa kohti. Tyyppiä 1 oleva
atomi saa arvon TOSI, jos määrittelyjoukkomuuttujien arvot liittyvät relaatioon R. Tyyppiä 2 ja 3 olevat
atomit ovat puolestaan tosia, jos muuttujien arvot toteuttavat niille esitetyt ehdot.
•
Kuten tupla-relaatiokalkyylin yhteydessä, myös määrittelyjoukkokalkyylissä kaavoja muodostetaan
yhdistelemällä atomeja, muuttujia ja kvanttoreita.
•
Tällä kurssilla käytetään määrittelyjoukkomuuttujista pieniä kirjaimia väliltä h, i, j, ..., x, y z.
•
Kysely 0: Etsitään työntekijän nimeltä 'John B. Smith' syntymäaika ja osoite:
Q0: { uv | (  q ) (  r ) (  s ) (  t ) (  w ) (  x ) (  y ) (  z ) ( EMPLOYEE ( qrstuvwxyz ) AND
q = 'John' AND r = 'B' AND s = 'Smith' ) }

Kyselyssä on kaksi vapaata ja kahdeksan olemassaolokvanttoreihin sidottua
määrittelyjoukkomuuttujaa.

Muuttujiin q, r, s, t, u, v, w, x, y ja z sijoitettavien arvojen pitää olla asetetun ehdon mukaisesti
peräisin taulun EMPLOYEE tuplista, ja lisäksi muuttujilla q, r ja s on esiinnyttävä arvot 'John' 'B' ja
'Smith' tässä järjestyksessä, jotta tupla tulisi valituksi kyselyn vastaukseen.
•
Myöhemmissä esimerkeissä kvantifiointi tapahtuu luettavuuden selkeyttämiseksi ainoastaan niiden
määrittelyjoukkomuuttujien ylitse, joilla on merkitystä valinta- tai liitosehtoa muodostettaessa
( edellisessä esimerkissä muuttujilla q, r ja s ), vaikka esitystapa ei olekaan formaalisti korrekti.
Myöskään pilkkua ei tulla jatkossa käyttämään erotinmerkkinä.
•
Toinen epästandardi esitysmuoto olisi asettaa valintaehtoina olevat vakiot suoraan muuttujien paikalle.
Samalla kaikki pystyviivan vasemmalla puolella esiintymättömät määrittelyjoukkomuuttujat
kvantifioidaan implisiittisesti ( siis ilman erillistä mainintaa ) olemassaolokvanttorilla.
Q0A: { uv | EMPLOYEE( 'John', 'B', 'Smith', t, u, v, w, x, y, z ) }
•
Kysely 1: Etsitään kaikkien tutkimusosaston työntekijöiden nimi ja osoite:
Q1: { qsv | (  z ) (  l ) (  m ) ( EMPLOYEE ( qrstuvwxyz ) AND DEPARTMENT ( lmno ) AND
l = 'Research' AND m = z ) }

Edellisessä kyselyssä kahden määrittelyjoukkomuuttujan välinen vertailuoperaatio m = z edustaa
liitosehtoa, kun taas vertailu vakioon lausekkeessa l = 'Research' tarkoittaa valintaehtoa.
•
Kysely 2: Etsitään jokaisen Staffordissa käynnissä olevan projektin numero, projektista vastaavan
osaston numero sekä kyseisen osaston johtajan sukunimi, syntymäaika ja osoite:
Q2: { iksuv | (  j ) (  m ) (  n ) (  t ) ( PROJECT ( hijk ) AND EMPLOYEE ( qrstuvwxyz ) AND
DEPARTMENT ( lmno ) AND k = m AND n = t AND j = 'Stafford' ) }
•
Kysely 6: Etsitään niiden työntekijöiden nimet, joilla ei ole perheenjäseniä:
Q6: { qs | (  t ) ( EMPLOYEE ( qrstuvwxyz ) AND ( NOT (  l ) ( DEPENDENT ( lmnop ) AND
t=l)))}

Tämä kysely voidaan muuntaa haluttaessa universaalikvanttorin avulla toteutettavaksi, mikä käy
selville seuraavasta esimerkistä:
Q6A: { qs | (  t ) ( EMPLOYEE ( qrstuvwxyz ) AND ( (  l ) ( NOT ( DEPENDENT ( lmnop ) OR
NOT ( t = l ) ) ) ) }
•
Kysely 7: Etsitään kaikkien niiden osastonjohtajien nimet, joilla on ainakin
yksi perheenjäsen:
Q7: { sq | (  t ) (  j ) (  l ) EMPLOYEE ( qrstuvwxyz ) AND DEPARTMENT ( hijk ) AND
DEPENDENT ( lmnop ) AND t = j AND l = t ) }
•
Kuten aikaisemmin jo todettiin, mikä tahansa relaatioalgebralla esitettävissä oleva kysely voidaan
yhtäläisesti esittää kummalla tahansa relaatiokalkyylillä. Samoin mikä tahansa tupla- tai
määrittelyjoukkokalkyylin turvallinen ilmaus voidaan esittää relaatioalgebran avulla.
•
Määrittelyjoukkokalkyyliin perustuvan QBE-kyselykielen lyhyt katsaus löytyy oppikirjan liitteestä D.
7. ER- ja EER-mallin kuvaaminen relaatiotietokannaksi
•
Tähän mennessä olemme käsitelleet, miten tietokannan kuvaus esitetään ER- tai EER-mallinnusta
käyttämällä luvuissa 3 ja 4.
•
Lisäksi olemme esitelleet relaatiomallin teoreettisen perustan luvussa 6. esittelemällä relaatioalgebran
sekä tupla- ja määrittelyjoukkoon perustuvan relaatiokalkyylin.
•
Sen sijaan menettely, miten käsitteellisestä tietomallista päästään siirtymään relaatiomalliin, on
toistaiseksi jäänyt vaille huomiota.
•
Seuraavassa tarkastellaan, miten ER-mallinnuksen avulla hahmoteltu tietokanta voidaan kuvata
relaatiomallin mukaiseksi. Kyseessä on tietokannan suunnitteluvaihe, jossa siirrytään TKHJ:stä
riippumattomasta osuudesta TKHJ:n asettamien reunaehtojen mukaiseen ( vertaa kirjan kuvaan 3.1 ).
•
Kuvauksen eri vaiheet on esitelty kirjan 7. luvun kappaleessa 7.1. Kappaleessa 7.2 käsitellään EERmallin kuvaamista relaatiomalliin.
7.1 ER-mallin mukaisen tietokannan suunnitelman kuvaaminen relaatiomallia
vastaavaksi
•
ER-mallia noudatteleva tietokannan kuvaus voidaan muuntaa relaatiomallin mukaiseksi
käyttämällä 7-vaiheista algoritmia.
•
Tarkastellaan eri vaiheita esimerkeissä käytetyssä yrityksen tietokannassa.
7.1.1 Algoritmi ER-mallin kuvaamiseksi relaatiomalliin
•
VAIHE 1: Perustetaan ER-mallin jokaista vahvaa entiteettityyppiä E kohti relaatiotaulu R, johon
sijoitetaan kaikki E:n yksinkertaiset attribuutit. Koosteiset attribuutit esitetään ositettuina
yksinkertaisiksi attribuuteiksi. Valitaan jokin E:n avainattribuuteista R:n pääavaimeksi.
Pääavain voi tarvittaessa koostua usean attribuutin yhdistelmästä. Vierasavain- ja
suhteiden attribuutit jätetään tässä vaiheessa vielä kirjaamatta.
•
Yritystä koskevassa esimerkissä perustetaan relaatiotaulut EMPLOYEE, DEPARTMENT ja PROJECT,
koska ne edustavat kaikki vahvoja entiteettityyppejä. Tässä vaiheessa jätetään taulusta EMPLOYEE
kirjaamatta vierasavainattribuutit SUPERSSN JA DNO. Samalla perusteella taulusta PROJECT
kirjaamatta osastonumero. Taulusta DEPARTMENT jätetään tässä vaiheessa pois tieto osaston johtajan
henkilötunnuksesta ( vierasavain ) ja hänen aloituspäivästään ( osaston johtamissuhteen attribuutti ).
•
VAIHE 2: Jokaista heikkoa entiteettityyppiä W varten perustetaan myös oma relaatiotaulu R, johon
kerätään kaikki kyseiseen entiteettityyppiin liittyvät yksinkertaiset attribuutit. Koosteiset
attribuutit esitetään yksinkertaisiksi ositettuina. Lisäksi tauluun otetaan mukaan W:n
omistajatyypin pääavain Z. Taulun pääavaimeksi valitaan W:n osittaisavaimen ja Z:n
yhdistelmä. Huonoimmassa tapauksessa W:n osittaisavain koostuu sen kaikkien omien
attribuuttien yhdistelmästä.
•
Koska heikon entiteettityypin edustaja on olemassaoloriippuva omistajatyyppi(e)nsä edustajasta,
kannattaa vyöryttää omistajaentiteetin tuplassa tapahtuvat muutokset sekä mahdollinen tuplan poisto
optiolla CASCADE kaikkiin siihen liittyviin heikon entiteettityypin edustajatupliin.
•
Yritysesimerkissä perustetaan taulu DEPENDENT, johon otetaan mukaan kaikki sen omat attribuutit
sekä lisäksi työntekijän henkilötunnusta kuvaava identifioiva attribuutti ESSN.
•
VAIHE 3: Jokaista lukumääräsuhteeltaan tyyppiä 1:1 olevaa liittymää R kohti selvitetään aluksi
suhteeseen osallistuvat taulut S ja T. Mikäli jommaltakummalta taululta vaaditaan
täydellistä osallistumista suhteeseen R, valitaan kyseinen taulu S:n paikalle ( menettelyllä
vältetään turhien NULL-arvojen tallentamista ). Tämän jälkeen sijoitetaan taulun S
vierasavaimeksi taulun T pääavain, ja lisäksi kaikki liittymälle R ominaiset attribuutit
viedään samoin tauluun S.
•
Yritystä kuvaavassa esimerkissä osaston johtamiseen liittyvä suhde on tyyppiä 1:1. Koska osaston
osallistuminen suhteeseen on täydellistä mutta työntekijän osittaista, valitaan tauluksi S
DEPARTMENT ja tauluksi T EMPLOYEE. Tällöin joudutaan tauluun DEPARTMENT lisäämään suhteen R
attribuutti MGRSTARTDATE sekä taulun EMPLOYEE vierasavain MGRSSN.
•
Mikäli olisi toimittu päinvastoin eli valittu taulu EMPLOYEE S:n paikalle, olisi kyseiseen tauluun
jouduttu lisäämään tieto siitä, mitä osastoa työntekijä johtaa sekä johtajana toimimisen
aloituspäivämäärä. Tämä ratkaisu olisi kuitenkin kömpelömpi, sillä suurin osa työntekijöistä ei johda
mitään osastoa, kun taas jokaisella osastolla pitäisi olla johtaja.
•
Jos osallistuminen relaatioon R on molempiin suuntiin täydellistä, olisi mahdollista koota siihen
osallistuvat entiteettityypit yhdeksi laajemmaksi entiteettityypiksi.
•
VAIHE 4: Jokaista lukumääräsuhteeltaan 1:N olevaa taulujen S ja T välillä vallitsevaa suhdetta R
kohti valitaan S:n paikalle tauluista se, johon lukumääräsuhde N liittyy. Sijoitetaan
tauluun S taulun T ( eli R:n 1-puolen ) vierasavainkenttä sekä kaikki suhteelle
ominaiset lisäattribuutit.
•
Yrityksessä lukumääräsuhdetta 1:N edustavat relaatiot OSASTOLLA_KIRJOILLAOLO,
PROJEKTIN_KONTROLLOINTI sekä ESIMIEHENÄ_TOIMIMINEN. Täten lisätään tauluun EMPLOYEE
attribuutti, joka kuvaa osastonumeroa ( DNO ), koska yhdellä osastolla voi olla monta työntekijää
( mutta yksikään työntekijä ei voi olla kirjoilla usealla eri osastolla ). Samasta syystä tauluun
PROJECT attribuutti DNUM. Lisäksi tauluun EMPLOYEE on lisättävä tieto esimiehestä eli attribuutti
SUPERSSN. Viimeksi mainittu relaatio ESIMIEHENÄ_TOIMIMINEN on refleksiivinen, joten taulu
EMPLOYEE esiintyy suhteessa sekä S:nä että T:nä.
•
VAIHE 5: Jokaista liittymää R kohti, jonka lukumääräsuhteena on M:N, on tietokantaan perustettava
uusi relaatiotaulu S, johon sijoitetaan attribuuteiksi kummankin suhteeseen osallistuvan
taulun U ja V pääavaimen muodostavat attribuutit. Näiden attribuuttien yhdistelmästä
muodostuu taulun S pääavain. Lisäksi S:ään sijoitetaan kaikki suhteelle R tyypilliset
attribuutit. Kannattaa huomioida, että uuden taulun S perustaminen on välttämätöntä
lukumääräsuhteen ollessa M:N, sillä moniarvoisia attribuutteja ei relaatiomallissa
hyväksytä.
•
Esimerkissämme entiteettityyppien TYÖNTEKIJÄ ja PROJEKTI välinen suhde TYÖTUNNIT on
lukumääräsuhteeltaan M:N, sillä yksittäinen työntekijä voi tehdä työsuorituksia useassa eri
projektissa, joissa voi puolestaan olla useita työntekijöitä kerrallaan. Täten perustetaan taulu
TYÖTUNNIT ( WORKS_ON ), jonka pääavain koostuu taulujen TYÖNTEKIJÄ ja PROJEKTI pääavainten
yhdistelmästä { henkilötunnus, projektinumero }. Lisäksi työntekijän eri projekteihin tekemien
työtuntien lukumäärä kirjataan taulun kolmanneksi attribuutiksi.
•
Tyypin M:N mukaisten suhteiden esittämiseksi perustettuun tauluun S kannattaa asettaa muutoksien
ja poistojen varalta optio CASCADE kullekin taulun pääavaimeen kuuluvalle vierasavainkentälle, sillä
taulun S tuplat ovat olemassaoloriippuvia S:n taustalla olevaan relaatioon R osallistuvien entiteettien
edustajista. Jos esimerkiksi jokin työntekijä lopettaa työskentelynsä yrityksessä, ei hänen
työtunneillaan ole sen jälkeen enää mitään relevanttia tulkintaa. Samoin käy, jos jokin sellainen
projekti lakkautetaan, johon työntekijä on osallistunut.
•
VAIHE 6: Jokaista relaatiotaulun R moniarvoista attribuuttia A varten on perustettava uusi
relaatiotaulu S. Kyseiseen tauluun pitää sijoittaa attribuutti B, joka esittää kerrallaan yhtä
A:n saamista arvoista yhtä R:n tuplaa kohti. Lisäksi S:ään pitää sijoittaa vierasavaimeksi
taulun R pääavain Z, jotta tiedetään, mihin tuplaan taulussa R uuden taulun S tuplat
liittyvät. Taulun S pääavain koostuu siten attribuuttien Z ja B yhdistelmästä.
•
Yrityksen tietokannassa osastoon liittyvä attribuutti TOIMIPISTEET oli ER-mallissa moniarvoinen:
yhdellä osastolla voi olla monta toimipistettä. Koska moniarvoisia attribuutteja ei hyväksytä
relaatiomallissa, pitää perustaa uusi taulu DEPT_LOCATIONS, joka sisältää kaksi attribuuttia:
osastonumeron sekä sijaintipaikan. Tuplia tauluun tulee jokaista osastoa kohti niin monta, kuin sillä
on toimipisteitä eri paikkakunnilla.
•
Moniarvoisten attribuuttien esittämiseksi perustetuissa tauluissa kannattaa jälleen vierasavaimen
päivitystä ja poistoa varten asettaa vyörytysoptio CASCADE – on turhaa säilyttää osaston
toimipisteitä tietokannassa, jos koko osasto lakkautetaan!
•
Esimerkkiyrityksessämme ei esiintynyt laisinkaan astetta 2 korkeampia asteita olevia relaatioita.
Viimeinen mallin kuvausvaiheista koskee tällaisten suhteiden kuvaamista relaatiomalliin sopiviksi.
•
VAIHE 7: Jokaista vähintään astetta 3 olevaa suhdetta R varten perustetaan uusi relaatiotaulu S,
johon sijoitetaan kaikkien suhteeseen R osallistuvien taulujen E pääavainattribuutit. Lisäksi
R:lle ominaiset lisäattribuutit sijoitetaan S:ään. Taulun S pääavain muodostuu kaikkien
taulujen E pääavainten yhdistelmästä pois lukien kuitenkin ne taulut, joiden kohdalla
lukumääräsuhteena on 1.
•
Tarkastellaan kirjan kuvaa 7.3, joka kuvaa esimerkin 4.11 mukaista tilannetta, jossa muodostettiin
astetta 3 oleva relaatio tavaran, sen toimittajan ja sitä tarvitsevan projektin välillä – relaation
pääavain muodostuu jokaisen suhteeseen osallistuvan taulun pääavainten yhdistelmästä.
•
Jos kuitenkin tiedettäisiin esimerkiksi, että vain yksi toimittaja pystyy toimittamaan kutakin osaa, ei
tietoa toimittajasta ole tarpeen sisällyttää suhdetta kuvaavan relaatiotaulun pääavaimeen, sillä
toimittaja pystytään identifioimaan toimitettavan osan numerosta. Vastaava tilanne syntyisi, jos
yhteen projektiin tarvittaisiin ainoastaan yhtä osaa ( osan numero voitaisiin päätellä projektin nimen
perusteella ) tai tietylle projektille pystyisi välittämään osia vain yksi toimittaja ( projekti voitaisiin
päätellä toimittajan perusteella ).
•
ER- ja relaatiomallien välinen pääasiallinen ero on, että ER-mallissa entiteettityyppien väliset suhteet
esitellään aina eksplisiittisesti, kun taas relaatiomallissa suhde ilmaistaan attribuuttien välillä, joiden
arvot edustavat keskenään samaa arvojoukkoa. Toinen attribuuteista on taulun pääavain ja toinen
puolestaan vierasavain ( vrt. taulun DEPARTMENT kenttä DNUMBER ja taulun PROJECT kenttä DNUM,
taulun EMPLOYEE kentät SSN ja SUPERSSN jne. ).
•
Suhteeseen R osallistuvat entiteettityyppien S ja T esiintymät yhdistetään toisiinsa
yhtäsuuruusliitoksen avulla S:n attribuutille A ja T:n attribuutille B. Liitosehto toteutuu, kun
S.A = T.B, ja S.A  NULL.
•
Jos binäärisen relaation lukumääräsuhde on 1:1 tai 1:N, tarvitaan sen esittämiseksi yleensä 1 liitos
( vrt. OSASTO ― JOHTAJA, PROJEKTI — OSASTO ).
•
Lukumääräsuhteeltaan M:N olevan binäärisen relaation esittämiseen vaaditaan 2 liitosta
( vrt. TYÖTUNNIT ).
•
Astetta n olevan suhteen esittämistä varten tarvitaan n liitosta.
•
Liitosten muodostamisessa kannattaa olla varovainen. Pitää huolehtia siitä, että liitosattribuuteista
toinen on taulun S pääavain ja toinen taulun T vierasavain. Muulla tavalla toteutettu liitos saattaa
tuottaa tulostauluun virheellistä tietoa sisältäviä ns. ’valetuplia’.
•
Esimerkki: Muodostetaan liitos taulujen PROJEKTI ja TOIMIPISTEET välille käyttämällä
liitosattribuuttina sijaintipaikkakuntaa, eli PLOCATION = DLOCATION. Koska kyseiset
attribuutit eivät muodosta pääavain-vierasavain –paria, päätyy tulostauluun järjettömiä
tuplien yhdistelmiä, joissa eri tauluista valitut tuplat eivät millään mielekkäällä tavalla liity
toisiinsa.
•
Kannattaa lisäksi huomioida, että jokaista tietokannassa esiintyvää moniarvoista attribuuttia varten
pitää perustaa oma taulunsa.
7.1.2. Rakenneosien vastaavuus ER- ja relaatiomallin välillä
•
Seuraavassa yhteenveto, miten ER-mallin rakenneosat muunnetaan vastaamaan relaatiomallia.
ER-malli
Relaatiomalli
Entiteettityyppi
Entiteettityyppiä kuvaava relaatiotaulu
Suhde 1:1 tai 1:N
Vierasavain ( tai erillinen relaatiotaulu )
Suhde M:N
Erillinen relaatiotaulu, jossa 2 vierasavainta
Astetta n oleva suhde ( n > 2 ) Erillinen relaatiotaulu, jossa n vierasavainta
Yksinkertainen attribuutti
Attribuutti
Koosteinen attribuutti
Joukko yksinkertaisia attribuutteja
Entiteettityypin E moniarvoinen attribuutti A
Relaatiotaulu, jossa avainattribuutteina A:n sekä taulun E pääavaimen
yhdistelmä
Arvojoukko
Määrittelyjoukko
Avainattribuutti
Pää- tai toisioavain
7.2. EER-mallin rakenneosien kuvaaminen relaatiomalliin
• Kirjan luvussa 7.1 tarkasteltiin ER-mallin rakenneosien kuvaamista
relaatiomalliin sopiviksi.
• Tässä luvussa tarkastellaan EER-malliin mukaisten lisäominaisuuksien
kuvaamista relaatiomalliin. Näitä ominaisuuksia ovat luokkaaliluokkarelaatiot sekä kategoriat.
7.2.1 Yleistämisen ja erikoistamisen kuvaaminen relaatiomalliin
•
Aloitetaan EER-mallin muuntamisen tarkastelu tutkimalla kirjan esimerkkien 4.5 ja 4.6 mukaisia
tilanteita.
•
Käytettäessä EER-mallin mukaista käsitteellistä kuvausta pitää kohdassa 7.1 esitetty 7-vaiheinen
algoritmi pidentää 9-vaiheiseksi.
•
VAIHE 8: Esitellään neljä optiota, joiden avulla voidaan luokka-aliluokka -suhteet muuntaa
relaatiomalliin sopiviksi. Olkoot EER-mallin mielivaltaisen luokan C attribuutit
{ k, a1, a2, ..., an }, missä k on kyseisen luokan avainattribuutti, ja edustakoon
luokan C aliluokkia joukko { S1, S2, S3, ..., Sm }. Tällöin jokainen C:n erikoistaminen
aliluokkiinsa pitää muuntaa relaatiomallin mukaiseksi jollain seuraavista tavoista:


Optio 8A: Useita relaatiotauluja, joista yksi yliluokkaa C varten

Perustetaan relaatiotaulu L, johon sijoitetaan kaikki C:n attribuutit. Taulun pääavaimeksi
tulee selvästikin C:n pääavain.

Jokaista C:n aliluokkaa Si ( 1 ≤ i ≤ m ) kohti perustetaan relaatiotaulu Li, johon sijoitetaan
attribuuteiksi C:n pääavain k sekä kaikki kyseisen aliluokan erikoisattribuutit. Taulun
pääavaimeksi valitaan k.

Tätä optiota voidaan soveltaa aina riippumatta erikoistamisen tyypistä ( täydellinen tai
osittainen ― erillinen tai päällekkäinen )
Optio 8B: Useita relaatiotauluja, mutta yksistään aliluokkia varten

Perustetaan relaatiotaulu Li jokaista luokan C aliluokkaa Si
( 1 ≤ i ≤ m ) kohti. Attribuuteiksi tauluun Li valitaan kaikki C:n sekä sen erikoistetun
aliluokan Si attribuutit. Kunkin perustettavan taulun pääavaimeksi valitaan k.

Optiota 8B voidaan soveltaa vain, jos erikoistaminen on täydellistä, eli jokainen luokan C
edustaja kuuluu ainakin yhteen sen aliluokista, sillä pelkästään yliluokkaan kuuluvat C:n
edustajat jäisivät tässä ratkaisumallissa kirjaamatta kokonaan.

Lisäksi, jos erikoistaminen ei ole erillistä, aiheutuu redundanssia, koska C:n attribuuttien
arvot joudutaan toistamaan kaikille niille aliluokille, joita sen tupla edustaa.


Optio 8C: Yksi relaatiotaulu, joka sisältää yhden tyyppiattribuutin

Perustetaan relaatiotaulu L, johon sijoitetaan kaikki C:n sekä kaikki sen aliluokkien Si
( 1 ≤ i ≤ m ) attribuutit. Taulun pääavaimeksi valitaan k.

Näiden lisäksi tauluun sijoitetaan yksi ns. tyyppiattribuutti t, jonka saama arvo väliltä
[1..m] osoittaa, mihin C:n aliluokkaan entiteetin tupla kuuluu. Ellei tupla ole edustettuna
muualla kuin yliluokassa, tulee kyseisen attribuutin arvoksi puuttuva ( = NULL ).

Erillistä tyyppiattribuuttia ei ole kuitenkaan tarpeen esitellä, mikäli erikoistaminen
määräytyy suoraan jonkin yliluokan attribuutin saaman arvon perusteella.

Tätä optiota voidaan soveltaa ainoastaan silloin, kun erikoistaminen aliluokkiin on tyypiltään
erillistä, eli yksi yliluokan edustaja voi kuulua kerrallaan vain yhteen aliluokkaan.

Ratkaisu tuottaa useita NULL-arvoja, mikäli luokalla on useita aliluokkia ja / tai aliluokilla on
useita paikallisia attribuutteja. Optiolla saavutettava etu on kuitenkin se, ettei tauluja
tarvita luokka-aliluokkarelaation esittämiseksi yhtä enempää.
Optio 8D: Yksi relaatiotaulu, jossa useita tyyppiattribuutteja

Perustetaan relaatiotaulu L, johon sijoitetaan kaikki C:n sekä kaikki sen aliluokkien Si
( 1 ≤ i ≤ m ) attribuutit. Taulun pääavaimeksi valitaan k.

Lisäksi jokaista C:n aliluokkaa Si ( 1 ≤ i ≤ m ) kohti perustetaan tyyppiattribuutti ti, jonka
arvo on loogista tyyppiä ( tosi / epätosi ) ja joka osoittaa, edustaako entiteetin tupla
aliluokkaa Si vai ei.

Usean tyyppiattribuutin asemesta voitaisiin optiota 8D varten ottaa käyttöön yksi mbittinen tyyppiattribuutti, jonka i. bitti kertoo, kuuluuko tupla C:n i:nteen aliluokkaan Si vai
ei ( 0 = epätosi, 1 = tosi ).

Tätä optiota on tarkoitettu sovellettavaksi lähinnä päällekkäistä erikoistamista ajatellen,
mutta se kelpaa yhtäläisesti erilliseen erikoistamiseen.

Myös tämän ratkaisun etuna on yhden taulun riittävyys relaation esittämiseen, mutta
nytkin NULL-arvojen määrä tulee suureksi, mikäli on yleistä, että yksittäinen C:n edustaja
ei kuulu moneen aliluokkaan samanaikaisesti.
•
Optioista 8A ja 8B käytetään toteutustapansa mukaisesti nimitystä usean relaation optiot, kun
taas vaihtoehdot 8C ja 8D ovat yhden relaation optioita.
•
Optiossa 8A muodostetaan relaatio yliluokan ja jokaisen aliluokkansa välillä
yhtäsuuruusliitoksella pääavaimen k arvon mukaisesti.
•
Tarkastellaan kirjan esimerkkiä 7.4a.
•
Option 8B mukainen ratkaisu sisältää yhtäsuuruusliitoksen jo valmiina, joten luokan ja sen
yksittäisen aliluokan attribuutit löytyvät samasta taulusta.
•
Etsittäessä mielivaltaista C:n tuplaa joudutaan haku kohdistamaan kaikkiin tauluihin Li, jotka
edustavat C:n luokka-aliluokka -relaatioita.
•
Kaikki C:n tuplat saadaan muodostamalla kaikkien taulujen Li täysi ulkoinen liitos tai ulkoinen
unioni. Tällä tavoin saatu tulostaulu näyttäisi samalta kuin optioiden 8C ja 8D mukainen, mutta
ilman tyyppiattribuutteja.
•
Tarkastellaan kirjan esimerkkiä 7.4b.
•
Option 8C mukainen toteutus on nähtävillä kirjan esimerkissä 7.4c. Siinä aliluokkaan
kuuluminen määräytyy yksikäsitteisesti attribuutin 'TyönTyyppi' mukaisesti.
•
Optio 8C ei kuitenkaan kelpaa ratkaisuksi, jos työntekijä voisi kuulua useaan ammattiryhmään
samanaikaisesti. Tällöin jokaista erikoistettua työtyyppiä varten pitäisi olla tyyppiattribuutti
seuraavaan tapaan: 'OnkoInsinööri?', 'OnkoTeknikko?', 'OnkoSihteeri?' jne. Tähän
tarkoitukseen kelpaa optio 8D.
•
Tarkastellaan vielä kirjan esimerkkiä 7.4d.
•
Mikäli erikoistamisella on useita tasoja, ei ole mitenkään välttämätöntä käyttää jokaisella
tasolla samaa optiota. Tarkastellaan kirjan esimerkkiä 7.5 yliopistotietokannasta, jossa on
käytetty luokalle henkilö kolmea eri optiota eri erikoistamisvaiheissa ( HUOM! kirjan kuvateksti
on virheellinen, viittaus tapahtuu todellisuudessa kirjan esimerkkiin 4.7 ). Luokan 'HENKILÖ'
ylimmälle erikoistamistasolle on sovellettu optiota 8A ( täydellinen päällekkäinen
erikoistaminen ), luokalle TYÖNTEKIJÄ optiota 8C ( täydellinen erillinen erikoistaminen ) ja
luokalle OPISKELIJA optiota 8D ( sekä täydellistä että osittaista erikoistamista ).
7.2.2 Kategorioiden ( eli unionityyppien ) kuvaaminen relaatiomalliin
•
Entiteettityyppiä kutsutaan kategoriaksi, mikäli se on muodostettu usean eri entiteettityypin
unionioperaatiolla. Kategoriat esiteltiin edellä kappaleessa 4.4.
•
Kategorioiden esittämiseksi relaatiomallin avulla tarvitaan kappaleen 7.1.1 algoritmiin vielä yksi
lisäkohta ― vaihe 9.
•
VAIHE 9: Jokaista sellaista kategoriaa kohti, joka koostuu entiteettityypeistä, joilla on eri
avainattribuutti, perustetaan taulu, jonka pääavaimeksi asetetaan ns. sijaisavain, jonka
turvin kategorian eri edustajat pystytään identifioimaan. Sijaisavain on otettava
käyttöön, jotta kategorian eri edustajat voitaisiin yhdistää toisiinsa käsitteellisesti,
vaikka ne voivatkin itsenäisinä edustaa keskenään eri entiteettityyppejä. Sijaisavainta
kuvaava vierasavainattribuutti pitää lisätä myös kaikkiin unioniin osallistuviin
entiteettityyppeihin.
•
Tarkastellaan kirjan esimerkkiä 7.6, jossa kuvan 4.8 ( kirjassa jälleen väärä kuvateksti ) mukainen
kategoria muunnetaan relaatiomalliin kelvolliseksi. Perustetaan taulu OMISTAJA, joka sisältää
pelkästään tunnistenumeron, jota tarvitaan unionin ylläpitämiseksi. Vierasavainkenttä kyseistä
tunnistenumeroa varten lisätään kaikkiin unionin muodostaviin entiteettityyppeihin eli tyypeille
HENKILÖ, PANKKI ja YHTIÖ. Relaation OMISTAMINEN esittämiseksi perustetaan myös erillinen
relaatiotaulu, jossa pääavain muodostuu omistajan tunnistenumeron ja kulkuneuvon valmistenumeron
yhdistelmästä.
•
Kannattaa huomioida, että omistajan tunnistenumeroksi tulee NULL jokaisella sellaisella henkilöllä,
pankilla ja yhtiöllä, jotka eivät satu omistamaan mitään kulkuneuvoa.
•
Lisäksi kannattaa huomioida, ettei henkilö- ja kuorma-autoista muodostetun kategorian esittämiseksi
tarvita erillistä sijaisavaintaulua, sillä kummankin unioniin osallistuvan entiteettityypin pääavain on
keskenään yhteensopiva.
8. SQL-99 -kyselykieli: kaavan määrittely, perusrajoitukset ja
kyselyt
•
Standardoidun SQL:n käyttöönotto oli tärkeä syy relaatiotietokantojen yleistymiselle.
•
SQL (=Structured Query Language) toimii sekä datan määrittely- (DDL) että varsinaisena
kyselykielenä (DML).
•
SQL on verrattain yksinkertainen korkean tason kieli, jolla kuvataan operaatiot, joita tietokannalle
halutaan suorittaa.
•
SQL on luonteeltaan deklaratiivinen; s. o. kyselyjä rakennettaessa on tärkeää ainoastaan halutun
tavoitteen esittäminen. Tavoitteen saavuttamiseksi suoritettavien operaatioiden
suoritusjärjestyksellä ei ole sellaista painoarvoa kuin relaatioalgebrassa.
•
Kuitenkin relaatioalgebran ymmärtäminen helpottaa melkoisesti virheettömien SQL-kyselyjen
tuottamista.
•
SQL-99 -standardi jakautuu ns. ytimeen, joka kuuluu jokaiseen SQL-ympäristöön sekä
lisäominaisuuksia sisältäviin täydennyspaketteihin ( mm. tiedonlouhintaa, tietovarastointia,
multimediaa yms. varten ).
8.1 Datan määrittely, rajoitukset ja tietokannan kaavan muutokset SQL-99:ssä
•
Relaatioalgebran termejä relaatio, tupla ja attribuutti vastaavat SQL:ssä taulu, rivi ja sarake.
8.1.1 Kaavan ja hakemiston käsitteet SQL-99:ssä
•
Tietokannan kaava ( = schema ) sisältää tietokannan nimen sekä tiedon sen omistajasta.
•
Lisäksi kaava pitää sisällään kaikki tietokantaan kuuluvat taulut, rajoitukset, näkymät,
määrittelyjoukot ja muut rajoitukset ( esimerkiksi käyttöoikeudet ).
•
Uusi tietokannan kaava perustetaan SQL:ssä lauseella CREATE SCHEMA.
•
Esimerkki: Perustetaan esimerkeissä käyttämämme yrityksen tietokanta, ja annetaan sen omistajan
tunnukseksi JSMITH:
•
CREATE SCHEMA COMPANY AUTHORIZATION JSMITH
•
Usea tietokannan kaava voidaan koota yhden hakemiston alle.
•
Hakemisto pitää sisällään ns. informaatiokaavan ( = information schema ), joka sisältää koostetietoa
kaikista hakemistoon kuuluvista tietokannan kaavoista, kaavojen mukaisten tietokantojen
käyttöoikeuksista, yhteisistä määrityksistä hakemiston sisällä jne.
8.1.2 Taulun perustaminen SQL-kielellä
•
Uusi taulu perustetaan komennolla CREATE TABLE, jota seuraavat taulun nimi, attribuutit, niihin
liittyvät arvoalueet ja rajoitukset.
•
Taulua perustettaessa voidaan tarpeen mukaan mainita myös tietokannan nimi, johon se liittyy, ellei
se ole ilmeistä ympäristössä, jossa taulua ollaan perustamassa. Esimerkki:
•
CREATE TABLE COMPANY.EMPLOYEE ( eksplisiittinen tietokannan nimeäminen taulua
perustettaessa )
•
CREATE TABLE EMPLOYEE ( käsiteltäessä paraikaa tietokantaa COMPANY: implisiittinen
nimeäminen )
•
Taulun nimeä seuraa sulkumerkkien sisällä oleva lista taulun attribuuteista. Jokaisesta attribuutista
on lueteltu arvojoukko sekä mahdolliset määräykset sen arvoista.
•
Tarkastellaan kirjan esimerkkiä 8.1.
8.1.3 Attribuuttien datatyypit ja määrittelyjoukot SQL:ssä
•
Tarjolla olevat tietotyypit ovat numeerinen, merkki- / merkkijonotyyppi, bittijono, päivämäärä ja
kellonaika.
•
Numeeriseen tietotyyppiin sisältyvät eri mittaiset kokonaisluvut ( lyhyet, normaalit ja pitkät ) sekä
reaaliluvut ( normaalit ja kaksinkertaisen tarkkuuden ).
•
Desimaalilukuja varten voidaan määrätä kokonais- ja desimaaliosan pituudet
( esimerkiksi DECIMAL( i, j ) ).
•
Merkkijonot voivat olla kiinteän ( CHAR( n ) ) tai vaihtelevan mittaisia( VARCHAR( n ) ). Vaihtelevan
mittaisilla merkkijonoilla n osoittaa merkkijonon maksimipituuden.
•
Päivämäärä esitetään muodossa VVVV-KK-PP.
•
Aika esitetään joko sellaisenaan TT:MM:SS tai tarkennettuna aikavyöhykkeellä, esimerkiksi +03:00.
Aikakriittisissä järjestelmissä voidaan hyödyntää myös sekunnin osia, jolloin voidaan käyttää ns.
aikaleimatyyppiä ( = TIMESTAMP ).
•
Lisäksi on käytettävissä tyyppi INTERVAL, jota voidaan käyttää päiväyksen, kellonajan tai aikaleiman
arvon kasvattamiseen tai pienentämiseen yhdellä yksiköllä.
•
Usein tarvittavat merkkijonotyypit voidaan nimetä omiksi tyypeikseen käyttämällä hyväksi lausetta
CREATE DOMAIN.
•
Esimerkki: CREATE DOMAIN SSN_TYPE AS CHAR( 9 ) luo tyypin nimeltä SSN_TYPE, joka tarkoittaa
kiinteästi yhdeksän mittaista merkkijonoa.
8.2 Perusrajoitusten määrittely SQL:ssä
•
Seuraavassa on tarkoituksena tarkastella ns. perusrajoitusten esittelyä SQL-kielellä.
Perusrajoituksiin luetaan kuuluviksi avain- ja viite-eheysrajoitukset, attribuuttien arvoalueiden
määrittely, NULL-arvojen laillisuus sekä rajoitukset yksittäisille tuplille relaation sisällä.
8.2.1 Attribuuteille asetettavat rajoitukset ja oletusarvot
•
Attribuuteille voidaan asettaa taulun perustamisen yhteydessä rajoituksia, jotka koskevat sen
saamia arvoja.
o Puuttuvien arvojen torjuminen ( NOT NULL ).
 Välttämätöntä, mikäli kyseessä on pääavainattribuutti, mutta voidaan asettaa tarpeen
mukaan myös muille attribuuteille.
o Oletusarvon asettaminen, jos syötetään tyhjä arvo ( DEFAULT ).
 Voidaan asettaa attribuutille oletusarvo, mikäli se jätetään syöttöhetkellä tyhjäksi.
Oletusarvon oletusarvona on NULL, mikäli attribuutin NULL-arvojen esiintymistä ei ole
estetty.
o
Voidaan lisäksi asettaa rajoitettu perustyypin arvoalue attribuutin arvoalueeksi
CHECK-lauseella
Esimerkki: Vaaditaan osastonumeron olevan olemassa, ja sen arvon pitää olla jotain
väliltä 1-20:
DNUMBER NOT NULL CHECK ( DNUMBER > 0 AND DNUMBER < 21 )
o
CHECK-lausetta olisi voitu yhtäläisesti käyttää CREATE DOMAIN -lauseen yhteydessä vaikkapa
seuraavasti:
o
CREATE DOMAIN D_NUM AS INTEGER CHECK ( DNUM > 0 AND DNUM < 21 )
8.2.2 Avainten ja vierasavainten eheysrajoitukset
•
•
Avainattribuutit luetellaan taulun attribuuttilistan viimeisen attribuutin jälkeen uudelleen. Seuraavat
avaimiin liittyvät rajoitukset voidaan asettaa attribuuteille:
o
Attribuutin asettaminen pääavaimeksi ( PRIMARY KEY ).
o
Attribuutin asettaminen vaihtoehtoisavaimeksi ( UNIQUE ).
o
Attribuutin määritteleminen vierasavaimeksi ( FOREIGN KEY ).
Esimerkki: perustetaan taulu TOIMIPISTEET, jossa on kaksi kenttää - osastonumero ja sijainti, jotka
kumpikin kuuluvat pääavaimeen:
CREATE TABLE TOIMIPISTEET
( OSASTONUMERO INT NOT NULL,
SIJAINTI VARCHAR( 15 ) NOT NULL,
PRIMARY KEY ( OSASTONUMERO, SIJAINTI )
FOREIGN KEY ( OSASTONUMERO ) REFERENCES OSASTO ( OS_NUM ) )
•
Tarkastellaan kirjan esimerkkiä 8.2.
•
Jos pääavain on taulun yksinkertainen attribuutti, se voidaan mainita jo taulun attribuutteja
esiteltäessä kuten seuraavassa:
DNUMBER INT PRIMARY KEY
•
•
Attribuuteille voidaan määritellä toimenpiteet, mitä tehdään silloin, kun siihen viittaava tupla
poistetaan tai viittauksen kohteena oleva arvo muuttuu. Toimenpiteet voivat olla erilaiset eri
operaatioissa. Oletuksena on, että operaatio peruutetaan, mikäli avain- tai viite-eheyttä yritetään
rikkoa.
o
SET NULL: asetus puuttuvaksi.
o
CASCADE: toimenpiteen vyörytys kaikkialle, missä muutoksen
kohteena olevaan tuplaan viitataan.
o
SET DEFAULT: asetetaan oletusarvo, mikäli viittauksen kohteena
oleva tupla poistetaan.
Vyörytysoption ( CASCADE ) soveltaminen on tyypillistä tauluille, jotka edustavat M:N-liittymää.
Esimerkki: Kun projekti lakkautetaan, ei siihen enää voida tehdä myöskään mitään
työsuorituksia.
8.2.3 Rajoitusten nimeäminen
•
Rajoitukset voidaan nimetä käyttämällä varattua sanaa CONSTRAINT ja kirjoittamalla tämän
perään rajoitukselle tunnus ja sen merkitys. Tällöin voitaisiin myöhemmin viitata rajoitukseen
annetun tunnuksen avulla muutettaessa taulun määrittelyä ALTER TABLE –komennolla ( tästä
tarkemmin kappaleessa 8.3.2 ).
Esimerkki: Taulua EMPLOYEE perustettaessa määritellään:
CONSTRAINT EMPPK PRIMARY KEY ( SSN )
Nyt tunnus EMPPK viittaa rajoitukseen, jonka mukaan SSN on taulun EMPLOYEE pääavain.
•
Myös edellisessä kappaleessa esitettyjä toimenpiteitä viite-eheyden säilyttämiseksi voidaan
sisällyttää nimettyihin rajoituksiin
•
Tarkastellaan uudelleen kirjan esimerkkiä 8.2.
8.2.4 Rajoitusten asettaminen tuplille CHECK-lauseen avulla
•
Tuplille voidaan asettaa muitakin rajoituksia kuin avain- ja viite-eheyteen liittyviä käyttämällä hyväksi
CHECK-lausetta.
•
CHECK-lauseen avulla voidaan testata muun muassa, onko tuplan tietyn attribuutin arvo
hyväksyttävä suhteessa jonkin toisen attribuutin arvoon.
•
Esimerkki: Oletetaan, että tauluun OSASTO lisättäisiin osaston perustamispäivää kuvaava attribuutti
DEPT_CREATE_DATE. Nyt voitaisiin varmistua osaston johtajan aloituspäivämäärän
laillisuutta seuraavalla rajoituksella:
CHECK ( DEPT_CREATE_DATE < MGRSTARTDATE )
Tällä tavoin estettäisiin ilmeisen virheellisen päivämäärän
asettaminen johtajan aloituspäiväksi.
•
CHECK-lausetta voidaan käyttää myös luonteeltaan tässä luvussa esitettäviä yleisempien rajoitusten
esittämiseksi. Tästä tarkemmin kappaleessa 9.1.
8.3 Tietokannan kaavan muutoslauseet SQL:ssä
•
Seuraavassa esitellään komennot, joiden avulla pystytään tekemään päivityksiä tietokannan jo
olemassa olevaan kaavaan. Tämä voi tapahtua lisäämällä tai poistamalla tauluja, attribuutteja,
rajoituksia tai muita kaavan rakenneosia.
8.3.1. Kaavan ja taulun poistaminen
•
Komennolla DROP SCHEMA voidaan poistaa koko tietokanta.
•
Vastaavasti komennolla DROP TABLE voidaan poistaa yksittäinen taulu.
•
Kumpaankin operaatioon voidaan kohdistaa rajoitus CASCADE tai RESTRICT.
•
DROP SCHEMAn yhteydessä CASCADE tuhoaa tietokannan kaiken sisällön. RESTRICT puolestaan
estää tuhoamisen, jos tietokannan taulut eivät ole tyhjiä.
•
DROP TABLEn yhteydessä annettu CASCADE-optio tuhoaa annetun taulun kaikkine tietoineen ja
siihen liittyvine viittauksineen. RESTRICT-optio estää taulun poistamisen, mikäli se ei ole tyhjä, tai
siihen viitataan vielä toisaalla.
8.3.2 Komento ALTER
•
ALTER TABLE -komennolla voi muuttaa aikaisemmin tehtyjä määrittelyjä taululle. Tällä komennolla
voidaan lisätä / poistaa attribuutteja, asettaa / kumota rajoituksia ja oletusarvoja jne. Komento on
muotoa
ALTER TABLE taulu MUUTOS KOHDE <OPTIOT>;
8.3.2 Komento ALTER
•
Mahdolliset muutokset:
o
Attribuutin lisääminen tauluun: ADD
Esimerkki: ALTER TABLE COMPANY.EMPLOYEE ADD JOB VARCHAR( 12 );
* lisää tietokannan COMPANY tauluun EMPLOYEE kentän JOB, joka on maksimissaan
12-merkkinen vaihtelevan mittainen merkkijonoattribuutti.
o
Attribuutin poistaminen taulusta: DROP;
Esimerkki: ALTER TABLE COMPANY.EMPLOYEE DROP ADDRESS CASCADE;
* poistaa taulusta EMPLOYEE sarakkeen ADDRESS sekä kaikki siihen kohdistuvat viittaukset
muista tietokannan tauluista. Optio RESTRICT olisi estänyt operaation, mikäli viittauksia
kenttään olisi ollut toisaalla.
o
Attribuutin ominaisuuksien muuttaminen: ALTER
Esimerkki: ALTER TABLE COMPANY.DEPARTMENT
ALTER MGRSSN DROP DEFAULT;
* poistaa taulun DEPARTMENT sarakkeelta MGRSSN sille annetun oletusarvon.
Esimerkki: ALTER TABLE COMPANY.DEPARTMENT
ALTER MGRSSN SET DEFAULT "333445555";
* asettaa osaston johtajalle oletusarvoksi Franklin Wongin henkilötunnuksen.
Esimerkki: ALTER TABLE COMPANY.EMPLOYEE DROP CONSTRAINT EMPSUPERFK CASCADE;
* lakkauttaa rajoituksen EMPSUPERFK voimassaolon taulusta EMPLOYEE.
8.4 SQL:n peruskyselyt
•
SELECT-lauseessa ilmoitetaan, mitkä kentät halutaan mukaan tulostauluun.
•
Kannattaa huomioida, että SQL:n SELECT-lause ei vastaa relaatioalgebran valintaoperaattorin 
merkitystä, vaan muistuttaa pikemminkin projektiota!
•
Lisäksi, SQL sallii duplikaattien esiintymisen tulostauluissa toisin kuin relaatioalgebra. Siten SQL:llä
tuotetut taulut ovat käsitteellisesti joukkojen sijaan monijoukkoja (= multiset ).
•
Duplikaatit saadaan poistettua valitsimella DISTINCT.
8.4.1 SELECT-FROM-WHERE -lause
•
SELECT-lauseen rakenne on muotoa
SELECT <attribuuttilista>
FROM <taululista>
WHERE <ehdot>;
missä <attribuuttilista> sisältää ne attribuutit, joiden halutaan näkyvän kyselyn vastauksessa,
<taululista> sisältää ne taulut, joita kyselyn toteuttamiseksi tarvitaan riippumatta siitä, esiintyykö
taulujen kenttiä vastauksessa vai ei, ja <ehdot> kuvaavat kriteerit, jotka täyttävät tuplat
hyväksytään vastaukseen ( valinta- ja liitosehdot ).
•
Attribuutti- ja taululistan jäsenet erotetaan toisistaan pilkuin, ehdot puolestaan loogisin
operaattorein.
•
Attribuuttilistan attribuuttien järjestys määrää tulostaulun attribuuttien järjestyksen.
•
Esimerkkejä: Esimerkkien numerointi QX viittaa kirjaan
1) Haetaan syntymäaika ja osoite kaikilta työntekijöiltä, joiden nimi on 'John B. Smith'. Kaikki
tarvittavat tiedot löytyvät yhdestä taulusta.
Q0: SELECT BDATE, ADDRESS
FROM EMPLOYEE
WHERE FNAME='John' AND MINIT='B' AND LNAME='Smith';
2) Haetaan etu- ja sukunimi sekä osoite kaikilta työntekijöiltä, jotka työskentelevät
tutkimusosastolla. Vaikka kaikki tuloskentät ovat taulussa EMPLOYEE, tarvitaan avuksi taulua
DEPARTMENT, jotta päästäisiin käsiksi tarkalleen tutkimusosaston työntekijöihin. Tehdään liitos
osaston ja työntekijän välille käyttämällä liitosattribuuttina osastonumeroa.
Q1: SELECT FNAME, LNAME, ADDRESS
FROM EMPLOYEE, DEPARTMENT
WHERE DNAME='Research' AND DNUMBER=DNO;
3) Etsitään jokaisen Staffordissa toimivan projektin projektinumero, projektia kontrolloivan osaston
numero, sekä osaston johtajan sukunimi, osoite ja syntymäaika. Nyt tarvitaan avuksi liitos sekä
projektin ja osaston että osaston ja työntekijän välille.
Q2: SELECT PNUMBER, DNUM, LNAME, ADDRESS, BDATE
FROM PROJECT, DEPARTMENT, EMPLOYEE
WHERE DNUM=DNUMBER AND MGRSSN=SSN AND PLOCATION='Stafford';
8.4.2 Saman niminen sarake useassa kyselyyn osallistuvassa taulussa, uudelleennimeäminen ( aliasointi ) ja
tuplamuuttujat
•
Mikäli saman niminen attribuutti esiintyy useassa kyselyyn osallistuvassa taulussa, pitää ne erotella
toisistaan joko esittelemällä attribuutin nimen yhteydessä myös viittauksen kohteena olevan taulun
nimi tai käyttämällä hyväksi uudelleennimeämistä.
Esimerkki: Kuvitellaan, että taulun EMPLOYEE sukunimeä ja taulun DEPARTMENT osaston nimeä
edustaisikin tunnus NAME tunnuksien LNAME ja DNAME sijaan, ja attribuutti DNO
olisikin nimetty DNUMBERiksi.
Tällöin kysely 2 eli Q1 ei olisikaan enää tulkittavissa yksikäsitteisesti ilman taulujen
esittelyä, sillä ei tiedettäisi, tarkoitetaanko tunnuksilla NAME ja DNUMBER taulun EMPLOYEE
vai DEPARTMENT kenttiä.
•
Seuraava versio kyselystä 2 ( eli kysely 4 ) ( = Q1A ) korjaa tilanteen kuvittelemiemme kaltaisilla
attribuuttien nimillä:
Q1A: SELECT FNAME, EMPLOYEE.NAME, ADDRESS
FROM EMPLOYEE, DEPARTMENT
WHERE DEPARTMENT.NAME = 'Research' AND
DEPARTMENT.DNUMBER = EMPLOYEE.DNUMBER;
•
Kenttien nimien yksikäsitteisyys häviää myös silloin, kun tehdään liitos taulun itsensä kanssa.
Tällöin voidaan ottaa käyttöön ns. tuplamuuttuja ( = tuple variable ), jonka avulla saadaan taulun
nimet erilaisiksi liitoksen eri rooleissa. Uudelleennimeämisessä eli aliasoinnissa voidaan
haluttaessa käyttää apuna varattua sanaa AS, mutta sen voi myös jättää pois.
•
Seuraavassa esimerkissä 5) halutaan listata kaikkien työntekijöiden etu- ja sukunimi sekä heidän
välittömän esimiehensä etu- ja sukunimi.
Q8: SELECT E.FNAME, E.LNAME, S.FNAME, S.LNAME
FROM EMPLOYEE AS E, EMPLOYEE AS S
WHERE E.SUPERSSN = S.SSN;
•
Haluttaessa voidaan taulujen uudelleennimeämisen yhteydessä nimetä myös taulun sarakkeet
uudelleen FROM-lauseessa.
Esimerkki: Nimetään EMPLOYEE-taululle alias E, jonka kentät on nimetty uudelleen seuraavasti:
SELECT ...
FROM EMPLOYEE AS E( FN, MI, LN, SSN, BD, ADDR, SEX, SAL, SSSN, DNO )
WHERE ...
•
Taulujen uudelleennimeäminen voidaan tulkita kopioiden ottamiseksi alkuperäisestä taulusta.
Esimerkiksi FROM-lauseessa annetut EMPLOYEE E ja EMPLOYEE S tekevät sekä E:stä että S:stä
taulun EMPLOYEE edustajia.
•
Lyhyiden aliasnimien käyttäminen lyhentää kätevästi SQL-komentoja.
6) Toteutetaan uudelleen kysely 4) käyttämällä hyväksi aliasnimiä työntekijä- ja osastotauluille:
Q1B: SELECT E.FNAME, E.NAME, E.ADDRESS
FROM EMPLOYEE E, DEPARTMENT D
WHERE D.NAME = 'Research' AND D.DNUMBER = E.DNUMBER
•
Edellisessä kyselyssä E ja D ovat tuplamuuttujan asemassa. Mikäli WHERE-lauseen jokaista taulua
kohti perustetaan tuplamuuttuja, kysely muistuttaa vastaavaa tupla-relaatiokalkyylin kyselyä.
Q1: { e.FNAME, e.LNAME, e.ADDRESS | EMPLOYEE ( e ) AND
(  d ) | ( DEPARTMENT ( d ) AND d.NAME = 'Research' AND d.DNUMBER = e.DNO ) }
8.4.3 Puuttuva WHERE-lause ja tähtisymbolin käyttö
•
Mikäli kyselyssä ei haluta asettaa käsiteltävien taulujen tuplille mitään valinta- eikä liitosehtoa, WHERElausetta ei kirjoiteta.
•
Jos kysely, josta WHERE-lause puuttuu, kohdistuu vain yhteen tauluun, tulostetaan SELECT-lauseessa
mainitut attribuutit taulun kaikista tuplista.
•
Jos tällainen kysely kohdistuu useaan tauluun, muodostetaan taulujen välinen karteesinen tulo
projisoituna SELECT-lauseen mukaisille attribuuteille.
7) Listataan jokaisen työntekijän sosiaaliturvatunnus.
Q9: SELECT SSN
FROM EMPLOYEE;
8) Listataan kaikki sosiaaliturvatunnusten ja osastojen nimien yhdistelmät, myös mahdolliset
duplikaatit. Tulokseksi saadaan taulujen EMPLOYEE ja DEPARTMENT karteesinen tulo, joka sisältää
SELECT-osassa luetellut attribuutit ( sinänsä varsin hyödytön kysely ).
Q10: SELECT SSN, DNAME
FROM EMPLOYEE, DEPARTMENT;
•
Mikäli jostain taulusta halutaan listata kaikki attribuutit, voidaan tämän pyynnön esittämiseksi käyttää
symbolia * sen sijaan, että kaikki attribuutit jouduttaisiin luettelemaan.
9) Listataan kaikki tiedot työntekijöistä, jotka ovat töissä osastolla 5.
Q1C: SELECT *
FROM EMPLOYEE
WHERE DNO = 5;
10) Listataan tutkimusosaston työntekijöistä kaikki työntekijää koskevat tiedot ja niiden perään
kaikki osaston tiedot.
Q1D: SELECT *
FROM EMPLOYEE, DEPARTMENT
WHERE DNAME = 'Research' AND DNO = DNUMBER;
11) Listataan työntekijöiden ja osastojen kaikki attribuutit sisältävä karteesinen tulo.
Q10A: SELECT *
FROM EMPLOYEE, DEPARTMENT;
8.4.4 Taulujen käsittely joukkoina SQL:ssä
•
Toisin kuin relaatioalgebra, SQL tulkitsee taulun tuplat oletuksen mukaisesti joukon sijasta
monijoukoksi, s. o. duplikaatteja saa esiintyä. Näin toimitaan, sillä
o
Duplikaattien poistaminen vaatii tuplien lajittelun, mikä hidastuttaa vasteaikoja.
o
Duplikaattien tulostaminen saattaa olla käyttäjälle kaikesta huolimatta hyödyllistä.
o
Aggregaattifunktioita sovellettaessa duplikaatit joudutaan yleensä kuitenkin huomioimaan.
•
Duplikaattien listaaminen voidaan estää antamalla SELECT-lauseeseen optio DISTINCT.
•
Duplikaatit hyväksyvä optio ALL on puolestaan oletuksena, joten se voidaan jättää pois haluttaessa
duplikaatit näkyviin.
12) Listataan kaikkien työntekijöiden palkka näkyviin riippumatta siitä, vaikka samaa palkkaa
esiintyisi usealla työntekijällä
----> tuloksena yhtä monta tuplaa kuin työntekijöitä:
Q11: SELECT ALL SALARY
FROM EMPLOYEE;
13) Jos kutakin eri suuruista palkkaa halutaan näkyville vain kuitenkin kertaalleen, pitää toimia
seuraavasti
----> tuloksena yhtä monta tuplaa kuin erilaisia palkkoja esiintyy:
Q11A: SELECT DISTINCT SALARY
FROM EMPLOYEE;
•
SQL:ssä on valmiina lauseet myös joukkojen unionin ( UNION ), erotuksen ( EXCEPT ) ja
leikkauksen ( INTERSECT ) esittämistä varten. Tosin kaikki järjestelmät eivät tue
erotusoperaatiota. Operaatioihin osallistuvat osakyselyt kirjoitetaan sulkeiden sisään.
14) Muodostetaan unionia hyväksi käyttäen kysely, jossa halutaan selvittää projektit, joissa Smithniminen henkilö toimii joko projektia kontrolloivan osaston johtajana tai itse projektin
työntekijänä. Alkuosassa tutkitaan Smith-nimisten toimiminen projekteja kontrolloivien
osastojen johtajina, loppuosassa heidän työskentelemisensä eri projekteissa.
Q4: ( SELECT DISTINCT PNUMBER
FROM PROJECT, DEPARTMENT, EMPLOYEE
WHERE DNUM = DNUMBER AND MGRSSN = SSN AND LNAME = 'Smith' )
UNION
( SELECT DISTINCT PNUMBER
FROM PROJECT, WORKS_ON, EMPLOYEE
WHERE PNUMBER = PNO AND ESSN = SSN AND LNAME = 'Smith' );
•
SQL-99:ssä on käytettävissä vastaavat lauseet myös monijoukkojen käsittelyyn
( UNION ALL, EXCEPT ALL, INTERSECT ALL ).
8.4.5 Osajonovertailut ja aritmeettiset operaatiot
•
Merkkijono-, päivämäärä- ja aikatyyppiä edustaviin kenttiin voidaan kohdistaa osajonovertailuja, eli
tutkia, löytyykö jotain tiettyä mallia
( =merkkijonoa ) noudattava osuus tarkasteltavana olevasta kentästä.
•
Tätä tarkoitusta varten on käytettävissä operaattori LIKE. Etsittävä malli kirjoitetaan yksinkertaisten
lainausmerkkien sisään.
•
Mielivaltaisen mittaista ( myös tyhjää ) merkkijonoa kuvaa symboli %, ja yksittäistä mielivaltaista
merkkiä ( ei-puuttuvaa ) edustaa alaviiva ( _ ).
15) Etsitään kaikki työntekijät, joiden osoitteessa esiintyy joissain kohtaa merkkijono
'Houston, TX'.
Q12: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE ADDRESS LIKE '%Houston, TX%';
16) Etsitään kaikki työntekijät, jotka ovat syntyneet 1950-luvulla ( oletetaan varovasti, ettei
vähintään sata vuotta aikaisemmin syntyneitä enää ole yrityksen palveluksessa ... ):
Q12A: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE BDATE LIKE '__5_______';
Päiväys on muotoa VVVV-KK-PP, joten kolmannen merkin pitää olla numero 5, ja loput eli
merkit 1-2 ja 4-10 saavat olla mitä tahansa.
•
Mikäli kenttä voi sisältää symboleita % ja _, ja juuri tällainen merkki esiintyy etsittävässä mallissa,
pitää niiden eteen kirjoittaa tunnistemerkki  vaikkapa kenoviiva (\)  ja esitellä käytetty
tunnistemerkki mallin jälkeen option ESCAPE perään lainausmerkkien sisään.
Esimerkki: Haetaan mallia 'AB_CD%EF'. Tällöin hakulause olisi muotoa
... LIKE 'AB\_CD\%EF' ESCAPE '\';
•
Samasta syystä merkkijonoon kuuluvat lainausmerkit pitää kyselyiden yhteydessä kahdentaa, jottei
tulkittaisi merkkijonon esittelyä päättyneeksi:
Esimerkki: Mallin 's-Gravenhage ( = pidempi hollanninkielinen versio kaupungin Haag nimestä )
etsintä tapahtuisi lauseella
... LIKE '''s-Gravenhage'
•
Numeerisille kentille voidaan soveltaa aritmeettisia peruslaskutoimituksia eli yhteen- (+),
vähennys (-), kerto- (*) ja jakolaskua (/). Desimaalierottimena toimii yleensä piste (.).
17) Listataan, miltä projektissa 'ProductX' toimivien työntekijöiden palkat näyttäisivät 10%:n
korotuksen jälkeen.
Q13: SELECT FNAME, LNAME, 1.1*SALARY
FROM EMPLOYEE, WORKS_ON, PROJECT
WHERE SSN = ESSN AND PNO = PNUMBER AND PNAME = 'ProductX';
•
Kannattaa huomioida, ettei edellinen kysely suinkaan päivitä 'ProductX'-projektin työntekijöiden
palkkoja tauluun EMPLOYEE, vaan tuottaa pelkän tulostaulun, jossa palkkoja on korotettu.
•
Merkkijonotyyppisille kentille voidaan soveltaa yhdistämis- eli katenaatio-operaatiota (||).
•
Operaattorit (+) ja (-) tarkoittavat päivämäärä-, aika- ja aikaleimakentille yhdellä lisäämistä
( increment ) tai vähentämistä ( decrement ).
•
Operaattoria BETWEEN käytetään muodossa X BETWEEN Y AND Z, ja se on synonyymi
kaksoisepäyhtälölle Y  X  Z.
18) Listataan kaikki tiedot osaston 5 työntekijöistä, joiden palkka on vähintään 30000 ja
korkeintaan 40000.
Q14: SELECT *
FROM EMPLOYEE
WHERE ( SALARY BETWEEN 30000 AND 40000 ) AND DNO = 5;
8.4.6 Kyselyn tulostaulun tuplien lajittelu
• Tulostaulun tuplat voidaan lajitella valittujen kenttien mukaisesti nousevaan
tai laskevaan suuruusjärjestykseen käyttämällä ORDER BY -lausetta.
•
ORDER BY -lauseen oletuksena on ei-vähenevä suuruusjärjestys (ASC). Ei-kasvava suuruusjärjestys
saadaan aikaan optiolla DESC.
19) Listataan kaikkien työntekijöiden työskentelytiedot eri projekteissa aakkosjärjestyksessä ensin
työntekijän osaston ja sitten suku- ja etunimen mukaan.
Q15: SELECT DNAME, LNAME, FNAME, PNAME
FROM DEPARTMENT, EMPLOYEE, WORKS_ON, PROJECT
WHERE DNUMBER = DNO AND SSN = ESSN AND PNO = PNUMBER
ORDER BY DNAME, LNAME, FNAME;
•
Jos haluttaisiin listata osastojen nimet käännetyssä aakkosjärjestyksessä mutta etu- ja sukunimet
normaalissa aakkosjärjestyksessä, ORDER BY -lause näyttäisi seuraavalta ( ASC-optiot voidaan
jättää pois ):
ORDER BY DNAME DESC, LNAME ASC, FNAME ASC;
8.5 Aiempia monimutkaisempia SQL-kyselyjä
•
Tähän mennessä tehdyt kyselyt on voitu toteuttaa suoraviivaisesti, sillä liitosehdot ovat olleet
suoraan ilmaistavissa attribuuttien arvojen avulla.
•
Kuitenkin saattaa toisinaan olla tarpeen tehdä kysely, joka on liian monimutkainen toteutettavaksi
yksivaiheisena.
8.5.1 Vertailut NULL-arvojen kanssa ja kolmiarvologiikka
•
Kuten jo kappaleessa 5.1.2 todettiin, arvolla NULL on kolme erilaista tulkintaa
1.
2.
3.
Arvo on varmasti olemassa, mutta jostain syystä sitä ei ole tallennettu ( esimerkiksi
syntymäajan puuttuminen työntekijältä ).
Arvoa ei ole saatavilla ( esimerkiksi salainen puhelinnumero )
Arvoa ei ole määriteltävissä ( esimerkiksi tiedot suoritetuista loppututkinnoista opiskelijalla, jolla
ei ole aikaisempia tutkintoja )
•
Puuttuvaa arvoa voidaan testata operaattoreilla IS NULL tai IS NOT NULL. Ensimmäinen palauttaa
totuusarvon tosi silloin, kun tarkasteltava kenttä on puuttuva ja jälkimmäinen silloin, kun kenttään on
syötetty jokin todellinen arvo.
•
SQL käsittelee liitoksissa eri paikkoihin tallennettuja NULL-arvoja erillisinä, joten tästä syystä arvo
NULL liitoskentissä ei toteuta normaalin ( eli muun kuin ulkoisen ) liitoksen liitosehtoa. Tästä syystä ei
yleensä arvoa NULL vastaan tapahtuvaa vertailua myöskään esitetä matemaattisten operaattoreiden
= ja  avulla.
•
NULL-arvojen käsittelyyn sovelletaan SQL:ssä ns. kolmiarvologiikkaa ( tosi / epätosi / tuntematon )
perinteisen kaksiarvologiikan ( tosi / epätosi ) asemesta.
•
Seuraavassa ovat esiteltyinä kolmiarvologiikan totuusarvotaulut loogisille operaattoreille JA, TAI ja EI:
___JA
TOSI
EPÄTOSI
TUNTEMATON
TOSI
TOSI
EPÄTOSI
TUNTEMATON
EPÄTOSI
EPÄTOSI
EPÄTOSI
EPÄTOSI
TUNTEMATON
EPÄTOSI
TUNTEMATON
TUNTEMATON
TAI
TOSI
EPÄTOSI
TUNTEMATON
TOSI
TOSI
TOSI
TOSI
EPÄTOSI
TOSI
EPÄTOSI
TUNTEMATON
TUNTEMATON
TOSI
TUNTEMATON
TUNTEMATON
____EI___________________
TOSI
EPÄTOSI
TUNTEMATON
EPÄTOSI
TOSI
TUNTEMATON
• Tarkastellaan seuraavaksi esimerkkiä, jossa vertailu kohdistuu attribuutin NULL-arvoon.
20) Etsitään työntekijät, joilla ei ole esimiestä:
Q18: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE SUPERSSN IS NULL;
8.5.2 Sisäkkäiset kyselyt, tuplat ja joukko- / monijoukkovertailut
•
Sisäkkäistä kyselyä voidaan käyttää silloin, kun tuloksen määrääminen perustuu jonkin toisen
kyselyn tulokseen.
•
Myös silloin, kun yksitasoinen kysely on mahdollinen, voidaan käyttää sisäkkäisiä kyselyitä avuksi.
•
Sisempi kysely esitellään WHERE-lauseessa joko aritmeettisen, operaattorin IN tai funktioiden
EXISTS ja NOT EXISTS jälkeen ( IN = joukkoon kuulumisrelaatio ).
•
Sisempi kysely ( = alikysely ) kirjoitetaan sulkeiden sisään.
21) Toteutetaan kysely 14 (= Q4A ) uudelleen sisäkkäisenä kyselynä ilman unionioperaatiota.
Q4A: SELECT DISTINCT PNUMBER
FROM PROJECT
WHERE PNUMBER IN ( SELECT PNUMBER
FROM PROJECT, DEPARTMENT, EMPLOYEE
WHERE DNUM=DNUMBER AND MGRSSN=SSN AND
LNAME = 'Smith' )
OR
PNUMBER IN ( SELECT PNO
FROM WORKS_ON, EMPLOYEE
WHERE ESSN = SSN AND LNAME = 'Smith' );
Ylempi alikysely tuottaa edellä luettelon projekteista, joita kontrolloivia osastoja Smith-niminen henkilö
johtaa, ja alempi alikysely luettelon projekteista, joissa Smith-niminen henkilö toimii työntekijänä.
Ulompi kysely vertaa PROJECT-taulun projektinumeroiden kuulumista jommankumman alikyselyn
tulokseen, joten sen FROM-lauseessa ei tarvita muita tauluja kuin PROJECT. Ulompi kysely poistaa
duplikaatit alikyselyjen tuloksista.
22) Selvitetään, ketkä henkilöt tekevät henkilön kanssa, jonka henkilötunnus on '123456789',
ainakin yhdessä projektissa saman määrän työtunteja viikossa. Duplikaatit poistetaan
vastauksesta.
SELECT DISTINCT ESSN
FROM WORKS_ON
WHERE ( PNO, HOURS ) IN ( SELECT PNO HOURS
FROM WORKS_ON
WHERE ESSN = '123456789' );
•
Yllä olevassa kyselyssä verrataan tuplan osien vastaavuutta keskenään. Kulloinkin valittuna olevan
taulun WORKS_ON osatuplan ( attribuuttiparin Projektinumero, Työtunnit ) pitää löytyä alikyselyn
tulostaulusta. Mikäli tällainen löytyy, kyseisen tuplan henkilötunnus päätyy ulomman kyselyn
tulostauluun.
•
IN-operaattorin asemesta voidaan käyttää myös matemaattisia vertailuoperaattoreita täydennettynä
optioilla ANY ( = SOME ) tai ALL. Tällöin voidaan tutkia, täyttääkö jokin alikyselyn tuloksen tuplista
vertailuoperaattorin mukaisen ehdon.
23) Listataan työntekijät, joiden palkka on korkeampi kuin jokaisella osaston 5 työntekijöistä.
SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE SALARY > ALL ( SELECT SALARY
FROM EMPLOYEE
WHERE DNO = 5 );
•
Mikäli sisemmässä kyselyssä esiintyy attribuutin nimi ilman pistenotaatiota, ja saman niminen
attribuutti esiintyy myös ulommassa kyselyssä jossain toisessa taulussa, sisemmän kyselyn
määrittely on voimakkaampi ( vrt. ohjelmointikielten muuttujien näkyvyysalueet ).
24) Listataan työntekijät, joilla on saman niminen ja samaa sukupuolta oleva perheenjäsen kuin hän
itse on.
Q16: SELECT E.FNAME, E.LNAME
FROM EMPLOYEE AS E
WHERE E.SSN IN ( SELECT ESSN
FROM DEPENDENT
WHERE E.FNAME = DEPENDENT_NAME AND E.SEX = SEX );
Kyselyn viimeisen rivin kenttä SEX viittaa nyt tauluun DEPENDENT, koska sisemmässä kyselyssä
käytetään kyseistä taulua. Jos sisemmässä kyselyssä tarvittaisiin myös taulua EMPLOYEE,
pitäisi taulut EMPLOYEE ja DEPENDENT nimetä uudelleen nimikonfliktin välttämiseksi
kentässä SEX.
8.5.3 Korreloivat sisäkkäiset kyselyt
•
Edellisen esimerkin kyselyä kutsutaan ns. korreloivaksi sisäkkäiseksi kyselyksi, sillä ulomman kyselyn
taulun attribuutin arvoa verrataan sisemmässä kyselyssä esiintyvän taulun attribuutin arvoon.
Tulkinnallisesti tämä tarkoittaa sitä, että kutakin ulomman kyselyn tuplaa kohti generoidaan sisempi
kysely ja tutkitaan liitosehdon toteutumista.
•
Mikäli kaksitasoinen kysely on muotoa SELECT-FROM-WHERE, jossa käytetään operaattoria
IN tai =, se voidaan esittää aina yksitasoisena kyselynä.
25) Kirjoitetaan kysely 24 toisin yksitasoisena.
Q16A: SELECT E.FNAME, E.LNAME
FROM EMPLOYEE AS E, DEPENDENT AS D
WHERE E.SSN = D.SSN AND E.SEX = D.SEX AND E.FNAME = D.DEPENDENT_NAME;
•
Harjoitustehtävä: Yritä tehdä kyselylle 21 samoin kuin edellä kyselylle 24
( vihje: 'monista' taulua WORKS_ON ).
•
Operaation CONTAINS avulla voidaan suorittaa relaatioiden jakolaskuoperaatio. Operaatio tosin
puuttuu monista relaatiotietokantajärjestelmistä.
26) Listaa niiden henkilöiden nimet, jotka työskentelevät kaikissa osaston 5 kontrolloimissa
projekteissa.
Q3: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE ( ( SELECT PNO
FROM WORKS_ON
WHERE SSN = ESSN )
CONTAINS
( SELECT PNUMBER
FROM PROJECT
WHERE DNUM = 5 ) );
Alikyselyn ensimmäinen osa etsii kaikki projektit, joissa työntekijä on töissä, ja toinen osa valitsee
kaikki ne projektit, joita osasto 5 kontrolloi. Jos kaikki loppuosan projektinumerot sisältyvät
alkuosaan, henkilö tulee valituksi tulostauluun.
8.5.4 EXISTS- ja UNIQUE-funktiot SQL:ssä
•
EXISTS-funktio testaa, kuuluuko alikyselyn tulokseen yhtään tuplaa ( jos kuuluu, on
samantekevää, montako ) vai ei.
27) Tehdään kysely 23 ( = Q16 ) käyttämällä hyväksi EXISTS-funktiota.
Q16B: SELECT E.FNAME, E.LNAME
FROM EMPLOYEE AS E
WHERE EXISTS ( SELECT *
FROM DEPENDENT
WHERE E.SSN = ESSN AND E.SEX = SEX AND
E.FNAME = DEPENDENT_NAME );
Mikäli alikyselyn vastaukseksi saadaan yksikin tupla tarkasteltavaa työntekijää kohti ( eli
työntekijällä on ainakin yksi saman niminen ja samaa sukupuolta oleva perheenjäsen ),
kyseinen työntekijä tulee valituksi.
•
Vastaavasti voidaan käyttää funktiota NOT EXISTS, joka palauttaa totuusarvon tosi silloin, kun
alikyselyn tulos on tyhjä relaatio. 28) Listataan työntekijät, joilla ei ole perheenjäseniä.
Q6: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE NOT EXISTS ( SELECT *
FROM DEPENDENT
WHERE SSN = ESSN );
Jos alikyselyn tulos on tyhjä, henkilöllä ei ole perheenjäseniä, jolloin työntekijä tulee valituksi.
•
Tarkastellaan vielä paria lisäesimerkkiä.
29) Listataan osastonjohtajat, joilla on ainakin yksi perheenjäsen ( kaksi korreloivaa
sisäkkäistä kyselyä ).
Q7: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE EXISTS ( SELECT *
FROM DEPENDENT
WHERE SSN = ESSN )
AND
EXISTS ( SELECT *
FROM DEPARTMENT
WHERE SSN = MGRSSN );
30) Toteutetaan kysely 25 ilman CONTAINS-funktiota ( jakolasku R:S on sama asia kuin erotus
S—R =  ).
Q3A: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE NOT EXISTS ( ( SELECT PNUMBER
FROM PROJECT
WHERE DNUM = 5 )
EXCEPT
( SELECT PNO
FROM WORKS_ON
WHERE SSN = ESSN ) );
Alikyselyn alkuosa muodostaa listan projekteista, joita osasto 5 kontrolloi. Loppuosa puolestaan
etsii ne projektit, joissa kulloinkin tarkasteltava henkilö työskentelee. Jos henkilö työskentelee
kaikissa osaston 5 projekteissa, on erotus tyhjä, jolloin NOT EXISTS palauttaa arvon tosi, ja
henkilö tulee valituksi koko kyselyn vastaukseen.
31) Koska EXCEPT-operaatio puuttuu monesta SQL-järjestelmästä, kierretään seuraavassa sekin!
Q3B: SELECT LNAME, FNAME
FROM EMPLOYEE
WHERE NOT EXISTS ( SELECT *
FROM WORKS_ON B
WHERE ( B.PNO IN ( SELECT PNUMBER
FROM PROJECT
WHERE DNUM = 5 ) )
AND
NOT EXISTS ( SELECT *
FROM WORKS_ON C
WHERE C.ESSN = SSN AND
C.PNO = B.PNO ) );
Toisen tason kysely listaa kaikki ne projektit, joita osasto 5 kontrolloi. Kolmannen tason kysely tutkii,
osallistuuko sama yksittäinen työntekijä kuhunkin osaston 5 kontrolloimaan projektiin. Jos löytyy
yksikin sellainen osaston 5 projekti, jossa tarkastelun kohteena oleva työntekijä ei toimi, sisempi
NOT EXISTS palauttaa arvon tosi. Tällöin toisen tason kyselyn AND-operaatio tuottaa tuloksen tosi,
jolloin ulompi NOT EXISTS palauttaa arvon epätosi. Henkilö tulee valituksi koko kyselyn
vastaukseen
ainoastaan silloin, kun ei ole yhtään sellaista osaston 5 projektia, jossa hän ei työskentele.
•
Mikäli halutaan testata, tuottaako alikysely vastaukseksi duplikaatteja, voidaan käyttää funktiota
UNIQUE ( Q ).
8.5.5 Eksplisiittiset joukot ja attribuuttien uudelleen nimeäminen SQL:ssä
•
SQL:ssä on mahdollista testata attribuutin arvon kuulumista eksplisiittisesti esiteltyyn
vakiojoukkoon. Joukkoon kuulumista kuvaa operaattori IN. Vakiojoukko esitellään sulkeiden sisällä,
ja joukon alkiot erotetaan toisistaan pilkuilla.
32) Listataan henkilötunnukset kaikilta niiltä työntekijöiltä, jotka toimivat ainakin jossain
projekteista 1, 2 ja 3:
Q17: SELECT DISTINCT ESSN
FROM WORKS_ON
WHERE PNO IN ( 1, 2, 3 );
•
SELECT-lauseessa voidaan valituiksi tulevat attribuutit vaihtaa tarvittaessa toisen nimisiksi.
33) Listataan jokaisen työntekijän ja hänen lähimmän esimiehensä sukunimi:
Q8A: SELECT E.LNAME AS EMPLOYEE_LNAME,
S.LNAME AS SUPERVISOR_NAME
FROM EMPLOYEE AS E, EMPLOYEE AS S
WHERE E.SUPERSSN = S.SSN
8.5.6 Liitostaulut SQL:ssä
•
SQL-99:ssä on mahdollista esitellä liitos jo FROM-lauseessa, mikä
selkeyttää jonkin verran kyselyjä, sillä nyt voidaan liitos- ja valintaehdot
erotella toisistaan. Liitoksen esittelyssä käytetään merkintää
taulu1 ( INNER ) JOIN taulu2 ON liitosehto.
34) Etsitään jälleen tutkimusosastolla työskentelevien nimi- ja osoitetiedot:
Q1A: SELECT FNAME, LNAME, ADDRESS
FROM ( EMPLOYEE JOIN DEPARTMENT ON DNO = DNUMBER )
WHERE DNAME = 'Research';
•
FROM-lauseessa esiteltävä liitos voi olla tyypiltään myös luonnollinen ( NATURAL JOIN ) tai ulkoinen
liitos ( LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL ( OUTER ) JOIN ). Samassa yhteydessä
voidaan nimetä liitokseen osallistuville tauluille ja niiden attribuuteille aliaksia. Näin on meneteltävä, jos
tehdään luonnollinen liitos, eikä liitoksen tauluilla ole yhtään keskenään saman nimistä attribuuttia.
35) Tehdään kysely 34 uudelleen käyttämällä luonnollista liitosta:
Q1B: SELECT FNAME, LNAME, ADDRESS
FROM ( EMPLOYEE NATURAL JOIN ( DEPARTMENT AS
DEPT ( DNAME, DNO, MSSN, MSDATE ) ) ) WHERE DNAME = 'Research';
36) Listataan jokainen työntekijä ja hänen esimiehensä, vaikka esimiestä ei työntekijällä olisikaan
( tarvitaan avuksi vasen ulkoinen liitos ):
Q8B: SELECT E.LNAME AS EMPLOYEE_NAME, S.LNAME AS SUPERVISOR_NAME
FROM ( EMPLOYEE AS E LEFT OUTER JOIN EMPLOYEE AS S ON
E.SUPERSSN = S.SSN );
•
Myös usean liitoksen esitteleminen samalla onnistuu haluttaessa FROM-lauseessa.
37) Listataan jokaisen Staffordin projektin projektinumero, projektia kontrolloivan osaston numero
sekä kyseisen osaston johtajan sukunimi, osoite ja syntymäaika:
Q2A: SELECT PNUMBER, DNUM, LNAME, ADDRESS, BDATE
FROM ( ( PROJECT JOIN DEPARTMENT ON DNUM = DNUMBER ) JOIN
EMPLOYEE ON MGRSSN = SSN )
WHERE PLOCATION = 'Stafford';
8.5.7 Koostefunktiot SQL:ssä
•
SQL:ssä on käytettävissä aggregaattifunktiot COUNT, SUM, MAX, MIN ja AVG. Näiden merkitykset
vastaavat kappaleessa 6.4.1 esitettyjä.
•
Aggregaattifunktioita voidaan käyttää SELECT- ja HAVING-lauseissa ( jälkimmäinen esitellään
myöhemmin ).
•
Funktioita MIN ja MAX voidaan käyttää myös ei-numeerisille attribuuteille, jos niiden arvojoukko on
täydellisesti järjestetty.
38) Listataan kaikkien työntekijöiden vuosipalkkojen kokonaissumma,
maksimi- ja minimipalkka sekä palkkojen keskiarvo:
Q19: SELECT SUM ( SALARY ), MAX ( SALARY ), MIN ( SALARY ), AVG ( SALARY )
FROM EMPLOYEE;
39) Listataan kyselyn 38 mukaiset koostetiedot ainoastaan tutkimusosaston työntekijöiltä:
Q20: SELECT SUM ( SALARY ), MAX ( SALARY ), MIN ( SALARY ), AVG ( SALARY )
FROM ( EMPLOYEE JOIN DEPARTMENT ON DNO = DNUMBER )
WHERE DNAME = 'Research';
40) Listataan työntekijöiden määrä koko yrityksessä:
Q21: SELECT COUNT ( * )
FROM EMPLOYEE;
Kyselyssä merkintä ( * ) funktion COUNT jälkeen merkitsee rivien eli tuplien määrää
taulussa EMPLOYEE.
41) Listataan työntekijöiden määrä tutkimusosastolla:
Q22: SELECT COUNT (*)
FROM EMPLOYEE, DEPARTMENT
WHERE DNO = DNUMBER AND DNAME = 'Research';
42) Listataan erisuuruisten palkkojen lukumäärä koko yrityksessä:
Q23: SELECT COUNT ( DISTINCT SALARY )
FROM EMPLOYEE;
Mikäli sana DISTINCT jätettäisiin pois, saataisiin sama vastaus kuin kyselyyn 40, sillä COUNT
ei ilman erillistä komentoa poista uplikaatteja. Kannattaa kuitenkin huomioida, että
COUNT ( SALARY ) ei kuitenkaan huomioisi tuplia, joissa palkkatieto olisi puuttuva!
•
Aggregaattifunktioita tarvitaan pelkkien koostetietojen tuottamisen lisäksi myös kyselyissä, joiden
valintaehdossa esiintyy lukumäärään perustuvia ehtoja.
43) Listataan työntekijät, joilla on vähintään 2 perheenjäsentä:
Q5: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE ( SELECT COUNT (*)
FROM DEPENDENT
WHERE SSN = ESSN ) >= 2;
•
Esimerkki 43 on luonteeltaan korreloiva 2-tasoinen kysely, jossa kutakin työntekijää kohti lasketaan
häneen liittyvien perheenjäsentuplien määrä taulussa DEPENDENT.
8.5.7 Ryhmittely: GROUP BY- ja HAVING-lauseet
•
Toisinaan on tarpeen ryhmitellä tuplat jonkin tietyn kentän arvojen mukaisesti ja laskea
ryhmäkohtaisia tilastotietoja. Tätä tarkoitusta varten SQL:ssä on käytettävissä lause GROUP_BY.
•
Kannattaa huomioida, että ryhmittelyattribuutin pitää esiintyä myös kyselyn SELECT-lauseessa.
44) Listataan työntekijöiden lukumäärä ja keskimääräinen palkka
osastokohtaisesti:
Q24: SELECT DNO, COUNT (*), AVG ( SALARY )
FROM EMPLOYEE
GROUP_BY DNO;
Kyselyn 44 tulostaulu on nähtävissä kirjan kuvassa 8.6(a).
45) Listataan jokaisesta projektista projektinumero, projektin nimi ja projektissa työskentelevien
henkilöiden lukumäärä:
Q25: SELECT PNUMBER, PNAME, COUNT (*)
FROM PROJECT, WORKS_ON
WHERE PNUMBER = PNO
GROUP BY PNUMBER, PNAME;
•
Jos ryhmittelyattribuutin arvo on NULL, perustetaan sitä varten oma rivi tulostauluun ( vrt. edellä
kysely 44, jos sallittaisiin tiedon työntekijän osastosta olevan puuttuva ).
•
Mikäli halutaan rajoittaa listaukseen otettavia ryhmiä, käytetään apuna HAVING-lausetta.
46) Listataan numero, nimi ja työntekijöiden lukumäärä jokaisesta sellaisesta projektista, jossa on
vähintään 3 työntekijää:
Q26: SELECT PNUMBER, PNAME, COUNT (*)
FROM PROJECT, WORKS_ON
WHERE PNUMBER = PNO
GROUP BY PNUMBER, PNAME
HAVING COUNT (*) > 2;
Kyselyn tulostaulu ilman projektinumeroa löytyy kirjan kuvasta 8.6(b).
•
Kannattaa huomioida, että WHERE-lauseen valintaehto valitsee yksittäisiä tuplia, mutta HAVINGlause valitsee tuplista koostuvia ryhmiä.
47) Listataan jokaisesta projektista sen numero, nimi ja osaston 5 työntekijöiden lukumäärä
projektissa:
Q27: SELECT PNUMBER, PNAME, COUNT ( * )
FROM PROJECT, WORKS_ON, EMPLOYEE
WHERE PNUMBER = PNO AND SSN = ESSN AND DNO = 5
GROUP BY PNUMBER, PNAME;
•
Kun SELECT- ja HAVING-lauseissa käytettyihin aggregaattifunktioihin liittyvät erilaiset ehdot, pitää
kyselyn rakentamisessa olla varovainen, jottei tuoteta virheellistä kyselyä.
Esimerkki: Oletetaan, että haluttaisiin listata osastokohtaisesti niiden työntekijöiden lukumäärä,
joiden palkka ylittää 40000, mutta kuitenkin vain sellaisilta osastoilta, joissa on
vähintään 6 työntekijää.
48) Kirjoitetaan alustavasti seuraava kyselyehdokas tehtävän ratkaisemiseksi:
SELECT DNAME, COUNT ( * )
FROM DEPARTMENT, EMPLOYEE
WHERE DNUMBER = DNO AND SALARY > 40000
GROUP BY DNAME
HAVING COUNT ( * ) > 5;
Tämä kyselyversio tuottaa kuitenkin virheellisen vastauksen, sillä se valitsee ainoastaan sellaiset
osastot, joilla on yli 40000 ansaitsevia työntekijöitä vähintään 6. Kyselyssä sovelletaan WHEREehtoa liian aikaisin eli ennen HAVING-lausetta, mikä ei ole tässä tapauksessa haluttu ratkaisu.
49) Kysely 48 joudutaan siten uusimaan kelvolliseksi seuraavaan muotoon:
SELECT DNUMBER, COUNT (*)
FROM DEPARTMENT, EMPLOYEE
WHERE DNUMBER = DNO AND SALARY > 40000 AND DNO IN ( SELECT DNO
FROM EMPLOYEE
GROUP BY DNO
HAVING COUNT > 5 )
GROUP BY DNUMBER;
Tämä kysely valitsee ne osastot, joita kohti taulussa EMPLOYEE on yli 5 työntekijää, ja jokaista
tällaista osastoa kohti lasketaan niiden työntekijöiden määrä, joiden palkka ylittää
40000:n rajan.
8.5.9 Yhteenveto SQL-kyselyistä
•
SQL-kielen kyselyiden yleinen muoto on esitelty seuraavassa. Hakasulkeiden sisälle merkityt osuudet
voivat olla puuttuvia.
SELECT < attribuutti - ja funktiolista >
FROM < taululista >
[ WHERE < ehto > ]
[ GROUP BY < ryhmittelyattribuutit > ]
[ HAVING < ryhmittelyehto >
[ ORDER BY < attribuuttilista >];
•
SELECT-lauseessa luetellaan tulostauluun haluttavat attribuutit ja koostefunktioita soveltamalla
tuotetut kentät.
•
FROM-lauseessa esitellään taulut, joita tarvitaan kyselyn toteuttamiseksi. Ainoastaan alikyselyissä
tarvittavia tauluja ei kuitenkaan esitellä.
•
WHERE-lause sisältää mahdolliset valinta- ja lisäksi liitosehdot, ellei liitostauluja esitelty jo edellä
FROM-lauseessa .
•
GROUP BY -lauseessa määritellään mahdolliset ryhmittelyattribuutit
•
HAVING-lauseessa esitellään tarvittaessa tuplien muodostamat ryhmät, jotka valitaan tarkasteluun.
•
ORDER BY -lauseella voidaan tarvittaessa käyttää tulostaulun lajittelemiseksi halutulla tavalla.
•
Kysely suoritetaan käsitteellisesti soveltamalla ensin FROM-lausetta, jotta tunnistettaisiin ensinnä
taulut,
joita ( uloimmassa ) kyselyssä tarvitaan sekä muodostettaisiin siinä esitellyt liitostaulut.
•
Tämän jälkeen suoritetaan järjestyksessä WHERE-, GROUP BY- ja HAVING-lauseet.
•
Käsitteellisesti viimeisenä suoritetaan tulostaulun tuplien lajittelu
ORDER BY -lauseen mukaisesti.
•
Ellei kyselyssä esiinny mitään lauseista GROUP BY, HAVING ja
ORDER BY, voidaan kysely tulkita suoritettavan käsitteellisesti seuraavasti:

•
Jokaista FROM-lauseessa esiteltyjen taulujen tuplien kombinaatiota kohti evaluoidaan WHERElause. Mikäli WHERE-lause palauttaa valittuna olevalle tuplien kombinaatiolle arvon 'Tosi',
kyseisestä tuplien kombinaatiosta listataan ne attribuutit, jotka esiintyvät SELECT-lauseessa.
Todellisuudessa tällainen prosessointitapa on kuitenkin tehoton. Kyselyiden optimointia käsitellään
tarkemmin vasta Tietokantojen jatkokurssilla.
8.6 Tuplan lisääminen, muuttaminen ja tuhoaminen SQL:llä
•
SQL-kielen kolme komentoa tietokannan sisällön päivittämiseksi ovat INSERT (lisäys), UPDATE
(muutos) ja DELETE (tuhoaminen).
8.6.1 Komento INSERT
•
Täyden uuden tuplan lisäämiseksi pitää kaikille sen attribuuteille asettaa arvot siinä järjestyksessä,
kuin attribuutit on kirjoitettu komennon CREATE TABLE yhteydessä.
•
Täydellisen tietueen ( kaikille attribuuteille syötetään arvo ) lisäyskomento on muotoa:
INSERT INTO taulu VALUES ( Attr1, Attr2, ..., AttrN );
50) Lisätään uusi tupla tauluun EMPLOYEE kaikkine arvoineen:
U1: INSERT INTO EMPLOYEE
VALUES ( 'Richard', 'K', 'Marini', '653298653', '1962-12-30', '98 Oak Forest, Katy, TX', 'M',
37000, '987654321', 4 );
•
Mikäli osa attribuuteista halutaan jättää syöttämättä, pitää taulun jälkeen selvittää, mihin kenttiin
syötettävät arvot sijoitetaan.
•
Muille kentille annetaan taulun määrittelyn yhteydessä annettu oletusarvo tai  ellei tällaista ole 
kentän tieto asetetaan puuttuvaksi arvolla NULL.
51) Lisätään uusi tupla tauluun EMPLOYEE, kun vain osa attribuuteista syötetään eksplisiittisesti:
U1A: INSERT INTO EMPLOYEE ( FNAME, LNAME, DNO, SSN )
VALUES ( 'Richard', 'Marini', 4, '653298653' );
•
Kerralla voidaan lisätä useita tuplia erottelemalla sulkeiden sisällä olevat arvolistat toisistaan pilkuilla.
Tietueen lisääminen estetään, mikäli tietokannan eheyssääntöjä rikotaan.
52) Seuraava lisäysoperaatio estetään, mikäli työntekijän osastonumeron pitää olla määriteltynä:
U2: INSERT INTO EMPLOYEE ( FNAME, LNAME, SSN, DNO )
VALUES ( 'Robert', 'Hatcher', '980760540', 2 );
53) Seuraava lisäysyritys tyrehtyisi SSN-kentän puuttumiseen EMPLOYEE-tuplasta, sillä arvoa NULL ei
sille saada asettaa oletusarvoksi ( kyseessä taulun pääavain ):
U2A: INSERT INTO EMPLOYEE ( FNAME, LNAME, DNO )
VALUES ( 'Robert', 'Hatcher', 5 );
•
Tauluun syöttö voi tapahtua myös kyselyyn saadun vastauksen perusteella.
54) Perustetaan taulu DEPTS_INFO, joka sisältää tiedot osaston nimestä, sen työntekijämäärästä
sekä palkkakustannuksista, ...
U3A: CREATE TABLE DEPTS_INFO
( DEPT_NAME VARCHAR( 15 ),
NO_OF_EMPS INTEGER,
TOTAL_SAL INTEGER );
55) ... ja syötetään sinne tiedot, jotka seuraava kysely tuottaa:
U3B: INSERT INTO DEPTS_INFO ( DEPT_NAME, NO_OF_EMPS, TOTAL_SAL )
SELECT DNAME, COUNT (*), SUM ( SALARY )
FROM ( DEPARTMENT JOIN EMPLOYEE ON DNUMBER = DNO )
GROUP BY DNAME;
8.6.2 Komento DELETE
•
Komennolla DELETE tuhotaan tuplia tietokannasta.
•
Yhdellä DELETE-komennolla voidaan poistaa joko yksi tai useampi tupla kerrallaan. Komento on
muotoa
DELETE FROM taulu WHERE ehto;
•
Mikäli tuhoamiskomennolle ei ole asetettu ehtoa, kaikki taulun tuplat hävitetään, mutta itse taulu
kuitenkin säilytetään.
8.6.2 Komento DELETE
56) Poistetaan kaikki Brown-nimiset työntekijät:
U4A: DELETE FROM EMPLOYEE
WHERE LNAME = 'Brown';
57) Poistetaan työntekijä, jonka hetu on '123456789':
U4B: DELETE FROM EMPLOYEE
WHERE SSN = '123456789';
58) Poistetaan tutkimusosaston työntekijät:
U4C: DELETE FROM EMPLOYEE
WHERE DNO IN ( SELECT DNUMBER
FROM DEPARTMENT
WHERE DNAME = 'Research' );
59) Poistetaan kaikki (!) työntekijät:
U4D: DELETE
FROM EMPLOYEE;
8.6.3 Komento UPDATE
•
Tietueiden sisällön muuttaminen tapahtuu UPDATE-komennolla. Komento on muotoa
UPDATE taulu SET muutokset WHERE ehto;
60) Muutetaan projektin 10 tietoja:
U5: UPDATE PROJECT
SET PLOCATION='Bellaire', DNUM=5
WHERE PNUMBER = 10;
61) Korotetaan tutkimusosaston työntekijöiden palkkoja 10 prosenttia.
U6: UPDATE EMPLOYEE
SET SALARY = SALARY*1.1
WHERE DNO IN ( SELECT DNUMBER
FROM DEPARTMENT
WHERE DNAME = 'Research' );
9. Lisää SQL:stä: vaatimukset ja näkymät
•
Tässä luvussa tarkastellaan vaatimusten esittämistä ja näkymien perustamista SQL-kielen avulla
•
Kirjassa oleva tietokantaohjelmoinnin osuus ( kappaleet 9.3 - 9.6 ) sivuutetaan tällä kurssilla.
9.1 Yleisten rajoitusten esittäminen vaatimuksina
•
Luvussa 8.2 käsiteltiin attribuuttien määrittelyjoukkoon, puuttuviin arvoihin sekä olio- ja viite-eheyteen
liittyviä rajoituksia.
•
Edellä mainittuun ryhmään kuulumattomia rajoituksia kutsutaan ns. deklaratiivisiksi rajoituksiksi, jotka
esitellään SQL-kyselyiden tavoin käyttämällä vaatimusten määrittelykomentoa CREATE ASSERTION.
•
Esimerkki: esitellään tietokannan tilaan liittyvä rajoitus, jonka mukaan minkä tahansa osaston
työntekijän palkka ei saa ylittää saman osaston johtajan palkkaa:
62) CREATE ASSERTION SALARY_CONSTRAINT
CHECK ( NOT EXISTS ( SELECT *
FROM EMPLOYEE E, EMPLOYEE M, DEPARTMENT D
WHERE E.SALARY > M.SALARY AND
E.DNO = D.DNUMBER AND
D.MGRSSN = M.SSN ) );
Asetettaessa uutta arvoa attribuutille SALARY testataan, ylittääkö uusi palkka sen osaston johtajan
palkan, jolla tarkasteltava työntekijä on kirjoilla. Tällöin sisin kysely palauttaa ei-tyhjän tulostaulun,
jonka jälkeen ulompi NOT EXISTS -funktio saa arvon epätosi. Tällöin uusi tietokannan tila ei ole
vaatimuksen mukainen, joten tehty päivitysyritys peruutetaan.
•
Edellisessä esimerkissä tunnusta SALARY_CONSTRAINT voidaan käyttää viittaamaan esiteltyyn
rajoitukseen.
•
CREATE ASSERTION -lauseen avulla esiteltävillä rajoituksilla voidaan testata attribuuttien arvojen
välisiä suhteita tiettyjen tuplien välillä.
•
Vaatimusten toteutuminen testataan aina tietokannan tilaa muutettaessa, kun taas kappaleiden 8.2.1
ja 8.2.4 CHECK-lauseiden mukaiset tarkastukset tehdään ainoastaan lisättäessä tai päivitettäessä
tietueita ( ei tuhottaessa niitä ).
63) CREATE DOMAIN D_NUM AS INTEGER CHECK ( D_NUM > 0 AND D_NUM < 21 )
Asetettaessa arvoa tyyppiä D_NUM olevalle kentälle tutkitaan arvon laillisuus eli kuuluminen
välille 1..20.
•
Deklaratiivisia rajoituksia voidaan käyttää myös tietokannan kyseenalaisten ( ei välttämättä laittomien
) tilojen selvittämiseksi kontrolloimaan tietokantaan vietyä dataa. Tällöin rajoituksen rikkoutuminen
aiheuttaa jonkin toimenpiteen käynnistymisen. Tällaisista rajoituksista käytetään nimitystä liipaisin
( trigger ). Liipaisintoiminto määritellään SQL:ssä komennolla CREATE TRIGGER.
•
Voitaisiin esimerkiksi generoida ilmoitus henkilöstöjohtajalle, jos työntekijöiden työtuntimäärät tai
matkakulut ovat kasvaneet tietyn rajan ylitse.
9.2 Näkymät ( virtuaaliset taulut ) SQL-kielellä esitettyinä
•
Seuraavassa tarkastellaan näkymien ( View ) määrittelyä ja käsittelyä
SQL-kielen avulla.
•
Lisäksi mietitään mahdollisuutta päivitysten tekemiseen näkymissä.
9.2.1 Näkymän käsite SQL:ssä
•
Näkymällä tarkoitetaan yksittäistä taulua, jonka sisältö on johdettu tietokannan muiden taulujen
perusteella.
•
Toisin kuin tähän mennessä käsiteltyjä relaatiotauluja, näkymiä ei tarvitse tallentaa fyysisesti. Siten
näkymät mielletään usein ns. virtuaalisiksi tauluiksi.
•
Näkymien virtuaalinen olemus rajoittaa mahdollisuutta tehdä näkymissä päivitysoperaatioita, mutta
se ei rajoita mitenkään mahdollisuutta toteuttaa kyselyjä.
•
Näkymän perustaminen tulee tarpeelliseksi erityisesti silloin, kun tiettyä kyselyä joudutaan
toistamaan usein.
•
Esimerkki: Oletetaan, että joudutaan usein selvittämään projektien nimet, joihin yrityksen
työntekijät tekevät työsuorituksia. Tämä edellyttäisi ilman näkymien olemassaoloa
kyselyä, joka liittää taulut TYÖNTEKIJÄ, TYÖTUNNIT ja PROJEKTI toisiinsa. Jottei
kyselyä tarvitsisi jatkuvasti toistaa, voidaan määritellä näkymä, joka on em.
liitosten tulos.
9.2.2 Näkymän määrittely SQL:ssä
•
Uusi näkymä voidaan perustaa komennolla CREATE VIEW.
•
Näkymälle annetaan komennon yhteydessä sitä osuvasti kuvaava nimi.
Tämän jälkeen esitellään kysely, jonka tulostauluksi näkymä halutaan määritellä.
•
64) Perustetaan näkymä, johon kerätään kunkin työntekijän etu- ja
sukunimi, projektit, joissa työntekijä toimii sekä niihin tehdyt
työtunnit:
V1: CREATE VIEW WORKS_ON1
AS SELECT FNAME, LNAME, PNAME, HOURS
FROM EMPLOYEE, PROJECT, WORKS_ON
WHERE SSN = ESSN AND PNO = PNUMBER;
•
Näkymän attribuutit tallentuvat edellisessä esimerkissä samalla nimellä kuin niiden vastinattribuutit
alkuperäisissä tauluissa.
•
Haluttaessa voidaan näkymän luonnin yhteydessä sen attribuutit nimetä kuitenkin uudelleen.
•
65) Perustetaan näkymä, joka sisältää koostetietoa fyysisesti
tallennettujen taulujen sisällöstä:
V2: CREATE VIEW DEPT_INFO( DEPT_NAME, NO_OF_EMPS, TOTAL_SAL )
AS SELECT DNAME, COUNT ( * ), SUM ( SALARY )
FROM DEPARTMENT, EMPLOYEE
WHERE DNUMBER = DNO
GROUP BY DNAME;
•
Esimerkissä 65 näkymän attribuutit on nimettynä uudelleen sen nimeä seuraavassa attribuuttilistassa.
Nimeäminen tapahtuu siinä järjestyksessä kuin SELECT-lauseessa valittavat näkymän attribuutit on
esitelty.
•
Näkymän kuvaamisessa käytetään hyväksi kaavadiagrammeja.
•
Tarkastellaan kirjan kuvaa 9.1.
•
Kun näkymä on kertaalleen perustettu, siihen voidaan kohdistaa kyselyoperaatioita murehtimatta
lainkaan siitä, mistä eri fyysisistä tietokannan tauluista näkymän sisältämät kentät ovat peräisin!
•
66) Kohdistetaan edellisessä esimerkissä konstruoituun näkymään
WORKS_ON1 kysely, jossa selvitetään projektissa ’ProductX’ työtä
tekevät henkilöt:
QV1: SELECT FNAME, LNAME
FROM WORKS_ON1
WHERE PNAME = ’ProductX’
•
Esimerkin 66 mukaisen kyselyn suorittaminen ilman näkymän WORKS_ON1 olemassaoloa vaatisi
kahden liitoksen muodostamista. Näkymien käyttäminen mahdollistaa selvästikin tietokannan
kyselyjen rakenteen yksinkertaistumisen.
•
Näkymiä voidaan käyttää myös tietoturvan parantamiseksi ja käyttöoikeuksien rajaamiseksi.
Näkymä on jatkuvasti reaaliaikainen. Joka kerta, kun tehdään näkymän taustalla oleviin fyysisiin
tauluihin päivityksiä, myös näkymän sisältö muutetaan vastaamaan tehdyn päivityksen aiheuttamia
muutoksia.
•
Näkymän reaaliaikaisuuden toteuttaminen jää TKHJ:n vastuulle.
•
Tarpeettomaksi käynyt näkymä voidaan poistaa komennolla DROP VIEW.
•
67) Poistetaan näkymä WORKS_ON1:
V1A: DROP VIEW WORKS_ON1;
9.2.3 Näkymän toteutus SQL:ssä ja sen päivittäminen
•
Näkymän tehokas toteuttaminen tietokannan hallintajärjestelmässä kyselyiden nopeutta ajatellen on
vaikea tehtävä.
•
Kaksi tärkeintä kyselyiden toteutusstrategiaa ovat kyselyn modifiointi
( query modification ) ja näkymän materialisointi ( view materialization ).
•
Ensin mainitussa lähestymistavassa muunnetaan näkymään kohdistunut kysely kyselyksi kaikkiin niihin
tauluihin, joihin näkymä perustuu.
•
Kyselyn modifiointi on kuitenkin tehotonta, mikäli näkymä on saatu aikaan monimutkaisen, useita
tauluihin tarvitsevan kyselyn turvin. Jos näkymään tehdään toistuvia kyselyitä lyhyin väliajoin,
joudutaan aikaa vievä modifioitu kyselyoperaatio suorittamaan usein, vaikkei välttämättä varsinaisessa
datassa olisikaan tapahtunut mitään muutoksia. Tällöin näkymäkyselyn vasteajoista saattaa tulla
tarpeettoman pitkiä.
•
Näkymän materialisoinnissa tallennetaan näkymän tiedot fyysisesti, kun ensimmäinen siihen perustuva
kysely esitetään.
•
Koska näkymän taustalla olevien taulujen sisältämät tiedot kuitenkin aika ajoin muuttuvat, pitää olla
tehokas menettelytapa automatisoitua fyysisen näkymätiedoston ylläpitoa varten.
•
Fyysisten näkymätiedostojen ajan tasalla pitämistä varten käytetään ns. asteittaisten päivitysten
( incremental updates ) tekniikkaa. Periaatteena on, että varsinaisiin datatiedostoihin tehtyjen
päivitysten ( lisäysten, poistojen ja muutosten ) aiheuttamat näkymätiedoston muutokset tallennetaan
samalla fyysiseen näkymätiedostoon pääosan näkymätiedostosta säilyessä muuttumattomana.
•
Oleellisena tekijänä fyysisen näkymätiedoston ylläpidon jatkumisen kannalta on aika, joka on
kulunut näkymän viimeisestä käyttöhetkestä.
•
Jos näkymään kohdistetaan ahkerasti kyselyitä, on myös fyysisen näkymätiedoston päivittäminen
tarpeen sitä mukaa kun sen taustalla oleviin datatiedostoihin tehdään muutoksia.
•
Jos puolestaan näkymän käytön intensiteetti heikkenee, voidaan fyysinen näkymätiedosto tuhota
kokonaan, jottei sitä tarvitsisi ylläpitää käytön ollessa vähäistä. Kun näkymää jälleen seuraavan
kerran tarvitaan, perustetaan se ’alkutekijöistään’ uudelleen.
•
Näkymissä tehtävissä olevat mahdolliset päivitysoperaatiot ovat varsinaisiin fyysisiin tauluihin
tehtäviin päivityksiin verrattuna huomattavasti rajoittuneempia, ja niiden kanssa kannattaa olla
varovainen.
•
Suurimpina ongelmina päivityksissä ilmenevät päivitysten monimutkaisuus, yksikäsitteisyyden puute
sekä mahdollisuus järjettömiin päivityksiin.
•
Tarkastellaan seuraavaksi esimerkkejä päivitykseen liittyvistä pulmista.
•
68) Yritetään muuttaa aikaisemmin tarkastellussa näkymässä WORKS_ON1
työntekijää ’John Smith’ kuvaavista tietueista projektin nimeä
’ProductY’:ksi riveillä, joilla projektin nimenä esiintyy ’ProductX’:
UV1: UPDATE WORKS_ON1
SET PNAME = ’ProductY’
WHERE LNAME = ’Smith’ AND FNAME = ’John’ AND
PNAME = ’ProductX’;
•
Pulma: mitä halutaan saada aikaan kyseisellä päivityksellä? Onko tavoiteltu vaikutus taustalla
olevaan tauluun WORKS_ON ehkä seuraavanlainen …
68a): UPDATE WORKS_ON
SET PNO = ( SELECT PNUMBER
FROM PROJECT
WHERE PNAME = ’ProductY’)
WHERE ESSN IN ( SELECT SSN
FROM EMPLOYEE
WHERE LNAME = ’Smith’ AND FNAME = ’John’)
AND
PNO IN ( SELECT PNUMBER
FROM PROJECT
WHERE PNAME = ’ProductX’ );
… vai olisiko tarkoitus ollut sittenkin seuraavassa ehdotettu?
68b) UPDATE PROJECT
SET PNAME = ’ProductY’
WHERE PNAME = ’ProductX’
•
Kumpainenkin edellä esitetyistä vaihtoehdoista toteuttaisi käyttäjän esittämän päivityspyynnön,
mutta toteutustavat poikkeavat kovasti toisistaan!
•
Kohdassa a) siirrettäisiin John Smithin työpanos projektista ’ProductX’ eli numerosta 1 projektiin 2,
mikä olisi mahdollisesti hyvinkin ajateltavissa oleva järkevä vaihtoehto – nyt tosin se olisi kelvoton
ratkaisu, sillä John Smith on jo ennestään töissä projektissa 2, mikä rikkoisi taulun WORKS_ON
pääavaimen yksikäsitteisyysvaatimusta.
•
Kohdassa b) saataisiin näkymä WORKS_ON1 myös halutun kaltaiseksi, eli John Smithin kohdalla
attribuutin PNAME arvo ’ProductX’ muuttuisi kylläkin arvoksi ’ProductY’, mutta tämä on saatu nyt
aikaan muuttamalla taulussa PROJECT projektin 1 nimeksi ’ProductY’. Tämäkään ei onnistuisi, koska
projektin nimen pitää olla esimerkkitietokannassamme yksikäsitteinen, mutta koko ajatus näkymän
korjaamiseksi b)-kohdassa esitetyllä tavalla tuntuisi intuitiivisesti ajatellen järjettömältä. Jos
operaatio onnistuisi, se muuttaisi näkymässä samalla kaikkien projektissa 1 työskentelevien tietoja,
vaikka esitetty valintaehto indikoisi selvästi, että muutos koskisi nimenomaan John Smithin tietoja.
TKHJ ei kuitenkaan osaa itse ratkaista, kumpi vaihtoehto olisi järkevä suorittaa!
•
Lisäksi käyttäjän itsensä ehdottama päivitys näkymään voi olla mieletön. Ajatellaanpa päivitystä
kenttään, joka on muodostettu soveltamalla aggregaattifunktiota.
•
69) Yritetään päivittää kokonaispalkkasummatietoa tauluun, joka perustettiin esimerkissä 54:
UV2: UPDATE DEPTS_INFO
SET TOTAL_SAL = 100000
WHERE DNAME = ’Research’
•
Esimerkissä 69 pyritään suoraviivaisella tavalla ’tilastotietojen väärentämiseen’: ei ole mieltä yrittää
päivittää sellaisen attribuutin arvoja, joka perustuu toisista tauluista kerättyyn koostetietoon! Olisi
olemassa rajaton määrä mahdollisia datatiedoston päivityksiä, joiden avulla laskennallisen
attribuutin TOTAL_SAL arvoksi saataisiin todellisuudessa juuri 100000!
•
Yleisesti ottaen, näkymästä käsin suoritettavaa päivitysyritystä voidaan pitää mielekkäänä
ainoastaan silloin, kun se on tulkittavissa tarkalleen yhdellä tavalla.
•
Muutamat tutkijat ovat kuitenkin laajentaneet päivitettävyyden käsitettä myös tilanteisiin, joissa
päivitys ei ole yksikäsitteinen, turvautumalla tietyin kriteerein määriteltyyn todennäköisimpään
päivitykseen, tai antamalla ratkaisu operaation tulkinnasta epäselvissä tilanteissa käyttäjälle.
•
Pähkinänkuoressa voidaan näkymissä tapahtuvista päivitysoperaatioista todeta kuitenkin seuraavaa:

Näkymässä, joka perustuu vain yhteen tauluun, voidaan tehdä päivityksiä, jos sen attribuutit
sisältävät taustalla olevan taulun pääavaimen tai mahdollisesti jonkin muun ehdokasavaimen,
koska tällöin jokainen näkymän tupla kuvautuu tarkalleen yhdeksi datatiedoston tuplaksi.

Taulut, jotka sisältävät liitoksia, eivät ole yleensä päivityskelpoisia ( s. o. niissä ei pidä tehdä
päivityksiä taustalla olevaan tietokantaan ).

Taulut, jotka on muodostettu käyttämällä ryhmittelyä ja koostefunktioita, eivät myöskään ole
kelvollisia päivitysoperaatioiden tekemistä varten.
10. Funktionaaliset riippuvuudet ja relaatiotietokannan
normalisointi
•
Tähän mennessä olemme ehtineet suunnitella tietokannan käsitteellistä ER- ja EER-mallinnusta
käyttäen ja muuntaneet sittemmin mallin mukaisen lopputuloksen relaatiomalliin sopivaksi mm.
esittelemällä vahvat entiteettityypit relaatiotauluina, purkamalla moniarvoiset attribuutit omiksi
relaatioikseen sekä esittelemällä suhteet pää- ja vierasavainkenttien välisinä liitoksina
( lukumääräsuhteet 1:1, 1:N ) tai lisätauluina ( lukumääräsuhde M:N ).
•
Kuitenkaan emme ole ottaneet kantaa siihen, minkä tähden jokin tietty attribuuttien ryhmittely eri
relaatiotauluihin on parempi kuin jokin toinen.
•
Relaatiokaavojen hyvyyttä voidaan tarkastella joko loogisella eli käsitetasolla tai fyysisellä eli
toteutustasolla.
•
Käsitetasolla voidaan selvittää, miten käyttäjät tulkitsevat relaatiokaavat sekä niihin kuuluvien
attribuuttien merkityksen. Mitä selkeämpiä relaatiokaavat ovat, sitä helpompaa on käyttäjien
muodostaa virheettömiä kyselyitä tietokantaan.
•
Toteutustasolla ollaan puolestaan kiinnostuneita siitä, miten varsinaisten relaatiotaulujen sisältämät
tuplat on tallennettu.
•
Tietokannan suunnittelu voi edetä kahteen suuntaan: joko yksittäisistä attribuuteista alkaen kohti
entiteettityyppien muodostamista ( alhaalta ylöspäin – suunnittelu synteesin avulla ) tai
hahmottelemalla suoraan relaatiokaavoja ja tekemällä siihen tarkennuksia ja korjauksia tarpeen
mukaan ( ylhäältä alaspäin – suunnittelu analyyttisesti ).
•
Ensimmäinen vaihtoehto tuottaa aluksi liian pieniä relaatiotauluja, s. o. kaikkia tarvittavia
attribuutteja ei koota heti samaan kaavaan, kun taas jälkimmäisessä saatetaan kerätä liikaa
attribuutteja yhdelle entitettityypille.
•
Jatkossa keskitytään lähinnä ylhäältä alaspäin etenevään suunnitteluun.
•
Tarkoituksena on tarkastella relaatiokaavojen laadukkuutta ensin neljällä ei-formaalilla kriteereillä.
•
Myöhemmin määritellään funktionaalisen riippuvuuden käsite, joka on formaalisti määritelty ja joka
mittaa attribuuttien ryhmittelyn kelvollisuutta eri relaatiokaavojen välillä. Myös funktionaalisen
riippuvuuden eri lajeja analysoidaan.
•
Lopuksi tarkastellaan relaatiokaavojen hyvyyden astetta tietokannan ns. normaalimuotojen avulla.
10.1 Ei-formaalit ohjesäännöt relaatiokaavojen suunnittelua varten
•
Seuraavassa tarkastellaan neljää ei-formaalia kriteeriä relaatiokaavan laadukkuudelle, jotka ovat:
1.
2.
3.
4.
Attribuuttien semantiikka
Redundanttien arvojen minimointi tuplissa
Puuttuvien arvojen minimointi
Valetuplien generoinnin estäminen
10.1.1 Relaation attribuuttien semantiikka
•
Semantiikalla tarkoitetaan tässä yhteydessä, miten käyttäjä tulkitsee relaation tuplan attribuuttien
arvot.
•
Mikäli käsitteellinen suunnittelu on tehty huolellisesti, ja sitä on seurannut kuvaus relaatiomalliin
luvun 7.1 algoritmin mukaisesti, saadun relaatiomallin mukaisen esityksen pitäisi olla tulkittavissa
yksikäsitteisesti ongelmitta.
•
Yleisesti ottaen, mitä helpompaa on relaatiokaavan tulkitseminen, sitä parempana relaatiokaavaa
voidaan pitää.
•
Tarkastellaan kirjan esimerkkiä 10.1 yksinkertaistetusta yrityksen tietokannasta sekä esimerkissä
10.2 esitettyä yhtä mahdollista kyseisen tietokannan tilaa.
•
Selvästikin relaation EMPLOYEE merkitys on helposti ymmärrettävissä: jokainen taulun tupla esittää
yksittäistä työntekijää, ja hänestä tallennetaan etunimi, henkilötunnus, syntymäaika, osoite ja
osastonumero, jolla hän työskentelee. Pääavaimena taulussa toimii henkilötunnus, joka erottelee
työntekijät toisistaan.
•
Samoin relaatioiden DEPARTMENT ja PROJECT tulkinta on hyvin suoraviivainen.
•
Taulujen DEPT_LOCATIONS ja WORKS_ON tulkinta on jossain määrin monimutkaisempi. Ensin
mainitun jokainen tupla edustaa yhden osaston yhtä toimipistettä. Jokaista toimipistettä kohti
muodostetaan tupla kunkin osaston osalta. Jälkimmäisessä puolestaan yksi tupla edustaa yhden
työntekijän työtunteja yhteen projektiin. Jokaista työntekijää kohti muodostuu niin monta tuplaa kuin
on projekteja, joissa hän työskentelee. Taulu WORKS_ON edustaa suhdetta M:N työntekijän ja
projektin välillä. Hieman monimutkaisemmasta tulkinnastaan huolimatta myös nämä kaksi kaavaa
ovat hyvin määriteltyjä ja tulkittavissa yksikäsitteisesti.
•
OHJESÄÄNTÖ 1: Suunnittele relaatiokaava siten, että sen merkitys on helppo selittää. Ei pidä
sekoittaa eri entiteettityyppien attribuutteja samaan relaatioon. Merkitys pysyy
selkeänä, kun taulu sisältää tarkalleen yhdelle entiteettityypille tai suhdetyypille
ominaisia attribuutteja.
•
Tarkastellaan kirjan esimerkkiä 10.3. Kohdassa ( a ) työntekijän tietoihin on lisätty taulusta
DEPARTMENT attribuutit, jotka kuvaavat hänen osastonsa nimeä ja sen johtajaa. Vastaavasti
kohdassa ( b ) suhdetyypin taulua WORKS_ON on täydennetty taulun EMPLOYEE attribuutilla ENAME
sekä taulun PROJECT attribuuteilla PNAME ja PLOCATION. Vaikkakin kummankin taulun attribuuttien
merkitys on helposti tulkittavissa, taulut rikkovat kuitenkin ohjesääntöä 1, sillä eri entiteettityyppien
attribuutteja ei pidä sekoittaa toisiinsa.
•
Esimerkin 10.3 mukaiset taulut voisivat kuitenkin hyvin esiintyä tietokannan näkyminä tietyille
käyttäjille.
10.1.2 Tuplien redundantti tieto sekä päivityksiin liittyvät anomaliat
•
Tarkastellaan kirjan esimerkkiä 10.4 relaatioiden EMP_DEPT ja EMP_PROJ tilasta, ja verrataan sitä
esimerkin 10.2 mukaiseen, jossa sekä työntekijää, osastoa ja projektia koskevat tiedot on säilötty
erilleen toisistaan.
•
Vaikkakin esimerkin 10.2 tauluissa EMPLOYEE ja DEPARTMENT sisältävät yhteenlaskettuna enemmän
tuplia kuin esimerkin 10.4 mukaisessa yhdistelmärelaatiossa EMP_DEPT, näyttää taulu EMP_DEPT
kuitenkin paljon kookkaammalta, sillä jokaista työntekijää kohti joudutaan tallentamaan myös osastoa
kuvaavat attribuutit. Siten saman osaston tiedot toistuvat taulussa niin monta kertaa kuin sillä on
kirjoilla työntekijöitä. Tämä ei ole tarpeen esimerkissä 10.2 työntekijän ja osaston tietojen ollessa
erillisiä.
•
Mikäli verrataan puolestaan tauluja EMP_PROJ tauluihin EMPLOYEE, WORKS_ON ja PROJECT niiltä osin,
kuin niissä esiintyy samoja attribuutteja, vaikuttaa taulu EMP_PROJ varsin täyteiseltä mihin tahansa
viimeksi mainittuun erillistauluun verrattuna.
•
Sijoitettaessa usean entiteettityypin attribuutteja samaan tauluun muodostuu päivitysten anomalioiden
ongelma tehtäessä tauluun lisäyksiä, poistoja ja muutoksia.
•
Tarkastellaan seuraavassa taulua EMP_DEPT, jonka pääavaimena on henkilötunnus.
•
Uuden työntekijän lisääminen tauluun edellyttää myös osaston tietojen sijoittamista tuplaan samalla.
Osaston tietoja syötettäessä pitää olla tarkkana, että ne syötetään samalla tavalla kuin aikaisemmin
samalle osastolle kirjattujen työntekijöiden kohdalla. Muutoin kyseisien osaston tiedoista tulee
inkonsistentteja. Tällaista ongelmaa ei ilmenisi, jos osaston tiedot pidettäisiin erillään työntekijää
kuvaavista tiedoista. Jos osastoa ei heti tiedetä, jätetään osastoa koskevat tiedot puuttuviksi.
•
Erityisen ikävä tilanne muodostuisi silloin, kun haluttaisiin perustaa yritykseen uusi osasto, jolle ei
kuitenkaan voitaisi samalla nimetä ketään työntekijää.
•
Tällöin pitäisi syöttää tauluun EMP_DEPT tupla, jossa työntekijää koskevat attribuutit jätettäisiin
tyhjiksi, mutta koska henkilötunnus on taulun pääavain, ei NULL-arvojen salliminen kenttään tuntuisi
järkevältä ( ad hoc -ratkaisu: perustetaan jokin ’haamutyöntekijä’ uudelle osastolle. Kun osastolle
ilmestyy ensimmäinen aito työntekijä, korjataan perustetun pseudotietueen henkilötiedot järkeviksi ).
•
Tietueen tuhoamiseen liittyvä anomalia: voidaan menettää vahingossa tietoa, jota ei olisi ollut
tarkoitus poistaa. Osaston ainoan työntekijän irtisanoutuminen veisi mennessään myös osaston tiedot,
vaikkei tätä ( välttämättä ) olisikaan haluttu! Näin ei kävisi esimerkin 10.2 mukaisessa tietokannassa.
•
Tiedon muuttamisen anomalia: riski tiedon muuttumisesta inkonsistentiksi. Mikäli vaikkapa osaston 5
johtaja vaihtuisi, pitäisi tieto uuden johtajan henkilötunnuksesta sijoittaa kaikkiin niihin taulun
EMP_DEPT tupliin, joissa osastonumerona on 5. Tällainen menettely ei olisi tarpeen esimerkin 10.2
tietokannassa.
•
OHJESÄÄNTÖ 2: Suunnittele relaatiokaavat siten, ettei anomalioita voi esiintyä päivityksissä. Mikäli
niitä kaikesta huolimatta siinä esiintyy, varmistu sovellusohjelmien oikeellisuudesta.
10.1.3 Puuttuvat arvot tuplissa
•
Muodostettaessa tietokantaa analyyttisellä suunnittelulla ( ylhäältä alas ) valitaan johonkin
entiteettityyppiin toisinaan attribuutteja, jotka ovat siihen liiaksi erikoistettuja.
•
Tällöin syntyy tilanne, jossa yhtä tuplaa kohti useita attribuutteja saattaa jäädä puuttuviksi, mikä
saattaa aiheuttaa harmia mm. erityyppisiä liitoksia tehtäessä tai aggregaattifunktioita käytettäessä.
•
Puuttuvilla arvoilla on lisäksi erilaisia tulkintoja:
1. Attribuutti ei koske lainkaan taulun jotain tuplaa.
2. Attribuutin arvo on tuntematon – ei tietoa, onko arvo saatavilla.
3. Attribuutin arvon tiedetään olevan saatavilla, mutta sitä ei jostain syystä ole tallennettu.
•
OHJESÄÄNTÖ 3: Yritä mahdollisimman tarkoin rajoittaa usein NULL-arvoa saavien attribuuttien
sijoittamista relaatiokaavaan. NULL-arvojen tulee olla poikkeuksia.
•
Esimerkki: Jos vain 10%:lla työntekijöistä on oma työhuone, ei työhuonetta kuvaavaa attribuuttia
kannata sijoittaa työntekijöiden perustietoihin, vaan erilliseen relaatiotauluun, joka
koostuu työntekijän tunnistetiedoista ja heidän työhuonetiedoistaan. Ainoastaan ne
työntekijät ovat edustettuina kyseisessä taulussa, joilla on oma työhuone olemassa.
10.1.4 Valetuplien generointi
•
Tarkastellaan kirjan esimerkkiä 10.5 hyvin huonosta relaatiokaavan suunnittelusta. Oletetaan, että
on perustettuna taulu EMP_PROJ, joka sisältää kaikki taulun WORKS_ON attribuutit ja niiden lisäksi
tiedon työntekijän nimestä, projektin nimestä ja sen sijaintipaikasta.
•
Ositetaan tämä relaatio tauluiksi EMP_LOCS, joka sisältää tiedot työntekijän nimestä sekä sen
projektin sijaintipaikasta, jossa hän työskentelee, sekä EMP_PROJ1, joka sisältää taulun WORKS_ON
attribuutit sekä lisäksi attribuutit PNAME ja PLOCATION. Mikäli nyt muodostettaisiin liitos taulujen
EMP_LOCS ja EMP_PROJ1 välille, ainoa mahdollinen liitosattribuutti olisi PLOCATION.
•
Taulujen välinen luonnollinen liitos ei kuitenkaan muodostaisi alkuperäistä taulua EMP_PROJ, sillä
liitosattribuutti ei koostu päävain-vierasavain -parista. Tuloksena olisi isokokoinen tulostaulu, joka
sisältäisi paljon virheellisiä tuplia, sillä esimerkiksi John Smithiä kuvaavat tietueet taulussa EMP_PROJ1
liitettäisiin kaikkien niiden taulun EMP_LOCS tuplien kanssa, joissa projektin sijaintipaikka on sama.
Täten esimerkiksi taulun EMP_PROJ1 toisen tuplan perään liitettäisiin vuoron perään paitsi Smithiä
itseään niin myös Franklin Wongin ja Joyce Englishin tiedot, koska jokainen heistä työskentelee
Sugarlandissa toimivassa projektissa 2 ( kts. kirjan esimerkki 10.6 )!
•
OHJESÄÄNTÖ 4: Suunnittele relaatiokaavat siten, että niiden välille voidaan muodostaa liitos pääavainvierasavain -paria käyttämällä siten, että liitoksella saatujen tuplien oikeellisuus on
taattu. Älä muodosta liitosta attribuuttien välille, jotka eivät täytä em. vaatimusta.
•
Alkuperäisen relaation osittamisen pitää tapahtua siten, että liitosten avulla voidaan alkuperäinen taulu
rekonstruoida ositteistaan.
10.2 Funktionaaliset riippuvuudet
•
Funktionaalisen riippuvuuden käsite on tärkein yksittäinen relaatiokaavan suunnitteluteoriaan liittyvä
käsite.
10.2.1 Funktionaalisen riippuvuuden määritelmä
•
Kuvitellaan aluksi, että kaikki tietokannassa tarvittavat attribuutit on sijoitettu yhteen ainoaan isoon
tauluun R = { A1, A2, …, An }.
•
Merkitään tunnuksilla X ja Y R:ään kuuluvien attribuuttien mielivaltaisia
osajoukkoja ( = komponentteja ).
•
Relaatiossa R vallitsee funktionaalinen riippuvuus attribuuttijoukkojen X ja Y välillä, eli X --> Y, mikäli
taulun R mitä tahansa kahta tuplaa kohti on aina voimassa ehto t1[X] = t2[X] --> t1[Y] = t2[Y].
•
Funktionaalinen riippuvuus X --> Y tarkoittaa, että komponentin X arvo(t)
määräävät yksikäsitteisesti komponentin Y arvo(n/t).
•
Funktionaalinen riippuvuus ( lyhennetään FR ) on attribuuttien semantiikan ominaisuus. Kun X --> Y
on voimassa tietyssä relaatiokaavassa R, ei voi esiintyä sellaista laillista tietokannan tilaa r(R) siten,
että kahdessa eri tuplassa komponentin X arvot olisivat samat, mutta komponentin Y arvot eroaisivat
toisistaan.
•
Jos X on R:n ehdokasavain, määräytyvät Y:n arvot väistämättä yksikäsitteisesti X:n perusteella, sillä
X ei sisällä duplikaatteja.
•
Funktionaalisen riippuvuuden X --> Y ollessa voimassa ei päinvastainen eli Y --> X ( välttämättä )
toteudu ( vrt. taulussa TYÖNTEKIJÄ hetu --> osastonumero ).
•
Tarkastellaan relaatiokaavaa EMP_PROJ kuvassa 10.3 (b). Seuraavat funktionaaliset riippuvuudet
ovat voimassa:
1. SSN --> ENAME
2. PNUMBER --> { PNAME, PLOCATION }
3. { SSN, PNUMBER } --> HOURS
Siten henkilötunnus määrää yksikäsitteisesti työntekijän nimen, projektinumero projektin nimen ja
sen sijaintipaikkakunnan sekä yhdistelmä hetu-projektinumero yksittäisen työntekijän työtunnit yhtä
projektia kohti viikossa.
•
Kannattaa huomioida, että funktionaalinen riippuvuus on relaatiokaavan eikä sen tilan määräämä
ominaisuus, eli relaation tilasta ei voida päätellä funktionaalisen riippuvuuden olemassaoloa kahden
attribuuttijoukon välillä. Sen sijaan sellaisen olemassaolon kiistäminen voidaan tehdä yhden
vastaesimerkin turvin
•
Tarkastellaan kirjan esimerkkiä 10.7 edelliseen aiheeseen liittyen. On selvää, ettei luennoitava kurssi
määräydy yksikäsitteisesti tiedettäessä opettajan nimi. Sen sijaan on mahdollista, että kurssikirja
voisi ilmaista, mistä kurssista on kyse, mutta pelkän relaation tilan perusteella tätä ei voida
todentaa!
10.2.2 Päättelysäännöt funktionaalisille riippuvuuksille
•
Tietyn attribuuttijoukon X kaikkien funktionaalisten riippuvuuksien transitiivinen sulkeuma F+
muodostuu kaikista tietokannan attribuuttien joukosta, joiden arvo määräytyy yksikäsitteisesti X:n
perusteella – joko suoraan tai ’mutkan kautta’.
•
Jos on esimerkiksi voimassa funktionaalisten riippuvuuksien joukko
F = { SSN --> { ENAME, ADDRESS, DNUMBER },
DNUMBER --> { DNAME, MGRSSN } }
voidaan johtaa seuraavat lisäriippuvuudet F:stä
SSN --> { DNAME, MGRSSN}, SSN --> SSN, DNUMBER --> DNAME
•
Funktionaalisten riippuvuuksien johtamiseksi voidaan käyttää apuna seuraavia logiikan ja joukko-opin
päättelysääntöjä ( IR = inference rule ). Merkintä ᅣ tarkoittaa ”on johdettavissa”.
IR1
IR2
IR3
IR4
IR5
IR6
(
(
(
(
(
(
refleksiivisyys ): Jos X  Y, niin X --> Y
laajentaminen ): { X --> Y } ᅣ XZ --> YZ
transitiivisuus ): { X --> Y, Y --> Z} ᅣ X --> Z
dekompositio ): { X --> XZ } ᅣ X --> Z
additiivisuussääntö ): { X --> Y, X --> Z } ᅣ X --> YZ
pseudotransitiivisuus ): { X --> Y, WY --> Z} ᅣ WX --> Z
Säännöistä kolme ensimmäistä ovat terveitä ja riittäviä, eli niiden avulla pystytään etsimään kaikki
X:stä funktionaalisesti riippuvat komponentit.
•
Edellä esitetyt päättelysäännöt voidaan todistaa oikeaksi, mutta todistukset sivuutetaan tässä
( löytyvät kirjasta, mutta esitetään kuitenkin luennolla ).
•
Esimerkki: mikäli F sisältää funktionaaliset riippuvuudet
{ SSN --> ENAME, PNUMBER --> { PNAME, PLOCATION }, { SSN, PNUMBER } --> HOURS },
saataisiin
{ SSN }+ = { SSN, ENAME }
{ PNUMBER }+ = { PNUMBER, PNAME, PLOCATION }
{ SSN, PNUMBER }+ = { SSN, PNUMBER, ENAME, PNAME, PLOCATION, HOURS }
10.2.3 Funktionaalisten riippuvuusjoukkojen ekvivalenssi
•
Määritelmä: Funktionaalisten riippuvuuksien joukon F sanotaan peittävän toisen funktionaalisten
riippuvuuksien joukon E, mikäli jokainen E:hen kuuluva FR kuuluu myös joukkoon F+, eli
jokainen E:n sisältämä FR voidaan johtaa F:stä. Toisin sanoen F peittää E:n.
•
Määritelmä: Kaksi funktionaalisten riippuvuuksien joukkoa E ja F ovat ekvivalentit, mikäli E+ = F+.
Tällöin jokainen E:n sisältämä FR voidaan johtaa F:stä ja vastaavasti jokainen F:ään
kuuluva FR on johdettavissa E:stä.
•
On mahdollista testata, peittääkö funktionaalisten riippuvuuksien joukko F joukon E generoimalla
joukko X+ jokaista E:hen kuuluvaa FR:ää X --> Y kohti ja tutkimalla, kuuluuko jokainen Y tällä tavoin
muodostettuun X+:aan. Mikäli näin on, tällöin F peittää E:n.
10.2.4 Funktionaalisten riippuvuuksien minimaalinen joukko
•
F on E:n funktionaalisten riippuvuuksien minimaalinen peittävän joukko, jos seuraavat ominaisuudet
ovat voimassa:

F:n sulkeuma F+ sisältää kaikki E:ssä esiintyvät funktionaaliset riippuvuudet

Poistamalla yksikin F:ään kuuluva FR ei peittävyysominaisuus ole enää voimassa.
10.2.4 Funktionaalisten riippuvuuksien minimaalinen joukko
•
Minimaalinen peittävä joukko F voidaan formaalisti määritellä seuraavanlaisesti:

1) Jokainen F:ään kuuluva FR sisältää oikealla puolella ainoastaan yhden attribuutin, eli A on
yksinkertainen attribuutti ilmauksessa X --> A.

2) Ei ole mahdollista korvata mitään F:ään kuuluvaa FR:ää X --> A toisella FR:llä Y --> A, missä
Y on X:n aito osajoukko siten, että tällöin muodostuva funktionaalisten riippuvuuksien joukko
F' olisi yhä ekvivalentti F:n kanssa.

3) F:stä ei voida poistaa mitään FR:ää siten, että poiston seurauksena muodostuva joukko F'
olisi yhä ekvivalentti F:n kanssa.
•
Edellisessä formaalissa määrittelyssä ehto 1) takaa sen, ettei FR:n oikealla puolella esiinny kuin
yksinkertaisia attribuutteja riippuvuuksien esitysmuodon yksinkertaistamiseksi. Ehdon 2) mukaisesti
FR:n vasemmalla puolella ei saa esiintyä turhia attribuutteja, ja ehto 3) hävittää funktionaaliset
riippuvuudet, jotka ovat lausuttavissa jo F:ssä ennestään esiintyvien FR:ien avulla.
•
Funktionaalisten riippuvuuksien minimaalinen peittävän joukko on ns. standardi- eli kanoninen muoto,
joka ei sisällä redundanssia.
•
Tällaisia standardimuotoja voi olla useita, ja ainakin yksi tällainen voidaan löytää käyttämällä
seuraavassa esitettävää algoritmia 10.2.
Algoritmi 10.2: Selvitetään FR:ien joukon E minimaalinen peitto F:
1. Aseta F := E
2. Korvaa jokainen F:n funktionaalinen riippuvuus X --> { A1, A2, ..., An } funktionaalisilla
riippuvuuksilla X --> A1, X --> A2, ..., X --> An.
3. Toista jokaista F:n funktionaalista riippuvuutta X --> A kohti
Toista jokaista X:ään kuuluvaa attribuuttia B kohti
Jos { { F - { X --> A } } U { X - { B } ) --> A } on ekvivalentti F:n kanssa
Korvaa X --> A FR:llä ( X - { B } ) --> A joukossa F.
4. Toista jokaista F:ssä jäljellä olevaa FR:ää X --> A kohti
Jos { F - { X --> A } } on ekvivalentti F:n kanssa
Poista FR X --> A joukosta F.
10.3 Pääavaimeen perustuvat normaalimuodot
•
Seuraavassa oletetaan, että jokaisen tarkasteltavan relaation funktionaaliset riippuvuudet ovat tiedossa,
ja jokaiselle relaatiolle on asetettu pääavain.
•
Tämän jälkeen on mahdollista käynnistää relaatiokaavan normalisointi.
•
Tässä yhteydessä tarkastellaan normaalimuotoja 1 - 3, jotka perustuvat pääavainkenttiin.
10.3.1 Relaatioiden normalisointi
•
Normaalimuodot toimivat relaatiokaavan yksinä laadukkuuden mittareina: Mitä korkeampaa
normaalimuotoa relaation kaava edustaa, sitä laadukkaampi sen sanotaan olevan.
•
Tärkeimmät normaalimuodoista ovat 1., 2. ja 3. normaalimuoto ( 1NF, 2NF ja 3NF ) sekä Boyce-Coddin
normaalimuoto ( BCNF ). Lisäksi on olemassa vielä normaalimuodot 4NF ja 5NF, jotka käsitellään
luvussa 11.
•
Normaalimuotojen toteutumista relaatiokaavassa voidaan testata. Ellei kaava toteuta tarkasteltavaa
normaalimuotoa, kaava muotoillaan uudelleen eli ns. normalisoidaan.
•
Relaatiokaavan ollessa tietyn normaalimuodon täyttävä, esimerkiksi NFX, se on myös kaikkien alempaa
järjestyslukua olevien normaalimuotojen mukainen. Esimerkiksi, jos relaatio on normaalimuotoa NF2, se
on täyttää myös NF1:n vaatimukset. BCNF on 3. normaalimuotoa tiukempi vaatimus.
•
Datan normalisointi voidaan ymmärtää prosessina, jossa tarkastelemalla annettujen relaatiokaavojen
pääavaimia ja kaavan funktionaalisia riippuvuuksia pyritään relaatio muotoilemaan tarpeen mukaan
uudelleen ns. dekompositiolla siten, että

Tietokannassa esiintyvä redundanssi minimoituisi

Tietueiden lisäämiseen, niiden tietosisällön muuttamiseen sekä tuhoamiseen liittyvät anomaliat
karsiutuisivat mahdollisimman hyvin
•
Mikäli relaatiokaava ei toteuta vaadittavaa normaalimuotoa, se jaetaan kahdeksi tai useammaksi
pienemmäksi relaatioksi, jotka ovat vaaditun normaalimuodon täyttäviä.
•
Kannattaa kuitenkin huomioida, että normalisointi ei muista laadukkuuteen vaikuttavista tekijöistä
eristettynä takaa, että tietokanta olisi hyvin suunniteltu!
•
Vaadittujen normaalimuotojen toteutumisen ohella pitää kiinnittää huomiota seuraavien ominaisuuksien
toteutumiseen:
•

Häviöttömän eli ei-additiivisen liitoksen ominaisuus, joka edellyttää, ettei relaatiokaavan uudelleen
järjestäminen voi johtaa valetuplien generointiin

Relaation sisältämien funktionaalisten riippuvuuksien säilyminen myös tehdyn dekomposition
jälkeen
Näistä ehdoista ensin mainitun toteutuminen on ehdoton edellytys dekompostion onnistumiselle.
Jälkimmäisestä vaatimuksesta voidaan tietyissä tapauksissa joustaa.
10.3.4 Ensimmäinen normaalimuoto
•
Relaatiokaava toteuttaa 1. normaalimuodon kriteerit, mikäli se sisältää ainoastaan atomisia attribuutteja
( ei koosteisia eikä moniarvoisia ).
•
Mikäli ei-atomisia attribuutteja esiintyy, pitää koosteiset attribuutit jakaa osiinsa ja moniarvoiset
attribuutit esitellä uutena relaationa ( kts. kohdassa 7.1 esitetty algoritmi ).
•
Myös moniarvoisen attribuutin arvojen maksimimäärään varautuminen on mahdollista perustamalla
riittävän monta attribuuttia. Usein tuloksena on kuitenkin tarpeettomia NULL-arvoja.
•
Tarkastellaan kirjan esimerkkiä 10.8, jossa poistetaan osaston toimipisteitä edustanut moniarvoinen
attribuutti. Esimerkin mukainen taulu ei ole oikeastaan edes relaatiomallin vaatimuksia täyttävä (
sisältää moniarvoisen attribuutin ).
•
Koska relaaatiotaulun OSASTO attribuutti Toimipisteet on moniarvoinen, se ei ole funktionaalisesti täysin
riippuva pääavaimesta ( voi esiintyä useita mahdollisia arvoja ).
•
Pulma ratkeaa poistamalla 1NF:ää rikkonut attribuutti Toimipisteet taulusta Osasto. Toimipisteiden
kuvaamiseksi perustetaan erillinen taulu, jonka pääavain muodostuu osastonumerosta ( taulun
OSASTO pääavaimesta ) sekä toimipisteen sijaintipaikkakunnasta.
•
Pulma olisi vaihtoehtoisesti voitu ratkaista varautumalla osastokohtaisten toimipisteiden
maksimimäärään perustamalla riittävän monta attribuuttia toimipisteitä varten ( Toimipiste1,
Toimipiste2, ..., ToimipisteN ) tauluun OSASTO, mutta ratkaisu olisi kömpelö, sillä

Toimipisteiden tarve osastoittain saattaa vaihdella suuresti, jolloin seurauksena olisi useiden
NULL-arvojen ilmestyminen tietokantaan.

Onko eri toimipisteattribuuteilla tulkinnassa kenties joitain aste-eroja?

Kyselyiden rakentaminen vaikeutuu huomattavasti, kun pitää huomioida paikkakunnan nimen
esiintyminen missä tahansa toimipisteen nimeä edustavassa attribuutissa.
10.3.5 Toinen normaalimuoto
•
Relaatiokaava on toisessa normaalimuodossa, mikäli taulun kaikki avaimeen kuulumattomat
attribuutit ovat funktionaalisesti täydellisesti riippuvia koko avainattribuuttien yhdistelmästä – ei
pelkästään avaimen osasta.
•
Toisen normaalimuodon testaaminen on tarpeellista silloin, jos jokin taulun ehdokasavaimista
koostuu useammasta kuin yhdestä attribuutista.
•
Tarkastellaan kirjan esimerkkiä 10.10. Todetaan, että relaatio EMP_PROJ ei ole 2NF, sillä työntekijän
nimi määräytyy pelkän henkilötunnuksen perusteella ( pääavaimen osa ) ilman projektinumeroa.
Samoin projektinumero määrää yksikäsitteisesti projektin nimen ja sijaintipaikan ilman, että
henkilötunnuksella on mitään merkitystä.
•
Relaatio, joka ei ole 2NF, pitää osittaa siten, että yksistään avaimen osasta riippuvat attribuutit
sijoitetaan riittävän avaimen osan kanssa toiseen relaatiotauluun. Sen sijaan koko pääavaimesta
täysin riippuvat attribuutit jäävät alkuperäiseen relaatiotauluunsa.
•
Tarkastellaan kirjan esimerkkiä 10.10.
10.3.6 Kolmas normaalimuoto
•
Relaatiokaava on kolmannessa normaalimuodossa, mikäli se on 2NF:n mukainen eikä sisällä
transitiivisia riippuvuuksia pääavaimesta. Jos relaatio R sisältää funktionaalisen riippuvuuden Y --> Z
siten, että Y ei ole taulun R superavain tai Z jonkin avaimen osa, ei relaatio ole 3NF:n mukainen.
•
Tarkastellaan kirjan esimerkkiä 10.10. Relaatio EMP_DEPT ei ole kolmatta normaalimuotoa, koska
taulun ei-avainattribuutti DNUMBER määrää yksikäsitteisesti attribuuttien DNAME ja DMGRSSN arvot.
Kyseiset kaksi attribuuttia ovat siten transitiivisesti riippuvia pääavaimesta kentän DNUMBER kautta.
•
Tilanne korjataan muodostamalla uusi taulu, johon asetetaan avaimeksi transitiivisen riippuvuuden
aiheuttanut attribuutti sekä ne attribuutit, joiden arvot määräytyivät tämän perusteella.
•
Aikaisemman taulun EMP_DEPT sisältämät tuplat pystytään toteutetun dekomposition jälkeen
rekonstruoimaan tekemällä luonnollinen liitos taulujen ED1 ( sisältää vain työntekijän attribuutteja +
vierasavaimena osastonumeron ) ja ED2 ( sisältää vain osaston attribuutteja ) välille käyttämällä
liitosattribuuttina osastonumeroa.
10.4 Toisen ja kolmannen normaalimuodon yleiset määritelmät
•
Kappaleessa 10.3 tarkasteltiin 2NF:n ja 3NF:n yhteydessä riippuvuutta pääavaimen osasta ( 2NF )
ja transitiivista riippuvuutta pääavaimesta jonkin ei-avainattribuutin kautta ( 3NF ).
•
Seuraavassa tarkastelu laajennetaan koskemaan kaikkia relaation avainattribuutteja ( ei rajoituta
yksinomaan pääavaimeen ).
10.4.1 Toisen normaalimuodon yleinen määritelmä
•
Relaatio on normaalimuodossa 2NF silloin, kun mikään sen avaimiin kuulumattomista attribuuteista ei
ole osittain riippuvainen minkään avaimen osasta.
•
Tarkastellaan kirjan esimerkkiä 10.11, jossa tontteja kuvaavassa relaatiotaulussa TONTIT ( LOTS )
esiintyy pääavaimen Omaisuustunniste ( PROPERTY_ID ) lisäksi toinenkin ehdokasavain, joka koostuu
attribuuttien LääninNimi ( COUNTY_NAME ) ja Tonttinumero ( LOT# ) yhdistelmästä.
•
Oletetaan lisäksi, että attribuutti Veroaste ( TAX_RATE ) on funktionaalisesti riippuva
vaihtoehtoisavaimen kentästä LääninNimi. Merkitään kyseistä funktionaalista riippuvuutta tunnisteella
FD3. Edelleen oletetaan, että attribuutti Pinta-ala ( AREA ) määrää yksikäsitteisesti tontin
Verotusarvon ( PRICE ). Merkitään tätä ominaisuutta FD4:llä.
•
Tällöin koko relaatio ei täytä vaatimusta 2NF, kun osittainen riippuvuus myös vaihtoehtoisavaimesta
huomioidaan. Siten taulu TONTIT pitää jakaa kahdeksi erilliseksi tauluksi TONTIT1 ja TONTIT2, jotta
osittaisen riippuvuuden aiheuttanut attribuuttipari { LääninNimi, Veroaste } saadaan syrjään
alkuperäisestä relaatiosta.
•
Alkuperäisen taulun TONTIT sisältämät tuplat voidaan rekonstruoida uusista tauluista TONTIT1 ja
TONTIT2 käyttämällä luonnollista liitosta.
•
Kannattaa huomioida, että FD4:stä ei ole mitään haittaa NF2:n toteutumista ajatellen, joten
attribuutteja Pinta-ala ja Verotusarvo ei tarvitse siirtää pois taulusta TONTIT1.
10.4.2 Kolmannen normaalimuodon yleinen määritelmä
•
Relaatio on normaalimuodossa 3NF silloin, kun taulun R jokaiselle ei-triviaalille ( ei siis muotoa X -->
X olevalle ) funktionaaliselle riippuvuudelle X --> A on voimassa joko


X on taulun R superavain tai
A on taulun R avainattribuutin osa
•
Tarkastellaan jälleen esimerkkiä 10.11. Kohdassa ( b ) oleva taulu TONTIT1 ei ( eikä myöskään
kohdan ( a ) taulu TONTIT ) täytä vaatimusta 3NF, koska tontin pinta-ala määrää yksikäsitteisesti
sen verotusarvon. Sen sijaan taulu TONTIT2 on 3NF:n mukainen.
•
Ongelma ratkeaa perustamalla erillinen taulu TONTIT1B, joka sisältää transitiivisen riippuvuuden
aiheuttaneen attribuutin Pinta-ala sekä sen perusteella määräytyvän verotusarvon. Nyt taulut
TONTIT1A, TONTIT1B ja TONTIT2 ovat kaikki 3NF:ssä, ja niiden avulla pystytään rekonstruoimaan
alkuperäisen taulun TONTIT sisältämät tuplat luonnollisin liitoksin.
•
Kannattaa huomioida, että ei ole välttämätöntä normalisoida relaatiota ensinnä 2NF:n ja vasta sitten
3NF:n mukaiseksi. Yhtäläisesti voitaisiin normalisoida suoraan 3NF:ään, jolloin 2NF tulisi huomioitua
samalla. Normalisointijärjestys 2NF --> 3NF on siten lähinnä normaalimuotojen historialliseen
kehitykseen perustuva.
•
Siten voidaan 3NF:n yleinen vaihtoehtoinen määrittely lausua seuraavasti:
Relaatio R on kolmannessa normaalimuodossa, mikäli sen jokainen avaimeen kuulumaton attribuutti
täyttää kummankin seuraavista vaatimuksista:

Se on funktionaalisesti täysin riippuvainen jokaisesta R:n avaimesta

Se on ei-transitiivisesti riippuvainen jokaisesta R:n avaimesta
10.5 Boyce-Coddin normaalimuoto
•
Boyce-Coddin normaalimuoto on normaalimuotoa 3NF tiukempi vaatimus, jonka mukaan
funktionaalinen riippuvuus X --> A voi esiintyä taulussa R ainoastaan silloin, kun X on taulun R
superavain.
•
3NF:n sisältämä toinen vaihtoehto, joka sallisi FR:n olemassaolon myös silloin, kun A on avaimen
osa, ei kelpaa toteuttamaan BCNF:ää.
•
Tarkastellaan kirjan esimerkkiä 10.12a tonttitietoihin liittyen. Lisätään esimerkin 10.11 mukaiseen
tilanteeseen vielä uusi funktionaalinen riippuvuus FD5, jonka mukaan tontin pinta-ala määräisi
yksikäsitteisesti läänin, jossa tontti sijaitsee ( ! ).
•
Taulu TONTIT1A on kylläkin 3NF:n mukainen, sillä LääninNimi on vaihtoehtoisavaimen osa, mutta se
ei täytä enää BCNF:ää, sillä Pinta-ala ei ole kyseisen taulun superavain.
•
Ongelman ratkaisemiseksi tehdään vielä taululle TONTIT1A dekompositio, jossa siitä irrotetaan
attribuutti LääninNimi, joka sijaitsi oikealla puolella FR:ssä Pinta-ala --> LääninNimi.
•
Oikean dekomposition valinnassa pitää olla huolellinen, sillä nyrkkisääntönä tulee pitää sitä, että
kaikki alkuperäisen taulun sisältämä informaatio pitää pystyä rekonstruoimaan, eikä valetuplia saa
syntyä.
•
Tarkastellaan esimerkkinä seuraavia funktionaalisia riippuvuuksia, joiden oletetaan olevan olemassa
tietokannassa:
FR1: { OPISKELIJA, KURSSI } --> OPETTAJA
FR2: { OPETTAJA } --> KURSSI
FR1:n mukaan jokaista opiskelija-kurssi -paria kohti on yksikäsitteinen opettaja. Vastaavasti FR2
sanoo, että yksi opettaja voi opettaa ainoastaan yhtä kurssia.
•
Tarkastellaan kirjan kuvaa 10.12b, joka esittää em. funktionaaliset riippuvuudet taulussa R, missä A
kuvaa opiskelijaa, B kurssia ja C opettajaa. Kyseessä oleva relaatio ei selvästikään ole BCNF:n
mukainen FD2:n takia. Se on kuitenkin 3NF:n mukainen.
•
Pulma: miten relaatio R pitäisi purkaa, jotta se saataisiin BCNF:n mukaiseksi ilman, että mitään
alkuperäisen taulun tiedoista menetetään tai generoidaan virheellisiä tuplia. BCNF:ään päästäisiin
millä tahansa dekompositiolla, joka purkaa nykyisen tilanteen ( HUOM! Jokainen relaatio, jossa on
vain kaksi attribuuttia, on samalla myös BCNF:ssä !!! [ voidaan todistaa helposti ] ). Vaihtoehtoja
olisivat vaikkapa:
1. { OPISKELIJA, OPETTAJA } ja { OPISKELIJA, KURSSI }
2. { KURSSI, OPETTAJA } ja { KURSSI, OPISKELIJA }
3. { OPETTAJA, KURSSI } ja { OPETTAJA, OPISKELIJA }
•
Dekompositiovaihtoehto 1 selvittäisi kylläkin, mitä eri kursseja opiskelijat käyvät ja keiden
opettajien kursseille eri opiskelijat osallistuvat. Kyseisen vaihtoehdon valitseminen jättäisi nyt
kuitenkin hämärän peittoon, kuka opettajista luennoi mitäkin kurssia ( ei pystytä yhdistämään
opettajaa siihen kurssiin, jota hän luennoi ).
•
Vaihtoehto 2 selvittäisi edellisen tapaan, mille eri kursseille opiskelijat osallistuvat. Samoin kävisi
nyt selville, kuka opettajista luennoi mitäkin kurssia. Sen sijaan hämäräksi jäisi, kuka opettajista
luennoisi juuri sitä kurssia, jolle opiskelija osallistuu ( usea opettaja saattaa pystyä luennoimaan
samaa kurssia ).
•
Vaihtoehto 3 osuisi tällä kertaa oikeaan, sillä jos tiedetään, mitä kurssia opettaja luennoi, ja keitä
kaikkia opiskelijoita hänen kurssillaan on, pystytään samalla tietämään, mille eri kursseille
opiskelijat osallistuvat. Tällöin funktionaalisten riippuvuuksien ketju ei pääse katkeamaan.
•
Tarkastellaan kirjan esimerkkiä 10.13, joka havainnollistaa alkuperäisen taulun R mahdollista
tietosisältöä.
•
Oikeellisen tiedon täydellisen säilyvyyden takaamiseksi pitää huolehtia siitä, että dekomposition
tuloksena saatujen taulujen välisillä luonnollisilla liitoksilla pystytään rekonstruoimaan kaikki
alkuperäisen taulun tuplat ja vain ne - mitään valetuplia ei saa tulla generoiduiksi!
•
Seuraavan luvun algoritmia 11.1 voidaan käyttää häviöttömän liitosominaisuuden toteutumiseen
tehdyssä taulujen dekompositiossa.
11. Relaatiotietokannan suunnittelualgoritmit ja
lisäriippuvuudet
•
Tällä kurssilla käsitellään kirjan luvusta 11 ainoastaan kappaleet 11.1 - 11.4 tärkeimmiltä osin.
Näissä käsitellään funktionaalisten riippuvuuksien säilymistä ja häviöttömän liitoksen toteutumista
relaatioiden dekompositioissa, puuttuvia arvoja sekä neljättä ja viidettä normaalimuotoa.
11.1 Relaatioiden dekompositioiden ominaisuuksia
•
Seuraavassa tullaan havaitsemaan, ettei pelkästään yksittäisten relaatioiden riittävän korkeaa
astetta olevan normaalimuodon toteutuminen ole tae sille, että suunnittelu olisi onnistunut. Sen
sijaan on tarkasteltava useita relaatioita yhdessä.
•
Tärkeitä ominaisuuksia relaatioihin jaon onnistumiselle ovat funktionaalisten riippuvuuksien
säilyminen sekä häviöttömän liitoksen ominaisuus. Näiden toteutumista voidaan testata jatkossa
esiteltävien algoritmien avulla.
11.1.1 Normaalimuotojen riittämättömyys relaatioita ositettaessa
•
Oletetaan, että lähdetään liikkeelle universaalista relaatiokaavasta R = { A1, A2, A3, ..., An }, joka
sisältää tarkasteltavan tietokannan kaikki attribuutit.
•
Edellisen oletuksen seurauksena kaikki R:n attribuutit ovat keskenään erinimisiä.
•
Olkoon D = { R1, R2, ..., Rn } relaatiokaavan R ositus pienempiin relaatioihin.
•
Koska osituksessa ei saada menettää mitään kaavan R sisältämästä tiedosta, pitää selvästikin
relaatioiden Ri unionin sisältää kaikki R:n attribuutit.
•
Edelleen oletetaan, että jokainen Ri edustaa vähintään kolmatta normaalimuotoa.
•
Pelkästään kaikkien attribuuttien esiintymiseen ja normaalimuotojen toteutumiseen huomiota
kiinnittämällä voidaan yhä saada aikaan epäonnistuneita relaatioiden osituksia.
•
Tarkastellaan kirjan esimerkkiä 10.5. Relaatio EMP_LOCS on kolmatta ja myös BCNFnormaalimuotoa. Muodostettaessa liitos taulun EMP_LOCS ja EMP_PROJ1 ( kirjassa painovirhe )
saadaan tulokseksi kuitenkin kelvottomia tuplia, kuten kuvasta 10.6 ilmenee.
•
Tilanne ei kuitenkaan parane, vaikka muodostettaisiin liitos taulujen EMP_LOCS ja esimerkin 5.6
PROJECT-taulujen välille. Nyt kumpikin on BCNF-normaalimuodon mukainen, mutta yhä edelleen
liitos tuottaa valetuplia
•
Tarvitaan normaalimuotojen lisäksi selvästikin myös muita kriteerejä, jotta vältyttäisiin huonolta
relaatioihin ositukselta.
11.1.2 Funktionaalisten riippuvuuksien säilyttäminen relaatiota ositettaessa
•
Olisi suotavaa, että jokainen alkuperäisessä relaatiokaavassa esiintynyt funktionaalinen
riippuvuus X ---> Y esiintyisi jossakin ositteista Ri tai että sen olemassaolo pystyttäisiin
päättelemään sen sisältämien riippuvuuksien perusteella. Tämä tarkoittaa ei-formaalisti
lausuttuna riippuvuuksien säilyvyyttä.
•
Jokaista funktionaalista riippuvuutta pidetään tietokannan tiloille asetettuna rajoituksena.
•
Jos jotain alkuperäisistä riippuvuuksista ei esiinny sellaisenaan missään osituksella
aikaansaaduista tauluista, pitää riippuvuuden olemassaolo todentaa liitoksien avulla. Tämä on
selvästikin tehoton ja epäkäytännöllinen toimenpide.
•
Tarkastellaan esimerkkiä 10.12a osituksesta, jossa funktionaalien riippuvuus
{ LÄÄNI, TONTTINUMERO } ---> OMAISUUSLAJI, PINTA-ALA lakkaa olemasta voimassa. Samoin
käy esimerkin 10.13 relaatiossa OPETUS - tehtiinpä millainen ositus alkuperäiselle relaatiolle
tahansa.
•
Voidaan osoittaa, että aina voidaan löytää R:lle 3NF:n mukainen ositus, joka säilyttää sen
funktionaaliset riippuvuudet ( ei kuitenkaan välttämättä BCNF:n mukaista ).
11.1.3 Dekomposition häviöttömän ( ei-additiivisen ) liitoksen ominaisuus
•
Suoritettaessa dekompositio D taululle R ositteisiin { R1, R2, ..., Rm } pitää varmistua, että taulun R
tietosisältö pystytään tarkalleen palauttamaan eli rekonstruoimaan soveltamalla luonnollisia liitoksia
dekompositiossa muodostuneiden uusien, kooltaan pienempien taulujen välille.
•
Formaalisesti määriteltynä dekompositio D säilyttää taululle R häviöttömän liitoksen ominaisuuden,
mikäli mille tahansa relaation R lailliselle tilalle olla voimassa:
*(π
R1
( r ), ..., π
Rm
(r))=r
•
Toteutuessaan häviöttömän liitoksen ominaisuus takaa, ettei dekompositio tuota valetuplia relaatioon R,
kun sitä kootaan D:n osatauluista luonnollisilla liitoksilla.
•
Häviöttömän liitoksen toteutumista voidaan testata algoritmisesti. Yleiskäyttöisin testausalgoritmeista
on seuraavassa esiteltävä algoritmi 11.1, joka ei ota kantaa siihen, moneenko osaan alkuperäinen taulu
R hajoaa dekomposition D yhteydessä.
Algoritmi 11.1: Häviöttömän liitoksen toteutumisen testaus
Syötetiedot: Normalisoinnin kohteena oleva relaatio R, sille suoritettu dekompositio
D = { R1, R2, ..., Rm } sekä funktionaalisen riippuvuuksien joukko F relaatiossa R
1. Perustetaan matriisi S, jossa on yhtä monta riviä kuin D:ssä on tauluja ja yhtä monta saraketta
kuin relaatiossa R on attribuutteja. Sarakkeet nimetään R:n attribuuttien mukaisesti.
2. Alustetaan jokainen matriisin positio S[i, j] alkuarvolla bij.
3. Toista jokaista matriisin riviä i kohti
Toista jokaista matriisin saraketta j kohti
Jos dekomposition D relaatiossa Ri esiintyy attribuutti j,
Vaihda paikan S[i, j] sisällöksi aj.
4. Toista niin pitkään, kunnes silmukan suorituksen aikana ei enää tapahdu muutoksia matriisissa S
Toista F:n jokaista funktionaalista riippuvuutta X --> Y kohti
Toista jokaista S:n riviä kohti, joilla on sarakkeissa samat symbolit X:n attribuuteilla
Vaihda Y:hyn kuuluvien attribuuttien symbolit vastaamaan toisiaan näillä riveillä.
Jos jollain kyseisistä riveistä esiintyy symbolia a, kopioidaan se samalla kaikkien
muiden tarkasteltavien rivien samaan sarakkeeseen. Ellei a:ta esiinny millään
rivillä Y:n attribuuteilla, yhdenmukaistetaan sarakkeen arvot jonkin rivin
bij-arvon mukaisesti kaikilla tutkittavilla riveillä.
5. Jos jokin matriisin riveistä sisältää ainoastaan a-symboleita, on normalisoinnin tulokseksi saatu
dekompositio D toteuttanut häviöttömän liitoksen kriteerin, muulloin ei.
•
Tarkastellaan kirjan esimerkkiä 11.1. Todetaan, että esimerkissä 10.3 esitetyn EMP_PROJ-relaation
dekompositio esimerkin 10.5 mukaisiin ositteisiin EMP_PROJ1 ja EMP_LOCS ei tuota häviötöntä
liitosta, kun taas dekompositio tauluiksi EMP, PROJECT ja WORKS_ON tuottaa sellaisen.
11.1.4 Häviöttömän liitoksen toteutumisen testaaminen ositettaessa vain kahteen tauluun ( binäärinen ositus )
•
Jos alkuperäisen relaation ositus tapahtuu pelkästään kahteen pienempään relaatioon, voidaan käyttää
algoritmia 11.1 yksinkertaisempaa testiä.
•
Relaation R dekompositio D = { R1, R2 } tuottaa häviöttömän liitoksen, joka huomioi R:n
funktionaaliset riippuvuudet F tarkalleen silloin, kun joko
FR (( R1  R2 ) ---> ( R1 - R2 )) esiintyy joukossa F+
tai
FR (( R1  R2 ) ---> ( R2 - R1 )) esiintyy joukossa F+
•
Säännön oikeellisuus on helposti todennettavissa ( todistus sivuutetaan kuitenkin tässä ).
•
Tarkastellaan esimerkin 10.3a relaatiota EMP_DEPT asian valaisemiseksi.
11.1.5 Häviöttömän liitoksen toteutuminen perättäisissä osituksissa
•
Voidaan todistaa, että jos D = { R1, R2, ..., Rm } on R:n ositus, joka säilyttää häviöttömän liitoksen
huomioiden sen funktionaaliset riippuvuudet, ja edelleen Di = { Q1, Q2, ... , Qk } on Ri:n funktionaaliset
riippuvuudet säilyttävä uusi ositus ( 1  i  m ), niin silloin ositus
D2 = { R1, R2, ..., Ri-1, Q1, Q2, ..., Qk, Ri+1, ..., Rm } on myös häviöttömän liitoksen ominaisuuden
säilyttävä R:n ositus.
11.2 Relaatiotietokannan kaavan suunnittelualgoritmeja
•
Tarkastellaan kolmea algoritmia, joiden avulla voidaan muodostaa relaatioiden ositus. Jokaisella
näistä on eri tyyppisiä piirteitä.
11.2.1 Funktionaaliset riippuvuudet säilyttävä ositusalgoritmi kolmannen normaalimuodon relaatiokaavoille
•
Algoritmi 11.2 muodostaa funktionaaliset riippuvuudet säilyttävän osituksen D = { R1, R2, ..., Rm }
universaalille ( = kaikki attribuutit sisältävälle ) relaatiolle R siten, että jokainen Ri on kolmatta
normaalimuotoa. Algoritmi on seuraavanlainen:
Syöte: Universaali relaatio R sekä sen funktionaalisten riippuvuuksien joukko F
1. Etsi F:n minimaalinen peitto G ( käyttämällä algoritmia 10.2 )
2. Jokaisen riippuvuuden X ---> Y vasenta puolta eli X:ää kohti perustetaan relaatiokaava D,
joka sisältää attribuuttien joukon X sekä kaikki tarkalleen siitä riippuvat attribuutit Ai, 1  i  k,
joille siis on voimassa X---> A1, X ---> A2, ..., X ---> Ak. Aseta X kyseisen relaation avaimeksi.
3. Sijoita kaikki muut R:n attribuutit ( joita ei ole vielä viety mihinkään ositteeseen ) vielä yhteen
ylimääräiseen relaatiokaavaan, jotta kaikki alkuperäiset attribuutit tulisivat huomioiduiksi.
•
Voidaan todistaa ( joukon G ominaisuuksiin perustuen ), että jokainen algoritmin 11.2. avulla luotu
relaatiokaava on 3NF:n mukainen.
11.2.2 Häviöttömän liitoksen dekompositio BCNF:n toteuttaviksi kaavoiksi
•
Algoritmi 11.3 osittaa universaalin relaation R = { A1, A2, A3, ..., An } dekompositioksi
D = { R1, R2, ..., Rm } siten, että jokainen uusista relaatioista Ri on BCNF:n mukainen ja D toteuttaa
häviöttömän liitoksen ominaisuuden suhteessa R:n funktionaalisten riippuvuuksien joukkoon F.
•
Algoritmi perustuu kappaleiden 11.1.4 ja 11.1.5 sääntöjen oikeellisuuteen.
Syöte: Universaali relaatio R sekä sen funktionaalisten riippuvuuksien joukko F
1. Aseta D = { R }
2. Toista niin pitkään kuin D:ssä esiintyy relaatiokaava Q, joka ei ole BCNF-muodossa
Valitse jokin relaatiokaavoista Q, joka ei ole BCNF:ssä
Etsi funktionaalinen riippuvuus X ---> Y, joka rikkoo BCNF-ominaisuuden
Korvaa relaatio Q joukossa R kahdella relaatiokaavalla ( Q - Y ) ja ( X  Y )
11.2.3 Funktionaaliset riippuvuudet säilyttävä ja häviöttömän liitoksen toteuttava 3NF-ositusalgoritmi
•
Algoritmi 11.4 yhdistää algoritmien 11.2 ja 11.3 hyvät ominaisuudet, eli
* säilyttää funktionaaliset riippuvuudet
* sisältää häviöttömän liitoksen ominaisuuden
* tuloksena saatavat relaatiot toteuttavat 3NF-normaalimuodon
Syöte: Universaali relaatio R sekä sen funktionaalisten riippuvuuksien joukko F
1. Etsi F:n minimaalinen peitto G ( käyttämällä algoritmia 10.2 )
2. Perusta jokaista eri X:ää kohti funktionaalista riippuvuutta X ---> Y varten oma relaatiotaulu,
jonka attribuuteiksi sijoitetaan kaikki Y-puolen attribuutit, ja X itse asetetaan relaation
avaimeksi. Näistä relaatiokaavoista koostuu alkuperäisen relaation R ositus D.
3. Ellei yksikään D:n relaatiokaavoista sisällä R:n avainta, perustetaan vielä yksi lisärelaatio, joka
sisältää R:n avainattribuutit.
•
Algoritmin kolmannessa vaiheessa tapahtuva R:n avaimen määrääminen voidaan tehdä seuraavaksi
esiteltävää algoritmia 11.4a käyttämällä.
•
Algoritmi 11.4a Universaalin relaatio R avaimen määrääminen
Syöte: Universaali relaatio R sekä sen funktionaalisten riippuvuuksien joukko F
1. Aseta avaimen alkuarvoksi kaikkien R:n attribuuttien yhdistelmä, eli K := R.
2. Toista jokaista K:n sisältämää attribuuttia A kohti
Määrää ( K - A )+ suhteessa F:ään
Jos ( K - A )+ sisältää kaikki R:n attribuutit, aseta tällöin K := K - { A }.
•
Algoritmin kolmannessa vaiheessa tapahtuva R:n avaimen määrääminen voidaan tehdä seuraavaksi
esiteltävää algoritmia 11.4a käyttämällä.
•
On tärkeää huomioida, että häviöttömän liitoksen muodostavien ositusten teoria nojautuu olettamukseen,
ettei liitosattribuuteissa saa esiintyä NULL-arvoja. Puuttuvista arvoista aiheutuvia ongelmia tarkastellaan
seuraavassa kappaleessa.
11.2.4 Puuttuvista arvoista ja irrallisista tuplista aiheutuvia ongelmia
•
Relaatioiden suunnitteluteoria ei toistaiseksi kata riittämiin puuttuvien arvojen käsittelyyn liittyviä pulmia.
•
Ongelmia esiintyy, mikäli liitosattribuutit voivat sisältää NULL-arvoja.
•
Tarkastellaan kirjan esimerkkiä 11.2a, jossa yritykseen otetaan kaksi uutta työntekijää, mutta heitä ei
haluta välittömästi kirjata millekään osastolle ( olettaen, että osastonumeron jättäminen tallentamatta
olisi TYÖNTEKIJÄ-taulun määrittelyn mukaan sallittua ).
•
Jos nyt haluttaisiin luonnollista ( tai theta- ) liitosta hyväksi käyttämällä tehdä kysely, johon haluttaisiin
jokaisen työntekijän sekä hänen osastonsa tiedot, eivät kaksi uutta työntekijää näkyisi listauksessa,
koska liitosehto osastonumeroiden kohdalla jäisi toteutumatta. Puutteellinen tulostaulu on nähtävissä
kirjan esimerkissä 11.2b.
•
Ongelma ratkeaisi käyttämällä vasenta ulkoista liitosta työntekijän ja osaston välillä. Nyt ne työntekijät,
joiden osastonumero puuttuu, liitetään 'kuvitteellisen' osaston kanssa, jonka kaikki attribuutit sisältävät
arvon NULL. Tällöin saataisiin esimerkin 11.2c mukainen oikeellinen tulostaulu.
•
Mahdollisten puuttuvien arvojen huomiointi on oleellista myös muiden kuin vierasavainattribuuttien
kohdalla, jos halutaan soveltaa esimerkiksi koostefunktioita. Esimerkiksi tästä kävisi vaikkapa
palkkakertymän tai -keskiarvon laskenta käyttämällä attribuuttia SALARY, jos se voi sisältää puuttuvia
arvoja.
•
Puuttuvien arvojen ongelmaa muistuttaa myös irrallisten tuplien ongelma. Tällaista voi esiintyä, jos
relaation osittamista jatketaan liian pitkälle.
•
Tarkastellaan kirjan esimerkkejä 11.3a ja 11.3b. Ajatuksena on osittaa TYÖNTEKIJÄ-relaatio siten, että
tieto työntekijän osastonumerosta sijoitetaan henkilötunnuksen kanssa erikseen uuteen tauluun
EMPLOYEE_2 ja osastonumero poistetaan alkuperäisestä taulusta, ja supistunut EMPLOYEE-taulu
nimetään tunnuksella EMPLOYEE_1.
•
Jos tauluun EMPLOYEE_2 viedään kaikki sellaisetkin työntekijät, joiden osastonumero on tuntematon,
voidaan alkuperäinen EMPLOYEE-taulu rekonstruoida taulujen EMPLOYEE_1 ja EMPLOYEE_2 luonnollisella
liitoksella. Jos puolestaan taulun EMPLOYEE_2 asemesta perustetaan taulu EMPLOYEE_3, johon ei viedä
työntekijöitä, joiden osastoa ei tiedetä, ei luonnollinen liitos enää riitä palauttamaan alkuperäistä taulua.
Osastonumeroa vailla olevien työntekijät ovat taulussa EMPLOYEE_1 ns. irrallisia tuplia, koska niillä ei ole
vastinetta taulussa EMPLOYEE_3. Tämä ilmenee kirjan esimerkistä 11.3c.
11.3.3 Neljäs normaalimuoto
•
Neljäs normaalimuoto liittyy yksistään pääavaimen osasta riippuvien moniarvoisten riippuvuuksien
purkamiseen.
•
Tällainen tilanne saattaa syntyä, jos samaan relaatiotauluun yritetään sijoittaa kaksi
lukumääräsuhteeltaan 1:N olevaa liittymää - yleensä ne kuvaavat moniarvoisia attribuutteja.
•
Tarkastellaan kirjan esimerkkiä 11.5, jossa työntekijän tietoihin on yhdistetty tiedot projekteista, joissa
hän työskentelee sekä tiedot hänen perheenjäsenistään.
•
Relaatio on kylläkin 3NF:n mukainen, mutta sen toteutus on kovin kömpelö, sillä pakottaa lisäämään
jokaista työntekijää kohti kerralla useita tuplia, jos työntekijä alkaa työskennellä uudessa projektissa,
tai hänen perheenjäsentensä lukumäärä kasvaa.
•
Tilanne purkautuu normalisoimalla relaatio 4NF:n mukaiseksi erottelemalla työntekijän projektit ja
perheenjäsenet eri tauluihinsa.
•
Relaatio on 4NF:n mukainen tarkalleen silloin, kun kaikki siinä esiintyvät sekä funktionaaliset ja
moniarvoiset riippuvuudet määräytyvät yksinomaan superavaimesta X -->> Y.
11.4 Liitosriippuvuudet ja viides normaalimuoto
•
Viidettä normaalimuotoa tarkastellaan lähinnä astetta 3 ja sitä korkeampaa astetta olevien
relaatioiden yhteydessä.
•
Käytännössä normalisointia 5NF:ään sovelletaan erittäin harvoin.
•
Tarkastellaan esimerkkinä tavarantoimitusrelaatiota toimittajan, osan ja projektin välillä. Oletetaan,
että jos toimittaja t pystyy toimittamaan osaa o, osaa o tarvitaan projektissa p, ja toimittaja t
toimittaa jotain osaa projektille p, niin silloin projektille p ostetaan o ( ainakin ) toimittajalta t.
•
Tarkastellaan lopuksi kirjan esimerkkejä 11.4c ja 11.4d.
14. Tiedostojen indeksirakenteet
•
Tässä luvussa oletetaan, että datatiedosto on jo perustettu jotain rakennetta noudattaen
( järjestämättömänä, järjestämällä fyysisesti tietyn kentän mukaan, käyttämällä
hajautustekniikkaa ).
•
Indeksillä tarkoitetaan saantirakennetta, jonka avulla tietueiden hakemista määrätyn kriteerin
mukaisesti saadaan nopeutettua.
•
Indeksi edustaa ns. toissijaista saantipolkua ( secondary access path ), jonka käyttäminen ei
vaikuta tietueiden fyysiseen tallennusrakenteeseen levyllä.
•
Indeksi voidaan perustaa mille tahansa tietueen tietokentälle, ja se voi olla joko yksin- tai
moninkertainen.
•
Indeksit perustuvat usein järjestetyn tiedoston käyttämiseen, ja indeksien talletusrakenteena
käytetään yleisesti B- tai B+-puuta.
14.1. Yksitasoisten indeksien tyypit
•
Indeksi muistuttaa kirjojen avainsanaluetteloa, jota selaamalla löydetään, millä sivuilla jokin tietty
termi kirjassa esiintyy.
•
Ellei tällaista luetteloa olisi käytettävissä, pitäisi kirjaa lähteä selaamaan alusta loppuun asti tai
hyödyntämällä mahdollisesti otsikkojen ja väliotsikkojen nimiä ilmeisimmin oikeiden kappaleiden
löytämiseksi ja vastaavasti turhien kappaleiden karsimiseksi.
•
Indeksi perustuu tyypillisesti tiedostossa olevien tietueiden yhden kentän ( = attribuutin ) arvoihin,
jotka järjestetään joko nousevaan tai laskevaan suuruusjärjestykseen.
•
Tärkein saavutettu etu: pystytään käyttämään hyväksi puolitushakua etsittäessä hakuehdon
täyttäviä tietueita, kunhan hakuehto perustuu indeksikentän arvoon.
•
Indeksitiedosto on paljon datatiedostoa pienempi, joten puolitushaku toimii tehokkaasti.
•
Yksinkertaisia indeksejä on kolmea lajia:
o
Pääindeksi ( primary index ) perustuu järjestetyn tiedoston järjestysavainkenttään. Siten
primääri-indeksikentän arvolla ei tietueissa saa esiintyä duplikaatteja ( samaa arvoa kahdesti
tai useammin ).
o
Ryvästysindeksi ( clustering index ) sallii indeksikentälle myös duplikaatteja.
o
Toisioindeksi ( secondary index ) voidaan muodostaa mille tahansa tiedoston kentälle, jonka
mukaan tiedosto ei ole valmiiksi järjestetty.
•
Koska pää- ja ryvästysindeksi perustuvat järjestetyn tiedoston fyysiseen tallennusrakenteeseen, niitä
voi tiedostossa esiintyä kerrallaan tarkalleen yksi ja vain jompikumpi indekseistä. Pää- tai
ryvästysindeksi on tiedoston pääsaantimenetelmä ( primary access method ).
•
Sen sijaan toisioindeksejä voi tiedostoa kohti esiintyä kerrallaan useita.
14.1.1. Pääindeksit
•
Pääindeksi on järjestetty tiedosto, joka sisältää kaksi kenttää ja jonka tietueet ovat kiinteän
mittaisia.
•
Ensimmäiseen kenttään on tallennettuna tiedoston järjestysavaimen arvo, joka on samalla tiedoston
pääavain ( primary key ).
•
Toinen kenttä sisältää puolestaan osoittimen levyblokkiin, josta pääavaimen arvoa vastaava tietue on
löydettävissä.
•
Jokaista levyblokkia kohti on tarkalleen yksi tietue pääindeksitiedostossa. Indeksitiedoston tietue
esitetään muodossa < K( i ), P( i ) >, missä K( i ) on i:nnen tietueen pääavaimen arvo ja P( i )
kyseisen tietueen levyblokki-osoite. Toisin sanoen, kaikkia datatiedoston tietueita kohti ei ole
olemassa tietuetta pääindeksitiedostossa!
•
Tarkastellaan kirjan kuvassa 13.7. esitettyä esimerkkiä järjestetystä tiedostosta ja pääindeksin
soveltamista siihen.
•
Ensimmäiset kolme pääindeksitiedoston tietuetta näyttäisivät seuraavanlaisilta olettaen, että nimi on
tiedostossa pääavaimen asemassa (muussa tapauksessa ei pääindeksiä voitaisi muodostaa, vaan
tarvittaisiin ryvästysindeksi!):
< K( 1 ) = ( Aaron, Ed ), P( 1 ) = blokin 1 osoite >
< K( 2 ) = ( Adams, John ), P( 2 ) = blokin 2 osoite >
< K( 3 ) = ( Alexander, Ed ), P( 3 ) = blokin 3 osoite >
•
Pääindeksitoteutus em. esimerkille on nähtävissä kuvassa 14.1.
•
Datatiedoston kunkin blokin ensimmäistä ( toisenlaisessa toteutuksessa vastaavasti viimeistä )
tietuetta kutsutaan blokin ankkuriksi.
•
Indeksin sanotaan olevan toteutukseltaan tiivis ( dense ), mikäli kutakin datatiedoston tietuetta kohti
esiintyy tietue myös indeksitiedostossa. Muussa tapauksessa indeksi on harva ( nondense, sparse ).
Siten pääindeksi on toteutukseltaan harva.
•
Pääindeksitiedosto vaatii selkeästi vähemmän muistitilaa kuin datatiedosto, sillä:
1. Pääindeksitiedostossa on vähemmän tietueita kuin sitä vastaavassa datatiedostossa.
2. Pääindeksitiedoston tietueet ovat fyysisesti lyhyempiä, sillä ne sisältävät vain kaksi kenttää.
---> Siten indeksitiedoston tietueita mahtuu yhteen blokkiin enemmän kuin vastaavan
datatiedoston tietueita, joten haku indeksitiedostosta vaatii keskimäärin vähempien
blokkien tutkimista puolitushaulla kuin suora datatiedostosta haku puolitushaulla. Tietue,
jonka avainkentän arvo on K, löytyy ( jos se on ylipäätään löytyäkseen tiedostosta )
blokista, jonka osoite on P( i ) siten, että K( i )  K < K( i + 1 ), sillä K on pääavainkentän
arvo.
•
Täten pitää etsiä tietueen oikea sijaintipaikka blokin tarkkuudella indeksitiedostosta, ja sen
jälkeen haetaan kyseinen blokki, josta tietue voi löytyä.
•
Haku pääindeksitiedostoa hyväksi käyttäen on tehokkaampaa kuin suoraan datatiedostosta.
Tarkastellaan asiaa seuraavan esimerkin valaisemana:
•
Esimerkki: Oletetaan, että on opiskelijatiedostossa on 30000 tietuetta. Tietueet ovat kiinteän
mittaisia, ja yhden tietueen pituus on 100 tavua. Yhden blokin koko on 1024 tavua.
Siten yhteen blokkiin mahtuu 1024/100 eli 10 tietuetta, joten blokkeja tarvitaan
yhteensä 30000/10 = 3000 kappaletta.
Binäärihaku 3000 blokista maksaa selvästikin maksimissaan log23000 = 12 hakua.
Tehdään vertailu, mitä vastaava haku maksaisi käyttämällä pääindeksitiedostoa
hyväksi. Oletetaan nyt, että pääavainkentän pituus on 9 tavua ja
levyblokkiosoitekentän 6 tavua. Koska pääindeksitiedoston tietueet ovat kiinteän
mittaisia, tällöin sen tietueita mahtuu yhteen blokkiin 1024/15 = 68 kappaletta.
Jokaista datatiedoston blokkia varten tarvitaan yksi tietue pääindeksiin. Siten
blokkeja tarvitaan pääindeksitiedostoa varten yhteensä 3000/68 = 45 kappaletta.
Puolitushaku 45 blokista vaatii ajan log245, eli hakuja tarvitaan maksimissaan 6
kappaletta. Lisäksi tarvitaan yksi ylimääräinen haku datatiedoston oikeaan
levyblokkiin, joten hakujen yhteismäärä on 7, joka on nopeampi kuin suoraan datatiedostoon kohdistuneen haun vertailujen määrä 12.
•
Pulmatilanne pääindeksitiedoston käyttämisessä: uuden tietueen lisääminen tiedostoon.
o
Pitää löytää paitsi oikea sijoituspaikka fyysisessä datatiedostossa, joudutaan lisäksi
indeksitiedosto organisoimaan uudelleen, sillä blokkien ankkurit varsin ilmeisesti muuttuvat.
o
Pulman ratkaisemiseksi voidaan perustaa järjestämätön ylivuototiedosto, kuten todettiin
järjestettyjen tiedostojen yhteydessä, tai muodostaa datatiedoston blokkeihin ylivuotoalue
linkitetyn listan avulla kuten hajautusten yhteydessä.
14.1.2. Ryvästysindeksit
•
Mikäli datatiedoston tietueet on järjestetty fyysisesti muun kuin avainkentän mukaan, käytetään
järjestyskentästä nimitystä ryvästyskenttä ( clustering field ).
•
Tällaista kenttää kohti voidaan ei voida perustaa pääindeksiä, vaan sen sijaan tähän tarkoitukseen
kelpaa ryvästysindeksi.
•
Ryvästysindeksin käyttötarkoitus on kuitenkin sama kuin pääindeksin: tietueiden nopeutunut haku
tiedoston fyysisen lajittelukentän arvon mukaisesti.
•
Ryvästyshakemistossa on tietue jokaista ryvästyskentän arvoa kohti. Jokainen hakemiston tietue
sisältää ryvästyskentän arvon sekä osoittimen ensimmäiseen datatiedoston blokkiin, jossa kyseistä
tietueen arvoa esiintyy.
•
Tarkastellaan kirjan esimerkkiä 14.2.
•
Kannattaa huomioida, että nytkin tietueiden lisääminen datatiedostosta (samoin myös poistaminen)
aiheuttavat hankaluuksia, koska datatiedosto on fyysisesti järjestetty. Tällöin muutos datatiedostossa
voi aiheuttaa muutoksia myös ryvästysindeksitiedostossa.
•
Usein datatiedosto toteutetaan siten, ettei saman blokin sisällä esiinny tietueissa kuin yhtä
ryvästyskentän arvoa, mikä poistaa ryvästystiedoston osoittimien uudelleenjärjestelyn tarpeen.
Tällöinkin kuitenkin täysin uuden ryvästyskentän arvon luonti aiheuttaa vaikeuksia.
•
Kuten pääindeksikin, myös ryvästysindeksi on toteutukseltaan harva, sillä kukin ryvästyskentän arvo
on edustettuna hakemistossa ( =ryvästysindeksitiedostossa ) vain kertaalleen.
•
Ryvästysindeksi muistuttaa toteutuksensa puolesta laajennettavaa hajautusta ( kts. kurssin
ulkopuolinen kirjan kappale 13.8.3 ).
14.1.3. Toisioindeksit
•
Myös toisioindeksi on järjestetty tiedosto, jonka tietueilla on kaksi kenttää.
•
Ensimmäinen kenttä edustaa datatiedoston jonkin sellaisen kentän arvoa, jonka mukaan datatiedosto
ei ole fyysisesti järjestetty.
•
Toinen kenttä on puolestaan joko blokki- tai tietueosoitin datatiedostoon.
•
Yhtä datatiedostoa kohti voi olla perustettuina useita toisioindeksejä.
•
Toisioindeksin toteuttamiseen vaikuttaa, onko indeksoinnin kohteena datatiedoston vaihtoehtoinen
avainkenttä (ei kuitenkaan fyysisen tallennuksen mukainen järjestysavain) vai kenttä, jonka arvoilla
esiintyy duplikaatteja.
•
Tarkastellaan aluksi vaihtoehtoisavaimeen perustuvaa toisioindeksiä ( kirjan esimerkki 14.4 ).
•
Koska datatiedosto ei ole fyysisesti järjestetty vaihtoehtoisavaimen suhteen, ei voida käyttää hyväksi
blokkiankkureita. Täten jokaista datatiedoston tietuetta kohti on oltava tietue myös
toisioindeksitiedostossa
---> Toisioindeksi on tiivis. Siten toisioindeksitiedostosta haku kestää jossain määrin kauemmin kuin
pääindeksistä.
•
Toisioindeksin perustamisesta saatava hyöty on kuitenkin huomattavasti suurempi kuin pääindeksin
perustamisesta, kun vertailukohtana on pelkän fyysisesti järjestetyn tiedoston käyttäminen ilman
indeksointia, sillä pääindeksi voitaisiin kuitenkin korvata suoraan datatiedostoon kohdistuvalla
puolitushaulla, kun taas toisioindeksille vaihtoehtona olisi lineaarihaku!
•
Esimerkki: Oletetaan, että aikaisemmin pääindeksin yhteydessä tarkasteltuun 30000 tietueen
opiskelijatiedostoon perustetaan toisioindeksi jonkin muun avainkentän kuin tiedoston
fyysisen järjestysavainkentän suhteen. Yhden levyblokin koko on 1024 tavua.
Oletetaan nyt, että vaihtoehtoisenkin avainkentän pituus on 9 tavua ja
levyblokkiosoitekentän 6 tavua. Koska myös toisioindeksitiedoston tietueet ovat
kiinteän mittaisia, tällöin sen tietueita mahtuu yhteen blokkiin 1024/15 = 68
kappaletta, kuten oli tilanne pääindeksinkin kohdalla.
Jokaista datatiedoston tietuetta varten tarvitaan yksi tietue toisioindeksiin. Siten
blokkeja tarvitaan toisioindeksitiedostoa varten yhteensä 30000/68 = 442
kappaletta.
Puolitushaku 442 blokista vaatii ajan log2442, eli hakuja tarvitaan maksimissaan 9
kappaletta. Lisäksi tarvitaan yksi ylimääräinen haku datatiedoston oikeaan levyblokkiin,
joten hakujen yhteismäärä on 10, joka on absoluuttisesti vain hieman enemmän kuin
haku samasta datatiedostosta pääindeksin avulla, mutta ero lineaarihaun keskiarvoon
( 1500 blokkia ) on valtava.
•
Toisioindeksi voidaan rakentaa myös sellaiselle datatiedoston kentälle, joka ei kelpaa avaimeksi
( arvoilla esiintyy duplikaatteja ).
•
Vaihtoehtoisia toteutustapoja:
1.
Toistetaan toisiohakemistossa indeksoinnin kohteena olevan kentän keskenään samoja
arvoja yhtä monta kertaa, kuin niitä esiintyy datatiedostossa. Tällöin toisioindeksistä tulee
tiivis.
Esimerkki: Henkilön nimen mukaan fyysisesti järjestetty työntekijätiedosto haluttaisiin
indeksoida myös osastonumeron mukaan. Tällöin pitäisi kutakin osastonumeroa
toistaa niin monta kertaa kuin osastolla on työntekijöitä.
2.
Esitellään toisioindeksi vaihtelevan mittaisina tietueina, jossa jokaista indeksikentän arvoa
seuraa osoitinlista niihin datatiedoston blokkeihin, joissa kyseistä kentän arvoa esiintyy.
Koska kutakin indeksikentän arvoa edustaa indeksissä vain yksi tietue, toisioindeksistä
tulee tällä toteutuksella harva.
3.
Pidetään toisioindeksitiedoston tietueet kiinteän mittaisina, ja asetetaan kutakin
indeksikentän arvoa kohti osoitin erilliseen blokkiin, joka sisältää osoittimet kaikkiin niihin
datatiedoston tietueisiin, joissa tiettyä indeksikentän arvoa esiintyy. Mikäli johonkin
indeksikentän arvoon liittyvät kaikki tietueosoittimet eivät mahdu niille varattuun blokkiin,
joudutaan turvautumaan ylivuotoalueiden käyttöön. Myös tämä vaihtoehto johtaa harvaan
indeksiin. Tarkastellaan kirjan esimerkkiä 14.5.
•
Vaihtoehdot 1 ja 2 aiheuttavat muutoksia puolitushakualgoritmiin, sillä vaihtoehdossa 1 esiintyy
hakukentässä duplikaatteja ja vaihtoehdossa 2 tietueet eivät ole kiinteän mittaisia.
•
Vaihtoehdossa 3 tarvitaan yksi ylimääräinen blokkihaku osoitinblokkirakenteen tähden, mutta
tietueiden haku ja lisäys ovat suoraviivaisempia kuin vaihtoehdoissa 1 ja 2. Siten vaihtoehto 3
on yleisimmin käytössä oleva.
•
Toisioindeksi voidaan tulkita datatiedoston ns. loogiseksi lajitteluksi indeksikentän mukaan.
14.2. Monitasoiset indeksit
•
Monitasoisen indeksin tavoitteena on pienentää hakuaikaa log2bi:stä, missä bi on indeksitiedoston
blokkien lukumäärä, siten, että logaritmin kantaluku kasvaa.
•
Hakemistotasot numeroidaan ykkösestä alkaen siten, että tasolla 1 on osoitteet datatiedoston
blokkeihin, tasolla 2 tason 1 blokkeihin jne. Korkeimmalla hakemistotasolla t on ainoastaan yksi
blokki, joka sisältää osoitteet tasolle t-1.
•
Merkintä bfri, joka tarkoittaa yhteen blokkiin mahtuvien indeksitiedoston tietueiden lukumäärää,
tarkoittaa samalla hakemiston laajenemista tasoa kohti. Tarkasteltaessa monitasoisia indeksejä
bfri:tä vastaa merkintä fo ( = fan-out ).
•
Oletetaan, että datatiedoston sisältämät r tietuetta on tallennettu b blokkiin levyblokin koon ollessa
B. Muodostetaan tiedostolle aluksi yksinkertainen pääindeksi siten, että indeksitiedoston tietueen
pituudeksi tulee Ri. Tällöin yhteen blokkiin mahtuu fo ( = bfri ) = B / Ri indeksitiedoston tietuetta.
Jokaista datatiedoston blokkia kohti tarvitaan yksi tietue pääindeksiin. Siten ensimmäisellä
indeksitasolla tarvitaan blokkeja b1 = b / fo kappaletta.
•
Haku indeksitiedostosta vaatisi nyt ajan log2b1, mutta jos b1 > fo, s.o. indeksitiedosto ei mahdu
kokonaisuudessaan yhteen blokkiin, voidaan hakua tehostaa rakentamalla uusi hakemistotaso 2,
jonka tietuepituus on sama kuin tasolla 1 eli Ri. Koska 1. hakemistotaso on järjestetty tiedosto kuten
datatiedostokin, voidaan siinäkin käyttää hyväksi blokkiankkureita. Täten riittää, että
hakemistotasolta 2 on olemassa linkit kaikkiin tason 1 käyttämiin blokkeihin.
•
Tasolla 2 tarvitaan nyt selvästikin b2 = b1 / fo tietuetta. Täten hakemistotason 2 tietueiden määrä
on b2 = b1 / fo = ( b / fo ) / fo kappaletta.
•
Esimerkki: Jos datatiedostossa on 3000 blokkia, blokkikoko on 1024 ja indeksitiedoston tietuepituus
on 15, mahtuu yhteen blokkiin 1024/15 = 68 pääindeksitiedoston tietuetta. Tällöin
yksinkertaisen pääindeksin rakentaminen vaatisi tilaa 3000/68 = 45 blokkia.
Jos haluttaisiin perustaa toinen hakemistotaso, siellä tarvittaisiin yksi tietue kutakin
1. hakemistotason blokkia varten. Koska myös 2. hakemistotason tietuepituus on 15,
mahtuisivat kaikki sen tietueet yhteen blokkiin, sillä ( 3000/68 ) / 68 = 45/68 = 1.
•
Hakemistotasojen maksimimäärää merkitään t:llä. Uusia hakemistotasoja voidaan perustaa niin
kauan, kunnes koko viimeksi perustettu hakemistotaso mahtuu yhteen blokkiin. Hakemiston tasojen
maksimimäärä t saadaan laskettua kaavasta t = ( logfor1 ), missä r1 edustaa hakemiston tasolla 1
olevien tietueiden lukumäärää.
•
Monitasoinen hakemisto voidaan perustaa samalla periaatteella myös ryvästys- tai toisioindeksille,
kunhan jokainen indeksitietue on kiinteän mittainen, eikä indeksikenttä sisällä duplikaatteja.
•
Esimerkki: 30000 opiskelijan tiedostolle voitaisiin rakentaa vaihtoehtoisen avainkentän mukaan
3-tasoinen toisioindeksi, sillä t = ( log6830000 ) = 3.
•
Moninkertainen indeksointi tarjoaa hyvin nopean haun, sillä blokkihakuja tarvitaan ainoastaan t + 1
kappaletta!
•
Jos ( monitasoinen ) pääindeksi on harva, joudutaan epäonnistuneen haun yhteydessä tutkimaan
datatiedoston blokki, jossa haettava tietue olisi voinut sijaita. Tiivistä indeksiä käytettäessä olisi haun
epäonnistuminen ollut todettavissa jo alimman tason ( tason 1 ) indeksitiedostossa.
•
Tarkastellaan kirjan esimerkkiä 14.6 ( esimerkki 2-tasoisesta pääindeksistä ).
•
Tarkastellaan kirjan algoritmia 14.1, joka suorittaa hakua t-tasoisesta pääindeksistä.
•
IBM:n ISAM-systeemissä ( Indexed Sequential Access Method ) on käytössä levyn rakennetta
myötäilevä 2-tasoinen sylinteri-indeksointi, jossa hakemisto perustuu ensisijaisesti sylinterin
numeroon levypakassa ja tämän jälkeen uraan yksittäisen sylinterin sisällä.
•
Myös monitasoisessa indeksoinnissa tietueiden lisääminen, päivittäminen ja tuhoaminen aiheuttavat
vaikeuksia, sillä kaikki indeksitiedostot ovat fyysisesti järjestettyjä tiedostoja.
•
Yksi ratkaisuvaihtoehto: dynaaminen monitasoinen indeksi, jossa jätetään blokkeihin jonkin verran
tyhjää tilaa uusien tietueiden tallentamiseksi. Tämä toteutetaan usein käyttämällä tietorakenteena
B- tai B+-puita.