TIETOKANNAT I. Kurssimoniste. Mika Karhulahti mika.karhulahti@jypoly.fi http://homes.jypoly.fi/~karmi Syksy 2002

TIETOKANNAT I Kurssimoniste Mika Karhulahti mika.karhulahti@jypoly.fi http://homes.jypoly.fi/~karmi Syksy 2002 Liiketalous Tietojenkäsittelyn koulutusohjelma

1 Tietokannan hallintajärjestelmien toteutusperiaatteet... 2 1.1 Määritelmiä... 2 1.2 Tietokannan määrittely... 3 1.3 Tkhj:n arkkitehtuuri ja toiminta... 7 1.4 TKHJ:n perusperiaatteita... 9 2 Tietokantajärjestelmän suunnittelu... 10 2.1 Tietokantasuunnittelun vaiheet... 10 2.2 Vaatimusten määrittely ja analyysi... 11 2.2 ER-Malli... 13 Käsitekaavan (ER) diagramminotaatiot... 17 2.3 Mallintaminen... 18 2.4 ER-mallin laajennus: abstraktiorakenteet... 19 Käsitekaavan (ER) yleistys/erilaistamismuodot... 21 3 Relaatiomalli... 22 3.1 Tiedonhallintamallit... 22 3.2 Rakenne relaatiomallissa... 23 3.3 Transformointi käsitekaavasta... 28 4 Tietokannan rakenteen määrittely ja tietotyypit... 35 4.1 Tietokannan rakenteen määrittely... 35 4.2 Eri tietokantojen tietotyyppimäärityksiä... 36 4.3 Taulujen suunnittelu... 39 5 Taulujen luominen ja rakenteen muuttaminen SQL-kielen avulla... 41 5.1 Structured Query Language (SQL)... 41 5.2 Taulujen luominen... 43 5.3 Rajoitteet... 45 5.4 Taulun rakenteen muuttaminen... 50 6 Tietokannan sisällön käsittely SQL-kielellä... 53 6.1 Yleistä hakuoperaatioista... 53 6.2 Yksinkertaisia predikaatteja... 54 6.3 Useamman relaation käsittely... 56 6.4 Muita predikaatteja... 57 6.5 Koostefunktiot... 59 6.6 Ryhmittely ja lajittelu SELECT-lauseessa... 61 Lähteet... 64 Liitteet... 65

1 Tietokannan hallintajärjestelmien toteutusperiaatteet 2 1.1 Määritelmiä Tietokanta Tietokanta on kokoelma tiettyä kohdetta kuvaavia tietoja, joita yksi tai useampi tietojärjestelmä käyttää ja päivittää (Suuri tietotekniikan tietosanakirja) Tietokanta ymmärretään lähestymistavasta riippuen tietueiden joukkona, arvojen joukkona, ilmaisujen joukkona, relaatioiden joukkona, olio- tai sääntöjoukkona. Olennaisia tietokannan tiedoille on niiden tarpeellisuus, sidokset toisiinsa ja yhteiskäyttöisyys. Yleensä: Tietokanta on laaja, tiedot muuttuvat päivittäin, samaa tietoa ei esiinny useammassa paikassa, tiedot ovat elektronisessa muodossa, tietokannan käsittely tapahtuu tietokannan hallintajärjestelmän tuella Tietokannan hallintajärjestelmä (tkhj) Tietokannan hallintajärjestelmä on tietokannan hallintaan tarkoitettu yleisohjelmisto. Tietokannan hallintajärjestelmä mahdollistaa mm. Tietokannan määrittelyn, Tiedon haun Tiedon samanaikaisen käsittelyn (concurrency) Tiedon eheyden varmistamisen (integrity) Virhetilanteista toipumisen (recovery, resiliency) Tiedon turvaamisen (authorization, security) Tietokantajärjestelmä Tietokantajärjestelmä on tietojärjestelmä, joka sisältää tietokannan ja sen käyttöön sekä ylläpitoon tarkoitetun ohjelmiston ja laitteiston

3 KÄYTTÄJÄT SOV.OHJELMAT / KYSELYT TIETOKANTA- JÄRJESTELMÄ TIETOKANNAN HALLINTA- JÄRJESTELMÄ KYSELYJEN PROSESSOINTI-OHJELMA OHJELMA JOLLA ON PÄÄSY TALLENNETTUUN TIETOON TIETOKANNAN KUVAUSKANTA TIETOKANTA Kuva 1.1: Yksinkertaistettu malli tietokantajärjestelmästä (Leppänen 2000) 1.2 Tietokannan määrittely Tietokannan rakenne ja sisältö määritellään erityisessä kuvauskannassa (tietohakemisto, metakanta), joka on usein samanrakenteinen kuin varsinainen tietokanta. Määritystapa on kehittynyt historiallisesti seuraavasti: yksitasoinen (1960-luvun alku) kaksitasoinen (1969, 1971) kolmitasoinen (1976) moniulotteinen (1986) Tietokannan kolmitasoinen määritystapa Suurin osa kaupallisista tietokannan hallintajärjestelmistä on toteutettu kolmitasoisen määritystavan mukaisesti. Siksi se käydään läpi hieman tarkemmin. sisäinen kaava määrittää koneen näkemyksen tietokannan tiedoista (fyysiset tietorakenteet ja saantimenetelmät) käsitekaava määrittää organisaation kokonaisnäkemyksen tietokannan sisällöstä. (Taulut ja niiden liittymäkohdat) ulkoinen kaava määrittää yhden tai useamman samantapaisen sovelluksen näkemyksen tietokannan sisällöstä

4 LOPPUKÄYTTÄJÄT ULKOINEN TASO Ulkoinen/käsitteellinen mallinnus U L K O IN E N K A A V A (1) U L K O IN E N K A A V A (N ) KÄSITTEELLINEN TASO K Ä SITE K A A VA K äsitteellinen/sisäinen mallinnus SISÄINEN TASO S IS Ä IN E N K A A V A Kuva 1.2: Tietokannan 3-tasoinen määritystapa (Leppänen 2000) TALLENNETTU TIETOKANTA Tietomallit Tietomallilla voidaan määrittää tietokannan perusrakenne, rajoitteita tietosisällölle sekä operaatioita tietokannan käytölle. Tietomalli on metamalli eli malli mallista, joka esittää tietyn tietokannan rakenteen, sisällön tai käytön. Postinro Astun Asni Postitoimipaikka Puhelin FIRMA 1 TOISSA Htun Astun N HENKILO Tutkinto Etunimi Sukunimi Kunta Kuva 1.3: Esimerkki ER-kaaviosta (Käsitemalli)

5 Käsitemalli Käsitemalli määrittelee käsitteellisen tason mallintamisen käsitteet ja säännöt (esim. ER-malli) Käsitemallin avulla voidaan tietokantasuunnitteluun tuoda organisatorinen näkemys mukaan jo suunnittelun alkuvaiheessa. Looginen malli Looginen malli määrittelee loogisen tason mallintamisen käsitteet ja säännöt (esim. relaatiomalli). Kuva 1.4 Esimerkki relaatiomallista (looginen malli) (Hovi 2000)

6 Fyysinen malli Fyysinen malli eli säilytysmalli määrittelee fyysisen tason mallintamisen käsitteet ja säännöt. Kuva 1.5 Esimerkki säilytysmallista (fyysinen malli) (Leppänen 2000) Tietokantakielet Tietomallin määritykset esitetään tietokantakielillä, joita ovat: Tiedon määrityskieli (DataDefinitionLanguage) Kielellä määritellään kaavan sallitut käsitteet, rakenteet ja rajoitteet tietokannan luonti ja rakenteen muutokset esim. CREATE TABLE Firma (Astun char(4) NOT NULL, Asnimi char(20), Postinro char(5), PRIMARY KEY (Astun)); Tiedon käsittelykieli (Data Manipulation Language) käskyt ja joskus myös ohjelmat, joilla tietokannan tietoja haetaan, lisätään, muutetaan tai poistetaan toiselta nimeltään kyselykieli esim. SELECT Astun, Asnimi FROM Firma WHERE Postinro= 40640 ; Isäntäkieli (host language) ne ohjelmaosat, jotka eivät tee viittauksia tietokantaan (esim. käyttöliittymä, laskutoimitukset, toistorakenteet) ohjelmointikieliä: Cobol, C, Fortran, C++,.. Tiedon käsittelykielen lauseet upotetaan (embedded language) tällöin isäntäkieliseen koodiin

7 1.3 Tkhj:n arkkitehtuuri ja toiminta Kuvassa 1.6 on esitetty kaavamainen kuvaus tkhj:n keskeisistä osista ja niiden välisistä suhteista. Seuraavassa selostetaan osien roolia tkhj:n tavanomaisessa toiminnassa: Kuva 1.6: Kaavio tkhj:n toiminnasta (Leppänen 2000) tavallisen käyttäjän korkean tason kielellä esittämät kyselyt ohjataan kyselyprosessorin käsiteltäviksi. Sen looginen osa muuttaa kyselyn sisäiseen muotoon ja päättää kyselyn optimaalisesta suoritustavasta. Sen fyysinen osa ohjaa kyselyn toteutusta valitun suoritustavan mukaisesti. Kyselyn jäsentämisessä ja optimoinnissa käytetään hyväksi tietokantamäärityksiä ja tilastotietoja (tietohakemisto).

Tietokannan hoitajan antamat tiedonmääritykset (DDL-lauseet) ohjataan asianomaiselle kääntäjälle, jonka antaman tulkinnan mukaiset sisäiset määritykset (koskien esim. relaatioiden rakenteita, tallennusrakenteita, näkymiä jne) tallennetaan tietohakemistoon. Sovellusohjelmien koodi ohjataan esikääntäjälle ja edelleen DMLkääntäjälle tai isäntäkielen kääntäjälle. Käännetyt ohjelmanosat linkitetään, jolloin muodostuu transaktioita, jotka ohjaavat ajoaikaisia prosessoreja.. Ajoaikainen tietokantaprosessori huolehtii tietokannan saantioperaatioista yhdessä tiedostonkäsittelijän kanssa. TKHJn kanssa tekemisissä välittömästi tai välillisesti on useita erilaisia käyttäjäryhmiä, joilla kullakin on erilaisia rooleja: peruskäyttäjä (end user), joka hakee ja päivittää tietokannan tietoja. o satunnainen käyttäjä (casual user) esim. keski-johto o parametrikäyttäjä (naive user/ parametric user): esim. lentovarausten käsittelijä o monipuolisesti käyttävä (sophisticated end user): esim. insinööri. taloussuunnittelija järjestelmän suunnittelija määrittää yhteistyössä käyttäjien kanssa tieto- ja käyttövaatimukset tietokannalle ja tekee näiden pohjalta suunnitelmat sovellusohjelmoija toteuttaa suunnitelmat tekemällä ja ylläpitämällä ohjelmia tietokannan hoitaja (data administrator) on vastuussa tkhj:n teknisestä kunnosta ja tietokannan asianmukaisesta käytöstä operaattori on tietokantajärjestelmän käytön tukena esim. käynnistämällä varmuuskopioinnit ja eräluonteiset ajot tkhj-suunnittelija on tkhj:n toimittajan palveluksessa oleva henkilö, joka edelleen kehittää tkhj:ää tuotteena välineen kehittäjä ón ohjelmistotoimittajan palveluksessa oleva henkilö, joka työskentelee tkhj:ään integroitavan ohjelmiston tuottamiseksi esim. tietokannan suunnittelua, suoritustehon seurantaa, simulointia, testitiedon generointia tai graafisen käyttöliittymän tuottamista varten tietokantakonsultti osallistuu ohjelmistotalossa asiantuntijana kehittämisprojekteihin Tkhj:n tukipalvelut Tietokannan halllintajärjestelmän tulee tarjota tukeaan monenlaiselle oheistoiminnalle lataustoiminto (loading utility): ladataan teksti- tai perkäkkäistiedostona olevat tiedot osaksi tietokantaa samalla muuttaen tiedot halutun fyysisen rakenteen mukaiseksi varmistustoiminto (backup utility): tietokannan tai sen osan automaattinen varmuuskopiointi tietokannan uudelleenorganisointi: tallennusrakenteiden muuttaminen toiminnan tehostamiseksi raporttien tuottamine: yksinkertaisten raporttimallien määrittely ja niiden mukaisten raporttien tuottaminen valvonta (performance monitoring): valvonnan kohteena käyttäjät, tiedot ja niiden käyttö - tietokannan hoitajaa varten 8

9 1.4 TKHJ:n perusperiaatteita Tietokannan hallintajärjestelmiltä edellytetään tiettyjä periaatteita, joista keskeisimpiä esitelty tässä. 1. Perusoperaatioiden suorittaminen tallennus, haku ja päivitys tietokannan tiedoilla 2. Tietoriippumattomuus (data independence) fyysinen: tietokannan fyysisen rakenteen muuttaminen -> ei tarvetta tehdä muutoksia sovellusohjelmiin looginen: tk:n loogisen määrityksen muutos (ohjelmien lisääminen ja niiden sekä niiden käyttämien alikaavojen muuttaminen, käsitekaavan muuttaminen olennaisia osia poistamatta)-> ei tarvetta tehdä muutoksia sovellusohjelmiin 3. Yhteiskäyttöisyys tk:n tiedot useiden henkilöiden ja sovellusten samanaikaisessa käytössä 4. Ylimäärättömyys (non-redundancy) tietojen ylimäärä=tietojen tallentaminen useampaan paikkaan täydellinen/osittainen, syntaktinen/semanttinen tavoitteena hallittu ylimäärä, joka ei vaaranna tietokannan eheyttä 5. Eheys (integrity) tietojen ristiriidattomuus: virheisiin varautuminen, virhetilanteiden paljastaminen sekä korjaamistoimet keinoja: tietokantamääritysten yhteensopivuuden tarkistaminen, suojausmenettelyt (protection) sekä toipumismenettelyt (recovery) 6. Turvaaminen (security) tiedon käyttöoikeuksien määrittäminen, toteuttaminen, valvonta ja muuttaminen voidaan rajata koskemaan tietyllä operaatiolla, tiettyä tietoalkiota, tietyllä aikavälillä, tietyltä laitteelta ja/tai tietyn henkilön suorittamaa toimintoa tukena toimiva tunnusjärjestelmä, salakirjoitus ja tietojen fyysinen eristäminen 7. Tehokkuus ja suorituskyky käyttäjien kyselyt kohtuullisessa ajassa arviointi benchmarking-ohjelmien avulla 8. Yhteensopivuus olemassa olevien tietojärjestelmien ja uuden tietokantajärjestelmän avulla tkhj:n ja varusohjelmistojen välillä tkhj:ien välillä 9. Skaalautuvuus tkhj ja tietokantajärjestelmän siirto laiteympäristöstä toiseen

10 2 Tietokantajärjestelmän suunnittelu 2.1 Tietokantasuunnittelun vaiheet Kuva 2.1: Tietokantasuunnittelun vaiheet (Elmasri, Navathe, 1994) Kuvassa 2.1 on esitetty karkeasti vaiheet, joiden kautta tietokantajärjestelmän suunnittelu etenee. 1. Vaatimusten määrittely ja analyysi Haastatteluin, kirjalliseen materiaaliin tutustumalla ja keskusteluin muodostetaan käsitys järjestelmältä vaadittavista ominaisuuksista (tietosisältö, käsittelytavat, vasteajat, suojaustasot jne.) tieto- ja käsittelyvaatimukset kirjataan ja niiden relevanttius sekä johdonmukaisuus tarkistetaan liiketoimintalogiikka

11 2. Käsitteellinen mallintaminen Tietovaatimusten perusteella laaditaan käsitekaava, joka kuvaa tietokannan sisällön ja rakenteen (ER-malli) 3 Looginen suunnittelu käsitekaavan perusteella laaditaan sisällöstä ja rakenteesta loogisen tason kuvaus (esim. relaatiokaava) käytettävissä olevan tkhj:n DDL:llä (Data Defininition Language, tiedon määrityskieli) Relaatiokaava tkhj-riippumaton, DDL-määrittely ei 4 Fyysinen suunnittelu loogisen tason kuvauksen perusteella ja tietokannan käsittelyvaatimukset huomioon ottaen, päätetään tietokannan tallennusrakenteista ja saantimenetelmistä 5 Toimintoanalyysi tietojenkäsittelyvaatimusten perusteella muodostetaan kuvaus erityisesti niistä toiminnoista, jotka käsittelevät suunniteltavan tietokannan tietoja; tarvittaessa toimintokuvauksia tarkennetaan tehtävien ja operaatioiden tasolle (transaktiosuunnittelu) 6 Sovellussuunnittelu toiminto- ja tehtäväkuvausten perusteella hahmotellaan sovellusohjelmien rajat, rakenne ja logiikka 7 Toteutus kuvaukset koodataan DML:llä ja isäntäkielellä, jonka jälkeen niiden toimivuus testataan 2.2 Vaatimusten määrittely ja analyysi Vaatimusten määrittely ja analyysi on tärkeä osa suunnittelua. Jos vaatimusmäärittely on kunnossa, suunnittelija tietää mitä tietokantajärjestelmältä halutaan. Apuna vaatimusmäärittelyssä voidaan käyttää esimerkiksi käyttötapaus (use case) tekniikkaa. Vaatimusmäärittelyn tavoitteet (ITS/UT 2002) tietokannan tietovaatimusten määrittäminen alustavien kohteiden suhteen näiden kohteiden tietojen kuvaaminen ja luokittelu kohteiden välisten suhteiden tunnistaminen ja luokittelu tietokannassa suoritettavien transaktioiden tunnistaminen sekä tiedon ja transaktioiden välinen vuorovaikutus tiedon eheyssäännöt Tiedon kerääminen olemassaolevat dokumentit (raportit, kirjalliset ohjeet, työnkuvaukset, henkilökohtaiset kertomukset ym. loppukäyttäjien haastattelut olemassaolevien automaatiojärjestelmien tutkiminen. Olemassa olevien järjestelmien suunnittelumääritysten ja dokumentaation hyödyntäminen

12 Vaatimusmäärittelyn kolme sääntöä 1. Keskustele loppukäyttäjien kanssa reaalimaailman termeillä. Käyttäjät eivät puhu kohteista, attribuuteista tai suhteista 2. Opettele mallinnettavan organisaation perustoiminta ja aktiviteetit 3. Loppukäyttäjät tyypillisesti ajattelevat ja luokittelevat tietoja organisatorisen asemansa mukaan. Haastattele siis mahdollisimman suurta joukkoa Käyttötapaustekniikka (Use Case) Use caset eli käyttötapaukset ovat tavallisesti oliomallinnuksen yhteydessä yleisesti käytetty tapa kuvata järjestelmälle asetettuja vaatimuksia. Use caset ovat osa vaatimusmäärittelyn dokumentaatiota, jonka avulla luodaan järjestelmästä kaikki käyttötapaukset kokoava use case -malli, joka kuvaa järjestelmän toiminnan niin kuin se näkyy käyttäjälle kukin use case kuvaa yhden käyttötapauksen sellaisena kuin se esiintyy järjestelmän ja aktorien välisenä vuorovaikutuksena Toisin sanoen: use case malli on joukko tekstimuotoisia käyttötapauskuvauksia sekä niiden pohjalta laadittu graafinen use case -kaavio Use case kuvaus Kustakin use casesta kirjoitetaan tekstimuotoinen kuvaus, joka sisältää tiedon siitä, mistä toiminnosta on kyse, mitkä aktorit siihen liittyvät ym. Kunkin use case kuvauksen tulisi sisältää seuraavat asiat: frekvenssi (frequency) aktorit (actors) käyttövaatimukset (usability requirements) esiehdot (preconditions) kuvaus (description) lopputulokset (postconditions) poikkeukset (exceptions)

13 Use case -kaavio Kuvassa 2.2 on esimerkki use case kaaviosta ja sen notaatiosta. Kuva 2.2: Use Case-kaavion notaatio Use caset on kuvattu ellipseillä, joiden sisällä on use casen nimi. Tällainen voisi olla esimerkiksi käyttäjä syöttää asiakkaan henkilötiedot. Aktorit on kuvattu tikku-ukoilla, joiden alapuolella on aktorin nimi. Aktorit ovat järjestelmän kannalta merkityksellisiä, tunnistettavia rooleja. Esim.: käyttäjä (järjestelmän käyttäjä) assosiaatio-suhde: yksittäisen aktorin ja use casen välinen kommunikaatio (viiva aktorin ja use casen välillä) käyttötapausten väliset suhteet: o laajennus-suhde (extend) laajentaa use casen käyttäytymistä toisella use casella (katkoviiva ja tunniste <<extend>>) o sisällytys-suhde (include) kuvaa tilanteen, jossa use case käyttää hyväkseen toisen use casen palveluja (katkoviiva ja tunniste <<include>>) o yleistys (generalisation) kuvaa tilanteen, jossa yleisestä use casesta periytetään uusi, erikoistuneempi use case (nuolenkärki yleisen use casen päähän) Katso esimerkki vaatimusmäärittelystä liitteestä 1: Eläinklinikan vaatimusmäärittely 2.2 ER-Malli Käsitteellinen mallintaminen Tunnetuin ja perusosiltaan sovelletuin käsitemalli on Chenin (1976) esittämä ER-malli (Entity- Relationship model). Mallia on myöhemmin laajennettu (EER-malli, ERT-malli, ER+-malli, ERGmalli jne.) mutta tässä lyhyesti alkuperäinen malli. Käsitekaava kuvaa tietokannan sisällön ja rakenteen keskeisiä termejä käsitekaavassa kohde attribuutti suhde

14 Kohde Kohde tarkoittaa ajateltavissa olevaa ja eroteltavissa olevaa asiaa tai tapahtumaa, esim. Seppo, Jaguar, SJS-1 Kohdejoukkoon kaikkien samantyyppisten kohteiden joukko, esim. kaikki autot, kaikki henkilöt Useamman kohteen samanlaisuus ilmenee niiden attribuuttien ja suhteiden samanlaisuutena Attribuutti Attribuutti on ominaispiirre, josta ollaan joko kohteessa / suhteessa kiinnostuneita, esim. Nimi, Osoite, Palkka Kuva 2.3: Atominen attribuutti Attribuutin arvo kuvastaa kohteen / suhteen yksittäisiä ominaispiirteitä, esim. Seppo, Rajakatu 44, 56 400 Attribuutin arvot valitaan sen arvoalueesta, esim. Palkka = (0,125 000) Koottu attribuutti pystytään jakamaan pienempiin osiin. Esimerkiksi osoite pystytään jakamaan katuosoitteeseen, postinumeroon ja postitoimipaikkaan. Attribuutti voi olla koottu useammalla tasolla. Kuva 2.4: Koottu attribuutti Muut kuin kootut attribuutit ovat ns. atomisia attribuutteja (ks. kuva 2.3). Yksiarvoisella attribuutilla voi olla kerrallaan vain yksi arvo, esim. rekisteritunnus: SJS-1 Muita attribuutteja kutsutaan moniarvoisiksi attribuuteiksi, esim. tuotteen_väri

15 Johdettu attribuutti saa arvonsa muiden attribuuttien (1 tai 1>) arvoista piirretään katkoviivalla Kuva 2.5: Moniarvoinen attribuutti esim. ikä voidaan laskea (synt_aika ja pvm) Kuva 2.6: Johdettu attribuutti Tyhjäarvo tarkoittaa, että kyseisen kohteen tai suhteen yhteydessä ei ole attribuuttiarvoa tai sitä ei tiedetä. Avainattribuutilla tunnistetaan yksikäsitteisesti kohde tai suhde, esim. henkilötunnus (htun) tai rekisterinumero (rekno). Joskus tarvitaan useampia avainattribuutteja tekemään viittauksesta yksikäsitteinen. Avainattribuutin arvo ei voi koskaan olla tyhjäarvo. Muut kuin avainattribuutit ovat kuvaaja-attribuutteja. Kuva 2.7: Avainattribuutti Kun kohdetta ei voi tunnistaa sen omilla attribuuttiarvoilla kutsutaan sitä heikoksi kohteeksi. Tällöin tunnistamisessa voidaan käyttää apuna toisen kohteen avainattribuuttien arvoja. Kohdetta, jonka attribuuttien arvoja tarvitaan heikon kohteen tunnistamiseen, kutsutaan tunnistavaksi kohteeksi. Kuva 2.8: Heikko kohde Suhde Yhden tai useamman kohteen välillä vallitseva riippuvuus tai muu asiayhteys, esim. Eetu omistaa Jaguar EEKA-1:n. Samanlaiset suhteet muodostavat Suhdejoukon. Suhdejoukon määritys vastaa suhdetyyppiä (esim. Auton_omistus). OMISTAJA omistaa 1 N R AUTO Kuva 2.9: Auton omistus -suhde

Suhdetyypin Suhdeaste ilmaisee suhteen sitomien kohdetyyppien lukumäärän, esim. autonomistus on binaarinen suhde, eli sen suhdeaste on 2. Roolilla tarkoitetaan sitä tehtävää, joka kohdetyypillä on suhdetyypissä, esim. suhdetyyppi: päätösvalta --> Roolit: alainen, esimies 16 ESIMIES JOHTAA 1 N ALAINEN Kuva 2.10: Esimiehen ja alaisen roolit johtamissuhteessa Kardinaalisuus ilmaisee, kuinka moneen suhteeseen kohde voi samaan aikaan osallistua ja kuinka monta kohdetta voi samaan aikaan osallistua tiettyyn suhteeseen. Perusmuodot ja esimerkit: 1 --> 1: avioliitto (hlö, hlö) 1 --> N: päätösvalta (esimies, alainen) N --> M: osanvalmistus (hlö, osa) Suhteen pakollisuus merkitsee, että kyseisestä suhdejoukosta ainakin yhden kohteen on osallistuttava ainakin yhteen kyseisenlaiseen suhteeseen (olemassaolorajoite; min_kard=1) Liiketoimintasäännöt Kardinaalisuus ja suhteen pakollisuus ovat esimerkkejä siitä, miten liiketoimintasääntöjä voidaan ilmaista. Liiketoimintasäännöllä tarkoitetaan ilmaisua, joka määrittää rakennetta tai tapaa, jolla liiketoimintaa suoritetaan, esimerkkejä: asiakas voi saada alennusta tuotteesta vain, jos hänellä on esittää kanta-asiakaskortti luottoyhtiö myöntää luottokortin vain, jos asiakkaalla ei ole maksuhäiriömerkintöjä Liiketoimintasäännöt voidaan jakaa karkeasti kahteen luokkaan: 1. rakenteelliset säännöt 2. toiminnalliset säännöt Liiketoimintasääntöjen kuvaaminen Tietokantojen suunnittelun kannalta on tärkeää, että kuvataan ja tunnistetaan säännöt, joiden voimaansaattaminen ja valvonta on mahdollista ja hyödyllistä tehdä tietokonetuetuksi. Kuvaus vodaan toteuttaa mm. luonnollinen kieli, formaali kieli, graafisesti (ER-kaaviot). Olennaista on, että tieto säännöistä siirtyy mahdollisimman tarkkana ja virheettömänä tietokannan loogisen suunnittelun vaiheeseen, jolloin ne voidaan toteuttaa eheysrajoitteilla tai muilla ratkaisuilla.

17 Käsitekaavan (ER) diagramminotaatiot Symboli Merkitys Kohdetyyppi Heikko kohde Suhdetyyppi Tunnistava suhdetyyppi Attribuutti Avainattribuutti Moniarvoinen attribuutti Koottu attribuutti Johdettu attribuutti (esim. ikä) E R 1 E2 E 2 :n täydellinen osallistuminen R:ään E1 1 N R E 2 Kardinaalisuussuhde 1-->N (esim. osasto, ttekijä) R (min,max) E Rakenteellinen rajoite (min,max)

18 2.3 Mallintaminen Käsitteellinen mallintaminen käynnistyy peruskohdetyyppien, suhdetyyppien ja attribuuttien tunnistamisella, nimeämisellä ja määrittelyllä. Pikku hiljaa keskeisten käsitteiden joukkoa täydennetään ja tehtyjä määritelmiä tarkennetaan. Työskentely edellyttää välitöntä ja tiivistä yhteistoimintaa peruskäyttäjien kanssa. Jos suunniteltava järjestelmä on laaja, käsitteellistä mallintamista varten mallinnettava kohdealue jaetaan osiin, joista tehdään ensin ns. näkemyskaavat. Myöhemmin näkemykset integroidaan. Seuraavassa lyhyt kuvaus tehtävistä, joiden suorittaminen voi edetä suuressa määrin rinnakkaisena. Mallintamisen vaiheet 1. Peruskohdetyyppien tunnistus ja kuvaus helpoimmin havaittavia peruskohdetyyppejä ovat käyttäjien puheissa toistuvat henkilöt, esineet, tilat ja tuotteet vaikeampia ovat käsitteelliset kohdetyypit kuten tilaus, sopimus ja organisaatiorakenne pääasia on, että valitut kohdetyypit ovat niitä, joista halutaan tallentaa tietoja pysyvästi apuna voi käyttää kysymyslistoja tai taulukoita jotka herättävät kysymyksiä ja auttavat havaintomaailman jäsentämisessä valitaan kohdetyypille mahdollisimman luonteva ja täsmällinen nimi sekä kuvaillaan kohdetyypin merkitys 2. Suhdetyyppien tunnistus ja kuvaus mietitään, mistä kohteiden välisistä suhteista halutaan tallentaa tietoja tietokantaan voivat koskea: olemassaoloa, toiminnallisia suhteita, tapahtumaa jne. tässä yhteydessä nousee tavallisesti esille uusia kohdetyyppejä, joiden kuvaamisen osalta palataan edelliseen tehtävään jotkut suhdetyypit voidaan nähdä mieluummin itsenäisen luonteen omaavina, joten tehdään niistä kohdetyyppejä nimetään suhdetyypit ja kuvataan ne myöhemmässä vaiheessa määritellään kardinaalisuudet ja pakollisuudet 3. Attribuuttien tunnistus ja kuvaus mietitään kunkin suhde- ja kohdetyypin osalta mistä niiden piirteistä ollaan kiinnostuneita -> potentiaalisten attribuuttien joukko kuvataan attribuutit tarkemmin valitaan avaimet, ja pohditaan muiden attribuuttien tarpeellisuutta määritellään attribuuteille arvoalueet, sekä päätetään kunkin attribuutin osalta, minkä arvot ovat yksi/moniarvoisia, alkeis/koottuja, perus/johdettuja, pakollisia/ehdollisia, pysyväarvoisia/vaihtuva-arvoisia 4. Käsitekaavan uudelleen organisointi Käytetään abstraktiorakenteita käsitekaavan selkiyttämiseksi. Seuraavat tapaukset voivat olla merkkinä erityisesti yleistysrakenteiden tarpeesta: o on useita kohdetyyppejä, joilla on sama avainattribuutti ja monia muita samanlaisia kuvaaja-attribuutteja

o on useita kohdetyyppejä, jotka ovat toisiinsa yhteydessä samantapaisilla suhdetyypeillä tarkennetaan koottujen attribuuttien rakennetta, mikä voi johtaa uusien kohdetyyppien perustamiseen mietitään moniarvoisten attribuuttien esittämistapaa 5. Tarkistetaan kohde- ja suhdetyypit sekä attribuutit kuvausten johdonmukaisuus 2.4 ER-mallin laajennus: abstraktiorakenteet Semanttisuuden lisäämiseksi on ER-malliin myöhemmin lisätty mm. abstraktiorakenteita. Ohessa tärkeimmät abstraktiomuodot käyttäen esimerkkeinä kohteita ja kohdetyyppejä (vastaavasti voitaisiin tarkastella myös suhteita ja suhdetyyppejä). Abstraktio Abstraktiolla tarkoitetaan periaate, jonka mukaan epärelevantit ilmiöt peitetään kiinnostavien ilmiöiden esille saamiseksi. Yleistys (generalisation) Yleistyksessä tarkastelu siirretään alityypeistä kohdistumaan ylityyppiin, jonka sisältämä määritys kattaa kaikki alityyppien mukaiset kohteet (esim. auto, juna ja lentokone -> ajoneuvoja). Alityyppien ja ylityyppien välistä suhdetta kutsutaaan is_a suhteeksi. Vastaavat alijoukot voivat olla: erillisiä (auto, juna, lentokone) Auto 19 Juna Lentokone leikkaavia (opiskelija, työntekijä) Opiskelija Työntekijä sisältyviä Yleistykselle käänteistä muotoa kutsutaan erilaistamiseksi (specialisation). Sillä muodostetaan ylityypistä alityyppejä. Erilaistaminen on:

20 kattava, mikäli syntyvien alijoukkojen yhdiste on sama kuin ylijoukko Auto Vene osittainen, jos osa ylijoukon kohteista ei kuulu mihinkään alijoukkoon Auto Vene Koostaminen (aggregation) Kohteiden/kohdetyyppien välistä suhdetta pidetään ylemmän tason kohteena/kohdetyyppinä eli koosteena (aggregate). Alemman tason kohteita kutsutaan konstituenteiksi (constituent) esim. moottori, akku ja ovi -> auton konstituentteja Suhdetta kutsutaan part_of suhteeksi. Olennaista abstraktiomuodolle on koosteen sisäinen rakenne. Koostamisen käänteistä muotoa kutsutaan osittamiseksi. Osittamisella koostekohde(tyyppi) jaetaan konstituenteiksi. Ryhmittely (grouping, association) Ryhmittelyssä kohteet nähdään ryhmänä. esim. työntekijät ovat ammattiyhdistyksen jäseniä Suhdetta kutsutaan member_of suhteeksi, joka kytkee toisiinsa jäsenen ja ryhmän. Ryhmittelylle käänteinen muoto on yksilöinti. ER-mallin mukaan laadittu käsitekaava esitetään tavallisesti graafisessa muodossa, jossa käytetään vaihtelevia notaatioita. Edellisessä kappaleessa esiteltiin Elmasrin ja Navanthen (1994) notaatio, ohessa abstraktiorakenteiden notaatiot.

21 Käsitekaavan (ER) yleistys/erilaistamismuodot Ajoneuvo d osittainen, erillinen Auto Vene Auto Vene Ajoneuvo o osittainen, leikkaava Auto Vene Auto Vene Ajoneuvo d kattava, erillinen Auto Vene Auto Vene Ajoneuvo Auto o Vene kattava, leikkaava Auto Vene

22 3 Relaatiomalli 3.1 Tiedonhallintamallit Hierarkkinen malli Päähakemisto Alihakemisto Alihakemisto Alihakemisto Kuva 3.1: Esimerkki hierarkkisesta mallista Ensimmäiset tietokantajärjestelmät 1960-luvulla olivat ns. hierarkkisen mallin mukaisia järjestelmiä. Hierarkkisen mallin mukaan tiedostot on jaoteltu puumaisen rakenteen mukaiseen hierarkkiseen järjestykseen. Hierarkkinen malli on kuitenkin varsin jäykkä, eikä kaikkia rakenteita pystytä sen avulla esittämään. Myöskään turhaa toistoa ei pystytä välttämään. Verkkomalli Päähakemisto Alihakemisto Alihakemisto Alihakemisto Kuva 3.2: Esimerkki verkkomallista Verkkotietokannat suunniteltiin korjaamaan hierarkkisten tietokantojen ongelmia. Tietojen väliset suhteet pyrittiin kuvaamaan joukkoina hierarkioiden asemasta. Hierarkkisen mallin mukaan esimerkiksi ristiin viittaaminen on mahdollista. Käytännössä verkkotietokannat erottaa hierarkkisista tietokannoista mahdollisuus antaa lapsitaululle enemmän kuin yksi äititaulu. Verkkotietokantojen toteuttaminen ja ylläpitäminen on kuitenkin hankalaa.

23 Relaatiomalli Kuva 3.3: Esimerkki relaatiomallista (Hovi 2000) E.F. Codd esitteli vuonna 1970 relaatiomallin, joka oli siihenastisista malleista joustavin ja yksinkertaisin. Ikävänä puolena oli relaatiomallin vaatimien koneresurssien suuri tarve. Kuten hierarkkinen ja verkkomallikin, relaatiomalli on ns. loogisen tason malli. Relaatiomalli on vakiintunut yleisimmäksi käytössä olevaksi tietokantamalliksi nykyään ja suurin osa kaupallisista tietokannan hallintajärjestelmistä tukee nimenomaan relaatiomallin mukaista tietokantaa. Oliorelaatio-, olio- ja multimediatietokannat Viime aikoina ohjelmistotuotannossa on saavuttanut suurta suosiota ns. olioajattelu, ja 1990-lukua voidaankin pitää tietojärjestelmien kehityksessä olioiden maihinnousun vuosikymmenenä. Tämä on vaikuttanut myös tietokantojen ja niiden mallien kehitykseen. Varsinaiset oliotietokannat eivät ole saaneet markkinoilla suurta jalansijaa, mutta sen sijaan relaatiotietokannat, joita on laajennettu olioominaisuuksilla, ovat levinneet jonkin verran. Olio-ominaisuudet helpottavat monimutkaisemman tiedon käsittelyä tietokannoissa. Myös multimedia asettaa tietokannoille uudenlaisia vaatimuksia. Multimedian tallentamista varten onkin kehitetty erityisiä multimediatietokantoja. 3.2 Rakenne relaatiomallissa

Relaatioksi kutsutaan taulua, joka koostuu riveistä ja sarakkeista. Kukin relaation rivi vastaa yhtä kohdetta (esim. Sepon tiedot) tai suhdetta (esim. Eetu_omistaa_Jaguar_EEKA-1). Kukin sarake vastaa yhden attribuutin todellisuudessa esiintyviä arvoja. Relaatioteoriassa käsitteinä ovat attribuutit ja monikot (tuple). Kullakin attribuutilla on määrätty arvoalueensa. Monikot taas muodostuvat relaation attribuuttien arvoalueista poimituista arvoista. Relaatioteorian määrityksiä Arvoalue Arvoalue (domain) D on atomisten arvojen joukko (esim. nimet, palkat). Atomisuus tarkoittaa että ko. arvoa ei voida jakaa pienempiin osiin. Arvoalueen määritys tehdään tavallisesti osaksi tietotyypin määrityksen avulla esim. nimet -> max 20 merkkiä, palkat -> desimaaliluku väliltä 1000-10 000 Relaatiokaava Relaatiokaava (relational schema) koostuu relaation nimestä R ja attribuuttilistasta A 1, A 2, A n. Kukin attribuutti A i on eräänlainen rooli, jota vastaava arvoalue D i näyttelee relaatiokaavassa. Relaation asteluku (degree) on relaatiokaavassa esiintyvien attribuuttien lukumäärä (n) Esimerkki relaatiokaavasta: Henkilo(ssn,hnimi,hosoite,hpalkka) Monikot Relaatiokaavan mukainen relaatio r on joukko monikkoja: r={t 1,t 2,,t m } Kukin monikko (tuple) t on järjestetty joukko arvoja: t =<v 1,v 2, v n >, missä arvo v i on attribuuttia A i vastaavan arvojoukon D i alkio tai tyhjäarvo (null). Relaation kardinaalisuus tarkoittaa monikoiden lukumäärää (m). Tyhjäarvo Tyhjäarvo tarkoittaa sitä, että ko. arvoa ei tiedetä tai että ko. attribuutti ei ole merkityksellinen ko. kohteelle. esim. Henkilön opiskelupaikkakunnan osoite, jos henkilö on työntkiejä eikä opiskele Kolmiarvoinen logiikka Tyhjärvon huomioiminen tuo kolmiarvoisen logiikan, joka sisältää arvot tosi (t), epätosi (f), ei tiedetä (u) AND t u f t t u f u u u f f f f f Kuva 3.4: Kolmiarvoinen logiikka OR t u f t t t t u t u u f t u f Codd (1990): tarvittaisiin neliarvoista logiikkaa, jossa eroteltuna ei tiedetä, ei merkityksellinen Perusrelaatiot ja johdetut relaatiot 24

25 Perusrelaatioiden kaava sisältää arvoalueiden eksplisiittiset määritykset. Johdettujen relaatioiden kaava on määritelty epäsuorasti, jolloin relaatio ja/tai sen attribuutit voivat olla nimeämättömiä. Johdettuja relaatioita kutsutaan usein näkymärelaatioiksi (view relations). Kuva 3.5: Perusrelaatio ja johdettu relaatio Yllä olevasta kuvasta selviää perusrelaation ja johdetun relaation ero esimerkillä. Esimerkissä johdettu relaatio on muodostettu yhdisteenä kahdesta taulusta, jotka sinällään ovat perusrelaatioita. Yhdistesääntöjen mukaan uuteen relaatioon tuodaan kummankin yhdistettävän relaation kaikki monikot kuitenkin niin, että samanlainen monikko esiintyy tulosrelaatiossa vain kerran. Johdetut relaatiot eli näkymät Näkymät pohjautuvat yhteen tai useampaan tauluun. Näkymä esittää tietyillä ehdoilla rajatun osan halutusta taulusta tai tauluista. Näin voidaan rajoittaa esimerkiksi, mitä eri käyttäjäryhmille tietokannasta näytetään. Taulujen sisällön päivittäminen myös vaikuttaa suoraan siitä tehtyjen näkymien sisältöön. Näkymien kautta voi myös eräin rajoituksin yrittää päivittää niiden pohjana olevia tauluja. Päivityskelpoiset (updateable) näkymät ovat näkymiä, jotka on saatu yhden perustaulun rivien ja/tai sarakkeiden osajoukkona ja perusavain on näkymässä mukana. Päivityskelvottomat (non-updateable) näkymät ovat näkymiä, joiden kautta alkuperäisiä tauluja ei voida päivittää: Päivitykset, joista ei edes teoriassa voida johtaa vaikutusta perustauluun, eli jonkin sarakkeen arvo on esim. perustaulun sarakkeen keskiarvo Ristiriita näkymän määrittelyn kanssa. Esim. kaikki joiden osasto-kentän arvo on 3 -> ei voida lisätä riviä jolla jokin muu arvo ko. kentässä Useammasta taulusta kootut näkymät Päivityskelpoinen näkymä, jonka jokin sarake on määritelty aritmeettisena lausekkeena tai skalaarifunktiona (esim. tietotyyppimuunnokset ja päiväysten käsittelyfunktiot). Tällaisessa tapauksessa voidaan poistaa rivejä ja muuttaa ainoastaan muita sarakkeita. Relaatioiden ominaisuudet (Codd 1970) Coddin relaatioteorian mukaan relaatioilla on tiettyjä ominaisuuksia: 1. Relaatioiden monikoiden järjestyksellä ei ole merkitystä 2. Arvojen järjestyksellä monikoissa ei ole merkitystä, kunhan yhteys arvo-arvoalue-attribuutti käy ilmi

26 3. Kukin arvo monikossa on atominen (normalisointi) tai tyhjäarvo Monikoiden tunnistaminen Jokaisen monikon tulee olla yksikäsitteisesti tunnistettavissa, ts. relaatiolla tulee olla yksi tai useampi attribuutti, joiden arvojen suhteen kaikki monikot eroavat toisistaan. Kyseinen attribuutti tai kyseiset attribuutit ovat avainehdokkaita (candidate key). Avainehdokkaan tulee olla 1. yksikäsitteinen -> sama avainehdokkaan arvo ei voi toistua koskaan eri monikoissa 2. minimaalinen -> avaimeen kuuluvista attribuuteista ei voida poistaa ainoatakaan ilman, että yksikäsitteisyys häviää Relaation perusavaimeksi valitaan sopivin avainehdokkaista. Relaatiotietokanta Relaatiotietokanta koostuu useista relaatioista. Relaatiotietokannan kaava S muodostuu relaatiokaavojen joukosta (ts. S = {R 1,R 2,,R p }) sekä eheysrajoitteiden joukosta IC Eheysrajoitteet IC sisältää seuraavat perustavaa laatua olevat rajoitetyypit: 1. kohde-eheysrajoite (entity integrity constraint): perusavain ei voi koskaan saada tyhjäarvoa 2. viite-eheysrajoite. olkoon relaatiot R ja S, joista relaatiossa R on viiteavaimena relaation S perusavain (avainattribuutti). Tällöin jokaiselle R:n viiteavainarvolle tulee löytyä vastine relaation S avainattribuuttiarvoista; muussa tapauksessa viiteavainarvon tulee olla tyhjäarvo. (huom. relaatiot R ja S voivat olla myös sama relaatio) 007 R 007 S Kuva 3.6: Viite-eheys Viite-eheysrajoitteen voimassa pitäminen Viite-eheysrajoitteen voimassa pitäminen edellyttää, että on määritelty miten menetellään viittauksen kohteena olevan monikon poiston ja perusavaimen päivityksen yhteydessä. Tässä suhteessa on yleensä kolme mahdollisuutta: 1. estäminen (restriction): viiteavaimen viittaaman monikon poistaminen tai sen perusavaimen arvon muuttaminen estetään 2. tyhjääminen (nullify): viiteavaimelle annetaan tyhjäarvo, jos sen viittaama monikko poistetaan 3. vyöryttäminen (cascade): viiteavaimen arvoa muutetaan vastaavasti, jos viitattavan monikon perusavaimen arvo muuttuu, ja jos viitattu monikko poistetaan, myös kaikki siihen viittaavat monikot poistetaan Esimerkki viite-eheydestä Ohessa esimerkki relaatiotietokannasta, jossa on kolme taulua: Osasto, Tyontekija sekä Projekti.

27 Kuva 3.7: Esimerkki viite-eheydestä tietokannassa (Lahtonen 2002a) Yritettäessä syöttää Tyontekija-tauluun ( lapsi ) arvoja, joita vastaavia ei ole Osasto-taulussa, viiteeheys pakottaa syöttämään jotakin kelvollista ennen kuin syöttö voidaan hyväksyä. Sama tapahtuu, jos Projekti-taulun Projektipaallikko-kenttään yritetään syöttää arvoa, jota ei löydy Tyontekija-taulun TyontekijaID-kentästä. Viite-eheys ei koske NULL-arvoja (tyhjäarvoja), joten yleensä on syytä kieltää NULL-arvojen esiintyminen kyseisessä lapsi-taulun kentässä. Kuva 3.8: Tietokannan Osasto-taulu (Lahtonen 2002a) Kuva 3.9: Tietokannan Projekti-taulu (Lahtonen 2002a) Kuva 3.10: Tietokannan Tyontekija-taulu (Lahtonen 2002a)

28 Mikäli ajatellaan aikaisemmin mainittuja viite-eheysrajoitteen voimassapitämisen mahdollisuuksia, tarkoittaisi tämän esimerkin valossa estäminen-sääntö, että esimerkiksi mitään osastoa ei voisi poistaa tai päivittää, mutta työntekijöistä vain ensimmäisen poisto tai päivittäminen olisi estetty. Vyöryttäminen-säännön käyttö aiheuttaisi sen, että päivitykset ja poistot vaikuttaisivat myös lapsitauluihin. Näin esimerkiksi markkinointi-osaston (0) poisto häivyttäisi myös Matti ja Maija Meikäläisen tietokannasta. Tyhjääminen-sääntö em. tapauksessa aiheuttaisi vastaavasti tyhjäarvon Matti ja Maija Meikäläisen Osasto-kentässä. Huomion arvoista on, että tyhjäämistä voidaan käyttää vain, jos ko. kentältä ei ole kielletty puuttuvaa arvoa (NOT NULL). Muut rajoitteet Edellisten rajoitteiden lisäksi relaatiotietokannan kaavaan voi olla määritelty spesifisempiä ja komplisoidumpia rajoitteita, esim: Työntekijän palkka ei saa ylittää hänen esimiehensä palkkaa Viikkotuntimäärä, jonka työtekijä työskentelee projekteissa ei saa ylittää 56 tuntia Relaatiokaavan formaali määrittely Relaatiotietokannan kaava voidaan esittää graafisesti siten, että relaatioita vastaavat suorakaiteet ja niiden avaimiin perustuvat suhteet osoitetaan nuolilla/viivoilla. Formaalisti relaatiokaava määritellään DDL:llä. Esimerkiksi SQL:llä perus- ja johdettujen relaatioiden määritykset ovat: CREATE TABLE Henkilo (ssn char(11), hnimi char(20), hosoite char(30)); CREATE VIEW Oululainen (hnimi) AS SELECT hnimi FROM Henkilo WHERE hosoite= Oulu ; Rajoitteiden määrittämistä varten on omat SQL-lauseet. 3.3 Transformointi käsitekaavasta Relaatiomallin mukaisen tietokannan muodostaminen Relaatiomallin mukainen tietokanta muodostuu tauluista, jotka sisältävät rivejä ja sarakkeita (kenttiä). Relaatiomallin mukaisen kaavan tuottamisen lähtökohtana toimii käsitekaava. Seuraavassa pohditaan lyhyesti, mitä asioita tulee ottaa huomioon relaatioita luotaessa. Taulut Taulujen nimeksi valitaan selkeä ja kuvaava nimi. Taulujen nimissä ei saa myöskään käyttää välilyöntejä, erikoismerkkejä tai skandeja (å,ä,ö). Jokainen taulu sisältää yhden tai useamman sarakkeen eli kentän Kentät Kenttiä luotaessa määritellään niille erilaisia ominaisuuksia. Myös kenttien nimeksi valitaan selkeä ja kuvaava nimi. Ei siis täälläkään välilyöntejä, erikoismerkkejä tai skandeja (å,ä,ö).tietotyypin valinta riippuu käytettävästä tietokannan hallintajärjestelmästä ja/tai tietokantatyypistä. Erilaisia tietotyyppejä edustavat mm. numeerinen-, merkkijono- ja aika-tyypit.

Täytyy siis miettiä, onko tarpeen käyttää kiinteä- vai vaihtuvamittaista kenttää, kuten myös maksimipituus ja mahdollinen tarkkuus. Myös se, onko tieto pakollinen, tulee miettiä valmiiksi. 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 voivat tulla kyseeseen. Kentille voidaan myös joissakin tapauksissa määrittää oletusarvo. Avaimet (keys) Jokaiselle taululle pitää määrittää perusavain (primary key). Tämän perusavaimen tulee olla yksikäsitteinen, mutta se voi muodostua yhdestä tai useammasta sarakkeesta. Olennaista on, että taulusta ei saa löytyä identtisiä perusavaimen arvoja, eikä perusavain saa puuttua yhdeltäkään riviltä. perusavaimen eheys (entity integrity) Toissijaiset avaimet (secondary key, secondary index) nopeuttavat joissakin tapauksissa taulun järjestämistä. Viite-avainten määritysalue on sama kuin jonkin perusavaimen. Transformointi käsitekaavasta ER-kaavio kuvataan relaatiokaavioksi muuntamalla ER-malli relaatioiksi, attribuuteiksi ja vierasavaimiksi. Tässä vaiheessa on hyvä myös tarkistaa, onko kohteiden nimissä SQL:n (tai muun tietokantakielen) käyttöön varattuja sanoja. Kohdetyypit Transformointi aloitetaan siten, että jokaisesta (perus)kohdetyypistä tehdään relaatio. Myös kustakin heikosta kohdetyypistä tehdään oma relaatio. Tällöin sijoitetaan relaatioon vastaavan tunnistavan kohdetyypin avainattribuutit. 29 ostun OSASTO Toissa 1 N ttun TYONTEKIJA 1 TYONTEKIJA ttun ostun OSASTO ostun... nimi suhde ELATE TTAVI A N ELATETTAVA ELATETTAVIA nimi suhde ttun Kuva 3.11: Kohdetyyppien transformointi Attribuutit Kootuista attribuuteista viedään alimman tason atomiset attribuutit. Tämä tarkoittaa sitä, että ER-mallin rakenteiset attribuutit poistetaan ja viedään relaatioihin yksinkertaistaen.

30 o s tu n ttu n n im i e n im i O S A S T O T o is s a T Y O N T E K IJ A s n im i 1 N T Y O N T E K IJ A ttu n e n im i s n im i Kuva 3.12: Koottujen attribuuttien transformointi Kustakin moniarvoisesta attribuutista tehdään ns. attribuuttirelaatio. Tällaisessa tapauksessa attribuuteiksi otetaan kyseinen moniarvoinen attribuutti sekä sen kohdetyypin avainattribuutti, johon moniarvoinen attribuutti liittyy. S IJ A IN T I s ija in ti o stu n os tun sija in ti ttu n O S A S T O T o issa 1 N T Y O N T E K IJA Kuva 3.13: Moniarvoisten attribuuttien transformointi Suhdetyyppi 1:1 Suhdetyypin 1:1 transformointi tapahtuu siten, että jompaankumpaan tai molempiin suhdetyypin kytkemiin relaatioihin liitetään vastinrelaation perusavain viiteavaimeksi. Normaalisti perusavain talletetaan sen kohteen relaatioon, joka kahdesta osallistuu kyseiseen suhteeseen täydellisesti. (ks. kuva 3.14) Mikäli molemmat kohteet osallistuvat suhteeseen täydellisesti, ne voidaan mieltää samaksi ja molemmat relaatiot supistaa yhdeksi relaatioksi. Tällaisessa tapauksessa tehdään toisen relaation perusavaimesta uuden supistetun relaation perusavain. Poikkeuksen muodostaa tilanne, jossa kumpikaan kohteista ei osallistu suhteeseen täydellisesti. Tällöin luodaan 1:1 suhteesta oma erillinen relaationsa, johon yhdistelmä-avaimeksi otetaan kummankin peruskohteen avaimet sekä kyseiselle suhteelle ominaiset attribuutit.

31 ostun OSASTO (1,1) (0,1) Johtaa 1 1 ttun TYONTEKIJA OSASTO ostun... ttun TYONTEKIJA ttun Kuva 3.14: Suhdetyypin 1:1 transformointi Suhdetyyppi 1:N Suhdetyyppi 1:N transformoidaan sijoittamalla siihen relaatioon, joka vastaa N-puolella olevaa kohdetyyppiä, viiteavaimeksi toisen relaation perusavain. Mikäli tilanne on kuitenkin sellainen, että N-puolen kohde osallistuu suhteeseen vain osittain ja suuri osa N-puolen kohteista ei kuulu mihinkään suhteeseen, kannattaa suhteesta tehdä oma relaationsa. Näin säästetään levytilaa, sillä tällaisessa tapauksessa N-puolen relaatioon tulisi paljon tyhjiä kenttiä vierasavaimen ja kohdetyypin attribuuttien tilalle. Tällainen suhderelaatio toteutetaan siten, että sen attribuuteiksi tulevat kohdetyypin ominaisuudet, N-puolen relaation pääavain ja 1-puolen relaation pääavain. Molemmat pääavaimet toimivat relaatiossa vierasavaimina vastinrelaatioonsa. Relaation varsinainen pääavain on N-puolen relaation pääavain. ostun OSASTO (1,N) (1,1) Toissa 1 N ttun TYONTEKIJA Kuva 3.15: Suhdetyypin 1:N transformointi OSASTO ostun... TYONTEKIJA ttun... ostun Suhdetyyppi N:M Suhdetyypin N:M transformoinnissa suhdetyyppiä varten luodaan oma ns. suhderelaatio, jonka attribuuteiksi tulevat suhdetyypin omat attribuutit ja perusavaimeksi vastaavien kohderelaatioiden avainattribuutit. Tämän suhdetyypin transformoinnissa ei ole vaikutusta sillä, onko molempien kohdetyyppien osallistuminen suhteeseen täydellistä vai ei.

32 totun otun T O IM IT T A J A (1,N ) (1,1) Toim itus O S A 1 N m a a ra TOIMITTAJA totun... TOIMITUS totun otun maara OSA otun... Kuva 3.16: Suhdetyypin N:M transformointi Binäärinen suhdetyyppi Edelliset esimerkkejä binäärisestä suhdetyypistä. Binäärinen suhdetyyppi on kysymyksessä niin kauan, kun suhteeseen osallistuu kaksi kohdetta. Suhdeaste kertoo suhteen sitomien kohdetyyppien lukumäärän. N:äärinen suhdetyyppi N:äärinen suhdetyyppi transformoidaan kuten N:M tyyppinen suhdetyyppi. PROJEKTI ptun PROJEKTI ptun... totun N otun TOIMITTAJA Toimitus 1 N maara OSA OSA otun... TOIMITTAJA totun... TOIMITUS totun otun ptun maara Kuva 3.17: N:äärisen suhdetyyppi transformointi Yleistysrakenteen vaihtoehtoiset transformointisäännöt Tavallisen ER-mallin transformoinnin lisäksi on olemassa omat sääntönsä abstraktiorakenteiden eli EER-mallien transformointiin. Nämä transformointisäännöt ovat vaihtoehtoisia ja onkin valittava aina tilanteeseen parhaiten sopiva. A. Kutakin yli ja alityyppiä varten omat relaatiot Ensimmäinen tapa transformoida on yleinen ja pätee kaikissa abstraktio-tilanteissa. Haittana on kuitenkin, että tauluja syntyy tällä tavalla paljon. Kaikkiin relaatioihin liitetään perusavaimeksi ko. kohdetyypin avainattribuutti(t).

33 A J O N E U V O...... A jo n e u v o A U T O...... A u to V e n e V E N E...... Kuva 3.18: Abstraktiorakenteen transformointi: kaikille tyypeille oma relaatio B. Kutakin alityyppiä varten omat relaatiot Tällä tavalla relaatioihin sijoitetaan alityypin omat attribuutit sekä ylityypiltä perityt attribuutit. Tämä tapa soveltuu tilanteisiin, joissa aliluokat ovat kattavia ja erillisiä. Tämä tapa ei sovellu käytettäväksi tilanteissa, joissa aliluokat eivät ole kattavia, koska siinä tapauksessa joitakin tapauksia jäisi relaatioiden ulkopuolelle. AUTO reknro paino reknro Ajoneuvo paino Auto d pituus Vene VENE reknro pituus... Kuva 3.19: Abstraktiorakenteen transformointi: alityypeille omat relaatiot C. Kattava iso relaatio Tällä tavalla transformoitaessa sijoitetaan attribuuteiksi yli- ja alityyppeihin liittyvät attribuutit sekä erilaistamisen ilmaiseva attribuutti. Tapa soveltuu tilanteisiin, joissa aliluokat ovat kattavia ja erillisiä sekä alityyppikohtaisia attribuutteja on vähän. AJONEUVO reknro Ajoneuvo reknro atyyppi paino pituus paino Auto d pituus Vene Kuva 3.20: Abstraktiorakenteen transformointi: yksi iso relaatio tyypin osoittavalla attribuuttimääreellä D. Kattava iso relaatio ja Boolean-arvoiset attribuuttimääritteet Viimeisellä tavalla transformoitaessa sijoitetaan attribuuteiksi yli- ja alityyppeihin liittyvät attribuutit sekä käytetään Boolean-arvoista (YES/NO) attribuuttia määrittelemään, ovatko sitä seuraavat

34 attribuutit relevantteja ko. monikossa vai eivät. Tapa soveltuu tilanteisiin, joissa aliluokat ovat kattavia/osittaisia ja leikkaavia. reknro Ajoneuvo AJONEUVO reknro aflag paino vflag pituus paino Auto o pituus Vene Kuva 3.21: Abstraktiorakenteen transformointi: yksi iso relaatio Boolean-arvoisella attribuuttimääreellä

4 Tietokannan rakenteen määrittely ja tietotyypit 35 4.1 Tietokannan rakenteen määrittely SQL-kielellä voidaan hoitaa sekä tietokannan kyselyt että rakenteen määrittely (DDL-osat). Uusia tauluja luotaessa tulee jokaiselle taululle määritellä taulun nimi ja siihen tulevat sarakkeet. Tauluille voidaan määritellä perusavaimet, viiteavaimet ja toissijaiset indeksit. Lisäksi voidaan määritellä myös näkymiä. Tauluja, rajoituksia, avaimia ja näkymiä voidaan tarvittaessa myös poistaa tai niiden ominaisuuksia jälkikäteen muuttaa. Sarakkeiden (kenttien) määrittely Sarakkeen nimi Sarakkeen nimen tulisi olla mahdollisimman kuvaava. Koska nykyiset tietokannan hallintajärjestelmät tukevat varsin pitkiä nimiä, on pitkä ja kuvaava parempi kuin lyhyt. Nimessä ei myöskään kannata käyttää välilyöntejä eikä skandeja (å,ä,ö). Joissakin järjestelmissä myös alaviivasta _ kannattaa pidättäytyä, koska sitä voidaan hakuja tehtäessä käyttää jokerimerkkinä. Tietotyyppi Vaihtelee käytettävän Tietokannan hallintajärjestelmän mukaan. Esimerkkinä SQL92 standardi. Maksimipituus Määritellään tarpeen ja vaatimusten mukaan. Tietokannan toimittaja määrää yleensä maksimipituudet myös tietotyyppikohtaisesti ja näistä täytyy tietysti pitää kiinni. Numeerisille tietotyypeille tarkkuus Määritellään esimerkiksi, montaako desimaalia käytetään. Pakollisuus Onko kyseinen kenttä pakollinen eli sallitaanko siinä NULL -arvot. NOT NULL -määritystä käytetään pakollisen kentän yhteydessä. Sallittujen arvojen rajoitukset Määritellään tarpeen ja vaatimusten mukaan rajoitukset kentän arvoille. Nämä rajoitukset tulevat vaatimusmäärittelystä, liiketoimintasäännöistä tms. Esim. Palkka voidaan rajoittaa välillä 500-10000. Oletusarvo Mikä arvo on kaikkein yleisin kyseisessä kentässä. Esim. Palkka 1500.

36 4.2 Eri tietokantojen tietotyyppimäärityksiä SQL 92 Tietotyypit Tietotyyppien ominaisuudet vaihtelevat jonkin verran tietokannan hallintajärjestelmästä riippuen. Onkin tärkeä tietää, minkälaisia tietotyyppejä juuri käytettävissä olevassa tietokannassa voidaan käyttää. Yhtä kaikki, SQL92 standardi on ollut pohjana useimmille tämän päivän tietotyyppirakenteille, ja samanlaisia tietotyyppikategorioita löytyy useimmista eri tietokannoista. Ohessa siis hieman tarkemmin selitettynä juuri SQL92 standardin tietotyypit. Kuva 4.1: SQL 92 Tietotyypit (Lahtonen 2002)

37 Merkkijonotietotyypit CHARACTER (CHAR) Tietotyyppi on täsmälleen annetun pituuden mittainen kiinteämittainen merkkijono. Jos kenttään syötetään varattua vähemmän tietoa, tietokannan hallintajärjestelmä täyttää automaattisesti välilyöntejä jäljelle jääneeseen tilaan. Tämän tietotyypin käyttäminen on perusteltua esimerkiksi henkilötunnuksen yhteydessä. CHARACTER VARYING (VARCHAR) Tietotyyppi on maksimissaan annetun pituuden mittainen vaihtuvamittainen merkkijono. Tämän tietotyypin käyttö on perusteltua useimmissa merkkitietoa tallettavissa kentissä. (esim. etu- ja sukunimet, osoitteet jne.) VARCHAR tietotyypin lisäksi useimmissa tietokannoissa on variaatioita, jotka ottavat huomioon kansalliset merkistöt. Tällaisia ovat esimerkiksi Oraclen NVARCHAR tai MySQL:n NATIONAL VARCHAR. Access sen sijaan hyväksyy suoraan omana tekstityyppinään kansalliset merkit. Ongelmia tulee vasta, kun luotua tietokantaa käytetään järjestelmässä jossa on käytössä eri kansallinen merkistö. Numeeriset tietotyypit NUMERIC Tietotyyppi on tarkka desimaaliluku, jossa on täsmälleen haluttu maksimimäärä numeroita ja näistä haluttu määrä varattuna desimaaleille. DECIMAL Tietotyyppi on tarkka desimaaliluku, jossa on vähintään haluttu maksimimäärä numeroita ja näistä haluttu määrä on varattuna desimaaleille. INTEGER (INT) ja SMALLINT Tietotyypit ovat kokonaislukuja joista SMALLINT-tietotyypin lukualue on pienempi kuin INTEGERtietotyypin. FLOAT Tietotyyppi tarkoittaa liukulukua, jolle voidaan määritellä haluttu tarkkuus. REAL ja DOUBLE ovat ympäristöriippuvaisia versioita FLOAT-tietotyypistä. Bittitietotyypit BIT Tietotyyppi on tarkoitettu binäärimuotoisen datan tallettamiseen. BIT on kiinteämittainen bittijono, joka on täsmälleen annetun pituuden mittainen. BIT VARYING Tietotyyppi on vaihtuvamittainen bittijono, maksimissaan annetun pituuden mittainen. Aikatietotyypit INTERVAL Tietotyyppi tarkoittaa ajanjaksoa, joka voi koostua joko vuosista ja kuukausista tai päivistä, tunneista, minuuteista ja sekunneista.