2. Tietokannan käsitteitä ja arkkitehtuuri

1. 2. Tietokannan käsitteitä ja arkkitehtuuri • Aikaisemmin tietokannanhallintajärjestelmät olivat suuria, tiiviisti integroituja järjestelmiä. • Nykyisille TKHJ:lle on tyypillistä ns. asiakas-palvelin -arkkitehtuuri. ----> sovellusohjelmat toimivat käyttäjän omalla koneella, itse tietokanta palvelimella toisaalla. 2.1. Tietomallit, kaavat ja esiintymät • Tietomalli on kokoelma käsitteitä, joiden avulla pystytään kuvaamaan tietokannan rakennetta ( tietotyypit, rajoitukset ja tietojen väliset suhteet ). • Tarjoaa välineet tiedon abstrahointiin.

2. 2.1.1. Tietomallien eri kategoriat • Käyttäjän itsensä määrittelemiä operaatioita tietokannan datalle kuten keskiarvon laskenta jonkin tietokentän arvoille esiintyy etenkin oliokeskeisessä tietomallissa, nykyisin myös ns. objekti-relaatiomallissa, joka on relaatio- ja oliotietomallin välimuoto. • Sisältää usein myös perusoperaatiot tiedon hakua ja päivittämistä varten. • Korkean tason eli käsitteellisissätietomalleissa tietokannan rakennetta kuvataan käsittein, jotka ovat käyttäjille luontevia ymmärrettäviksi ( entiteetti, attribuutti, liittymä ). • Matalan tason eli fyysisissä tietomalleissa kuvaillaan, miten data on tallennettuna tietokoneelle. Ne on tarkoitettu lähinnä tietokannan laitteistoa lähellä oleviin ominaisuuksiin erikoistuneille asiantuntijoille, ei niinkään tavallisille loppukäyttäjille ( tietueiden talletusmuoto, järjestys, saantipolut ).

3. Näiden kahden tason 'kompromissina' voidaan nähdä ns. toteutusmalli, joka on vielä loppukäyttäjänkin hahmotettavissa, muttei samalla kuitenkaan kohtuuttoman kaukana matalan tason tiedon organisointimallista ( piilottaa osan rakenteiden yksityis-kohdista, mutta voidaan silti käyttää suoraan TKHJ:ssä; useimmat kaupalliset TKHJ:t tukevat ). • Käsitteellisissä tietomalleissa entiteetti edustaa jotain reaalimaailman kohdetta tai käsitettä ( esimerkiksi opiskelijaa ). Attribuutti tarkoittaa jotain entiteettiin kuuluvaa ominaisuutta ( esimerkiksi opiskelijan nimi ). Liittymä puolestaan kuvaa kahden tai useamman entiteetin välistä yhteyttä ( esimerkiksi kurssin numero on kurssin perustiedot ja sen luennointikerrat toisiinsa liittävä attribuutti ). • Tällä kurssilla käsiteltävän relaatiotietomallin ja yleistymässä olevan oliokeskeisen tietokantamallin lisäksi toteutusmalleihin luetaan aikaisemmat verkko- ja hierarkkinen malli, jotka tällä kurssilla sivuutetaan.

4. 2.1.2. Kaavat, esiintymät ja tietokannan tila • Kaikissa tietomalleissa itse tietokanta ja sen kuvaus pidetään erillään toisistaan. • Tietokannan kuvausta kutsutaan tietokannan kaavaksi ( database schema ). • Tietokannan kaava määritellään tietokannan suunnitteluvaiheessa, joten kaavaan odoteta tehtävän muutoksia kovin usein. • Kaavan yksittäistä objektia ( kuten yliopistoa kuvaavassa esimerkissä opiskelijaa, kurssia jne. ) kutsutaan kaavan rakenneosaksi ( schema construct ).

5. Kaavadiagrammi selvittää vain osan tietokannan kaavan sisällöstä, kuten taulujen nimet ja tietokentät sekä yksinkertaisia rajoituksia (esimerkiksi avainattribuutit). Monimutkaisia rajoituksia ei kaavadiagrammilla pystytä esittämään. • Tietokannan datasisältöä tietyllä hetkellä kutsutaan tietokannantilaksi. • Tietokanta on määrittelyn jälkeen tyhjässä tilassa ( ei vielä sisällä dataa ). • Ensimmäisen syöttövaiheen päätyttyä tietokanta on alkutilassaan. • Tehtäessä päivityksiä tietokantaan sen tila muuttuu. • Jokaisella tietokannan kaavan rakenneosalla on tietty nykyinen esiintymien joukko ( tietyssä taulussa yhtenä ajankohtana esiintyvien tietueiden sisältö ).

6. 2.2. Tietokannan hallintajärjestelmän arkkitehtuuri2.2.1. Kolmitasoarkkitehtuuri • TKHJ:n tehtävänä on huolehtia, että jokainen tietokannan tila on laillinen sille asetetut säännöt huomioon ottaen. Täten on tietokannan käyttökelpoisuuden ja virheettömyyden kannalta hyvin tärkeää, että sen määrittely tehdään huolellisesti. Tietokannan määrittelyvaiheessa ratkeaa melko lailla kannan laadukkuus. • Tietokannan kaava voidaan tulkita tietokannan sisäisenä tarkennuksena, tietokannan tila puolestaan kaavan laajennukseksi. • Sisäinen taso ( kaava ), joka kuvaa tietokannan fyysistä tallennusrakennetta ja saantipolkuja. Sisäisellä tasolla käytetään matalan tason tietomallia. • Käsitetaso, jossa kuvaillaan koko tietokannan rakenne käyttäjille fyysistä tallennusrakennetta lukuun ottamatta, eli entiteetit, tietotyypit, säännöt, taulujen väliset suhteet ja käyttäjän määrittelemät operaatiot. Tason kuvaamisessa käytetään joko korkean tai toteutustason tietomallia. ·

7. 2.2.2. Tietoriippumattomuus • Ulkoinen eli näkymätaso kuvaa sitä, millaisena kukin käyttäjäryhmä näkee tietokannan. Se sulkee ulkopuolelleen kaikki heille tarpeettomat osat, ja sen kuvaamiseksi käytetään korkean tason tietomallia. • Eri tasojen välillä käytetään kuvauksia, jotta esimerkiksi tehdyt tietokantakyselyt ja niihin saadut tulokset voidaan välittää tasolta toiselle kullekin tasolle ominaiseen esitysmuotoon. • Useimmat TKHJ:t eivät  lähinnä tehokkuussyistä  tue kahden ylimmän tason erottamista toisistaan, sillä kuvauksien suorittaminen tasojen välillä hidastuttaa tietokantaan kohdistuvien operaatioiden toteuttamista. • Varsinainen data sijaitsee aina fyysisellä tasolla. • Kolmitasoarkkitehtuuri tukee tietoriippumattomuutta. Tämä tarkoittaa sitä, että tietokannan kaavan muutos alemmalla tasolla ei aiheuta muutoksia ylemmälle tasolle. Ainoastaan tasojen välinen kuvaus muuttuu.

8. 2.3. Tietokannan kielet ja käyttöliittymät • Looginen tietoriippumattomuus tarkoittaa mahdollisuutta tehdä lisäyksiä käsitekaavaan ilman tarvetta muuttaa samalla ulkoista kaavaa tai sovellusohjelmia ( kts. esimerkkiä kirjan kuvista 1.2., 1.4. ja 1.5. ). Mikäli tietokantaa puolestaan supistetaan eli redusoidaan, muuttumattomiin rakenteisiin viittaavissa ulkoisissa näkymissä ei tapahdu muutoksia. • Fyysinen tietoriippumattomuus takaa, että fyysisten datatiedostojen uudelleenorganisointi ei aiheuta muutoksia ylemmillä tasoilla. Tämä mahdollistaa sen, että dataan voidaan lisätä esim. uusia saantipolkuja ilman, että kyselyitä tai sovellusohjelmia jouduttaisiin uusimaan. Muutos fyysisellä tasolla vaikuttaa vain operaatioiden suoritusaikaan. • Tietokannoissa voidaan käyttää erilaisia kieliä ja käyttöliittymiä eri tarkoituksiin.

9. 2.3.1. TKHJ:n kielet • Tiedonmäärittelykieli DDL ( Data Definition Language ) on tarkoitettu tietokannan kaavan määrittelyä varten. • TKHJ:hin sisältyy DDL-kääntäjä, joka muuntaa tehdyn määrityksen systeemiluettelon käyttämään muotoon. • Sisäisellä tasolla käytetään tietovaraston määrittelykieltä eli SDL:ää ( Storage Definition Language ). • Fyysisen ja käsitetason välinen kuvaus tehdään jommallakummalla kielistä DDL ja SDL. • Täydellisessä kolmitasoarkkitehtuurissa tarvittaisiin vielä näkymienmäärittelykieli VDL ( View Definition Language ) • Normaalisti käytetään kuitenkin DDL:ää sekä tiedon- että näkymienmäärittelykielenä. • Tiedon syöttöä ja tietokannan ylläpitoa varten tarvitaan edelleen datan käsittelykieli DML ( Data Manipulation Language ).

10. Nykyisissä tietokannan hallintajärjestelmissä kieliä ei sinänsä pidetä erillisinä SDL:ää lukuun ottamatta, vaan samaa kieltä voidaan käyttää sekä tietokannan että näkymien määrittelyyn ja datan käsittelyyn. Aikaisemmin myös SDL-ominaisuus sisältyi tietokannoille yleiseen SQL-kieleen, mutta sittemmin SQL:ää käytetään vain kahden ylimmän tason määrittelyyn. • Datan käsittelykieli voi olla luonteeltaan korkean tai matalan tason DML. • Korkean tason eli ei-proseduraalinen DML on luonteeltaan deklaratiivinen, eli se kuvaa, mitä tietoa kulloinkin tietokannasta käsitellään ( "joukko kerrallaan” ). Se on käyttökelpoinen sellaisenaan, mutta sitä voidaan käyttää myös upotettuna yleiseen ohjelmointikieleen. Tällöin tarvitaan DML-esikääntäjä avuksi, jotta DML-lauseet käännettäisiin erillään muusta ohjelmasta. • Matalan tason eli proseduraalinen DML voi toimia ainoastaan upotettuna yleiseen ohjelmointi-kieleen. Toisin kuin korkean tason DML, se kuvaa, miten tieto haetaan tietokannasta. Haku tapahtuu aina tietue kerrallaan, eli avuksi tarvitaan silmukkarakenteita.

11. 2.3.2. TKHJ:n käyttöliittymät • Käytettäessä apuna yleistä ohjelmointikieltä datan käsittelyä varten siitä käytetään nimitystä isäntäkieli ja DML:stä puolestaan nimitystä data-alikieli. Käytettäessä korkean tason DML:ää yksinään sitä kutsutaan usein kyselykieleksi, vaikkakin sitä voidaan käyttää myös päivitysoperaatioihin. • Peruskäyttäjät eivät turvaudu tietokannan erityiskieliin, vaan heitä varten perustetaan erilaisia käyttöliittymiä käyttöä helpottamaan. • Erilaisia käyttöliittymätyyppejä: • Valikkoperustaiset • lähinnä tietokannan selailua varten

12. Lomakepohjaiset • kyselyjen muodostamiseen • tiedon syöttöön • Graafiset • voidaan käyttää hyödyksi hiirtä • Luonnolliseen kieleen perustuvat • komennot muistuttavat luonnollista kieltä • viitataan tietokannassa esiintyviin kenttiin • Peruskäyttäjille suunnatut • toimintojen 'avauduttava' nopeasti • funktionäppäimet, lyhyet komennot yms. • Tietokannan valvojalle suunnatut • valmiudet luoda uusia käyttäjäprofiileja, tietokannan näkyvyyden rajoittamiseen ja tiedon fyysiseen uudelleenorganisointiin

13. 2.4. Tietokantajärjestelmäympäristö2.4.1. TKHJ:n komponenttimoduulit • Tallennetun datan järjestelijä ( stored data manager ) • kontrolloi, onko viittauksen kohteena oleva tieto varsinaista dataa vai metadataa • käyttää avukseen käyttöjärjestelmän toimintoja järjestellessään tiedon siirtämistä levyltä keskusmuistiin • huolehtii puskureiden hallinnasta keskusmuistissa • Tiedonmäärittelykielen eli DDL-kääntäjä • prosessoi tietokannan kaavamäärittelyjä ja tallentaa kuvaukset ( metadatan ) systeemiluetteloon • Ajonaikainen tietokantaprosessori • käsittelee tietokantaan kohdistetut operaatiot • levyoperaatiot kulkevat tallennetun datan järjestelijän kautta

14. 2.4.2. Tietokantajärjestelmän palveluja • Kyselyiden kääntäjä • jäsentää, analysoi ja kääntää käyttäjän tuottaman kyselyn sekä generoi siitä koodin tietokantaprosessorille • Esikääntäjä erottelee datan käsittelykielen yleisen ohjelmointikielen keskeltä • DML-kääntäjä kääntää DML-osuuden, minkä jälkeen ohjelman osat linkitetään valmiiksi sovellusohjelmaksi • Tiedon lataaminen tietokantaan • lukeminen tekstitiedostosta tai konversio joltakin muulta tiedostotyypiltä nykyisen TKHJ:n ymmärtämään muotoon

15. Turvakopiointi • tarkoittaa yleensä koko tietokannan tallentamista nauhalle • voidaan tehdä joko täydellisenä tai inkrementaalisesti – s. o.pelkästään edellisen kopioinnin jälkeen muuttuneiden tietojen osalta • Tiedostojen uudelleenorganisointi • tehokkuuden lisäämiseksi • Suorituskyvyn seuranta • tilastotietoa tietokannan valvojan käyttöön • Muita palveluja mm. mahdollisuus tiedostojen lajitteluun, tiedon tiivistämiseen, käytettävyys verkon kautta jne. 2.4.3. Työkaluja, sovelluskehitysympäristöt ja etäyhteydet • Tietokoneavusteinen ohjelmistosuunnittelu, ns. CASE-välineet ( CASE=Computer Aided Software Engineering ) • hyödyksi tietokannan suunnitteluprosessissa

16. Tietohakemisto • pitää sisällään TKHJ:n systeemiluettelon sisältämät tiedot, mutta on käyttötarkoitukseltaan laajempi • sisältää tietoja mm. tietokannan suunnittelua koskevista päätöksistä, käyttöstandardeista, sovellusohjelmien kuvauksen ja tietoa käyttäjistä • palvelee etupäässä käyttäjiä pikemmin kuin TKHJ:n ohjelmistoa • Sovelluskehitysympäristöt • helpottavat valmiiden sovellusohjelmien, graafisten käyttöliittymien ja kyselyiden muodostamista ( mm. PowerBuilder, JBuilder ) •  Yhteysohjelmistot • tarvitaan, kun tietokanta on toteutettu asiakas-palvelin -arkkitehtuurilla ( tietokanta sijaitsee fyysisesti palvelinkoneella ) tai tietokanta on hajautettu ( jaettu usean koneen kesken ) o  usein erillismoduuleina TKHJ:ssä • yhdistetystä tietokanta- ja tietoliikennesysteemistä käytetään lyhennettä DB/DC ( Database / Data communications )

17. 2.5. Tietokannanhallintajärjestelmien keskitetty / asiakas-palvelin -arkkitehtuuri • Varhaisimmissa tietokannanhallintajärjestelmissä käytetty arkkitehtuuri • Tietokanta sijoitettuna suurtietokoneelle, johon käyttäjät olivat yhteydessä ’tyhmien’ päätteiden välityksellä • Mikrotietokoneiden yleistyessäkin useat tietokantasovellukset pyörivät edelleen keskuskoneissa, koska mikrotietokoneiden laskentavoima oli edelleen riittämätön tietokantasovelluksille • Koneiden tehon kasvaessa alkoi asiakas-palvelin –arkkitehtuuri vähitellen yleistyä tietokantasovelluksissa • Tarkastellaan kirjan kuvaa 2.4. 2.5.1. Keskitetty TKHJ:N arkkitehtuuri

18. 2.5.2. Yleistä asiakas – palvelin -arkkitehtuureista • Useita mikrotietokoneita, työasemia, tiedostopalvelimia, kirjoittimia, tietokantapalvelimia ja verkkopalvelimia on kytketty toisiinsa verkkoyhteyden avulla • Palvelinkoneiden, kuten tietokanta-, tiedosto-, verkko- ja sähköpostipalvelinkoneiden on tarkoitus huolehtia kyseisten palveluiden tarjonnasta verkkoon liitetyille asiakaskoneille, jotka on tarkoitettu yksittäisille käyttäjille. • Asiakaskoneille on asennettuna käyttöliittymät palvelimilla olevien sovellusten käyttöön saamiseksi. • Käyttäjät voivat lisäksi suorittaa omilla asiakaskoneillaan omia erikoissovelluksiaan, joissa em. palvelimia ei tarvita ja joita ei tarvitse tarjota kaikkien käyttäjien saataville. • On tyypillistä, että lähiverkkoon kytketty kone toimii ainoastaan asiakkaana tai palvelimena, mutta koneella voi olla samanaikaisesti myös molemmat ominaisuudet.

19. 2.5.3. Kaksitahoinen asiakas – palvelin -ratkaisu • Asiakkaan koneella voidaan suorittaa tietokantaan kuuluvia sovellusohjelmia ja esittää kyselyjä, joiden prosessointi tapahtuu palvelinkoneella. • Tarvitaan yhteysohjelmisto, jonka avulla kommunikointi tietokannan datapalvelimen kanssa tapahtuu. • Mahdollistaa TKHJ:n hajautuksen: palvelin toimii puhtaasti datan käsittelijänä, kilpailevien tapahtumien kontrolloijana sekä virhetilanteista toipumisen toteuttajana. • Kyselyiden optimointi, käyttöliittymät ja tietohakemistojen käsittely tapahtuu puolestaan asiakkaan koneella.

20. 2.5.3. Kolmitahoinen asiakas – palvelin -ratkaisu • Internetin yleistyttyä asiakas-palvelin ratkaisuihin on tullut mukaan kolmas taso • Asiakkaalla on käytössään graafinen käyttöliittymä, jonka kautta hän ottaa yhteyttä sovelluspalvelimeen tai verkkopalvelimeen, joka käsittelee asiakkaan lähettämän pyynnön tai kyselyn ja lähettää sen eteenpäin varsinaiselle tietokantapalvelimelle. • Tietokantapalvelin palauttaa ainakin osittain käsitellyt tulokset takaisin edelliselle tasolle, jossa tulosta mahdollisesti vielä muokataan asiakkaan käyttöliittymälle sopivaksi. • Täten käyttöliittymä, sovelluksen säännöt ja varsinainen datan saanti tapahtuvat kolmella eri taholla. • Tietoliikenne asiakkaan ja sovelluspalvelimen välillä tapahtuu salatusti tietoturvan parantamiseksi.

21. 2.6. Tietokannan hallintajärjestelmien luokittelutavat • Tärkein kriteeri on tietomalli ( relaatio-, olio-, verkko-, hierarkkinen vai olio-relaatiotietokanta ) • Muita kriteerejä: • yhden vai monen käyttäjän järjestelmä? • keskitetty vai hajautettu? • jos hajautettu, niin onko tietokannan hallintajärjestelmä homogeeninen vai heterogeeninen? • käytetäänkö samaa vai eri TKHJ-ohjelmistoatietokannan eri sijaintipisteissä? • hajautettu heterogeeninen TKHJ on ainakin jossain määrin paikallisesti autonominen, jolloin puhutaan ns. liittomuotoisesta TKHJ:stä ( federated DBMS )

22. TKHJ:n kustannukset • datan saantipolkujen tyypit • yleiskäyttöinen vai erikoiskäyttöön tarkoitettu • erikoiskäyttöön tarkoitettua TKHJ:tä ei voida helposti muuntaa muuhun tarkoitukseen käytettäväksi ( esim. lentoyhtiöiden paikanvarausjärjestelmät ) • lyhyt vasteaika tärkeä kriteeri TKHJ:n käyttökelpoisuuden kannalta • Relaatiotietokannat perustuvat kokonaisuuksien esittämiseen taulumuodossa • Oliotietokannat perustuvat objekteihin, jotka edustavat jotain luokkaa, jonka edustajilla on voimassa tietyt ominaisuudet.   • Olio-relaatiotietokannat ovat relaatiomallin laajennus, joka hyödyntää oliotietomallin piirteitä ( mm. objektien tallentaminen dataan ).

23. Verkkomallissa data esitetään joukkotyyppisenä linkitettyjen tietueiden avulla • riippuvuussuhde 1:N ( yksi tietue liittyy N:ään tietueeseen ) • Hierarkkisessa mallissa data esitetään hierarkkisena puurakenteena. • jokainen hierarkiataso kuvaa toisiinsa liittyviä tietueita • ei standardoitua kyselykieltä • käsitellään yleensä tietue kerrallaan