HARJOITUS 2. Tehtävä 1 Alla on esitetty relaatiotietokannan taulujen rakenne. Mitä ongelmia tähän tietokantaan liittyy jos se yritettäisiin ottaa käyttöön sellaisenaan? Korjaa puutteet ja esitä toimiva ratkaisu. Osa tietokannasta Kalankasvattamot ja mittaukset Taulujen väliset yhteydet on piirretty näkyviin helpottamaan suhteiden hahmottamista. Ilman niitäkin suhteet pitäisi voida nähdä varsin helposti, mutta tässä tapauksessa näin ei ole, sillä tietokannan rakenne ei ole aivan kelvollinen. Tietokannassa on tietoa kasvattaja tiloista, omistajista, altaista, lajikkeista ja altaisiin liittyvistä mittauksista, esim. kalataudit, veden laatu jne. sekä mittauspalvelujen tarjoajista yms. Kasvattamot ja mittaukset Esimerkkivastaus Tietokannassa esiintyviä puutteita ja ongelmia: Pääavaimet: Yritys taulun Ytunnus ei välttämättä ole paras mahdollinen pääavain, sillä jos kyseessä on yrityksen y-tynnus, on sen käyttö hankalaa Mittaaja taulussa, johon se tulisi yhdistää. Parempi esim YritysID ja jos yrityksen y-tunnusta todella tarvitaan, lisätään se tauluun tavalliseksi attribuutiksi.
Huono pääavain tauluissa Mittaaja, Kasvattaja ja Tila. Nimi tavallisena tekstinä ei yleensä ole hyvä idea avaimeksi sillä usein on mahdollista, edes jossain määrin, että myöhemmin törmätään toiseen saman nimiseen henkilöön jota ei voitaisikaan lisätä sellaisenaan enää tauluun. Riippuen miten tilan nimi tietokannassa ymmärretään voi olla että toista saman nimistä ei voi tulla edes teoriassa vastaan, mutta jokin indeksi olisi tässäkin tapauksessa parempi. Näin ollen tietokannan rakenne ei rajoita sen toimintaa tulevaisuudessakaan. Allas taulun yhdistetty pääavain on turha ja jopa huono: Sitä ei tarvita. Paremman rakenteen saisi käyttämällä AllasID avainta ja muuttamalla Tila ja Numero attribuutit tavallisiksi tietueen tiedoiksi niin että Tila on edelleen vierasavain Tila taulun pääavaimeen joka jo yllä korjattiin. Nyt nähtäisiin esimerkiksi Altaan 15 kuuluvan Tilalle 4 ja olevan siellä allas numero 3. Tila taulusta taas saadaan tieto mikä onkaan Tila numero 4 jne. Attribuutit: Puhelinnumerot olisi hyvä tallentaa tekstimuotoisina. Esimerkiksi 040-123456 ei ole luku. 0405078572 on lukuarvo, mutta riippuen käytettävästä järjestelmästä saattaa siitä kadota automaattisesti nolla edestä lukua tallennettaessa, aivan kuten Excelissä (mm. Access), sillä luvussa ei tarvita ylimääräistä nollaa edessä. Tietokannan vieras käyttäjä ei välttämättä tiedä missä muodossa numero juuri tällä kertaa halutaan, ja saattaa siis yrittää tallentaa esim. väliviivan puhelinnumeroon. Mittaaja taulussa lienee Osoite parempi nimetä Postiosoitteeksi, mikä sen tarkoitus lieneekin. Yritys taulusta lienee unohtunut ensisijainen s-postiosoite joka liittyy juuri tietokannan käyttäjän tarpeisiin. Vierasavaimet: Avaimia korjattiin jo yllä, mutta hyvä tapa olisi käyttää vierasavaimen nimenä samaa nimeä kuin siihen liittyvä pääavainkin on. Nyt tietokannan rakenteen hahmottaminen on hankalampaa ilman näkyviä linkkejä johtuen täysin satunnaisista vierasavain-pääavain nimistä. Yllä esitetyt pääavainten korjaukset myös selkiyttävät rakennetta. Tiedon toistaminen Tila taulussa on paljon toistettua tietoa. Omistaja ja Lajike attribuutit eivät kuulu enää tähän tauluun sillä tieto on jo tauluissa Kasvattaja ja Allas. Lisäksi Omistaja oli vielä nimetty eriävästi kasvattajasta, aivan turhaan. Olisi myös mietittävä onko kasvattajalla ja tilalla todellakin eri osoite ja puhelinnumero? Miten ne tällöin tallennetaan tietokantaan? Lisäksi voitaisiin vielä miettiä onko altaiden lukumäärä tieto oikeasti tarpeellinen. Jos ei, niin samaan tietoon päästäisiin kyselyn kautta joka laskisi kyseisen tilan altaiden lukumäärän. Nyt jos tilalle lisätään allas, on päivitys tehtävä kahteen paikkaan, mikä ei kuulosta relaatiomaiselta ratkaisulta. Alla on esitetty yksi ehdotus parannetuksi versioksi.
Kasvattamot ja mittaukset, ehdotus korjatuksi versioksi.
Tehtävä 2 Mitä vaiheita sisältyy tietokannan suunnitteluprosessiin? Milloin käytetään käsiteanalyysia ja mikä rooli normalisoinnilla on suunnittelun kannalta? Suunnittelusta Tietokantojen suunnittelu voidaan karkeasti jakaa kahteen osaan, kuten mikä tahansa systeemityö: varsinainen suunnittelu ja kehitys, sekä käyttöönoton jälkeinen ylläpitotyö ja siihen liittyvät tekijät. Toisaalta itse suunnitteluvaiheesta voidaan vielä erottaa analyysivaihe, johon mm. käsiteanalyysi kuuluu. Suunnittelu aloitetaan analyysivaiheella. Tämän kurssin kannalta olennainen analyysin osa on käsiteanalyysi, mutta siihen sisältyy paljon muutakin. Käsiteanalyysin rinnalla suoritetaan usein toimintoanalyysi ja tietotarveanalyysi. Vaihe voidaan päättää normaalitarkistuksilla, eli normalisoinnilla. Analyysivaiheen jälkeen on käytettävissä tietokannan käsitekaavio, eli looginen kuvaus mitä tietokannassa on sellaisessa muodossa että se on mahdollisimman tehokas (usein varmennettu normalisoinnilla) ja tiedon päällekkäisyyttä ei esiinny, mutta kaikki tarvittava kohdealueesta on mallinnettu. Käsitekaavio on vielä järjestelmäriippumaton. Suunnitteluvaiheen aikana käsitekaaviosta muotoutuu käytettävän järjestelmän mukainen malli tietokannasta. Relaatiotietokannassa käsitekaaviosta johdetaan taulujen rakenne, eli attribuutit, avaimet, tietotyypit jne., sekä vastaavasti taulujen väliset suhteet. Toisin sanoen käsitekaavion yksilötyypit, ominaisuustyypit ja yhteystyypit muotoutuvat relaatiomallin tauluiksi, attribuuteiksi ja avaintiedoiksi. Yhtälailla siitä voitaisiin johtaa jonkin muunkin tietomallin mukainen tietokanta, olkoon se vaikka verkkomallin tai hierarkkisen mallin mukainen. Suunnitteluvaiheen jälkeen, kun käytössä on relaatiomallin mukainen esitys tietokannasta, on myös määritetty käytettävät eheyssäännöt ja tehty pientä hienosäätöä tietokannan rakenteeseen. Joitain muitakin operaatiota yleensä suoritetaan mutta tämän kurssin puitteissa keskitytään itse suunnitteluun, käsitekaavion laadintaan ja kohdealueen mallintamiseen ja sen toteuttamiseksi valmiiksi pieneksi tietokannaksi. Normalisoinnista Normalisointi on alun perin relaatiomallin mukainen suunnittelumenetelmä, jolla pyritään samaan lopputulokseen kuin käsiteanalyysinkin avulla: mahdollisimman hyvään (relaatiomallin) mukaiseen tietokantaan. Normalisointi voidaan siis nähdä käsiteanalyysiin verrattavana vaihtoehtoisena menetelmänä, mutta sitä voidaan käyttää myös täydentämään käsiteanalyysia, kuten aiemmin mainittiin. Tällöin puhutaan usein normalisointi tarkistuksesta. Normalisoinnin tuloksena saadaan malli tauluista ja niiden attribuuteista, sekä tieto avaimista. Tuloksena on siis ehdotelma tietokannan rakenteesta, joka voidaan taata olevan tiedon esityksen kannalta optimaalinen siten että tietoa ei toisteta, taulut esittävät vain kyseiselle taululle kuuluvaa tietoa ja toisaalta taulut ovat myös mahdollisimman pieniä ja yksinkertaisia. Lopputulos on käytännössä sama kuin mihin päädyttäisiin käsiteanalyysinkin kautta, mutta lähestymistapa ongelmaan vain on erilainen. Käsitekaaviolle voidaan suorittaa, kuten jo mainittiin, ns. normaali- tai normalisointi tarkistus. Tällä tarkoitetaan että valmiille käsitekaaviolle, tai oikeastaan sen yksilötyypeille, suoritetaan normalisointi. Jos rakenne on jo hyvä, ei normalisointi aiheuta enää muutoksia yksilötyypeissä. Tämä on normaali tilanne, ja hyvin tehty käsiteanalyysi johtaa normalisoituun malliin, mutta asia voidaan haluta varmistaa kokeilemalla normalisointia jokaiseen yksilötyyppiin. Jos muutoksia kuitenkin tulee, korjataan käsitekaaviota sen mukaan ja voidaan olla varmoja hyvästä lopputuloksesta. Normalisointia voidaan
siis käyttää varmistamaan että käsiteanalyysin tulos oli hyvä. Lisää normalisoinnista ja esimerkki tehtävässä x (Normalisointi harjoitus) Käsiteanalyysin eteneminen Käsiteanalyysi suoritetaan tavallisesti seuraavassa järjestyksessä: 1. Yksilötyyppien määritys 2. Yhteystyyppien määritys ja avainten lisääminen 3. Avainten ja yhteystyyppien eheyssäännöt, jos tarpeellisia. 4. Ominaisuustyyppien määritys (ei-avain tyypit) 5. Mahdolliset muut eheyssäännöt 6. Mallin tarkistus yleisesti ja esim. normalisointitarkistus.
Eheyssäännöistä Eheyssäännöt pyrkivät varmistamaan tietokannan ongelmattoman toiminnan ja relaatiomallin mukaisen perustan. Tietokannan rakenteeseen liittyviä eheyssääntöjä on jo käsitelty, esimerkiksi avaimiin liittyvät säännöt, mutta on myös semanttisia, käyttäjän määrittämiä eheyssääntöjä, joihin otetaan kantaa suunnitteluvaiheessa jotka voivat liittyä puhtaasti tiedon sisältöön ja merkitykseen tai asettaa rajoituksia esimerkiksi tiedon poistamiseen ja lisäämiseen. Suunnittelija voi päättää että tietyn tyyppistä dataa ei voi syöttää kuin tietynlaisessa muodossa, tai voidaan määrätä että tauluun X kuuluvaa tietuetta ei voi poistaa jos siihen liittyvä avaintietue taulussa Y on yhä olemassa, tai että henkilön tietoja ei voi syöttää ilman etu ja sukunimeä, mutta sähköpostiosoite ei ole välttämätön jne.
Tehtävä 3 Käsitemallin voidaan katsoa koostuvan yksilötyypeistä (olio), yhteystyypeistä ja ominaisuustyypeistä. Mitä näillä tarkoitetaan? Miten ne liittyvät valmiiseen relaatiotietokantaan? Miten käsitemallin osat löydetään? Yksilötyyppi Yksilö tai yksilötyyppi on kohdealueella oleva mallinnettavan tietokannan kannalta jollakin tavalla tarpeellinen olio, todellinen tai abstrakti. Tyypillinen olio voisi olla vaikkapa opiskelija, työntekijä, tilaus, koulu, projekti, asiakas jne. Yksilötyyppi on siis eräänlainen olioluokka. Kaikki vastaavat yksilöt kuuluvat tähän luokkaan, mikä johtaa siihen että valmiissa tietokannassa yksilötyypeistä tulee relaatiotietokannan tauluja ja tauluissahan on yksilöitä, tietueita, jotka ovat ominaisuuksiltaan (attribuutit) samanlaisia. Yksilötyypit löytyvät varsin helposti kohdealueelta. Ainoa ongelma voi olla jossakin tilanteessa päättää tulisiko kyseessä olla uusi yksilötyyppi vai ominaisuustyyppi jo olemassa olevaan yksilöön. Alityypeiksi kutsutaan yksilötyyppiä joka perii ominaisuutensa toiselta yksilöltä. Alityypit ovat isäntä yksilön eri ilmentymiä jotka halutaan mallintaa käsitekaaviossa erikseen. Esimerkiksi Asiakas yksilöllä voisi olla alityypit Henkilö ja Yritys, sillä asiakas voi tässä tapauksessa olla yksityis- tai yritysasiakas. Kuitenkin molemmilla asiakas yksilöillä on samat attribuutit ja tietokannassa voi olla yksi taulu Asiakas jolla saattaa olla attribuutti tyyppi, joka kertoo onko asiakas yksityinen vai yritys. Jos tällä on tietokannassa merkitystä, ilmoitetaan siitä myös käsitekaaviossa alityypeillä. Voi myös olla että jollakin alityypeistä on yhteys yksilöön X, mutta muilla alityypeillä ei. Yksilötyyppi Asiakas ja alityypit, yksi merkintätapa Yhteystyypit Kahden yksilöntyypin välistä riippuvuutta kuvataan yhteystyypillä. Yhteystyyppi vastaa siten relaatiotietokannan taulujen välisiä yhteyksiä tai linkkejä, jotka esiintyvät pää- ja vierasavainten välillä. Samanlaiset yhteydet muodostavat siten yhteystyypin. Yhteystyyppejä voisivat olla Yritys- Tyontekija sekä Opiskelija-OsallistuaKurssiin-Kurssi, jolloin yksilöiden välille tulee relaatiotietokannassa avain yhteys. Esimerkiksi Tyontekija tauluun YritysTunnus vierasavaimeksi. Yhteystyyppejä määriteltäessä ei vielä mietitä avaimia sinänsä, vaan pää- ja vierasavaimet päätetään usein yhteyksien mukaan kun kaikki yhteydet on saatu päätettyä. Yhteystyyppi voi olla kolmea eri astetta: 1:1, 1:M sekä M:N, luetaan yhden suhde yhteen, yhden suhde moneen ja monen suhde moneen. M:N suhde ei ole sallittu valmiissa relaatiotietokannan käsitekaaviossa, ja tällainen suhde on purettava kahdeksi 1:M tyyppiseksi suhteeksi. Kts. Tästä lisää seuraavassa tehtävässä.
Esimerkkejä eri suhteista: 1:1 Rehtori Koulu, Kaupunki Pormestari, jne... Yhteen kouluun liittyy yksi rehtori ja toisinpäin. Pormestariin liittyy yksi kaupunki ja kaupunkiin liittyy yksi pormestariin, ei useampaan. 1:N Koulu Oppilas, Yritys Tyontekija, Pankki Konttori, jne... Kouluun liittyy useita oppilaita, mutta oppilaat liittyvät yhteen kouluun. Yrityksellä on työntekijöitä, mutta työntekijä liittyy vain yhteen yritykseen kerrallaan (ainakin tietokannassa), samoin pankilla on sivukonttoreita, mutta jokainen konttori kuuluu yhteen pankkiin. M:N Kokous Osallistuja, Esitieto Kurssi, Opiskelija Kurssi, Bandi Artisti jne... Kokouksella on useita osanottajia, mutta osallistuja voi olla läsnä useassa eri kokouksissa. (Tai on mahdollista olla näin!). Opiskelija osallistuu kursseille ja kurssiin liittyy opiskelijoita. Bändi voi esiintyä eri artistien kanssa, ja artisti ei aina esiinny saman yhtyeen kanssa. Olennaista yhteyksissä on, että jos on mahdollista, että yksilöön A voi liittyä useampi yksilö B, niin yhteys on silloin 1:N. Jos se ei ole mahdollista, niin vain silloin 1:1. Sama M:N suhteen kanssa. Kaksi eri merkintätapaa alla Suhteita voidaan merkitä asteluvulla, tässä tapauksessa 1 tai N, tai kuten alla on tehty nuolilla. Joskus myös yhteystyypille annetaan nimi, esimerkiksi Opettaa, tai Kuuluu (Oppilas kuuluu Luokka).
Harjoituksissa ei käsitellä yhteystyyppejä joille on asetettu ehdollisuutta, eikä erikoisia yhteystyyppejä. Ominaisuustyypit Ominaisuustyypeistä tulee valmiissa tietokannassa taulujen attribuutteja. Yleensä yhteystyyppien määrittelyn myötä osa ominaisuustyypeistä on jo saatettu määritellä ennen muiden lisäämistä, sillä avain attribuutit on tapana määritellä heti yhteystyyppien jälkeen. Jäljelle jäävät perus ominaisuustyypit, esimerkiksi Opettaja yksilötyypissä Etunimi, Sukunimi, kaikenlaisia yhteystietoja yms. Joskus on tapana merkitä löydetyt ominaisuustyypit käsitekaavioon näkyviin, kun se on kehitetty tälle asteelle saakka. Voi myös olla että ominaisuuksien määrittelyn myötä esiintyy tarvetta muuttaa yksilötyyppejä, erityisesti jos ominaisuuden sijoittaminen tuottaa vaikeuksia ja kaaviosta paljastuu heikkouksia tai epäloogisuutta. Ominaisuustyypit merkitty
Tehtävä 4 Mitä tarkoitetaan monen-suhde-moneen yhteystyypin pilkkomisella? Anna esimerkki tilanteesta jossa tämä on välttämätöntä sekä sopiva ratkaisu. Valmiissa relaatiotietokannassa ei voi esiintyä monen suhde moneen yhteystyyppiä. Ennen kuin käsitekaavio muutetaan varsinaiseksi tietokannaksi, on tällaiset yhteystyypit poistettava. Ratkaisu on purkaa M:N suhde kahdeksi 1:N yhteystyypiksi ja luoda uusi yhteys-yksilötyyppi joka mahdollistaa yhteysinformaation säilymisen, mutta joka ei tarvitse M:N yhteyttä. Sen sijaan kumpikin vanhoista yksilöistä on 1:N yhteydessä tähän uuteen, yhdistävään yksilöön. Alla oleva esimerkki selventää asiaa. Ongelmatilanne Ratkaisu Sekä taulujen rakenne Työntekijällä voi olla nyt useita osallistumisia, ja toisaalta projektiin liittyy (tai voi liittyä) useita osallistumisia. Ratkaisu korjaa ongelman varsin yksinkertaisesti ja vaivattomasti. Tämäkään ei aina ole 100% varma ratkaisu, kuten tehtävän 2 vastauksessa todettiin. Voi olla että yhdistävään yhteystyyppiin joudutaan lisäämään oma pääavain jos on olemassa vaara että yhdistävän yksilötyypin avainpari voi saada saman arvon kahdesti. Usein M:N yhteyden pilkkomisen takia joudutaan luomaan hieman keinotekoiselta vaikutta uusi yhteys yksilötyyppi, mutta ratkaisun tyylikkyys ei ole avain asemassa vaan tuloksena satava toimiva ratkaisu, kuten yllä.