1. No category

1
CT60A4301
Tietokannat
5 op
KURSSIMONISTE
KEVÄT 2015
Koonnut: Erja Mustonen-Ollila
Lisäykset vuodelle 2015: 1.1.2015/Erja Mustonen-Ollila
2
CT60A4301 Tietokannat -kurssin sisältö ja suorittaminen
Kevään 2015 luentoaikataulu, harjoitusaikataulu, Viope-verkkokurssin suoritusaikataulu,
tentit, kurssin loppuarvosana ja kurssipalaute:
Luennot pidetään maanantaisin klo 12.15-13.45 salissa 4511.
Harjoitukset pidetään keskiviikkoisin klo 15.15-16.45 mikroluokassa 6218. Harjoitukset
alkavat ensimmäisellä luentoviikolla.
Harjoitustyön palautuspäivä on perjantai 29.5.2015 kello 23.59 sähköpostin liitteenä. Katso
tarkemmat ohjeet harjoitusohjeen kohdasta Nopasta. Harjoitustyö on pakollinen kurssin
suorittamiseksi. Harjoitustyötä ohjaa kurssin luennoija. Harjoitustyön kiitettävästi
suorittaminen korottaa kurssin loppuarvosanaa yhdellä (1) arvosanalla.
ViopeSQL-verkkokurssi on pakollinen, mutta tentissä saa korvata SQL-kysymyksen kurssin
suorittamisella (yhteensä 8 pistettä). Ohjeet SQL-verkkokurssista ovat Nopassa kohdassa ”Muu
materiaali.” ViopeSQL- verkkokurssin suoritusaika päättyy 29.5.2015 kello 23.59. SQLViope
verkkokurssia ohjaa kurssin luennoija Erja Mustonen-Ollila.
Tentit
Kurssiin kuuluu tentti. Opiskelijan on itsensä huolehdittava tentti-ilmoittautumisesta. Kurssin
tentissä on 4 kysymystä, jotka kukin vastaavat 8 täyttä pistettä. SQLViope verkkokurssin
suorittamisella saa 8 p tenttiin.
Kurssin loppuarvosana
Kurssin loppuarvosanan saamiseksi on opiskelijan suoritettava: tentti hyväksytyllä arvosanalla
(minimissään arvosana 1), SQL-verkkokurssi ja harjoitustyö (hyväksytty tai kiittäen hyväksytty).
Kurssipalaute: Kurssin loppupuolella luennoija lähettää palautekyselyn opiskelijoille vastattavaksi.
Kurssipalaute näkyy Nopassa kohdassa tulokset. Kurssin vastapalaute: Opiskelijoilta saamaansa
palautteeseen luennoija vastaa vastapalautteella. Vastapalaute löytyy Nopasta. Kaikissa kurssiin
liittyvissä asioissa voi ottaa yhteyttä kurssin luennoijaan, email: erja.mustonen-ollila@lut.fi
Vaihtoehtoinen tapa suorittaa kevään 2015 Tietokannat- kurssi:
Koko Tietokannat kurssin voi suorittaa myös täysin etänä Stanford- yliopiston Databasekurssin avulla: https://class.stanford.edu/courses/DB/2014/SelfPaced/about
Tässä Stanford- kurssin tapauksessa opiskelija kirjautuu itse etäkurssille ja suorittaa sen
29.5.2015 klo 23.59 mennessä ja saa siitä todennetun/todennetut sertifikaatit. Kopion
sertifikaateista opiskelija toimittaa luennoijalle sähköpostin liitteenä.
Suorittaminen korvaa luennot, harjoitukset, harjoitustyön, tentin ja SQL-Viopen
verkkokurssin.
Onnea kurssille!
3
Relaatiotietokannat ......................................................................................................................................................... 4
Tiedonhallintajärjestelmän perusteita ......................................................................................................................... 5
Relaatiotietokantojen tasot ja kuvausmallit ................................................................................................................ 7
Relaatiotietokannan perusteet ja termistöä ................................................................................................................. 7
Relaatiomalli ............................................................................................................................................................. 10
Käsitenalyysi ............................................................................................................................................................ 10
Käsiteanalyysin pohja: ER-malli (entity-relationships model) ................................................................................. 10
Relaatioalgebran perusoperaatiot .............................................................................................................................. 13
Tietokannan suunnittelu- ja toteutusprosessi ................................................................................................................ 15
Tietokannan suunnittelun vaiheet ............................................................................................................................. 15
ER-mallintamisen peruskäsitteet .............................................................................................................................. 24
ER-kaaviosta relaatiomalliksi: esimerkkejä .............................................................................................................. 26
ER-mallista relaatioiksi -säännöt .............................................................................................................................. 27
Tietokannan normalisointi ............................................................................................................................................ 28
SQL-kieli ...................................................................................................................................................................... 32
Oliotietokannat ............................................................................................................................................................. 35
Olio-relaatiomalli .................................................................................................................................................... 36
Open Database Connectivity (ODBC) ja OLE DB .............................................................................................. 37
Oliotietokannat ja OQL ......................................................................................................................................... 37
Oliosuuntautuneet tietokannat .............................................................................................................................. 38
Olion identiteetti, olion rakenne ja tyypin rakentajat ................................................................................................ 38
OQL .............................................................................................................................................................................. 41
SQL-3 (SQL:99) ........................................................................................................................................................... 41
TIETOKANTASUUNNITTELUN PERUSTEET ....................................................................................................... 42
Seuraavat materiaalit ovat uutta vuoden 2015 luentomateriaalia: ................................................................................ 45
Tietokannan turvallisuus ............................................................................................................................................... 45
Tietoturvallisuus ........................................................................................................................................................... 45
Sovellusten turvallisuus ................................................................................................................................................ 47
Saatavuus ...................................................................................................................................................................... 48
Eheys ............................................................................................................................................................................ 48
Luottamuksellisuus ....................................................................................................................................................... 49
Tietokantojen uhat ........................................................................................................................................................ 50
Tietokannat ja tietoverkot ............................................................................................................................................. 53
Tietoverkkojen ja tietokantojen rajapinnat ................................................................................................................... 55
PHP Ja MySQL............................................................................................................................................................. 56
Hajautetut tietokannat & tietovarastointi ...................................................................................................................... 58
HAJAUTETUT TIETOKANNAT (Distributed database) ........................................................................................... 58
Komplikaatiot ............................................................................................................................................................... 58
Hajautettujen tietokantojen suunnittelu ........................................................................................................................ 59
Hajautettu hakemistojen hallinta................................................................................................................................... 59
Hajautettu kyselyn prosessointi .................................................................................................................................... 59
Hajautettu samanaikaisuuden hallinta........................................................................................................................... 59
Hajautettu umpikujan hallinta ....................................................................................................................................... 60
Hajautetun tietokannan luotettavuus ............................................................................................................................. 60
Toistuvuus .................................................................................................................................................................... 60
TIETOVARASTOINTI (Data warehousing)................................................................................................................ 61
Yleinen arkkitehtuuri .................................................................................................................................................... 61
Tietovaraston ominaisuudet .......................................................................................................................................... 62
Tietovarastoinnin uudet trendit ..................................................................................................................................... 63
4
Relaatiotietokannat
Kurssin relaatiotietokantojen osuus jäsentyy alla olevan kuvan 1 mukaisesti.
Kuva 1.
reaalimaailma
Käyttäjä ja
Käyttäjän toiveet
mallinnus
Tk:n
määrit
tely
LomakeRaportti
yms. määr
Tk:n
käyttämi
nen
ERkaavio
TiedonhallintaJärjestelmän ydin
Muunto
relaatioiksi
Tietohakemisto
Thj:n käyttöliittymät
Thj:n fyysiset
liittymät
Tietokanta
relaatiomalli
5
Tiedonhallintajärjestelmän perusteita
Tiedonhallintajärjestelmän rakennetta voi parhaiten selittää alla olevan kuvan 2 avulla.
Määritykset ja
määrityksien
muutokset
Tietokantakyselyt
Tietojen
lisäykset,
poistot ja
muutokset
Kuva 2.
"Kyselyjen"
prosessointi
Transaktioiden
hallinta
Tietohakemisto ja
tietokanta
(metadata ja
data)
Tiedostojen
hallinta
Tiedonhallintajärjestelmä prosessoi (tulkitsee, optimoi, suorittaa) käyttäjiltä ja ohjelmista tulevia
sanomia, jotka voivat olla:
- kyselyjä tietokannasta
- tietokannan tietojen lisäyksiä, poistoja ja muutoksia
- tietokannan tietojen määritysten muutoksia
Tiedonhallintajärjestelmän pitää em. "käyttäjäpalveluiden" lisäksi huolta tietokannan eheydestä.
Tätä varten tiedonhallintajärjestelmä valvoo transaktioita (sanomia) mm. niiden alkamista,
päättymistä, peruutuksia, varmistuksia ja uudelleensuorituksia esim. lukkojen, loki-tiedostojen ja
aikaleimojen avulla.
Tiedonhallintajärjestelmä hoitaa tietokannan ja tietohakemiston
tiedostonhallinnan joko
käyttöjärjestelmän avulla (pienehköissä tiedonhallintajärjestelmissä) tai pääosin omatoimisesti
(suuremmissa tiedonhallintajärjestelmissä).
Tiedonhallintajärjestelmä hakee tietokannasta tietoja (ja vie tietoja) ja muuntaa ne tietohakemistossa
olevien määrittelyjen mukaisina käyttäjille (tai sovellusohjelmille).
Em. tehtävien lisäksi tiedonhallintajärjestelmään kuuluviksi luetaan mm,
tietokannan konvertointityökaluja (versiosta toiseen tai toiseen tietokantajärjestelmään),
varmistuksiin ja palautuksiin liittyviä ohjelmia,
eheyden tarkistuksiin ja korjaamiseen liittyviä ohjelmia ja tietokannan dokumentointityökaluja.
Tietokannassa ovat
varsinaiset käyttäjien tarvitsemat ja tallentamat tiedot. Tietokannan
tiedostorakenne ei näy käyttäjälle eikä myöskään sovellusohjelmalle, vaan tiedonhallintajärjestelmä
hoitaa tietojen talletukset ja haut tietokantaan ja tietokannasta. Tietokannassa saattaa olla lisäksi
6
indeksi- tai puurakenteita nopeuttamassa hakua. Tietokannan suunnittelija tai vastuuhenkilö voi
määritellä tietyt tiedot indeksoitaviksi, mutta jotkut tiedonhallintajärjestelmät osaavat optimoida
tietokannan rakennetta ja tarvittaessa luoda uusia indeksitauluja.
Tietohakemistossa ovat tietokannan tietojen kuvaukset, mm. tietojen nimet, tyypit, ulkoasu, tiedon
pituus , tarkistussäännöt, triggerit, mahdollisia ilmoituksia, syöttömaskit, pakollisuus, oletusarvo ja
avainkenttien määrittelyt. Tietokannan tietojen määrittelyistä osa on sellaisia, että niitä voi vaihtaa
myös tietokannan perustamisen jälkeen ja osa määrittelyistä vaatii tietokannan konversiota
tullakseen voimaan. Tietokantoja käytettäessä ohjelmiin ei siis tarvitse kirjoittaa mitään
tietuekuvauksia, koska tiedonhallintajärjestelmä löytää tiedon nimen perusteella tietohakemistosta
tiedon ominaisuudet.
Tietokannan ja tietohakemistojen lisäksi tiedonhallintajärjestelmä luo ja pitää yllä lokitiedostoja,
joihin kerätään tietokannan muutostapahtumia, joita voidaan käyttää tietokannan uudelleen
organisointiin esim laitehäiriön jälkeen.
Tietokannan hallintajärjestelmiä ovat esim. Oracle, DB2, Ingres ja SQL Server. Tietyin rajoituksin
tietokannan hallintajärjestelmäksi voi kutsua myös Accessia ja Paradoxia.
Hallintajärjestelmän muita perusvaatimuksia ovat seuraavat: perusoperaatiot (tallennus, haku,
päivitys), tietoriippumattomuus, yhteiskäyttö, ylimäärättömyys, turvaaminen, tehokkuus ja
suorituskyky, yhteensopivuus ja skaalautuvuus.
Tietokannan hallintajärjestelmien huonoja puolia ovat mm. monimutkaisuus, koko, hinta,
laitteistokustannukset, muutoskustannukset, suorituskyky ja vahinkojen suuri vaikutus.
Tietoturvaa hoidetaan mm. seuraavilla oikeuksissa asioiden takia:
taulukon omistajan (owner) määrittely (authorization), tietokantakäsittelyn valtuuksien
myöntäminen (grant), oikeuksin delegoida valtuus edelleen (with grant option), valtuuksien
epääminen (revoke) ja myös näkymien käsittelyyn voidaan myöntää oikeudet. Kustannuksia
aiheuttava elvytys koostuu seuraavista osioista:
varmuuskopio (backup copy), kopio koko tietokannasta tiettynä ajanhetkenä, pystytään
palauttamaan (restore) tietty aikaisempi tietokannan tilanne, lokitiedosto (log file), voidaan siirtyä
tietokannan
tilasta
toiseen,
ajallisesti
eteen
tai
taaksepäin.
Jokaisen tietokantaan tehtävän muutoksen yhteydessä kirjoitetaan lokitiedostoon tietueen esi- ja
jälkivedokset, jossa esivedos on kopio tietueesta ennen päivitystä ja jälkivedos on kopio tietueesta
päivityksen jälkeen. Lisäyksen yhteydessä syntyy vain jälkivedos ja poiston yhteydessä syntyy vain
esivedos.
Tapahtumien (transaktio) lokitiedostoa käytetään mahdollistamaan palautuminen keskeytyneestä
transaktiosta. Transaktio toteutetaan kokonaisuudessaan tai ei ollenkaan (atomicity). Tietokanta on
ennen ja jälkeen transaktion ristiriidattomassa (consistent) tilassa. Eristyvyys (isolation) tarkoittaa,
että transaktion aiheuttamat muutokset eivät saa näkyä muille ennen kuin koko transaktio on
hyväksytty (commit) ja pysyvyys (durability) saavutettu. Kun tapahtuma on vahvistettu (commit),
tapahtuman tulokset eivät häviä missään olosuhteissa. Keskeytyneen (aborted) transaktion
tietokantaan tekemät muutokset pitää peruuttaa (rollback). Lisäksi tulee huomioida
samanaikaisuuden käsittely (concurrency control) eli samanaikaiset transaktiot eivät saa sekoittua
keskenään.
Yhteiskäytössä useampi ihminen käyttää tietokantaa samanaikaisesti josta voi seurata ongelmia jos
yhteiskäyttöön ei ole varauduttu. Keinona on on rajoittaa muiden käyttäjien mahdollisuuksia jonkin
resurssin käytössä. Pessimistinen tapa (lukitukset) on toinen vaihtoehto. Tällöin
7
tietue lukitaan koko toimintoketjun ajaksi muilta käyttäjiltä. Optimistisempi tapa eli aikaleimat
päivityksessä tarkoittaa sitä, että tietuetta päivitettäessä tutkitaan onko tietueessa "käyty" sen
jälkeen kun se otettiin muutettavaksi (aikaleimat).
Pessimistisessä lukituksessa käytetään eritasoisia lukituksia. 1)S-lukitus eli jaettu lukitus (shared):
lukon omistaja ja muut voivat lukea sivun tietoja, mutta eivät päivittää niitä. Muut saavat S- ja Ulukituksia tälle sivulle. 2) U-lukitus eli päivityslukitus (update): lukituksen omistaja voi lukea tietoa
ja aikoo päivittää sitä. Kukaan muu ei voi saada U- eikä X-lukitusta. Ennen päivitystä lukon
omistaja odottaa, ettei muilla ole sivulle S-lukitusta. Sitten hän pyytää X-lukituksen ja suorittaa
päivityksen. 3) X-lukitus eli poissulkeva (exclusive): lukituksen omistaja voi lukea tai päivittää
lukittua dataa. Kukaan muu ei voi saada lukitusta. Lukkiumien (deadlocks) ennaltaehkäisy on
oleellista. Tästä tietoa enemmän käyttöjärjestelmien kurssilla.
Relaatiotietokantojen tasot ja kuvausmallit
Relaatiotietokanta käsittää kolme tasoa: ulkoisen, käsitteellisen ja sisäisen tason. Sisäinen taso
kuvaa tietokannan fyysistä rakennetta, todellisia talletettuja tietoja. Tiedon esitystapa, saantipolut
yms. määritellään tällä tasolla.
Käsitteellinen taso esittää koko tietokannan loogisen sisällön. Kuvaukset voidaan esittää joko
käytetystä tietokantamallista riippumattomalla loogisella tasolla tai jonkin semanttisen (merkitystä
kuvaavan) mallin mukaan tai tietokantamallin (kuten relaatiomallin) mukaan.
Ulkoinen taso kuvaa tietokantaa tietyn käyttäjäryhmän tai sovelluksen kannalta.
Käsitteellisellä tasolla yhtyvät kaikki ulkoisen tason näkymät.
Ts. kolmentasoinen tietokantarakenne mahdollistaa sen, että käsitteellisen tason kuvaukset voivat
muodostaa kohdealueesta suhteellisen pysyvän mallin.
Tietokantariippumattomuus: looginen tietokantariippumattomuus kuvaa ulkoisen tason ja
käsitteellisen tason keskinäistä riippumattomuutta ja fyysinen tietokantariippumattomuus kuvaa
käsitteellisen tason ja sisäisen tason keskinäistä riippumattomuutta.
Tietokannan rakenteen kuvaamiseen käytetään tietomalleja, jotka jaetaan semanttisiin malleihin,
tietokantamalleihin ja fyysisiin malleihin.
Semanttiset mallit: ER-malli: maailma kuvataan olioina ja niiden välisinä suhteina. ER-mallin
pohjana on joukkoteoria ja relaatioteoria.
Tietokantamallit: hierarkkinen malli, verkkomalli ja relaatiomalli.
Hierarkkinen malli ja verkkomalli antavat käyttäjälle keinot navigoida tietokannassa tietuetasolla.
Relaatiomalli sisältää lisäksi tietorakennetason, eikä tietuetaso välttämättä näy sen
tietojenkäsittelyssä.
Fyysiset mallit esittävät, miten tietokanta on talletettu muistiin. Ne käsittelevät tietuemuotoja,
tietuejärjestystä ja hakupolkuja.
Relaatiotietokannan perusteet ja termistöä
E.F.Codd esitti vuonna 1970 relaatiotietokannan keskeiset ideat julkaisussa "A relational model for
large shared data banks". Perusideoita ovat:
8
- Tietokanta näkyy käyttäjille tauluina eli relaatioina (vrt. excel-taulut). Siitä, millä tavalla
tiedot on talletettu levylle, pitää huolta tiedonhallintajärjestelmä eikä käyttäjä tai sovellusohjelma
"näe" tietokannan fyysistä talletusrakennetta (looginen ja fyysinen tietoriippumattomuus)
- Tietokannan taulujen välillä voi olla yhteyksiä eli riippuvuuksia (relationship).
- Tietokannan yksi taulu sisältää rivejä (vrt. tietueet) ja sarakkeita (vrt. tietueessa yksittäinen tieto).
- Taulussa jokin tieto (tai tietojen yhdistelmä) on avain-kenttä, jonka avulla voidaan identifioida
taulun rivi yksikäsitteisesti.
- Vierasavain tarkoittaa taulussa sellaista tietoa, jonka avulla löydetään jostain toisesta taulusta
haluttu rivi (tai halutut rivit) esim. tilitaulussa vierasavain on tilinomistaja, joka viittaa
henkilotaulun henkilotunnus-tietoon (katso alla kuva 3).
- Matemaattisesti perusteltu eli perustuu relaatioalgebraan. Tämä takaa sen, että relaatiotietokanta
saadaan ohjelmallisesti toteutettua, kun on olemassa matemaattinen perusta algoritmiseen
ohjelmointiin.
- SQL- kieli (Structured Query Language), joka perustuu edellä mainittuun relaatioalgebraan.
Kuva 3.
Tilitaulu
Tilinnro*
12345
34567
Henktaulu
hetu*
220345-6782
121212-6543
Tilin saldo
100,00
2340,00
Tilin omistaja
220345-6782
121212-6543
nimi
Matti Mattila
Aino Kallas
Tilin tyyppi
Luotollinen
Karttuva
lähiosoite
Kaivokatu 12 A 23
Alkutie 11
Postitmp
00100 Hki
00660 Hki
Relaatiotietokantojen "hyvyys" perustuu siihen, että relaatiotietokannat ja niissä tapahtuvat
operaatiot voidaan kuvata matemaattisesti selkeästi relaatio-algebran avulla, mikä mahdollistaa
käyttäjäystävälliset kyselykielet (esim. SQL) ja tehokkaat käsittelyalgoritmit.
Relaatiotietokantojen "puutteena" voitaneen pitää sitä, että ne edellyttävät tietojen olevan unaarisia
eli yksittäisiä ts. tietokannan tietyssä sarakkessa on yksi tieto. Sarake ei voi olla esim. lista tai uusi
taulukko, niinkuin esim. C-kielen tietue-määrittelyssä tai oliotietokannoissa.
Relaatiotietokanta muodostuu tauluista (tables), jotka sisältävät kenttiä (fields).
Taulun nimeksi kannattaa valita jokin selkeä ja kuvaava nimi. Nimessä kannattaa kuitenkin välttää
välilyöntejä, erikoismerkkejä ja skandinaavisia merkkejä (å,ä,ö).
Jokainen taulu sisältää yhden tai useamman kentän
Kenttiä (fields)luotaessa niille määritellään seuraavanlaisia ominaisuuksia:
Kentän nimi
Kentän nimeksi kannattaa valita jokin selkeä ja kuvaava nimi. Nimessä kannattaa kuitenkin välttää
välilyöntejä, erikoismerkkejä ja skandinaavisia merkkejä (å,ä,ö).
Tietotyyppi
Numeerinen
Merkkijono
Aika
Kiinteä vai vaihtuvamittainen kenttä?
Maksimipituus ja mahdollinen tarkkuus
9
Onko tieto pakollinen: mahdollisimman moni kenttä pitää määritellä pakolliseksi, jolloin vältetään
NULL-arvojen tuomat ongelmat. Tarkistukset syötettävän tiedon oikeellisuudelle tai sallittujen
arvojoukkojen joukko.
Oletusarvo
AVAIMET (keys):
- perusavain (primary key)
- yksikäsitteinen muodostuen yhdestä tai useammasta sarakkeesta
- taulusta ei saa löytyä identtisiä perusavaimen arvoja
- ei saa puuttua yhdeltäkään riviltä
- perusavaimen eheys (entity integrity)
- toissijaiset avaimet (secondary key, secondary index) nopeuttavat taulun järjestämistä
- viite-avaimet (foreign keys)
- määritysalue on sama kuin jonkin perusavaimen
Viite-eheys (Referential Integrity):
Jokaista taulussa esiintyvää (NULL:sta poikkeavaa) viiteavaimen arvoa pitää vastata sama
perusavaimen arvo taulussa, johon viiteavain viittaa.
Yritettäessä rikkoa viite-eheyttä perusavaimen päivityksellä on kolme vaihtoehtoa:
- NULLIFIES eli viiteavaimen nollaus:
kaikki poistuvaan perusavaimeen viittaavat viiteavaimet muutetaan NULLeiksi soveltuu vain
sarakkeisiin, joilta ei ole kielletty puuttuvaa arvoa (NOT NULL)
- CASCADES eli johdannaispoisto:
kaikki poistuvaan perusavaimeen viittaavat viiteavaimet ja vastaavat rivit poistetaan
- RESTRICTED eli rajoitettu poisto:
voidaan poistaa vain perusavaimet, joihin ei ole viittauksia eli kyseistä päivitystä ei tehdä.
Viite-eheysmäärittelyt:
Many-to-Many -suhteisiin DELETE RESTRICTED, UPDATE CASCADES
Many-to-One -suhteet DELETE RESTRICTED, UPDATE CASCADES
heikoille kohdetyypeille DELETE CASCADES, UPDATE CASCADES
Tietokanta on kokoelma yhteen liittyvää tietoa (data). Tietokanta on loogisesti yhtenäinen kokoelma
tietoa jolla on jokin merkitys. Tietokanta on suunniteltu, rakennettu ja täytetty tiedolla jotain tiettyä
tarkoitusta varten. Sillä on jokin tarkoitettu käyttäjäryhmä ja joitain ennalta laadittuja ohjelmia joita
käyttäjät käyttävät. Kukin tieto talletetaan kannassa vain yhteen paikkaan eli ei esiinny turhaa
toistuvuutta (redundanssia). Tietoja pystytään hakemaan joustavasti erilaisin perustein, myös
sellaisin, joita ei tietokantaa suunnitellessa ole pystytty ennakoimaan. Tietokannan rakenteellinen
muuttaminen on joustavaa Hyväksikäyttö ja sovellusohjelmat ovat riippumattomia tietojen
fyysisestä talletusrakenteesta: tietoriippumattomuus.
Muita relaatiotietokantoihin liittyviä termejä ja ominaisuuksia ovat seuraavat: ristiriidattomuus
(Consistency), normalisointi (Normalization), tietokantaskeemat (Database schemas), tapahtumien
hallinta (Transaction management), Jakamattomuus (Atomicity), pysyvyys (Durability),
samanaikaisuuden hallinta (Concurrency Control), transaction isolation, transaction serializability.
10
Relaatiomalli
Relaatiomalli (Codd, 1970) koostuu kolmesta komponentista:
1. Tietorakenne
- käyttäjä näkee tiedot kokoelmana taulukkoja ja ainoastaan taulukkoja
- taulukoihin eli tauluihin liittyy myös indeksejä
- tauluille on asetettu tarkat vaatimukset mm. rakenteen ja yksikäsitteisyyden suhteen. Näistä
taulukoista käytetään myös nimitystä relaatio.
Relaatiotaulut sisältävät attributteja eli sarakkeita, joille on määriteltävä arvoalueet.
Muut käsitteet ovat: monikko eli taulun rivi, avainehdokas, perusavain, toisioavain, viiteavain.
2. Tiedonkäsittely
Relaatiomalliin kuuluvat relaatio-operaatiot muodostavat mallin olennaisen osan.
Tietokantakäsittely tapahtuu relaatiomallissa pääasiassa taulukoiden, ei yksittäisten rivien
käsittelynä.
Relaatioalgebrassa määritellään operaatiot (yhdiste, leikkaus, erotus, tulo, valinta, projektio, jako,
liitos, jotka käsitellään myöhemmin tarkemmin tässä kurssimonisteessa.
3. Tiedon eheys:
- relaatiomalliin kuuluu joukko eheyssääntöjä
- eheydellä tarkoitetaan tietojen ristiriidattomuutta ja oikeellisuutta
- mallissa määritellään taulun sisäisten eheyssääntöjen lisäksi taulujen välistä viite-eheyttä koskevia
sääntöjä
- relaatiomalli keskittyy käyttäjän tietonäkemykseen ja siis tietokannan ulkoiseen ja käsitteelliseen
tasoon
- relaatiotietokanta on ainakin pääpiirteissään edellä esitetyn relaatiomallin mukainen tietokanta.
Käsitenalyysi
Tietokannan suunnittelu aloitetaan käsiteanalyysillä. Analyysin kohteena on koko toimintayksikkö
tai sen osa (rajattu alue). Käsitenalyysin tuloksena syntyy kohdealuetta kuvaava looginen malli,
käsitemalli. Käsitemalli esitetään graafisesti käsitekaaviona ja täydennetään tietokuvauksin.
Kohdealue kuvataan pelkistetysti tietokantaa varten. Käsitemalli sisältää kohdealueen tietojen
rakenteen lisäksi eheyssääntöjä. Käsitenalyysin käyttö johtaa tietokantaratkaisuihin, jotka ovat tietoja toteutusriippumattomia. Tietoja tarkastellaan loogisella tasolla ja ne heijastelevat toiminnan
tavoitteita, eivät tietokannan toteutustekniikkaa. Tavoitteena on rakentaa malli, joka on
maksimaalisen pysyvä.
Käsiteanalyysin pohja: ER-malli (entity-relationships model)
ER-mallin mukaan reaalimaailma jäsennetään
a) yksilöiksi (Entity),
b) niiden välisiksi suhteiksi (relationship) sekä
c) ominaisuuksiksi (Attribute).
Jokaiselle yksilölle etsitään lisäksi yksilöivä avain.
Käsiteanalyysissä käytetään termejä yksilötyyppi, yhteystyyppi ja ominaisuustyyppi, joilla
tarkoitetaan kokonaisia luokkia, jotka sisältävät yksittäisiä yksilöitä, yhteyksiä ja ominaisuuksia.
11
Käsiteanalyysin eteneminen vaiheittain:
1) Yksilötyyppien määritys: etsitään kohdealueeseen liittyvät yksilötyypit. Etsitään synonyymit ja
homonyymit.
2) Yhteystyyppien määritys: nimetään yhteystyypit ja määritellään ne alustavasti, yhteystyypin aste
ja mahdollinen ehdollisuus ja laji selvitetään. Aletaan muodostaa käsitemallikaaviota.
3) Avainten etsiminen: jokaiselle yksilötyypille yksilöivä perusavain sekä toisio- ja viiteavaimet.
Muokataan käsitemalli.
4) Avaimia koskevien eheyssääntöjen määritys: perusavaimia ja toisioavaimia koskevat
eheysäännöt ja yhteystyyppien eheyssäännöt
5) Ominaisuustyyppien määritys: etsitään ja määritellään ei-avain ominaisuustyypit kullekin
yksilötyypille. Muutokset käsitemalliin.
6) Muiden eheyssääntöjen määritys: määritellään ominaisuustyyppejä koskevat arvoaluesäännöt.
Muut ominaisuustyyppien eheyssäännöt.
7) Käsitemallin tarkistus: kriittisyys, virheiden ja puutteiden korjaus. Useita tarkistuskierroksia.
8) Määrittelyjen tarkastus ja viimeistely: tarkistetaan ja tarvittaessa täydennetään tehdyt kuvaukset.
Yksilötyypit: Esim. opettaja, oppilas
synonyymit= samasta asiasta kaksi eri nimitystä
homonyymit= kahdella tai useammalla eri asialla oleva sama nimi
Yhteystyypin suunta ja aste:
suunnalla tarkoitetaan sitä, että kummasta yksilötyypistä lähtien yhteyttä tarkastellaan (vanhempilapsi).
Aste vanhemman ja lapsen välillä voi olla: yhden suhde yhteen (1:1), yhden suhde moneen (1:N) tai
monen suhde moneen (M:N).
Monen suhde moneen- yhteys tulee AINA purkaa kahdeksi 1:N-yhteydeksi.
Avaimet: perus- ja toisioavaimet ja viiteavaimet
Jokaiselle yksilötyypille on määriteltävä sen yksilöiden identifioimiseen käytettävät avaimet:
perusavaimet ja toisioavaimet
ominaisuustyyppiä tai pienintä ominaisuustyyppiyhdistelmää, joka yksikäsitteisesti määrittelee
yksilön, kutsutaan avainehdokkaaksi
HUOM! Jos kahdella yksilöllä on sama avainehdokkaan arvo, ne ovat SAMA YKSILÖ!
Yksilötyypillä voi olla useita avainehdokkaita. Perusavaimeksi valitaan jokin näistä
avainehdokkaista, sellainen, jolle jokaisella yksilöllä on varmasti arvo.Muut avainehdokkaat
nimetään toisioavaimiksi. Löydettyjen avainten tiedot liitetään käsitemalliin
Viiteavaimet:
Viiteavain on ominaisuustyyppi tai ominaisuustyyppijoukko, joka osoittaa yhteyden yksilötyypin
vanhempaan (vanhemman perusavain).
Viiteavain on lapsiyksilötyypissä ja on SAMA kuin yllämainittu vanhemman perusavain.
Kaikkien yksilötyyppien viiteavaimet on määriteltävä.
Viiteavaimet esittävät yksilötyyppien välisiä eheyssääntöjä.
Avaimia koskevat eheyssäännöt: Perusavaimen valinta sisältää kaksi eheystarkistusta:
-- jokaisella yksilöllä täytyy olla perusavaimelle arvo ja
-- tämän arvon on oltava yksikäsitteinen jokaisella yksilöllä.
Toisioavaimien valintasäännöt sisältävät myös eheystarkistuksia:
-- jokaisella yksilöllä, jolla on toisioavaimella jokin arvo, arvo on yksikäsitteinen ja
ehkä jokaisella yksilöllä täytyy olla toisioavainarvo
eheyssäännöt tutkivat lisäysten, muutosten ja poistojen vaikutusta yhteystyyppeihin
12
olemassaolosäännöt: olosuhteet, joiden aikana perus- ja viiteavain voidaan lisätä, poistaa tai
päivittää.
Jokaista yhteystyyppiä varten selvitetään lisäys- ja poistosäännöt.
Lisäyssäännöt:
Lisäyssäännöt määrittävät milloin ja miten uuden lapsiyksilön voi lisätä tietokantaan.
Lisäyssääntöjä on kuutta tyyppiä:
- lapsiyksilön saa lisätä vain, jos vastaava vanhempiyksilö on olemassa
- lapsiyksilön saa lisätä vain, jos vanhempiyksilö luodaan automaattisesti, ellei ole jo olemassa
- lapsiyksilön saa lisätä aina; jos vastaavaa vanhempiyksilöä ei ole, viedään lapsen viiteavaimeen
NULL-arvo
- lapsiyksilön saa lisätä aina; jos vastaavaa vanhempiyksilö ei ole, viedään lapsen viiteavaimeen
ennalta määrätty alkuarvo
- lapsiyksilön saa lisätä vain, jos tietyt laatuehdot täytetään
- lapsiyksilön lisääminen on aina sallittua; ei mitään tarkistuksia vanhempiyksilön suhteen.
Poistosäännöt:
Poistosäännöt määrittelevät olosuhteet, joiden aikana vanhempiyksilön voi poistaa tietokannasta tai
päivittää sen perusavaimen.
Kuusi eri poistosääntöä:
- vanhempiyksilön saa poistaa vain, jos ei ole olemassa yhtään siihen liittyvää lapsiyksilöä;
- vanhempiyksilön saa poistaa aina; vastaavat lapsiyksilöt poistetaan automaattisesti;
- vanhempiyksilön saa poistaa aina; vastaavien lapsiyksilöiden viiteavaimiin viedään NULLarvo
- vanhempiyksilön saa poistaa aina; vastaavien lapsiyksilöiden viiteavaimiin viedään ennalta
määrätty alkuarvo;
- vanhempiyksilön saa poistaa vain, jos tietyt ehdot ovat voimassa
- vanhempiyksilön saa poistaa aina; ei mitään tarkistuksia lapsiyksilöiden suhteen; NULLarvo merkitsee puuttuvaa, ei tiedossa olevaa arvoa. Se EI ole sama kuin tyhjä tai nolla.
Ominaisuustyypit:
Avaimiin sisältyvät ominaisuustyypit on tässä vaiheessa jo löydetty ja uusien yksilötyyppien
luominen voi olla tarpeen. Johdetut ominaisuustyypit: arvot saadaan johtamalla ne tavalla tai
toisella muiden ominaisuustyyppien arvoista. Kysymys kuuluu, että onko mahdollista yhdistää
yksilötyyppejä toisiinsa->käsitemallin tarkistus?
Muut eheyssäännöt ja arvoaluemäärittelyt:
Arvoaluemäärittelyt (domains) ja muut ominaisuustyppien eheyssäännöt (triggering operations):
Ominaisuustyyppien kelvollisten arvojen joukkoa kutsutaan sen arvoalueeksi: pituus, muoto,
vaihteluväli,
yksikäsitteisyys,
NULL-arvon
salliminen
ja
mahdollinen
alkuarvo.
Arvoaluemäärittelyt on tehtävä myös avaimille. Perusavain eikä sen osaa saa saada NULL-arvoa,
toisioavaimet voivat saada NULL-arvon.
Käsiteanalyysin tulokset ja tietohakemisto:
Käsiteanalyysiä tehdessä syntyy sekä käsitekaavioita että sanallisia tietokuvauksia.
Tietokuvaukset kootaan tietohakemistoon. Tietohakemisto sisältää siis metadataa, tietoa datasta.
Täydellisimmillään tietohakemistoon sisällytetään kaikki toimintayksikön tiedot sovelluksista,
13
tietokannoista, loogisista malleista, käyttäjistä ja hakukriteereistä: se sisältää tietokannan sisäisen,
käsitteellisen ja ulkoisen tason kaaviot sekä näiden väliset kuvaukset. Käsiteanalyysin aikana
tietohakemistoon liitetään määrittelyt yksilötyypeistä, yhteystyypeistä, ominaisuustyypeistä ja
eheyssäännöistä. Automaattinen tietohakemisto voi olla joko sisäänrakennettu osa tietokannan
hallintajärjestelmää ja siihen liittyvää kehitintä tai tietokannan hallintajärjestelmän tukema sovellus.
Relaatiotietokannoissa on yleinen tapa tallettaa tkhj:ään sisältyvä tietohakemisto tauluina, joita voi
käyttää samalla tavalla kuin tietokannan muita tauluja.
Relaatioalgebran perusoperaatiot
Relaatiotietokantojen matemaattinen perusta on relaatioalgebra. Relaatioalgebran muutamaa
perusoperaatiota tarvitaan mm tietokannan normalisoinnissa. Relaatioalgebraan perustuu myös.
esim. SQL-kyselyjen optimointi.
Liitos eli Join
Liitoksessa yhdistetään kaksi taulua uudeksi tauluksi jonkin avaimen perusteella tässä esimerkissä
piirin tunnuksen perusteella. Uudessa taulussa on sarakkeita yhteensä sama määrä kuin
alkuperäisissä yhteensä - 1 ja rivien määrä on sama kuin siinä taulussa, jossa rivejä oli enemmän.
Myyjätaulu
Myyjänro
M1
M2
M3
M4
Mynimi
Pirkko
Maija
Kalle
Saku
Piiritaulu
Pnro
P1
P2
MPnro
P1
P2
P2
P1
Myyjätaulu join Piiritaulu
Myyjänro
Mynimi
M1
Pirkko
M2
Maija
M3
Kalle
M4
Saku
MPnro
P1
P2
P2
P1
Pnimi
Länsi
Itä
Pnimi
Länsi
Itä
Itä
Länsi
Edellä oleva liitos on "inner join". Siinä uudessa taulussa on vain sellaisia rivejä, joiden tiedot
löytyvät molemmista tauluista. Jos piiritaulussa olisi rivi, jossa pnro=3 ja Pnimi=Etelä, ei tämän
rivin tietoja näkyisi ollenkaan liitostaulussa. "Outer join" on liitos, jossa jommasta kummasta
taulusta tuodaan uuteen liitostauluun myös sellaisia rivejä, joille ei löydy vastinparia toisesta
taulusta.
14
Yhdiste eli union
Yhdiste tarkoittaa sitä, että kaksi samanlaista taulua (samanlaiset sarakkeet) yhdistetään uudeksi
tauluksi, jolloin rivien määrä on sama kuin kahdessa alkuperäisessä yhteensä - ne rivit, jotka olivat
identtisiä.
Piiri1
Mnro
M1
M4
Mnimi
Pirkko
Saku
MPnro
P1
P1
Piiri1 union Piiri2
Mnro
Mnimi
M1
Pirkko
M2
Maija
M3
Kalle
M4
Saku
MPnro
P1
P2
P3
P1
Piiri2
Mnro
M2
M3
Mnimi
Maija
Kalle
MPnro
P2
P3
Valinta (selection)
Jostain taulusta valitaan uuteen tauluun vain tietyt rivit esim Sql:n avulla ilmaistuna:
Select * from myyja where nimi like "M*"
valinta myyjätaulusta
Mnro
Mnimi
M2
Maija
MPnro
P2
Projektio
Jostain taulusta valitaan uuteen tauluun vain tietyt sarakkeet. Tätä operaatiota käytetään varsin usein
tietokannan normalisoinnissa.
Projektio(Mnro,MPnro)
myyjätaulusta
Mnro
MPnro
M1
P1
M2
P2
M3
P2
M4
P1
15
Tietokannan suunnittelu- ja toteutusprosessi
Ohjelmistotuotantoprojekteissa käytetään yleisesti erilaisia vaihejakomalleja, jotka jäsentävät
kehitystyön määrittely-, suunnittelu-, toteutus- ja käyttöönottovaiheisiin. Näitä malleja ovat mm
EVO-malli ja vesiputousmalli. Näissä vaihejakomalleissa useimmiten näkökulmana ovat käyttäjän
toiminnot tai prosessit. Jos sovellusalue on voimakkaasti rekisteri- tai kortistotyyppinen, saattaa
vaiheistus olla toisenlainen tai ainakin määrittelyvaiheen jälkeen eriytetään tietokannan suunnittelu, toteutus- ja käyttöönotto omaksi (osa)projektikseen.Tietokantaprojektin vaihejakomalli voisi olla
seuraavanlainen (kuva 4 alla).
Reaalimaailman
mallinnus
Relaatiomallin
määrittely
Käyttöliittymän
suunnittelu
Tietokannan
määrittely
Tietokannan
tekninen toteutus
Käyttöliittymän
toteutus
Sovelluksen
testaus
Tietokannan suunnittelun vaiheet
Vaatimusten määrittely ja analyysi
Haastatteluin, kirjalliseen materiaaliin tutustumalla ja keskusteluin selvitetään järjestelmältä
vaadittavat ominaisuudet.
Käsitteellinen mallintaminen
Tietokantasuunnittelun alussa on tehtävä päätös siitä, minkä mallin mukaan (relaatiomalli,
verkkomalli, hierarkkinen malli) edetään.On myös päätettävä, mikä tiedonhallintajärjestelmä
valitaan käyttöön. Laaditaan käsitekaava, joka kuvaa tietokannan sisällön ja rakenteen. Tehdään
joko käsiteanalyysina tai oliomallinnuksena.
Ensimmäisenä vaiheena on reaalimaailman mallinnus, jossa suunnittelija yhdessä käyttäjien kanssa
kuvaa sovellusalueen kannalta keskeiset objektit, niiden ominaisuudet ja objektien väliset suhteet.
Tätä vaihetta kuvataan ER-mallinnuskohdassa. Mallinnus tehdään usein graafisilla menetelmillä
(kuten ER-mallinnus), jotta käyttäjä voisi osallistua suunnitteluprosessiin.
Mallinnuksen jälkeen malli muutetaan relaatiomalliksi (tai oliomalliksi, jos tullaan käyttämään
oliotietokantaa). Tässä vaiheessa mietitään relaatiomallin loogista rakenneta (eikä vielä fyysistä
16
toteutusta). Relaatiomallin pohjalta määritellään tietokannan taulut, taulujen väliset suhteet ja
taulujen tiedot (tietojen ominaisuudet). Tämän vaiheen jälkeen tietokantaan jo voi syöttää tietoja
joillakin tietokannan omilla työvälineillä, vaikka tietokannan käyttöliittymiä varsinaisesti ei olisi
olemassa. Lyhyesti vaihe sisältää sen, että ensin muutetaan semanttinen käsitemalli tietokantamallin
mukaiseksi rakenteeksi.
Tehtävä- ja transaktiosuunnittelu
Mallinnetaan tehtävät ja transaktiot, joilla tietokannan tietoja käytetään. Tietokannan suunnittelun ja
toteutuksen kanssa rinnan etenee käyttöliittymän suunnittelu ja toteutus. Siinä projektissa
suunnitellaan ja toteutetaan mm. tietojen ylläpitoon (lisäykset, muutokset, poistot), tietojen
kyselyihin ja tietojen raportointiin liittyvät ohjelmat. Monissa tietokantaohjelmissa ja myös
sovelluskehittimissä on välineitä, joiden avulla saadaan "ilman ohjelmointia" aikaan valikoita,
syöttölomakkeita, kyselylomakkeita ja raportteja.
Näiden avulla voidaan käyttäjille "demota" tietokantaa jo suunnitteluvaiheessa, jotta voidaan
mahdollisimman aikaisin korjata mallinnuksen tai suunnittelun aikana tehdyt virheet tai
väärinymmärrykset. Suunnitellaan sovelluksen rakenne ja sovellukseen kuuluvien näyttöjen sisältö
ja rakenne. Lopuksi toteutetaan tietokannan looginen suunnittelu
Käsitekaavan pohjalta laaditaan sisällöstä ja rakenteesta relaatiokaava käytettävissä olevalla
DDL:llä (Data Definition Language). Kiinnitetään käytettävä arkkitehtuuri, muodostetaan
komponentteja ja määritellään ne.
Fyysinen suunnittelu: päätetään tietokannan tallennusrakenteista ja saantimenetelmistä.
Tarkoituksena on tuottaa suorituskyvyn ja muistitilan käytön suhteen optimaalinen fyysinen
rakenne tietokannalle.
Toteutetaan edellisten osien suunnitelmat ohjelmointikielillä ja testataan toteutuksen toimivuus.
Tietokannan tekniseen toteutukseen ei yleensä juuri mikrotietokoneissa tarvitse kiinnittää
huomiota, mutta suuremmissa tietokannoissa on tietokannan suorituskyvyn kannalta runsaasti
"virittelemistä" vaativia asioita, jotka liittyvät mm indeksitauluihin, loki-tiedostoihin,
lukitsemiskäytäntöihin ja tietokannan sijoittamiseen levyille. Viritetään tietokantamäärittelyt ottasen
siis huomioon oman tietokannan hallintajärjestelmän ominaisuudet.
Käsitemallin muuttaminen relaatiorakenteeksi
Jokainen käsitemallin osa vuorollaan muutetaan relaatiomallin mukaiseksi. Relaatiomalli käsittää
osat tietorakenne ja tietoeheys. Loogisessa tietomallissa puhutaan yksilötyypeistä, yhteystyypeistä
ja ominaisuustyypeistä; relaatiomallissa nämä rakenteet kuvataan määrittelemällä relaatiotauluja ja
niiden sarakkeita eli attribuutteja. Loogisen tietomallin eheysominaisuudet muutetaan relaatiomallin
mukaisiksi mm. lisäämällä sääntöparametrejä taulujen määrittelyihin tai luomalla yksikäsitteisiä
indeksejä, makroja, ohjelmia jne. Tietokantasuunnittelun tuloksena saadaan tietokantakaava, joka
noudattelee loogisen käsitemallin kaikkia osasia. Relaatiotietokantajärjestelmät eivät kuitenkaan ole
täydellisiä ja eivät siten toteuta kaikkia niitä vaatimuksia, mitä tietosuuntautunut suunnittelu niiltä
edellyttää, joten viritykset on tehtävä.
Käsitemallin muuttaminen relaatiorakenteeksi:
Askel 1: Taulujen määrittely
Askel 2: sarakkeiden määrittely
Askel 3: Tietorakenteen sopeuttaminen tuotantoympäristöön
Askel 4: Yksilötyyppien eheyssääntöjen käsittely
Askel 5: Yhteystyyppien eheyssääntöjen käsittely
Askel 6: Muiden eheyssääntöjen käsittely
17
Askel 1: Taulujen määrittely
Jokaista käsitemallin yksilötyyppiä kohden määritellään relaatiotaulu. Taulut nimetään ja kirjataan
yhteys yksilötyypin ja taulun välillä. Määrittelyt kuvataan yleensä tietokannan hallintajärjestelmän
tiedonmäärittelykielellä (esim. Oraclessa SQL-kieli):
CREATE TABLE asiakas ...
Askel 2: Sarakkeiden määrittely
Jokaiseen tauluun määritellään sarakkeet: jokaista yksilötyypin ominaisuustyyppiä kohti
määritellään vastaavaan relaatiotauluun sarake.
Yksilötyyppien väliset yhteydet siirtyvät tässä vaiheessa automaattisesti relaatiorakenteeseen, koska
käsitemalli rakennettiin niin, että se sisältää viiteavaimissaan yhteystyypin sisältämän yhteyden.
Relaatiomalli kuvaa yhteyksiä viiteavaimia vastaavilla sarakkeilla.
Ominaisuustyyppejä EI PIDÄ YHDISTÄÄ yhdeksi sarakkeeksi.
CREATE TABLE asiakas (haaraosasto …
numero…
nimi…
osoite
tilikoodi…)
Askel 3: Tietorakenteen sopeuttaminen tuotantoympäristöön
Rakenne mukautetaan nyt tietyn TKHJ:n mukaiseksi:
Valitaan sarakkeiden talletusjärjestys
taulut tallennetaan muistiin (perusalueen varaus ja varatila)
taulujen sijoittaminen tietokantoihin (1-n kpl)
tietokannan lukitusparametrien asettaminen: lukitus on mekanismi, jolla TKHJ kontrolloi
tietoeheyttä saman tiedon yhtäaikaisten hakujen aikana.
Lukittavan tiedon määrä on määriteltävä; lukitaanko useita taulujam yksi taulu vai tietty taulun osa.
Lukon laatu ja lukituksen kestoaika.
Askel 4: Yksilötyyppien eheyssääntöjen käsittely
Yksilötyyppejä koskevat eheyssäännöt ovat perusavaimen ja toisioavaimen eheyssäännöt.
Perusavaimen eheysominaisuudet (yksikäsitteisyys, minimaalisuus (eli mikään perusavaimen osa ei
saa olla yksikäsitteinen), pakollisuusvaatimus) liitetään tietokantakaavaan.
CREATE TABLE asiakas (haaraosasto …
numero…
nimi…
osoite
tilikoodi…
PRIMARY KEY (haaraosasto, numero))
arvoaluetekniikka
vastaavasti toisioavaimen eheyssäännöt
18
Askel 5: Yhteystyyppien eheyssääntöjen käsittely
Lisäys ja poistosäännöt
koskevat perusavaimien ja viiteavaimien välisiä suhteita ja tukevat näin ollen tietokannan viiteeheyttä.
CREATE TABLE lasku (numero …
as * haaraosasto…
as * numero…
maara...
PRIMARY KEY (numero)
FOREIGN KEY (as *haaraosasto,
as *numero) References asiakas)
viiteavain (as * haaraosasto, as *numero) viittaa asiakas-vanhempitaulun perusavaimeen
Askel 6: Muiden eheyssääntöjen käsittely
Arvoaluemäärittelyt
säännöt, jotka koskevat lisäysten, poistojen ja muutosten vaikutusta muihin yksilötyyppeihin tai
saman yksilötyypin muihin ominaisuustyyppeihin.
Viritys
Tietokannan viritysvaiheessa tarkastellaan tietyn TKHJ:n mahdollisuuksia toteuttaa suunniteltu
tietokanta mahdollisimman tehokkaasti, sekä tutkitaan millaista räätälöintiä kyseisen TKHJ:n käyttö
aiheuttaa käsitemalliin ja tietokantakaavaan.
Virityskeinoista suosituimpia ovat erilaisten hakumekanismien luonti, koska ne ovat käyttäjälle
näkymättömiä:
selaus: tutkitaan peräkkäisesti rivejä, jotta haluttu tieto löytyy
ryvästys (clustering): rivit talletaan lajiteltuina joidenkin kenttien mukaan
hajautus: käytetään algoritmia tiedon osoitteen laskemiseen
indeksointi: luodaan tietokantaan erillisiä indeksirakenteita, joita käytetään hyväksi tietohaussa.
Indeksit on mahdollista myös luoda jälkeenpäin.
Viritystä voidaan kohdistaa myös tietorakenteeseen.
Viritys tietorakenteeseen:
Taulujen ja sarakkeiden uudelleen määrittely eli denormalisointi
tiedon toistaminen
sarakkeen uudelleen määrittely
taulujen uudelleen määrittely
suositus: normalisoidaan tietokanta kolmanteen normaalimuotoon ja vasta viritysvaiheessa tehdään
mahdolliset muutokset.
19
Alla on esitetty esimerkki tietohakemistosta
Henkilö
Ominaisuus
Tietotyyppi
Sisältörajoitteet ja -tarkistukset
email
sotu
CHAR(11)
etunimi
VARCHAR(32)
sukunimi
VARCHAR(64)
kotisivu
VARCHAR(128) pitää alkaa http://
puh
VARCHAR(32)
fax
VARCHAR(32)
katuosoite
VARCHAR(64)
VARCHAR(64) Pitää löytyä @-merkki
Sallitaan myös pelkkä syntymäaika
postitoimipaikka VARCHAR(64)
postinro
Paikkakunta
Ominaisuus
CHAR(5)
Aina viisi merkkiä
PID
AUTOINCREMENT
Oppilaitos
VARCHAR(128)
email
VARCHAR(64)
pitää löytyä @-merkki
kotisivu
VARCHAR(128)
pitää alkaa http://
puh
VARCHAR(32)
fax
VARCHAR(32)
katuosoite
VARCHAR(64)
Tietotyyppi
Sisältörajoitteet ja -tarkistukset
postitoimipaikka VARCHAR(64)
postinro
CHAR(5)
Aina viisi merkkiä
Postituslista
VARCHAR(64)
Pitää löytyä @-merkki
Tyyppi
Ominaisuus Tietotyyppi
Sisältörajoitteet ja -tarkistukset
TyyppiID AUTOINCREMENT
Tyyppinimi VARCHAR(64)
Harjoitustyö
Ominaisuus Tietotyyppi
Sisältörajoitteet ja -tarkistukset
email
INTEGER
koodi
INTEGER
TyoNro
URL
SMALLINT
VARCHAR(128) Pitää alkaa http://
Aihe
VARCHAR(128)
Pvm
DATE
Bonus
Formaatti
DOUBLE
Arvot alkavat ykkösestä jokaisella kurssilla
Ei sallita negatiivisia arvoja. Oletusarvo on nolla.
20
Ominaisuus
Tietotyyppi
Sisältörajoitteet ja -tarkistukset
FID
AUTOINCREMENT
Tiedostopaate VARCHAR(3)
Tiedostomuoto VARCHAR(64)
Kurssi
Ominaisuus Tietotyyppi
Sisältörajoitteet ja -tarkistukset
Koodi
Nimi
VARCHAR(64)
OV
DOUBLE
Kotisivu
VARCHAR(128) Pitää alkaa http://
CHAR(6)
htlkm
Arvosanat
Ominaisuus Tietotyyppi
SarjaID
Aina kuusi merkkiä
Sallitaan kokonaisluvut ja puolikkaat
SMALLINT
Sisältörajoitteet ja -tarkistukset
INTEGER
Pistemaara DOUBLE
Arvosana
VARCHAR(50) Arvosana voi olla sanallinen esim. Hylätty
Tentti
Ominaisuus Tietotyyppi
Sisältörajoitteet ja -tarkistukset
AUTOINCREMENT
TenttiID
Pvm
DATE
Suoritus
Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset
email
INTEGER
TID
INTEGER
Nro
SMALLINT
Pisteet
DOUBLE
Tilaa
Ominaisuus Tietotyyppi
Toimituspvm DATE
Tilauspvm
DATE
Toim.os
VARCHAR(50)
Sisältörajoitteet ja -tarkistukset
21
Alla on esitetty esimerkkejä ER-mallinnuksesta
ER-mallinnus on graafinen kuvaustapa. Se on helposti ymmärrettävää ja sopii hyvin tietokannan
suunnittelijan ja käyttäjän yhteistyössä suorittamaan reaalimaailman mallintamiseen ja käsitteiden
analysoimiseen. Lisäksi ER-mallinnuksella tuotetut kaaviot tuottavat 'automaattisesti' hyvin
relaatiotietokantoihin sopivat määrittelyt. Sinällään ER-kaavioita voitaisiin käyttää myös
oliotietokantojen määrittelyjen pohjana, mutta jos tiedossa on, että toteutus tapahtuu
oliotietokantaan, niin kannattanee käyttää mieluimmin OMT –mallinnusta (object modelling
technique).
Kuva 4
alkupvm
loppupvm
hetu
nimi
autot
omista
minen
henkilöt
osoite
Esimerkki 1
On autoja ja henkilöitä, joita kuvataan suorakaiteella. Suorakaide kuvaa yksilötyyppiä (entity).
Oliomallinnuksessa käytetään termiä olio (objekti). Suomen kielessä ei yleensä tehdä eroa
yksilötyypin ja yksilön välillä. Periaatteessa kuitenkin ero on olemassa eli yksilö tarkoittaa
esimerkiksi tiettyä henkilöä, mutta yksilötyyppi ei tarkoita ketään tiettyä henkilöä, vaan henkilöä
käsitteenä. Vinoneliö tai timantti on yhteystyyppi (riippuvuus, relationship) kahden yksilötyypin
välillä.
Sekä yksilötyyppeihin että yhteystyyppeihin voi liittyä ominaisuuksia (attribuutit) tai oikeastaan
ominaisuustyyppejä. Ominaisuuksia kuvataan ellipseillä. Esimerkissä henkilöillä on ominaisuudet:
hetu, nimi ja osoite sekä omistamisella on ominaisuudet: alkupvm ja loppupvm. Ominaisuus
nimeltä hetu on alleviivattu, koska se on henkilön identifiointitieto (perusavain).
Samankin reaalimaailman tilanteen voi nähdä monella tavalla. Esimerkiksi avioliitto voisi olla
kahden henkilön välinen yhteys taikka avioliitto voi olla oma yksilötyyppinsä.
ER-kaaviossa voidaan esittää myöskin lukumääräsuhteet. Vaihtoehtoja on
yksi liittyy yhteen
yksi liittyy moneen
moni liittyy moneen
Edellä olleessa esimerkissä voisi olla esim. niin, että yksi ihminen voi omistaa monta autoa, mutta
yhdellä autolla voi olla vain yksi omistaja. Lukumääräsuhteiden kuvaamiseen on useampia eri
tapoja, joista käytetyimpiä ovat seuraavat:
22
nuolet:
- yhden suhde moneen
Jos on yksilöt E ja F ja kutakin E:ssä oleva yksilöä vastaa täsmälleen yksi F, niin nuoli
osoittaa F:ää eli ylläolevassa esimerkissä nuolen kärki osoittaisi henkilöä.
- yhden suhde yhteen (nuolet kärjet molempiin)
monen suhde moneen (ei ollenkaan nuolen kärkiä), joskus käytetään kaksoiskärkeä osoittamaan
suhdetta moneen
suhdeluvut:
- nuolien tai viivojen päällä luvut 1:1 tai 1:n tai n:1
ER-mallinnuksessa merkitään yksilön perusavain alleviivaamalla ko ominaisuus. Avaimen pitää
olla yksikäsitteinen (sitten oikeassa tietokannassa). Kun esim "Tuntemattomasta Sotilaasta" on
kaksi eri elokuvaa, niin avaimeksi ei riitä pelkästään elokuvan nimi (koska se ei vielä kerro,
kummasta elokuvasta on kysymys), vaan avain voi olla useamman ominaisuuden yhdistelmä esim
nimi ja vuosiluku (elokuvaesimerkissä)
Jokin yhteys voi olla useamman kuin kahden yksilön välinen. Esim jossain sopimuksissa voisi olla
useampia sopijapuolia eli sopimus on yhteys, joka on kytketty moneen yksilöön. Tämä voidaan
purkaa binääririippuvuuksiksi (siis kahden välisiksi) niin, että tehdään sopimuksesta yksilö, johon
kytketään yhteydet ostaja, myyjä, todistaja ja takaaja.
Yleensä tietokannoissa ei myöskään yhteyksillä olla ominaisuuksia vaikka ER-mallinnuksessa voi
olla. Itse asiassa kun ER-kaavio muutetaan relaatiomalliksi, niin sekä yksilötyypeistä että
yhteystyypeistä tulee tietokannan tauluja, joissa sarakkeet vastaavat ER-mallin ominaisuuksia. ERmallinnusvaiheessa ei ole mitään syytä pyrkiä siihen, että
Toisinaan voi käydä niin, että on vain yksi yksilötyyppi (esim ihmiset) ja yhteystyyppi (esim
avioliitto), joka kytkeytyy kahteen kertaan yksilötyyppiin (eli mies ja vaimo). Silloin
näihin nuoliin voi laittaa nimiksi esim vaimo_ihminen ja mies_ihminen, mikä ihmisen "roolia" ko
avioliitossa.
23
Saman reaalimaailman ilmiön voi kuvata monella tavalla. Edellä olleen esimerkin henkilöt-autot
voi kuvata myös hienojakoisemmin. Tarkkuus ja kuvaustapa riippuvat kulloisestakin
sovellusalueesta ja käyttäjien tarpeista.
Kuva 5
ostaja
autot
kohde
myynti
myyjä
henkilöt
ostaja
kohde
osto
myyjä
Etenkin oliomallinnuksessa puhutaan usein luokista ja aliluokista. Myös ER-mallinnuksessa
voidaan muodostaa luokkia ja aliluokkia. Asiaa voinee parhaiten selittää esimerkin avulla.
Otetaanpa yksilötyyppi auto. Autoon voi liittyä monia ominaisuuksia esim moottorin tilavuus,
käyttöönottovuosi, merkki ja malli. On kuitenkin olemassa henkilöautoja, kuorma-autoja ja linjaautoja. Näistä kaikista on tarpeen tallettaa tietoja, henkilöautoista istumapaikat etupenkillä ja
takapenkillä, kuorma-autoista lastitilan koko kuutioina ja linja-autoista istumapaikkojen ja
seisomapaikkojen määrä. Tämä tilanne voidaan ER-mallinnuksessa hoitaa seuraavan esimerkin
mukaisesti:
24
merkki
Kuva 6
rekno
auto
isa
isa
isa
kauto
hauto
hauto
bussi
istumapaik
Henk edessä
Pyörien lkm
seisomapaikk
Henk takana
Autojen "yhteiset" ominaisuudet liitetään yksilöön auto ja kuhunkin aliluokkaan liitetään ko
aliluokan ominaisuudet. Avaimena voi toimia kaikissa yksilötyypeissä kuitenkin rekisterinumero.
ER-mallintamisen peruskäsitteet
Kohdetyypit (entity types): tunnistettavissa oleva asia tai tapahtuma
Helposti havaittavia kohdetyyppejä ovat käyttäjien puheissa esiintyvät henkilöt, esineet, tilat ja
tuotteet. Hankalampia ovat käsitteelliset kohdetyypit kuten tilaus tai sopimus.
Kohdetyypit ovat sellaisia, joista halutaan tallettaa tietoja pysyvästi tietokantaan. Raportit ja
tulosteet eivät ole kohdetyyppejä vaan tietokannan tiedoista johdettuja tulostietoja
heikko tyyppi (weak entity type).
Olemassaolo riippuu toisesta kohteesta eli ei voi olla olemassa jos tätä toista kohdetta ei ole myös
olemassa. Esim. tenttitulosta ei voi olla olemassa ilman tenttijää.
Suhdetyypit (relationship types): vähintään kahden kohteen välillä vallitseva riippuvuus. Suhde voi
merkitä olemassaoloa, toiminnallista suhdetta tai tapahtumaa. Suhteen aste määräytyy suhteeseen
liittyvien kohteiden lukumäärän mukaan.
Jos jokaista suhteeseen liittyvää kohdetta A vastaa vähintään yksi kohde B on kyseessä täysi suhde
(pakollinen suhde) muussa tapauksessa osittainen suhde
suhdeen kardinaalisuus (cardinality):
yhden suhde yhteen (one-to-one, 1-to-1)
yhden suhde moneen (one-to-many, 1-to-M) (monen suhde yhteen (many-to-one, M-to-1))
monen suhden moneen (many-to-many, M-to-M)
ominaisuudet (properties, attributes)
jokaisella samantyyppisellä kohteella on tiettyjä yhteisiä ominaisuuksia
opiskelijoilla on kaikilla nimi, sotu, osoite yms
25
Ominaisuuksien joukosta valitaan avaimeksi sopivat
Avaimen pitää olla yksilöivä, uniikki
Jokainen ominaisuus saa arvonsa (value) tietystä arvojoukosta (domain)
ominaisuudet voivat olla koottuja useasta osasta tai yksittäisiä.
Nimi voi koostua etu- ja sukunimestä.
Ominaisuus voi olla yksi- tai moniarvoinen
Sallitaanko ominaisuuksille tyhjät arvot
Sallitaaanko tuntemattot arvot (NULL)
Ominaisuudet voivat olla johdettuja
esim. tilausten kokonaislukumäärä lasketaan yksittäistilausten kappalemääristä.
Alityypit
perintä
Jokainen kohde on vähintään yhtä kohdetyyppiä mutta voi olla samaan aikaan useampaakin
ohjelmoija on on työntekijä eli ohjelmoija on alityyppi työntekijän ollessä ylityyppi
ohjelmoijalla on kaikki työntekijän ominaisuudet mutta ei päinvastoin
tyyppihierarkia
ER-diagrammit
- Kohteet: Jokainen kohde esitetään suorakulmiona jonka sisällä lukee kyseisen kohteen
kohdetyyppi. Heikoilla kohdetyypeillä suorakulmion kehä kaksinkertaistetaan.
- Ominaisuudet esitetään ellipseillä jotka on liitetty jatkuvalla viivalla kohteeseen tai suhteeseen.
Ellipsin sisällä lukee ominaisuuden nimi.
- Perityt ominaisuudet liitetään katkoviivalla
- Moniarvoiset ominaisuudet liitetään kaksinkertaisella viivalla
-Koottujen ominaisuuksien osaset esitetään kukin omana ellipsinään jotka liitetään jatkuvilla
viivoilla koostettuun ominaisuuteen.
- Avaimina toimivat ominaisuudet alleviivataan.
Suhteet:
Jokainen suhde esitetään timanttikuviona jonka sisällä lukee suhteen nimi.
Jos suhde on heikon kohteen ja "vahvan" kohteen välillä niin timanttikuvion kehä
kaksinkertaistetaan. Suhteeseen liittyvät kohteet liitetään siihen jatkuvalla viivalla joista jokaisen
kohdalla lukee 1 tai M riippuen siitä onko kyseessä yhden suhde yhteen, yhden suhde moneen vai
monen suhde moneen. Suhteen ja kohteen välinen viiva kaksinkertaistetaan jos kyseessä täysi suhde
alityypit:
alityyppi yhdistetään ylityyppiin yhtenäisellä viivalla jonka toisessa päässä on nuoli (ylityypin
päässä).
26
ER-kaaviosta relaatiomalliksi: esimerkkejä
Edellä esitetystä ER-esimerkistä 1 (autot-henkilöt) on tehty seuraavat neljä
relaatioratkaisua. Mikä tai mitkä niistä ovat mielestänne hyviä ja mitkä huonoja ja miksi ?
henkilöt
autot
omistami
nen
vaihtoehto 1
henkilot
hetu
nimi
12345
Ojala
Ville
34567
Mattila
Kai
67899
Simola
Olli
osoite
Kaivokatu
6
Ojakuja 3
Ojatie 15
vaihtoehto 2
henkilot
hetu
nimi
osoite
12345
Ojala
Kaivokatu
Ville
6
34567
Mattila Ojakuja 3
Kai
67899
Simola Ojatie 15
Olli
12345
Ojala
Kaivokatu
Ville
6
34567
Mattila Ojakuja 3
Kai
vaihtoehto 3
henkilot
hetu
nimi
osoite
12345
Ojala
Kaivokatu
Ville
6
34567
Mattila Ojakuja 3
Kai
67899
Simola Ojatie 15
Olli
autot
rekno
merkki
SYR-456 Volvo
hetu
12345
ABC-345 Saab
12345
VCX-765 Saab
34567
UIO-665 Ford
IOP-876 BMW
34567
67899
rekno
SYR-456
autot
rekno
merkki
SYR-456 Volvo
UIO-665
ABC-345 Saab
IOP-876
VCX-765 Saab
ABC-345
UIO-665
Ford
UIO-665
IOP-876
BMW
omistaminen
hetu
rekno
12345
SYR-456
autot
rekno
12345
ABC-345
SYR-456 Volvo
34567
VCX-765
ABC-345 Saab
34567
67899
UIO-665
IOP-876
VCX-765 Saab
UIO-665 Ford
IOP-876 BMW
merkki
erilaista
27
vaihtoehto 4
rekno
merkki rekpvm
hetu
SYR-456 Volvo
12.3.1996 12345
ABC-345 Saab
VCX-765 Saab
11.12.199 12345
1
3.6.1984 34567
UIO-665 Ford
1.1.1994
IOP-876 BMW
12.12.199 67899
7
34567
nimi
Ojala
Ville
Ojala
Ville
Mattila
Kai
Mattila
Kai
Simola
Olli
osoite
Kaivokatu
6
Kaivokatu
6
Ojakuja 3
Ojakuja 3
Ojatie 15
ER-mallista relaatioiksi -säännöt
- yksilötyypistä tulee relaatio eli taulu ja kaikista yksilötyypin ominaisuuksista tulee relaation
sarakkeita
- yhteystyypistä tulee myös relaatio, jonka tietoja yhteystyypin omat ominaisuudet ja lisäksi
vielä yhteysviivojen päissä olevien yksilöiden avaimet
- isa-yhteystyypeistä ei tehdä relaatioita
Tämä säännöstö tuottaa hyviä relaatioratkaisuja, joskin 1:n tai n:1 yhteystyypeistä ei välttämättä
aina tarvitsi tehdä tauluja (ellei haluta varautua siihen, että yhteystyyppi joskus saattaakin olla
tyyppiä n:n esim yksi ihminen voi omistaa monta autoa ja yhdellä autolla voi olla monta
omistajaa).
Relaatiotietokannan mallia (Schema) ei useinkaan tekstissä kuvata taulukoina, vaan lyhyemmin
seuraavasti:
HENK(hetu, sukunimi, etunimi, lähiosoite, postinro, postitoimipaikka)
AUTO(rekno, merkki,malli, kottovuosi)
OMISTAJA(hetu,rekno)
Jokaisesta taulusta on yksi rivi, jossa on taulun nimi ja taulussa olevat tiedot avainkenttä
alleviivattuna.
Sama voidaan kuvata myös yksityiskohtaisemmin seuraavasti:
HENK (
hetu, string
sukunimi, string
etunimi, string
lähiosoite, string
postinro, integer
postitoimipaikka, integer)
28
Tietokannan normalisointi
Tietokannan mallin pitäisi vastata todellisuutta ja käyttäjän tarpeita. Tietokannassa ei saa olla
redundanssia (päällekkäisyyttä) tiedoissa, muuta kuin tietysti välttämättömien linkkitietojen verran.
Redundanssi aiheuttaa mm ylimääräistä tietojen tallentamistyötä ja myös helposti virheitä, kun
muutokset tehdään johonkin paikkaan, mutta unohdetaan tehdä samaan tietoon jossain muussa
kohden tietokantaa. Tietokannan pitäisi olla sellainen, että kun tietoja muutetaan, poistetaan tai
lisätään, niin kaikki tehdään vain yhteen kertaan ja yhteen paikkaan eikä muutos saa aiheuttaa
ristiriitatilanteita eikä tuhota tarpeellisia tietoja. Hakeminen vaatii enemmän tehoa kuin
normalisoimattomassa ratkaisussa koska tiedot joudutaan hakemaan useammasta relaatiosta
Normaalimuodot syntyvät suhteellisen automaattisesti jos noudatetaan seuraavia sääntöjä:
Kohteen yhteyteen talletetaan vain kohteeseen välittömästi liittyviä tietoja ja kunkin tiedon
päivitys tapahtuu vain yhteen paikkaan.
ER-mallin perusteella tehty relaatiomalli on yleensä automaattisesti hyvä. Jos tietokanta tehdään
"korvakuulolta" esim. vanhan excel-taulukon pohjalta, siinä on varsin todennäköisesti hyvin paljon
redundanssia (samoja tietoja moneen kertaan).
Tietokantaa lähdetään nyt muodostamaan analyysivaiheen tulosten pohjalta tietyn tietokantamallinrelaatiomallin, verkkomallin tai hierarkkisen mallin- mukaiseksi. Tässä vaiheessa otetaan huomioon
myös sen tietokannan hallintajärjestelmän ominaisuudet, jolla tietokanta aiotaan toteuttaa.
Relaatiotietokantaa käytettäessä johdetaan taulujen määrittelyt käsitemallista sen jälkeen
mukautetaan tietorakenne valittuun tietokannan hallintajärjestelmään ja kuvataan sen sisältämällä
tietomäärittelykielellä. Myös tietokannan eheysominaisuudet liitetään tietokantamäärittelyyn.
Tietokannan virityksellä tarkoitetaan tietokannan suunnitteluvaiheen lopussa tapahtuvaa rakenteen
hienosäätöä, jonka tarkoituksena on tehdä tietokanta mahdollisimman suorituskykyiseksi (erilaisten
talletusrakenteiden edut ja hakumenetelmien suomat edut tai denormalisointi). Viritystoimien
jälkeen tehdään joukko muita tietokantaa koskevia suunnittelutehtäviä, ennen kuin tietokanta
voidaan ottaa käyttöön: tietokannan fyysisen ulkoisen tason näkymien määrittelyt ja
käyttöoikeuksien määrittelyt sekä fyysisen tason suunnittelun loppuunsaattaminen ohjelmien
suunnittelu ja toteutus.
Normalisoitu käsitemalli
Normalisointitarkistuksessa tietorakennetta kehitetään niin, että se täyttää tietyt kriteerit.
Normalisointitarkistus käsittää useita askeleita, joiden mukaan looginen tietomalli johdetaan
toivotun mukaiseksi rakenteeksi. Normalisointiaskelelten tuloksia kutsutaan normaalimuodoiksi.
Yleensä normalisoidaan kolmanteen normaalimuotoon asti. Analysointivaiheen tuloksena syntyy
looginen tietokannan kuvaus- täydennetty, normalisoitu käsitemalli, joka toimii lähtökohtana
seuraavalle vaiheelle, tietokannan suunnittelulle. Mallissa tiedot on loogisesti integroitu siten, että
tarpeetonta tietojen päällekkäisyyttä ei esiinny. Kun käsitemalli on tarkistettu ja todettu tai muutettu
halutun normaalimuodon mukaiseksi, on analyysivaihe saatettu päätökseen. Tämän jälkeen alkaa
suunnitteluvaihe, joka käsittää sekä tietokantasuunnittelun että ohjelmistosuunnittelun.
Normalisoinnilla muutetaan siis tietokannan rakennetta asteittain. Se aloitetaan
attribuuttimäärittelyistä (vastaa ominaisuustyyppiä) tai mielivaltaisista relaatio (taulukko-)
määrittelyistä (vastaa yksilötyyppiä) ja siinä käytetään hyväksi semanttista tietoa (tietojen
funktionaalisia riippuvuuksia), jotta lopputulokseksi saataisiin tietyt laatukriteerit täyttävät relaatiot.
Relaatioiden muokkaus tapahtuu askel askeleelta. Askeleita kutsutaan normaalimuodoiksi.
29
Normaalimuotoja on kolme: 1NM, 2NM ja 3NM. Myöhemmin niitä on kehitetty lisää: BCNM,
4NM ja 5NM. Normaalimuodot on määritelty niin, että aina yleisemmässä normaalimuodossa oleva
relaatio on myös kaikissa sitä alemmissa normaalimuodoissa.
Normalisointitarkastus
perustuu
ominaisuustyyppien
välisille
riippuvuuksille,
jonka
lähdemateriaalina on käsitemalli. Uusia yksilötyyppejä saattaa syntyä ja entiset voivat pilkkoontua
pienemmiksi. Yksilötyyppiin jätetään vain olennaisesti yhteen kuuluvat ominaisuustyypit.
Funktionaalinen riippuvuus:
Funktionaalinen riippuvuus voidaan määritellä seuraavasti:
Jos A ja B ovat ominaisuustyyppejä tai ominaisuustyyppiyhdistelmiä ja jokaista A:n arvoa vastaa
YKSI ja VAIN YKSI B:n arvo, sanotaan, että B on funktionaalisesti riippuva A:sta.
Tätä merkitään usein A->B
Jos A on usean ominaisuustyypin yhdistelmä ja B on funktionaalisesti riippuva koko A:sta eikä
mistään sen osajoukosta, sanotaan, että
B on täydellisesti funktionaalisesti riippuva A:sta.
Ensimmäinen normaalimuoto: Normalisointitarkastus alkaa siten, että kaikki yksilötyypit
johdetaan ensimmäiseen normaalimuotoon, mikäli ne eivät jo siinä ole.
Siksi on tarkasteltava, että millaisia ominaisuuksia yksilö voi saada.
1. Normaalimuoto (1NM) määritellään:
yksilötyypin katsotaan olevan 1. Normaalimuodossa, jos sen kaikki ominaisuutyypit ovat
perusominaisuustyyppejä, so. eivät ole koottuja. Jokainen ominaisuustyyppi siis voi sisältää vain
yhden arvon.
Toinen normaalimuoto: Toisessa normaalimuodossa tarkastellaan yksilötyypin sisäisiä
riippuvuussuhteita.
2. Normaalimuoto (2NM) määritellään:
Yksilötyyppi on toisessa normaalimuodossa, jos
1. Se on 1. Normaalimuodossa JA
2. Kaikki sen ei-avain -ominaisuustyypit
perusavaimesta.
ovat
täydellisesti
funktionaalisesti
riippuvia
Kolmas normaalimuoto:
Kolmas normaalimuoto merkitsee sitä, että yksilötyypissä saa olla vain perusavaimesta täydellisesti
funktionaalisesti riippuvia ei-avain -ominaisuustyyppejä (siis mihinkään avainehdokkaaseen
kuulumattomia ominaisuustyyppejä), joilla puolestaan ei saa olla muuta keskinäistä riippuvuutta.
3. Normaalimuoto määritellään:
Yksilötyyppi on kolmannessa normaalimuodossa, jos
1. Se on toisessa normaalimuodossa JA
2. Ei-avain- ominaisuustyypit eivät ole funktionaalisesti riippuvia toisesta ei-avainominaisuustyypistä (tarkemmin ominaisuustyyppijoukosta, joka ei sisällä avainta).
3.NORMAALIMUOTOA kuvataan usein puhumalla transitiivisesta riippuvuudesta, joka
määritellään seuraavasti:
Tarkastellaan yksilötyyppiä R(A,B,C). Ominaisuustyyppi C on transitiivisesti riippuva
ominaisuustyypistä A, jos pitää paikkansa, että
A->B JA B->C, mutta ei B->A (SIIS B ei ole avainehdokas)
30
Muut normaalimuodot ja normalisoitu käsitemalli:
Boyce-Codd (BCNM): yksilötyypillä on useita koottuja, limittäisiä avainehdokkaita.
BCNM:ssä yksilötyypin täytyy olla 3NM:ssä valittiinpa perusavaimeksi mikä tahansa
avainehdokas.
4NM: tilanteet, joissa esiintyy nk. moniarvoista riippuvuutta
5NM: sykliset riippuvuudet (vaatii hajottamaan yksilötyypin kerralla kolmeen tai useampaan
pienempään yksilötyyppiin).
Alla on esitetty esimerkkejä eri normaalimuodoista:
Ensimmäinen normaalimuoto
taulukossa ei saa olla tietotoistoja
taulukossa ei saa olla tietokoosteita
piirinro
p1
p1
p1
p2
p2
pinimi
länsi
länsi
länsi
itä
itä
mnro
m1
m2
m2
m3
m4
mnimi
pirkko
heikki
heikki
simo
kaija
mosoit
00660 hki
00630 hki
00630 hki
70400 kuo
55610 ima
tuote1
t1
t2
t5
t12
t9
määrä1
120
99
234
123
2234
tuote2
t9
t4
määr2
75
111
t4
221
Tässä taulussa on redundanssia eli samoja tietoja on moneen kertaan. Mm mnimi heikki on kahteen
kertaan ja pinimi länsi jopa kolmeen kertaan. Lisäksi taulussa on tietotoistoja, mm otsikot 'tuote' ja
'määrä' on samassa taulukossa useassa sarakkeessa. Taulukossa on myös tietokooste eli mosoite
sisältää kaksi tietoa (postinumero ja postitoimipaikka). Tällainen taulukko voidaan muuttaa
ensimmäiseen normaalimuotoon seuraavasti:
Tietokooste puretaan jakamalla tiedot kahteen eri sarakkeeseen.
Tietotoistot puretaan jakamalla em taulukko kahdeksi eri taulukoksi seuraavasti:
myyjätaulukko
piirinro piirinnimi
p1
länsi
p1
länsi
p2
itä
p2
itä
myyjä/tuotetaulukko
mnro
mnimi
m1
pirkko
m1
pirkko
m2
heikki
m2
heikki
m2
heikki
m3
simo
m4
kaija
m4
kaija
mnro
m1
m2
m3
m4
mnimi
pirkko
heikki
simo
kaija
tuotenro
t1
t9
t2
t4
t5
t12
t9
t4
mpostinro
00660
00630
70400
55610
määrä
120
75
99
111
234
123
2234
221
mptmp
hki
hki
kuopio
imatra
31
Toinen normaalimuoto
Taulukko on toisessa normaalimuodossa, jos taulukon kaikki tiedot (ominaisuudet) ovat täysin
riippuvat taulun koko avaimesta. Olennaista on siis selvittää ensin, mikä on taulukon avain.
Myyjätaulukossa avain on mnro, joka yksikäsitteisesti määrittelee jokaisen rivin. Kaikki muut tiedot
riippuvat mnro:sta, joten siinä ei tehdä muutoksia. Myyjätuotetaulukon avaimena on
yhdistelmäavain (mnro, tuotenro). Siinä taulukossa myyjän nimi ei riipu koko avaimesta, vaan
ainoastaan mnro:sta, joten mnimi voidaan ottaa siitä taulukosta pois.
Toisessa normaalimuodossa taulukot olisivat seuraavat:
myyjä/tuotetaulukko
mnro
tuotenro
m1
t1
m1
t9
m2
t2
m2
t4
m2
t5
m3
t12
m4
t9
m4
t4
määrä
120
75
99
111
234
123
2234
221
myyjätaulukko
piirinro piirinnimi
p1
länsi
p1
länsi
p2
itä
p2
itä
mnro
m1
m2
m3
m4
mnimi
pirkko
heikki
simo
kaija
mpostinro
00660
00630
70400
55610
mptmp
hki
hki
kuopio
imatra
Kolmas normaalimuoto
Säännön mukaan kolmannessa normaalimuodossa ei taulussa saa olla transitiivisia riippuvuuksia.
Myyjätaulukossa yllä mro on myyjätaulukon avain ja siitä riippuvat taulukon kaikki tiedot.
Kuitenkin mnro määrää yksikäsitteisesti postinron ja kun postinumero tiedetään, tiedetään myöskin
postitoimipaikka eli siinä on transitiivinen riippuvuus. Se voidaan poistaa ottamalla
myyjätaulukosta pois postitmp ja perustamalla uusi taulukko, jossa postitoimipaikat ovat. Samalla
tavalla mro:sta seuraa piirinro, josta seuraa piirinnimi. Näin myyjätaulukosta tehdään kolme uutta
taulua.
postinumerotaulu
postinumero
postitoimipaikka
00660
Helsinki
00630
Helsinki
70400
Kuopio
55610
Imattra
myyjätaulukko
piirinro mnro
p1
m1
p1
m2
p2
m3
p2
m4
mnimi
pirkko
heikki
simo
kaija
mpostinro
00660
00630
70400
55610
piiritaulukko
piirinro
p1
p1
p2
p2
piirinnimi
länsi
länsi
itä
itä
32
Neljäs normaalimuoto
Joillakin ominaisuuksilla saattaa olla monia arvoja samanaikaisesti. Tällaisia ominaisuuksia ovat
esim kielitaito, tutkinto ja harrastukset. Seuraavassa esimerkki tällaisesta tilanteesta ja sen
ratkaisusta normalisoimalla.
henktaulu
hetu
11
11
11
12
12
henk
hetu
11
12
nimi
jussi
jussi
jussi
maija
maija
kielitaito
engl
saksa
ruotsi
saksa
engl
kielitaito
hetu
11
11
11
12
12
nimi
jussi
maija
kieli
engl
saksa
ruotsi
saksa
engl
SQL-kieli
Yleistä
SQL (structured Query Language) kehitettiin IBM:n San Josen tutkimuslaboratioissa, alunperin
nimi oli SEQUEL. Ensimmäinen toteutus oli System R. Kokemukset olivat hyviä ja niinpä
kehitystä on jatkettu ja nyttemin SQL on käytössä lukuisien toimittajien sadoissa eri järjestelmissä.
Tunnetuimpia varmaan ovat IBM:n db2 ja Oracle. Kuitenkaan kaikki relaatiotietokannat (esim
Ingress) eivät tukeudu SQL-kieleen. Sittemmin SQL-kieltä on kehitetty edelleen ja siitä on tehty
useita standardeja.
ODBC (=open database connection tai connectivity): tarkoituksena on, että sovellusohjelma, joka
käyttää sql-kieltä voi käyttää mitä tahansa tietokantaa, johon on odbc-ajuri. Sovellusohjelman ja
tietokantamoottorin (=tiedonhallintaohjelmiston) välissä on ajuri, joka muuttaa sovelluksesta tulevat
sql-käskyt
sellaisiksi, että ne käyvät ko tiedonhallintajärjestelmälle ja vastaavasti
tiedonhallintajärjestelmästä tulevat viestit muutetaan standardi-sql-muotoisiksi, jotka sovellus
kykenee ottamaan vastaan. Osapuilleen samalla idealla toimivat esimerkiksi kirjoitinajurit, jotka
muuttavat tekstinkäsittelyohjelman tuottamat kirjoittimen ohjausmerkit sellaisiksi, joita ko
koneeseen kytketty kirjoitin ymmärtää ja "tottelee".
Nimi (SQL) on itse asiassa turhan vaatimaton. SQL se ei ole pelkästään kyselykieli, vaan sen on:
kyselykieli, kannan määrittely- tai kuvauskieli (DDL), kannan käsittelykieli (DML) , jolla voi tehdä
tietokantaan tietojen muutoksia, poistoja ja lisäyksiä.
SQL:ää voi käyttää itsenäisesti eli erikseen (käsikäskyillä), myös MsAccess-ohjelmassa
sql-kieltä voi käyttää upotettuna jollakin ohjelmointikielellä esim. C:llä staattisesti (eli sql-käskyt
on kiinteä osa ohjelmaa) tai dynaamisesti (ohjelman suoritusvaiheessa annetaan sql-käskyjä).
33
Eri sql-murteet eroavat tässä suhteessa aika lailla. Kuitenkin samat asiat voidaan kaikissa tehdä.
Näkymä (view)
Määritellään 'illuusio' taulusta, jota ei ole (se voi olla osa sarakkeita jostain olemassa olevasta
taulusta tai yhdistelmä useamman taulun tiedoista). Tätä illuusiota (eli taulua) ei siis ole
sellaisenaan tietokannassa, vaan tiedonhallintajärjestelmä hakee aina tiedot "oikeista" tauluista tai
vie "oikeisiin" tauluihin tiedot. Näkymän avulla voidaan rajoittaa käyttäjien pääsyä joihinkin
tietoihin (voidaan taulukohtaisesti ja näkymäkohtaisesti antaa oikeuksia) tai se voi olla vain
helpottamassa ohjelmointia.
Näkymän määrittelyesimerkki
CREATE VIEW tov2
AS SELECT sukunimi, etunimi,ika
FROM toverit
käyttöoikeuksien määrittely
GRANT ALL PRIVILEGES
ON tov2 TO K12345
GRANT SELECT
ON tov2 TO K23456
SQL-kyselyt
Yhdestä taulusta
SELECT tieto1, tieto2, tieto3
tai * (kaikki)
FROM
taulun nimi
WHERE joku ehto tai joitain ehtoja
ORDER BY tieto1, tieto2 ASC tai DESC
SELECT ihmiset.nimi, ihmiset.huone, ihmiset.osasto
FROM ihmiset;
SELECT ihmiset.nimi, ihmiset.huone, ihmiset.osasto
FROM ihmiset
ORDER BY ihmiset.nimi DESC;
SELECT *
FROM ihmiset
WHERE (((ihmiset.osasto)="Y"))
ORDER BY ihmiset.nimi DESC , ihmiset.huone DESC;
funktioita
SELECT count (*)
FROM tilaus
rivien lukumäärä
Tässä on tilaustaulusta tulostettu asiakkaittain asiakasnumero, tilausten kplmäärä ja tilausten mkyhteensä:
SELECT tilasnro, Count(*) AS lukum, Sum(tilaus.tilhintayht) AS mkyht
34
FROM tilaus
GROUP BY tilasnro;
SELECT Count(*), Avg(tilhinta), Min(tilhinta), Max(tilhinta), Sum(tilhinta)
FROM tilaus
SELECT * FROM tilaus
WHERE tilasnro = [anna asiakkaan numero]
SELECT * FROM tilaus
WHERE tilasnro = Forms![lomake1]![kentta2]
tietystä kentästä)
(asiakkaan numero kysytään)
(asiakkaan numero otetaan lomakkeelta
Useasta taulusta
SELECT ihmiset.nimi, ihmiset.osasto, huoneet.iskpl, huoneet.hunro FROM huoneet INNER JOIN
ihmiset ON huoneet.hunro = ihmiset.huone;
SELECT ihmiset.nimi, ihmiset.osasto, huoneet.iskpl, huoneet.hunro
FROM huoneet, ihmiset
WHERE huoneet.hunro = ihmiset.huone;
SELECT ihmiset.nimi, ihmiset.osasto, huoneet.iskpl, huoneet.hunro
FROM huoneet, ihmiset
WHERE huoneet.hunro = ihmiset.huone and ihmiset.nimi like 'A*';
Sql ja alikyselyt
SQL:n avulla voi myöskin "ketjuttaa" kyselyjä seuraavasti (alikyselyjen idea).
Tehdään ensin yksi kysely ja sitten sen tulosta käytetään seuraavassa kyselyssä jne
select nimi
from henkilot
where huone IN
(select huone
from henkilot
where nimi = 'jussi rajamäki')
sql ja määritysmuutokset
alter table toverit
add sp int;
alter table toverit
drop sp;
SQL ja tietokannan muutokset
insert into auto
values ('ABT-271', 'Toyota', 1975)
vrt 'tekstikenttä' ja 1975
insert into auto (rekno, merkki)
values ('ABT-271','Toyota')
vain osa kentistä
35
insert into auto(rekno, merkki)
values (Forms![lomake2]![kentta3], Forms![paalom3]![alilomake4]![mkentta]
tiedot haetaan lomakkeelta
update toverit
set etunimi = 'Maija'
where sukunimi = 'Rajamäki';
delete from toverit
where etunimi = 'Maija':
sql-triggerit
Triggerit (laukaisimet, liipaisimet) ovat tietokannassa olevia sääntöjä, joiden perusteella suoritetaan
"automaattisesti" jotain operaatioita, jos ehto on voimassa.
create trigger ennatys
after update of tulos on tulokset
when (tulokset.tulos > ennatykset.mtulos)
set ennatykset.mtulos = tulokset.mtulos;
Sulautettu SQL
SQL-käskyt upotetaan ohjelmointikieleen tai sovellus/raporttikehittimeen. Vastaukset suoraan
ohjelmointikielen muuttujiin. Dynaaminen SQL: SQL-käskyjä luodaan dynaamisesti
ohjelmakoodissa ja lähetetään generoitu SQL-käsky tietokantajärjestelmälle käännettäväksi ja
suoritettavaksi.
Oliotietokannat
Oliotietokannat mahdollistavat monimutkaisia sisäkkäisiä ja dynaamisesti muuttuvia rakenteita
Tarjoavat kyselyjen tueksi mielivaltaisia ja monimutkaisia operaatioita, joita käyttäjät voivat itse
määritellä (vrt. select SQL:ssä)
Mahdollistavat erityyppisten, usein yhdessä käsiteltävien olioiden tallentamisen fyysisesti lähelle
toisiaan.
Milloin kannattaa käyttää oliotietokantaa?
Jos relaatiotietokannassa taulujen määrä kasvaa räjähdysmäisesti.
Jos ilmenee monimutkaisten liitosten tarvetta.
Jos sovelluksessa käytetään oliotekniikkaa.
Jos talletettava tieto on monimutkaista, kuvia, ääntä, videokuvaa, muuttuvan kokoisia rakenteita.
Jos kyseessä hajautettu ympäristö.
Jos käyttö edellyttää pitkiä tapahtumia.
Oliokäsitteitä
Jokaisella tietokantaan talletetulla oliolla on oma yksilöllinen tunniste (object identifier, OID).
OID on muuttumaton ja ainutkertainen
Olion ominaisuuksia
Oliotunnisteen lisäksi oliot eroavat toisistaan ominaisuuksiensa perusteella.
Ominaisuudet voivat olla rakenne- tai käyttäytymisperusteisia.
Olion rakenne määrittyy tyyppimäärittelyn mukaan.
36
Olioluokka
Määrittää joukon, joka muodostuu rakenteeltaa ja ominaisuuksiltaan samanlaisista olioista.
Kapselointi (encapsulation)
Periaate, jonka mukaan kootaan yhteen toisiinsa liittyvät asiat eli tietokannan tapauksessa tiedon
rakenne ja sallitut metodit. Osa tiedoista voi olla sisäisiä (private) ja osa julkisia (public).
Sisäisiä tietoja voidaan käsitellä vain metodien avulla.
Kompleksit oliot
Kompleksi olio voi olla rakenteeton tai rakenteellinen tai rakenteeton (unstructured). Kompleksi
olio on esimerkiksi bittikarttana esitettävä kuva. Rakenteinen (structured) kompleksi olio
muodostetaan yksinkertaisemmmista olioista.
Laajennettavuus
Oliomallia voidaan laajentaa uusilla tietotyypeillä ja operaatioilla jo olemassaolevien (built-in)
tyyppien lisäksi.
Periytyminen (inheritance)
Luokat muodostavat hierarkian, jossa aliluokat perivät yliluokkiensa ominaisuudet.
Aliluokille voidaan määritellä lisäominaisuuksia.
Moniperinnässä (multiple inheritance)
Aliluokalla on useampia yliluokkia, joilta se voi periä ominaisuuksia.
Syrjäyttäminen (override), kuormittaminen (overloading) ja myöhäinen (dynaaminen)
sidonta (late binding)
Määritellään jokin operaatio luokkahierarkian ylimmällä tasolla.
Aliluokassa määritellään sama operaatio uudelleen eli syrjäytetään yliluokan määrittely.
Yksi operaatio voi siis osoittaa useampaan eri ohjelmaan (kuormittaminen). Vasta ajonaikana
ratkeaa, minkä aliluokan määrityksen mukaan operaatio suoritetaan (myöhäinen sidonta).
Olio-relaatiomalli
Sybasen Adaptive server on ns. olio-relaatiotietokanta, joka tukee suoraan Java-kielen olioiden
sijoittamista tietokantaan.
Lisätään tyontekijat tauluun uusi työntekija, jonka osoitteena on Java-luokan Osoite esiintymä.
INSERT INTO tyontekijat(ID, nimi, Osoite)
VALUES (1235, 'Kalle Kehveli',
new Osoite ('piilokuja 13', '11111 mörskäkylä', 'Suomi')
Lisätään tyontekijat-tauluun uusi työntekijä, jonka osoitteena on Java-luokasta Osoite perityn
SuomOsoite-luokan esiintymä.
INSERT INTO tyontekijat (ID, nimi, osoite)
VALUES (1235, 'Ville Kehveli',
new SuomOsoite('Piilokuja 14', '11111 Mörskäkylä')
Etsitään työntekijät, joiden katuosoite on Piilokuja 14.
SELECT name
FROM tyontekijat
WHERE Osoite.katu = 'Piilokuja 14'
37
Open Database Connectivity (ODBC) ja OLE DB
ODBC on rajapinta SQL-sovellusten ohjelmointiin Windows-ympäristöissä. OLE DB on rajapinta
mihin tahansa tietoon. Sovellus käyttää ODBC:n standardoituja funktioita, jotka tulkitsevat SQLkomennot tietokannan ymmärtämään muotoon. Sovelluksen ei tarvitse tukea erikseen mitään tiettyä
tietokantasovellusta. Java Database Connectivity (JDBC): Java-ohjelmien käyttöön tarkoitettu
standardoitu tietokantaliittymärajapinta. JDBC on puhtaasti oliopohjainen.
ActiveX Data Objects -mallin yleiskäyttöiset luokat:
Connection - luo yhteyden tietokantaan
Command - käytetään kyselyjen suorittamiseen
Recordset - tallettaa kyselyjen tulokset
Oliotietokannat ja OQL
OQL on SQL- tyylinen kieli tukien olioiden helppoa hakua.
- vuorovaikutteiset ennakoimattomat (ad hoc) kyselyt ja tulkin käyttö kyselyihin
-upotettujen kyselyiden yksinkertainen ohjelmointi ja C++ - määrittelyt käyvät suoraan OQLkielelle.
- optimoinnin käyttö kyselyihin: voidaan käyttää relaatiotietokannoissa käytettyä
optimointitekniikkaa.
- looginen/fyysinen riippumattomuus
- OQL-kyselyä voidaan tehostaa fyysisen tason parannuksilla, esim. indeksit.
- Korkeamman tason rakenteet: OQL kuten SQL tukee lajittelua, ryhmittelyä, koostamista.
- SQL kaltaisuus: helpottaa oppimista.
- uusien piirteiden tuki: oliotietokantojen palveluun ominaisuuksia, kuten näkymät, liipaisimet,
eheysrajoitukset.
- Myös SQL- kyselykieltä on kehitetty olioperiaatteita paremmin vastaavaiksi.
- SQL3- versiosta on kehitetty uutta standardia 2000-luvun aikana. SQL3:n osajoukko tunnetaan
myös nimellä SQL:99.
1
38
Oliosuuntautuneet tietokannat
2
Mahdollistavat monimutkaisia, sisäkkäisiä ja dynaamisesti muuttuvia rakenteita.
Tarjoavat kyselyn tueksi vapaavalintaisia (monimutkaisiakin) operaatioita, joita käyttäjät
voivat itse määritellä (vrt. select, project, join SQLssä). Oliokannat mahdollistavat erityyppisten,
usein yhdessä käsiteltävien olioiden tallentamisen fyysisesti lähelle toisiaan. Fyysinen läheisyys ja
välimuistin käyttö vähentää levyn I/O:ta ja nopeuttaa tiedon saantia. Kaikkiin kantoihin luodaan
sovelluksen tarvitsemista luokista malli (schema), jonka perusteella kanta osaa tallettaa oliot. Malli
esittelee myös luokkien väliset suhteet eli periytymiset, koosteet ja assosiaatiot.
Milloin kannattaa käyttää oliotietokantaa?
Jos relaatiokannassa taulujen määrä kasvaa räjähdysmäisesti, niin se viittaa siihen, että rakenne on
liian monimutkainen tauluilla hallittavaksi.Jos ilmenee monimutkaisten liitosten tarvetta. Jos
liitoksissa on tauluja 3 tai enemmän, niiden suorittaminen hidastuu. Jos sovelluksessa käytetään
olioteknologiaa. Oliokannan käyttö muiden oliomenetelmien (kuvausmenetelmien & koodin)
kanssa vähentää yhteensovittamistarvetta (impedance mismatch).
Jos talletettava tieto on monimutkaista, kuvia, ääntä, videokuvaa, muuttuvan kokoisia rakenteita.
Tieto on lähellä tarvitsijaansa. Oliokantoja mainostetaan hyvänä ratkaisuna hajautetuille ratkaisuille
Tietokanta-arkkitehtuuri:
Palvelin:
- hoitaa I/O:n levylle, jossa kanta sijaitsee
- hoitaa transaktioiden hallinnan
- kommunikoi toisten palvelimien kanssa lukituksesta
- tutkii lisensoinnin
- hoitaa on-line varmistustoiminnot
- huolehtii automaattisesta toipumisesta
- korkeintaan yksi palvelin-prosessi yhdessä koneessa (voi olla useita kantoja)
- tietohakemiston valvoja
- hoitaa nimipalvelut
Asiakas (client):
- kirjasto, joka on linkattu sovellukseen hoitaa muistiosoitteet ObjectStoren varaamassa
välimuistissa
- varaa ja vapauttaa tilaa pysyville olioille
- ylläpitää välimuistia äskettäin käytetyistä olioista
- kommunikoi välimuistin valvojan kanssa lukituksista
- lähettää vahvistettujen transaktioiden muuttamat tiedot palvelimelle
- voi olla useita samassa koneessa
Välimuistin valvoja:
- hoitaa asynkroniset lukituspyynnät palvelimelle (asiakas huolehtii synkronisista)
- vain yksi prosessi yhdessä koneessa
- vähentää verkkoliikennettä asiakkaan ja palvelimen välillä
Olion identiteetti, olion rakenne ja tyypin rakentajat
Jokaisella tietokantaan talletetulla oliolla on järjestelmän generoima yksilöllinen tunniste (object
identifier, OID). OID:n perusominaisuuksia ovat muuttumattomuus (immutable) ja ainutkertaisuus
39
(jokainen OID on käytössä vain kerran). Olisi myös suositeltavaa, että OID ei olisi fyysisen
muistipaikan osoite, mutta tästä on jouduttu luopumaan joissakin toteutuksissa (tehokkuussyistä).
14
Mutkikkaan olion rakenne voidaan määritellä tyypin rakentajien (type constructors) avulla, joita
ovat esim. joukko, monikko, lista, taulukko, säkki (bag). Olio esitetään kolmikon (i,c,v) avulla,
missä i vastaa OIDtä, c on rakentaja ja v esittää olion arvon (tilan). Tähän perustuen voidaan
päätellä esim. että jos c on jakamaton alkio, niin arvo v on atominen, jos c on joukko, niin v on
joukko olioiden tunnisteita {i1, ... in}, OIDtä. Samanlaisuus määritellään joko tiukan identtisillä
arvoilla (samat OIDt eri tasoilla) tai pelkästään samanlaisina arvoina.
Kapselointi
Kapseloinnin juuret löytyvät abstrakteista tietotyypeistä ja informaation kätkemisperiaatteesta.
PKapselointia on aiemmin käytetty esim. oliokeskeisissä ohjelmointikielissä. Erotetaan olion
ulkopuolelle (käyttäjille) näkyvät ja sallitut toiminnot (interface) ja muille näkymätön toteutus
(implementation) eli sisäinen tietorakenne ja tämän rakenteen käsittely (methods).
Tietokantasovelluksissa ei noudateta täydellistä kapselointia vaan esitellään sekä näkyviä (niihin
voidaan kohdistaa kyselyjä) että piilotettuja attribuutteja.
Ulottuvuus
Oliot voivat olla pysyviä (persistent) tai tilapäisiä (transient). Pysyvät oliot talletetaan tietokantaan,
josta ne voidaan hakea nimen avulla tai siihen ulotutaan jonkin toisen pysyvän olion kautta. Olion A
sanotaan ulottuvan (reachable) olioon B, jos oliograafissa esitetään viite oliosta A olioon B.
Oliotietokantojen eräs eroavuus esim. relaatiotietokantoihin tulee luokkamäärittelyjen ja pysyvien
olioiden kokoelmien erottamisesta toisistaan. Oliotietokannoissa esitellään luokat ja erikseen esim.
joukko- tai listarakenteen avulla määritellään pysyvät kokoelmat (extents), joihin oliot sitten
talletetaan.
Tyyppi- ja luokkahierarkiat
Oliotietokannat perustuvat tyyppi- tai luokkahierarkioiden käyttöön ja perintään. Vaikka ne ovat
käsitteellisesti erilaisia, ne johtavat samanlaiseen lopputulokseen. Uusia tyyppejä voidaan määritellä
olemassaolevien perusteella, tämä johtaa tyyppihierarkioiden käyttöön. PTyyppi määritellään
nimen, attribuuttien ja toimintojen avulla. Attribuutit ja operaatiot voidaan myös käsitellä yhtenä
kokonaisuutena,
funktiona.
Alityyppi/supertyyppi
määrittelyillä
saadaan
rakennettua
tyyppihierarkioita ja voidaan toteuttaa periytyminen. Useimmissa oliotietokannoissa
luokkahierarkia vastaa tyyppihierarkiaa, jolloin kaikki saman luokan oliot ovat samaa tyyppiä.
Tilanvaraus luokan olioiden talletukselle tehdään extent määreen avulla.Pysyvät (persistent) luokat
talletetaan tietokantaan (persistent collection) ja väliaikaisia (transient) luokkia käytetään esim.
kyselyjen yhteydessä (transient collection).
Mutkikkaat oliot
Mutkikkaat oliot voivat olla rakenteellisia tai rakenteettomia. PRakenteelliset muodostetaan
tyyppien rakentajien avulla. Rakenteettomia käytetään esim. kuvien ja suurten tekstimuotoisten
olioiden esitykseen.
Rakenteettomat mutkikkaat oliot
Rakenteettomat mutkikkaat oliot tunnetaan myös termeillä BLOB (binary large objects) ja
CLOB (character large object). Tietokannan hallintajärjestelmä ei tunne niiden rakennetta,
ainoastaan sovellusohjelma voi tulkita olion tarkoituksen. Suuruudesta johtuen olio joudutaan
hakemaan tietokannasta paloittain käsiteltäväksi.
40
Rakenteelliset mutkikkaat oliot
Rakenteelliset mutkikkaat oliot ovat tietokannan hallinnassa ja siten myös monien sovellusten
käytettävissä. Mutkikkaan olion komponenttien välillä tunnetaan omistajuus ja viiteyhteyksiä.
Omistajuus vastaa is-part-of/is-component-of yhteyttä ja viiteyhteys is-associated-with yhteyttä.
ODMG:n määrittelemä JDO (Java Data Objects) rajapinta
tukee myös läpinäkyvää pysyvyyttä (transparent persistence): etsitään sovelluksessa käsiteltävään
olioon liitoksissa olevat oliot ilman erityistä kyselyä välimuistiin hävittää rajan pysyvien ja
tilapäisten olioiden välillä POODBMS käyttää ryvästystä tehostamaan rakenteellisen mutkikkaan
olion hakuun levyltä
Muita oliokäsitteitä
Polymorfismi (monimuotoisuus) tarkoittaa operaatioiden kuormitusta. Tällöin saman operaation
toiminta on räätälöity eri tyyppisille olioille. Monimuotoisuuteen liittyy myös aikainen tai
myöhäinen sidonta, eli metodin toiminta sidotaan käännös- tai ajoaikana.
Moniperintä johtaa verkko tai ristikko (lattice) rakenteisiin. Valikoivalla perinnällä
alityyppi ottaa käyttöön vain osan supertyypin ominaisuuksista. Versioita ja konfiguraatioita
tarvitaan esim. ohjelmistotuotantoa palvelevissa oliototeutuksissa. Samasta vaihetuotteesta/
moduulista on olemassa useita versioita ja ohjelmistokonfiguraatio on koottu sopivista
vaihetuote-/moduuliversioista.
Oliotietokantastandardit
Standardien kehittely alkoi vuonna 1990 manifestien esittämisellä. Atkinson et al. esittivät "The
Object-Oriented Database System Manifesto" ehdotuksen ja jatkoa seurasi ODMG-93 standardin
muodossa, jossa määriteltiin esim. 1-N ja N-M yhteyksien toteutus inverse määrittelyllä ja
oliokyselykieli OQL. ODMG standardin versio 2.0 julkaistiin vuonna1997 ja versio 3.0 vuonna
2000.
The Object-Oriented Database System Manifesto
(Atkinson, Banchilon, DeWitt, Dittrich, Maier, Zdonik)
Säännöt: (1 - 13 oliosuuntautuneisuuden painotus)
1. Kompleksisten olioiden tuki (sets, bags, lists, arrays)
2. Olion ainutkertaisuuden tuki (identical/ equal)
3. Olioiden kapselointi (specification/implementation)
4. Tyyppi- tai luokkatuki (set of types/classes)
5. Luokkien tai tyyppien periytyvyys
6. Korvaus, kuormitus ja myöhäinen sitoutuvuus
7. Laskennallinen täydellisyys (computable function must be expressible)
8. Laajennettavuus (system-defined/ user defined types)
9. Tiedon pysyvyys (persistence)
10. Suurten tietokantojen hallinta (indexing, acccess path selection, query optimization)
11. Samanaikaisten käyttäjien salliminen (serializable access)
12. Elpyminen laitteisto- ja ohjelmistovirheistä
13. Ennakoimattomat kyselyt (ad hoc queries)
The Object-Oriented Database System Manifesto
Lisäpiirteet
1.Moniperiytyvyys
2. Tyyppien tarkistus ja tyyppien päättely
3. Hajautus
4. Suunnittelutransaktiot
5. Versiot
41
ODMG oliomallin komponentit
Oliot ja literaalit
Oliolla on yksilöiva tunnista (oid) ja tila (tai nykyinen arvo), se määritellään neljän ominaisuuden
perusteella:
• Yksilöivä tunniste
• Nimi; olioon voidaan viitata pysyvän nimen avulla
• Elinaika; pysyvä tai tilapäinen
• Rakenne; atominen (voi olla myös rakenteinen) tai kokoelma
Literaali esittää vakioarvoa; sillä ei ole tunnistetta ja se voi olla
• Atominen (Long, Short, Unsigned Long, Unsigned Short, Float, Double, Boolean, Char, Enum,
…)
• Rakenteinen (Date, Interval, Time, Timestamp, Struct,…)
• Kokoelma (SET, BAG, LIST, ARRAY, DICTIONARY,…)
ODMG oliomalli käyttää interface määrittelyä class ja type määrittelyjen sijaan kokoelmaolion
esittelyyn. Vastaa abstraktin luokan käsitettä.
OQL
OQL on SQL tyylinen kieli tukien olioiden helppoa hakua, vuorovaikutteiset, ennakoimattomat (ad
hoc) kyselyt.
• tulkin käyttö kyselyihin
Upotettujen kyselyiden yksinkertainen ohjelmointi
• C++ määrittelyt käyvät suoraan OQL kielelle, optimoinnin käyttö kyselyihin.
• voidaan käyttää relaatiotietokannoissa käytettyä optimointitekniikkaa.
- looginen/fyysinen riippumattomuus
• OQL kyselyä voidaan tehostaa fyysisen tason
parannuksilla, esim indeksit
korkeamman tason rakenteet
• OQL kuten SQL tukee lajittelua, ryhmittelyä,
koostamista
SQL kaltaisuus
• helpottaa oppimista
uusien piirteiden tuki
• oliotietokantojen palveluun ominaisuuksia, kuten näkymät, liipasimet, eheysrajoitukset
Myös SQL kyselykieltä on kehitetty olioperiaatteita paremmin vastaavaksi.
PSQL-3 versiosta on kehitetty uutta standardia 2000
luvun aikana. SQL-3:n osajoukko tunnetaan myös nimellä SQL:99.
SQL-3 (SQL:99)
Jo SQL-2 tarjosi seuraavat laajennukset: liipasin/herätinkäsitteen (trigger) eheyden tarkistuksen
tueksi, Grant ja Revoke komennot käyttöoikeuksien määrittelyyn, kehittyneemmät
kyselymahdollisuudet, kuten rekursion käyttö, "for all" ja "for some" predikaatit, lisäyksiä liitoksen
käyttöön Row-tyypin monimutkaisille rakenteille. Uudet itsemääritellyt tietotyypit , Boolean arvot
ja Large Objects (LOB) suurten muistiolioiden talletukseen. SQL-3 määrittely jatkaa tästä ja uusina
piirteinä ovat:
SQL/PSM (Persistent Stored Modules) ominaisuudet
• kielen laajennukset, esim. lausekielten yleiset ohjausrakenteet
• ulkoisten proseduurien käyttö
42
• talletetut proseduurit
Uudet tietotyypit (Row & ADT)
Liipasimet/herättimet
TIETOKANTASUUNNITTELUN PERUSTEET
Alla olevat ohjeet soveltuvat tietokannan suunnittelulle millä tahansa välineellä.
Hyvä suunnittelu vie aikaa, mutta vähintäänkin sama aika säästyy tietokannan toteutusvaiheessa.
Suunnittelussa huomioitavaa:
1. Minkälainen tietokanta
-- minkälaisia tietoja halutaan tallentaa
2. Tietokannan sisäinen rakenne
-- mitä tauluja tarvitaan?
-- mitkä tiedot tallennetaan mihinkin tauluun?
-- taulujen avainkentät?
-- tieto on tallennettuna vain yhdessä paikassa.
TIETOKANNAN SUUNNITTELU
Hyvin suunniteltu on puoliksi tehty.
Hyva suunnittelu vie aikaa, mutta vahintaan sama aika yleensa saastyy tietokannan
toteutusvaiheessa.
Suunnittelussa huomioitavaa
1. Minkalainen tietokanta .
Mita tietoja halutaan tallentaa?
2. Tietokannan sisainen rakenne .
Mita tauluja tarvitaan?
. Mitka tiedot tallennetaan mihinkin tauluihin?
. Taulujen avainkentat?
. Tieto on tallennettuna vain yhdessa paikassa.
3. Taulujen valiset yhteydet eli suhteet.
Mahdollisia: yhden suhde yhteen, yhden suhde moneen ja monen suhde moneen. . Kaytannössa
taulut rakennetaan yhden suhde yhteen ja yhden suhde moneen -suhteilla.
4. Kyselyt.
Mita tietoja tarvitaan .
Mista tauluista tiedot saadaan?
Missa jarjestyksessa tiedot halutaan?
5. Lomakkeet .
Mitka tiedot muodostavat yhdessa katsottaviaja paivitettavia kokonaisuuksia ?
6. Raportit.
Mita tietoja tarvitaan ja mista tauluista?
Miten tiedot muotoillaan?
Mita summatietoja halutaan?
Mita vakiotietoja raportille halutaan?
43
Tietokannan suunnittelussa ja toteutuksessa on seuraavat vaiheet:
a) tietokannan tarkoituksen miettiminen (ER-mallinnus)
Tietokannan loogisen rakenteen lisäksi pitää määritellä, mitä lopputuloksia esim raportteja,
kyselyjä, tilastoja tietokannasta halutaan tulostaa. Nämä asiat määräävät sen, mitä tietoja
tietokannassa pitää olla
b) tietokannan relaatiot eli taulut
Tyypillisesti tietokanta muodostuu "aihekohtaisista" tauluista. Taulujako ei ole itsestään selvä asia.
Tavoitteena on, että kukin tieto on tietokannassa vain kertaalleen. Tyypillisiä tauluja ovat
yritysmaailmassa: asiakaskunta, henkilöstö, tuotteet, tilaukset, toimitukset.
c) taulujen sarakkeiden eli tietojen määrittely
Kunkin taulun sisältö suunnitellaan yksityiskohtaisesti kenttä kentältä. Tietenkin tietokantaan
kannattaa kerätä vain tarpeellisia tietoja eli sellaisia, joita käytetään raporteissa tai tilastoissa.
Kustakin kentästä on määriteltävä ainakin nimi, kentän pituus ja tiedon tyyppi.
d) liitäntöjen eli yhteyksien määrittely
Relaatiokannassa taulut voidaan liittää toisiinsa. Liittäminen tarkoittaa sitä, että jossain taulussa
esiintyvä tieto esim hetu-tunnus on myös toisessa taulussa, jolloin tämän yhteisen tiedon avulla
taulujen vastinrivit voidaan liittää toisiinsa.
e) em. vaiheiden jälkeen kannattanee vielä kerran katsoa suunnittelun tulosta ja vasta sitten
käydä tekemään muunnosta relaatiomalliin
f) ennen lopullista käyttöönottoa tietokantaa on vielä testattava
Tietokannan määrittely
Tietotyypit ja ominaisuudet
Tietotyyyppi
koko
muoto
desim
syöttöraj
otsikko
oletus
kelpois
Kelp kuv
Pakoll ?
Tyhjät ?
Indeks ?
teksti
x
x
x
x
x
x
x
x
x
x
memo
x
x
x
x
x
x
X
luku
x
x
x
x
x
x
x
x
x
aika
raha
x
x
x
x
x
x
x
x
X
x
X
X
X
X
x
x
x
laskuri
X
X
X
X
x
Muoto: miltä tieto näyttää ruudulla; tämä liittyy lähinnä lukuihin ja päiväyksiin sekä kellonaikoihin
luvut
yleinen (general) esim 123,567
valuutta (currency) esim 123,55
vakio
23 345 567,567 123
prosentti
123,00%
päiväys: esim ddmmyyyy 24121998; esim. yleinen (general) 12/31/2014
keskipitkä (medium) 31-jou-14
44
Syöttörajoite (input mask):
tällä ohjataan syötettävän tiedon pituutta ja muotoa. Jos ajatellaan esim postinumero-kenttää, niin
siinä syöttörajoite voisi olla 00000, mikä tarkoittaa, että pitää syöttää 5 kpl numeromerkkejä
(pakko); jos ajatellaan henkilötunnusta, niin siinä syöttörajoite voisi olla 000000\-000A
eli ensin 6 numeroa pakollisena, sitten tulee väliviiva, sitten kolme numeroa pakollisena
ja sitten pakollisena kirjain tai numero.
valikoimassa on mm.
numeromerkki 0..9 pakollinen
numero tai välilyönti, ei pakollinen
# numero tai välilyönti, ei pakollinen, etumerkit + ja - sallittuja
L kirjain, pakollinen
? kirjain, ei pakollinen
A kirjain tai numero, pakollinen
a kirjain tai numero, ei pakollinen
& mikä tahansa merkki tai väli, pakollinen
C mikä tahansa merkki tai väli, ei pakollinen
\ seuraava merkki tulee näkyviin vakiona
< aiheuttaa merkin muuttumisen pieneksi
> aiheuttaa merkin muuttumisen suureksi
Tässä on esimerkki tilausraportin lopputuloksesta ja määrittelyistä:
Raportti perustuu kyselyyn, jossa on yhdistettynä tiedot kolmesta taulusta: tilaus, asiakas ja tuote.
Kysely on SQL-muodossa seuraava:
SELECT asiakas.asnimi, tuote.tuotenimi, tilaus.tilmaara, [tuotehinta]*[tilmaara] AS veloitus
FROM (asiakas INNER JOIN tilaus ON asiakas.ansro = tilaus.tilasnro) INNER JOIN tuote ON
tilaus.tiltuotenro = tuote.tuotenro;
45
Uutta 2015 luentomateriaalia:
Tietokannan turvallisuus
Tietoturvallisuus
Tietokannan turvallisuus liittyy yleiseen tietoturvallisuuteen, johon puolestaan liittyy paljon
peruskäsitteitä. Yleisesti hyväksytty ja paljon käytetty tietoturvallisuuden määritelmä on
seuraavanlainen:
”Tietoturvallisuus (tietoturva) on tietojen, järjestelmien ja palveluiden asianmukaista suojaamista
sekä normaali- että poikkeusoloissa lainsäädännön ja muiden toimenpiteiden avulla. Tietojen
luottamuksellisuutta, eheyttä ja käytettävyyttä suojataan laitteisto- ja ohjelmistovikojen,
luonnontapahtumien tai tahallisten, tuottamuksellisten ja tapaturmaisten inhimillisten tekojen
aiheuttamilta uhkilta ja vahingoilta.”
1. Saatavuus: (käytettävyys): Järjestelmien tiedot ovat tarvittaessa niihin oikeutettujen
käytettävissä.
2. Eheys: Tiedot ja järjestelmät ovat luotettavia, oikeellisia ja ajantasaisia, eivätkä ne ole
laitteisto- ja ohjelmistovikojen, luonnontapahtumien tai oikeudettoman inhimillisen
toiminnan seurauksena muuttuneet virheellisiksi.
3. Luottamuksellisuus: Tiedot ovat vain niiden käyttöön oikeutettujen saatavissa eikä niitä
paljasteta tai muuten saateta sivullisten käyttöön.
4. Aitous: Ominaisuus, joka ilmentää tiedon eheyttä ja sitä, että tiedon alkuperäinen lähde on
se, joka sen väitetään olevan. Alkuperäisyys-sanaa käytetään toisinaan samassa
merkityksessä kuin aitous-termiä. (Sanastokeskus TSK 2004).
46
Sanastokeskus on koonnut tietoturvaan liittyvää sanastoa ja käsitteitä (kuva1) käsitekartan
muodossa.
Kuva 1. Tietoturvan käsitteitä (Sanastokeskus TSK 2004).
Tietoturvan päämäärät ja periaatteet määritellään yrityksen tietoturvapolitiikassa. Tietokantoihin ja
niiden suunnitteluun rakentamiseen ja käyttöön liittyy monia tiedon suojaukseen liittyviä
aihealueita. Valtionhallinnon tietoturvallisuuden johtoryhmän VAHTI: n sivuilla kerrotaan heidän
sivustojen olevansa yksi maailman kattavimmista yleisistä tietoturvaohjeistoista. Sivuston
(Valtiovarainministeriö 2009) mukaan ohjeisto kattaa tietoturvallisuuden kaikki osa-alueet:
•
•
•
•
•
•
•
•
Fyysinen turvallisuus
Hallinnollinen tietoturvallisuus
Henkilöstöturvallisuus
Käyttöturvallisuus
Laitteistoturvallisuus
Ohjelmistoturvallisuus
Tietoaineistoturvallisuus
Tietoliikenneturvallisuus
Tietokannat tietoineen ovat tietoaineistoa joka on kaiken tietoturvallisuuden keskellä (kuva 2).
47
Kuva 2. Tietoaineistojen turvallisuus on kaikkien tietoturvan kerrosten ytimenä. (Suomen
Automaatioseura 2010).
Tiedon turvaamiseen liittyy monia eri tasoja joiden pitää tietokannan turvallisuuden lisäksi olla
kunnossa. Tietokantoja lähinnä ovat tietokantoja käyttävät ohjelmistot.
Sovellusten turvallisuus
Tietokannan varsinaiseen käyttöön tarvitaan siis yleensä erillinen ohjelmisto (kuva 3), ennen kuin
käyttäjät pääsevät tietokantaan käsiksi (Viope 2014). Ohjelmistoa kutsutaan tietokannan
hallintajärjestelmäksi (TKHJ). Kuva 3. Tietokannan käyttö (Laine 2010) (alla).
48
Tietokantaa käytetään tietokannan hallintajärjestelmän avulla. Käyttäjät voivat suorittaa
operaatioita, kuten kyselyjä, suoraan tietokantaan tai sitä käyttävien sovellusohjelmien välityksellä.
(Laine 2010)
Tietokantojen huolellisen suunnittelun lisäksi myös tietokantoja käyttävien sovellusten suunnittelun
eri vaiheissa on kartoitettava mahdolliset tietoturvariskit ja keinot joilla riskejä ehkäistään. Hyvä
ohje
on
että
huomioidaan
kehitettävän
sovelluksen
kriittisyys
liiketoiminnalle.(Valtiovarainministeriö 2013.)
Kansainvälinen OWASP (Open Web Application Security Project) -yhteisö julkaisee listaa
kymmenestä yleisimmästä sovellushaavoittuvuustyypistä Yleisin ohjelmistojen uhka on injektio,
jossa käytetään sovellusten tietoturva-aukkoja hyväksi järjestelmiin tunkeutumisessa.
Saatavuus
Hyvin tavallista on että esimerkiksi verkkopankit ilmoittavat silloin tällöin että toiminnoissa on
huolto- tai käyttökatkos jolloin pankkipalvelut ovat pois käytöstä tai korkeintaan käytettävissä
varayhteyden kautta. Pankkitietojen saatavuus on tällöin kärsinyt. Yleisesti huolto ja
käyttökatkokset, jos mahdollista, olisi hyvä ajoittaa sellaiseen ajankohtaan kun liikenne on
hiljaisinta.
Tietokantojen suorituskyky takaa omalta osaltaan sen että tietokantojen tiedot ovat nopeasti ja
tehokkaasti niiden käyttäjien saatavilla, joilla on oikeus tietoja käyttää. Suorituskykyyn vaikuttaa
tietokannan suunnittelun lisäksi tietokantaa käyttävän sovelluksen optimointi niin että se käyttää
tietokantaa tehokkaasti. Käytettävällä levyjärjestelmällä voidaan myös vaikuttaa nopeuteen ja
vikasietoisuuteen. Tietokantojen yhteydessä on usein käytetty RAID-levyjärjestelmää (Redundant
Array of Inexpensive Disks). Lisäksi suorituskykyyn vaikuttaa tietokantapalvelimen prosessoriteho
sekä muistin määrä ja käytettävä yhteys. Saatavuuden kannalta on tärkeää varmistaa tiedot
varmuuskopioinnilla.(Nousiainen 2002; Kurtti 2010)
Eheys
Tietokantojen suunnittelussa pitää ottaa huomioon tietojen eheys. Tietokantojen eheyssäännöistä on
kurssimonisteen kohdassa ”tietokantojen suunnittelu” aiheesta lisää. Tietojen eheys saattaa
vaarantua jos tietueita poistetaan tai lisätään ilman että tiedetään mitä ollaan tekemässä. Muutoksia
49
voidaan haluta tehdä myös vahingoittamistarkoituksella. Käyttöoikeuksilla voidaan osittain estää
normikäyttäjien tekemät virheet tietokantojen rakenteiden muuttamisessa.
Laitteisiin tai ohjelmiin voi tulla vikoja ja esimerkiksi sähkökatkokset voivat aiheuttaa sen että
tiedot eivät ole enää eheitä tai ristiriidattomia. Varmuuskopioinnilla, lokitiedostoilla sekä
mahdollisuudella tehtyjen muutosten peruuttamiseen voidaan tarvittaessa palauttaa tietokanta
takaisin ehjään tilaan.
Yleisesti käytetty eheysmekanismi on kaksivaiheinen päivitys: aikomus ja päätös ('intent &
commitment'). Ensimmäisen vaiheen eli aikomuksen jälkeen tarvitaan vielä päätös ennen kuin
muutokset vahvistuvat. (Helenius 2010)
Luottamuksellisuus
Tiedot ovat vain niiden käyttöön oikeutettujen saatavissa eikä niitä paljasteta tai muuten saateta
sivullisten käyttöön. Autentikointi (todennus) varmistaa, että vain sallitut käyttäjät pääsevät
järjestelmään.
Perinteistä
pelkän
käyttäjätunnuksen
ja
siihen
liittyvän
salasana
avulla
tunnistautumista pidetään heikkona tunnistautumisena ja esimerkiksi pankeissa käytetään edellisten
lisäksi
kertakäyttöistä
salasanaa,
myös
sirukortteja
ja
biometristä
tunnistusta
voidaan
käyttää.(Hämäläinen P 2005)
Käyttöoikeudet ovat keskeinen osa tietokantojen turvallisuutta. Käyttöoikeuksia voidaan myöntää
suoraan joillekin henkilöille tai oikeudet voivat liittyä rooliin (kuva 4). Rooliin sisältyy ne
käyttöoikeudet joita käyttäjät tehtävässä tarvitsevat. Roolien hallinnassa käytetään termiä RBAC
(Role-based Access Control). Etenkin suuria määriä käyttöoikeuksia myönnettäessä on helpompaa
ja nopeampaa myöntää käyttöoikeuksia tietyille käyttäjäryhmille kuin yksittäisille käyttäjille.
Käyttöoikeudet liittyvät tiedon luokitteluun johon voidaan käyttää erilaisia perusteita kuten tiedon
tärkeys tai arkaluontoisuus. ( Ferraiolo &Kuhn1992)
50
Kuva 4. Käyttöoikeuksien jako roolien mukaan. (Oracle 2005).
Tiedot voidaan myös halutessa salata mutta salauskaan ei ratkaise kaikkia tietoturvaongelmia vaan
voi puolestaan synnyttää uusia ongelmia kuten suorituskyvyn aleneminen koska salaus vaatii
yleensä paljon resursseja (Oracle 2012)
Tietokantojen uhat
Tietokantojen uhat voivat liittyä laitteisiin kuten kiintolevyjen kestävyyteen tai sähkökatkoksiin.
Suurimmat uhkat liittyvät kuitenkin käyttöoikeuksiin (taulukko 1).
Taulukko 1 Tietokantojen Top 10 uhat, 2010 ja 2013 (Imperva 2014)
51
Liiallisten (liian vahvojen) käyttöoikeuksien väärinkäyttö on yleisin tietokantojen uhka.
Käyttäjille voidaan siis myöntää sellaiset käyttöoikeudet jotka oikeuttavat muuhunkin kuin mihin
kenties tehtävät vaatisivat tai sallisivat. Näin voi käydä jos esimerkiksi tietokannan
käyttöoikeuksien määrittämisessä halutaan päästä helpolla ja annetaan yleisiä oikeuksia kaikille.
(Imperva 2014)
Vaikka käyttöoikeudet olisivat oikein määriteltyjä, voidaan oikeuksia käyttää tarkoituksella tai
vahingossa väärin.
Tietoja voidaan esimerkiksi tallettaa omalle koneelle helpottamaan tiedon
jatkokäyttöä, tai tietoa voidaan jopa myydä. (Ibid)
SQL-injektiossa hyökkääjä antaa tietokantapalvelimelle muutettuja SQL-komentoja. Hyökkäys
tapahtuu useimmiten puuttuvan tai väärin toteutetun syöttötiedon tarkistuksen kautta, ja joissain
tapauksissa tietokantaan päästään käsiksi tietokantarajapinnassa tapahtuvan tiedon vääränlaisesta
käsittelyn vuoksi. (Ibid)
Riskikartoitus on osa tietokantojen tietoturvallisuutta, organisaatioiden on mietittävä riskien
todennäköisyyttä sekä vakavuutta eri tietojen osalta. Taulukossa 2 on tietokantojen uhkiin liittyviä
ohjeita
ja
parhaita
käytäntöjä.
Taulukkoa
voidaan
käyttää
apuna
tietoturvaratkaisujen
suunnittelussa, todennäköisesti jokaisella organisaatiolla on lisäksi omia toimialaan tai johonkin
muuhun seikkaan perustuvia uniikkeja ongelmia.
52
Taulukko 2. Tietokantojen uhat sekä malliratkaisut. (Imperva 2014).
HUOM!
Lisää tietokantojen tietoturvasta löytyy kirjasta: Handbook of Database, Security Applications and
Trends (edited by Michael Gertz & Sushil Jajodia. 2008)
http://www.cse.hcmut.edu.vn/~ttqnguyet/Downloads/SIS/3_Handbook%20of%20Database%20Sec
urity%20-%20Applications%20&%20Trends%20(2008).pdf
53
Tietokannat ja tietoverkot
Tietokoneet ovat nykyisin lähes poikkeuksetta yhteydessä jonkinlaiseen tietoverkkoon. Verkko voi
olla organisaation lähiverkko jossa tietokoneet on yhdistetty toisiinsa ja ehkä lisäksi palvelimeen ja
tulostimeen. Lähiverkon kautta voi yleensä olla yhteydessä myös Internetiin (kuva 1).
Kuva 1. Lähiverkko (Tuikka 2014).
Esimerkki sisäisen verkon kautta tapahtuvalle tietokantojen käytölle voisi olla että opiskelijat
hakevat tietoa kirjastossa koulun koneiden ja tietoverkon avulla. Tietoa haetaan kirjaston omista
elektronisista aineistoista tai erilaisista tietokannoista myös yliopiston verkon ulkopuolelta voidaan
hakea ja etäkäyttää aineistoa. Puhuttaessa avoimen verkon tiedonhausta tarkoitetaan hakua
Internetistä, esimerkiksi Googlen tai Google Scholarin avulla. (Tampereen yliopisto 2013)
Tietoverkot mahdollistavat myös tietokantojen etäkäytön (kuva 2). Esimerkiksi Lappeenrannan
teknillisellä yliopistolla on ssl-vpn palvelin, johon otetaan yhteys selaimella tai VPN
asiakasohjelmalla.
SSL-protokolla (Secure Sockets Layer) salaa tietokoneen ja internetsivun
palvelimen välisen liikenteen sisällön (LUT 2007; Viestintävirasto 2014).
54
Kuva 2. VPN- etäkäyttöpalvelu (Oulun yliopisto 2013).
Yliopiston verkon ja asiakkaan laitteen välille syntyy salattu VPN-tunneli, jota pitkin kaikki
verkkoliikenne kulkee. Muualta katsottaessa näyttää siltä kuin asiakkaan laite olisi kytkettynä
yliopiston verkkoon. (Oulun yliopisto 2013)
Koska lähiverkojen kautta ollaan yhteydessä Internettiin, nousee yrityksen tai organisaation
tietoihin kohdistuva tietoturvariski huomattavasti verrattuna vain pelkän oman sisäisen verkon
riskiin. Tietoverkkoihin kytkettyjen laitteiden suojaaminen ulkopuolisista, kuin myös mahdollisesti
omasta verkosta tulevilta hyökkäyksiltä, on tärkeä osa tietoverkkojen turvallisuutta.( WebOpas
2010).
55
Tietoverkkojen ja tietokantojen rajapinnat
ODBC (Open Database Connectivity) on Microsoftin kehittämä ohjelmointirajapinta jonka avulla
muodostetaan yhteys tietokantaan (kuva 3) (Virkki 2000).
Kuva 3. Monen käyttäjän tietokantajärjestelmä (Words of Wisdom 2014).
ODBC:tä käytettäessä ei tarvitse tietää onko se kytkeytynyt Access-tietokantaan vai esimerkiksi
SQL Serveriin (kuva 4).
Java kielelle on oma JDBC (Java Datbase Connectivity) joka on
vastaavanlainen kuin ODBC, mutta toimi Java- ympäristössä. Muita tietokantayhteyden tarjoavia
palveluja on mm. OLE DB (Object Linking and Embedding, Database), ADO (ActiveX Data
Objects) (Virkki 2000).
56
Kuva 4. ODBC tarjoama rajapinta. (OpenLink Software 2014).
PHP Ja MySQL
MySQL on suosittu etenkin www-sivujen yhteydessä käytetty relaatiotietokantaohjelma.
Tietokannassa voi olla esimerkiksi verkkokaupan tuotetiedot. Toisin sanoen asiakas etäkäyttää
omalta koneeltaan käsin tietokantaa valitessaan tai katsellessaan tuotteita verkkokaupan kotisivuilla.
MySQL:n kotisivuilla mainostetaan ohjelman olevan maailman suosituimman avoimen lähdekoodin
tietokannan. Tosin MySQL:stä on olemassa myös kaupallinen versio (Laaksonen 2003).
PHP on suosittu erityisesti dynaamisten web-sivujen toteutukseen tarkoitettu ohjelmointikieli.
Dynaamisuus tarkoittaa sitä että nettisivut voivat muuttua sen mukaan miten esimerkiksi käyttäjä
hakee sivulle tietoa (kuva 5). Moodle-oppimisalustassa on käytössä PHP ja usein juuri My SQL:n
tietokannan kanssa (Laaksonen 2003).
57
Kuva 5. Tietokantapohjainen asiakas-palvelin (Tuikka 2007).
Dynaaminen sivu luodaan vasta, kun selain sitä pyytää. Selaimen hakupyyntö käynnistää
palvelinkoneella toimintoja, joiden tuloksena syntyy uusi verkkosivu. Tietokantapalvelin
tietokantoineen voi sijaita myös omalla palvelinkoneella( Tuikka 2007 ).
MySQL-tietokantaa käytetään usein PHP:llä. PDO-rajapinta (kuva 6) on PHP:ssä mukana
uusimmissa versioissa. PDO:lla voi käyttää MySQL:n lisäksi muitakin tietokantoja.
Kuva 6. PHP ja PDO- rajapinta (ZenTut 2014).
58
Hajautetut tietokannat & tietovarastointi
HAJAUTETUT TIETOKANNAT (Distributed database)
Kuten mainittua, hajautetuista tietokannoista on jo 15 luentokalvollista materiaalia. En ole aivan
varma kannattaisiko olemassa olevaan materiaaliin lisätä tavaraa, vai pikemminkin tiivistää
olemassa oleva materiaali murto-osaan nykyisestä laajuudesta. Päädyin kuitenkin lisäämään vielä
yhden kappaleen olemassa oleviin luentokalvoihin, jolloin tiivistämistä voi harkinnan mukaan
suorittaa kattavammasta materiaalista.
Komplikaatiot
Yleisesti ottaen hajautetuissa järjestelmissä tulee ottaa huomioon, että levyasemat ovat
nopeudeltaan huomattavasti kehittyneempiä, kuin vastaavasti verkkoyhteydet, jolloin päätavoitteena
hajautetuissa järjestelmissä nopeuden optimoimiseksi tulisi olla yleensä verkon kuormittamisen
minimointi. (Date, 1994, s. 605).
Seuraavaksi esiteltävät komplikaatiot eivät ole eristyksissä toisistaan, vaan vaikuttavat toinen
toisiinsa. Tietokannan suunnittelulla on ratkaiseva rooli monien mahdollisten ongelmakohtien
suunnittelussa ja ratkaisussa. (Valduriez & Özsu, 2011, s. 19).
Kuva 1. Komplikaatioiden väliset suhteet. (Valduriez & Özsu, 2011, s. 19).
59
Hajautettujen tietokantojen suunnittelussa täytyy muistaa
ottaa
huomioon
näiden
lukuisten
komplikaatioiden (kuva 1) mahdollisuus ja niiden väliset suhteet. Näitä ongelmia on muun muassa:
Hajautettujen tietokantojen suunnittelu
Perusvaihtoehdot hajautettujen tietokantojen tiedon sijoittamisen suunnittelussa on ositettu tai
monistettu. Kaksi perustavaa laatua olevaa suunnittelun haastetta on sirpaloituminen ja hajautus.
Sirpaloitumisella tarkoitetaan sitä, miten tietokanta ositetaan näiksi sirpaleiksi ja hajautuksella
puolestaan tarkoitetaan sitä, miten nämä sirpaleet hajautetaan optimaalisesti. Tätä ongelmaa
tutkitaan matemaattisella mallintamisella, jonka tarkoituksena on optimoida tietokannan
varastointikustannukset, prosessointitransaktiot ja viestin välityksen sivustojen välillä. (Valduriez
Özsu, 2011, s. 17).
Hajautettu hakemistojen hallinta
Hakemisto sisältää informaatiota, kuten kuvailua tai paikkatietoja, datasta tietokannassa. Haasteita
on muun muassa siinä, miksi ja kuinka tätä tietoa tulisi sirpaloida. Hakemisto voi olla globaali tai
lokaali, se voidaan myös keskittää yhdelle sivustolle tai hajauttaa useille. (Valduriez & Özsu, 2011,
s. 17).
Hajautettu kyselyn prosessointi
Kyselyn prosessointi käsittelee algoritmit, jotka analysoivat kyselyt ja kääntävät ne datan
muokkausoperaatioiksi. Ongelmana on optimoida kyselyt mahdollisimman kustannustehokkaiksi
tätä varten luodun strategian mukaisesti. Huomioonotettavia faktoreita on tiedon hajautuksen määrä,
yhteydenpitokustannus ja tarpeellisen lokaalisti saatavilla olevan informaation puute. (Valduriez &
Özsu, 2011, s. 17).
Hajautettu samanaikaisuuden hallinta
Samanaikaisuuden hallinta sisältää hajautetun tietokannan sisäänpääsyn synkronoinnin siten, että
tietokannan eheys säilytetään. Tämä on yksi eniten tutkituista haasteista hajautetuissa
tietokannoissa. Hajautetuissa tietokannoissa ei jouduta huolehtimaan vain yksittäisen tietokannan
eheydestä, vaan myös tietokannan kopioiden eheydestä. Ongelmanratkaisuun käytetään yleensä
joko lukitusta, joka perustuu yhteiseen dataan pääsyn poissulkemiseen, tai sitten aikaleimausta,
missä toimintojen suorittamiset määrätään perustuen aikaleimoihin. Näistä perusratkaisuista on
olemassa lukuisia variaatioita, kuin myös hybridialgoritmejä, joilla pyritään yhdistämään nämä
kaksi mekanismia. (Valduriez & Özsu, 2011, s. 18).
60
Hajautettu umpikujan hallinta
Monien käyttäjien samanaikainen pyrkiminen käyttämään dataa voi johtaa umpikujaan, jos
synkronointimekanismi perustuu lukituksiin. (tästä oli esimerkkikuva luentokalvoissa, nämä
yhdistetään) (Valduriez & Özsu, 2011, s. 18).
Hajautetun tietokannan luotettavuus
Tietokannan luotettavuus ja saavutettavuus ovat hajautetun tietokannan potentiaalisia etuja, mutta
ne vaativat paljon huomiota toteutuakseen. On tärkeää, että tietokannan johdonmukaisuuteen,
virheiden havaitsemiseen ja niistä toipumiseen kiinnitetään huomiota. Virheiden johdosta
tietokannasta tulee joko käyttökelvoton tai pääsy sinne estyy. Tietokannan pitäisi pystyä myös
virhetilanteesta
elpyessään
päivittämään
ja
palauttamaan
epäonnistuneet
sivustot
toimintakuntoisiksi. (Valduriez & Özsu, 2011, s. 18).
Toistuvuus
Jos tietokanta on osittain tai kokonaan monistettu, on tärkeää toteuttaa protokollia, jotka varmistavat
monistettujen osien johdonmukaisuuden, eli että kopiot saavat samat arvot. Tämä voidaan toteuttaa
niin, että toiminto ei valmistu, ennen kuin kaikki kopiot ovat päivitettyjä tai sitten toiminto päivittää
vain yhden kopion, josta loput kopiot päivittyvät toiminnon valmistuttua. (Valduriez & Özsu, 2011,
s. 19).
61
TIETOVARASTOINTI (Data warehousing)
Tietovarastointi käsittää työkalut ja algoritmit, joiden avulla data tuodaan hajautetuista informaation
varastoista yksittäiseen varastoon, johon voidaan suorittaa datan analysointia. Viimeaikainen
kehitys tieteellisissä ja teknillisissä sovelluksissa on tuottanut valtavat määrät dataa. Tämä nopeasti
kasvava datamassa, jota tallennetaan suuriin tietokantoihin, on ylittänyt ihmisen kyvyn käsittää sitä
ilman asianmukaisia työkaluja. Tietovarastointi on tarpeellinen teknologia informaation
keräämiseen hajautetuista tietokannoista jotta sille voidaan suorittaa analyysiä (Singhal, 2007, s. 12).
Tietovarastoinnin kaupallinen hyödyllisyys on tuottaa liiketoiminnan johdolle työkaluja, joiden
avulla voi systemaattisesti organisoida, ymmärtää ja hyödyntää informaatiota strategisiin
päätöksiin. (Singhal, 2007, s. 2).
Yleinen arkkitehtuuri
Datan analysointiteknologia perustuu laajalti käytössä olevaan tietovarastointiarkkitehtuuriin. Siinä
informaatio, joka tulee useista hajautetuista ja heterogeenisista varastointijärjestelmistä,
integroidaan keskusvarastoon jota kutsutaan tietovarastoksi (data warehouse). Tätä integroitua
informaatiota analysoidaan niin sanotuilla online analyyttisella prosessoinnilla (On-Line Analytical
Processing, OLAP), kyselyillä ja datan louhintasovelluksilla, joiden tarkoituksena on:
•
Analysoida liiketoiminnan toimenpiteiden tehokkuutta
•
Löytää ja analysoida trendejä
•
Löytää anomalioita ja käyttäytymismalleja
•
Löytää riippuvuuksia
•
Ennustaa trendejä ja simuloida liiketoiminnan ratkaisuja
Tietovarastointia ja OLAP-teknologiaa käytetään yleisesti muun muassa myyntiliiketoiminnassa,
pankkialalla, pörssimarkkinoilla ja tieteessä. (Kozielski & Wrembel, 2009, s. 5).
Teknisessä mielessä tietovarasto on suuri tietokanta. Tietovaraston suuri koko, OLAP-kyselyiden ja
datanlouhinta-algoritmien monimutkaisuus sekä informaation heterogeeninen luonne aiheuttavat
suuria haasteita.
62
Näihin haasteisiin kuuluu muun muassa:
1. Tietovaraston konseptuaalinen mallinnus ja loogiset tietomallit
2. Tietovaraston lataus (päivitys)
3. OLAP-kyselyiden ja datanlouhinta-algoritmien tehokkaan suorittamisen varmistaminen
4. Materialisoituneiden näkymien hoitaminen
5. Datan analysointitekniikat
6. Metadatan käsittely
7. Tietovaraston kehittymisen hallinta
8. Striimit, reaaliaikaiset ja aktiiviset tietovarastot
9. Monimutkaisen informaation varastonti (XML, objekti, multimedia)
Tyypillisesti tietovarastoissa käytetään moniulotteista tietomallia. Siinä analysoitu informaatioon ja
kerättyihin faktoihin viitataan monilla ulottuvuuksilla, jotka luovat kontekstin analyysille. Tällaisia
moniulotteisia tiloja kutsutaan ”tietokuutioiksi”. Näitä kuutioita voidaan toteuttaa relaatio- tai
moniulotteisilla servereillä. (Kozielski & Wrembel, 2009, s. 5).
Tietovaraston ominaisuudet
Tietovaraston avainominaisuuksiin kuuluu:
1. Subjektiorientoitunut: Tietovaraston tieto on organisoitu pääsubjektien, kuten asiakkaan,
toimittajan tai myynnin mukaan ja se keskittyy mallintamaan tietoa päätöksentekoa varten.
2. Integraatio: Tietovarasto on rakennettu integroimalla monia heterogeenisiä lähteitä, kuten
RDBMS, flat-tiedostoja tai OLTP-tallenteita.
3. Aikariippuvainen: Tieto on varastoitu tuottamaan tietoa historiallisesta perspektiivistä.
(Singhal, 2007, s. 2).
63
Tietovarastoinnin uudet trendit
Tietovarastoinnista on tullut erittäin suosittua monissa yrityksissä, mutta sitä on pystytty
hyödyntämään vain melko yksinkertaisen tyyppisen informaation kanssa. Jotta voitaisiin laajentaa
tietovarastoinnin etuja, on selvitettävä Kozielskin & Wrembelin (2009, s. 2) mainitsemat viisi
yksilöllistä haastetta:
1. Fyysisen maailman tiedon tallentaminen
2. Strukturoidun,
semi-strukturoidun
ja
strukturoimattoman
datan
integroiminen
tietovarastossa
3. Menneen, nykyhetken ja tulevaisuuden integroiminen
4. Epätäydellisen tiedon varastointi
5. Yksityisyyden varmistaminen tietovarastoissa
Nykyisten teknologioiden ongelmana on, ettei tämäntyyppisten tiedostojen/mallien integroiminen ja
analysoiminen ole johdonmukaisesti mahdollista. Sen sijaan sovelluksiin pitää kehittää ad-hoc sovelluksia integroimiseen ja analysointiin. Tämä puolestaan on kallista ja virheherkkää. (Kozielski
& Wrembel, 2009, s. 2).
Yleinen perusta näiden haasteiden selättämiseen voisi olla uudenlainen datamalli, joka perustuu
moniulotteiseen ja semistrukturoituun dataan, mutta joka tukisi paljon laajempaa datamuotojen
skaalaa. Erityisesti tuen tulisi olla paikkatietoihin, sensoridataan, striimeihin, semistrukturoituun ja
strukturoimattomaan dataan ja epätäydelliseen dataan (Kozielski & Wrembel, 2009, s. 2).
64
Lähteet
Mustonen-Ollila, E. Lappeenrannan teknillinen yliopisto, tietotekniikan osasto
Pesonen, T. Lappeenrannan teknillinen korkeakoulu
Rajamäki, J. Helsingin Ammattikorkeakoulu, Tekniikka ja Liikenne
Tervonen, I. Oulun teknillinen tiedekunta.
Tikkala, A. Lappeenrannan teknillinen korkeakoulu.
http://appro.mit.jyu.fi/2002/kevat/tietokannat/harkka/malli.html
ATK-insituutti: Relaatiotietokannat, 1993
Polvinen, T. Tietokannat käytännön työssä, 1999
Jeffrey, D. Ullman, Jennifer Widom: A first course in database systems, 1997
Fred McFadden, Jeffrey Hoffer, Mary Prescott: Modern Database Management, 1999
C.J. Date: An Introduction to Database Systems, 1995
Thomas Connolly, Carolyn Begg, Anne Strachan: Database Systems, 1998
Brockschmidt, Kraig, 1995. When to Use Which OLE Technology. Microsoft Developer Relations.
http://www.microsoft.com/oledev/olemkt/oleent/whenwhat.htm.
Favorin, Tero, 1996. Internetin mullistajat. Tietokone, nro 9/1996.
Informix, 1996. Informix NewEra and OLE Integration.
http://www.informix.com/informix/corpinfo/zines/whitpprs/ole/ole.htm
Microsoft corporation, 1997. Active Server Pages FAQ.
http://www.eu.microsoft.com/iis/LearnAboutIIS/ActiveServer/faq.htm.
Microsoft corporation, 1996a. Microsoft OLE DB. http://www.eu.microsoft.com/oledb/.
Microsoft corporation, 1996b. White paper: Universal Data Access - OLE DB.
http://www.eu.microsoft.com/oledb/prodinfo/wpapers/wpapers.htm.
North, Ken, 1996. Database programming with OLE and ActiveX. DBMS, November 1996.
Oracle, 1996. Introduction to Oracle Objects.
http://www.oracle.com/support/bulletins/oo/html/1400.html
Rauch, Stephen, 1996. Talk to Any Database the COM Way Using the OLE DB Interface.
Microsoft Systems Journal July 1996.
Sun Microsystems, 1996a. Java Beans: A Component Architecture for Java.
http://splash.javasoft.com/beans/WhitePaper.html.
Sun Microsystems, 1996b. JDBC Guide: Getting Started.
http://java.sun.com/products/jdk/1.1/docs/guide/jdbc/getstart/intro.doc.html.
Tanttu, J. (2014). Tietokannat ja tietoverkot. Harjoitustyö Tietokannat-kurssille.
Peltonen, M. (2014). Hajautetut tietokannat ja tietovarastot. Harjoitustyö Tietokannat- kurssille.
Ferraiolo, David F.. & Kuhn, D. Richard. 1992. Role-Based Access Controls. Reprinted from15th
National Computer Security Conference (1992), Baltimore MD.[verkkojulkaisu]. [viitattu
14.5.2014]. Saatavissa: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf
Helenius, M. 2010. EheysTietokannassa. TWiki. [verkkojulkaisu]. [viitattu 14.5.2014]. Saatavissa:
https://jop.cs.tut.fi/twiki/bin/view/Tietoturva/EheysTietokannassa%282-A%29
Hämäläinen, P. 2010.Vahva käyttäjätunnus. Tietokone- digilehti. [viitattu 14.5.2014]. Saatavissa:
http://www.tietokone.fi/artikkelit/vahva_kayttajatunnistus
Imperva. 2014. Top Ten Database Threats.The Most Significant Risks and How to Mitigate Them.
[verkkojulkaisu]. [viitattu 14.5.2014]. Saatavissa:
http://www.imperva.com/docs/WP_TopTen_Database_Threats.pdf
Kurtti, N 2010. RAID-tekniikka. TWiki. [verkkojulkaisu]. [viitattu 14.5.2014]. Saatavissa:
https://jop.cs.tut.fi/twiki/bin/view/Tietoturva/RAID-tekniikka(2-A)
Laine H. 2010, Tietokantasovellus Tietokantaohjelmointi ja Java-tietokantaliittymä. Helsigin
yliopisto, Tietojenkäsittelytieteen laitos. [verkkojulkaisu]. [viitattu 14.5.2014].
Saatavissa:https://www.cs.helsinki.fi/u/laine/tikas/material/ohjelmointi.html
Nousiainen, A. 2002. Tietokannan suorituskyky kohdalleen. Tietokone- digilehti. [viitattu
14.5.2014]. Saatavissa: http://www.tietokone.fi/artikkelit/tietokannan_suorituskyky_kohdalleen
65
Oracle, 2012 Database Security Guide
Developing Applications Using Data Encryptio
2005. [verkkojulkaisu]. [viitattu 14.5.2014]. Saatavissa:
http://docs.oracle.com/cd/B19306_01/network.102/b14266/apdvncrp.htm#i1007112
Oracle, 2014 Database Security Guide. 2005. [verkkojulkaisu]. [viitattu 14.5.2014]. Saatavissa:
http://docs.oracle.com/cd/B19306_01/server.102/b14220/security.htm
Sanastokeskus, TSK . 2004. Tiivis Tietoturvasanasto. [verkkojulkaisu]. [viitattu 14.5.2014].
Saatavissa: http://www.tsk.fi/fi/info/TiivisTietoturvasanasto.pdf
Suomen Automaatioseura ry. 2010 Turvallisuusjaosto. Tietoturvan hallinnan periaatteet.
[verkkopainos]. [viitattu 14.5.2014] Saatavissa
https://www.cert.fi/attachments/cip/5na1SblCp/SAS29_TeollisuusautomaationTietoturva.pdf
Valtionvaraiministeriö. 2009.Hankkeen tietoturvallisuuden osa-alueet. [verkkojulkaisu]. [viitattu
14.5.2014]. Saatavissa: https://www.vahtiohje.fi/web/guest/hankkeen-tietoturvallisuuden-osa-alueet
Valtionvaraiministeriö. 2013.VAHTI 1/2013 Sovelluskehityksen tietoturvaohje. [verkkojulkaisu].
[viitattu 14.5.2014]. Saatavissa:
https://www.vahtiohje.fi/c/document_library/get_file?uuid=03c32520-f3f8-4621-b0d4ec4ca8edafb3&groupId=10128&groupId=10229
Viope 2014. Tietokannat kurssin SQL- verkkokurssi. Teoriaa. [viitattu 13.03 014}. Saatavissa:
lut.viope.com, vaatii käyttäjätunnuksen.
Date, C. J. (1994) An Introduction to Database Systems. New York. Addison-Wesley.
Valduriez, P. & Özsu, M. T. (2011) Principles of Distributed Database Systems. 3. p. New York.
Springer Science.
Kozielski, S. & Wrembel, R. (2009) New Trends in Data Warehousing and Data Analysis. New
York. Springer Science
Singhal, A. (2007) Data Warehousing and Data Mining Techniques for Cyber Security. New York.
Springer Science.
Laaksonen, A. 2003. Ohjelmointiputka. Opasarkisto: Käytännön PHP-opas: Osa 1 – Johdanto.
[verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://www.ohjelmointiputka.net/oppaat/opas.php?tunnus=phpj
LUT. 2007.Lappeenrannan teknillinen yliopisto. SSL-VPN palvelimen käyttöpolitiikka.
[verkkodokumentti]. [viitattu 19.5.2014]. Saatavissa: https://uni.lut.fi/documents/10304/442fa2667194-43b9-bdc4-0b9f0ea0d6fc
OpenLink Software. 2014. Multi-Tier ODBC Driver Architecture [verkkojulkaisu]. [viitattu
19.5.2014]. Saatavissa: http://www.openlinksw.com/
Oulun yliopisto. 2013. VPN-etäkäyttöpalvelu.[verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://www.oulu.fi/tietohallinto/verkko/vpn/vpn.jpg
Tampereen yliopisto. 2013.Nelli-Portaali.[verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://www.uta.fi/kirjasto/oppaat/tiedonhankinnanperusteet/yky/tiedonlahteet/nelli/index.html
Tuikka, T. 2007. PHP:n perusteet. [verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://batman.jamk.fi/~tuito/www_sk/phpperusteet.htm
Tuikka, T. 2014. Tietoverkot.[verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://batman.jamk.fi/~tuito/ta_ja_tjinfra/tietoverkot/tietoverkot.htm
Viestintävirasto 2014 Viestinnän salaus. [verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
https://www.viestintavirasto.fi/tietoturva/palveluidenturvallinenkaytto/viestinnansalaus.html
66
Virkki, O. 2000. Upotettu SQL. [verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa: http://myy.haagahelia.fi/~virou/TIHA/mats/TH_lu6x_ohj.pdf
WebOpas. 2010. Tietoverkkojen suojaaminen. [verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://webopas.blogspot.fi/2010/09/tietoverkkojen-suojaaminen.html
Words of Wisdom. 2014. Mitä ovat tietokannat [verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://www.wisdom.fi/site/dbms/tietokannat.html.
ZenTut 2014. ZenTut Website PHP PDO. [verkkojulkaisu]. [viitattu 19.5.2014]. Saatavissa:
http://www.zentut.com/php-pdo/