Kurssimoniste 2015 - Noppa - Lappeenrannan teknillinen yliopisto
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: [email protected] 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/
© Copyright 2024