2. Tietokannan käsitteitä ja arkkitehtuuri

Esitys aiheesta: "2. Tietokannan käsitteitä ja arkkitehtuuri"— Esityksen transkriptio:

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. Tietomallien eri kategoriat Korkean tason eli käsitteellisissä tietomalleissa tietokannan rakennetta kuvataan käsittein, jotka ovat käyttäjille luontevia ymmärrettäviksi ( entiteetti, attribuutti, liittymä ). Matalan tason eli fyysisissä tietomalleissa kuvaillaan, miten data on tallennettuna tietokoneelle. Ne on tarkoitettu lähinnä tietokannan laitteistoa lähellä oleviin ominaisuuksiin erikoistuneille asiantuntijoille, ei niinkään tavallisille loppukäyttäjille ( tietueiden talletusmuoto, järjestys, saantipolut ).

3 Näiden kahden tason 'kompromissina' voidaan nähdä ns
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 tietokannan tilaksi. Tietokanta on määrittelyn jälkeen tyhjässä tilassa ( ei vielä sisällä dataa ).   Ensimmäisen syöttövaiheen päätyttyä tietokanta on alkutilassaan.   Tehtäessä päivityksiä tietokantaan sen tila muuttuu.   Jokaisella tietokannan kaavan rakenneosalla on tietty nykyinen esiintymien joukko ( tietyssä taulussa yhtenä ajankohtana esiintyvien tietueiden sisältö ).

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

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. Tietoriippumattomuus Kolmitasoarkkitehtuuri tukee tietoriippumattomuutta. Tämä tarkoittaa sitä, että tietokannan kaavan muutos alemmalla tasolla ei aiheuta muutoksia ylemmälle tasolle. Ainoastaan tasojen välinen kuvaus muuttuu.

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. 2.3. Tietokannan kielet ja käyttöliittymät Tietokannoissa voidaan käyttää erilaisia kieliä ja käyttöliittymiä eri tarkoituksiin.

9 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. TKHJ:n käyttöliittymät Peruskäyttäjät eivät turvaudu tietokannan erityiskieliin, vaan heitä varten perustetaan erilaisia käyttöliittymiä käyttöä helpottamaan. Erilaisia käyttöliittymätyyppejä: 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 Tietokantajärjestelmän palveluja Tiedon lataaminen tietokantaan lukeminen tekstitiedostosta tai konversio joltakin muulta tiedostotyypiltä nykyisen TKHJ:n ymmärtämään muotoon

15 2.4.3. Työkaluja, sovelluskehitysympäristöt ja etäyhteydet
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. 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
Keskitetty TKHJ:N arkkitehtuuri Varhaisimmissa tietokannanhallintajärjestelmissä käytetty arkkitehtuuri Tietokanta sijoitettuna suurtietokoneelle, johon käyttäjät olivat yhteydessä ’tyhmien’ päätteiden välityksellä Mikrotietokoneiden yleistyessäkin useat tietokantasovellukset pyörivät edelleen keskuskoneissa, koska mikrotietokoneiden laskentavoima oli edelleen riittämätön tietokantasovelluksille Koneiden tehon kasvaessa alkoi asiakas-palvelin –arkkitehtuuri vähitellen yleistyä tietokantasovelluksissa Tarkastellaan kirjan kuvaa 2.4.

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-ohjelmistoa tietokannan 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