HELIA 1 (19) Outi Virkki Tietokantasuunnittelu

Transkriptio

1 HELIA 1 (19) Luento 11 Eheyssäännöt (Integrity Constraints)... 2 Eheyden valvonta... 3 Yksilön eheyssääntö... 4 Arvojoukkoeheyssäännöt... 5 Null-arvoista... 6 Viite-eheyssäännöt... 7 Emorelaation päivitys... 9 Lisäys... 9 Poisto / Pääavaimen muutos... 9 Lapsirelaation päivitys Lisäys / Viiteavaimen muutos Poisto Sovellusaluekohtaiset säännöt Yhteenveto Tietokannan suunnittelun abstraktiotasot tasomalli TIHA-standardi (SFS-106) Kuvaustasot toinen näkökulma Käsite- ja loogisen tason suunnittelun kulku Satunnaisia suosituksia Kysymyksiä käsite- ja loogisen tason tietokantasuunnittelusta? 19

2 HELIA 2 (19) Eheyssäännöt (Integrity Constraints) Osa relaatiotietomallia 1. Yksilön eheyssääntö (entity integrity constraints) 2. Viite-eheyssääntö (referential integrity constr.) 3. Arvojoukko-eheyssääntö (domain constraints) 4. Käyttäjän määrittelemät sovelluskohtaiset eheyssäännöt Eheys Yksittäisen tai useamman tietovaraston tietojen sisäinen ristiriidattomuus

3 HELIA 3 (19) Eheyden valvonta a) Tiedonhallintajärjestelmä b) Sovellusohjelma c) Käyttäjä Yksilön eheyssäännöstä tiedonhallintajärjestelmät ovat huolehtineet jo pitkään Viite-eheydestä ja arvojoukkoeheydestä on perinteisesti huolehdittu sovellusohjelmassa Virhealtis, epäluotettava Tiedonhallintajärjestelmät tukevat eheyden valvontaa vaihtelevasti Vain osa määriteltävissä Rajoituksia Syntaksit erilaisia, heikko siirrettävyys Luotettavin tapa

4 HELIA 4 (19) Yksilön eheyssääntö Entity Integrity Relaatiossa ei saa olla kahta tai useampaa täysin samanlaista riviä Pääavain on pienin joukko attribuutteja, jotka riittävät yksilöimään kunkin relaation rivin Esim. KOIRA Rekno Nimi Rotu S-vuosi 105 Anki Seka Turkka Suom.pk Turkka Suom.pk Saara Labr Tietokannan hallintajärjestelmä huolehtii yksilön eheyssäännön valvonnasta, mikäli eheyssääntö on määritelty tietokantaan (Primary Key Constraint)

5 HELIA 5 (19) Arvojoukkoeheyssäännöt Domain Constraints Tulkinta ja määrittely vaihtelee! a) Attribuutin arvot kuuluvat samaan arvojoukkoon. b) Kaikki arvojoukkoon liittyvät rajoitukset: tietotyyppi, pituus, oletusarvo, sallitut arvot, välttämättömyys/pakollisuus, erilaisuus, ) Tietokannan hallintajärjestelmä huolehtii viite-eheyssäännön valvonnasta useamman mekanismin avulla: tietotyyppitarkistus oletusarvomääritykset (Default value) eheyssääntömäärittelyt (Check Constraint) (myös pakollisuus / not null -määrittelyt) erilaisuusmäärittelyt (Unique Constraint) herättimet (Trigger) Esim. Asiakkaan_tyyppi Char(10) Not null Default( yritys ) Check(value in yritys, yksityinen ),

6 HELIA 6 (19) Null-arvoista Puuttuva arvo Tuntematon arvo 0 Ä esitystavat ja käyttäytyminen eri operaatioissa vaihtelevat eri tiedonhallintajärjestelmissä lajittelu vertailut funktiot liitokset... Å toiminta testattava, jos haluaa välttää ennalta arvaamattomia tuloksia / seurauksia Ä vältä mahdollisuuksien mukaan! Ä jos et voi välttää, varaudu mahdollisuuksien mukaan

7 HELIA 7 (19) Viite-eheyssäännöt Referential Integrity Ä Viiteavaimet ainoa keino määritellä yhteyksiä relaatioiden välille (Foreign Key Constraint) Viite-eheyden ylläpito Mitä toimenpiteitä tehdään kun äiti- tai lapsirelaatioon kohdistuu lisäys, muutos tai poisto Ä Määritellään käsitekaavion (ja käyttäjien haastattelun) perusteella Perustana kohdealueen toimintasäännöt Terminologia Teoria Intuitiivinen Englanti Viittaava relaatio Lapsi-relaatio Referencing relation Viitattu relaatio Emo-relaatio Referenced relation Target relation

8 HELIA 8 (19) Esim. esimies <-o---- ->> työntekijä Kullakin esimiehellä on välttämättä työntekijä, mahdollisesti useampia; Kullakin työntekijällä on mahdollisesti esimies, mutta vain 1 Eheyssäännöt 1.1 Esimies poistetaan -> työntekijöiden esimiestieto tyhjäksi 1.2 Uusi esimies -> kirjattava vähintään 1 alainen 1.3 Esimiehen tunniste muuttuu -> alaisten esimies-viiteavaimet muuttuvat 2.1 Uusi alainen -> ei vaatimuksia / vaikutuksia 2.2 Alainen poistuu -> jos ko. viimeinen alainen, esimies tiedot poistetaan 2.3 Alaisen tiedot muuttuvat -> ei vaatimuksia / vaikutuksia

9 HELIA 9 (19) Emorelaation päivitys Lisäys - Poisto / Pääavaimen muutos Rajoitettu / Restrict / No Action Poisto / pääavaimen muutos sallitaan joss lapsirelaatiossa ei esiinny viittauksia poistettavaan Vyörytys / Cascade Poisto / pääavaimen muutos sallitaan aina. Jos lapsirelaatioita on, nekin poistetaan / niiden viiteavaimen arvo päivitetään vastaavasti Tyhjä arvo / Set null Poisto / pääavaimen muutos sallitaan aina. Jos lapsirelaatioita on, niiden viiteavaimen arvoksi asetetaan null (huom. null arvojen oltava sallittuja ko. viiteavaimelle!) Oletusarvo / Set default Poisto / pääavaimen muutos sallitaan aina. Jos lapsirelaatioita on, niiden viiteavaimen arvoksi asetetaan oletusarvo (huom. oletusarvo oltava määritelty ko. viiteavaimelle!)

10 HELIA 10 (19) Esim. TILAUS TOIMITTAJA Ä Huom: pakollisuutta / ehdollisuutta ei määritelty 1. Rajoitettu Käyttäjä ei voi poistaa toimittajaa, jos tilauksia on kirjattu. 2. Vyörytys Käyttäjä poistaa toimittajan ja kaikki ko. toimittajaan liitetyt tilaukset poistetaan myös (peruutetaan.) 3. Tyhjä arvo Käyttäjä poistaa toimittajan ja tilausten toimittajatieto muutetaan tyhjäksi (...) 4. Oletusarvo Käyttäjä poistaa toimittajan ja tilausten toimittajatiedoksi muuttuu vakiotoimittaja, Laatutoimitus Oy Ä Ota huomioon mahdollinen ketjuvaikutus!!

11 HELIA 11 (19) Lapsirelaation päivitys Lisäys / Viiteavaimen muutos Riippuvainen / Dependent Lisäys / muutos viiteavaimeen sallitaan joss emorelaatiossa on ko. viiteavainta vastaava pääavain Automaattinen / Automatic Lisäys / muutos viiteavaimeen sallitaan aina. Jos emotaulussa ei ole vastinriviä, se luodaan. (<- miten??) Tyhjä / Set null Lisäys / muutos viiteavaimeen sallitaan aina. Jos emotaulussa ei ole vastinriviä, viiteavaimen arvoksi asetetaan null. Oletusarvo / Set default Lisäys / muutos viiteavaimeen sallitaan aina. Jos emotaulussa ei ole vastinriviä, viiteavaimen arvoksi asetetaan oletusarvo. Poisto -

12 HELIA 12 (19) Esim. TILAUS TOIMITTAJA 5. Rajoitettu Käyttäjä liittää tilauksen johonkin olemassa olevista toimittajista 6. Automaattinen Käyttäjä liittää tilauksen olemassa olevaan tai uuteen toimittajaan, tarvittaessa uusi toimittajatieto luodaan 7. Tyhjä arvo Käyttäjä liittää tilauksen olemassa olevaan toimittajaan tai toimittajatieto jätetään tyhjäksi, 8. Oletusarvo Käyttäjä liittää tilauksen olemassa olevaan toimittajaan tai toimittajaksi kirjataan vakiotoimittaja, Laatutoimitus Oy

13 HELIA 13 (19) Sovellusaluekohtaiset säännöt Lisäysten, muutosten ja poistojen mielekkyyden valvonta ko. sovellusympäristössä Esim. Elokuvatehtävä: Anekdootin liityttävä vähintään yhteen seuraavista: yritys, henkilö, elokuva Esim. Fleming Ä Tiedonhallintajärjestelmät tukevat vaihtelevasti SQL-92: Assertions / yleiset säännöt / Vahvistussäännöt Liipasimet / Triggerit Å Hyödyntäminen toistaiseksi vähäistä

14 HELIA 14 (19) Yhteenveto Tietokannan suunnittelun abstraktiotasot 3-tasomalli Käsitetaso Ohjelmataso Fyysinen taso Tiedon nimi, merkitys ja arvot Tiedon esitys valitulla tietomallilla Tiedon esitys fyysisellä tallennusvälineellä riippumaton toteutusratkaisuista sidottu käytettävään tietomalliin ja kieleen sidottu käytettävään toteutusympäristöön ehkä yleisimmin on käytössä Ä Eri tasojen kuvaukset yhdessä kuvaavat tiedot kokonaisuudessaan Samaa asiaa ei kuvata monella tasolla. Ä Kullakin tasolla on oma peruskäsitteistönsä ja esitystekniikka Piirrokset / piirroskielet Formaalit tekstimuotoiset kuvauskielet Tietohakemistot

15 HELIA 15 (19) TIHA-standardi (SFS-106) 1988 Taso Keskeinen sisältö Suunnittelun tulos Käsitetaso Looginen taso Tekninen taso Fyysinen taso Kohdealueen käyttämien käsitteiden rakenne Tietomallin mukainen (looginen) tietorakenne Tietyn DBMS:n mukainen (tekninen) tietorakenne Tietyn tiedostonhallintaohjelmiston mukainen (fyysinen) talletusrakenne Käsitekaavio Normalisoidut relaatiokaavat Eheysmäärittelyt Tietokannan luontilauseet SQL:llä Tietokannan talletusmääritykset

16 HELIA 16 (19) Kuvaustasot toinen näkökulma Käyttäjäryhmän / Sovelluksen alikaavio Yhteisön käsitekaavio Sisäinen kaavio (Toteutusrakenne) Käsitekaavio Tietokannan käsitteellisen sisällön kuvaus Sisäinen kaavio Tietokannan toteutusrakenteen kuvaus Alikaavio Tietokannan toteutusrakenne jonkun sovellusohjelman / käyttäjäryhmän näkökulmasta Ä Teknisen tason toteutus piilotetaan kaikilta sovelluksilta Ä Joustavammin muokattavissa Ä Käsitekaavio piilotetaan siltä osin kuin ko. sovellusohjelma / käyttäjäryhmä ei sitä tarvitse Ä Ei turhaa monimutkaisuutta

17 HELIA 17 (19) Käsite- ja loogisen tason suunnittelun kulku 1. Tietotarpeiden kartoitus 2. Keskeisten käsitteiden / olioiden / yksilötyyppien poiminta 3. Olioiden välisten suhteiden määrittely 4. Olioiden määrittely 5. Pääavainten määrittely 6. Muiden ominaisuuksien määrittely 7. Normalisointi 8. Viite-eheysmäärittely 9. Mielekkyysmäärittely Tietokantatoteutuksen suunnittelu

18 HELIA 18 (19) Satunnaisia suosituksia J Tietokeskeinen suunnittelu turvaa parhaiten relevantin, johdonmukaisen ja joustavan tietokannan. Tietotarpeiden kartoitusvaiheessa voi apuna käyttää myös muita lähestymistapoja J Seurustele aktiivisesti käyttäjien kanssa Vain keskustelemalla kohdealueen käsitteellinen rakenne aukenee. Kysele. J Pitäydy johonkin metodologiaan Etenemistapa Nimeämiskäytäntö Dokumentointikäytäntö Kuvaustekniikat Työkalut J Muodolliset vaatimukset / tekniikat ovat työkaluja, käytä niitä, normalisoi relaatiot ja määrittele käsitteet J Hyödynnä kaavioita Kaavio on yksiselitteinen, parempi kun n sanaa J Ylläpidä tietohakemistoa Muuten on enemmän kuin todennäköistä, että käsitteiden tarkka merkitys on epäselvä suunnitteluun osallistuville J Määrittele olioiden lisäksi myös eheyssäännöt

19 HELIA 19 (19) Kysymyksiä käsite- ja loogisen tason tietokantasuunnittelusta?