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

Tietokannat
Aineopintokurssi, 4 ov, syksy 2002
Turun yliopisto / ohjelmistotekniikka / Salo
Lasse Bergroth
_____________________________________
Kurssi perustuu kirjaan Elmasri - Navathe: Fundamentals of Database Systems,
Addison-Wesley 2000, 3. painos sekä Antti Tuomiston aikaisempaan
luentomonisteeseen
Kurssin aikataulu
•
Luennot tiistaisin kello 09.00-10.45 ja perjantaisin kello 14.00-15.45,
yhteensä 44 tuntia
o 1. luento 2002-09-23, viimeinen 2002-12-13
o ei luentoa 2002-12-06
•
Demonstraatiot torstaisin kello 12.00-13.45, yhteensä 20 tuntia 200210-03 alkaen
o Viimeinen demonstraatiokerta torstaina 2002-12-05
•
Ensimmäinen tenttikerta maanantaina 2002-12-16 kello 9-13.
•
Seuraavat tenttikerrat vuoden 2003 tammitarkemmat päivämäärät ilmoitetaan myöhemmin.
ja
maaliskuussa,
Kurssin suoritustavat

Kurssi koostuu luennoista, demonstraatioista, harjoitustyöstä ja
tentistä.

Demonstraatiotehtäviä yhteensä 10∙5 = 50 tehtävää.
o 15 tehtyä tehtävää (30%) riittää kurssin tenttioikeuden
saavuttamiseen
o 25 tehtävällä (50%) ¼:n hyvitys tenttiarvosanaan
o 35 tehtävällä (70%) ½:n hyvitys tenttiarvosanaan
o 45 tehtävällä (90%) ¾:n hyvitys tenttiarvosanaan
•
Tehtävät jaetaan viimeistään käsittelykertaa edeltävän perjantain
luennolla.
•
Kysymykset löytyvät viikolta 40 lähtien myös verkosta osoitteesta
http://www.cs.utu.fi/bergroth/tietokannat.htm.
Kurssin suoritustavat (jatkoa)
•
Demovastaukset voidaan palauttaa kirjallisesti ainoastaan yhden kerran
ilman perusteltua syytä.
•
Harjoitustyöt jaetaan lokakuun loppupuolella. Tehtävänä on suunnitella
ja toteuttaa pienimuotoinen tietokanta.
•
Ensimmäiseen tenttikertaan ei tarvitse ilmoittautua, myöhempiin
osallistumisesta pitää ilmoittaa luennoitsijalle viimeistään viikkoa
etukäteen.
•
Tenttiin vastaamisaikaa käytettävissä 4 tuntia.
o 5 kysymystä, jotka kaikki arvostellaan 6 pisteen arvoisesti,
maksimipistemäärä 30
o hyväksyttyyn arvosanaan riittää 13 pistettä
o mahdollinen demonstraatiohyvitys lisätään ainoastaan hyväksyttyyn tenttiarvosanaan
Kurssin tavoitteet
•
Tietokanta-ajattelun sisäistäminen ja tiedonhallinnan periaatteiden ja
käsitteiden omaksuminen
•
Antaa valmiudet tietokantojen suunnittelua, toteuttamista ja käyttöä
varten
•
Korostaa laadun merkitystä tietokannan suunnittelussa (ER-mallinnus
ja normalisointi) ja toteutuksessa (säännöt ja niiden merkitys)
•
Antaa lyhyt katsaus tärkeimpiin tietokantojen tallennuksessa
käytettäviin tietorakenteisiin
•
Tarjota perustiedot jatko-opintoja varten (mm. syventävät kurssit,
kurssia sivuavat aihealueet ja alan tutkimuskohteet)
•
Kurssilla keskitytään lähinnä relaatiotietokantoihin
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 mielen-kiintoisia. Muutoin ei olisi mielekästä
edes perustaa kyseistä tietokantaa saatika 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 puhelinnumerotiedot. Toisessa ääripäässä ovat puolestaan valtion ja
suuryritysten ylläpitämät massiiviset tietovarastot (esimerkiksi
Yhdysvaltain kansalaisten verotiedot viimeisten viiden vuoden ajalta,
kts. kirjan 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 vaadi välttämättä
tuekseen
kaupallista
ohjelmistoa,
mutta
usein
tietokannan
määritteleminen, toteuttaminen ja käsittely vaativat suuremman
työpanoksen, jos TKHJ halutaan ohjelmoida kokonaan itse. Työmäärän
lisääntyminen
korostuu
erityisesti
muutettaessa
tietokannan
rakennetta uusien tiedon ylläpitotarpeiden mukaiseksi.
•
Tietokannan sovellusohjelmien, TKHJ:n, sekä levylle tallennetut dataja määrittelytiedot muodostavat yhdessä ns. tietokantajärjestelmän.
1.2. Esimerkki tietokannasta
•
Yliopiston opiskelijoiden opintotiedot
•
Viisi eri kokonaisuutta, jotka ovat omina tiedostoinaan
o Opiskelijan tiedot
o Kurssin yleistiedot
o Kurssin yksittäisen luentokerran tiedot
o Opintosuoritusraportti
o 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
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 tietokanta-sovelluksia. Edellytyksenä on
ainoastaan, että sekä tietokanta että sen määrittelyt ovat ohjelman
luettavissa.
tiedon
tietokannan
1.3.2. Ohjelmien ja datan eristäminen toisistaan; tietoabstraktio
•
Tietokantajärjestelmässä tietokannan rakenteen muuttuminen ei yleensä
johda suuriin muutos-toimenpiteisiin, sillä data ja määrittelyt sijaitsevat
toisistaan erillään ----> tiedon riippumattomuus ohjelmista
•
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 mainita vaikkapa
opintosuoritusten arvosanojen keskiarvon laskeminen.
opiskelijan
•
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 paitsi kokonaisuuksittain, niin myös
poistamalla yksittäisestä kokonaisuudesta tarpeettomia kenttiä (kts.
kirjan esimerkki 1.4.).
1.3.4. Tiedon jakaminen ja monen käyttäjän tapahtumien käsittely
•
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 paitsi kokonaisuuksittain, niin myös
poistamalla yksittäisestä kokonaisuudesta tarpeettomia kenttiä (kts.
kirjan esimerkki 1.4.)
•
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
suuksista ja/tai sisällöstä.
itse tietokannan ominai-
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 tietokannan hallinta-järjestelmän sekä sovellusohjelmien
toimivuudesta ja tehokkuudesta.
•
Huolehtii lisäksi käyttöoikeuksien
järjestelmän tietoturvasta.
•
Huolehtii lisäksi tarvittavien ohjelmistojen ja laitteistojen hankinnasta.
jakamisesta
henkilöstölle
sekä
•
Suurissa organisaatioissa voi tietokannan valvojalla olla tukenaan
avustavaa henkilökuntaa.
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
työtehtävissään tarvitsevat.
käyttäjät
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 paikanvaraus-sovellusten 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
analyytikon suunnittelemat sovellusohjelmat
tietojärjestelmä-
1.5. Tietokantojen taustavoimat
•
Toisin kuin varsinaiset toimijat, taustavoimat eivät suoranaisesti ole
kiinnostuneita itse tietokannasta.
•
Tietokannan hallintajärjestelmän systeeminsuunnittelijat suunnit-televat 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
tietokannan suunnittelua ja käyttöä voidaan helpottaa.
•
Operaattorit huolehtivat yrityksen ATK-laitteiston yleisestä toimi-vuudesta.
välineitä,
joilla
1.6. Tietokannan hallintajärjestelmän 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 pääsyä tiettyihin TKHJ:n
moduuleihin, kuten perustamaan uusia käyttäjätunnuksia.
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ä ei saa 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
sovellusohjelmien uusiminen uusia sääntöjä vastaaviksi.
•
kuin
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 määrääminen tietokentille:
arvojen tallentaminen tietokantaan estetään.
laittomien
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
 Esimerkin yliopistotietokannan tapauksessa voitaisiin
vaatia, että luentoja voi järjestään ainoastaan sellaisesta
kurssista, jonka perustiedot on jo tallennettu ----> ei
perusteta sellaisia luentotietueita, joiden kurssi on
tuntematon
 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 eheyssää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
1.7. Tietokantalähestymistavan seurauksia
•
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ä talletusrakennetta 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
tiedostojä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ä.
•
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.8. Milloin TKHJ:tä ei kannata käyttää?
•
Saattaa olla perusteltua
järjestelmää, mikäli
olla
käyttämättä
tietokannanhallinta-
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
ja
kunnolliseen
panostettavien voimavarojen riittämättömyys.
toteutukseen
o Tietokanta ja sen sovellukset ovat yksinkertaisia, ja tietokannan
sisältämä tieto on luonteeltaan stabiilia (ei juuri muutoksia
kannan määrittelyihin).
o Vaaditaan tiukkaa pitäytymistä reaaliaikaisuudessa (haluttaessa
karsia pois kaikki hidastuttavat elementit).
o Haluttaessa perustaa vain yhden käyttäjän järjestelmä.
2. Tietokannan käsitteitä ja arkkitehtuuri
•
Aikaisemmin tietokannan
integroituja järjestelmiä.
hallintajärjestelmät
olivat
suuria,
tiiviisti
•
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. objektirelaatiomallissa, 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
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. objektirelaatiomallissa, joka on relaatio- ja oliotietomallin välimuoto.
o Sisältää usein myös perusoperaatiot tiedon hakua ja päivittämistä varten.
•
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 yksityiskohdista, 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 ).
•
Tällä kurssilla käsiteltävän relaatiotietomallin ja yleistymässä olevan
oliokeskeisen tietokantamallin lisäksi toteutusmalleihin luetaan
aikaisemmat verkko- ja hierarkkinen malli, jotka tällä kurssilla
sivuutetaan.
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 suunnittelu-vaiheessa,
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 ulko-puolelleen 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.
•
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äännet-tä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
•
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.
•
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
 lähinnä tietokannan selailua varten
o Lomakepohjaiset
 kyselyjen muodostamiseen
 tiedon syöttöön
o Graafiset
 voidaan käyttää hyödyksi hiirtä
o 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 palvelin (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
•
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 palvelimen kautta
•
Kyselyiden kääntäjä
o jäsentää käyttäjän tuottaman kyselyn ja muuntaa sen 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 lukeminen tekstitiedostosta tai konversio joltakin muulta
tiedostotyypiltä TKHJ:n ymmärtämään muotoon
•
Turvakopiointi
o tarkoittaa yleensä koko tietokannan tallentamista nauhalle
•
Tiedon lataaminen tietokantaan
o lukeminen tekstitiedostosta tai konversio joltakin muulta
tiedostotyypiltä TKHJ:n ymmärtämään muotoon
•
Turvakopiointi
o tarkoittaa yleensä koko tietokannan tallentamista nauhalle
•
Tiedostojen uudelleenorganisointi
o tehokkuuden lisäämiseksi
•
Suorituskyvyn seuranta
o tilastotietoa tietokannan valvojan käyttöön
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
o sisältää tietoja mm. tietokannan suunnittelua koskevista
päätöksistä, käyttöstandardeista, sovellusohjelmien kuvauksen ja
tietoa käyttäjistä
o 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
•
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 tietoliikenne-systeemistä käytetään
lyhennettä DB/DC (Database / Data communications)
2.5. Tietokantajä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 hallinta-järjestelmä
homogeeninen vai heterogeeninen?
 käytetäänkö samaa vai eri TKHJ-ohjelmistoja 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 jokainen hierarkiataso kuvaa toisiinsa liittyviä tietueita
o ei standardoitua kyselykieltä
o käsitellään yleensä tietue kerrallaan
3. Datan mallintaminen ER-mallin avulla
•
ER (Entity Relationship) tarkoittaa kokonaisuuksien välisiä suhteita.
•
Käsitteellinen mallinnus on tärkeää tietokantasovellusten
suunnittelussa
•
Tietokannan käyttöönottovaihetta edeltävät aina suunnittelu, toteutus
ja sovellusohjelmien testaus
•
Tietokannan suunnitteluvaihe muistuttaa jonkin verran yleistä
ohjelmien suunnittelua.
•
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ä
•
Vaiheet tietokannan suunnittelussa nähtävissä seuraavan sivun
kaaviossa.
Eteneminen alkutekijöistä kohti valmista tietokantaa
•
Tarpeiden kartoittaminen ja analysointi
o selvitetään käyttäjiltä kysymällä, mitä kaikkia tietoja tietokannassa
tulisi olla saatavilla
o tarpeelliset tiedot ja toiminnot pitäisi selvittää niin tarkoin kuin
mahdollista
o käytetään apuna tietovuokaavioita yms. suunnittelua helpottavia
menetelmiä
 tavoitteena muodostaa kokonaiskäsitys tiedon ja toimintojen
tarpeesta tietokannassa
•
Muodostetaan tietokannan käsitekaava käyttämällä korkean tason
tietomallia
– 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 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
tallennus-rakenteen 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
suhteiden avulla.
•
Entiteetti on jokin reaalimaailmassa esiintyvä itsenäinen käsite, joka voi
olla joko fyysinen tai käsitteellinen.
o esimerkiksi henkilö, auto, työntekijä jne. ovat fyysisiä entiteettejä
o vastaavasti yliopiston kurssi, luennointikerta jne. ovat käsitteellisiä
entiteettejä
o 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ä.
•
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 tiedetä,
onko arvo olemassa)
 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äisten edustajien joukkoa
•
Entiteettityppiä 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.
yliopisto-tietokannan 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- ja 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 liitty 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 yksittäisten laillisten arvojen joukko
o
moniarvoista attribuuttia kaikki yhdistelmät, joita esiintyy
entiteettijoukossa
o
yhdistettyä attribuuttia 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ä koottuina 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 haluavat mieluummin
ensimmäisen vaihtoehdon.
3.4. Suhteet ja niiden tyypit, roolit ja rakenteelliset
rajoitukset
• Tällä kurssilla 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. Suhteiden tyypit, joukot ja esiintymät
• Tällä kurssilla suhde  relaatio.
• Relaatioon osallistuu vähintään kaksi entiteettityyppiä. Kahden
entiteettityypin välinen 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 entiteettien 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
projektissa
--> työntekijäentiteettiä edustava esiintymä liitetään projektia 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 suhteeseen (esimerkiksi relaatio työntekijän työskenteleminen
projektissa).
o Roolinimet ovat melko selkeät, mikäli sama entiteettityyppi ei osallistu
siihen useita kertoja.
o 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. kardinaliteettisuhde
ja osallistumiskriteeri.
•
Binäärin relaation kardinaliteettisuhde määrää, monenko esiintymän
kanssa entiteetti voi osallistua relaation. Esimerkki: osasto-työntekijä
relaation kardinaliteettisuhde 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 kardinaliteettisuhteet ovat 1:1, N:1 ja M:N.
•
Esimerkki 1:1 -kardinaliteettisuhteesta: osaston johtaminen. Jokaisella
osastolla voi olla vain yksi johtaja, ja jokainen henkilö voi johtaa vain yhtä
osastoa.
•
Esimerkki M:N -kardinaliteettisuhteesta: 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. Suhdetyypin attribuutit
•
Paitsi entiteettityypeille, myös suhteille voidaan määritellä attribuutteja.
•
Toisinaan attribuutti liittyy luonnollisemmin kahden (tai useamman)
entiteettityypin väliseen suhteeseen kuin jompaan kumpaan (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ä riippuvuutta kuin
itse työntekijää tai projektia sinänsä).
Mikäli relaation kardinaliteettisuhde 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 kardinaliteettisuhde 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 kardinaliteettisuhde 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 avain-attribuutti, 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ä
heikon entiteetin 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 entiteetti-tyyppiä 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ä
kardinaliteettisuhteiden 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, kardinaliteettisuhteeksi
1:N osaston ja työntekijän välille
o Projektin kontrolloiminen osaston ja projektin väliseksi suhteeksi.
Kardinaliteettisuhteeksi 1:N osaston ja projektin välille. Projektin
osallistumisen pitää olla täydellinen (kysytty käyttäjiltä).
o Työntekijä - Esimies -suhde: kardinaliteettisuhde 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 identioiva 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 minimoiminen 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
kardinaliteettisuhteele 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ä.
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).
•
Tietokannan funktionaalisia vaatimuksia voidaan kuvata myös OMT(Object Modeling Technique) ja UML-kuvauskielen (Universal Modeling
Language) avulla.
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öntekijä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 automaat-tisesti jonkin attribuutin arvon
perusteella. Tällä tavoin määritellystä aliluokasta käytetään nimitystä
käyttäjän määrittelemä aliluokka (user-defined subclass).
•
Erikoistumiseen 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 erikoistumista 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.
•
Erikoistuminen voi osallistumisen tapaan olla osittaista tai täydellistä.
•
Mikäli tietyn luokan esiintymän on kuuluttava ainakin johonkin sen
aliluokista, on kyseessä täydellinen erikoistuminen (esimerkiksi työntekijän
palkkaustyyppi).
•
Jos puolestaan aliluokkaan kuuluminen ei ole välttämätöntä, on kyseessä
osittainen erikoistuminen. 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 luokkaaliluokkarakenteita:
– Jos yliluokan tietue poistetaan, kyseinen tietue tuhotaan automaattisesti
myös kaikista niistä aliluokista, joissa se on edustettuna.
– 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ää.
– 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:
•
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 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
esimerkki 4.9. (a): kaikki yhtiöt ja yksityishenkilöt eivät välttämättä ole
tilinomistajia).
4.5. Esimerkki yliopiston tietokannasta EERmallinnuksella ja mallin käsitteiden formaaleja
määritelmiä
•
Käsitellään kirjan esimerkin 4.10. 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. Käsitteellinen objektimallinnus UML:n
luokkadiagrammien avulla
•
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.
•
Kardinaliteettisuhdetta 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.15. 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.
•
Luokka-aliluokkasuhteita kuvattaessa valkoinen kolmio kuvaa erillistä
erikoistamista ja musta kolmio päällekkäistä (tarkastellaan lopuksi
aiheeseen liittyvää kirjan esimerkkiä 4.12.).
4.7. Astelukua 2 korkeamman asteen suhdetyypit
•
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äärisen relaation 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
1
1
2
2
3
OSA
kuulalaakeri
pultti
hammaspyörä
kuulalaakeri
venttiili
toimittaa_projektille(t, p):
TOIMITTAJA
1
1
2
3
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(1, kuulalaakeri),
toimittaa_projektille(1, säiliöalus) ja lisäksi
osien_käyttö(kuulalaakeri,säiliöalus), mutta sen sijaan ei välttämättä
pidä paikkaansa, että toimittaja 1 huolehtisi kuulalaakerien
toimittamisesta säiliöaluksiin, sillä yhtäläisesti sen voisi tehdä myös
toimittaja 2.
•
Kaikki tietokantojen suunnitteluvälineet eivät salli ternääristen tai sitä
korkeamman asteisten relaatioiden esittämistä, vaan on turvauduttava
heikon entiteetti-tyypin 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.14., 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: 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 kardinaliteettisuhteeltaan 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ää
kardinaliteettisuhde ja osallistumisrajoite.
•
Mikäli ternäärisen relaation kardinaliteettisuhde 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) kardinaliteettisuhde 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.
2.
Aggregaation esittäminen normaalina relaationa.
3.
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 4.16.):
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, että kyseisistä
henkilöistä ainakaan molemmat eivät enää olisi 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.
5. Tietueiden tallentaminen ja
primääritiedoston organisointitavat
•
Tässä luvussa keskitytään tietokannan fyysiseen rakenteen
ymmärtämiseen siinä määrin, kuin se on myöhemmin kurssin aikana
tarpeen.
•
Osa kirjan vastaavan luvun sisällöstä sivuutetaan.
5.1. Johdanto
•
Tietokanta on tallennettava johonkin tietokoneen muisteista, jotta TKHJ
pystyisi tarpeen mukaisesti hakemaan, päivittämään ja prosessoimaan sen
sisältämiä tietoja.
•
Primäärisellä tallennuspaikalla (primary storage) tarkoitetaan tietokoneen
keskus- tai välimuistia, josta tiedot ovat nopeasti saatavissa, mutta jonka
koko on melko rajoitettu. Näissä muistipaikoissa oleva tieto on suoraan
keskusyksikön käytettävissä.
•
Toissijaisella tallennuspaikalla tarkoitetaan massamuistilaitteita
(kiintolevyt, optiset levyt ja magneettinauhat). Nämä ovat hinnaltaan
keskusmuistia huomattavasti halvempia, mutta samalla niiden
käyttäminen on hitaampaa kuin keskus- ja välimuistin.
Massamuistilaitteille tallennettua dataa ei keskusyksikkö pysty
käsittelemään ilman kopioimista primääriseen tallennuspaikkaan.
5.1.1. Muistihierarkiat ja tallennuslaitteet
•
Primääristen tallennuspaikkojen lajeja:
o Välimuisti (Cache) eli staattinen RAM (Random Access Memory) on eri
muistilajeista kallein ja toimivuudeltaan kaikkein nopein.
Keskusyksikkö tarvitsee sitä ohjelmien suorituksen nopeuttamista
varten.
o Varsinainen keskusmuisti, eli dynaaminen RAM (DRAM), on
keskusyksikön pääasiallinen työmuisti, jossa säilytetään sekä ohjelmia
että dataa.
 Varsinainen keskusmuisti on hinnaltaan välimuistia selkeästi
halvempaa, mutta se on toiminnallisesti hitaampaa kuin välimuisti.
 Lisäksi DRAMin huonona puolena välimuistiin nähden on sen
volatiliteetti, eli tietojen häviäminen tietokoneesta esimerkiksi
sähkövirran katketessa.
 Koska varsinaisen keskusmuistin hinta on jatkuvasti halventunut,
on nykyisin toiminnassa monia ns. keskusmuistitietokantoja, jotka
ladataan kokonaisuudessaan keskusmuistiin. Mahtuminen kerralla
keskusmuistiin on merkittävä etu ns. reaaliaikaisissa
tietokantasovelluksissa, joissa vasteaikojen tulee olla lyhyitä.
o Keskusmuistin ja massamuistilaitteisiin kuuluvan kiintolevymuistin
välillä on ns. pikamuisti (flash memory), jonka etuna on tietojen
pysyvyys mm. sähköhäiriötilanteissa. Pikamuistit käyttävät ns.
EEPROM-teknologiaa (Electrically Erasable Programmable Read-Only
Memory), ja niiden tiedonhakuaika on lyhyt. Haittana on kuitenkin
kirjoitusoperaatioiden hitaus, sillä koko muistiblokki pitää kirjoittaa
kerralla uudelleen, vaikka muutostarve olisi hyvin vähäinen.
•
Toissijaiset tiedon talletuspaikat:
o CD-ROM -muistit tallentavat dataa optisesti, ja niitä luetaan laserilla.
Tietojen muuttaminen ei näissä ole mahdollista. CD-ROM -muistit
kestävät magneettisia kiintolevyjä paremmin.
o DVD - uusi standardi optisille levyille.
o Optisten levyjen kokoelmat (Optical juke box memories) ovat toisiinsa
liittyviä CD-ROM -levyjä. Ne eivät ole yleistyneet odotetulla tavalla,
koska ne ovat magneettisia levyjä hitaampia, ja magneettisten levyjen
hinta on laskenut voimakkaasti.
o Magneettinen levy on tyypillisin tietokoneen massamuistiväline. Laajat
tietokannat tallentuvat käytön aikana pieneltä osalta keskusmuistiin,
suurimmalta osaltaan magneettilevyille.
o Magneettinauhaa käytetään lähinnä hyvin suurten tietokantojen
turvakopiointiin. Niiden etuna on erittäin suuri kapasiteetti ja halpa
hinta. Suurena miinuksena ovat puolestaan hyvin hidas haku ja
tallentaminen.
o Nykyisin magneettinauhaa pidetäänkin syystä tertiäärisenä
muistivälineenä; sitä käytetään vain tietokantojen varmistusta varten
mahdollisten vakavien häiriötilanteiden varalta.
5.1.2. Tietokantojen tallentaminen
•
Tietokannan on säilyttävä käyttökelpoisena jokaisen suorituskerran
päätyttyä - toisin kuin monet sovellusohjelmat, joiden muuttujien tiedot
menetetään suorituksen päättyessä.
•
Yleisesti ottaen tietokannat ovat liian suuria, jotta niitä voisi säilyttää
kokonaisuudessaan keskusmuistissa suorituksen aikana.
•
Tietojen häviämistä tapahtuu useammin keskus- kuin massamuistissa.
•
Tiedon tallennuskustannus tietoyksikköä kohti on kertalukua suurempi
primäärisillä tallennuspaikoilla massamuistiin verrattuna.
•
Magneettinauhalla oleva tieto ei ole hitaan hakuajan tähden käytettävissä
milloin tahansa (off-line) - toisin kuin levylle tallennettu (on-line).
•
Tietokannan sisältämä tieto tallennetaan tietuista koostuvina tiedostoina.
•
Yksittäinen tietue esittää jonkin entiteettityypin tai relaation esiintymää
kuvaavia tietoja.
•
Primääritiedoston tallennusorganisaatioita (eli millä tavoin sen tietueet on
tallennettu) on useita:
– peräkkäistiedosto (heap file): tietueilla tallennusjärjestys, ei lajittelua
minkään tietyn kriteerin mukaisesti
– lajiteltu tiedosto (sorted file): tietueet järjestetty jonkin tietyn kentän
mukaan, josta käytetään nimitystä lajitteluavain.
– hajautustiedosto (hashed file): tietueen sijaintipaikka levyllä määräytyy
ns. hajautusfunktion arvoon tietylle kentälle, josta käytetään nimitystä
hajautusavain (hash key).
– puurakenteet (esimerkiksi B-puu)
5.2. Toissijaiset tallennuspaikat
5.2.1 Magneettisten levyjen fyysisistä ominaisuuksista
•
Levyn pienin tietoyksikkö on bitti. Levyalueen erilaisen magnetoinnin
avulla voidaan esittää yksittäiseen bittiin tallennettua nollaa tai ykköstä.
•
Tavu voi koostua esimerkiksi neljästä tai kahdeksasta bitistä tietokoneen
toteutuksen mukaan.
•
Levyn tallennuskapasiteetti ilmoitetaan tavuina (nykyisten levyjen
kapasiteetti mitataan usein gigatavuissa).
•
Levy on 1-puoleinen, jos ainoastaan sen toista pintaa käytetään tiedon
tallentamiseen, muutoin se on
2-puoleinen.
•
Levypakka (disk pack) koostuu useista päällekkäisistä levyistä.
•
Levyn pinta koostuu urista (track), joiden kunkin halkaisija on erisuuri.
•
Levypakassa kaikki keskenään samanlevyiset urat muodostavat ns.
sylinterin. Yhden sylinterin sisältä tiedon hakeminen on verrattain nopeaa
verrattuna usealta eri sylinteriltä hakemiseen.
•
Yksittäinen ura jakautuu edelleen sektoreihin tai blokkeihin.
•
Blokkikoko on järjestelmäkohtainen, eikä sitä pysty muuttamaan. Blokit
erottuvat toisistaan tietyn mittaisin välein.
•
Yksittäisen blokin osoitteen määrää levyllä pinnan, uran ja blokin
numeroiden yhdistelmä.
•
Keskusmuistin puskuriin voidaan tallentaa yhden levyblokin sisältö.
•
Levy on hajasaantinen tietoväline (random access device).
•
Luettaessa tietoja levyltä lukeminen tapahtuu blokki kerrallaan
keskusmuistin puskuriin.
•
Kirjoitettaessa levylle tallennetaan keskusmuistin puskurin sisältö
levyblokkiin.
•
Toisinaan myös usean perättäisen blokin yhdistelmä, ns. klusteri (cluster),
voidaan siirtää kokonaisena yhdellä kerralla puskuriin. Tällöin puskurin
koko säädetään vastaamaan tavujen määrää klusterissa.
•
Levyn luku- ja kirjoitusoperaatioista huolehtii levyaseman luku- /
kirjoituspää, joita on yksi kappale kunkin levyn käytettävää pintaa (1 tai 2)
kohti.
•
Luku- ja kirjoituspäät ovat mekaanisen varren kautta yhteydessä
kytkinvarteen (actuator), joka siirtää mekaanista vartta levyn yhden uran
kohdalta toiselle.
•
On olemassa myös ns. kiinteitä luku- / kirjoituspäitä, jotka käsittelevät
vain yhtä tiettyä uraa levypinnalta. Näin saadaan aikaan nopea haku,
mutta toteutus on verraten kallis.
•
Levy pyörii akselinsa ympäri vakionopeudella (yleensä väliltä 3600-7200
kierrosta minuutissa). Levykeasemien levyt pyörivät vain silloin, kun niihin
kohdistetaan luku- tai kirjoitustoimintoja.
•
Levyn kontrolloija (disk controller) huolehtii keskusyksikön ja levyn välisten
toimintojen ohjauksesta.
•
Levyoperaatioiden suoritusaikojen jaottelu:
o
hakuaika: kuluu luku-/kirjoituspään siirtämisestä
sen uran kohdalle, josta luku / johon
kirjoitus tapahtuu (seek time).
o
pyörähdysviive: aika, jonka kuluessa oikea levyn
blokki siirtyy luku-/kirjoituspään
kohdalle (rotation delay / latency).
o
blokinsiirtoaika: aika, joka kuluu datan siirtämisestä
blokista / blokkiin (block transfer
time). Levyoperaation kokonaiskustannus = hakuaika
+ pyörähdysviive + blokinsiirtoaika.
•
Kahden ensiksi mainitun osuus yhteensä on huomattavan suuri
blokinsiirtoaikaan verrattuna.
•
Kokonaiskustannukset alenevat melkoisesti, mikäli voidaan siirtää useita
perättäisiä blokkeja, sillä silloin hakuajan ja pyörähdysviiveen osuus
veloitetaan vain ensimmäistä blokkia haettaessa.
•
Useissa tietokantasovelluksissa juuri datan paikallistaminen levyltä on
toiminnan nopeuden kannalta vaikein pullonkaula.
5.2.2. Magneettinauhat
•
Toisin kuin levyt, magneettinauhat eivät ole hajasaantia tukevia
tietovälineitä: magneettinauhat noudattavat peräkkäissaantia (sequential
access).
•
Magneettinauhojen käyttöä varten tarvitaan erillinen nauha-asema, jossa
on luku-/kirjoituspää.
•
Datan tallennus tapahtuu nauhoillakin blokki kerrallaan, mutta blokkikoot
ovat melkoisesti isommat kuin levyillä, samoin blokkien erottimet --->
tallenneustilaa menee hukkaan.
•
Etsittävän tiedon löytämiseksi pitää nauhaa rullata eteenpäin
järjestyksessä, kunnes haluttu kohta löytyy tai koko nauha on kelattu
loppuun (tietoa ei löytynyt).
•
Tiedon lukemis- ja kirjoittamisoperaatiot ovat hyvin hitaita, joten
magneettinauhoja ei juuri voida käyttää kuin tietojen turvakopiointiin,
johon ne sopivatkin varsin hyvin suuren kapasiteettinsa ja halvan hintansa
tähden.
5.3. Levysaannin rinnakkaistaminen RAIDteknologian avulla (käsitellään lyhyesti)
•
RAID (Redundant Arrays of Independent (Inexpensive) Disks) tarkoittaa
usean pienen levyn linkittämistä yhdeksi nopeaksi loogiseksi levyksi.
•
Levyoperaatioiden hitaus suhteessa keskusmuistin toimintaan antaa
aihetta yrittää tehostaa levyyn kohdistuvia operaatioita.
•
Mahdollisuus jakaa tiedoston sisältämät tiedot tasaisesti eri fyysisten
levyjen kesken, jotta voitaisiin suorittaa rinnakkaista lukua ja
kirjoittamista.
•
RAIDin käyttö tiedon säilyvyyden varmistamiseksi: kaksinkertainen
tallentaminen.
•
Esimerkki: Oletetaan, että koneessa on 100 levyä, ja yksi levy kestää
likimain 200000 tuntia, kunnes se rikkoutuu.
---> Tällöin pelkästään yhtä levyä käytettäessä pärjättäisiin keskimäärin
yli 22 vuotta, mutta sadasta levystä jokin rikkoutuisi odotusarvon
mukaisesti jo 2000 tunnin kuluttua, eli järjestelmä toimisi vain noin
83 tuntia ilman häiriötä!
---> Mikäli kaikki tiedot olisi monistettu kahdelle eri levylle, tietojen
häviämisriski pienenisi oleellisesti. Hakuaika tosin lisääntyisi, mutta
blokinsiirtoaika pysyisi ennallaan.
---> Jos rohkenemme olettaa, että yksittäinen rikkoutunut levy pystytään
vaihtamaan 24 tunnin sisällä, tällöin levyvirhe aiheuttaisi tietojen
menettämisen yhden kerran ajanjaksossa
(200000)2/(2*24) tuntia = 8.33 * 108 tuntia. Tietojen menettäminen
tapahtuisi tarkalleen silloin, kun samat tiedot sisältävä levypari
rikkoutuu siten, ettei ensimmäisen rikkoutuneen tilalle ole vielä
ehditty vaihtaa toimivaa levyä ja kopioida vastinlevyn tietoja sille,
kun myös vastinlevy rikkoutuu!
5.4. Blokkien puskurointi
•
Mikäli on vain yksi prosessori käytettävissä, kaksi keskusmuistissa
olevaa prosessia eivät pysty toimimaan rinnakkaisesti, vaan ainoastaan
vuorotellen.
•
Tietokoneissa usein kuitenkin levyä varten on oma prosessori, joka voi
toimia samalla kun keskusyksikönkin prosessori.
•
Tietokannan prosessointia voidaan nopeuttaa varaamalla muistista
useampi puskuri kerrallaan.
•
Mikäli yhden puskurin käsittely vie vähemmän aikaa kuin uuden
hakeminen, on kannattavaa käyttää kahta keskusmuistipuskuria
kerrallaan.
•
Tällöin voidaan samalla kirjoittaa levylle toisen puskurin sisältöä tai
vastaavasti lukea siihen tietoja levyltä. Tästä käytetään nimitystä
kaksinkertainen puskurointi.
•
Tällöin on mahdollista peräkkäisten blokkien siirtelyt levyn ja
keskusmuistin välillä ilman hakuaika- ja pyörähdysviivekustannusta
levyllä.
5.5. Tiedostojen tallentaminen levylle
•
Tiedot tallennetaan yleensä tietueittain.
•
Jokainen tietue sisältää kokoelman yhteen liittyviä tietoja, joista
käytetään nimitystä tietokenttä (field).
•
Tietokenttä vastaa fyysisellä tasolla attribuutin käsitettä.
•
Tietokentällä on tyyppi, joka ilmaisee, miten kentän sisältämä tieto pitää
tulkita. Yleisimmin käytettävät tyypit ovat numeerinen (kokonaisluvut,
pitkät kokonaisluvut ja reaaliluvut), merkkijonot (kiinteän mittaiset tai
vaihtelevan pituiset), looginen (tosi / epätosi) sekä päivämäärää ja aikaa
esittävät tyypit.
•
Eri tyyppien vaatimat muistitilat:
–
–
–
–
–
kokonais- ja reaaliluvut: 4 tavua
looginen tieto: 1 tavu
merkkijonot: 1 tavu merkkijonon kutakin merkkiä kohti
päivämäärä: 10 tavua esityksellä VVVV-KK-PP
aika: 8 tavua esityksellä TT:MM:SS
•
Esimerkki yrityksen tietokannan henkilötietueen rakenteesta C-kielellä:
struct employee {
char name[30];
char ssn[9];
int salary;
int jobcode;
char department[20];
}
Muun muassa multimediatietokannoissa tietueissa voi esiintyä
suurikokoisia tietokenttiä (esim. kuvia), joita ei tallenneta suoraan
muiden tietokenttien sekaan, vaan ne tallennetaan toisaalle ja niihin
viitataan ns.linkkikentän avulla. Tällaisista objekteista käytetään
lyhennettä BLOB (Binary Large Object).
•
5.5.2. Tiedostot sekä kiinteän ja vaihtelevan mittaiset tietueet
•
Tietue voi olla kiinteän mittainen, jolloin kussakin tietueessa tietty kenttä
alkaa samasta positiosta.
•
•
Myös vaihtelevan mittainen rakenne on mahdollista seuraavissa
tapauksissa:
1.
Jokin merkkijonokentistä on vaihtelevan mittainen: esimerkiksi
merkkijonokentästä täytetään vain kulloinkin tarpeellinen määrä.
2.
Tietueeseen kuuluu moniarvoinen tietokenttä, jolloin samaan
kenttään tallentuu mahdollisesti useita arvoja.
3.
Tietue voi sisältää puuttuvia arvoja, eli kaikkiin sen kenttiin ei
tallenneta tietoa.
4.
Tiedosto sisältää eri entiteettityypin edustajia. Voi olla esimerkiksi
tarpeen liittää opiskelijan perustietojen perään tietueet saman
opiskelijan opintosuorituksista, jos on odotettavissa, että niitä
tarvitaan usein perustietojen haun yhteydessä.
Käytettäessä kiinteän mittaisia tietueita on ohjelmien helpompaa
käsitellä tiedostoa, kun jokaisen kentän alkamispositio on aina sama.
Myöskään kenttien ja tietueiden erottimista ei tarvitse tällöin murehtia.
•
Haittapuolena kiinteän mittaisten tietueiden käyttämisessä on kuitenkin
muistitilan hukkaaminen, sillä kiinteän mittaisten tietueiden
suunnittelussa on varauduttava aina pahimpaan, eli hahmotettava
merkkijonokenttien absoluuttinen maksimipituus, sekä moniarvoisten
attribuuttien arvojen maksimimäärä tietuetta kohti.
•
Vaihtelevan mittaisilla tietueilla tarvitaan kolmea eri tyyppiä
erotinmerkkejä (kirjan esimerkki 5.7.):
1.
Ilmoittamaan, milloin vaihtelevan mittainen merkkijonokenttä
päättyy. Erotinmerkin pitää olla jokin merkkijonokentässä
esiintymätön
erikoismerkki (?, %, $ tms.).
2.
Moniarvoisen attribuutin eri arvojen erottimet kentän sisällä.
3.
Koko tietueen päättymistä ilmaiseva erotinsymboli.
•
Jos tietueesta on jätetty tallentamatta osa kentistä, voidaan kunkin
kentän alkuun sijoittaa joko kentän nimi tai sen sijaintia kuvaava
koodinumero (field type code), jotta tiedettäisiin, mitä tietokenttää kukin
tallennettu arvo tietueessa edustaa.
•
Jos useaa eri tyyppiä olevia tietueista sallitaan talletettavan samaan
tiedostoon, pitää tietuetta edeltää lisäksi tietueen tyyppikoodi.
5.5.3. Tietueiden esittäminen levymuistissa
•
Tiedonsiirron yksikkönä levyn ja keskusmuistin välillä toimii ns. blokki.
•
Tietueen koko ratkaisee, montako tietuetta pystytään tallentamaan yhteen
blokkiin.
•
Yhteen blokkiin, jonka koko on B, voidaan sijoittaa pituudeltaan R olevia
tietueita bfr kappaletta kaavan bfr = B / R mukaisesti. Merkintä x
tarkoittaa ns. lattiafunktiota eli suurinta kokonaislukua, joka on
korkeintaan yhtäsuuri kuin x. Termistä bfr käytetään nimitystä
blokkikerroin (blocking factor).
•
Mikäli jakolasku B / R ei mene tasan, blokkiin jää ns. hukkatilaa, johon ei
enää mahdu kokonaista tietuetta. Hukkatilan kokonaismäärä on
B - ( bfr * R ).
•
Jos tietueen ei sallita jakautuvan useamman kuin yhden blokin alueelle,
kyseessä on ns. virittämätön tietueiden (unspanned) organisointi.
•
Muutoin on kyseessä viritetty (spanned) organisointi. Viritettyä
organisointia on käytettävä, mikäli B < R, koska tällöin tietue ei mahdu
pelkästään yhteen blokkiin.
•
Vaihtelevan mittaisilla tietueilla merkintä bfr tarkoittaa keskimääräistä
tietueiden määrää blokkia kohti, kun
B  R.
•
Vastaavasti, kun B  R, r:n tietueen tallentamista varten tarvittavien
muistiblokkien määrä b = r / bfr. Merkintä x tarkoittaa ns. kattofunktiota eli pienintä kokonaislukua, joka on vähintään yhtäsuuri kuin x.
•
Tietueiden eri organisointitavoista käsitellään kirjan esimerkki 5.8.
5.5.4. Tiedostoblokkien varaaminen levyltä
•
Jatkuva allokointi: varataan perättäisiä blokkeja. Tällöin voidaan hyödyntää
kaksinkertaista puskurointia, jolloin tiedonsiirto levyn ja keskusmuistin
puskurien välillä on nopeaa, mutta tiedoston koon laajentaminen voi
aiheuttaa harmia.
•
Linkitetty allokointi: varatut blokit eivät ole välttämättä perättäisiä, vaan
blokit on linkitetty toisiinsa. Tällöin tiedoston koon kasvattaminen on
yksinkertaista, mutta koko tiedoston läpikäyminen hidastuu.
•
Klusterointi: edellisten varaamistapojen yhdistelmä. Varataan useita
perättäisiä blokkeja, jotka linkitetään toisiinsa. Klusterista käytetään myös
nimitystä tiedostosegmentti.
•
Allokointi indeksoinnin avulla: perustetaan indeksiblokkeja, joissa
osoittimet varsinaisiin blokkeihin, jonne tietueet on tallennettu.
5.5. Tiedoston otsikko
•
Tiedoston otsikko (file header) sisältää systeemin tarvitsemaa tietoa
tiedoston rakenteesta.
•
Sisältää tallennusblokkien levyosoitteet.
•
Sisältää kenttien järjestyksen ja pituudet, jos kyseessä on kiinteän
mittaisia tietueita sisältävä tiedosto, ja vastaavasti tietueen ja kenttien
tyyppikoodit sekä erotinmerkit, jos tiedostossa voi esiintyä vaihtelevan
mittaisia tietueita.
•
Yksittäisen tietueen hakemiseksi tiedostosta on turvauduttava ns.
lineaarihakuun, ellei tietueen sijainnista tiedostossa tiedetä mitään. Tällöin
tiedostoa selataan läpi tietue kerrallaan, kunnes se joko löytyy tai tiedosto
loppuu. Hakukustannus on keskimäärin b/2, jos etsittävä tietue on
tiedostossa ja b, jos tietuetta ei löydy.
5.6. Tiedosto-operaatiot
•
Tiedosto-operaatiot voidaan karkeasti jaotella haku- ja
päivitysoperaatioihin.
•
Hakuoperaatio ei muuta tiedoston sisältöä, kun taas päivitysoperaatiossa
joko poistetaan tietue, muutetaan tietueen aikaisempaa sisältöä tai lisätään
uusi tietue.
•
Riippumatta siitä, onko kyseessä haku- vai päivitysoperaatio, tarvitaan jokin
hakuehto tietueen löytämiseksi. Se voi olla yksinkertaisimmillaan kentän
arvon vertailu johonkin vakioon, mutta se voi olla myös usean ehdon
yhdistelmä, ja vertailu voi perustua myös erisuuruuteen.
•
Kompleksinen hakuehto voidaan suorittaa useassa eri vaiheessa.
•
Esimerkki: Halutaan löytää työntekijät, jotka ovat töissä tutkimusosastolla
ja joiden palkka on yli 30000 €.
Vaihe 1: Etsitään aluksi pelkän osaston perusteella, jolloin
löydetään kaikki tutkimuspuolen työntekijät.
Vaihe 2: Etsitään vaiheessa 1 löydetyistä ne, joiden palkka
ylittää 30000 €.
•
Mikäli useampi kuin yksi tietue täyttää hakuehdon, ensimmäiseksi löydettyä
käsitellään ns. nykytietueena (current record).
•
Seuraavassa tyypillisimmät tiedosto-operaatiot:
o Tiedoston avaaminen (Open): valmistelee tiedoston lukemista tai
kirjoittamista varten. Sijoittaa tiedosto-osoittimen tiedoston alkuun.
o Siirtyminen tiedoston alkuun (Reset): sijoittaa avatun tiedoston
osoittimen tiedoston alkuun.
o Etsi (Find / Locate): hakee tiedosto-osoittimen nykyisestä
sijaintipaikasta lukien ensimmäisen hakuehdon täyttävän tietueen, ja
siirtää sen sisältävän blokin keskusmuistiin. ellei se ole siellä jo
entuudestaan. Löydetystä tietueesta tulee ns. nykyinen tietue.
o Lue (Read / Get): lukee nykyisen tietueen keskusmuistiin ja siirtää
tiedosto-osoitinta yhdellä eteenpäin.
o EtsiSeuraava (FindNext): etsii seuraavan tietueen, joka täyttää
annetun hakuehdon. Blokki, jossa kyseinen tietue sijaitsee, siirretään
keskus-muistin puskuriin, ellei se siellä jo ole. Löydetystä tietueesta
tulee nykyinen tietue.
o Tuhoa (Delete): Tuhoaa nykyisen tietueen ja mahdollisesti myös
päivittää myös levytiedoston.
o TeeMuutos (Modify): tekee nykytietueen joidenkin kenttien arvoihin
muutoksia ja mahdollisesti päivittää myös levytiedoston.
o Lisää (Insert): Etsii tiedostosta blokin, johon tietue on tarkoitus lisätä.
Siirtää kyseisen blokin keskusmuistiin (tarvittaessa), kirjoittaa uuden
tietueen puskuriin, ja mahdollisesti kirjoittaa blokin takaisin levylle.
o Sulje (Close): Sulkee tiedoston ja tyhjentää puskurit.
•
Edellä mainituista muut paitsi Avaa ja Sulje ovat ns. tietue kerrallaan
-operaatioita, sillä niiden vaikutus kohdistuu vain yhteen tietueeseen.
•
Operaatiot Etsi, EtsiSeuraava ja Lue voidaan yhdistää operaatioksi Selaa
(Scan).
•
Tietokantajärjestelmissä ovat usein käytettävissä myös seuraavat joukko
kerrallaan -operaatiot:
o EtsiKaikki (FindAll): hakee kaikki tietyn kriteerin täyttävät tietueet.
o EtsiJärjestettyinä (FindOrdered): hakee kaikki tietueet järjestettyinä
jonkin kentän mukaan
o OrganisoiUudelleen (Reorganize): käynnistää tiedoston
uudelleenorganisoinnin, joka pitää aika ajoin suorittaa.
•
Tiedoston organisointi tarkoittaa tapaa, jonka mukaisesti data on
tallennettuna tiedostoon (tietueet, blokit, saantirakeneet).
•
Saantimenetelmällä tarkoitetaan puolestaan sitä, millä tavoin tiedoston
tietueita päästään käsittelemään.
•
Mikäli tiedoston sisältö muuttuu verrattain harvoin, tiedoston sanotaan
olevan staattinen. Muutoin tiedosto on dynaaminen.
•
Tiedoston organisointia suunniteltaessa on tarpeen tietää, minkä
kriteerien perusteella hakuja yleensä tullaan tiedostossa tekemään.
5.7. Järjestämättömät tiedostot
•
Järjestämättömän eli peräkkäistiedoston (heap file, pile file, sequential
file) tietueita ei ole lajiteltu minkään kriteerin mukaan, vaan tietueen
sijaintipaikka määräytyy yksinomaan tallennusjärjestyksen perusteella.
•
Uusien tietueiden lisäämiskustannus on pieni, sillä lisääminen voidaan aina
tehdä tiedoston loppuun.
•
Sen sijaan tietueen hakeminen tulee kalliiksi, koska on turvauduttava
lineaarihakuun.
•
Tietueen tuhoamista varten pitää ensin hakea haluttu tietue keskusmuistin
puskuriin, poistaa se puskurista ja tallentaa puskurin uusi sisältö takaisin
levylle. Tällöin blokkiin muodostuu tyhjää tilaa tuhotun tietueen koon
verran. Jos tuhottavia tietueita on useita, blokin muistitilaa menetetään
tuntuvasti.
•
Tiedon poistaminen voidaan toteuttaa myös käyttämällä hyväksi ns.
tuhoamismerkintää (deletion marker). Tietueita, jotka on merkitty
tuhottaviksi, ei käsitellä enää hakuoperaatioissa, vaikka ne olisivatkin
toteuttaneet vaaditun hakukriteerin.
•
Toteutettiinpa tuhoaminen kummalla tavalla tahansa, pitää tiedosto
jossain vaiheessa organisoida uudelleen joko tiivistämällä blokkia
(vaihtoehdossa 1) tai poistamalla tuhotut tietueet fyysisesti (käytettäessä
vaihtoehtoa 2).
•
Myös tuhottujen tietueiden kohdalle voitaisiin ajatella kirjoitettavan uusia,
mutta tämä edellyttää  paitsi kiinteää tietuemittaa  myös kirjanpitoa
blokkien tyhjistä paikoista.
•
Järjestämätön tiedosto voi koostua joko kiinteän tai vaihtelevan mittaisista
tietueista, ja tiedosto voi olla joko viritetty tai virittämätön.
•
Mikäli järjestämätöntä tiedostoa haluttaisiin käsitellä järjestettynä tietyn
kentän mukaan, siitä pitäisi muodosta lajiteltu kopio ---> kallis operaatio,
jos tiedosto on kooltaan iso!
•
Sen sijaan tietueen järjestysnumerolla tietue löytyy nopeasti, jos allokointi
on tyypiltään jatkuva ja tietueet ovat kiinteän mittaisia. Jos tietueen
numerot ovat muotoa 0, 1, 2, ... , bfr-1, tällöin i. tietue sijaitsee blokissa
i / bfr ja se on blokin tietue numero i mod bfr.
5.8. Järjestetyt tiedostot
•
Tiedosto voidaan fyysisesti lajitella jonkin kentän sisällön mukaisesti.
Tuloksena on järjestetty tiedosto (ordered / sequential file, huomaa termin
sequential file kaksi eri päinvastaista merkitystä!).
•
Jos lajittelu tapahtuu tiedoston avainkentän mukaan, kyseessä on ns.
tiedoston järjestysavain (ordering key).
•
Tarkastellaan esimerkki lajitellusta henkilötiedostosta (kirjan esimerkki
5.9.).
•
Järjestetyn tiedoston etuja:
o Haluttaessa etsiä tietueita järjestysavainkentän mukaan, erillistä
lajittelua ei enää tarvita.
o Järjestyksessä seuraavan tietueen hakeminen ei yleensä vaadi uuden
blokin lukemista, ellei nykyinen tietue satu olemaan blokkinsa
viimeinen tietue.
o Etsittäessä tietuetta jonkin järjestysavaimen arvon perusteella voidaan
hyödyntää ns. puolitushakua (binary search), joka on lineaarihakua
tuntuvasti tehokkaampi. Puolitushaun teoreettinen aikakompleksisuus
on suuruusluokka (log2b), missä b on tiedoston sisältämien tietueiden
lukumäärä.
•
Tarkastellaan kirjan puolitushakualgoritmia 5.1.
•
Puolitushakua käytettäessä hakukriteerin ei tarvitse välttämättä olla
yhtäsuuruus, vaan myös pienemmyys ja suuremmuus tulevat kyseeseen
tehokkaasti.
•
Tiedon järjestämisestä ei kuitenkaan ole apua hauissa, joiden kriteeri ei
perustu järjestysavaimeen.
•
Vaikka tietueen hakeminen järjestysavaimen mukaan on halpaa,
päivitysoperaatiot (erityisesti lisäys) ovat kalliita, sillä keskimäärin puolet
tietueista joudutaan siirtämään. Tuhoaminen tulee sen sijaan halvemmaksi,
jos käytetään tuhoamismerkkejä.
•
Tietueen järjestysavainkentän arvon muuttaminen aiheuttaa entisen
tietueen tuhoamisen ja uuden, päivityksen mukaiset tiedot sisältävän
tietueen perustamisen. On nimittäin ilmeistä, että järjestysavainkentän
arvon päivittäminen johtaa tietueen fyysiseen siirtämiseen toisaalle, jotta
tietueiden järjestys säilyisi korrektina.
•
Tietueen lisäämiskustannusta voidaan pienentää myös muodostamalla
erillinen ns. ylivuoto- tai tapahtumatiedosto (overflow / transaction file),
jonne lisättävät tietueet kirjoitetaan syöttöjärjestyksessä. Alkuperäistä,
järjestettyä tiedostoa kutsutaan tuolloin päätiedostoksi (main file, master
file).
•
Myöhemmin ylivuototiedoston tietueet lajitellaan saman kentän mukaan
kuin päätiedosto ja limitetään päätiedoston kanssa uudeksi järjestetyksi
tiedostoksi.
•
Ylivuototiedostossa tietueen lisääminen tapahtuu aina tiedoston loppuun.
•
Vaikka ylivuototiedoston käyttäminen osittain ratkaisee järjestetyn
tiedoston uuden tietueen lisäämisen kalleusongelman, sen kuitenkin
kostautuu pidentyneinä hakuaikoina, jos haun aikana joudutaan usein
tutkimaan myös ylivuotoalue, sillä siellä on käytettävä lineaarihakua
(ylivuotoalue on lajiteltu vain limitettäessä sitä päätiedoston kanssa).
•
Erikoistapauksissa voidaan ylivuotoalue jättää tutkimatta, ellei tietuetta
löytynyt binäärihaulla päätiedostosta.
•
Järjestettyjä tiedostoja käytetään normaalisti vain yhdessä ns. primääriindeksien kanssa (käsitellään luvussa 6).
5.9. Hajautustekniikat
•
Hajautustekniikkaa (hashing technique) voidaan käyttää, kun lajitteluehto
perustuu yhtäsuuruusvertailuun yhden tietueen kentän suhteen.
•
Kyseisestä kentästä käytetään nimitystä hajautuskenttä (= hash field). Jos
kenttä on samalla avainkentän asemassa, siitä käytetään lisäksi nimitystä
hajautusavain (= hash key).
•
Hajautuksessa on periaatteena ns. hajautusfunktion soveltaminen
hajautuskentän arvolle. Tietueen hajautuskentän arvolle laskettu tietueen
hajautusfunktion arvo määrää levyblokin osoitteen, johon kyseinen tietue
tallennetaan / on tallennettu.
•
Haku annetun levyblokin sisältä tapahtuu siirtämällä tietueen sisältävän
blokin sisältö keskusmuistiin.
•
Hajautusta voidaan käyttää hyväksi sekä keskusmuistin sisäisenä
hakurakenteena että ulkoisten levytiedostojen tallentamiseen.
5.9.1. Sisäinen hajautus
•
Käytetään tietokoneen keskusmuistissa.
•
Tavoitteena erittäin nopea yksittäisen tietueen löytäminen.
•
Toteutetaan yleensä ns. hajautustaulun (hash-table) avulla, jonka
osoiteavaruus vaihtelee välillä 0..M-1: varataan M kappaletta muistipaikkoja tietueiden tallentamista varten (kts. kirjan esimerkki 5.10 (a)).
•
Hajautusfunktioksi h(K), missä K on hajautuskentän arvo, valitaan usein
K mod M, joka kuvaa hajautuskenttään tallennetut arvot alueelle 0..M.
•
Mikäli K:n arvo on reaaliluku, se on muunnettava kokonaisluvuksi ennen
mod-operaation soveltamista.
•
Merkkijonokentille voidaan käyttää apuna merkkien ASCII-koodeja
(tarkastellaan kirjan algoritmia 5.2 (a)).
•
Hajautusfunktio voidaan valita usealla eri tavalla; tässä tyydytään lähinnä
jakojäännösoperaation (mod) valintaan.
•
Yleinen pulma hajautustekniikkaa sovellettaessa: hajautuskentän
mahdollisten arvojen joukko on laajempi kuin hajautusfunktion arvoalue
---> usea hajautus-kentän arvo saattaa kuvautua samaksi
muistiosoitteeksi ---> seurauksena osoitetörmäyksiä (collisions). Samaan
muistiosoitteeseen voidaan kuitenkin sijoittaa vain yksi tietue.
•
Keinoja osoitetörmäysten hallitsemiseksi:
o Avoin osoittaminen (Open addressing):
 Tutkitaan seuraavia muistiosoitteita, kunnes ensimmäinen vapaa
löytyy, ja sijoitetaan tietue sinne (kts. kirjan algoritmi 5.2 (b)).
o Ketjuttaminen (Chaining):
 Sijoitetaan osoitetörmäyksen aiheuttanut tietue ns.
ylivuotoalueella olevaan vapaaseen muistipaikkaan, ja asetetaan
siihen linkki siitä muistipaikasta, jossa osoitetörmäys tapahtui
(katsotaan kirjan esimerkkiä 5.10 (b)).
 Alun perin samaan muistiosoitteeseen päätyneet tietueet
muodostavat linkitetyn listan, jota seuraamalla hajautusfunktion
kaikki samaan osoitteeseen kuvaamat tietueet löydetään.
o Moninkertainen hajautus (Multiple hashing):
 Mikäli ensimmäinen hajautusfunktio tuottaa osoitetörmäyksen,
yritetään uudelleen soveltamalla toista hajautusfunktiota. Mikäli
edelleen saadaan aikaan osoitetörmäys, voidaan turvautua joko
avoimeen osoittamiseen tai soveltaa vielä kolmattakin
hajautusfunktiota ja vasta tämän jälkeen avointa osoittamista,
mikäli tarpeen.
•
Jokaista osoitetörmäysten hallintamenetelmää kohti on omat algoritminsa
tietueiden hakua, lisäämistä ja tuhoamista varten. Yksinkertaisinta on
ketjutuksen käsittely, kun taas avoimeen osoittamiseen liittyvät algoritmit
tietueen poistamiseksi ovat varsin monimutkaisia.
•
Hyvä hajautusfunktio jakaa muistiosoitteita tasaisesti siten, ettei
osoitetörmäyksiä esiinny paljoa. Toisaalta, liian vähäinen hajautustaulun
täyttöaste hukkaa tarpeettomasti muistitilaa.
•
Yleensä arvo väliltä 0.7 - 0.9 suhteelle r / M on suotuisa: ei liian usein
osoitetörmäyksiä, muttei myöskään kohtuuttomasti käyttämätöntä
muistitilaa.
5.9.2. Ulkoinen hajautus
•
Käytetään levytiedostoissa.
•
Levy on jaettu nippuihin (buckets), joihin mahtuu useita tietueita. Nippu
edustaa joko yhtä muistiblokkia tai useamman perättäisen blokin
muodostamaa klusteria.
•
Nipun osoite annetaan yleensä ennemmin nipun suhteellisena
sijaintinumerona kuin nipun absoluuttisena blokkiosoitteena.
•
Osoitetörmäysongelma ei ole ulkoisessa hajautuksessa niin akuutti kuin
sisäisessä, sillä yhteen nippuun mahtuu useita tietueita. Kuitenkin myös
nipun täyttymiseen pitää varautua, joten yritettäessä viedä lisää tietueita
täynnä olevaan nippuun pitää perustaa linkki ylivuotoalueen nipun
vapaaseen muistipaikkaan, josta ketjutusta jatketaan niin pitkään kuin
osoitetörmäyksen aiheuttavia tietueita riittää (kts. kirjan kuva 5.12.).
•
Hajautusfunktio ei yleisesti säilytä tietueiden järjestystä nipun sisällä
hajautuskentän arvon suhteen. Kuitenkin myös järjestyksen ylläpitäviä
hajautusfunktioita on olemassa (esimerkiksi identiteettikuvaus). Myös
lajittelu nipun sisällä on mahdollista.
•
Staattinen hajautus: nippuja allokoidaan kiinteä määrä (esimerkiksi M
nippua, joihin kuhunkin mahtuu m tietuetta). Staattisen hajautuksen
haittapuolena on kuitenkin liiallinen muistin varaaminen, jos tietueita on
vähemmän kuin m  M kappaletta; vastaavasti, jos tietueita on tätä paljon
enemmän, tapahtuu useita osoitetörmäyksiä, mikä johtaa ylivuotoalueiden
käyttöön ja samalla tarvittavien linkitettyjen listojen pitenemiseen.
Ongelman ratkaisuksi saattaa kelvata dynaamisen hajautuksen
käyttäminen (kts. kappale 5.9.3).
•
Samoin kuin sisäisessä hajautuksessa, joudutaan nytkin turvautumaan
lineaarihakuun, jos haku ei tapahdu hajautuskentän vaan jonkin muun
kentän arvon perusteella.
•
Jos tietue poistetaan nipusta, tilalle voidaan tuoda jokin nipun
ylivuotoalueen tietueista.
•
Jos tietue poistetaan ylivuotoalueelta, on pidettävä kirjaa alueen vapaista
muistipaikoista.
•
Tietueen hajautuskentän arvoa päivitettäessä saatetaan tietue joutua
tuhoamaan alkuperäisestä paikastaan ja sijoittamaan toiseen nippuun
kentän uuden arvon määräämänä.
5.9.3. Dynaamista tiedoston koon muuttamista tukevia
hajautustekniikoita
•
Staattisen hajautuksen ongelmana on hajautusosoitteiden kiinteä
lukumäärä: tiedoston koon dynaaminen kasvattaminen tai supistaminen
on työlästä.
•
Vaihtoehtoja dynaamisuuden aikaansaamiseksi: laajennettava ja
lineaarinen hajautus (extendible / linear hashing).
•
Laajennettavassa hajautuksessa käytetään hyväksi ns.
hakemistorakennetta, joka on 2d-kokoinen nippuosoitevektori, jossa d
tarkoittaa hakemiston globaalia syvyyttä (global depth).
•
Hajautusosoitteen d ensimmäistä bittiä määräävät hakemistosta paikan,
josta löytyy tietueen sisältävän nipun varsinainen osoite.
•
Hakemiston kutakin 2d paikkaa kohti ei kuitenkaan tarvitse olla erillistä
nippua, johon hakemistopaikan tietueet tallennetaan, vaan useasta
hakemiston osoitteesta voi johtaa linkki samaan nippuun.
•
Nipun paikallisella syvyydellä (local depth) d' tarkoitetaan, monenko bitin
perusteella nippuun valitut tietueet ovat määräytyneet.
•
Tutkitaan kirjan esimerkkiä 5.13, jossa hakemiston globaali syvyys on 3.
•
Hakemiston globaalin syvyyden d arvo voi kasvaa tai pienentyä kerrallaan
yhdellä. d:n arvon kasvaessa hakemisto kahdentuu, pienentyessä
puoliintuu.
•
Hakemiston kahdentuminen tapahtuu, kun jokin nippu, jonka paikallinen
syvyys d' on yhtä suuri kuin hakemiston globaali syvyys d, vuotaa yli.
•
Hakemiston puoliintuminen tapahtuu silloin, kun tietueen
poistamisoperaation jälkeen yhdessäkään nipussa ei enää ole voimassa
d' = d (kaikissa d' < d).
•
Nipun halkaiseminen on tarpeen silloin, kun se vuotaa yli. Jos nipun
d' < d, ei hakemiston kahdentumista kuitenkaan tapahdu.
•
Tarkastellaan kahdentumista, puoliintumista ja nipun halkaisemista kirjan
esimerkin 5.13. avulla.
•
Laajennettavan hajautuksen etuja on useita:
o Tiedoston koon kasvaminen ei aiheuta suorituksen hidastumista kuten
staattisessa hajautuksessa, jossa on odotettavissa osoitetörmäyksiä.
o Tiedoston koon muuttumiseen ei tarvitse varautua etukäteen, vaan
mukautuminen tiedoston kulloiseenkin kokoon tapahtuu dynaamisesti.
o Hakemiston maksimaalinen koko on 2k, missä k on bittien lukumäärä
hajautuskentässä ---> tilan tarve hakemistoa varten vähäinen.
o Nipun halkaiseminen vaatii ainoastaan rajoitetulla alueella muutoksia,
sillä ainoastaan halkaistavan nipun tietueet joudutaan jakamaan
kahden nipun kesken.
•
Haittoina ovat hakemiston kahdentumisesta tai puoliintumisesta
aiheutuvat lisäkustannukset, samoin hakemistorakenteen aiheuttama
kahden muistiblokin (hakemisto + data) haku staattisen hajautuksen
yhden blokin (ainoastaan data) asemesta.
•
Lineaarisessa hajautuksessa pystytään käytettävien muistiblokkien
määrää säätelemään ilman hakemistoa.
•
Oletetaan seuraavaksi, että aluksi on käytettävissä M nippua, jotka on
numeroitu 0, 1, 2, ..., M-1 käyttämällä hajautusfunktiota h(K) = K mod M.
Merkitään kyseistä hajautusfunktiota merkinnällä hi.
•
Hajautusfunktion arvon osoittaman nipun ollessa täynnä on turvauduttava
ylivuotoalueeseen, mutta samalla halkaistaan nippu 0 ja jaetaan sen
sisältämät tietueet aikaisemman nipun 0 ja juuri perustetun uuden nipun M
kesken käyttämällä uutta hajautusfunktiota hi+1, joka on nyt muotoa K mod
2M.
•
Uudet ylivuototilanteet johtavat järjestyksessä seuraavan alkuperäisen
nipun 1, 2, 3, ..., M-1 halkaisuun, ja samalla uusien nippujen M+1, M+2,
M+3, ... 2M-1 luomiseen.
•
Arvo n kuvaa, mikä on seuraavaksi halkaistavan alkuperäisen nipun
numero. Aluksi n on arvoltaan 0, ja saavutettuaan arvon M-1 n nollataan
uudelleen. Nyt on käytettävä kaikkialla hajautusfunktiota hi+1. Uuden
ylivuodon tapahtuessa otettaisiin käyttöön jälleen uusi hajautusfunktio hi+2,
mikä johtaa blokin 0 halkaisuun ja blokin 2M perustamiseen.
•
Etsittäessä tietuetta silloin, kun kaikkia nippuja ei ole vielä halkaistu
kertaakaan, lasketaan aluksi ensimmäisen hajautusfunktion arvo. Jos tämä
on pienempi kuin n, pitää soveltaa 2. hajautusfunktiota (tarkastellaan kirjan
algoritmia 5.3).
•
Halkaisujen tapahtuessa saattaa ylivuotoalueella oleva tietue päätyä
varsinaiseen nippuun. Tästä käytetään nimitystä viivästynyt halkaisu
(delayed split).
•
Halkaisua voidaan kontrolloida myös ns. tiedoston kuormituskertoimen l
(file load factor) avulla, joka saadaan kaavasta l = r / (bfr  N), missä r
on tietueiden lukumäärä, bfr nippuun mahtuvien tietueiden määrä ja N
nippujen lukumäärä. Tällöin l:n arvo 0.9 olisi riittävä nipun halkaisuun ja
vastaavasti 0.7 kahden nipun yhdistämiselle.
5.10. Muita primääritiedoston organisaatioita
•
Eri tyyppiä olevista tietueista koostuva tiedosto voidaan perustaa silloin,
kun etsittäessä tietyn entiteettityypin edustajaa pitäisi nopeasti päästä
käsiksi tähän liittyviä muun tyyppisiin tietoihin. Menettelystä käytetään
nimitystä fyysinen klusterointi (physical clustering).
•
Esimerkki: etsittäessä tiedekunnan tietoja haluttaisiin selata kaikkia sen
opiskelijoita. Tällöin voitaisiin opiskelijoiden tietueet sijoittaa fyysisesti
samaan tiedostoon tiedekunnan tietueiden kanssa.
•
Tämä edellyttää tietueen tyyppikoodien tallentamista, jotta tiedettäisiin,
mistä entiteetistä kulloinkin on kyse.
•
B-puut indeksoinnin tietorakenteena (käsitellään myöhemmin lyhyesti
luvussa 6.3.1).
6. 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, joiden 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.
6.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.
6.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 levyblokkiosoite. Toisin sanoen, kaikkia datatiedoston tietueita kohti ei ole olemassa
tietuetta pääindeksitiedostossa!
•
Tarkastellaan kirjan kuvassa 5.9. 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 6.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ä.
6.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ä 6.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ästysindeksi-tiedostossa) vain kertaalleen.
•
Ryvästysindeksi muistuttaa toteutuksensa puolesta laajennettavaa
hajautusta (kts. kappale 5.9.3).
6.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 6.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ä 6.5.
•
Vaihtoehdot 1 ja 2 aiheuttavat muutoksia puolitushaku-algoritmiin, 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.
6.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 kokonaisuu-dessaan 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ä 6.6 (esimerkki 2-tasoisesta pääindeksistä).
•
Tarkastellaan kirjan algoritmia 6.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.
6.3. Dynaamiset monitasoiset indeksit
B- ja B+-puita käyttäen
•
Aluksi lyhyesti yleisiin puu-tietorakenteisiin liittyviä peruskäsitteitä:
o Puu muodostuu solmuista (nodes).
o Jokaisella solmulla juurisolmua lukuun ottamatta on tarkalleen yksi
isäsolmu ja mielivaltaisen monta lapsisolmua (=poikaa). Lapsisolmuja
ei välttämättä ole yhtään. Juurisolmu merkitään normaalisti
puurakenteen huipulle.
o Solmua, jolla ei ole yhtään lapsisolmua, kutsutaan lehtisolmuksi. Muut
solmut ovat puolestaan sisäsolmuja.
o Solmun taso on aina yhtä isompi kuin sen isäsolmun taso. Juurisolmun
taso on 0.
o Alipuu koostuu solmusta n, kaikista sen lapsi-solmuista ja kaikista
niiden jälkeläisistä.
6.3.1. Hakupuut ja B-puut
•
Kappaleessa 6.2. esitellyt monitasoiset indeksit voidaan mieltää hakupuun
yhtenä varianttina: jokaisella solmulla on maksimissa fo kappaletta
lapsisolmuja, ja solmujen avainarvot edustavat hakemistotasojen arvoja.
•
Kertalukua p olevassa hakupuussa esiintyy solmussa korkeintaan p-1
hakuarvoa ja p osoitinta lapsisolmuihin. Lisäksi voidaan olettaa, ettei sama
arvoa esiinny puussa kahdesti.
•
Solmut ovat siten muotoa <P1, K1, P2, K2, ..., Pq-1, Kq-1, Pq>, q  p.
•
Jokaiselle solmulle on voimassa:
1.
2.
K1 < K2 < ... < Kq-1.
Jokaiselle arvolle X Pi:n osoittamassa alipuussa pätee Ki-1 < X < Ki,
kun 1 < i < q, X < Ki, kun i = 1 ja Ki-1 < X, kun i = q.
•
Haettaessa tiettyä avainarvoa X tutkitaan aluksi juurisolmua. Mikäli etsitty
arvo esiintyy siellä, haku voidaan lopettaa saman tien. Muussa tapauksessa
pitää tehdä vertailu juurisolmun avainarvojen suhteen ja jatkaa hakemista
yhtä vähintään yhtä tasoa kauempaa. Seuraava haku kohdistuu solmuun,
jonne osoittaa juurisolmun osoitin Pi, kun i toteuttaa X:lle kohdan 2
mukaisen ehdon.
•
Tarkastellaan kirjan esimerkkejä 6.8 ja 6.9 hakupuista.
•
Hakupuun huonoina puolina ovat kuitenkin mahdollinen epätasapaino sekä
turha muistitilan kulutus. Hakuavainten syöttöjärjestys vaikuttaa nimittäin
ratkaisevasti muodostuvan hakupuun rakenteeseen. Pahimmassa
tapauksessa puu muodostuu pitkäksi listaksi, jolloin haun kustannus on
lineaarinen hakuavaimien määrään nähden.
•
Lääke tasapainottomuuden ongelmaan: B-puu, joka on hakupuu, jolla on
yleiseen hakupuuhun verrattuna tiukennetut vaatimukset.
•
Kertaluokkaa p olevalla B-puulla on voimassa seuraavat ominaisuudet:
1. Jokainen B-puun sisäsolmu on muotoa
<P1, <K1, Pr1>, P2, <K2, Pr2>, ..., <Kq-1, Prq-1>, Pq>, missä q  p.
Jokainen Pi on puuosoitin, joka osoittaa solmun seuraajasolmuun.
Vastaavasti Pri:t ovat dataosoittimia, jotka osoittavat siihen
datatiedoston tietueeseen (tai blokkiin), jossa hakuavain Ki esiintyy.
2. Jokaiselle solmulle on voimassa K1 < K2 < ... < Kq-1.
3. Jokaiselle arvolle X Pi:n osoittamassa alipuussa pätee Ki-1 < X < Ki,
kun 1 < i < q, X < Ki, kun i = 1 ja Ki-1 < X, kun i = q.
4. Jokaisella solmulla on enintään p puuosoitinta.
5. Jokaisella solmulla paitsi juurella ja lehtisolmuilla on vähintään p/2
puuosoitinta. Juurella on puuosoittimia vähintään 2, ellei se ole puun
ainoa solmu.
6. Solmulla, jossa esiintyy q kappaletta puuosoittimia,
sisältää q-1 avainarvoa ja siten myös saman verran
dataosoittimia.
7. Kaikki lehtisolmut sijaitsevat samalla tasolla.
Lehtisolmujen rakenne on muuten samanlainen kuin
sisäsolmujen, paitsi että niiden kaikki puuosoittimet
ovat nollaosoittimia (null pointers).
•
Tarkastellaan kirjan esimerkkiä 6.10a B-puun yleisestä rakenteesta ja
esimerkkiä 6.10b yksittäisestä kertalukua 3 olevasta B-puusta.
•
Mikäli B-puu on rakennettu ryvästyshakemistoon perustuen, on
dataosoittimien tilalla osoittimet blokkiin, jonne on tallennettu osoittimet
niihin datatiedoston tietueisiin, joissa hakuavaimen mukaista
ryvästyskentän arvoa esiintyy (vrt. vaihtoehto 3 / toisioindeksit). B-puun
rakentaminen alkaa perustamalla juurisolmu, jonne viedään niin monta
avainarvoa kuin sinne mahtuu, eli p-1 kappaletta.
•
Juurisolmun ollessa täynnä seuraavan avainarvon lisääminen johtaa
juurisolmun ylivuotoon, jolloin perustetaan kaksi uutta solmua tasolle 1
(juurisolmun taso on 0).
•
Lisättävä uusi avainarvo sekä juurisolmun vanhat avainarvot lajitellaan
nousevaan suuruusjärjestykseen. Arvoista keskimmäinen jää
juurisolmuun, tätä edeltävät (pienemmät) päätyvät vasemmanpuoleiseen
uuteen solmuun ja loput oikeanpuoleiseen uuteen solmuun.
•
Lisääminen tapahtuu aina puun alimmalle tasolle. Mikäli alimman tason
(merkitään alinta tasoa t:llä) solmu vuotaa yli, pitää se halkaista siten,
että tasolle t muodostuu yksi uusi solmu. Lisättävä avainarvo lajitellaan
ylivuotaneen solmun avainarvojen kanssa nousevaan suuruusjärjestykseen. Lajittelun jälkeen keskimmäinen alkio viedään ylivuotaneen
solmun tasolla t-1 sijaitsevaan isäsolmuun. Tätä pienemmät arvot jäävät
alkuperäiseen solmuun, ja suuremmat päätyvät uuteen solmuun.
•
Mikäli keskimmäisen avaimen lisääminen tason t-1 isäsolmuun ei onnistu
sen tähden, että kyseinenkin solmu on täynnä, joudutaan halkaisuja
jatkamaan samaan tapaan kuin tasolla t, eli tason t solmun halkaiseminen
saattaa johtaa myös tasoilla t-1, t-2, ..., 1 uusiin halkaisuihin. Jos taso t-1
on kuitenkin jo juurisolmu, joudutaan juuri halkaisemaan, ja puuhun
syntyy uusi taso.
•
Jos puolestaan B-puusta tuhotaan avainarvoja, ja tuhoaminen aiheuttaa
solmun täyttöasteen putoamisen alle puoleen, pitää solmuja yhdistää, eli
rakenteesta häviää solmuja. Tuhoamista tarkastellaan kuitenkin vasta
tietorakenteiden kurssilla.
•
Tarkastellaan kirjan esimerkissä 6.10. olevan B-puun muodostumista, kun
avainten syöttöjärjestys on 8, 5, 1, 7, 3, 12, 9, 6.
•
Empiiristen testien perusteella voidaan todeta, että B- ja B+-puiden
täyttöaste on noin 69%, kun avaimien syöttö ja poistaminen stabiloituu.
Tämä tarkoittaa sitä, että solmujen halkaisemista ja yhdistämistä  etenkin
niiden leviämistä ylemmille tasoille  tapahtuu verraten harvoin, joten haun
lisäksi myös avaimien lisäys- ja poisto-operaatiot toimivat tehokkaasti.
•
Tarkastellaan seuraavaksi, miten perustettavan B-puun kertaluku
määräytyy ja montako avainarvoa sen eri tasoille mahtuu (kirjan esimerkit
4-5 sivulla 174).
Oletetaan, että levyblokin koko B on 512 tavua. Avainkentän pituus V on 9
tavua. Puuosoitin P on 6 tavun mittainen ja dataosoitin Pr on 7-tavuinen.
Jokaiseen solmuun mahtuu enintään p kappaletta puuosoittimia ja p-1
kappaletta avainarvoja ja dataosoittimia. Yhden B-puun solmun pitää
mahtua yhteen blokkiin. Siten saadaan epäyhtälö:
(p * P) + ((p-1) * (Pr + V))  B
Sijoittamalla annetut arvot saadaan:
(p * 6) + ((p-1) * (7 + 9))  512
(22*p)  512
p  24
Toisin sanoen, B-puu saisi olla kertalukua 24. Kannattaa kuitenkin jättää
solmuun tilaa mahdollisia lisätietoja varten (esim. tallennettujen arvojen
lukumäärälle, isäosoittimelle jne.), joten 23 olisi parempi valinta p:lle.
•
Mikäli yleensä puun täyttöaste on 69%, olisi tällöin keskimääräinen
laajeneminen 0.69 * 23  16.
•
Tällöin puulla olisi keskimäärin seuraavat ominaisuudet:
Juuri:
1 solmu, 15 avainta, 16 puuosoitinta
Taso 1: 16 solmua, 240 avainta, 256 puuosoitinta
Taso 2: 256 solmua, 3840 avainta, 4096 puuosoitinta
Taso 3: 4096 solmua, 61440 avainta, 65536 puuosoitinta
...
•
Mikäli datatiedosto on pieni, ja sen tietueet ovat lyhyitä, voidaan B-puuta
käyttää myös tiedoston fyysisenä organisointina. Pitkillä tietueilla
rakenteesta tulee haun kannalta tehoton, koska tasoja muodostuu paljon.
6.3.2. B+-puut
•
B+-puut eroavat B-puista siten, että
o B+-puun sisäsolmut eivät sisällä lainkaan dataosoittimia, vaan kaikki
dataosoittimet esiintyvät lehtitasolla.
o Myös puun kaikki avainarvot esiintyvät lehtitasolla. Sisäsolmujen
avainarvoja käytetään ainoastaan haun opastimina.
o Lehtisolmu sisältää myös ns. seuraajaosoittimen (next pointer), jonka
avulla päästään käsiksi järjestyksessä seuraavaan solmuun.
o Sisäsolmussa esiintyvä arvo esiintyy myös sen vasemmalla puolella
olevan osoittimen osoittaman alipuun oikeanpuoleisimpana
lehtisolmuna.
•
Tarkastellaan kirjan esimerkkiä 6.11 B+-puun yleisestä rakenteesta.
•
Koska B+-puun sisäsolmut eivät sisällä dataosoittimia, B+-puun solmuja
mahtuu yhteen blokkiin enemmän kuin vastaavan B-puun solmuja
---> haku nopeutuu.
•
Tarkastellaan seuraavaksi, miten perustettavan B+-puun kertaluku
määräytyy ja montako avainarvoa sen eri tasoille mahtuu (kirjan esimerkit
6-7 sivulla 177).
Oletetaan, että levyblokkikoko ja kenttien pituudet ovat samat kuin B-puun
yhteydessä. Tutkitaan aluksi sisäsolmujen osuus. B+-puun kertaluku
saadaan laskettua epäyhtälöstä:
S(p * P) + ((p-1) * V)  B
Sijottamalla tähän annetut arvot saadaan:
(p * 6) + (p-1) * 9)  512
(15 * p)  521
Korkein epäyhtälön toteuttava p:n arvo on 34.
Seuraavaksi tarkastellaan lehtisolmut. Saadaan:
(plehti * (Pr + V)) + P  B
Sijoituksen jälkeen
(plehti * (7+9)) + 6  512
(16 * plehti)  506
Täten suurin mahdollinen arvo muuttujalle plehti olisi 31.
Koska B+-puidenkin keskimääräinen täyttöaste on 69%, sisäsolmuissa
olisi käytössä keskimäärin 34 * 0.69  23 puuosoitinta ja lehtisolmuissa
31 * 0.69  21 dataosoitinta.
Tällöin B+-puulla olisi keskimäärin seuraavat
ominaisuudet:
Juuri:
1 solmu, 22 avainta, 23 puuosoitinta
Taso 1: 23 solmua, 506 avainta, 529 puuosoitinta
Taso 2: 529 solmua, 11638 avainta, 12167 puuosoitinta
Taso 3: 12167 solmua, 255507 dataosoitinta
...
•
Siten B+-puuhun mahtuu keskimääräisellä täyttöasteella 0.69 paljon
enemmän solmuja kuin vastaavaan B-puuhun ---> haku nopeampaa.
•
Avainarvon lisääminen B+-puuhun muistuttaa melko lailla vastaavaa
menettelyä B-puussa.
•
Aluksi perustetaan juurisolmu, jonne viedään avainarvoja niin pitkään,
kunnes solmu täyttyy.
•
Solmu lisätään aina lehtitasolle.
•
Kun halutaan lisätä uusi avainarvo, kun juurisolmu on jo täynnä, lajitellaan
lisättävä arvo juuressa ennestään sijaitsevien avainarvojen kanssa. Tällöin
perustetaan tasolle 1 kaksi uutta solmua. Lajittelun jälkeiset j = (p+1)/2
ensimmäistä arvoa päätyvät vasemmanpuoleiseen uuteen solmuun ja
loput oikeanpuoleiseen. Keskimmäinen eli j:s arvo tallentuu myös
opastinarvoksi juureen.
•
Samaa menettelyä sovelletaan myös silloin, kun lisäyksen kohteena oleva
lehtisolmu vuotaa yli: uusi hakuavain lajitellaan lehtisolmun vanhojen
arvojen kanssa, ja lajittelun jälkeen toimitaan kuten silloin, kun juurisolmu
vuotaa ensimmäisen kerran yli.
•
Jos lehtisolmun ylivuodon yhteydessä ei lajittelun keskimmäistä arvoa
voidakaan tallentaa isäsolmuun sen ollessa täynnä, täytyy isäsolmukin
halkaista. Tällöin isäsolmuun lisättävä uusi arvo lajitellaan siellä
aikaisemmin esiintyneiden arvojen kanssa. Tämän jälkeen isäsolmun j =
(p+1)/2 ensimmäistä arvoa jäävät alkuperäiseen isäsolmuun, j:s arvo
siirretään tasoa korkeammalle (siitä ei säily kopiota alkuperäisellä
tasollaan puussa kuten halkaistaessa lehtisolmu) ja loput päätyvät uuteen
solmuun. Mikäli solmujen halkaiseminen jatkuu juureen asti, muodostuu
puuhun uusi taso.
•
Tarkastellaan lyhyesti avaimen hakuun ja lisäämiseen liittyviä algoritmeja
6.2 ja 6.3.
•
Tarkastellaan esimerkkiä 6.12., jossa B+-puuhun viedään samat avainarvot
samassa järjestyksessä kuin B-puuhun esimerkissä 6.10.
•
Hakuavaimen poistaminen B+-puusta on monimutkainen operaatio, mikäli
se saa aikaan solmujen yhdistämisen juureen asti (käsitellään lyhyesti yksi
esimerkki). B-puista voidaan muodostaa erilaisia variantteja solmujen
täyttöasteen mukaan:
o B*-puussa pitää olla vähintään 2/3 sen sisältämistä avainarvojen
tallennuspaikoista täytettyinä.
o Alhaisen täyttöasteen salliminen varaa turhan paljon muistia, mutta
mahdollistaa nopeamman avaimen poisto-operaation, koska
täyttöasteen tilapäinen pieneneminen alle 50%:n ei aiheuta solmujen
yhdistämistä.
o On myös mahdollista asettaa erilaiset kriteerit sisä- ja lehtisolmujen
täyttöasteen minimille.
6.4. Indeksointi useamman kuin yhden kentän suhteen
•
Kaikki tähän mennessä tarkastelemamme indeksit on perustettu
ainoastaan yhden kentän suhteen.
•
Kyselyissä esiintyy kuitenkin usein viittauksia useamman kuin yhden
kentän arvoihin.
•
Esimerkki: Halutaan löytää kaikki osastolla 4 töissä olevat 59-vuotiaat
työntekijät. Vaihtoehtoisia ratkaisutapoja:
1) Jos osastonumeron suhteen on perustettu indeksi muttei
iän suhteen, voidaan etsiä aluksi kaikki osaston 4
työntekijät ja poimia niistä kaikki 59-vuotiaat.
2) Jos puolestaan iän suhteen on olemassa indeksi muttei
osastonumeron suhteen, etsitään aluksi kaikki
59-vuotiaat, joiden joukosta etsitään sitten osastolla 4
kirjoilla olevat.
3) Jos kummankin kentän suhteen on olemassa indeksi,
tutkitaan niiden leikkaus (sama tietue- tai blokkiosoitin
molemmissa), ja haetaan kyseiset tietueet.
•
Kaikki kolme vaihtoehtoa tuottavat oikean tuloksen, mutta haku on
verrattain tehotonta, jos kummankin yksittäisen ehdon täyttäviä tietueita
on useita, mutta molemmat ehdot täyttäviä on vain harvoja.
6.4.1. Usean attribuutin suhteen järjestetty indeksi
•
Kaikki kolme vaihtoehtoa tuottavat oikean tuloksen, mutta haku on
verrattain tehotonta, jos kummankin yksittäisen ehdon täyttäviä tietueita
on useita, mutta molemmat ehdot täyttäviä on vain harvoja. Tehdään
n-vaiheinen järjestys: ensiksi ensimmäisen ja seuraavaksi toisen jne.,
lopulta n:nnen kentän mukaan.
•
Esimerkki: osastonumero-ikä -indeksissä hakuavaimet olisivat muotoa
<<osasto, ikä>, osoitin >,
missä osoitin viittaa osoitinblokkiin, joka sisältää osoittimet
niihin datatiedoston tietueisiin, joissa esiintyy tietty osasto-ikä
-yhdistelmä.
6.4.2. Ositettu hajautus
•
Mikäli hakukriteeri perustuu n:ään attribuuttiin, lasketaan hajautusavain
n:n hajautusosoitteen katenaationa (osoitteet yhdistetään peräkkäin).
•
On käyttökelpoinen ainoastaan silloin, kun haku perustuu yhtäsuuruusvertailuun.
•
Esimerkki: Osastonumeron ja iän suhteen tehty hajautus. Oletetaan, että
osastonumerolle saadaan 3-bitin hajautusosoite ja iälle
5-bitin mittainen. Oletetaan, että osastolle 4 muodostuu
hajautusosoite 100 ja iälle 59 osoite 10101.
---> Tällöin osaston 4 työntekijät löytyisivät niistä blokeista,
joiden 8-bittinen osoite alkaa 100 (XXXXX), ja niistä
59-vuotiaat tarkalleen blokista 100 10101.
6.4.3. Ristikkotiedostot
•
Soveltuvat hyvin tarkoitukseen, jossa jokaisen hakukriteeriin osallistuvan
attribuutin arvoalueet ovat luokiteltavissa arvoalueisiin.
•
Muodostetaan n-ulotteinen matriisi, ristikkotiedosto, jonka yksittäinen solu
edustaa yhteen hakuun liittyvien n:n attribuutin arvoalueiden
kombinaatiota. Jokaisesta solusta on osoitin nippuun, josta
hakuattribuuttien alueiden annettua yhdistelmää edustavat tietueet
löytyvät datatiedostosta.
•
Tarkastellaan kirjan esimerkkiä 6.14, jossa sekä osastonumerot ja iät on
kumpikin luokiteltu kuuteen luokkaan.
•
Haittoina ovat muistitilan hukkaaminen luokkien ollessa kooltaan
vaihtelevia sekä ylläpitokustannusten kalleus.
6.5 Muut indeksityypit
•
Sivuutetaan.
7. Relaatiomalli, relaatioiden rajoitukset ja
relaatioalgebra
7.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 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ä 7.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 attribuutien arvojoukot ovat äärellisiä, R:n
karteesiseen tuloon kuuluu yhteensä dom(A1) * dom(A2) * ... *
dom (An) erilaista tuplaa.
7.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 7.1 ja 7.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 7.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).
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!
7.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.
•
Myöskään ei ole merkitystä sillä, missä järjestyksessä relaation kentät on
kaavassa esitelty (kirjan esimerkki 7.3).
•
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,
59, 1.16>,
olisi nyt
t[Nimi] = <'Tahvo Löppönen'>
t[Hetu, OpsKeskiarvo, Ikä] = 010203-7890, 1.16, 59
7.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ä.
7.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 SQL2:n standardin
yhteydessä.
7.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
attribuutista, 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 relaation lyhyesti relaation
avaimeksi (key). Poistamalla yksikin avaimeen kuuluvista attribuuteista
yksikäsitteisyys-vaatimus relaatiotaulussa rikkoutuu.
•
Jokainen attribuuttien joukko, joka sisältää avaimen, on samalla myös
superavain.
•
Tarkastellaan uudelleen kirjan esimerkkiä 7.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 Hetu 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 7.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.
7.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ä 7.5, joka esittää yrityksen tietokannan
kaavaa.
•
Tarkastellaan esimerkkiä 7.6 yrityksen tietokannan tietynhetkisestä tilasta.
Tähän esimerkkiin viitataan jatkossa erittäin usein.
•
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.
7.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ä 7.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 7.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ä 7.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 7.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ä.
•
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äärittelykieltä (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.
•
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.
7.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.
7.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 eipuuttuvalle arvolle ei löydy vastinetta sen relaation pääavaimesta,
mihin vierasavain viittaa.
•
Tarkastellaan kirjan esimerkkiä, jossa 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 henkilötauluun.
7.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 tupla viittaa siihen.
•
Tarkastellaan kirjassa sivulla 210 olevia esimerkkejä, jotka perustuvat
kaikki kuvan 7.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. Relaation WORKS_ON toimii 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 yhteydessä:
o 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.
•
Eri toipumistapoja voidaan myös kombinoida.
Esimerkiksi työntekijän lopettaessa työt yrityksessä voitaisiin hänen
osallistumistietona 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 EMPLOYEEtaulussa.
•
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!
7.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 211 olevia esimerkkejä
muutosoperatioista.
7.4 Relaatioalgebran perusoperaatiot
•
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.
7.4.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ä erikoisoperaat-toreita, 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.
•
Valintaoperaattori on unaarinen, eli se kohdistuu kerrallaan yhteen
relaatioon.
•
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ä.
7.4.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.
7.4.3 Perättäiset operaatiot ja uudelleennimeäminen
•
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ä osastolla 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ä 7.9.
•
Uudelleennimeämisoperaattoria  voidaan käyttää tarpeen mukaan kuten
valinta- ja projektio-operaattoreitakin. 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
7.4.4 Joukkoteoreettiset operaatiot
•
Unionioperaation avulla voidaan kahteen relaation kuuluvat tuplat
yhdistää.
•
Unioperaattorista 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ä 7.10. 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ä 7.11.
•
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.
•
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ä nS, 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 naispuloisten 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ä 7.12.
•
Käytännössä edellisen esimerkin kaltaisissa tilanteissa käytetään
karteesisen tulon sijasta liitosoperaatiota.
7.4.5 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 m
attribuuttia, on tulosrelaatiossa m+n attribuuttia (liitosattribuutti esiintyy
kahdesti).
•
Kun liitosehdossa esiintyy muitakin kuin yhtäsuuruus-operaattoreita,
käytetään liitoksesta nimitystä theta-liitos, muutoin kyseessä on
yhtäsuuruusliitos (=equijoin).
•
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ä 7.13.
•
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 osasto-relaatiossa 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 samannimiset (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)
7.4.6 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 edeltää 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.
7.4.7 Jakolaskuoperaatio
•
Myös seuraavaksi esiteltävä jakolaskuoperaatio (division) voitaisiin
esittää projektion ja karteesisen tulon avulla.
•
Jakolaskuoperaatiota tarvitaan, kun tulosrelaatioon halutaan tietueita,
joilla on samat tulkinnalliset ominaisuudet kuin jollain tietyn
entiteettityypin yksittäisellä edustajalla.
•
Tarkastellaan esimerkkiä, jossa halutaan löytää ne henkilöt, jotka
työskentelevät kaikissa niissa 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 X ja Y jakolaskun tulosrelaatioon T, pitää
relaatiossa R esiintyä jokaista S:n arvoa kohti attribuuttijoukon Y arvona t.
•
Tarkastellaan kirjan esimerkkiä 7.15b. 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
7.5 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.
7.5.1 Aggregaattifunktiot
•
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. aggregaatti-funktioita, 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ä 7.16: 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))!
7.5.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.
•
SQL3:n syntaksi kuitenkin tukee rekursiivista sulkeuma-operaatiota.
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 7.17 avulla.
7.5.3 Ulkoiset liitokset ja ulkoinen unioni
•
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
päinvastainen.
X[)
tilanne on tarkalleen
•
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).
Otetaan avuksi vasen ulkoinen liitos:
TILAP <--- (EMPLOYEE ]XSSN=MGRSSNDEPARTMENT)
TULOS <--- FNAME, MINIT, LNAME, DNAME(TILAP)
•
Tarkastellaan kirjan kuvaa 7.18, joka esittää edellisen esimerkin
tulosrelaatiotaulua.
•
Ulkoinen unioni voidaan muodostaa kahden osittain yhteensopivan
relaation välille.
•
Tällöin osa kentistä on kummassakin relaatiossa 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.
7.6 Esimerkkejä relaatioalgebran mukaisista kyselyistä
•
Tarkastellaan kirjassa olevia seitsemää esimerkkiä (luennolla jaetaan niistä
paperikappale).
8. Relaatiotietokantojen SQL-kyselykieli
•
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.
8.1 Datan määrittely, rajoitukset ja tietokannan
kaavan muutokset SQL2:ssa
•
Relaatioalgebran termejä relaatio, tupla ja attribuutti vastaavat SQL:ssä
taulu, rivi ja sarake.
8.1.1 Kaavan ja hakemiston käsitteet SQL2:ssa
•
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 ja SQL2:n tietotyypit ja rajoitukset
•
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.
•
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).
•
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.
•
Attribuuteille voidaan asettaa taulun perustamisen yhteydessä rajoituksia,
jotka koskevat sen saamia arvoja. Avainattribuutit luetellaan taulun
attribuuttilistan viimeisen attribuutin jälkeen uudelleen.
o Puuttuvien arvojen torjuminen (NOT NULL).
o Oletusarvon asettaminen, jos syötetään tyhjä arvo (DEFAULT).
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,
PERUSTAMISVUOSI INT,
PRIMARY KEY (OSASTONUMERO, SIJAINTI)
FOREIGN KEY (OSASTONUMERO) REFERENCES TYÖNTEKIJÄT
(OS_NUM))
•
Tarkastellaan kirjan esimerkkiä 8.1a.
•
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.
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.
•
Lisäksi voidaan attribuuteille määrätä toimenpiteet, mitä tehdään silloin,
kun siihen viittaava tupla poistetaan tai viittauksen kohteena oleva arvo
muuttuu. Toimenpiteet voivat olla erilaiset eri operaatioissa.
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.
•
Myös edellä esitellyt toimenpiteet voidaan nimetä käyttämällä varattua
sanaa CONSTRAINT.
•
Tarkastellaan kirjan esimerkkiä 8.1b.
8.1.3. 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. RESTRICToptio estää taulun poistamisen, mikäli se ei ole tyhjä, tai siihen viitataan
vielä toisaalla.
8.1.4 Komento ALTER TABLE
•
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>;
•
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
merkkijonosarake.
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.2 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.2.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 sekä 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.2.2 Saman niminen sarake useassa kyselyyn osallistuvassa taulussa;
uudelleennimeäminen (aliasointi)
•
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ä edustaisikin
tunnus NAME tunnuksen LNAME 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.NUMBER = E.NUMBER
8.2.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, WHERE-lausetta 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.
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
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.2.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:
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 Smith-niminen 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');
•
SQL2:ssa on käytettävissä vastaavat lauseet myös monijoukkojen
käsittelyyn (UNION ALL, EXCEPT ALL, INTERSECT ALL).
8.2.5 Osajonovertailut, aritmeettiset operaatiot ja lajittelu
•
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 ESC perään lainausmerkkien sisään.
Esimerkki: Haetaan mallia 'AB_CD%EF'. Tällöin hakulause olisi muotoa
... LIKE 'AB\_CD\%EF' ESC '\';
•
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 huomioda, 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 katenaatiooperaatiota (||).
•
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;
•
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 projektin 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 projektien 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.3 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.3.1 Sisäkkäiset kyselyt ja joukkovertailut
•
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.
20) Toteutetaan kysely 14 (=Q4A) uudelleen sisäkkäisenä kyselynä ilman
unionioperaatiota.
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.
21) 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');
•
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.
22) 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).
23) 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.
•
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ä.
24) Kirjoitetaan kysely 23 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 20 samoin kuin edellä kyselylle 23
(vihje: 'monista' taulua WORKS_ON).
•
Operaation CONTAINS avulla voidaan suorittaa relaatioiden
jakolaskuoperaatio. Operaatio tosin puuttuu monista
relaatiotietokantajärjestelmistä.
25) 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.3.2 EXIST- ja UNIQUE-funktiot SQL:ssä
•
EXIST-funktio testaa, kuuluuko alikyselyn tulokseen yhtään tuplaa (jos
kuuluu, on samantekevää, montako) vai ei.
26) 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.
27) 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
henkilö tulee valituksi.
•
Mikäli halutaan testata, tuottaako alikysely vastaukseksi tarkalleen yhden
tuplan, voidaan käyttää funktiota UNIQUE.
•
Tarkastellaan vielä paria lisäesimerkkiä.
28) 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
NOT EXISTS (SELECT *
FROM DEPARTMENT
WHERE SSN=MGRSSN);
29) 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.
30) Koska EXCEPT-operaatio puuttuu monesta 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.
8.3.3 Eksplisiittiset joukot ja puuttuvat arvot 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.
31) 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);
•
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.
32) Etsitään työntekijät, joilla ei ole esimiestä:
Q18: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE SUPERSSN IS NULL;
8.3.4 Attribuuttien uudelleennimeäminen ja liitostaulut
•
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
•
SQL2:ssa 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.3.5 Aggregaattifunktiot ja ryhmittely
•
SQL:ssä on käytettävissä aggregaattifunktiot COUNT, SUM, MAX, MIN ja
AVG. Näiden merkitykset vastaavat kappaleessa 7.5.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 palkkojen summa, maksimi, minimi
ja keskiarvo:
Q19: SELECT SUM (SALARY), MAX (SALARY), MIN (SALARY),
AVG (SALARY)
FROM EMPLOYEE;
39) Listataan kyselyn 39 mukaiset koostetiedot ainoastaan tutkimusosaston
työntekijöiltä:
Q20: SELECT SUM (SALARY), MAX (SALARY), MIN (SALARY),
AVG (SALARY)
FROM EMPLOYEE, DEPARTMENT
WHERE DNO=DNUMBER AND DNAME='Research';
40) Listataan työntekijöiden määrä koko yrityksessä:
Q21: SELECT COUNT (*)
FROM EMPLOYEE;
Kyselyssä merkintä (*) funktion COUNT jälkeen merkitsee 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
duplikaatteja. 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.
•
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.
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.4(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;
•
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.4(b).
•
Kannattaa huomioida, että WHERE-lauseen valintaehto valitsee yksittäisiä
tuplia, mutta HAVING-lause 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ä halutaan listata osastokohtaisesti niiden
henkilö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
henkilöitä vähintään 6.
49) Kysely 48 joudutaan siten uusimaan kelvolliseksi seuraavaan muotoon:
SELECT DNAME, 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.4 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.4.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 EMPLOYEEtuplasta, 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.4.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.
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.4.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');