Tietokannat

1
Tietokannat

• Aineopintokurssi, 4 ov, syksy 2002
• Turun yliopisto / ohjelmistotekniikka / Salo
• Lasse Bergroth
• _____________________________________
• Kurssi perustuu kirjaan Elmasri - Navathe
  Fundamentals of Database Systems, Addison-Wesley
  2000, 3. painos sekä Antti Tuomiston aikaisempaan
  luentomonisteeseen

2
Kurssin aikataulu

• Luennot tiistaisin kello 09.00-10.45 ja
  perjantaisin kello 14.00-15.45, yhteensä 44
  tuntia
• 1. luento 2002-09-23, viimeinen 2002-12-13
• o ei luentoa 2002-12-06
• Demonstraatiot torstaisin kello 12.00-13.45,
  yhteensä 20 tuntia 2002-10-03 alkaen
• Viimeinen demonstraatiokerta torstaina 2002-12-05
• Ensimmäinen tenttikerta maanantaina 2002-12-16
  kello 9-13.
• Seuraavat tenttikerrat vuoden 2003 tammi- ja
  maaliskuussa, tarkemmat päivämäärät ilmoitetaan
  myöhemmin.

3
Kurssin suoritustavat

• Kurssi koostuu luennoista, demonstraatioista,
  harjoitustyöstä ja tentistä.
• Demonstraatiotehtäviä yhteensä 105 50
  tehtävää.
• 15 tehtyä tehtävää (30) riittää kurssin
  tenttioikeuden saavuttamiseen
• 25 tehtävällä (50) ¼n hyvitys tenttiarvosanaan
• 35 tehtävällä (70) ½n hyvitys tenttiarvosanaan
• 45 tehtävällä (90) ¾n hyvitys tenttiarvosanaan
• Tehtävät jaetaan viimeistään käsittelykertaa
  edeltävän perjantain luennolla.
• Kysymykset löytyvät viikolta 40 lähtien myös
  verkosta osoitteesta http//www.cs.utu.fi/bergroth
  /tietokannat.htm.

4
Kurssin suoritustavat (jatkoa)

• Demovastaukset voidaan palauttaa kirjallisesti
  ainoastaan yhden kerran ilman perusteltua syytä.
• Harjoitustyöt jaetaan lokakuun loppupuolella.
  Tehtävänä on suunnitella ja toteuttaa
  pienimuotoinen tietokanta.
• Ensimmäiseen tenttikertaan ei tarvitse
  ilmoittautua, myöhempiin osallistumisesta pitää
  ilmoittaa luennoitsijalle viimeistään viikkoa
  etukäteen.
• Tenttiin vastaamisaikaa käytettävissä 4 tuntia.
• 5 kysymystä, jotka kaikki arvostellaan 6 pisteen
  arvoisesti, maksimipistemäärä 30
• hyväksyttyyn arvosanaan riittää 13 pistettä
• mahdollinen demonstraatiohyvitys lisätään
  ainoastaan hyväk-syttyyn tenttiarvosanaan

5
Kurssin tavoitteet

• Tietokanta-ajattelun sisäistäminen ja
  tiedonhallinnan periaatteiden ja käsitteiden
  omaksuminen
• Antaa valmiudet tietokantojen suunnittelua,
  toteuttamista ja käyttöä varten
• Korostaa laadun merkitystä tietokannan
  suunnittelussa (ER-mallinnus ja normalisointi) ja
  toteutuksessa (säännöt ja niiden merkitys)
• Antaa lyhyt katsaus tärkeimpiin tietokantojen
  tallennuksessa käytettäviin tietorakenteisiin
• Tarjota perustiedot jatko-opintoja varten (mm.
  syventävät kurssit, kurssia sivuavat aihealueet
  ja alan tutkimuskohteet)
• Kurssilla keskitytään lähinnä relaatiotietokantoih
  in

6
1. Tietokannat ja tietokantojen käyttäjät
1.1. Tietokannan määritelmä ja ominaisuudet

• Tietokannalla tarkoitetaan kokoelmaa tietoja,
  joilla on ilmeinen yhteys toisiinsa (esimerkiksi
  kirjaston asiakkaita ja sieltä lainattavaa
  materiaalia koskevat tiedot, yliopiston
  opiskelijarekisteri, yrityksen asiakas- ja
  tuotantotiedot, pankin asiakas- ja tilitiedot,
  sairaalan potilastiedot, autojen rekisteritiedot
  jne.).
• Tietokannan osien välillä pitää olla looginen
  yhteys, eli sinne säilöttyjen tietojen pitää olla
  riittävän voimakkaasti sidoksissa toisiinsa.
  Esimerkiksi kirjan yksittäisen sivun sisältämistä
  sanoista koottu luettelo ei täytä tietokannan
  kriteeriä.
• Tietokanta edustaa siten jotain selkeästi
  määriteltyä ja rajattua kohdetta
  reaalimaailmassa. Muutokset tällaisessa
  'minimaailmassa' heijastuvat muutoksina kyseistä
  kohdetta kuvaavaan tietokantaan.

7

• Menettelytavat, joilla tietokannan sisältämät
  tiedot on kerätty, ovat hyvin määritellyt eivätkä
  sattumanvaraisesti valitut (esimerkiksi
  asiakastietojen / kirjastossa tarjolla olevan
  nidevalikoiman päivittä-minen).
• Tietokannan sisältämät tiedot ovat ainakin jonkin
  intressiryhmän kannalta hyödyllisiä tai
  mielen-kiintoisia. Muutoin ei olisi mielekästä
  edes perustaa kyseistä tietokantaa saatika
  ylläpitää sitä.
• Tietokannat voivat nykyisin yhä enenevässä määrin
  sisältää paitsi perinteistä tekstimuotoista,
  numeerista ja loogista tietoa niin myös
  esimerkiksi videokuvaleikkeitä ja karttatietoa.
• Tietokannat voivat vaihdella kooltaan erittäin
  suuresti. Yksin-kertaisimmillaan se muodostuu
  yhdestä ainoasta tiedostosta, joka sisältää
  pienehkön määrän tietueita. Esimerkiksi kelpaisi
  vaikkapa yksityishenkilön puhelinmuistioon
  tallennetut nimi-, osoite ja puhelin-numerotiedot.
  Toisessa ääripäässä ovat puolestaan valtion ja
  suuryritysten ylläpitämät massiiviset
  tietovarastot (esimerkiksi Yhdysvaltain
  kansalaisten verotiedot viimeisten viiden vuoden
  ajalta, kts. kirjan sivu 5).

8

• Tietokannan ei välttämättä tarvitse olla
  sähköisessä muodossa, vaan pieniä tietokantoja
  voidaan ylläpitää myös manuaalisesti (vrt.
  puhelinmuistiot, kalenterit yms.).
• Ohjelmistoa, joka mahdollistaa tietokannan
  perustamisen ja ylläpitämisen, kutsutaan
  tietokannan hallintajärjestelmäksi (TKHJ). Se
  sisältää työvälineet, joiden avulla käyttäjän
  muodostamat kyselyt ja päivitykset saadaan
  toteutettua itse tietokantaan.
• Tietokannan sisältämä data sekä sen
  kuvailemiseksi tehdyt määrittelyt (ns. metadata)
  pidetään toisistaan fyysisesti erillään.
• Tietokoneympäristöön toteutettu tietokanta ei
  vaadi välttämättä tuekseen kaupallista
  ohjelmistoa, mutta usein tietokannan
  määritteleminen, toteuttaminen ja käsittely
  vaativat suuremman työpanoksen, jos TKHJ halutaan
  ohjelmoida kokonaan itse. Työmäärän lisääntyminen
  korostuu erityisesti muutettaessa tietokannan
  rakennetta uusien tiedon ylläpitotarpeiden
  mukaiseksi.
• Tietokannan sovellusohjelmien, TKHJn, sekä
  levylle tallennetut data- ja määrittelytiedot
  muodostavat yhdessä ns. tietokantajärjestelmän.

9
1.2. Esimerkki tietokannasta

• Yliopiston opiskelijoiden opintotiedot
• Viisi eri kokonaisuutta, jotka ovat omina
  tiedostoinaan
• o Opiskelijan tiedot
• o Kurssin yleistiedot
• o Kurssin yksittäisen luentokerran tiedot
• o Opintosuoritusraportti
• o Kurssin esitietovaatimukset
• Jokainen tiedosto muodostuu tietueista, jotka
  sisältävät tietokenttiä.
• Jokainen tietokenttä edustaa jotain tiettyä
  yksikäsitteistä tietotyyppiä (merkkijono,
  kokonaisluku, reaaliluku, looginen tieto jne.).

10

• Lueteltua tyyppiä, jolla on verrattain suppea
  arvojoukko, voidaan esittää myös koodaamalla
  ominaisuudet esimerkiksi kokonaislukujen tai
  lyhenteiden avulla (esimerkiksi pääaineet
  1matematiikka, 2fysiikka, 3tietojenkäsittelytie
  de jne.).
• Jokaisella tietokannan sisältämällä tiedostolla
  on looginen yhteys ainakin yhteen muuhun
  tiedostoon tietokannan sisällä (esim. kurssi -
  kurssin esitiedot, opiskelija -
  opintosuoritusote, kurssi - kurssin
  luennointikerrat jne.).
• Yhteydet eri tiedostojen välillä mahdollistavat
  monimutkaistenkin kyselyjen ja operaatioiden
  suorittamisen. Esimerkiksi listataan kaikkien
  niiden opiskelijoiden tiedot, jotka suorittivat
  vuonna 1999 pidetyn tietokantojen kurssin.

11
1.3. Miksi perustaa tietokanta?
1.3.1. Tietokantajärjestelmän kyky kuvailla
itseään

• Vaihtoehtona voitaisiin ajatella yksittäisten
  tiedostojen ylläpitoa yhden yhtenäisen
  tietokannan asemesta.
• Vaikka tiedostorakenne on hyvin yksinkertainen,
  käytännön pulmat tulevat usein kuitenkin nopeasti
  esiin
• o samoja tietoja saatetaan tarvita yksikössä
  usealla taholla (esimerkiksi opintosuoritusten ja
  lukukausimaksujen hallinta molemmissa tarvitaan
  opiskelijan perustietoja)
• ----gtsamoja tietoja joudutaan ylläpitämään
  useassa paikassa, mikä johtaa
  moninkertaiseen samojen tietojen ylläpitoon
  hukataan sekä työtunteja että tietokoneiden
  muistitila- resursseja
• Tietokantalähestymistapa estää tiedon
  tarpeettoman moninkertaisen ylläpidon, kunhan
  tietokanta määritellään huolellisesti ennen sen
  perustamista.

12

• Määrittelyn yhteydessä kuvataan tietokantaan
  kuuluvien tiedostojen sisältämät kentät, niiden
  tyypit sekä rajoitukset kenttiin tallennettavalle
  datalle. Määrittelyistä käytetään nimitystä
  metadata, ja se tallennetaan ns.
  systeemiluetteloon ( system catalog ).
• Metadata sisältää kaiken tarpeellisen tiedon
  tietokannan rakenteellisista ominaisuuksista.
• Tietokannan selkeänä etuna yksittäisten
  tiedostojen käsittelemiselle on fyysisen
  tallennusrakenteen näkymättömyys käyttäjälle.
  Riittää tietää, minkä nimiseen tiedostoon ja sen
  kenttään viitataan. Yksittäistä tiedostoa
  käsiteltäessä pitää sen rakenne tietää tarkoin,
  ja muutokset tiedoston tietuerakenteessa voivat
  edellyttää suuria muutoksia sitä käsitteleviin
  ohjelmiin.
• Kaupallisilla sovelluskehittimillä voidaan
  rakentaa useita toisistaan täysin riippumattomia
  tietokanta-sovelluksia. Edellytyksenä on
  ainoastaan, että sekä tietokanta että sen
  määrittelyt ovat ohjelman luettavissa.

13
1.3.2. Ohjelmien ja datan eristäminen toisistaan
tietoabstraktio

• Tietokantajärjestelmässä tietokannan rakenteen
  muuttuminen ei yleensä johda suuriin
  muutos-toimenpiteisiin, sillä data ja määrittelyt
  sijaitsevat toisistaan erillään ----gt tiedon
  riippumattomuus ohjelmista
• Esimerkki uuden kirjattavan ominaisuuden
  (vaikkapa syntymäajan) lisääminen opiskelijaa
  kuvaavaan tietueeseen ----gt vain opiskelijataulua
  kuvaava määritys pitää uusia (ongelmia voi
  kuitenkin esiintyä, jos ei esimerkiksi sallita
  kyseiselle kentälle puuttuvaa arvoa, sillä
  vanhoista tietueista syntymäaikatieto puuttuu
  määrittelyä muutettaessa).
• Oliokeskeisissä sekä ns. olio-relaatiotietokannois
  sa voidaan määritellä tietokannan sisältämälle
  datalle myös operaatioita (funktioita).
  Funktiosta pitää tietää käyttöliittymä (nimi
  parametrit), mutta niiden toteutus kätketään
  käyttäjältä ----gt ohjelmien operaatioriippumattomu
  us.

14

• Esimerkkinä operaatiosta voitaisiin mainita
  vaikkapa opiskelijan opintosuoritusten
  arvosanojen keskiarvon laskeminen.
• Ohjelmien riippumattomuutta datasta ja
  operaatioista kutsutaan tietoabstraktioksi.
• Tietomalli on tietoabstraktion tyyppi, joka
  mahdollistaa tietokannan käsitteellisen
  kuvaamisen ilman, että on tiedettävä tiedon
  fyysisestä tallennusrakenteesta tai funktioiden
  toteutustavasta.
• Korkean tason tietomalli kuvaa tietokannan
  sisältämien kokonaisuuksien (esimerkiksi
  opiskelijan tiedot, kurssitiedot jne.)
  ominaisuuksia ja niiden välisiä riippuvuuksia
  siten, että käyttäjä pystyy ne ymmärtämään
  helpommin kuin tietokannan fyysisen
  tallennusrakenteen.

15
1.3.3. Erilaiset näkymät tietokannan sisältämään
dataan

• Suurissa tietokantasovelluksissa ei ole yleensä
  mielekästä, että kaikki käyttäjät saavat
  käyttöönsä kaiken mahdollisen kantaan tallennetun
  tiedon, vaan ainoastaan käyttäjälle itselleen
  tarpeellisen.
• Näkymää voidaan rajata paitsi kokonaisuuksittain,
  niin myös poistamalla yksittäisestä
  kokonaisuudesta tarpeettomia kenttiä (kts. kirjan
  esimerkki 1.4.).

1.3.4. Tiedon jakaminen ja monen käyttäjän
tapahtumien käsittely

• Suurissa tietokantasovelluksissa ei ole yleensä
  mielekästä, että kaikki käyttäjät saavat
  käyttöönsä kaiken mahdollisen kantaan tallennetun
  tiedon, vaan ainoastaan käyttäjälle itselleen
  tarpeellisen.
• Näkymää voidaan rajata paitsi kokonaisuuksittain,
  niin myös poistamalla yksittäisestä
  kokonaisuudesta tarpeettomia kenttiä (kts. kirjan
  esimerkki 1.4.)

16
1.4. Tietokannan varsinaiset toimijat

• TKHJn pitää pystyä huolehtimaan päivitysten
  oikeellisuudesta, kun useampi kuin yksi henkilö
  kerrallaan pyrkii päivittämään samaa tiedostoa
  (esimerkki kulkunevojen paikanvarausjärjestelmät)
  .
• On varmistuttava, etteivät jo hetkeä aikaisemmin
  tehdyt päivitykset jää huomioimatta esimerkiksi
  paikkoja varattaessa.
• Päivitysten oikeellisuuden takaamista
  tarkastellaan lisää Tietokantojen
  jatkokurssilla.

• Pienen tietokannan sekä suunnittelija, toteuttaja
  että päivittäjä voivat olla yksi ja sama henkilö.
• Tilanne muuttuu ratkaisevasti, kun tietokanta on
  suuri, ja sillä on paljon erilaisia käyttäjiä ja
  käyttötarkoituksia.
• Tietokantoja käsittelevät työntekijät voidaan
  karkeasti jakaa kahteen ryhmään ns. varsinaisiin
  toimijoihin ja taustavoimiin.

17
1.4.1. Tietokannan valvoja

• Varsinaisiin toimijoihin lasketaan tietokannan
  valvojat, suunnittelijat ja loppukäyttäjät.
• Varsinaiset toimijat ovat kiinnostuneita itse
  tietokannan ominai-suuksista ja/tai sisällöstä.

• Tarvitaan organisaatioissa, joissa tietokannalla
  on useita samanaikaisia käyttäjiä.
• Vastaa ensisijaisesti tietokannan sisältämän
  tiedon hallinnasta, toissijaisesti tietokannan
  hallinta-järjestelmän sekä sovellusohjelmien
  toimivuudesta ja tehokkuudesta.
• Huolehtii lisäksi käyttöoikeuksien jakamisesta
  henkilöstölle sekä järjestelmän tietoturvasta.
• Huolehtii lisäksi tarvittavien ohjelmistojen ja
  laitteistojen hankinnasta.

18
1.4.2. Tietokannan suunnittelija

• Suurissa organisaatioissa voi tietokannan
  valvojalla olla tukenaan avustavaa henkilökuntaa.

• Vastaa tietokannan rakenteellisesta
  määrittelystä.
• Toimii tiiviissä yhteistyössä kaikkien
  tietokannan tulevien käyttäjien kanssa ennen
  tietokannan toteuttamista, jotta tietokanta
  vastaisi mahdollisimman tarkoin käyttäjien
  tarpeita ja toivomuksia.
• Räätälöi eri käyttäjäryhmille erilaiset näkymät
  tietokantaan.
• o Valitsee näkymiin tarkalleen niitä tietoja,
  joita käyttäjät työtehtävissään tarvitsevat.

19
1.4.3. Loppukäyttäjät

• Loppukäyttäjät voidaan jaotella neljään eri
  ryhmään kuuluviksi tietotarpeen mukaan
• Satunnaiset käyttäjät
• tarvitsevat tietokannasta tietoa silloin tällöin
• haettavat tiedot saattavat vaihdella
• ----gt tarvetta ainakin
  osittaiselle kyselykielen osaamiselle
• yleensä yrityksen keski- tai ylemmän johdon
  edustajia
• Peruskäyttäjät (naiivit eli parametriset
  käyttäjät)
• tarve ymmärtää tietokannan rakennetta hyvin
  vähäinen
• valmiiksi määritellyt sovellusohjelmat
• ----gt kyselykielen opetteleminen ei tarpeen
• esimerkiksi toimisto- ja paikanvaraus-sovellusten
  käyttäjät, pankkivirkailijat jne.

20
1.4.4. Tietojärjestelmäanalyytikot ja
sovellusohjelmoijat

• Kehittyneet loppukäyttäjät
• tiedonsaannin tarpeet usein monimutkaisia ja
  vaihtelevia
• kyselykielen ja myös tietokannan rakenteen
  ymmärtäminen oleellisen tärkeää
• insinöörit, tiedemiehet, analyytikot jne.
• Yksinäiskäyttäjät
• ylläpitävät jotain rajattua osaa tietokannasta
• pystyvät kehittämään itse kyseiseen
  sovellusalueeseen tarpeellisia ohjelmia

• Tietojärjestelmäanalyytikot kartoittavat
  valmiiden sovellusohjelmien tarpeen
  loppukäyttäjille, ja suunnittelevat tarvittavat
  ohjelmat.
• Sovellusohjelmoijien tehtävänä on toteuttaa
  tietojärjestelmä-analyytikon suunnittelemat
  sovellusohjelmat

21
1.5. Tietokantojen taustavoimat

• Toisin kuin varsinaiset toimijat, taustavoimat
  eivät suoranaisesti ole kiinnostuneita itse
  tietokannasta.
• Tietokannan hallintajärjestelmän
  systeeminsuunnittelijat suunnit-televat ja
  toteuttavat TKHJn moduulit. Moduuleja ovat mm.
  systeemiluettelo, kyselykieli, kilpailevien
  tapahtumien hallinta, toipuminen
  virhetilanteista, turvallisuus, käyttöliittymät
  sekä tietoihin käsiksi pääseminen.
• Työvälineiden kehittäjät pyrkivät saamaan aikaan
  välineitä, joilla tietokannan suunnittelua ja
  käyttöä voidaan helpottaa.
• Operaattorit huolehtivat yrityksen
  ATK-laitteiston yleisestä toimi-vuudesta.

22
1.6. Tietokannan hallintajärjestelmän hyötyjä

• Redundanssin (tiedon toistamisen) kontrolli
• Tiedon toistamista tapahtuu perinteisessä
  tiedostojärjestelmässä, kun usealla taholla
  joudutaan syöttämään samoja tietoja (vrt.
  yliopiston opiskelijoiden opintomaksut ja
  opintosuoritukset kummassakin paikassa tarvitaan
  opiskelijan perustietoja).
• Seurauksena ylimääräistä tiedon syöttö- ja
  päivitystyötä sekä levytilan tarpeetonta
  tuhlausta.
• Virhe tallennuksessa (esimerkiksi syntymäajan
  kohdalla) johtaa siihen, että opiskelijan tiedot
  näkyvät erilaisina eri toimipisteissä ----gt
  tiedon vastaamattomuus eli inkonsistenssi
• Käytettäessä tietokantalähestymistapaa eri
  käyttäjäryhmät integroidaan tietokannan
  suunnitteluvaiheessa ----gt samat tiedot
  tallennetaan vain yhteen kertaan

23

• Hyvin perustelluista syistä voidaan tietoa
  kuitenkin toistaa useaan tiedostoon. Näin voidaan
  tehdä esimerkiksi kyselyjen nopeuttamiseksi.
• Esimerkki opintosuorituksia kuvaavaan tiedostoon
  voidaan mennä lisäämään opiskelijan nimi ja
  kurssin tunnus, sillä niiden näkyminen
  opintosuoritusotteessa on varsin tarpeellista.
• Tällöin on kuitenkin määriteltävä metadataan
  säännöt, jotka vaativat vastaavuutta opiskelijan
  nimen ja opiskelijanumeron sekä vastaavasti
  kurssin nimen ja sen luennointikerran välille,
  jotta tietokanta pysyisi konsistenttina.
  Tällaista menettelyä kutsutaan kontrolloiduksi
  redundanssiksi.
• Tiedon käyttöoikeuksien jakaminen
• Tietokannan valvoja pystyy määrittelemään
  erilaisia käyttäjäprofiileja, joiden mukaan
  määräytyy, mihin tietoihin kukin käyttäjä saa
  saantioikeudet ----gt käyttäjätunnukset ja
  salasanat.
• Tämä edellyttää tietystikin rajattua pääsyä
  tiettyihin TKHJn moduuleihin, kuten perustamaan
  uusia käyttäjätunnuksia.

24

• Lisäksi voidaan rajata tietokantaan pääsy
  ainoastaan valmiiden loppukäyttäjäsovellusten
  kautta, tavoitteena loppukäyttäjien tekemien
  virheiden välttäminen
• ----gt loppukäyttäjä ei saa relaatiotauluja
  näkyviin.
• Olioiden ja tietorakenteiden tallentaminen
  pysyvästi
• Oliokeskeisissä tietokannoissa voidaan
  ohjelmointikielten objekteja tallentaa suoraan
  tietokantaan rikkomatta niiden rakennetta toisin
  kuin tiedostoon tallennettaessa (ns. pysyvät
  objektit).
• Päättelyä tukevat (deduktiiviset)
  tietojärjestelmät
• Loogiseen päättelyyn perustuvat tietokannat,
  joissa tietyn ominaisuuden olemassaolo perustuu
  hyvin määriteltyihin sääntöihin.
• Logiikkatietokannoista lisää mm.
  logiikkaohjelmoinnin kurssilla.

25

• Päättelysääntöjen muuttaminen yleensä helpompaa
  kuin sovellusohjelmien uusiminen uusia sääntöjä
  vastaaviksi.
• Erilaiset käyttöliittymät eri käyttäjäryhmille
• Lomake- ja valikkotyyppiset näytöt sekä opastavat
  graafiset käyttöliittymät peruskäyttäjille
• Edellisten lisäksi kyselykielet edistyneemmille
  käyttäjille
• Tietokannan tietojen välisten suhteiden
  esittäminen
• Pystytään helpohkosti määrittelemään tietokannan
  eri kokonai-suuksien väliset yhteydet toisiinsa
  (esim. kurssin perustietojen ja sen
  luentokertojen välillä, opiskelijan perustietojen
  ja opintosuoritusraportin välillä jne.).
• Helpottaa huomattavasti monimutkaisten hakujen ja
  päivitysten suorittamista.

26

• Tietokannan eheyssääntöjen kontrollointi
• Tyypin ja arvoalueen määrääminen tietokentille
  laittomien arvojen tallentaminen tietokantaan
  estetään.
• Avaintietokenttien yksikäsitteisyys ( esim. samaa
  opiskelija-numeroa ei saa esiintyä kahdella eri
  rivillä opiskelijoiden perustietoja kuvaavassa
  taulussa )
• Riippuvuudet tietokannan taulujen välillä
  estetään viittausten katkeaminen
• Esimerkin yliopistotietokannan tapauksessa
  voitaisiin vaatia, että luentoja voi järjestään
  ainoastaan sellaisesta kurssista, jonka
  perustiedot on jo tallennettu ----gt ei perusteta
  sellaisia luentotietueita, joiden kurssi on
  tuntematon
• Vastaavasti sellaisen kurssin tietojen
  poistaminen, josta on luentokertatietueita tai
  opintosuorituksia olemassa, olisi laitonta ilman
  kaikkien niiden tietojen tuhoamista tai
  muuttamista, jotka viittaavat kyseiseen kurssiin

27

• Tietokanta ei ole kuitenkaan mikään
  'ihmerakennelma' kaiken virheellisen tiedon
  eliminoimiseksi, sillä
• Tietokannan suunnittelu voi olla puutteellinen,
  jolloin on mahdollista, ettei edellä mainittuja
  tarpeellisia eheys-sääntöjä välttämättä
  asetettukaan.
• Voidaan syöttää laillinen mutta virheellinen arvo
  johonkin tietokenttään, jonka arvoalue on
  rajoitettu.
• Turvakopioinnin ja virheistä toipumisen tuki
• Tietokannan hallintajärjestelmä mahdollistaa
  tallennettujen tietojen palauttamisen, mikäli
  jostain syystä (esimerkiksi sähkökatkon takia)
  ohjelman suoritus yllättäen keskeytyy.
• Helpottaa tietokannan turvakopiointia erilaisten
  katastrofaalisten tilanteiden (levyrikko, fataali
  käyttövirhe, ilkivalta yms.) kannalta

28
1.7. Tietokantalähestymistavan seurauksia

• Mahdollisuus standardien valvontaan
• Keskitetysti hallitulle tietokannalle voidaan
  määritellä käytännöt, jonka mukaisesti mm. taulut
  nimetään, raportit ja näkymät muotoillaan, mitä
  terminologiaa käytetään jne. Tämä ei onnistuisi,
  jos käyttäjät voisivat määritellä omat
  tiedostonsa ja ohjelmansa itse.
• Sovelluskehityksen nopeutuminen
• Kun tietokanta on kertaalleen määritelty ja
  perustettu, on uusien sovelluksien rakentaminen
  verrattain helppoa, koska fyysistä
  talletus-rakennetta ei tarvitse tietää
  (sovelluksia rakennettaessa käytettävät käsitteet
  lähellä itse sovellusta).

29

• Rakenteellinen joustavuus
• Uusien tiedon ylläpitotarpeiden aiheuttamat
  muutokset (esimerkiksi yksittäisten tietokenttien
  lisääminen tauluihin tai uusien taulujen
  perustaminen) helpommin toteutettavissa kuin
  tiedosto-järjestelmässä.
• Yksittäisen kentän lisäys ei kuitenkaan ole
  välttämättä yksinkertaista, jos kenttään halutaan
  liittyvän sääntöjä.
• Ajan tasalla olevan tiedon saatavuus
• Tehdyt päivitykset näkyvät heti kaikkialla, koska
  samaa tietoa ei (kontrolloimattomasti) säilötä
  useaan paikkaan.
• Mittakaavaedut
• Voidaan hankkia keskitetysti tehokas kone, jossa
  tietokanta fyysisesti sijaitsee.
• Myöskään ei tarvita moninkertaista ylläpitotyötä.

30
1.8. Milloin TKHJtä ei kannata käyttää?

• Saattaa olla perusteltua olla käyttämättä
  tietokannanhallinta-järjestelmää, mikäli
• TKHJn hankinta-, koulutus- sekä TKHJtä varten
  tarvittavan laitteiston tuomien lisäkustannusten
  ollessa kohtuuttoman suuret rakennettavan
  sovelluksen kokoon nähden.
• Tiedon hallintamekanismien yleisyys ----gt
  tehottomuus
• TKHJn tuottaman tietoturvan, kilpailevien
  tapahtumien kontrolloinnin, toipumisen
  varmistamisen ja eheyssääntöjen tarkastusten
  aiheuttama ylläpidon monimutkaisuus
• Tietokannan suunnitteluun ja kunnolliseen
  toteutukseen panostettavien voimavarojen
  riittämättömyys.

31

• Tietokanta ja sen sovellukset ovat
  yksinkertaisia, ja tietokannan sisältämä tieto on
  luonteeltaan stabiilia (ei juuri muutoksia kannan
  määrittelyihin).
• Vaaditaan tiukkaa pitäytymistä reaaliaikaisuudessa
  (haluttaessa karsia pois kaikki hidastuttavat
  elementit).
• Haluttaessa perustaa vain yhden käyttäjän
  järjestelmä.

32
2. Tietokannan käsitteitä ja arkkitehtuuri

• Aikaisemmin tietokannan hallintajärjestelmät
  olivat suuria, tiiviisti integroituja
  järjestelmiä.
• Nykyisille TKHJlle on tyypillistä ns.
  asiakas-palvelin -arkkitehtuuri. ----gt
  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.

33
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äivit-tämistä varten.

• 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äivit-tämistä varten.

34

• Korkean tason eli käsitteellisissä tietomalleissa
  tietokannan rakennetta kuvataan käsittein, jotka
  ovat käyttäjille luontevia ymmärrettäviksi (
  entiteetti, attribuutti, liittymä ).
• Matalan tason eli fyysisissä tietomalleissa
  kuvaillaan, miten data on tallennettuna
  tietokoneelle. Ne on tarkoitettu lähinnä
  tietokannan laitteistoa lähellä oleviin
  ominaisuuksiin erikoistuneille asiantuntijoille,
  ei niinkään tavallisille loppukäyttäjille (
  tietueiden talletusmuoto, järjestys, saantipolut
  ).
• Näiden kahden tason 'kompromissina' voidaan nähdä
  ns. toteutusmalli, joka on vielä
  loppukäyttäjänkin hahmotettavissa, muttei samalla
  kuitenkaan kohtuuttoman kaukana matalan tason
  tiedon organisointimallista ( piilottaa osan
  rakenteiden yksityis-kohdista, mutta voidaan
  silti käyttää suoraan TKHJssä useimmat
  kaupalliset TKHJt 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 ).

35

• Tällä kurssilla käsiteltävän relaatiotietomallin
  ja yleistymässä olevan oliokeskeisen
  tietokantamallin lisäksi toteutusmalleihin
  luetaan aikaisemmat verkko- ja hierarkkinen
  malli, jotka tällä kurssilla sivuutetaan.

2.1.2. Kaavat, esiintymät ja tietokannan tila

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

36

• 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ö).

37
2.2. Tietokannan hallintajärjestelmän
arkkitehtuuri2.2.1. Kolmitasoarkkitehtuuri

• TKHJn 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.

         
38
2.2.2. Tietoriippumattomuus

• Ulkoinen eli näkymätaso kuvaa sitä, millaisena
  kukin käyttäjäryhmä näkee tietokannan. Se sulkee
  ulko-puolelleen kaikki heille tarpeettomat osat,
  ja sen kuvaamiseksi käytetään korkean tason
  tietomallia.
• Eri tasojen välillä käytetään kuvauksia, jotta
  esimerkiksi tehdyt tietokantakyselyt ja niihin
  saadut tulokset voidaan välittää tasolta toiselle
  kullekin tasolle ominaiseen esitysmuotoon.
• Useimmat TKHJt 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 tietoriippumattomuutt
  a. Tämä tarkoittaa sitä, että tietokannan kaavan
  muutos alemmalla tasolla ei aiheuta muutoksia
  ylemmälle tasolle. Ainoastaan tasojen välinen
  kuvaus muuttuu.

39
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.

40
2.3.1. TKHJn kielet

• Tiedonmäärittelykieli DDL (Data Definition
  Language) on tarkoitettu tietokannan kaavan
  määrittelyä varten.
• TKHJhin 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).

41

• 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äännet-tä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.

42
2.3.2. TKHJn käyttöliittymät

• Käytettäessä apuna yleistä ohjelmointikieltä
  datan käsittelyä varten siitä käytetään nimitystä
  isäntäkieli ja DMLstä 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.

• Käytettäessä apuna yleistä ohjelmointikieltä
  datan käsittelyä varten siitä käytetään nimitystä
  isäntäkieli ja DMLstä 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 

43

• 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

44
2.4. Tietokantajärjestelmäympäristö2.4.1
. TKHJn komponenttimoduulit

• Tallennetun datan palvelin (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
• DDL-kääntäjä
• prosessoi tietokannan kaavamäärittelyjä ja
  tallentaa kuvaukset (metadatan)
  systeemiluetteloon
• Ajonaikainen tietokantaprosessori
• käsittelee tietokantaan kohdistetut operaatiot
• levyoperaatiot kulkevat tallennetun datan
  palvelimen kautta

45
2.4.2. Tietokantajärjestelmän palveluja

• Kyselyiden kääntäjä
• jäsentää käyttäjän tuottaman kyselyn ja muuntaa
  sen generoi siitä koodin tietokantaprosessorille
• Esikääntäjä erottelee datan käsittelykielen
  yleisen ohjelmointikielen keskeltä
• DML-kääntäjä kääntää DML-osuuden, minkä jälkeen
  ohjelman osat linkitetään valmiiksi
  sovellusohjelmaksi

• Tiedon lataaminen tietokantaan
• lukeminen tekstitiedostosta tai konversio
  joltakin muulta tiedostotyypiltä TKHJn
  ymmärtämään muotoon
• Turvakopiointi
• tarkoittaa yleensä koko tietokannan tallentamista
  nauhalle

                    Tiedostojen
uudelleenorganisointio     tehokkuuden
lisäämiseksi          Suorituskyvyn
seurantatilastotietoa tietokannan valvojan
käyttöön
46

• Tiedon lataaminen tietokantaan
• lukeminen tekstitiedostosta tai konversio
  joltakin muulta tiedostotyypiltä TKHJn
  ymmärtämään muotoon
• Turvakopiointi
• tarkoittaa yleensä koko tietokannan tallentamista
  nauhalle
• Tiedostojen uudelleenorganisointi
• tehokkuuden lisäämiseksi
• Suorituskyvyn seuranta
• tilastotietoa tietokannan valvojan käyttöön

2.4.3. Työkaluja, sovelluskehitysympäristöt ja
etäyhteydet

• Tietokoneavusteinen ohjelmistosuunnittelu, ns.
  CASE-välineet (CASEComputer Aided
  Software Engineering)
• hyödyksi tietokannan suunnitteluprosessissa

47

• Tietohakemisto
• pitää sisällään TKHJn 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 TKHJn
  ohjelmistoa
• Sovelluskehitysympäristöt
• helpottavat valmiiden sovellusohjelmien,
  graafisten käyttöliittymien ja kyselyiden
  muodostamista
•  Yhteysohjelmistot
• tarvitaan, kun tietokanta on toteutettu
  asiakas-palvelin - arkkitehtuurilla (tietokanta
  sijaitsee fyysisesti palvelinkoneella) tai
  tietokanta on hajautettu (jaettu usean koneen
  kesken)
• o  usein erillismoduuleina TKHJssä
• yhdistetystä tietokanta- ja tietoliikenne-systeemi
  stä käytetään lyhennettä DB/DC (Database / Data
  communications)

48
2.5. Tietokantajä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
  hallinta-järjestelmä homogeeninen vai
  heterogeeninen?
• käytetäänkö samaa vai eri TKHJ-ohjelmistoja
  tietokannan eri sijaintipisteissä?
• hajautettu heterogeeninen TKHJ on ainakin jossain
  määrin paikallisesti autonominen, jolloin
  puhutaan ns. liittomuotoisesta TKHJstä
  (federated DBMS)

49

• TKHJn kustannukset
• datan saantipolkujen tyypit
• yleiskäyttöinen vai erikoiskäyttöön tarkoitettu
• erikoiskäyttöön tarkoitettua TKHJtä ei voida
  helposti muuntaa muuhun tarkoitukseen
  käytettäväksi (esim. lentoyhtiöiden
  paikanvarausjärjestelmät)
• lyhyt vasteaika tärkeä kriteeri TKHJn
  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).

50

•  
• Verkkomallissa data esitetään joukkotyyppisenä
  linkitettyjen tietueiden avulla
• riippuvuussuhde 1N (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  

3. Datan mallintaminen ER-mallin avulla

• ER (Entity Relationship) tarkoittaa
  kokonaisuuksien välisiä suhteita.
• Käsitteellinen mallinnus on tärkeää
  tietokantasovellusten suunnittelussa
• Tietokannan käyttöönottovaihetta edeltävät aina
  suunnittelu, toteutus ja sovellusohjelmien testaus

51
3.1. Korkean tason käsitemalli tietokannan
suunnittelun apuvälineenä

• Tietokannan suunnitteluvaihe muistuttaa jonkin
  verran yleistä ohjelmien suunnittelua.
• ER-malli on korkean tason käsitemalli, jota
  käytetään yleisesti hyväksi tietokantaa
  suunniteltaessa.

• Vaiheet tietokannan suunnittelussa nähtävissä
  seuraavan sivun kaaviossa.

52
(No Transcript)
53
Eteneminen alkutekijöistä kohti valmista
tietokantaa

• Tarpeiden kartoittaminen ja analysointi
• selvitetään käyttäjiltä kysymällä, mitä kaikkia
  tietoja tietokannassa tulisi olla saatavilla
• tarpeelliset tiedot ja toiminnot pitäisi
  selvittää niin tarkoin kuin mahdollista
• käytetään apuna tietovuokaavioita yms.
  suunnittelua helpottavia menetelmiä
• ? tavoitteena muodostaa kokonaiskäsitys
  tiedon ja toimintojen tarpeesta
  tietokannassa
• Muodostetaan tietokannan käsitekaava käyttämällä
  korkean tason tietomallia
• tarvittavat kokonaisuudet, suhteet ja säännöt
  määritellään
• fyysiseen toteutukseen ei oteta tässä vaiheessa
  kantaa
• selvitetään, että kaikkien osapuolten
  tietotarpeet esiintyvät käsitekaavassa ja
  etteivät eri käyttäjäryhmien asettamat
  vaatimukset ole ristiriitaisia keskenään
• jos käsitekaava osoittautuu virheelliseksi tai
  puutteelliseksi, tehdään tarvittavat muutokset

54

• Rinnakkaisesti tai hieman jälkeenpäin voidaan
  käsitekaavaan perustuen yrittää hahmottaa
  toiminnallisessa eli funktionaalisessa
  analyysissä todetut käyttäjien tarvitsemat
  operaatiot.
• Jos käsitekaava on riittämätön toimintojen
  mallintamiseen, sitä voidaan uusia.
• Kun kaikki tahot ovat tyytyväisiä tietokannan
  määriteltyihin ominaisuuksiin, on aika aloittaa
  sen käytännön toteuttaminen (implementointi).
  Tätä vaihetta kutsutaan tietokannan loogiseksi
  suunnitteluksi. Siinä muunnetaan korkean tason
  tietomallin mukainen kuvaus TKHJlle sopivaan
  muotoon (esimerkiksi relaatiomallin mukaiseksi).
• Loogisen kaavan valmistuttua voidaan aloittaa
  kyseiseen kaavaan perustuva sovellusohjelmien
  suunnittelu sekä tietokannan fyysisen
  tallennus-rakenteen suunnittelu, jonka tuloksena
  saadaan tietokannan sisäinen kaava.

55
3.2. Esimerkki tietokantasovelluksesta

• Sisäiseen kaavaan perustuen voidaan optimoida
  tietokantaa hyödyntävät valmiit sovellusohjelmat.
•  
• Sovellusohjelmien valmistuttua tietokannan
  pitäisi nyt ihannetilanteessa vastata täysin sen
  kaikkien käyttäjätahojen sille asettamia
  odotuksia.

• Tavoitteena on rakentaa toimiva
  tietokantasovellus yhtä yritystä varten.
  Yritys edustaa tapauksessamme siten sovelluksen
  kohteena olevaa "pienoismaailmaa".
  Oletetaan, että seuraavat tiedot on saatu
  selville kartoitettaessa tietokannalle
  asetettavia vaatimuksia

• Yritys on jakautunut osastoihin. Kullakin
  osastolla on yksikäsitteinen nimi ja yksi
  johtaja. Johtajan tehtävässään
  aloittamispäivämäärä kirjataan muistiin.
  Yksittäisellä osastolla voi olla toimintaa
  usealla paikkakunnalla.

56

• Osasto kontrolloi projekteja, joilla kullakin on
  yksikäsitteinen nimi ja koodinumero sekä yksi
  sijaintipaikka.
• Jokaisesta yrityksen työntekijästä kirjataan
  nimi, henkilötunnus, osoite, kuukausipalkka,
  sukupuoli ja syntymäaika. Lisäksi oletetaan, että
  kukin työntekijä on kirjoilla tarkalleen yhdellä
  osastolla, mutta hän voi työskennellä usean eri
  osaston kontrolloimassa projektissa. Lisäksi
  halutaan pitää yllä tietoa työntekijän
  viikoittaisista työtunneista kussakin eri
  projektissa, joissa hän työskentelee. Myös tieto
  kunkin työntekijän lähimmästä esimiehestä pitää
  olla saatavilla.
• Vielä halutaan pitää kirjaa kunkin työntekijän
  mahdollisista perheenjäsenistä. Heistä on
  tiedettävä etunimi, sukupuoli, syntymäaika sekä
  asema perheessä työntekijään nähden.
• Kirjan esimerkissä 3.2. on nähtävillä tietokannan
  suunnittelutyön lopputuloksena syntynyt ER-mallin
  mukainen käsitekaava.
• Jatkossa tullaan käymään läpi vaiheet, miten
  kyseiseen kaavaan on päädytty. Samoin esitellään
  kaavassa esiintyvien merkintöjen tulkinta.

57
3.3. Entiteettityypit, entiteettijoukot,
attribuutit ja avaimet
3.3.1. Entiteetit ja attribuutit

• ER-malli perustuu datan kuvaamiseen entiteettien,
  attribuuttien ja suhteiden avulla.
• Entiteetti on jokin reaalimaailmassa esiintyvä
  itsenäinen käsite, joka voi olla joko fyysinen
  tai käsitteellinen.
• esimerkiksi henkilö, auto, työntekijä jne. ovat
  fyysisiä entiteettejä
• vastaavasti yliopiston kurssi, luennointikerta
  jne. ovat käsitteellisiä entiteettejä
• entiteettiä relaatiotietokannassa edustaa
  yksittäinen taulu (esimerkiksi opiskelijan ja
  kurssin perustietotaulu jne.), ja entiteetin
  nimike pyrkii kuvaamaan sitä osuvasti.
• Entiteetille tyypillisiä ominaisuuksia kutsutaan
  attribuuteiksi. Attribuutit ovat siten
  entiteettiin kuuluvia tietokenttiä.

58

• Entiteetille tyypillisiä ominaisuuksia kutsutaan
  attribuuteiksi. Attribuutit ovat siten
  entiteettiin kuuluvia tietokenttiä.
• Esimerkiksi nimi, ikä, osoite ja puhelinnumero
  ovat tyypillisiä yksittäiseen työntekijään
  liittyviä ominaisuuksia.
• Attribuutti voi olla joko yksinkertainen tai
  koottu
• yksinkertaisen attribuutin arvo on selkeästi
  jakamaton (esimerkiksi henkilön pituus)
• koottua attribuuttia voidaan käsitellä
  kulloisenkin tarpeen mukaisesti joko kokonaisena
  tai ositettuna (esimerkiksi henkilön nimen
  voidaan olettaa koostuvan etunimestä, toisen
  nimen alkukirjaimesta ja sukunimestä)
• Lisäksi attribuutti voi olla joko yksi- tai
  moniarvoinen
• yksiarvoinen attribuutti tarkoittaa ominaisuutta,
  joka ei voi saada kuin yhden arvon kerrallaan
  (esimerkiksi ikä)
•  moniarvoinen attribuutti voi saada
  samanaikaisesti useita eri arvoja (esimerkiksi
  henkilön suorittamat tutkinnot)

59

• Attribuutti voi olla joko tallennettu tai
  johdettu.
• Tallennetun attribuutin arvo ei ole pääteltävissä
  muiden attribuuttien avulla (esimerkiksi henkilön
  kotiosoite)
• Johdetun attribuutin arvo on pääteltävissä tai
  laskettavissa tallennettujen attribuuttien
  perusteella (esimerkiksi ikä voidaan laskea, jos
  tiedetään nykyinen päivämäärä ja henkilön
  syntymäaika)
• Johdettu attribuutti voi liittyä myös koko
  entiteetin ominaisuuteen eikä välttämättä
  erikseen jokaiseen tietueeseen (esimerkiksi
  opiskelijoiden kokonaismäärä saadaan laskemalla
  tietueiden lukumäärä opiskelijataulusta)
• Toisinaan myös puuttuvat arvot attribuutille ovat
  sallittuja, kunhan kyseessä ei ole ns.
  avainattribuutti.
• puuttuvan arvon tulkinta on joko 'ei ole
  olemassa/ laskettavissa' (esimerkiksi henkilön
  esimies, jos hän sattuu olemaan yrityksen
  toimitusjohtaja) tai 'tuntematon' (ei tiedetä,
  onko arvo olemassa)
• ryhmä 'tuntematon' jakaantuu vielä kahteen
  alaryhmään

60
3.3.2. Entiteettityypit ja -joukot, avaimet ja
arvojoukot

• "tieto varmasti olemassa, muttei tiedossa"
  (esimerkiksi henkilön pituus ja paino)
• "ei tietoa, onko olemassa" (esimerkiksi
  puhelinnumero - voi olla salainen)
• kompleksiset attribuutit
• yhdistelmä koottuja ja moniarvoisia attribuutteja
  (esimerkiksi tilanne, jossa henkilöllä on
  useampia asuntoja, joihin voi olla lisäksi useita
  puhelinnumeroita).

• Entiteettityyppi määrittelee kokoelman entiteetin
  edustajia, joilla on samat attribuutit
  (esimerkiksi tyyppi, joka kuvaa opiskelijan
  perustietoja).
• Entiteettijoukko kuvaa tietyn entiteettityypin
  kaikkia edustajia (esimerkiksi kaikkia
  yksittäisiä opiskelijoita esittäviä tietueita).

61

• Usein termiä entiteetti käytetään kummassakin
  edellä mainitussa merkityksessä, eli
  tarkoittamaan sekä kokonaisuutta kuvaavia
  ominaisuuksia että sen yksittäisten edustajien
  joukkoa
• Entiteettityppiä kuvaa ER-kaaviossa
  yksinkertaisilla viivoilla merkitty suorakulmio,
  jonka sisällä on entiteetin nimi, joka merkitään
  pelkkiä isoja kirjaimia käyttämällä.
• Sellaista attribuuttia tai niiden yhdistelmää,
  joka yksikäsitteisesti identifioi
  entiteettijoukon yksittäisen jäsenen (tietueen),
  kutsutaan entiteettityypin avaimeksi.
• Avainattribuutti on usein yksittäinen attribuutti
  (esimerkiksi henkilötunnus), mutta
  yksikäsitteisyyden saavuttaminen saattaa vaatia
  useamman attribuutin yhdistelmän valitsemista
  avaimeksi (esimerkki projektit, joissa henkilö
  työskentelee).
• Entiteettijoukon nykytilassa vallitseva
  yksikäsitteisyys on attribuutin avaimeksi
  kelpaamisen kannalta välttämätön, muttei riittävä
  ehto (kts. yliopisto-tietokannan opiskelijoiden
  perustiedot). Pitää kiinnittää huomiota
  tietokannan määrittelyssä asetettuihin ehtoihin
  sen rakenteesta.

62

• Avaimeksi voi kelvata useampiakin kuin yksi
  attribuutti tai niiden yhdistelmä (esimerkiksi
  auton rekisteri- ja valmistenumero).
• Avaimen on oltava minimaalinen. Tämä tarkoittaa,
  ettei avaimeen pidä ottaa mukaan muita kuin
  sellaisia attribuutteja, jotka ovat
  välttämättömiä yksikäsitteisyyden
  saavuttamiseksi.
• Entiteettityyppiä, jolla ei ole lainkaan omaa
  avainattribuuttia, kutsutaan heikoksi
  entiteetiksi.Entiteettityypin avaimeen kuuluvat
  attribuutit merkitään ER-kaavioon
  alleviivattuina.
• Jokaiseen attribuuttiin liitty ns. arvojoukko,
  joka määrää, millaisia arvoja sillä voi esiintyä
  (esimerkiksi rajoitettu kokonaislukualue,
  enintään tietyn mittainen merkkijono jne.).
• Arvojoukko on matemaattisesti ymmärrettävissä
  kuvauksena entiteettityypiltä arvojoukon
  potenssijoukkoon (kaikkien mahdollisten
  alijoukkojen joukkoon).

63
3.3.3. Yrityksen tietokannan alustava
käsitteellinen suunnittelu

• puuttuvaa arvoa edustaa tyhjä joukko
• yksiarvoista attribuuttia yksittäisten
  laillisten arvojen joukko
• moniarvoista attribuuttia kaikki yhdistelmät,
  joita esiintyy entiteettijoukossa
• yhdistettyä attribuuttia sen kaikkien
  osakomponenttien välinen karteesinen
  tulo

• Lähdetään rakentamaan ER-kaaviota kappaleessa
  3.2. esiteltyjen vaatimusten mukaiselle
  tietokannalle.
• Osasto sisältää attribuutit Nimi, Numero,
  Toimipisteet, Johtaja ja JohtajanAloituspäivä
  . Koska sekä Nimi että Numero vaadittiin
  yksikäsitteisiksi, kumpikin näistä kelpaa
  erilliseksi avaimeksi.
• Projektiin tarvitaan attribuutit Nimi, Numero,
  Sijaintipaikka ja KontrolloivaOsasto. Sekä
  Nimi että Numero kelpaavat avaimeksi.

64

• Työntekijästä tallennetaan attribuutit Nimi,
  Hetu, Sukupuoli, Osoite, Kuukausipalkka,
  Syntymäaika, Osasto ja Esimies. Nimi ja Osoite
  voitaisiin esittää sekä yksinkertaisina että
  koottuina attribuutteina
• ---gt kysyttävä lisätietoa käyttäjiltä.
• Perheenjäsenistä tarvitaan attribuuteiksi
  Työntekijä, Perheenjäsenen nimi, Sukupuoli,
  Syntymäaika ja Perhesuhde työntekijään.
• Edelleen pitäisi pystyä esittämään, että
  työntekijä voi toimia useassa eri projektissa, ja
  myös tehdyt työtunnit pitäisi kirjata.
• ---gt olisi lisättävä työntekijä-entiteettityy
  ppiin moniarvoinen koottu attribuutti
  Työskentelee(Projekti, Tunnit) tai
  projekti-entiteettityyppiin moniarvoinen
  attribuutti Työsuoritukset(Työntekijä, Tunnit).
• ---gt kysytään taas lisää
  käyttäjiltä, jotka haluavat mieluummin
  ensimmäisen vaihtoehdon.

65
3.4. Suhteet ja niiden tyypit, roolit ja
rakenteelliset rajoitukset

• Tällä kurssilla suhde ? relaatio.
• Edellisissä määrityksissä on useita
  implisiittisiä riippuvuuksia, eli
  tietyn entiteettityypin attribuutti viittaa
  selkeästi johonkin toiseen entiteettiin
  (esimerkiksi Osaston johtaja --gt Työntekijä,
  Projektia kontrolloiva osasto --gt Osaston
  tiedot, Työntekijän esimies --gt Työntekijä,
  Työntekijän osasto --gt Osaston tiedot).
• Implisiittiset riippuvuudet kannattaa esitellä
  pikemminkin suhteina kuin attribuutteina,
  vaikka aluksi niiden esittely attribuutteina
  onkin mahdollista --gt käsitekaava
  tarkentuu asteittain.

•   

3.4.1. Suhteiden tyypit, joukot ja esiintymät

• Tällä kurssilla suhde ? relaatio.
• Relaatioon osallistuu vähintään kaksi
  entiteettityyppiä. Kahden entiteettityypin
  välinen relaatiota sanotaan binääriseksi, kolmen
  ternääriseksi jne.

66

• Sama entiteettityyppi voi osallistua relaatioon
  useammin kuin yhden kerran.
• Suhteen esiintymällä ri tarkoitetaan kokoelmaa
  (e1, e2, e3, ..., en), jossa eit ovat siihen
  osallistuvien entiteettien E1, E2, ..., En
  yksittäisiä esiintymiä). Jos kyseessä on
  binäärinen relaatio, n2.
• Jokainen entiteettityypeistä E1, E2, ..., En
  osallistuu niiden välille määriteltyyn
  relaatioon.
• Esimerkki binäärisestä relaatiosta työntekijän
  työskenteleminen projektissa
• --gt työntekijäentiteettiä edustava esiintymä
  liitetään projektia esittävän esiintymän
  kanssa (kts. kirjan esimerkki 3.9.)
• Esimerkki ternäärisestä relaatiosta tavaran, sen
  toimittajan ja toimituksen kohteena olevan
  projektin liittäminen toisiinsa (kts. kirjan
  esimerkki 3.10.)
• Relaatiota voidaan kuvailla attribuuttien avulla.
  Esimerkiksi työntekijän työskentelyä jonkin
  osaston laskuun voidaan kuvata työntekijän
  mahdollisena yksiarvoisena attribuuttina Osasto.
  Sama toimii myös toisin päin yhtäläisesti
  kutakin osastoa kohti voisi olla määriteltynä
  moniarvoinen attribuutti nimeltä
  OsastonTyöntekijät, joka olisi luettelo
  työntekijöistä, jotka ovat töissä tietyllä
  osastolla.

67
3.4.3. Rajoitukset suhteiden tyypeille

• Roolinimellä tarkoitetaan ominaisuutta,
  jollai