KURSSIMONISTE KEVÄT 2009

Transkriptio

1 1 CT20A4301 Tietokannat 5 op KURSSIMONISTE KEVÄT 2009 Koonnut: Erja Mustonen-Ollila

2 CT20A4301 Tietokannat -kurssin sisältö ja suorittaminen Kevään luento- ja harjoitusaikataulu Mustonen-Ollila Erja Tietokantojen luennot pidetään tänä keväänä intensiivisesti sekä perusopiskelijoille että digiopiskelijoille neljänä peräkkäisenä perjantaina seuraavasti: 1. pe klo salissa pe klo salissa pe klo salissa pe klo salissa 1382 Harjoitukset perusopiskelijolle ja digeille pidetään myös intensiivisesti. Perusopiskelijoille se merkitsee sitä, että harjoituksia on 7 viikon aikana 2 kertaa viikossa a' 2 h kerrallaan, yhteensä siis 4 h/vko seitsemän viikon aikana. Viikolla HRa ja HRb- harjoitukset ovat eri harjoitukset, joten opiskelija voi valita itse, osallistuuko HR1a ja HR1b- harjoituksiin, vaiko esim. HR1a ja HR3b- harjoituksiin kyseisellä samalla viikolla. Harjoitukset pidetään mikroluokassa 6428, paitsi ensimmäisen kalenteriviikon harjoitukset luokassa 3305, koska luokkaa 6428 tarvitaan CopeCamp- kurssille. Perusopiskelijoiden harjoitukset pidetään seuraavasti: 5. kalenteriviikko (ei siis luentoviikko!): ma 26.1.klo HR1a, salissa ti klo HR1b, salissa ti klo HR2a, salissa 4410 ti klo HR2b, salissa 3305 ke klo HR3a, salissa 3305 ke klo HR3b, salissa kalenteriviikko ma 2.2.klo HR1a. ti klo HR1b. ti 3.2. klo HR2a ti 3.2. klo HR2b ke 4.2. klo HR3a ke 4.2. klo HR3b

3 3 7. kalenteriviikko ma 9.2.klo HR1a. ti klo HR1b. ti klo HR2a ti klo HR2b ke 11.2 klo HR3a ke klo HR3b 8. kalenteriviikko ma 16.2.klo HR1a. ti klo HR1b. ti klo HR2a ti klo HR2b ke klo HR3a ke klo HR3b 9. kalenteriviikko ma 23.2.klo HR1a. ti klo HR1b. ti klo HR2a ti klo HR2b ke klo HR3a ke klo HR3b 11. kalenteriviikko ma 9.3.klo HR1a. ti klo HR1b. ti klo HR2a ti klo HR2b ke klo HR3a ke klo HR3b

4 4 12. kalenteriviikko ma 16.3.klo HR1a. ti klo HR1b. ti klo HR2a ti klo HR2b ke klo HR3a ke klo HR3b Digitaalisen viestinnän ja tietojohtamisen opiskelijoille harjoitukset pidetään neljänä lauantaina seuraavasti: la klo 9-16 la 7.2. klo 9-16 la klo 9-16 la klo 9-16 Harjoitustöiden palautuspäivä on kello joko sähköisesti sähköpostin liitteenä tai paperilla Tieto-Sähkötalon 7. kerroksen postilaatikkoon. Viimemainitussa tapauksessa sähköpostia kurssia luennoijalle siitä, että työ on palautettu. SQL-verkkokurssin suoritusaika on saakka. Kurssin suoritusohjeet ja www-sivu: Kurssin ilmoitustaulu, jota on syytä seurata viikottain: 1) Luentoja, 28 tuntia (intensiivisesti neljänä perjantaina, katso yllä aikataulu). Luentomateriaali tulee olemaan kurssin www-sivuilla.pdf- tiedostona kohdassa Luennot ja se on sieltä tulostettavissa. Kurssimoniste on saatavissa Aalef-kirjakaupasta ennen 1. luentoja, jotka pidetään ) Harjoitukset, 28 h (intensiivisesti, katso yllä aikataulu). Huomaa, että perusopiskelijoille ja digitaalisen viestinnän ja tietojohtamisen opiskelijoille on oma harjoitusaikataulunsa. Harjoituksissa käytetään sekä PostgreSQL:ää että Access-tietokantaa että tehdään käsitteelistä mallinnusta. PostgreSQL:ää käytetään harjoituksissa www-sivuilla annettavien ohjeiden mukaan. Vastaavasti toimitaan Access- tietokannan kanssa. Harjoitustehtävät ja niiden ratkaisut tulevat olemaan kurssin www-sivuilla kohdassa Harjoitukset.

5 5 3a) Perusharjoitustyö Kurssin harjoitustyö tehdään 1-3 hengen ryhmissä Access-tietokantaohjelmalla/myös muu tietokantaohjelma sopii. Arvostelu on hylätty/hyväksytty. Tarkemmat harjoitustyöohjeet ja palautusohjeet ovat kurssin www-sivuilla. Harjoitustyöaiheen voi valita myös itse kurssin wwwsivuilta. Harjoitustyön tavoitteena on antaa valmius suunnitella ja toteuttaa relaatiotietokantapohjainen järjestelmä ja oppia relaatiotietokannoista. Palautuspäivä on kello joko sähköisesti sähköpostin liitteenä tai paperilla Tieto-Sähkötalon 7. kerroksen postilaatikkoon. Viimemainitussa tapauksessa sähköpostia kurssia luennoijalle siitä, että työ on palautettu. Harjoitustyöohje ja harjoitustyövaihtoehdot tulevat olemaan kurssin www-sivuilla kohdassa Harjoitustyöt. 3b) Laaja harjoitustyö (koko kurssin suorittaminen) Opiskelijalla on myös mahdollista suorittaa koko kurssia tekemällä laajan harjoitustyön itsenäisesti. Tässä tapauksessa opiskelija saa loppuarvosanan suoraan harjoitustyöstä ja kurssia ei siis tarvitse tenttiä, ei osallistua SQL-verkko-opiskeluun tai tehdä perusharjoitustyötä. Aiheesta ja sen laajuudesta tulee sopia erikseen luennoijan kanssa. Aihe voi esimerkiksi liittyä opiskelijan työpaikassaan tekemään työhön, jolloin sen luovuttamisesta kurssin harjoitustyöksi tulee saada myös työpaikan esimiehen lupa. Palautuspäivä on perjantaina kello joko sähköisesti sähköpostin liitteenä tai paperilla Tieto-Sähkötalon 7. kerroksen postilaatikkoon. Viimemainitussa tapauksessa sähköpostia kurssin luennoijalle siitä, että työ on palautettu. 4) VIOPE-SQL-verkkokurssi (vapaaehtoinen) SQL-verkkokurssin onnistuneesti läpäissyt saa korvata tentissä tentin SQL-kysymyksen ja jonkun toisen kysymyksen ( yhteensä 16 pistettä). Ohjeet SQL-verkkokurssista ovat kurssin www-sivuille (ilmoittautumiset yms.) 16 pistettä vastaa arvosanaa 1.Viope-suorituksella on siis mahdollista saada kurssi läpi arvosanalla 1 ilman tenttimistä. HUOM! Jos opiskelija tulee tenttiin, niin hän vastaa VAIN 2 kysymykseen, jos SQL-Viope verkkokurssi on suoritettu. Ilman verkkokurssin suoritusta opiskelija vastaa 4 kysymykseen tentissä. Kurssin suoritusaika on saakka. HUOM! SQL-Viope kurssille ilmoittautumisohjeet tulevat kurssin Ilmoitustaululle ensimmäisiä luentoja: ennen SQL-linkki tulee olemaan myös kurssin www-sivuilla kohdassa SQL-verkkokurssi. Luennoija ohjaa verkkokurssia viikottain. 5) Access- itseopiskeluopas Opas niitä opiskelijoita varten, jotka jostain syystä eivät pääse Access-harjoituksiin. Itseopiskelupaketti löytyy osoitteesta

6 6) Kurssin www-sivut ja ilmoitustaulu 6 Ilmoitustaulua ja kurssin www-sivuja on syytä seurata koko kurssin ajan, koska siellä informoidaan muutokset (luento, harjoitus yms. jonkun syyn takia esim. siirto toiseen ajankohtaan). 7) Tentit Kurssiin kuuluu tentti (3 eri tenttikertaa mahdollista). Opiskelijan on itsensä huolehdittava tenttiilmoittautumisesta. Kurssin tentissä on 4 kysymystä, jotka kukin vastaavat 8 täyttä pistettä. SQL- Viope verkkokurssista voi saada 16 p eli arvosanan 1 suoraan ilman tenttimistä. 8) Kurssin loppuarvosana Kurssin loppuarvosanan saamiseksi on opiskelijan suoritettava: tentti hyväksytyllä arvosanalla (minimissään 1) TAI SQL-verkkokurssi (suoritus vastaa arvosanaa 1). Kummassakin suoritustapauksessa on hyväksytysti myös suoritettava perusharjoitustyö. TAI b) Laaja itsenäisesti tehtävä harjoitustyö, jolloin loppuarvosana tulee suoraan harjoitustyön arvosanasta ilman tenttiä ja SQL-verkkokurssin suorittamista. 9) Vanhojen harjoitustöiden ja tenttien vastaavuus nykyiseen kurssiin. Lähettämällä luennoijalle sähköpostilla weboodista sen rekisteritiedon, jossa näkyy, että opiskelija on tenttinyt tentin aiemmin tai tehnyt harjoitustyön aiemmin, on mahdollista suorittaa kurssista vain se osa, joka puuttuu loppusuorituksesta. Vanhat SQL-viope suoritukset katsotaan tapaus kerrallaan, että ovatko ne voimassa. Jos tentti on tentitty ennen tämän kurssin ensimmäistä tenttiä, niin saatava opintopistemäärä määräytyy kyseisen tentin opintopistemäärän mukaan. Loppuarvosana tässä tapauksessa määräytyy myös tenttiarvosanan mukaan. 10) Kurssipalaute Kurssin loppupuolella luennoija lähettää palautekyselyn opiskelijoille vastattavaksi. Kaikissa kurssiin liittyvissä asioissa voi ottaa yhteyttä kurssin luennoijaan, erja.mustonen-ollila@lut.fi Onnea kurssille!

7 7 Relaatiotietokannat... 8 Tiedonhallinnan historiaa... 8 Tiedonhallintajärjestelmän perusteita Relaatiotietokantojen tasot ja kuvausmallit Relaatiotietokannan perusteet ja termistöä Relaatiomalli Käsitenalyysi Käsiteanalyysin pohja: ER-malli (entity-relationships model) Relaatioalgebran perusoperaatiot Tietokannan suunnittelu- ja toteutusprosessi Tietokannan suunnittelun vaiheet ER-mallintamisen peruskäsitteet ER-kaaviosta relaatiomalliksi: esimerkkejä ER-mallista relaatioiksi säännöt Tietokannan normalisointi SQL-kieli Oliotietokannat Olio-relaatiomalli Open Database Connectivity (ODBC) ja OLE DB Oliotietokannat ja OQL Oliosuuntautuneet tietokannat Olion identiteetti, olion rakenne ja tyypin rakentajat OQL SQL-3 (SQL:99) MSACCESSIN PERUSTEET Liite 1. Relaatiomallin ja suunnittelun perusteita: harjoitustehtävät... 71

8 8 Relaatiotietokannat Kurssin relaatiotietokantojen osuus jäsentyy alla olevan kuvan 1 mukaisesti. Kuva 1. reaalimaailma Käyttäjä ja Käyttäjän toiveet mallinnus ERkaavio Tk:n määrit tely Lomake- Raportti yms. määr Tk:n käyttämi nen Muunto relaatioiksi relaatiomalli Tiedonhallinta- Järjestelmän ydin Thj:n käyttöliittymät Thj:n fyysiset liittymät Tietohakemisto Tietokanta Tiedonhallinnan historiaa Esihistoria Tietotekniikan "aamuhämärän" aikoihin 1800-luvulla käytettiin ensin reikäkortteja tietojen säilyttämiseeen koneella käsiteltävässä muodossa esim Yhdysvalloissa väestönlaskennoissa. Reikäkortit säilyivät käytössä pitkään 1970-luvulle, mutta eivät enää tietojen säilytyskäytössä, vaan lähinnä tapana siirtää tietoja tietokoneelle. Peräkkäistiedostojen historia alkoi paperisilla reikänauhoilla, jotka sitten 1960-luvulla korvautuivat magneettinauhoilla. Magneettinauhoja käytetään edelleenkin, tosin kätevämmässä muodossa eli magneettikasetteina ja lähinnä tiedostojen varmistamisessa. Levyt tulevat 1960-luvun lopulla tietokoneissa otettiin käyttöön "suorasaanti"-muisteja eli alkuun rumpumuisteja ja myöhemmin levymuisteja. Aluksi levyt olivat niin kalliita, että niitä käytettiin lähinnä

9 9 varusohjelmien pysyvään tallettamiseen ja sovellusohjelmien ajossa työtiloina, mutta jo 1970-luvulla levyjen hinnat halpenivat niin, että myös "tavallisia" tiedostoja talletettiin levyille. Tiedostojen käsittely 1970-luvun alkuun saakka oli pitkälti kuitenkin tiedostojen peräkkäiskäsittelyä. Varsinaisen sysäyksen tiedostojen hajakäsittelytarpeelle toivat kuitenkin näyttöpäätteet, jotka mullistivat koko tietojenkäsittelyn perusidean. Aiemmin ajettiin eräajoja ja selattiin listoja, nyt oli mahdollisuus saada näyttöpäätteelle esille halutut tiedot. Tiedostokäsittelyyn tämä tarve loi hajakäsittelyn ja taulukoidut peräkkäistiedostot. Tiedostoissa on hakutaulukot (istiedostot eli indeksoidut peräkkäistiedostot), joiden avulla tiedostosta voidaan etsiä avainten avulla tietoja. Nämä tiedostot ovat edelleenkin vahvoja ja käteviä, jos tiedetään ennakolta muutama keskeinen avain, joiden avulla ainoastaan hakuja tarvitaan (ts operatiivisessa työssä usein riittävää, mutta ei ehkä sitten satunnaiskyselyissä tai raportoinnissa ). Tietokantojen alku Avaruus- ja sotatekniikka ovat tuottaneet monia siviilielämää hyödyttäviä keksintöjä. Niin myös tietotekniikan alalla. Yhdysvallat ryhtyi 1960-luvulla valmistelemaan lentoa kuuhun (toteutui 1969). Tätä APOLLO-projektia varten alettiin kehittää hierarkkista tietokantaa. Tietokannan nimi oli GUAM (Generalized Update Access Method) ja kehittäjä North American Aviation (nykyinen Rockwell International). Myöhemmin IBM kehitti tälle seuraajan, josta tuli tärkein hierarkinen tietokantajärjestelmä eli IMS (Information Management System). General Electric ryhtyi samoihin aikoihin kehittelemään ns "verkkotietokantaa", mikä ei tässä tarkoita tietokoneverkkoa, vaan hierarkkista tietorakennetta monipuolisempaa rakennetta. Tuotteen nimi oli IDS (Integrated Data/Store). Kovin laajaan kaupalliseen käyttöön vielä 1970-luvulla ei kumpikaan idea johtanut, sillä tietokantaohjelmistot olivat valtavan laajoja (silloisten tietokoneiden kapasiteetin kannalta) ja myöskin kalliita (myös nykyrahassa). Näiden kahden suuntauksen eli hierarkisen ja verkkorakenteen pohjalta yritettiin määritellä ns CODASYL- standardia (Conference on Data Systems Languages), mistä sitten palasia rupesi valmistumaan 1970-luvun alkupuolella. Niissä oli muutama hyvä oivallus: tiedon määrittelykieli eli data definition language sekä tiedon käsittelykieli eli data manipulation language ja perusideat (fyysinen tietoriippumattomuus ja looginen tietoriippumattomuus)

10 Tiedonhallintajärjestelmän perusteita 10 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

11 11 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

12 12 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 U- lukituksia 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:

13 13 - 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* Tilin saldo Tilin omistaja Tilin tyyppi , Luotollinen , Karttuva Henktaulu hetu* nimi lähiosoite Postitmp Matti Mattila Kaivokatu 12 A Hki Aino Kallas Alkutie 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

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

15 Relaatiomalli 15 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.

16 Käsiteanalyysin eteneminen vaiheittain: 16 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

17 17 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,

18 18 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 Piiritaulu Myyjänro Mynimi MPnro Pnro Pnimi M1 Pirkko P1 P1 Länsi M2 Maija P2 P2 Itä M3 Kalle P2 M4 Saku P1 Myyjätaulu join Piiritaulu Myyjänro Mynimi MPnro Pnimi M1 Pirkko P1 Länsi M2 Maija P2 Itä M3 Kalle P2 Itä M4 Saku P1 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.

19 19 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 Piiri2 Mnro Mnimi MPnro Mnro Mnimi MPnro M1 Pirkko P1 M2 Maija P2 M4 Saku P1 M3 Kalle P3 Piiri1 union Piiri2 Mnro Mnimi MPnro M1 Pirkko P1 M2 Maija P2 M3 Kalle P3 M4 Saku P1 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 MPnro M2 Maija 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

20 20 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 Tietokannan määrittely Käyttöliittymän suunnittelu 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ä

21 21 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

22 22 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

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

24 24 Alla on esitetty esimerkki tietohakemistosta Henkilö Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset VARCHAR(64) Pitää sotu CHAR(11) Sallitaan myös pelkkä syntymäaika etunimi VARCHAR(32) sukunimi VARCHAR(64) kotisivu VARCHAR(128) pitää alkaa puh VARCHAR(32) fax VARCHAR(32) katuosoite VARCHAR(64) postitoimipaikka VARCHAR(64) postinro CHAR(5) Aina viisi merkkiä Paikkakunta Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset PID AUTOINCREMENT Oppilaitos VARCHAR(128) VARCHAR(64) pitää kotisivu VARCHAR(128) pitää alkaa puh VARCHAR(32) fax VARCHAR(32) katuosoite VARCHAR(64) postitoimipaikka VARCHAR(64) postinro CHAR(5) Aina viisi merkkiä Postituslista VARCHAR(64) Pitää Tyyppi Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset TyyppiID AUTOINCREMENT Tyyppinimi VARCHAR(64) Harjoitustyö Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset INTEGER koodi INTEGER TyoNro SMALLINT Arvot alkavat ykkösestä jokaisella kurssilla URL VARCHAR(128) Pitää alkaa Aihe VARCHAR(128) Pvm DATE Bonus DOUBLE Ei sallita negatiivisia arvoja. Oletusarvo on nolla. Formaatti

25 Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset FID AUTOINCREMENT Tiedostopaate VARCHAR(3) Tiedostomuoto VARCHAR(64) Kurssi Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset Koodi CHAR(6) Aina kuusi merkkiä Nimi VARCHAR(64) OV DOUBLE Sallitaan kokonaisluvut ja puolikkaat Kotisivu VARCHAR(128) Pitää alkaa htlkm SMALLINT Arvosanat Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset SarjaID INTEGER Pistemaara DOUBLE Arvosana VARCHAR(50) Arvosana voi olla sanallinen esim. Hylätty Tentti Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset TenttiID AUTOINCREMENT Pvm DATE Suoritus Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset INTEGER TID INTEGER Nro SMALLINT Pisteet DOUBLE Tilaa Ominaisuus Tietotyyppi Sisältörajoitteet ja -tarkistukset Toimituspvm DATE Tilauspvm DATE Toim.os VARCHAR(50) 25

26 Alla on esitetty esimerkkejä ER-mallinnuksesta 26 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:

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

28 28 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 autot kohde myynti ostaja 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:

29 merkki 29 rekno Kuva 6 auto isa isa isa hauto kauto bussi Henk edessä Pyörien lkm istumapaik 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

30 30 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ä).

31 31 ER-kaaviosta relaatiomalliksi: esimerkkejä Edellä esitetystä ER-esimerkistä 1 (autot-henkilöt) on tehty seuraavat neljä erilaista relaatioratkaisua. Mikä tai mitkä niistä ovat mielestänne hyviä ja mitkä huonoja ja miksi? autot omistami nen henkilöt vaihtoehto 1 henkilot autot hetu nimi osoite rekno merkki hetu Ojala Kaivokatu SYR-456 Volvo Ville Mattila Ojakuja 3 ABC-345 Saab Kai Simola Ojatie 15 VCX-765 Saab Olli UIO-665 Ford IOP-876 BMW vaihtoehto 2 henkilot autot hetu nimi osoite rekno rekno merkki Ojala Kaivokatu SYR-456 SYR-456 Volvo Ville Mattila Ojakuja 3 UIO-665 ABC-345 Saab Kai Simola Ojatie 15 IOP-876 VCX-765 Saab Olli Ojala Kaivokatu ABC-345 UIO-665 Ford Ville Mattila Kai Ojakuja 3 UIO-665 IOP-876 BMW vaihtoehto 3 henkilot omistaminen hetu nimi osoite hetu rekno autot Ojala Kaivokatu SYR-456 rekno merkki Ville Mattila Ojakuja ABC-345 SYR-456 Volvo Kai Simola Ojatie VCX-765 ABC-345 Saab Olli UIO-665 VCX-765 Saab IOP-876 UIO-665 Ford IOP-876 BMW

32 vaihtoehto 4 rekno merkki rekpvm hetu nimi osoite SYR-456 Volvo Ojala Ville Kaivokatu 6 ABC-345 Saab Ojala Ville Kaivokatu 6 VCX-765 Saab Mattila Ojakuja 3 Kai UIO-665 Ford Mattila Ojakuja 3 Kai IOP-876 BMW Simola Olli Ojatie 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)

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

34 34 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 ovat täydellisesti funktionaalisesti riippuvia perusavaimesta. 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)

35 35 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 pinimi mnro mnimi mosoit tuote1 määrä1 tuote2 määr2 p1 länsi m1 pirkko hki t1 120 t9 75 p1 länsi m2 heikki hki t2 99 t4 111 p1 länsi m2 heikki hki t5 234 p2 itä m3 simo kuo t p2 itä m4 kaija ima t 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 mnro mnimi mpostinro mptmp p1 länsi m1 pirkko hki p1 länsi m2 heikki hki p2 itä m3 simo kuopio p2 itä m4 kaija imatra myyjä/tuotetaulukko mnro mnimi tuotenro määrä m1 pirkko t1 120 m1 pirkko t9 75 m2 heikki t2 99 m2 heikki t4 111 m2 heikki t5 234 m3 simo t m4 kaija t m4 kaija t4 221

36 Toinen normaalimuoto 36 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 määrä m1 t1 120 m1 t9 75 m2 t2 99 m2 t4 111 m2 t5 234 m3 t m4 t m4 t4 221 myyjätaulukko piirinro piirinnimi mnro mnimi mpostinro mptmp p1 länsi m1 pirkko hki p1 länsi m2 heikki hki p2 itä m3 simo kuopio p2 itä m4 kaija 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 Helsinki Helsinki Kuopio Imattra myyjätaulukko piiritaulukko piirinro mnro mnimi mpostinro piirinro piirinnimi p1 m1 pirkko p1 länsi p1 m2 heikki p1 länsi p2 m3 simo p2 itä p2 m4 kaija p2 itä

37 Neljäs normaalimuoto 37 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 nimi kielitaito 11 jussi engl 11 jussi saksa 11 jussi ruotsi 12 maija saksa 12 maija engl henk kielitaito hetu nimi hetu kieli 11 jussi 11 engl 12 maija 11 saksa 11 ruotsi 12 saksa 12 engl Yleistä SQL-kieli 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ä).

38 38 Eri sql-murteet eroavat tässä suhteessa aika lailla. Kuitenkin samat asiat voidaan kaikissa tehdä. Esim MsAccess-ohjelmassa taulun luonti tietokantaan voisi mennä näin (siis jos ei halua käyttää graafista määrittelytapaa): CREATE TABLE toverit ([hetu] text, [sukunimi] text, [etunimi] text, [ika] integer, CONSTRAINT [index1] PRIMARY KEY ([hetu])); DB2:ssä sama asia oli ainakin muutama vuosi sitten osapuilleen CREATE TABLE toverit ([hetu] char(11) UNIQUE [sukunimi] text(25) NOT NULL, [etunimi] text(20) NOT NULL, [ika] integer) 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;

39 SELECT ihmiset.nimi, ihmiset.huone, FROM ihmiset ORDER BY ihmiset.nimi DESC; 39 ihmiset.osasto 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 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] (asiakkaan numero kysytään) SELECT * FROM tilaus WHERE tilasnro = Forms![lomake1]![kentta2] tietystä kentästä) (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

40 where nimi = 'jussi rajamäki') 40 sql ja määritysmuutokset alter table toverit add sp int; alter table toverit drop sp; sql ja kannan 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ä 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; sql ja tietojen siirto tai päivitys toisesta taulusta Seuraavalla sivulla on lähtötilanteessa kolme taulua: henk-taulussa on henkilötietoja mm hetu talot-taulussa on talojen tietoja mm arvo ja omistaja temp-taulu on aputaulu inskysely laskee kuinka monta taloa kukin henkilö omistaa ja mikä on niiden arvo ja sitten lisää nämä rivit temp-tauluun up-kysely päivittää henk-taulun kpl ja arvoyht-tiedot temp-taulussa olevilla tiedoilla Jostain syystä tätä operaatiota ei näy voivan suorittaa yhdellä päivityskyselyllä, vaan ainoastaan tällaisen aputaulun avulla.

41 41 Upotettu 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.

42 Oliokäsitteitä Jokaisella tietokantaan talletetulla oliolla on oma yksilöllinen tunniste (object identifier, OID). OID on muuttumaton OID on 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. 42 Olioluokka Määrittää joukon, joka muodostuu rakenteeltaa ja ominaisuuksiltaan samanlaisista olioista. Malli/muotti, jonka mukaan voidaan uusia luokan 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 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',

43 new SuomOsoite('Piilokuja 14', ' Mörskäkylä') Etsitään työntekijät, joiden katuosoite on Piilokuja 14. SELECT name FROM tyontekijat WHERE Osoite.katu = 'Piilokuja 14' 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.

44 44 - 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 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. 4 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). 5 Jos talletettava tieto on monimutkaista, kuvia, ääntä, videokuvaa, muuttuvan kokoisia rakenteita. Tieto on lähellä tarvitsijaansa. Oliokantoja mainostetaan hyvänä ratkaisuna hajautetuille ratkaisuille 8 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 1Asiakas (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 12 Välimuistin valvoja: - hoitaa asynkroniset lukituspyynnät palvelimelle (asiakas huolehtii synkronisista) - vain yksi prosessi yhdessä koneessa - vähentää verkkoliikennettä asiakkaan ja palvelimen välillä 13

45 Olion identiteetti, olion rakenne ja tyypin rakentajat 45 Jokaisella tietokantaan talletetulla oliolla on järjestelmän generoima yksilöllinen tunniste (object identifier, OID). OID:n perusominaisuuksia ovat muuttumattomuus (immutable) ja ainutkertaisuus (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. 15 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. 16 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. 17 Tyyppi- ja luokkahierarkiat Oliotietokannat perustuvat tyyppi- tai luokkahierarkioiden käyttöön ja perintään. Vaikka ne ovat käsitteellisesti erilaisia, ne johtavat samanlaiseen lopputulokseen 18 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. 20 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). 21

46 46 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. 22 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. 23 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ä 24 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. 26 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. 27 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 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)

47 Suurten tietokantojen hallinta (indexing, access path selection, query optimization) 11. Samanaikaisten käyttäjien salliminen (serializable access) 12. Elpyminen laitteisto- ja ohjelmistovirheistä 13. Ennakoimattomat kyselyt (ad hoc queries) 30 The Object-Oriented Database System Manifesto Lisäpiirteet 1.Moniperiytyvyys 2. Tyyppien tarkistus ja tyyppien päättely 3. Hajautus 4. Suunnittelutransaktiot 5. Versiot 31 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ä 32

48 48 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. 36looginen/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. Lisätietoa standardien kehityksestä ja tilasta: Hhttp:// 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 Huudet 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ö talletetut proseduurit Uudet tietotyypit (Row & ADT) Liipasimet/herättimet 40

49 49 MSACCESSIN 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? ACCESSIN KOMPONENTIT Kaikki tietokantaan liittyvat tiedot sijaitsevat kahdessa tiedostossa (*.mdb ja *.ldb ). Taulu (table): Tauluihin syötetaan tietokantaan tulevat tiedot. Taulut ovat välttämättömiä:ilman tauluja ei ole tietokantaa, koska ei ole mitaan, mihin tietoja saisi tallennettua. Taulu koostuu tietueista eli riveista ja tietueet muodostuvat kentista eli sarakkeista. Kenttä on pienin tallennettavan tiedon yksikkö ( esim. asiakkaan nimi tai puhelinnumero ). Yhteen kuuluvat kentat muodostavat tietueen.

50 50 Tietue voi pitaa sisallaan esim. asiakkaan nimen, osoitteen, puhelinnumeron ja asiakastunnuksen. Kysely (query): Kyselyilla haetaan tauluista tietoja jatkokasittelya varten. Kyselyilla voidaan mm. ryhmitella tiedot uudelleen, poimia vain osa yhden taulun tiedoista, yhdistella monen taulun tietoja ja lajitella tiedot uudelleen. Lomake (form): Lomakkeella tiedot saadaan esitettya havainnollisemmin. Lomakkeen avulla seka tiedon selailu etta syöttö voidaan tehda selkeammaksi. Yhdelle lomakkeelle voidaan koota kaikki oleellisesti toisiinsa liittyvat tiedot vaikka eri tauluista. Lomakkeita laatiessa kannattaa harkita, pitäisikö niiden pohjana käyttää kyselyitä sen sijaan, että suoraan kytkisi ne taulujen kenttiin. Raportti (report): Raportti on siisti tapa esittää tauluihin syötetty tieto. Raporttiin voidaan koota monesta taulusta tietoja, tuottaa yhteenvetotietoja ja laskea kenttiä yhteen. Raportti voidaan tulosta joko näytölle tai kirjoittimelle. Raportteja laatiessa kannattaa harkita, pitäisikö niiden pohjana käyttää kyselyitä sen sijaan, että kytkisi ne taulujen kenttiin. Macro (macro): Makroilla voidaan automatisoida toistuvia toimintoja. Moduuli (module): Access Visual Basic-kielellä ohjelmoituja tietokantasovelluksen osia. HUOM! Accessin oma SQL-kieli muistuttaa tavallista SQL:ää, mutta syntaxissa on kuitenkin suuria eroja! OHJELMAN KAYNNISTYS JA LOPETUS Käynnistys Ohjelma kaynnistetaan kaksoisnapayttamalla Accessin kuvaketta. Lopetus Ohjelman lopetus tapahtuu yleisen Windows-kaytannön mukaisesti File-valikon valinnalla Exit. Lopettaminen onnistuu myös jarjestelmavalikon valinnalla Close. Jarjestelmavalikon saa avattua otsikkopalkin vasemmasta reunasta. MsAccess on tietokanta-ohjelma, jota voidaan käyttää itsenäisesti ja erillään erilaisten rekistereiden ja kortistojen pitoon sekä myöskin pieniin sovelluksiin. Sitä voidaan käyttää myös "tavallisten" tietokantojen tapaan ohjelmista käsin, jolloin MsAccess on käyttäjälle "näkymätön" tiedostojärjestelmä. MsAccessin mukana tulee erilaisia työkaluja ja ohjaimia. Näiden avulla voidaan mm tuoda excel-, lotus-,xbase- ja paradox-tiedostojen MsAccess-tietokantaan (ja kääntäen). Odbc-ohjaimen avulla SQL-sovellukset/ohjelmat voivat käyttää MsAccess-kantaa kuten mitä tahansa muuta SQL-kantaa. MsAccess on relaatiokanta (relaatiotietokantojen tiedonhallintajärjestelmä eli RDMS). Relaatiokannoissa tyypillisesti tiedot käyttäjille näytetään taulukoina. MsAccessissa on myös mahdollisuus tehdä lomakkeita tietojen syöttöön ja kyselyyn. Ms-Accessissa on tietokantojen ja taulujen (=relaatiot) määrittelyyn mahdollista käyttää valmiita pohjia (ns ohjatut toiminnot) tai tehdä määrittelyt alusta alkaen itse. Samalla tavoin kyselyjen ja raporttien luonnissa voi käyttää ohjattuja toimintoja tai määritellä kyselyt ja raportit itse.

51 Suunnittelu 51 Tietokannan toteutuksessa 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 määrittelyjä MsAccess-kantaan f) ennen lopullista käyttöönottoa tietokantaa on vielä testattava Tietokannan määrittely Kun MsAccess käynnistetään, tulee ensimmäiseksi esille lomake, jossa on mahdollisuus valita tietokanta. Valintavaihtoehdot ovat: käytetään olemassa olevaa tietokantaa perustetaan uusi tietokanta - ohjattuna toimintona, (wizard) (josta löytyy muutamia kymmeniä valmiita pohjia, joita voi edelleen muokata haluamaansa suuntaan) alusta alkaen itse (annetaan tietokannalle nimi ja valitaan levy sekä hakemisto, mihin tietokanta luodaan) MsAccess-tietokanta on tyyppiä.mdb ja se sisältää sekä varsinaisen tietokannan että tietohakemiston (tietojen määrittelyt). Taulujen määrittelyt Kun on käsillä avattu tietokanta, siihen voidaan määritellä tauluja. Tauluja voidaan määritellä ohjattuna toimintona (wizard) tai alusta alkaen itse Taulukon määrittelyä voi tehdä kahdessa eri näkymässä: taulukkonäkymässä, datasheet view, (jossa voi myös syöttää tietoja taulukkoon) tai rakennenäkymässä, design view (monipuolisin)

52 Rakennenäkymässä tulee esille uusi lomake, jossa kutakin lomakkeen kenttää kohden annetaan/voidaan antaa: nimi (pakollinen) tyyppi (pakollinen) pituus (oletusarvot) muoto tai format (miltä näyttää ruudulla) desimaalipaikat (jos numero) syöttörajoite (input mask) otsikko (caption) oletusarvo kelpoisuussääntö (esim tstnro > 0 and tstnro < 999) virheilmoitus, jos kelpoisuussääntöä yritetään rikkoa syötössä (esim tstnron pitäisi olla välillä 1-998) tiedon pakollisuus onko tyhjä merkkijono sallittu onko kenttä indeksoitu 52 Yksi taulun kentistä on erikoisasemassa eli se on perusavain (primary key). MsAccessissa sen oltava täysin yksilöivä (ei voi olla useammalla rivillä), mutta se voi myös olla yhdistelmä useammasta kentästä. MsAccess voi tarvittaessa pitää yllä automaattista perusavainta (juoksevaa numerointia). Tietokannan tietojen määrittelyt tehdään rakennenäytössä, joka näyttää seuraavanlaiselta:

53 53 Yhteyksien (riippuvuuksien, relationship) määrittely Valitaan rakennenäkymässä yhteyksien määrittely (relationships). Otetaan ruudulle haluttujen taulujen tiedot (ne taulut, joiden välille määritellään yhteyksiä). Otetaan hiirellä kiinni vaikkapa henkilo-taulussa tietoa toimistonro (jos se osoittaa toimiston, jossa henkilö on töissä) ja viedään osoitin toimistotauluun vastaavan kentän (esim tstnro) päälle ja päästetään hiirestä irti. Näin on määritelty kahden taulukon välille yhteys. Yhteysviivaa voi klikata hiiren oikealla näppäimistöllä ja näin aukeaa uusi ikkuna, jossa voi tehdä ko yhteyteen lisämäärittelyjä. Yhteyksien määrittelyruutu näyttää seuraavanlaiselta: Muuta Lopuksi kannattaa määrittelyt tietenkin tallettaa. Lisäksi voi tulostaa rakennekuvaukset (työkalut/analysoi/dokumentointi tai tools/analyze/documenter). Tietojen syöttö Kun tauluja on sopiva määrä valmiina, niihin voi syöttää tietoja. Ensin valitaan taulu, joka avataan ja sitten aukeaa lomakepohja, johon tietoja voi syöttää. Lomakepohjaa voi käsitellä esim sarakkeiden leveyksiä voi muuttaa yms. Rivin vaihto tapahtuu painamalla <enter> rivin päässä. Taulukossa voi liikkua nuolilla tai hiirellä. Vanhoja tietoja voi muuttaa päälle kirjoittamalla. Talletus tietokantaan tapahtuu aina kun vaihdat riviä.

54 54 Tietotyypit ja ominaisuudet tekst i mem o luku aika rah a laskur i koko x x X muoto x x x x x X desim x X syöttöraj x x x X otsikko x x x x x X oletus x x x x X kelpois x x x x X Kelp kuv x x x x X Pakoll? x x x x X Tyhjät? x X Indeks? x x x x x Muoto: tarkoittaa miltä tieto näyttää ruudulla nämä liittyy lähinnä lukuihin ja päiväyksiin sekä kellonaikoihin luvut yleinen (general) esim 123,567 valuutta (currency) esim 123,55 vakio , prosentti 123,00% päiväys esim ddmmyyyy esim yleinen (general) 12/31/96 keskipitkä (medium) 31-jou-96 Syöttörajoite (input mask): sillä ohjataan syötettävän tiedon pituutta ja muotoa itse asiassa aika harvoin käytetty ainakin MsAccessin tietokantaesimerkeissä jos ajatellaan esim postinumero-kenttää, niin siinä syöttörajoite voisi olla mikä tarkoittaa, että pitää syöttää 5 kpl numeromerkkejä (pakko) jos ajatellaan henkilötunnusta, niin siinä syöttörajoite voisi olla \-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

55 Kelpoisuussääntö: 55 Kelpoisuussäännön voi kirjoittaa itse suoraan tai sitten käyttää MsAccessin expression builderiä, joka lähtee liikkeelle kun klikkaa validation rule-kohdassa kohtaa, missä on kolme merkkiä. Joka tapauksessa säännöt voivat olla aika monimutkaisia, mutta niissä ei voi olla viittauksia muihin taulun kenttiin. Alla muutama esimerkki: Rekvuosi > 1960 and rekvuosi < 1999 Like "a*" vain a:lla alkavat kelpaavat Like "a????" alkaa a:lla ja on 5 merkkiä "Kalle" or "Ville" or "Timo" vain nämä kolme nimeä ovat sallittuja <>0 ei saa olla 0 >1000 or is Null suurempi kuin 1000 tai tyhjä (=Null) Null siis ei ole "nolla", vaan tyhjä Tietokantakyselyt: Kyselyjä (=queries) voi tehdä monella tavalla. Ehkä helpointa on tehdä ensimmäinen kysely ensin ohjattuna kyselynä (simple wizard), jotta saa jotain aikaan. Tämän jälkeen kyselyä voi edelleen kehitellä kahdella tavalla: rakennenäytttö (design view) tai sql-näyttö Kyselyä tehdessä määritellään, mistä tauluista tiedot kyselyyn saadaan. Usein lomakkeet ja raportit perustuvat kyselyihin, joiden avulla on "koottu yhteen" useamman taulun tietoja. Kyselyissä voi antaa ehdot, joiden perusteella valitaan näyttöön tulevat rivit, lajitella rivit haluttuun järjestykseen, valita näytettävät tiedot ja tehdä uusia tietoja (esim laskusääntöjen avulla). Kun on jotain määrittelyjä muuttanut, niin taas voi katsoa lopputuloksen taulukkonäkymästä (=datasheet view). Määrittelyissä on muutama valintaperuste kyselyssä (=criteria): show/näytä eli näkyykö jokin tieto raportissa vai ei, tämän idea on, että voisi käyttää esim lajittelussa tai valintaperusteena jotain tietoa, jota sitten kuitenkaan ei näytetä kyselyn lopputuloksena jos taulujen yhteydet on määritelty jo taulujen määrittelyjen yhteydessä, niin kaikkien taulujen tiedot (yhdistettynä linkkien avulla) on suoraan käytettävissä kyselyn (määrittelyn) voi tallettaa sopivalla nimellä niin, ettei tarvitse määrityksiä tehdä aina uudelleen Kyselyn tekemisen rakenne-näytössä on kunkin kyselyyn tulevan kentän alla kolme lisämahdollisuutta. Lajittelu kyselyn lopputuloksen voi lajitella ko kentän mukaan nousevaan tai laskevaan järjestykseen - jos merkitsee useamman kentän lajittelutekijäksi, niin lajittelu tehdään vasemmalta oikealle ts jos esimerkiksi kyselyssä on kentät: osastonimi henkilönimi

56 56 ja tässä järjestyksessä ja molemmat on merkitty lajittelukentiksi, niin lajitellaan osastoittain kunkin osaston sisällä henkilöittäin ja show/näytä eli tuleeko tämä kenttä näyttöön vai ei tyypillisesti joku kenttä voi olla lajittelutekijänä tai haluta näyttää näytössä tai paperilla valintakriteerinä, mutta sitä ei kuitenkaan criterion eli valinta kyselyyn voi valita vain osan datasta ja tähän voi kirjoittaa samantapaisia sääntöjä kuin kelpoisuusehtoihin esim a* alkaa a:lla " Lontoo" or "Helsinki" >234 and < 345 Tässä on huomattava vertailujen ero silloin jos kenttä on määritelty tekstiksi tai jos kenttä on määritelty numerokentäksi. Tekstikenttä numerokenttänä 5 ei ole välillä "5" on välillä "10" - "60", mutta Alla on kuva siitä, miltä kysely näyttää SQL-näytössä, rakennenäytössä ja suoritettuna.

57 57 Kriteerin kysyminen käyttäjältä Jotta ei tarvitsisi tehdä ja tallettaa satoja erilaisia kyselyjä, niin kyselyn voi rakentaa niin, että kriteeri kysytään käyttäjältä aina kun kyselyohjelma suoritetaan. Minkä tahansa kyselyssä olevan tiedon criterion/kriteeri-kenttään kirjoitetaan hakasuluissa jokin sopiva viesti, esim. [Anna auton rekisterinumero] tai [Anna halutun osaston nimi] tms. ja käyttäjän vastausta käytetään sitten hakukriteerinä tässä kyselyssä. Käyttäjän antama kriteeri voi olla myös sellainen, että henkilön nimi alkaa käyttäjän antamalla tekstinjonolla. Tällöin kriteeriksi kirjoitetaan: Like [anna nimen alkua]&"*" ja MsAccess purkaa käyttäjän antamasta vastauksesta (esim Aal) kriteeriksi Aal* Kyselylomakkeella tietojen muutokset - tiedon voi poistaa "mustaamalla" halutun kentän hiirellä ja painamalla delete sarakkeen paikan voi vaihtaa klikkaamalla hiirellä ko saraketta ihan sarakkeen kapessa yläreunassa, jolloin ko sarake on kokonaan valittu. Sitten sarakkeeseen otetaan "kiinni" hiiren vasemmalla painikkeella ja vedetään sarake haluttuun paikkaan Kyselylomakkeelle "uusia" tietoja kyselylomakkeelle voidaan määritellä uusia tietoja, joita saadaan vanhojen tietojen avulla laskennallisesti tai muutoin kyselylomakkeelle syötetään uuden tiedon nimi, kaksoispiste ja sitten käsittelysääntö esim nimi: sukunimi & etunimi veloitus: hinta * maara jos tietokannassa on olemassa tiedot: sukunimi, etunimi, hinta ja maara - uusia muuttujia voi rakentaa myös loogisilla lauseilla. Jos kannassa on kenttä sukup ja nainen on koodattu numerolla 0 ja mies numerolla 1, voitaisiin nämä kyselyssä muuttaa uudeksi muuttujaksi, jonka nimi on sukupuoli: rakennenäyttö: sukupuoli: iif(sukup=0;"nainen";"mies") sql-kysely: iif([sukup=0,"nainen","mies") AS sukupuoli Tietojen ominaisuudet kyselylomakkeella kyselylomakkeelle tulevien tietojen ominaisuuksia (esim nimi, ulkoasu yms) voidaan muuttaa erilaisiksi kuin mitä ne on taulun määrityksissä klikkaa ko kenttää hiiren oikealla näppäimellä, niin aukeaa pikku ikkuna (ominaisuudet/properties), johon voit tehdä näitä määrittelyjä (vain tätä kyselylomaketta varten) Lomakkeet MsAccessin käyttöliittymämahdollisuuksia on useampia. "Tavallinen" käyttäjä voi syöttää tietoja joko taulukkomuodossa tai lomakepohjaan. Samoin kyselyjen tuloksia voi katsella joko taulukkomuodossa tai lomakepohjalla. Lomakkeita voi tehdä automaattisesti ohjatusti tai "tyhjästä" eli rakennenäytössä (missä voi tietysti myös automaatisesti tehtyjä edelleen kehittää Lomakkeiden muotoiluihin ja toimintoihin on valtavasti erilaisia mahdollisuuksia, joista tähän on otettu vain muutamia keskeisiä.

58 Lomakkeen luonti 58 Klikkaa lomakkeet/forms ja uusi/new. Aukeavassa ikkunassa valitset, että tehdään lomake rakennenäytössä/design view ja samalla valitaan mistä taulusta tai mistä kyselystä data/tiedot tulevat tälle lomakkeelle (ja kääntäen mihin syötettäessä tiedot menevät). Lomakkeen tekemisikkunan vasemmalla sivulla on tiettyjä työkaluja, joita voit käyttää (mm otsikoiden tekemistä yms.). Ylhäällä toisessa rivissä on Field list/kenttäluettelo, jota klikkaamalla saat listan niistä tiedoista, joita voit tuoda lomakkeelle. Ko. listasta valitaan jokin kenttä ja vedetään se hiirellä lomakkeelle sopivaan kohtaan. Itse asiassa mukana tulee kaksi kenttää, jotka oletuksena asettuvat rinnakkain eli "otsikkokenttä" ja "syöttöruutu", joissa molemmissa lukee sama teksti eli kentän nimi. Näitä kenttiä voi siirrellä, suurentaa, pienentää jne. kenttien kulmista, sivulta, päistä jne. vetämällä. Esim. kämmenen kuva (vasen yläkulma) = siirtää kenttäparia (kenttä ja otsikko) Sormen kuva = siirtää yhtä kenttää Kaksipäinen nuoli = reunaviivan siirto Ylhäältä toisen rivin alusta "lomaketta" klikkaamalla näet, miltä lomake näyttäisi käyttäjälle. Takaisin rakennenäyttöön pääset samasta paikasta klikkaamalla. Yläriviltä view/näkymä-kohdasta voit esim ylätunnisteen, jolloin lomakkeelle tulee yläosaan pari riviä tyhjää, joihin voit laittaa jotain tekstiä (ottamalla vasemmalta label/otsikko-työkalun käyttöön). Vastaavalla tavalla voit laittaa lomakkeelle alatunnisteen. Sitten tietysti lopuksi talletat lomakkeen jollakin sopivalla nimellä. Nyt lomaketta voi käyttää tietojen syöttöön ja katseluun. Alla näet miltä lomake näyttää rakennenäytössä.

59 59 Lomakkeen muokkausta Hiiren kanssa siirtelemällä ja reunoista vetämällä voi tietysti lomaketta ja sen kenttiä suurentaa, pienentää jne, mutta ei kovin pikkutarkasti. Helposti samalta kohden aloitettavaksi tarkoitetut kentät eivät ole ihan tarkasti allekkain. Tarkemmin voit muutella jotain kenttää klikkaamalla sitä hiiren oikealla, jolloin aukeaa uusi valikko ja siitä voi valita ominaisuudet/properties. Täältä voi sitten ko kentälle määritellä tarkasti mistä alkaa, kuinka leveä jne (left, top, width, height). Saman voi tehdä koko lomakkeellekin klikkaamalla hiiren oikealla lomakkeen vasenta yläkulmaa. Jos ei halua itse askarrella, niin voi käyttää automaattisempaa tapaa eli valitsee tiettyjä kenttiä kohteeksi (yksi tai useampi kerrallaan) ja valitsee format/muotoile-kohdasta sopivia käskyjä align/tasaa (vasemmalle tai oikealle) muutakokoa/size jne Valintaluettelot Tietojen syöttämistä tietokantaan helpottavat valintaluettelot ts käyttäjä voi valita sopivista vaihtoehdoista eikä tarvitse itse kirjoittaa. Ota käyttöön combo-box (yhdistelmälista) klikkaamalla sitä. Sitten klikkaat kenttälistasta sitä kenttää, josta haluat tehdä tällaisen valintaluettelon esim auton merkki ja vedät hiirellä ko kentän haluamaasi paikkaan lomakkeella. Kun päästät irti hiirestä, niin MsAccess kysyy haluatko itse kertoa nämä valintavaihtoehdot (jolloin aukeaa lomake, johon voit ne syöttää)

60 60 tai MsAccess hakee olemassa olevasta taulukosta ko vaihtoehdot (jos sinulla on taulukko, missä on valmiina kaikki mahdolliset vaihtoehdot). Combo-boxia tehdessäsi voit tehdä siitä esim 1 tai 2 sarakkeisen esim volvo tai 0 nainen saab 1 mies ford 2-sarakkeisessa tietokantaan viedään ensimmäisen sarakkeen tieto esimerkissä 0 tai 1. Usein combo-boxeissa halutaan käyttäjälle näyttää vain esimerkiksi asiakkaan nimeä, mutta kuitenkin tietokantaan halutaan viedä asiakkaan numero. Silloin pitää combo-boxin olla kaksisarakkeinen (asnro, asnimi) ja ensimmäisen sarakkeen voi piilottaa (jos unohdit piilottaa luontivaiheessa, voit myöhemmin vaihtaa combo-boxin ominaisuuksista ensimmäisen sarakkeen leveydeksi 0). Esimerkki combo-boxista Tässä tehdään tilausta. Tietokannassa on taulut: asiakas, tuote ja tilaus. Tilauslomakkeella on combo-boxit, joiden avulla voidaan valita tilaukseen haluttu asiakas ja haluttu tuote. Jos MsAccessin eivät wizardit toimi (tai haluaa myöhemmin jotain asiaa muuttaa), niin comboboxin ominaisuuksiin pääsee kiinni klikkaamalla ko. kenttää hiiren oikealla ja ominaisuuksien pitäisi näyttää suunnilleen seuraavilta:

61 61 Name: Combo-boxille annettu nimi Control Source: Mihin tauluun viedään tästä combo-boxista valitut tiedot Row Source Type: Tiedon tulevat taulusta tai kyselystä (toinen vaihtoehto olisi syöttää ne itse) Row Source: asiakas-taulusta tähän tulevat ansro ja asnimi Column Count: 2 (kaksi sarakketta eli tiedoille ansro ja asnimi) Column Heads: otsikoiden nimet Columns Widths: 0 cm; 2,54 (ensimmäisen sarakkeen leveys on 0, jotta se ei näy käyttäjälle) Bound Column: 1 (sarakkeen 1 tieto eli ansro viedään tilaus-tauluun) Tietojen syöttöjärjestys Sitä, missä järjestyksessä kursori pomppii kentästä toiseen (kun painaa Tab) voi muuttaa (muutoin se on kenttien luontijärjestyksen mukainen). View-kohdasta löytyy valinta tab-order (ja siellä lomake, jolla voi vaihtaa järjestystä). Kenttiin voi laittaa oletusarvoja ja myös laskusääntöjä, joiden avulla jokin kenttä saa arvon muiden avulla. Syöttötietojen tarkistuksia voi laittaa lomakkeelle. Tietoja voidaan syöttää yhdellä lomakkeella moneen tauluun (päälomake/alilomakesysteemi). Esimerkiksi päälomakkeena voisi olla henkilölomake ja tämän sisällä voisi olla alilomake, jossa näkyy päälomakkeella kulloinkin näkyvän henkilön (vaikkapa) autot. Tämä tehdään niin, että ensin tehdään ensin alilomake, vaikkapa tässä tapauksessa auto-lomake. Sen jälkeen tehdään päälomake (henkilölomake) ja sille viedään alilomake-kuvake (työkaluriviltä). MsAccess avaa tämän jälkeen ikkunan, josta voi valita sen lomakkeen (tässä tapauksessa autolomake), joka päälomakkeelle halutaan viedä ja lisäksi MsAccessin avulla määritellään päälomakkeen ja alilomakkeen tiedot yhdistävät kentät esim päälomakkeella henkilön hetu-tunnus ja alilomakkeella ajoneuvon haltijan hetu-tunnus. Päälomakkeella voi olla myös useampia alilomakkeita samaan aikaan. Jos MsAccessissa eivät wizardit toimi (tai muuten vain haluaa muutella asioita), niin päälomakkeen rakennenäytöstä voi hiiren oikealla klikata alilomaketta ja alilomakkeen ominaisuuksien pitäisi näyttää suunnilleen tällaisilta:

62 62 Jos ja kun päälomakkeen ja alilomakkeen "yhteispeli" ei toimi ts alilomakkeella eivät vaihdu asiakkaiden nimet, kun päälomakkeella siirrytään tilauksesta toiseen, on virhe todennäköisesti määrittelysssä: Link Child Fields tai Link Master Fields. Nämä kentät ovat "linkki"-kenttiä. Raportit Sinällään usein tulostuksiin riittävät taulukkomuodosta suoraan tehdyt tulosteet (jos yhdelle riville mahtuvat kaikki yhden tiedot) lomakemuotoiset tulostukset tapauksen Raportteja tarvitaan kuitenkin erityisesti, jos tarvitaan monipuolista laskentaa tarvitaan väli- ja loppusummia halutaan lajitteluja monipuolisesti jos halutaan "hienoja" sivuasetteluja Tähän on koottu vain muutamia keskeisiä asioita raporttien tekemisestä. Suurin osa yksityiskohdista on jätetty pois. Asioita on niin valtavasti, ettei kannata tähän niitä kirjoittaa. Raportin luonti Luonti alkaa samalla tavalla kuin lomakkeen teko. Valitaan raportti/uusi ja rakennenäkymä. Samalla valitaan mistä taulusta tai mistä kyselystä tiedot raportille tulevat. Tämän jälkeen esille tuleva raportin teon ikkuna on aika tavalla samanlainen kuin lomakkeen teossa ja menettelykin on saman tapaista. Kenttäluettelosta (field-list) valitaan raportille tulevia tietoja ja