Tietokannat

1. Tietokannat Aineopintokurssi, 3-4 ov, syksy 2004 Turun yliopisto / ohjelmistotekniikka / Salo Lasse Bergroth _____________________________________ Kurssi perustuu kirjaan Elmasri - Navathe: Fundamentals of Database Systems, Addison-Wesley 2004, 4. painos

2. Kurssin aikataulu • Luennot yhteensä 48 tuntia • maanantaisin alkaen 2004-09-13, kello 12.15-14.00, sali 373 • 2004-10-25 pidettävä luento on edellisestä poiketen salissa D113 • tiistaisin alkaen 2004-09-14, kello 10.00-11.45, sali 373 o ei luentoa ma 2004-09-20 ( peruutettu matkan takia ) o lisäluento keskiviikkona 2004-09-22, kello 10.45-12.30, sali 373 o kurssin viimeinen luento tiistaina 2004-11-30 • Demonstraatiot tiistaisin kello 14.00-15.45, yhteensä 12 tuntia • Ensimmäinen kerta 2004-10-26, sali D113 • Seuraavat kerrat viikon välein salissa 373 • Viimeinen demonstraatiokerta 2004-11-30

3. Kurssin suoritustavat • Kurssi koostuu luennoista, demonstraatioista, harjoitustyöstä ja tentistä. • Demonstraatiotehtäviä yhteensä 6∙5 = 30 tehtävää. • 10½ tehtävää (35%): tenttioikeus • 16½ tehtävää (55%): ¼:n hyvitys tenttiarvosanaan • 22½ tehtävää (75%): ½:n hyvitys tenttiarvosanaan • 28½ tehtävää (95%): ¾:n hyvitys tenttiarvosanaan • Hyvitykset tulevat aina hyväksytyn tenttiarvosanan päälle. • Tehtävät ovat saatavilla noin viikkoa ennen demonstraatiotilaisuutta. • Kysymykset löytyvät verkosta kurssin kotisivulta osoitteesta http://www.cs.utu.fi/opinnot/kurssit/Salo/syksy2004/bergroth/tietokannat.htm. • Harjoitustyöt ovat saatavilla marraskuun alkupuolella. Tehtävänä on suunnitella ja toteuttaa pienimuotoinen tietokanta. Työ tehdään 3-4 hengen ryhmissä, mutta tarvittaessa myös 1-2 hengen ryhmätkin tulevat kyseeseen. • Kaikkiin tentteihin pitää ilmoittautua viimeistään viikkoa etukäteen 3. kerroksen ilmoitustaululla olevalle listalle! • Tenttiin vastaamisaikaa käytettävissä 4 tuntia. • 5 kysymystä, jotka kaikki arvostellaan 6 pisteen arvoisesti, maksimipistemäärä 30 • hyväksyttyyn arvosanaan riittää 15 pistettä • Kurssin ensimmäinen tenttimistilaisuus on tarjolla 2004-12-20 kello 14.00 – 18.00 salissa D113.

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

5. 1. Tietokannat ja tietokantojen käyttäjät 1.1. Tietokannan määritelmä ja ominaisuudet • Tietokannalla tarkoitetaan kokoelmaa tietoja, joilla on ilmeinen yhteys toisiinsa ( esimerkiksi kirjaston asiakkaita ja sieltä lainattavaa materiaalia koskevat tiedot, yliopiston opiskelijarekisteri, yrityksen asiakas- ja tuotantotiedot, pankin asiakas- ja tilitiedot, sairaalan potilastiedot, autojen rekisteritiedot jne. ). • Tietokannan osien välillä pitää olla looginen yhteys, eli sinne säilöttyjen tietojen pitää olla riittävän voimakkaasti sidoksissa toisiinsa. Esimerkiksi kirjan yksittäisen sivun sisältämistä sanoista koottu luettelo ei täytä tietokannan kriteeriä. • Tietokanta edustaa siten jotain selkeästi määriteltyä ja rajattua kohdetta reaalimaailmassa. Muutokset tällaisessa 'minimaailmassa' heijastuvat muutoksina kyseistä kohdetta kuvaavaan tietokantaan. • Menettelytavat, joilla tietokannan sisältämät tiedot on kerätty, ovat hyvin määritellyt eivätkä sattumanvaraisesti valitut ( esimerkiksi asiakastietojen / kirjastossa tarjolla olevan nidevalikoiman päivittä-minen ). • Tietokannan sisältämät tiedot ovat ainakin jonkin intressiryhmän kannalta hyödyllisiä tai mielenkiintoisia. Muutoin ei olisi mielekästä edes perustaa kyseistä tietokantaa saatikka ylläpitää sitä. • Tietokannat voivat nykyisin yhä enenevässä määrin sisältää — paitsi perinteistä tekstimuotoista, numeerista ja loogista tietoa — niin myös esimerkiksi videokuvaleikkeitä ja karttatietoa. • Tietokannat voivat vaihdella kooltaan erittäin suuresti. Yksinkertaisimmillaan se muodostuu yhdestä ainoasta tiedostosta, joka sisältää pienehkön määrän tietueita. Esimerkiksi kelpaisi vaikkapa yksityishenkilön puhelinmuistioon tallennetut nimi-, osoite ja puhelin-numerotiedot. Toisessa ääripäässä ovat puolestaan valtion ja suuryritysten ylläpitämät massiiviset tietovarastot ( esimerkiksi Yhdysvaltain kansalaisten verotiedot viimeisten viiden vuoden ajalta, kts. oppikirjan sivu 5 ).

6. 1.2. Esimerkki tietokannasta • Tietokannan ei välttämättä tarvitse olla sähköisessä muodossa, vaan pieniä tietokantoja voidaan ylläpitää myös manuaalisesti ( vrt. puhelinmuistiot, kalenterit yms. ). • Ohjelmistoa, joka mahdollistaa tietokannan perustamisen ja ylläpitämisen, kutsutaan tietokannan hallintajärjestelmäksi ( TKHJ ). Se sisältää työvälineet, joiden avulla käyttäjän muodostamat kyselyt ja päivitykset saadaan toteutettua itse tietokantaan. • Tietokannan sisältämä data sekä sen kuvailemiseksi tehdyt määrittelyt ( ns. metadata ) pidetään toisistaan fyysisesti erillään. • Tietokoneympäristöön toteutettu tietokanta ei vaadi välttämättä tuekseen kaupallista ohjelmistoa, mutta usein tietokannan määritteleminen, toteuttaminen ja käsittely vaativat suuremman työpanoksen, jos TKHJ halutaan ohjelmoida kokonaan itse. Työmäärän lisääntyminen korostuu erityisesti muutettaessa tietokannan rakennetta uusien tiedon ylläpitotarpeiden mukaiseksi. • Tietokannan sovellusohjelmien, TKHJ:n, sekä levylle tallennetut data- ja määrittelytiedot muodostavat yhdessä ns. tietokantajärjestelmän. • Yliopiston opiskelijoiden opintotiedot ( kts. oppikirjan sivu 7 ) • Viisi eri kokonaisuutta, jotka ovat omina tiedostoinaan o Opiskelijan tiedot o Kurssin yleistiedot o Kurssin yksittäisen luentokerran tiedot o Tiedot opintosuorituksista o Kurssin esitietovaatimukset

7. 1.3. Miksi perustaa tietokanta? • Jokainen tiedosto muodostuu tietueista, jotka sisältävät tietokenttiä. • Jokainen tietokenttä edustaa jotain tiettyä yksikäsitteistä tietotyyppiä ( merkkijono, kokonaisluku, reaaliluku, looginen tieto jne. ). • Lueteltua tyyppiä, jolla on verrattain suppea arvojoukko, voidaan esittää myös koodaamalla ominaisuudet esimerkiksi kokonaislukujen tai lyhenteiden avulla ( esimerkiksi pääaineet: 1=matematiikka, 2=fysiikka, 3=tietojenkäsittelytiede jne. ). • Jokaisella tietokannan sisältämällä tiedostolla on looginen yhteys ainakin yhteen muuhun tiedostoon tietokannan sisällä ( esim. kurssi - kurssin esitiedot, opiskelija - opintosuoritusote, kurssi - kurssin luennointikerrat jne. ). • Yhteydet eri tiedostojen välillä mahdollistavat monimutkaistenkin kyselyjen ja operaatioiden suorittamisen. Esimerkiksi listataan kaikkien niiden opiskelijoiden tiedot, jotka suorittivat vuonna 1999 pidetyn tietokantojen kurssin. 1.3.1. Tietokantajärjestelmän kyky kuvailla itseään • Vaihtoehtona voitaisiin ajatella yksittäisten tiedostojen ylläpitoa yhden yhtenäisen tietokannan asemesta. • Vaikka tiedostorakenne on hyvin yksinkertainen, käytännön pulmat tulevat usein kuitenkin nopeasti esiin • o samoja tietoja saatetaan tarvita yksikössä usealla taholla ( esimerkiksi opintosuoritusten ja lukukausimaksujen hallinta: molemmissa tarvitaan opiskelijan perustietoja ) • ----> samoja tietoja joudutaan ylläpitämään useassa paikassa, mikä johtaa moninkertaiseen samojen tietojen ylläpitoon: hukataan sekä työtunteja että tietokoneiden muistitilaresursseja

8. 1.3.2. Ohjelmien ja datan eristäminen toisistaan; tietoabstraktio • Tietokantalähestymistapa estää tiedon tarpeettoman moninkertaisen ylläpidon, kunhan tietokanta määritellään huolellisesti ennen sen perustamista. • Määrittelyn yhteydessä kuvataan tietokantaan kuuluvien tiedostojen sisältämät kentät, niiden tyypit sekä rajoitukset kenttiin tallennettavalle datalle. Määrittelyistä käytetään nimitystä metadata, ja se tallennetaan ns. systeemiluetteloon ( system catalog ). • Metadata sisältää kaiken tarpeellisen tiedon tietokannan rakenteellisista ominaisuuksista. • Tietokannan selkeänä etuna yksittäisten tiedostojen käsittelemiselle on fyysisen tallennusrakenteen näkymättömyys käyttäjälle. Riittää tietää, minkä nimiseen tiedostoon ja sen kenttään viitataan. Yksittäistä tiedostoa käsiteltäessä pitää sen rakenne tietää tarkoin, ja muutokset tiedoston tietuerakenteessa voivat edellyttää suuria muutoksia sitä käsitteleviin ohjelmiin. • Kaupallisilla sovelluskehittimillä voidaan rakentaa useita toisistaan täysin riippumattomia tietokantasovelluksia. Edellytyksenä on ainoastaan, että sekä tietokanta että sen määrittelyt ovat ohjelman luettavissa. • Tietokantajärjestelmässä tietokannan rakenteen muuttuminen ei yleensä johda suuriin muutostoimenpiteisiin, sillä data ja määrittelyt sijaitsevat toisistaan erillään ----> tiedon riippumattomuus ohjelmista • Esimerkki: uuden kirjattavan ominaisuuden ( vaikkapa syntymäajan ) lisääminen opiskelijaa kuvaavaan tietueeseen ----> vain opiskelijataulua kuvaava määritys pitää uusia ( ongelmia voi kuitenkin esiintyä, jos ei esimerkiksi sallita kyseiselle kentälle puuttuvaa arvoa, sillä vanhoista tietueista syntymäaikatieto puuttuu määrittelyä muutettaessa ). • Oliokeskeisissä sekä ns. olio-relaatiotietokannoissa voidaan määritellä tietokannan sisältämälle datalle myös operaatioita ( funktioita ). Funktiosta pitää tietää käyttöliittymä ( nimi + parametrit ), mutta niiden toteutus kätketään käyttäjältä ----> ohjelmien operaatioriippumattomuus.

9. 1.3.3. Erilaiset näkymät tietokannan sisältämään dataan • Esimerkkinä operaatiosta voitaisiin mainita vaikkapa opiskelijan opintosuoritusten arvosanojen keskiarvon laskeminen. • Ohjelmien riippumattomuutta datasta ja operaatioista kutsutaan tietoabstraktioksi. • Tietomalli on tietoabstraktion tyyppi, joka mahdollistaa tietokannan käsitteellisen kuvaamisen ilman, että on tiedettävä tiedon fyysisestä tallennusrakenteesta tai funktioiden toteutustavasta. • Korkean tason tietomalli kuvaa tietokannan sisältämien kokonaisuuksien ( esimerkiksi opiskelijan tiedot, kurssitiedot jne. ) ominaisuuksia ja niiden välisiä riippuvuuksia siten, että käyttäjä pystyy ne ymmärtämään helpommin kuin tietokannan fyysisen tallennusrakenteen. • Suurissa tietokantasovelluksissa ei ole yleensä mielekästä, että kaikki käyttäjät saavat käyttöönsä kaiken mahdollisen kantaan tallennetun tiedon, vaan ainoastaan käyttäjälle itselleen tarpeellisen. • Näkymää voidaan rajata poistamalla yksittäisestä kokonaisuudesta tarpeettomia kenttiä ( kts. kirjan esimerkki 1.4. ). • Tarpeen mukaan voidaan lisäksi yhdistellä useaan eri kokonaisuuteen kuuluvia tietoja ( esimerkiksi ne kirjaston asiakkaat, joilla on sakkoja maksamatta ).

10. 1.3.4. Tiedon jakaminen ja monen käyttäjän tapahtumien käsittely 1.4. Tietokannan varsinaiset toimijat • TKHJ:n pitää pystyä huolehtimaan päivitysten oikeellisuudesta, kun useampi kuin yksi henkilö kerrallaan pyrkii päivittämään samaa tiedostoa ( esimerkki: kulkunevojen paikanvarausjärjestelmät ). • On varmistuttava, etteivät jo hetkeä aikaisemmin tehdyt päivitykset jää huomioimatta esimerkiksi paikkoja varattaessa. oPäivitysten oikeellisuuden takaamista tarkastellaan lisää Tietokantojen jatkokurssilla. • Pienen tietokannan sekä suunnittelija, toteuttaja että päivittäjä voivat olla yksi ja sama henkilö. • Tilanne muuttuu ratkaisevasti, kun tietokanta on suuri, ja sillä on paljon erilaisia käyttäjiä ja käyttötarkoituksia. • Tietokantoja käsittelevät työntekijät voidaan karkeasti jakaa kahteen ryhmään: ns. varsinaisiin toimijoihin ja taustavoimiin. • Varsinaisiin toimijoihin lasketaan tietokannan valvojat, suunnittelijat ja loppukäyttäjät. • Varsinaiset toimijat ovat kiinnostuneita itse tietokannan ominaisuuksista ja/tai sisällöstä.

11. 1.4.1. Tietokannan valvoja • Tarvitaan organisaatioissa, joissa tietokannalla on useita samanaikaisia käyttäjiä. • Vastaa ensisijaisesti tietokannan sisältämän tiedon hallinnasta, toissijaisesti tietokannan hallintajärjestelmän sekä sovellusohjelmien toimivuudesta ja tehokkuudesta. • Huolehtii lisäksi käyttöoikeuksien jakamisesta henkilöstölle sekä järjestelmän tietoturvasta. • Huolehtii lisäksi tarvittavien ohjelmistojen ja laitteistojen hankinnasta. • Suurissa organisaatioissa voi tietokannan valvojalla olla tukenaan avustavaa henkilökuntaa. 1.4.2. Tietokannan suunnittelija • Vastaa tietokannan rakenteellisesta määrittelystä. • Toimii tiiviissä yhteistyössä kaikkien tietokannan tulevien käyttäjien kanssa ennen tietokannan toteuttamista, jotta tietokanta vastaisi mahdollisimman tarkoin käyttäjien tarpeita ja toivomuksia. • Räätälöi eri käyttäjäryhmille erilaiset näkymät tietokantaan. • o Valitsee näkymiin tarkalleen niitä tietoja, joita käyttäjät työtehtävissään tarvitsevat.

12. 1.4.3. Loppukäyttäjät • Loppukäyttäjät voidaan jaotella neljään eri ryhmään kuuluviksi tietotarpeen mukaan: • Satunnaiset käyttäjät • tarvitsevat tietokannasta tietoa silloin tällöin • haettavat tiedot saattavat vaihdella ----> tarvetta ainakin osittaiselle kyselykielen osaamiselle • yleensä yrityksen keski- tai ylemmän johdon edustajia • Peruskäyttäjät ( naiivit eli parametriset käyttäjät ) • tarve ymmärtää tietokannan rakennetta hyvin vähäinen • valmiiksi määritellyt sovellusohjelmat ----> kyselykielen opetteleminen ei tarpeen • esimerkiksi toimisto- ja paikanvaraussovellusten käyttäjät, pankkivirkailijat jne. • Kehittyneet loppukäyttäjät • tiedonsaannin tarpeet usein monimutkaisia ja vaihtelevia • kyselykielen ja myös tietokannan rakenteen ymmärtäminen oleellisen tärkeää • insinöörit, tiedemiehet, analyytikot jne. • Yksinäiskäyttäjät • ylläpitävät jotain rajattua osaa tietokannasta • pystyvät kehittämään itse kyseiseen sovellusalueeseen tarpeellisia ohjelmia

13. 1.4.4. Tietojärjestelmäanalyytikot ja sovellusohjelmoijat • Tietojärjestelmäanalyytikot kartoittavat valmiiden sovellusohjelmien tarpeen loppukäyttäjille ja suunnittelevat tarvittavat ohjelmat. • Sovellusohjelmoijien tehtävänä on toteuttaa tietojärjestelmä-analyytikon suunnittelemat sovellusohjelmat • Toisin kuin varsinaiset toimijat, taustavoimat eivät suoranaisesti ole kiinnostuneita itse tietokannasta. • Tietokannan hallintajärjestelmän systeeminsuunnittelijat suunnittelevat ja toteuttavat TKHJ:n moduulit. Moduuleja ovat mm. systeemiluettelo, kyselykieli, kilpailevien tapahtumien hallinta, toipuminen virhetilanteista, turvallisuus, käyttöliittymät sekä tietoihin käsiksi pääseminen. • Työvälineiden kehittäjät pyrkivät saamaan aikaan välineitä, joilla tietokannan suunnittelua ja käyttöä voidaan helpottaa. • Operaattorit huolehtivat yrityksen ATK-laitteiston yleisestä toimivuudesta. 1.5. Tietokantojen taustavoimat

14. 1.6. Tietokannan hallintajärjestelmästä saatavia hyötyjä • Redundanssin ( tiedon toistamisen ) kontrolli • Tiedon toistamista tapahtuu perinteisessä tiedostojärjestelmässä, kun usealla taholla joudutaan syöttämään samoja tietoja ( vrt. yliopiston opiskelijoiden opintomaksut ja opintosuoritukset: kummassakin paikassa tarvitaan opiskelijan perustietoja ). • Seurauksena ylimääräistä tiedon syöttö- ja päivitystyötä sekä levytilan tarpeetonta tuhlausta. • Virhe tallennuksessa ( esimerkiksi syntymäajan kohdalla ) johtaa siihen, että opiskelijan tiedot näkyvät erilaisina eri toimipisteissä ----> tiedon vastaamattomuus eli inkonsistenssi • Käytettäessä tietokantalähestymistapaa eri käyttäjäryhmät integroidaan tietokannan suunnitteluvaiheessa ----> samat tiedot tallennetaan vain yhteen kertaan • Hyvin perustelluista syistä voidaan tietoa kuitenkin toistaa useaan tiedostoon. Näin voidaan tehdä esimerkiksi kyselyjen nopeuttamiseksi. • Esimerkki: opintosuorituksia kuvaavaan tiedostoon voidaan mennä lisäämään opiskelijan nimi ja kurssin tunnus, sillä niiden näkyminen opintosuoritusotteessa on varsin tarpeellista. • Tällöin on kuitenkin määriteltävä metadataan säännöt, jotka vaativat vastaavuutta opiskelijan nimen ja opiskelijanumeron sekä vastaavasti kurssin nimen ja sen luennointikerran välille, jotta tietokanta pysyisi konsistenttina. Tällaista menettelyä kutsutaan kontrolloiduksi redundanssiksi.

15. Tiedon käyttöoikeuksien jakaminen • Tietokannan valvoja pystyy määrittelemään erilaisia käyttäjäprofiileja, joiden mukaan määräytyy, mihin tietoihin kukin käyttäjä saa saantioikeudet ----> käyttäjätunnukset ja salasanat. • Tämä edellyttää tietystikin rajattua pääsyä tiettyihin TKHJ:n moduuleihin, kuten perustamaan uusia käyttäjätunnuksia. • Lisäksi voidaan rajata tietokantaan pääsy ainoastaan valmiiden loppukäyttäjäsovellusten kautta, tavoitteena loppukäyttäjien tekemien virheiden välttäminen ----> loppukäyttäjän ei tarvitse välttämättä saada tietokannan relaatiotauluja näkyviin. • Olioiden ja tietorakenteiden tallentaminen pysyvästi • Oliokeskeisissä tietokannoissa voidaan ohjelmointikielten objekteja tallentaa suoraan tietokantaan rikkomatta niiden rakennetta toisin kuin tiedostoon tallennettaessa ( ns. pysyvät objektit ). • Päättelyä tukevat ( deduktiiviset ) tietojärjestelmät • Loogiseen päättelyyn perustuvat tietokannat, joissa tietyn ominaisuuden olemassaolo perustuu hyvin määriteltyihin sääntöihin. • Logiikkatietokannoista lisää mm. logiikkaohjelmoinnin kurssilla. • Päättelysääntöjen muuttaminen yleensä helpompaa kuin sovellusohjelmien uusiminen uusia sääntöjä vastaaviksi.

16. Erilaiset käyttöliittymät eri käyttäjäryhmille • Lomake- ja valikkotyyppiset näytöt sekä opastavat graafiset käyttöliittymät peruskäyttäjille • Edellisten lisäksi kyselykielet edistyneemmille käyttäjille • Tietokannan tietojen välisten suhteiden esittäminen • Pystytään helpohkosti määrittelemään tietokannan eri kokonaisuuksien väliset yhteydet toisiinsa ( esim. kurssin perustietojen ja sen luentokertojen välillä, opiskelijan perustietojen ja opintosuoritusraportin välillä jne. ). • Helpottaa huomattavasti monimutkaisten hakujen ja päivitysten suorittamista. • Tietokannan eheyssääntöjen kontrollointi • Tyypin ja arvoalueen määrääminen tietokentille: laittomien arvojen tallentaminen tietokantaan estetään. • Avaintietokenttien yksikäsitteisyys ( esim. samaa opiskelija-numeroa ei saa esiintyä kahdella eri rivillä opiskelijoiden perustietoja kuvaavassa taulussa ) • Riippuvuudet tietokannan taulujen välillä: estetään viittausten katkeaminen • Esimerkin yliopistotietokannan tapauksessa voitaisiin vaatia, että luentoja voi järjestään ainoastaan sellaisesta kurssista, jonka perustiedot on jo tallennettu ----> ei perusteta sellaisia luentotietueita, joissa esiintyvä kurssi on tuntematon • Vastaavasti sellaisen kurssin tietojen poistaminen, josta on luentokertatietueita tai opintosuorituksia olemassa, olisi laitonta ilman kaikkien niiden tietojen tuhoamista tai muuttamista, jotka viittaavat kyseiseen kurssiin

17. Tietokanta ei ole kuitenkaan mikään 'ihmerakennelma' kaiken virheellisen tiedon eliminoimiseksi, sillä: • Tietokannan suunnittelu voi olla puutteellinen, jolloin on mahdollista, ettei edellä mainittuja tarpeellisia eheys-sääntöjä välttämättä asetettukaan. • Voidaan syöttää laillinen mutta virheellinen arvo johonkin tietokenttään, jonka arvoalue on rajoitettu. • Turvakopioinnin ja virheistä toipumisen tuki • Tietokannan hallintajärjestelmä mahdollistaa tallennettujen tietojen palauttamisen, mikäli jostain syystä ( esimerkiksi sähkökatkon takia ) ohjelman suoritus yllättäen keskeytyy. • Helpottaa tietokannan turvakopiointia erilaisten katastrofaalisten tilanteiden ( levyrikko, fataali käyttövirhe, ilkivalta yms. ) kannalta. • Mahdollisuus standardien valvontaan • Keskitetysti hallitulle tietokannalle voidaan määritellä käytännöt, jonka mukaisesti mm. taulut nimetään, raportit ja näkymät muotoillaan, mitä terminologiaa käytetään jne. Tämä ei onnistuisi, jos käyttäjät voisivat määritellä omat tiedostonsa ja ohjelmansa itse. • Sovelluskehityksen nopeutuminen • Kun tietokanta on kertaalleen määritelty ja perustettu, on uusien sovelluksien rakentaminen verrattain helppoa, koska fyysistä talletus-rakennetta ei tarvitse tietää ( sovelluksia rakennettaessa käytettävät käsitteet lähellä itse sovellusta ).

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

19. 1.7. Lyhyesti tietokantasovellusten historiasta • Ensimmäisiä tietokantasovellusten käyttäjiä olivat lähinnä suuret organisaatiot, kuten yliopistot, sairaalat ja pankit. • Kaikki yksittäistä henkilöä koskevat tiedot pyrittiin tallentamaan fyysisesti lähelle toisiaan ( ns. hierarkkinen tietokantamalli ) • henkilötunnisteen perusteella tapahtuva haku toimi hyvin nopeasti ( esimerkiksi tietyn opiskelijan kaikki opintosuoritukset ) • hakukriteerin muuttuessa suorituskyky kuitenkin hidastui merkittävästi ( esimerkiksi haettaessa tiettynä vuonna aloittaneiden opiskelijoiden opintosuorituksia ) • käsitteellisesti eri kokonaisuuksiin kuuluvia tietueita tallennettu toistensa perään ( henkilötiedot, opintosuoritukset jne. ) • myöskään mitään erityistä kyselykieltä ei ollut käytettävissä, vaan kaikki kyselyt oli toteutettava ohjelmointikieltä käyttämällä! • tietokannan rakenteen muuttaminen erittäin työlästä • Verkkomallin myötä tietojen fyysisestä sidonnaisuudesta päästiin eroon, mutta edelleen käyttäjäystävällinen kyselykieli puuttui. • Verkkomallissa yhteen kuuluvat tietueet linkitetään toisiinsa osoittimien avulla.

20. Relaatiotietokannat alkoivat yleistyä 1980-luvulla • alkuperäisenä kannustimena oli kyselyjen yksinkertaistaminen • samalla päästiin eroon kyselyiden sidonnaisuudesta tiedon fyysiseen tallennusrakenteeseen • mahdollisti käsitteellisesti samantyyppisen tiedon pitämisen yhdessä ( mm. opiskelijoiden perustiedot, kurssien perustiedot jne. ) • edelleen yleisin tietokantamalli nykypäivänä • Oliokeskeisissä tietokannoissa sallitaan myös ns. abstraktien tietotyyppien ja operaatioiden liittämistä osaksi tietokantaa. • etuna yhteensopivuus olio-ohjelmointikielten objektien kanssa • relaatiomallia laajempi tietotyyppivalikoima • standardoinnin puute ja järjestelmän monimutkaisuus kuitenkin käytön laajemman yleistymisen hidastajina. • WWW-teknologian myötä voidaan fyysisesti eri paikoissa sijaitsevia dokumentteja liittää toisiinsa hyperlinkkien avulla • Sähköisessä kaupankäynnissä verkkosivujen sisältö kootaan usein dynaamisesti eri tietokannanhallintajärjestelmistä. • XML-kieli työvälineenä tiedonsiirrossa eri tyyppisten tietokantojen ja verkkosivujen välillä • Uusimmilla sovellusalueilla puhdas relaatiomalli saattaa osoittautua liian rajoittuneeksi mm. sen riittämättömien tietorakenteiden ja tietotyyppien sekä ilmaisuvoimaltaan liian heikon kyselykielen takia. Tällaisia sovellusalueita ovat mm. • tieteelliset sovellukset, joissa tietomäärät ovat suuria • röntgen- ja magneettikuvien tallennus • videokuvan ja –leikkeiden tallennus • tiedonlouhinta ( esimerkiksi hahmontunnistus suuresta tietopankista ) • sää- ja karttatietokannat ( satelliittikuvien varastointi ) • aikasarja- ja muut tilastolliset ja taloustieteelliset mittaussovellukset

21. Saattaa olla perusteltua olla käyttämättä tietokannanhallinta-järjestelmää, mikäli TKHJ:n hankinta-, koulutus- sekä TKHJ:tä varten tarvittavan laitteiston tuomien lisäkustannusten ollessa kohtuuttoman suuret rakennettavan sovelluksen kokoon nähden. Tiedon hallintamekanismien yleisyys ----> tehottomuus TKHJ:n tuottaman tietoturvan, kilpailevien tapahtumien kontrolloinnin, toipumisen varmistamisen ja eheyssääntöjen tarkastusten aiheuttama ylläpidon monimutkaisuus Tietokannan suunnitteluun ja kunnolliseen toteutukseen panostettavien voimavarojen riittämättömyys. Tietokanta ja sen sovellukset ovat yksinkertaisia, ja tietokannan sisältämä tieto on luonteeltaan stabiilia ( ei juuri muutoksia kannan määrittelyihin ). Vaaditaan tiukkaa pitäytymistä reaaliaikaisuudessa ( haluttaessa karsia pois kaikki hidastuttavat elementit ). Haluttaessa perustaa vain yhden käyttäjän järjestelmä. 1.8. Milloin TKHJ:tä ei kannata käyttää?

22. 2. Tietokannan käsitteitä ja arkkitehtuuri • Aikaisemmin tietokannanhallintajärjestelmät olivat suuria, tiiviisti integroituja järjestelmiä. • Nykyisille TKHJ:lle on tyypillistä ns. asiakas-palvelin -arkkitehtuuri. ----> sovellusohjelmat toimivat käyttäjän omalla koneella, itse tietokanta palvelimella toisaalla. 2.1. Tietomallit, kaavat ja esiintymät • Tietomalli on kokoelma käsitteitä, joiden avulla pystytään kuvaamaan tietokannan rakennetta ( tietotyypit, rajoitukset ja tietojen väliset suhteet ). • o Tarjoaa välineet tiedon abstrahointiin. • o Käyttäjän itsensä määrittelemiä operaatioita tietokannan datalle kuten keskiarvon laskenta jonkin tietokentän arvoille esiintyy etenkin oliokeskeisessä tietomallissa, nykyisin myös ns. objekti-relaatiomallissa, joka on relaatio- ja oliotietomallin välimuoto. • o Sisältää usein myös perusoperaatiot tiedon hakua ja päivittämistä varten.

23. 2.1.1. Tietomallien eri kategoriat • Korkean tason eli käsitteellisissätietomalleissa tietokannan rakennetta kuvataan käsittein, jotka ovat käyttäjille luontevia ymmärrettäviksi ( entiteetti, attribuutti, liittymä ). • Matalan tason eli fyysisissä tietomalleissa kuvaillaan, miten data on tallennettuna tietokoneelle. Ne on tarkoitettu lähinnä tietokannan laitteistoa lähellä oleviin ominaisuuksiin erikoistuneille asiantuntijoille, ei niinkään tavallisille loppukäyttäjille ( tietueiden talletusmuoto, järjestys, saantipolut ). • Näiden kahden tason 'kompromissina' voidaan nähdä ns. toteutusmalli, joka on vielä loppukäyttäjänkin hahmotettavissa, muttei samalla kuitenkaan kohtuuttoman kaukana matalan tason tiedon organisointimallista ( piilottaa osan rakenteiden yksityis-kohdista, mutta voidaan silti käyttää suoraan TKHJ:ssä; useimmat kaupalliset TKHJ:t tukevat ). • Käsitteellisissä tietomalleissa entiteetti edustaa jotain reaalimaailman kohdetta tai käsitettä ( esimerkiksi opiskelijaa ). Attribuutti tarkoittaa jotain entiteettiin kuuluvaa ominaisuutta ( esimerkiksi opiskelijan nimi ). Liittymä puolestaan kuvaa kahden tai useamman entiteetin välistä yhteyttä ( esimerkiksi kurssin numero on kurssin perustiedot ja sen luennointikerrat toisiinsa liittävä attribuutti ). • Relaatiotietomallin ja yleistymässä olevan oliokeskeisen tietokantamallin lisäksi toteutusmalleihin luetaan aikaisemmat verkko- ja hierarkkinen malli, jotka tällä kurssilla sivuutetaan oliokeskeisen mallin lisäksi.

24. 2.1.2. Kaavat, esiintymät ja tietokannan tila • Kaikissa tietomalleissa itse tietokanta ja sen kuvaus pidetään erillään toisistaan. • Tietokannan kuvausta kutsutaan tietokannan kaavaksi ( database schema ). • Tietokannan kaava määritellään tietokannan suunnitteluvaiheessa, joten kaavaan odoteta tehtävän muutoksia kovin usein. • Kaavan yksittäistä objektia ( kuten yliopistoa kuvaavassa esimerkissä opiskelijaa, kurssia jne. ) kutsutaan kaavan rakenneosaksi ( schema construct ). • Kaavadiagrammi selvittää vain osan tietokannan kaavan sisällöstä, kuten taulujen nimet ja tietokentät sekä yksinkertaisia rajoituksia (esimerkiksi avainattribuutit). Monimutkaisia rajoituksia ei kaavadiagrammilla pystytä esittämään. • Tietokannan datasisältöä tietyllä hetkellä kutsutaan tietokannantilaksi. • Tietokanta on määrittelyn jälkeen tyhjässä tilassa ( ei vielä sisällä dataa ). • Ensimmäisen syöttövaiheen päätyttyä tietokanta on alkutilassaan. • Tehtäessä päivityksiä tietokantaan sen tila muuttuu. • Jokaisella tietokannan kaavan rakenneosalla on tietty nykyinen esiintymien joukko ( tietyssä taulussa yhtenä ajankohtana esiintyvien tietueiden sisältö ). • TKHJ:n tehtävänä on huolehtia, että jokainen tietokannan tila on laillinen sille asetetut säännöt huomioon ottaen. Täten on tietokannan käyttökelpoisuuden ja virheettömyyden kannalta hyvin tärkeää, että sen määrittely tehdään huolellisesti. Tietokannan määrittelyvaiheessa ratkeaa melko lailla kannan laadukkuus. • Tietokannan kaava voidaan tulkita tietokannan sisäisenä tarkennuksena, tietokannan tila puolestaan kaavan laajennukseksi.

25. 2.2. Tietokannan hallintajärjestelmän arkkitehtuuri 2.2.1. Kolmitasoarkkitehtuuri • Sisäinen taso ( kaava ), joka kuvaa tietokannan fyysistä tallennusrakennetta ja saantipolkuja. Sisäisellä tasolla käytetään matalan tason tietomallia. • Käsitetaso, jossa kuvaillaan koko tietokannan rakenne käyttäjille fyysistä tallennusrakennetta lukuun ottamatta, eli entiteetit, tietotyypit, säännöt, taulujen väliset suhteet ja käyttäjän määrittelemät operaatiot. Tason kuvaamisessa käytetään joko korkean tai toteutustason tietomallia. • Ulkoinen eli näkymätaso kuvaa sitä, millaisena kukin käyttäjäryhmä näkee tietokannan. Se sulkee ulkopuolelleen kaikki heille tarpeettomat osat, ja sen kuvaamiseksi käytetään korkean tason tietomallia. • Eri tasojen välillä käytetään kuvauksia, jotta esimerkiksi tehdyt tietokantakyselyt ja niihin saadut tulokset voidaan välittää tasolta toiselle kullekin tasolle ominaiseen esitysmuotoon. • Useimmat TKHJ:t eivät  lähinnä tehokkuussyistä  tue kahden ylimmän tason erottamista toisistaan, sillä kuvauksien suorittaminen tasojen välillä hidastuttaa tietokantaan kohdistuvien operaatioiden toteuttamista. • Varsinainen data sijaitsee aina fyysisellä tasolla. ·

26. 2.2.2. Tietoriippumattomuus • Kolmitasoarkkitehtuuri tukee tietoriippumattomuutta. Tämä tarkoittaa sitä, että tietokannan kaavan muutos alemmalla tasolla ei aiheuta muutoksia ylemmälle tasolle. Ainoastaan tasojen välinen kuvaus muuttuu. • Looginen tietoriippumattomuus tarkoittaa mahdollisuutta tehdä lisäyksiä käsitekaavaan ilman tarvetta muuttaa samalla ulkoista kaavaa tai sovellusohjelmia ( kts. esimerkkiä kirjan kuvista 1.2, 1.4 ja 1.5 ). Mikäli tietokantaa puolestaan supistetaan eli redusoidaan, muuttumattomiin rakenteisiin viittaavissa ulkoisissa näkymissä ei tapahdu muutoksia. • Fyysinen tietoriippumattomuus takaa, että fyysisten datatiedostojen uudelleenorganisointi ei aiheuta muutoksia ylemmillä tasoilla. Tämä mahdollistaa sen, että dataan voidaan lisätä esim. uusia saantipolkuja ilman, että kyselyitä tai sovellusohjelmia jouduttaisiin uusimaan. Muutos fyysisellä tasolla vaikuttaa vain operaatioiden suoritusaikaan. 2.3. Tietokannan kielet ja käyttöliittymät • Tietokannoissa voidaan käyttää erilaisia kieliä ja käyttöliittymiä eri tarkoituksiin. 2.3.1. TKHJ:n kielet • Tiedonmäärittelykieli DDL ( Data Definition Language ) on tarkoitettu tietokannan kaavan määrittelyä varten. • oTKHJ:hin sisältyy DDL-kääntäjä, joka muuntaa tehdyn määrityksen systeemiluettelon käyttämään muotoon.

27. 2.3.1. TKHJ:n kielet • Sisäisellä tasolla käytetään tietovaraston määrittelykieltä eli SDL:ää ( Storage Definition Language ). • Fyysisen ja käsitetason välinen kuvaus tehdään jommallakummalla kielistä DDL ja SDL. • Täydellisessä kolmitasoarkkitehtuurissa tarvittaisiin vielä näkymienmäärittelykieli VDL ( View Definition Language ) • Normaalisti käytetään kuitenkin DDL:ää sekä tiedon- että näkymienmäärittelykielenä. • Tiedon syöttöä ja tietokannan ylläpitoa varten tarvitaan edelleen datan käsittelykieli DML ( Data Manipulation Language ). • Nykyisissä tietokannan hallintajärjestelmissä kieliä ei sinänsä pidetä erillisinä SDL:ää lukuun ottamatta, vaan samaa kieltä voidaan käyttää sekä tietokannan että näkymien määrittelyyn ja datan käsittelyyn. Aikaisemmin myös SDL-ominaisuus sisältyi tietokannoille yleiseen SQL-kieleen, mutta sittemmin SQL:ää käytetään vain kahden ylimmän tason määrittelyyn. • Datan käsittelykieli voi olla luonteeltaan korkean tai matalan tason DML. • Korkean tason eli ei-proseduraalinen DML on luonteeltaan deklaratiivinen, eli se kuvaa, mitä tietoa kulloinkin tietokannasta käsitellään ( "joukko kerrallaan” ). Se on käyttökelpoinen sellaisenaan, mutta sitä voidaan käyttää myös upotettuna yleiseen ohjelmointikieleen. Tällöin tarvitaan DML-esikääntäjä avuksi, jotta DML-lauseet käännettäisiin erillään muusta ohjelmasta. • Matalan tason eli proseduraalinen DML voi toimia ainoastaan upotettuna yleiseen ohjelmointi-kieleen. Toisin kuin korkean tason DML, se kuvaa, miten tieto haetaan tietokannasta. Haku tapahtuu aina tietue kerrallaan, eli avuksi tarvitaan silmukkarakenteita.

28. 2.3.2. TKHJ:n käyttöliittymät • Käytettäessä apuna yleistä ohjelmointikieltä datan käsittelyä varten siitä käytetään nimitystä isäntäkieli ja DML:stä puolestaan nimitystä data-alikieli. Käytettäessä korkean tason DML:ää yksinään sitä kutsutaan usein kyselykieleksi, vaikkakin sitä voidaan käyttää myös päivitysoperaatioihin. • Peruskäyttäjät eivät turvaudu tietokannan erityiskieliin, vaan heitä varten perustetaan erilaisia käyttöliittymiä käyttöä helpottamaan. • Erilaisia käyttöliittymätyyppejä: • Valikkoperustaiset • lähinnä tietokannan selailua varten • Lomakepohjaiset • kyselyjen muodostamiseen • tiedon syöttöön • Graafiset • voidaan käyttää hyödyksi hiirtä • Luonnolliseen kieleen perustuvat • komennot muistuttavat luonnollista kieltä • viitataan tietokannassa esiintyviin kenttiin

29. 2.4 Tietokantajärjestelmäympäristö • Peruskäyttäjille suunnatut • toimintojen 'avauduttava' nopeasti • funktionäppäimet, lyhyet komennot yms. • Tietokannan valvojalle suunnatut • valmiudet luoda uusia käyttäjäprofiileja, tietokannan näkyvyyden rajoittamiseen ja tiedon fyysiseen uudelleenorganisointiin 2.4.1 TKHJ:n komponenttimoduulit • Tallennetun datan järjestelijä ( stored data manager ) • kontrolloi, onko viittauksen kohteena oleva tieto varsinaista dataa vai metadataa • käyttää avukseen käyttöjärjestelmän toimintoja järjestellessään tiedon siirtämistä levyltä keskusmuistiin • huolehtii puskureiden hallinnasta keskusmuistissa • Tiedonmäärittelykielen eli DDL-kääntäjä • prosessoi tietokannan kaavamäärittelyjä ja tallentaa kuvaukset ( metadatan ) systeemiluetteloon • Ajonaikainen tietokantaprosessori • käsittelee tietokantaan kohdistetut operaatiot • levyoperaatiot kulkevat tallennetun datan järjestelijän kautta

30. 2.4.2. Tietokantajärjestelmän palveluja • Kyselyiden kääntäjä • jäsentää, analysoi ja kääntää käyttäjän tuottaman kyselyn sekä generoi siitä koodin tietokantaprosessorille • Esikääntäjä erottelee datan käsittelykielen yleisen ohjelmointikielen keskeltä • DML-kääntäjä kääntää DML-osuuden, minkä jälkeen ohjelman osat linkitetään valmiiksi sovellusohjelmaksi • Tiedon lataaminen tietokantaan • lukeminen tekstitiedostosta tai konversio joltakin muulta tiedostotyypiltä nykyisen TKHJ:n ymmärtämään muotoon • Turvakopiointi • tarkoittaa yleensä koko tietokannan tallentamista nauhalle • voidaan tehdä joko täydellisenä tai inkrementaalisesti – s. o.pelkästään edellisen kopioinnin jälkeen muuttuneiden tietojen osalta • Tiedostojen uudelleenorganisointi • tehokkuuden lisäämiseksi

31. Suorituskyvyn seuranta • tilastotietoa tietokannan valvojan käyttöön • Muita palveluja ovat mm. mahdollisuus tiedostojen lajitteluun, tiedon tiivistämiseen, käytettävyys verkon kautta jne. 2.4.3 Työkaluja, sovelluskehitysympäristöt ja etäyhteydet • Tietokoneavusteinen ohjelmistosuunnittelu, ns. CASE-välineet ( CASE = Computer Aided Software Engineering ) • o hyödyksi tietokannan suunnitteluprosessissa • Tietohakemisto • o pitää sisällään TKHJ:n systeemiluettelon sisältämät tiedot, mutta on käyttötarkoitukseltaan laajempisisältää tietoja mm. tietokannan suunnittelua koskevista päätöksistä, käyttöstandardeista, sovellusohjelmien kuvauksen ja tietoa käyttäjistä palvelee etupäässä käyttäjiä pikemmin kuin TKHJ:n ohjelmistoa • Sovelluskehitysympäristöt • o helpottavat valmiiden sovellusohjelmien, graafisten käyttöliittymien ja kyselyiden muodostamista ( mm. PowerBuilder, JBuilder ) •   Yhteysohjelmistot • o tarvitaan, kun tietokanta on toteutettu asiakas-palvelin -arkkitehtuurilla ( tietokanta sijaitsee fyysisesti palvelinkoneella ) tai tietokanta on hajautettu ( jaettu usean koneen kesken ) • o usein erillismoduuleina TKHJ:ssä • o yhdistetystä tietokanta- ja tietoliikennesysteemistä käytetään lyhennettä DB/DC ( Database / Data communications )

32. 2.5. Tietokannanhallintajärjestelmien keskitetty / asiakas-palvelin -arkkitehtuuri 2.5.1. Keskitetty TKHJ:N arkkitehtuuri • Varhaisimmissa tietokannanhallintajärjestelmissä käytetty arkkitehtuuri • Tietokanta sijoitettuna suurtietokoneelle, johon käyttäjät olivat yhteydessä ’tyhmien’ päätteiden välityksellä • Mikrotietokoneiden yleistyessäkin useat tietokantasovellukset pyörivät edelleen keskuskoneissa, koska mikrotietokoneiden laskentavoima oli edelleen riittämätön tietokantasovelluksille • Koneiden tehon kasvaessa alkoi asiakas-palvelin –arkkitehtuuri vähitellen yleistyä tietokantasovelluksissa • Tarkastellaan kirjan kuvaa 2.4. 2.5.2. Yleistä asiakas – palvelin -arkkitehtuureista • Useita mikrotietokoneita, työasemia, tiedostopalvelimia, kirjoittimia, tietokantapalvelimia ja verkkopalvelimia on kytketty toisiinsa verkkoyhteyden avulla • Palvelinkoneiden, kuten tietokanta-, tiedosto-, verkko- ja sähköpostipalvelinkoneiden on tarkoitus huolehtia kyseisten palveluiden tarjonnasta verkkoon liitetyille asiakaskoneille, jotka on tarkoitettu yksittäisille käyttäjille.

33. Asiakaskoneille on asennettuna käyttöliittymät palvelimilla olevien sovellusten käyttöön saamiseksi. • Käyttäjät voivat lisäksi suorittaa omilla asiakaskoneillaan omia erikoissovelluksiaan, joissa em. palvelimia ei tarvita ja joita ei tarvitse tarjota kaikkien käyttäjien saataville. • On tyypillistä, että lähiverkkoon kytketty kone toimii ainoastaan asiakkaana tai palvelimena, mutta koneella voi olla samanaikaisesti myös molemmat ominaisuudet. 2.5.3 Kaksitahoinen asiakas – palvelin -ratkaisu • Asiakkaan koneella voidaan suorittaa tietokantaan kuuluvia sovellusohjelmia ja esittää kyselyjä, joiden prosessointi tapahtuu palvelinkoneella. • Tarvitaan yhteysohjelmisto, jonka avulla kommunikointi tietokannan datapalvelimen kanssa tapahtuu. • Mahdollistaa TKHJ:n hajautuksen: palvelin toimii puhtaasti datan käsittelijänä, kilpailevien tapahtumien kontrolloijana sekä virhetilanteista toipumisen toteuttajana. • Kyselyiden optimointi, käyttöliittymät ja tietohakemistojen käsittely tapahtuu puolestaan asiakkaan koneella.

34. 2.6. Tietokannan hallintajärjestelmien luokittelutavat 2.5.3 Kolmitahoinen asiakas – palvelin -ratkaisu • Internetin yleistyttyä asiakas-palvelin ratkaisuihin on tullut mukaan kolmas taso • Asiakkaalla on käytössään graafinen käyttöliittymä, jonka kautta hän ottaa yhteyttä sovelluspalvelimeen tai verkkopalvelimeen, joka käsittelee asiakkaan lähettämän pyynnön tai kyselyn ja lähettää sen eteenpäin varsinaiselle tietokantapalvelimelle. • Tietokantapalvelin palauttaa ainakin osittain käsitellyt tulokset takaisin edelliselle tasolle, jossa tulosta mahdollisesti vielä muokataan asiakkaan käyttöliittymälle sopivaksi. • Täten käyttöliittymä, sovelluksen säännöt ja varsinainen datan saanti tapahtuvat kolmella eri taholla. • Tietoliikenne asiakkaan ja sovelluspalvelimen välillä tapahtuu salatusti tietoturvan parantamiseksi. • Tärkein kriteeri on tietomalli ( relaatio-, olio-, verkko-, hierarkkinen vai olio-relaatiotietokanta ) • Muita kriteerejä: • yhden vai monen käyttäjän järjestelmä? • keskitetty vai hajautettu?

35. jos hajautettu, niin onko tietokannan hallintajärjestelmä homogeeninen vai heterogeeninen? • käytetäänkö samaa vai eri TKHJ-ohjelmistoatietokannan eri sijaintipisteissä? • hajautettu heterogeeninen TKHJ on ainakin jossain määrin paikallisesti autonominen, jolloin puhutaan ns. liittomuotoisesta TKHJ:stä ( federated DBMS ) • TKHJ:n kustannukset • datan saantipolkujen tyypit • yleiskäyttöinen vai erikoiskäyttöön tarkoitettu • erikoiskäyttöön tarkoitettua TKHJ:tä ei voida helposti muuntaa muuhun tarkoitukseen käytettäväksi ( esim. lentoyhtiöiden paikanvarausjärjestelmät ) • lyhyt vasteaika tärkeä kriteeri TKHJ:n käyttökelpoisuuden kannalta • Relaatiotietokannat perustuvat kokonaisuuksien esittämiseen taulumuodossa • Oliotietokannat perustuvat objekteihin, jotka edustavat jotain luokkaa, jonka edustajilla on voimassa tietyt ominaisuudet.   • Olio-relaatiotietokannat ovat relaatiomallin laajennus, joka hyödyntää oliotietomallin piirteitä ( mm. objektien tallentaminen dataan ). • Verkkomallissa data esitetään joukkotyyppisenä linkitettyjen tietueiden avulla • riippuvuussuhde 1:N ( yksi tietue liittyy N:ään tietueeseen ) • Hierarkkisessa mallissa data esitetään hierarkkisena puurakenteena. • jokainen hierarkiataso kuvaa toisiinsa liittyviä tietueita • ei standardoitua kyselykieltä • käsitellään yleensä tietue kerrallaan  

36. 3. Tiedon mallintaminen ER-mallin avulla • Tietokannan käyttöönottovaihetta edeltävät aina suunnittelu, toteutus ja sovellusohjelmien testaus. • Tietokannan suunnitteluvaihe muistuttaa jonkin verran yleistä ohjelmien suunnittelua. • Käsitteellinen mallinnus on tärkeää tietokantasovellusten suunnittelussa. • ER ( Entity Relationship ) tarkoittaa kokonaisuuksien välisiä suhteita. • ER-malli on korkean tason käsitemalli, jota käytetään yleisesti hyväksi tietokantaa suunniteltaessa.

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

38. Eteneminen alkutekijöistä kohti valmista tietokantaa • Tarpeiden kartoittaminen ja analysointi • selvitetään käyttäjiltä kysymällä, mitä kaikkia tietoja tietokannassa tulisi olla saatavilla • tarpeelliset tiedot ja toiminnot pitäisi selvittää niin tarkoin kuin mahdollista • käytetään apuna tietovuokaavioita yms. suunnittelua helpottavia menetelmiä ----> tavoitteena muodostaa kokonaiskäsitys tiedon ja toimintojen tarpeesta tietokannassa • Muodostetaan tietokannan käsitekaava käyttämällä korkean tason tietomallia • tarvittavat kokonaisuudet, suhteet ja säännöt määritellään • fyysiseen toteutukseen ei oteta tässä vaiheessa kantaa • selvitetään, että kaikkien osapuolten tietotarpeet esiintyvät käsitekaavassa ja etteivät eri käyttäjäryhmien asettamat vaatimukset ole ristiriitaisia keskenään • jos käsitekaava osoittautuu virheelliseksi tai puutteelliseksi, tehdään tarvittavat muutokset • Rinnakkaisesti tai hieman jälkeenpäin voidaan käsitekaavaan perustuen yrittää hahmottaa toiminnallisessa eli funktionaalisessa analyysissä todetut käyttäjien tarvitsemat operaatiot. • Jos käsitekaava on riittämätön toimintojen mallintamiseen, sitä voidaan uusia. • Kun kaikki tahot ovat tyytyväisiä tietokannan määriteltyihin ominaisuuksiin, on aika aloittaa sen käytännön toteuttaminen ( implementointi ). Tätä vaihetta kutsutaan tietokannan loogiseksi suunnitteluksi. Siinä muunnetaan korkean tason tietomallin mukainen kuvaus TKHJ:lle sopivaan muotoon ( esimerkiksi relaatiomallin mukaiseksi ).

39. 3.2. Esimerkki tietokantasovelluksesta • Loogisen kaavan valmistuttua voidaan aloittaa kyseiseen kaavaan perustuva sovellusohjelmien suunnittelu sekä tietokannan fyysisen tallennusrakenteen suunnittelu, jonka tuloksena saadaan tietokannan sisäinen kaava. • Sisäiseen kaavaan perustuen voidaan optimoida tietokantaa hyödyntävät valmiit sovellusohjelmat. • Sovellusohjelmien valmistuttua tietokannan pitäisi nyt ihannetilanteessa vastata täysin sen kaikkien käyttäjätahojen sille asettamia odotuksia. • Tavoitteena on rakentaa toimiva tietokantasovellus yhtä yritystä varten. Yritys edustaa tapauksessamme siten sovelluksen kohteena olevaa "pienoismaailmaa". Oletetaan, että seuraavat tiedot on saatu selville kartoitettaessa tietokannalle asetettavia vaatimuksia: • oYritys on jakautunut osastoihin. Kullakin osastolla on yksikäsitteinen nimi ja yksi johtaja. Johtajan tehtävässään aloittamispäivämäärä kirjataan muistiin. Yksittäisellä osastolla voi olla toimintaa usealla paikkakunnalla. • o Osasto kontrolloi projekteja, joilla kullakin on yksikäsitteinen nimi ja koodinumero sekä yksi sijaintipaikka. • o Jokaisesta yrityksen työntekijästä kirjataan nimi, henkilötunnus, osoite, • kuukausipalkka, sukupuoli ja syntymäaika. Lisäksi oletetaan, että kukin työntekijä on kirjoilla tarkalleen yhdellä osastolla, mutta hän voi työskennellä usean eri osaston kontrolloimassa projektissa. Lisäksi halutaan pitää yllä tietoa työntekijän viikoittaisista työtunneista kussakin eri projektissa, joissa hän työskentelee. Myös tieto kunkin työntekijän lähimmästä esimiehestä • pitää olla saatavilla.

40. 3.3. Entiteettityypit, entiteettijoukot, attribuutit ja avaimet • Vielä halutaan pitää kirjaa kunkin työntekijän mahdollisista perheenjäsenistä. Heistä on tiedettävä etunimi, sukupuoli, syntymäaika sekä asema perheessä työntekijään nähden. • Kirjan esimerkissä 3.2. on nähtävillä tietokannan suunnittelutyön lopputuloksena syntynyt ER-mallin mukainen käsitekaava. • Jatkossa tullaan käymään läpi vaiheet, miten kyseiseen kaavaan on päädytty. Samoin esitellään kaavassa esiintyvien merkintöjen tulkinta. 3.3.1. Entiteetit ja attribuutit • ER-malli perustuu datan kuvaamiseen entiteettien, attribuuttien ja liittymien eli suhteiden avulla. • Entiteetti on jokin reaalimaailmassa esiintyvä itsenäinen käsite, joka voi olla joko fyysinen tai käsitteellinen. • esimerkiksi henkilö, auto, työntekijä jne. ovat fyysisiä entiteettejä • vastaavasti yliopiston kurssi, luennointikerta jne. ovat käsitteellisiä entiteettejä • entiteettiä relaatiotietokannassa edustaa yksittäinen taulu ( esimerkiksi opiskelijan ja kurssin perustietotaulu jne. ), ja entiteetin nimike pyrkii kuvaamaan sitä osuvasti.

41. Entiteetille tyypillisiä ominaisuuksia kutsutaan attribuuteiksi. Attribuutit ovat siten entiteettiin kuuluvia tietokenttiä. • Esimerkiksi nimi, ikä, osoite ja puhelinnumero ovat tyypillisiä yksittäiseen työntekijään liittyviä ominaisuuksia. • Attribuutti voi olla joko yksinkertainen tai koottu: • yksinkertaisen attribuutin arvo on selkeästi jakamaton ( esimerkiksi henkilön pituus ) • koottua attribuuttia voidaan käsitellä kulloisenkin tarpeen mukaisesti joko kokonaisena tai ositettuna ( esimerkiksi henkilön nimen voidaan olettaa koostuvan etunimestä, toisen nimen alkukirjaimesta ja sukunimestä ) • Lisäksi attribuutti voi olla joko yksi- tai moniarvoinen • yksiarvoinen attribuutti tarkoittaa ominaisuutta, joka ei voi saada kuin yhden arvon kerrallaan ( esimerkiksi ikä ) • moniarvoinen attribuutti voi saada samanaikaisesti useita eri arvoja ( esimerkiksi henkilön suorittamat tutkinnot ) • Attribuutti voi olla joko tallennettu tai johdettu. • Tallennetun attribuutin arvo ei ole pääteltävissä muiden attribuuttien avulla ( esimerkiksi henkilön kotiosoite ) • Johdetun attribuutin arvo on pääteltävissä tai laskettavissa tallennettujen attribuuttien perusteella ( esimerkiksi ikä voidaan laskea, jos tiedetään nykyinen päivämäärä ja henkilön syntymäaika ) • Johdettu attribuutti voi liittyä myös koko entiteetin ominaisuuteen eikä välttämättä erikseen jokaiseen tietueeseen ( esimerkiksi opiskelijoiden kokonaismäärä saadaan laskemalla tietueiden lukumäärä opiskelijataulusta ) • Toisinaan myös puuttuvat arvot attribuutille ovat sallittuja, kunhan kyseessä ei ole ns. avainattribuutti. • puuttuvan arvon tulkinta on joko 'ei ole olemassa/ laskettavissa' ( esimerkiksi henkilön esimies, jos hän sattuu olemaan yrityksen toimitusjohtaja ) tai 'tuntematon' ( ei ole jostain syystä tallennettu ) • ryhmä 'tuntematon' jakaantuu vielä kahteen alaryhmään:

42. 3.3.2. Entiteettityypit ja -joukot, avaimet ja arvojoukot • "tieto varmasti olemassa, muttei tiedossa" ( esimerkiksi henkilön pituus ja paino ) • "ei tietoa, onko olemassa" ( esimerkiksi puhelinnumero - voi olla salainen ) • kompleksiset attribuutit • yhdistelmä koottuja ja moniarvoisia attribuutteja (esimerkiksi tilanne, jossa henkilöllä on useampia asuntoja, joihin voi olla lisäksi useita puhelinnumeroita). • Entiteettityyppi määrittelee kokoelman entiteetin edustajia, joilla on samat attribuutit ( esimerkiksi tyyppi, joka kuvaa opiskelijan perustietoja ). • Entiteettijoukko kuvaa tietyn entiteettityypin kaikkia edustajia ( esimerkiksi kaikkia yksittäisiä opiskelijoita esittäviä tietueita ). • Usein termiä entiteetti käytetään kummassakin edellä mainitussa merkityksessä, eli tarkoittamaan sekä kokonaisuutta kuvaavia ominaisuuksia että sen yksittäistä edustajaa. • Entiteettityyppiä kuvaa ER-kaaviossa yksinkertaisilla viivoilla merkitty suorakulmio, jonka sisällä on entiteetin nimi, joka merkitään pelkkiä isoja kirjaimia käyttämällä. • Sellaista attribuuttia tai niiden yhdistelmää, joka yksikäsitteisesti identifioi entiteettijoukon yksittäisen jäsenen ( tietueen ), kutsutaan entiteettityypin avaimeksi.

43. Avainattribuutti on usein yksittäinen attribuutti ( esimerkiksi henkilötunnus), mutta yksikäsitteisyyden saavuttaminen saattaa vaatia useamman attribuutin yhdistelmän valitsemista avaimeksi ( esimerkki: projektit, joissa henkilö työskentelee ). • Entiteettijoukon nykytilassa vallitseva yksikäsitteisyys on attribuutin avaimeksi kelpaamisen kannalta välttämätön, muttei riittävä ehto ( kts. yliopistotietokannan opiskelijoiden perustiedot ). Pitää kiinnittää huomiota tietokannan määrittelyssä asetettuihin ehtoihin sen rakenteesta. • Avaimeksi voi kelvata useampiakin kuin yksi attribuutti tai niiden yhdistelmä ( esimerkiksi auton rekisteri- tai valmistenumero ). • Avaimen on oltava minimaalinen. Tämä tarkoittaa, ettei avaimeen pidä ottaa mukaan muita kuin sellaisia attribuutteja, jotka ovat välttämättömiä yksikäsitteisyyden saavuttamiseksi. • Entiteettityyppiä, jolla ei ole lainkaan omaa avainattribuuttia, kutsutaan heikoksi entiteetiksi. Entiteettityypin avaimeen kuuluvat attribuutit merkitään ER-kaavioon alleviivattuina. • Jokaiseen attribuuttiin liittyy ns. arvojoukko, joka määrää, millaisia arvoja sillä voi esiintyä ( esimerkiksi rajoitettu kokonaislukualue, enintään tietyn mittainen merkkijono jne. ). • Arvojoukko on matemaattisesti ymmärrettävissä kuvauksena entiteettityypiltä arvojoukon potenssijoukkoon ( kaikkien mahdollisten alijoukkojen joukkoon ). • puuttuvaa arvoa edustaa tyhjä joukko • yksiarvoista attribuuttia edustaa attribuutin laillisten arvojen joukko • moniarvoista attribuuttia edustavat kaikki yhdistelmät, joita esiintyy entiteettijoukossa • yhdistettyä attribuuttia edustaa sen kaikkien osakomponenttien välinen karteesinen tulo

44. 3.3.3. Yrityksen tietokannan alustava käsitteellinen suunnittelu • Lähdetään rakentamaan ER-kaaviota kappaleessa 3.2. esiteltyjen vaatimusten mukaiselle tietokannalle. • Osasto sisältää attribuutit Nimi, Numero, Toimipisteet, Johtaja ja JohtajanAloituspäivä. Koska sekä Nimi että Numero vaadittiin yksikäsitteisiksi, kumpikin näistä kelpaa erilliseksi avaimeksi. • Projektiin tarvitaan attribuutit Nimi, Numero, Sijaintipaikka ja KontrolloivaOsasto. Sekä Nimi että Numero kelpaavat avaimeksi. • Työntekijästä tallennetaan attribuutit Nimi, Hetu, Sukupuoli, Osoite, Kuukausipalkka, Syntymäaika, Osasto ja Esimies. Nimi ja Osoite voitaisiin esittää sekä yksinkertaisina että koostettuina attribuutteina: • ---> kysyttävä lisätietoa käyttäjiltä. • Perheenjäsenistä tarvitaan attribuuteiksi Työntekijä, Perheenjäsenen nimi, Sukupuoli, Syntymäaika ja Perhesuhde työntekijään. • Edelleen pitäisi pystyä esittämään, että työntekijä voi toimia useassa eri projektissa, ja myös tehdyt työtunnit pitäisi kirjata. • ---> olisi lisättävä työntekijä-entiteettityyppiin moniarvoinen koottu attribuutti Työskentelee( Projekti, Tunnit ) tai projekti-entiteettityyppiin moniarvoinen attribuutti Työsuoritukset( Työntekijä, Tunnit ). • ---> kysytään taas lisää käyttäjiltä, jotka kertovat haluavansa mieluummin ensimmäisen vaihtoehdon.

45. 3.4. Relaatiotyypit ja -joukot, roolit ja rakenteelliset rajoitukset • Tällä kurssilla liittymä  suhde  relaatio. • Edellisissä määrityksissä on useita implisiittisiä riippuvuuksia, eli tietyn entiteettityypin • attribuutti viittaa selkeästi johonkin toiseen entiteettiin ( esimerkiksi Osaston johtaja --> Työntekijä, Projektia kontrolloiva osasto --> Osaston tiedot, Työntekijän esimies --> Työntekijä, Työntekijän osasto --> Osaston tiedot). • Implisiittiset riippuvuudet kannattaa esitellä pikemminkin suhteina kuin attribuutteina, vaikka aluksi niiden esittely attribuutteina onkin mahdollista ----> käsitekaava tarkentuu asteittain. 3.4.1. Liittymien tyypit, joukot ja esiintymät • Relaatioon osallistuu vähintään kaksi entiteettityyppiä. Kahden entiteettityypin välistä relaatiota sanotaan binääriseksi, kolmen ternääriseksi jne. Sama entiteettityyppi voi osallistua relaatioon useammin kuin yhden kerran. • Suhteen esiintymälläri tarkoitetaan kokoelmaa ( e1, e2, e3, ..., en ), jossa ei:t ovat siihen osallistuvien entiteettityyppien E1, E2, ..., En yksittäisiä esiintymiä. Jos kyseessä on binäärinen relaatio, n = 2.

46. 3.4.3. Rajoitukset suhteiden tyypeille • Jokainen entiteettityypeistä E1, E2, ..., En osallistuu niiden välille määriteltyyn relaatioon. • Esimerkki binäärisestä relaatiosta: työntekijän työskenteleminen osastolla --> työntekijäentiteettiä edustava esiintymä liitetään osastoa esittävän esiintymän kanssa ( kts. kirjan esimerkki 3.9. ) • Esimerkki ternäärisestä relaatiosta: tavaran, sen toimittajan ja toimituksen kohteena olevan projektin liittäminen toisiinsa ( kts. kirjan esimerkki 3.10. ) • Relaatiota voidaan kuvailla attribuuttien avulla. Esimerkiksi työntekijän työskentelyä jonkin osaston laskuun voidaan kuvata työntekijän mahdollisena yksiarvoisena attribuuttina Osasto. Sama toimii myös toisin päin: yhtäläisesti kutakin osastoa kohti voisi olla määriteltynä moniarvoinen attribuutti nimeltä OsastonTyöntekijät, joka olisi luettelo työntekijöistä, jotka ovat töissä tietyllä osastolla. • Roolinimellä tarkoitetaan ominaisuutta, jollaisessa entiteettityyppi osallistuu liittymään ( esimerkiksi relaatio työntekijän työskenteleminen osastolla ). • Roolinimet ovat melko selkeät, mikäli sama entiteettityyppi ei osallistu siihen useita kertoja. • Muussa tapauksessa on kyseessä ns. rekursiivinen relaatio, jossa sama entiteettityyppi osallistuu siihen kahdessa ( tai useammassa ) eri roolissa ( esimerkiksi työntekijöiden esimiehet ). • Relaatioon osallistuvien entiteetin esiintymien kombinaatioiden lukumäärää voidaan tarpeen mukaan rajoittaa ( esimerkiksi työntekijä voi olla kirjoilla vain yhdellä osastolla, jokaisella osastolla on vain yksi johtaja jne. ). • Kaksi tyypillisintä suhteen tyypin rajoitetta ovat ns. lukumääräsuhde ja osallistumiskriteeri.

47. Binäärisen relaation lukumääräsuhde määrää, monenko esiintymän kanssa entiteetti voi osallistua relaation. Esimerkki: osasto-työntekijä -relaation lukumääräsuhde on 1:N. Tämä tarkoittaa sitä, että yhdellä osastolla voi olla kirjoilla monta työntekijää, mutta yksi työntekijä voi edustaa vain yhtä osastoa. • Muut lukumääräsuhteet ovat 1:1, N:1 ja M:N. • Esimerkki 1:1 -lukumääräsuhteesta: osaston johtaminen. Jokaisella osastolla voi olla vain yksi johtaja, ja jokainen henkilö voi johtaa vain yhtä osastoa. • Esimerkki M:N -lukumääräsuhteesta: työskenteleminen eri projekteissa. Jokainen työntekijä voi toimia useassa eri projektissa, ja yhdessä projektissa voi olla useita työntekijöitä. • Relaation osallistumisrajoite ( participation constraint ) ilmaisee, onko yksittäisen entiteettityypin esiintymän olemassaolo riippuvainen suhteesta toisen entiteettityypin esiintymään ( Esimerkki: voiko yrityksessä olla työntekijää, joka ei ole kirjoilla millään osastolla ). • Osallistumisrajoite voi olla osittainen tai täydellinen. • Relaation osallistumisvaatimuksen ollessa täydellinen pitää tietyn entiteetin kaikkien edustajien osallistua kyseiseen relaatioon. Täydellistä osallistumisrajoitetta kutsutaan myös olemassaoloriippuvuudeksi ( existence dependency ). • Esimerkiksi täydellisestä osallistumisesta voitaisiin mainita suhde kirjoilla_osastolla( työntekijä ---> osasto ): jokaisen työntekijän pitää kuulua johonkin osastoon. • Jos puolestaan osallistumisrajoite on osittainen, ei kaikkien relaation muodostavan entiteettityypin edustajien tarvitse osallistua relaatioon.

48. 3.4.4. Liittymätyypin attribuutit • Esimerkki osittaisesta osallistumisesta: osaston johtaminen, eli johtaa( työntekijä ---> osasto ): jokaisen työntekijän ei tarvitse johtaa jotakin osastoa. • Kannattaa huomioida, että sama osallistumisrajoite ei välttämättä ole voimassa relaation käänteisrelaatiossa ( Esimerkki: johtaja( osasto ---> työntekijä ): jokaisella osastolla pitää olla johtaja, vaikkei kaikkien työntekijöiden tarvitsekaan toimia jonkin osaston johtajana )! • Täydellinen osallistumisrajoite merkitään ER-kaavioon kaksinkertaisena ja osittainen osallistumisrajoite yksinkertaisena viivana ( kts. kirjan kuva 3.2. ). • Paitsi entiteettityypeille, myös liittymille voidaan määritellä attribuutteja. • Toisinaan attribuutti liittyy luonnollisemmin kahden ( tai useamman ) entiteettityypin väliseen suhteeseen kuin jompaankumpaan ( johonkin ) yksittäisistä entiteettityypeistä. Toistaiseksi keskitytään jatkossa vain binäärisiin relaatioihin. • Esimerkki suhteen attribuutista: työntekijän yhdessä projektissa tekemät työtunnit ( kuvaa paremmin henkilön ja projektin välistä yhteyttä kuin itse työntekijää tai projektia sinänsä ). • Mikäli relaation lukumääräsuhde on 1:1, voidaan suhteen attribuutti esittää haluttaessa kumman tahansa entiteettityypin attribuuttina. Esimerkki: osaston johtajan aloittamispäivämäärä voitaisiin yhtäläisesti sijoittaa osaston tai työntekijän attribuutiksi, mutta käsitteellisesti se kuitenkin liittyy selvästi itse johtamisrelaatioon johtaa( henkilö ---> osasto ).

49. 3.5. Heikot entiteettityypit • Jos lukumääräsuhde on 1:N, voidaan suhteeseen liittyvä attribuutti sijoittaa luontevasti vain relaation N-puolella olevaan entiteettiin. Esimerkki: jos työntekijän työsuhteen alkamispäivä osastolla haluttaisiin kirjata, se voitaisiin viedä haluttaessa työntekijän perustietoihin yksinkertaisena attribuuttina. Sen sijaan osaston attribuutiksi se sopii erittäin huonosti, sillä siitä olisi tehtävä moniarvoinen koosteinen attribuutti 'Työntekijät+Aloituspäivät', jossa selvästi kaksi eri attribuuttia jouduttaisiin kombinoimaan yhdeksi. • Mikäli relaation lukumääräsuhde on M:N, eivät suhteen attribuutit enää mielekkäästi liity yksistään jompaankumpaan entiteettiin. Tällöin ne pitää esittää suhteen attribuutteina (esimerkiksi työntekijän tekemät työtunnit eri projekteissa). Vaihtoehtoinen esittely työntekijän tai projektin moniarvoisena attribuuttina olisi paljon vaikeaselkoisempi. • Entiteettityyppi, jolla ei ole omia avainattribuutteja, on nimeltään heikkoentiteetti( tyyppi ). • Heikon entiteettityypin tietueet on tunnistettavissa ainoastaan niiden tunniste- eli omistajatyypin kautta. Heikon entiteettityypin osallistumisrajoite on aina täydellinen, eli sen esiintymien olemassaolo on täysin riippuvaa omistajatyypistä. Esimerkki: työntekijän perheenjäsenet ovat tunnistettavissa ainoastaan työntekijän henkilötunnuksen kautta. • On kuitenkin mahdollista, että olemassaoloriippuvuutta esiintyy myös muillakin kuin heikoilla entiteeteillä. Tällöin entiteetillä on olemassa jokin oma avainattribuutti, mutta ilman yhteyttä tunnistetyyppinsä edustajaan entiteetin edustajilla ei ole mielekästä asemaa tietokannassa. Esimerkki: ajokorttitiedot ( ajokorteilla on olemassa numero, joka identifioi yksittäisesti ajokortin — eli kyseessä ei siten ole heikko entiteetti — mutta tiedot ovat melko lailla hyödyttömiä ilman yhteyttä ajokortin haltijaan ).

50. Heikolla entiteettityypillä on yleensä osittaisavain, jonka turvin tyypin esiintymät ovat tunnistettavissa, kun tietueiden omistaja tiedetään. Osittaisavain voi huonossa tapauksessa muodostua kaikista heikon entiteettityypin attribuuttien yhdistelmästä. Esimerkki: tarkastellaan työntekijän perheenjäseniä. Jos voidaan olettaa, ettei samalla työntekijällä ole kahta etunimeltään saman nimistä perheenjäsentä, perheenjäsenen etunimi on tällöin osittaisavain. Osittaisavaimeen kuuluvat attribuutit alleviivataan katko- tai pisteviivalla. • Heikot entiteetit merkitään ER-kaavioon kahdella viivalla rajatuin suorakulmioin. • Samoin relaatiot, joihin heikko entiteetti osallistuu, merkitään kaksin reunaviivoin piirretyin ruuduin. • Heikon entiteetin perustaminen voidaan haluttaessa kiertää lisäämällä sen attribuutit omistajatyyppinsä moniarvoiseksi koosteiseksi attribuutiksi. Esimerkki: työntekijän perheenjäseniä kuvaavat tiedot voisivat yhtenä attribuuttina työntekijän perustiedoissa { Perheenjäsenet( Nimi, Sukupuoli, Syntymäaika, Perhesuhde ) }. • On kuitenkin suositeltavaa käyttää heikkoa entiteettityyppiä moniarvoisen attribuutin asemesta, jos • heikkoon entiteettiin kuuluvia attribuutteja on 'tarpeeksi monta', jotta käsittely moniarvoisena attribuuttina tulisi hankalaksi • mikäli heikko entiteettityyppi muodostaa relaatioita myös jonkin muun kuin omistajaentiteettinsä kanssa