Tietokannan eheysrajoitteet ja niiden määrittäminen SQL-kielellä

hyväksymispäivä arvosana arvostelija Tietokannan eheysrajoitteet ja niiden määrittäminen SQL-kielellä Tuomas Husu Helsinki 9.3.2010 Kandidaatin tutkielma, aine HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tuomas Husu Työn nimi Arbetets titel Title Tietokannan eheysrajoitteet ja niiden määrittäminen SQL-kielellä Oppiaine Läroämne Subject Tietojenkäsittelytiede Tietojenkäsittelytieteen laitos Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Kandidaatin tutkielma, aine 9.3.2010 10 sivua + 0 liitesivua Tiivistelmä Referat Abstract Tietokannan eheysrajoitteet ovat sääntöjä, joilla pidetään huoli tietokannan tietojen määrämuotoisuudesta ja sisäisestä ristiriidattomuudesta. Tässä aineessa esitellään tavallisimmat deklaratiiviset eheysrajoitteet ja niiden määrittämistavat SQL-kielellä. ACM Computing Classification System (CCS): H.2 [Database Management], H.2.0 [General]: Security, integrity, and protection Avainsanat Nyckelord Keywords Eheysrajoitteet, SQL-kieli Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

Sisältö ii 1 Johdanto 1 2 Avainrajoitteet 2 3 Viite-eheysrajoitteet 3 4 Arvojoukkorajoitteet 6 5 Yhteenveto 8 Lähteet 9

1 Johdanto 1 Tietokantojen käyttötapojen monimuotoistuessa, niiden tietosisältöä muokataan yhä useampien erilaisten ja eri tahojen tuottamien sovellusten toimesta, minkä seurauksena tietosisältö on yhä alttiimpana tahattomalle eheyden vahingoittumiselle. Cochrane ja kumppanit muistuttavat [CPM96], että lukuisat tietokantaa mahdollisesti samanaikaisestikin käyttävät sovellusohjelmat muodostavat siten entistä suuremman tarpeen nimenomaan tietokantatasoiselle eheysvalvonnalle. Sen sijaan, että eheydestä pyrittäisiin huolehtimaan sovellusohjelmatasolla, voidaan tietokantatasoisten eheysrajoitteiden avulla suoraviivaisesti määrittää kaikkiin nykyisiin ja tuleviin tietokantaa käyttäviin sovellusohjelmiin pätevät säännöt, jotka ovat siten myös sekä helposti keskitetysti hallittavissa että voimassa kaikissa erikoistapauksissakin. Tietokannan eheysrajoitteet ovat sääntöjä, joilla pidetään huoli tietokannan tietojen määrämuotoisuudesta ja sisäisestä ristiriidattomuudesta. Niillä voidaan määritellä joustamattomat puitteet ja pelisäännöt, joiden mukaisuutta tietokannan sisällöltä joka hetki edellytetään. Eheysrajoitteet ovat tapa julkilausua järjestelmän ennaltasovitut reunaehdot, ei-toiminnalliset vaatimukset (non-functional requirement), jotka voivat ihmiselle olla hyvinkin itsestään selviä, mutta tietojärjestelmän tapauksessa ne on määriteltävä hyvin yksiselitteisesti. Tietokannan eheyssäännöt ovat keskeinen osa relaatiotietomallia. Coddin mukaan [Cod70] relaation jokainen rivi on voitava yksikäsitteisesti tunnistaa ja tietojen väliset loogiset yhteydet kuvata pää- ja viiteavaimien avulla. Keinoja eheyden ylläpitämiseksi on näin ollen tarvittu relaatiomallin historian alusta asti, mutta SQLkieli ei kehityksen alkuvaiheessaan tarjonnut paljoakaan mahdollisuuksia rajoitteiden määrittelemiseksi. Relaatiotietokantojen ja SQL-kielen alkulähteiden, IBM:n System R:n ja SEQUEL-kielen, eheysrajoitteisiin kohdistunut mielenkiinto [ABC76, CAB81, Sto75] koski lähinnä arvojoukkorajoitteita sekä samanaikaisuus- ja suorituskykyongelmien eheysnäkökulmia, joita tuoreemmat tutkimukset [BMP01] eivät juuri samassa valossa tarkastele. Kielen kehittyessä määrittelymekanismi on tullut yhä rikkaammaksi, ja kirjoitelmassa tarkastelen nykyisten SQL-standardien tarjoamia keinoja eheysrajoitteiden määrittelemiseksi sekä määrittelymahdollisuuksien kehittymistä kuuden SQL-standardiversion aikana. Päähuomion tekstissä kiinnitän staattisiin, deklaratiiviseen rajoitteisiin, jotka eivät ota huomioi tilasiirtymiä, vaan yksinkertaisesti määrittävät, onko tietty tietokannan

2 tila eheä vai ei. Käsittelen monikoiden yksikäsitteisyyden perustana olevat avainrajoitteet, tietojen välisiä loogisia yhteyksiä määrittävät viite-eheysrajoitteet sekä attribuuttien arvoille reunaehdot asettavat arvojoukkorajoitteet omissa luvuissaan ja esitän niiden määrittelytavat SQL-kielisin esimerkein. 2 Avainrajoitteet Tietokannasta on pystyttävä hakemaan tietty monikko, mikä edellyttää Coddin relaatiomallin [Cod70] mukaisesti määriteltyä yhdestä tai useammasta attribuutista koostuvaa, jokaisen monikoivan yksilöivää relaatiokohtaista pääavainta. Avainrajoitteilla määrätään relaation pääavain ja halutut ehdokasavaimet yksilöllisiksi, millä varmistetaan, että relaatiossa ei voi olla kahta tai useampaa täysin samanlaista monikkoa, vaikka sovellusohjelma tai käyttäjä sinne epähuomiossa sellaisia pyrkisi syöttämäänkin. Pääavainrajoite määrää pääavaimen myös tyhjiä arvoja sisältämättömäksi. Kuten muutkin eheysrajoitteet, relaatioiden avainrajoitteet määritellään SQL-kielen osajoukoksi miellettävällä tietokannan määrittelykielellä (DDL, Data-Definition Language) joko luotaessa tauluja CREATE TABLE -lausein tai muokattaessa niitä myöhemmin ALTER TABLE -lausein. Perussyntaksi taulun luomiseksi ja pääavaimen määrittämiseksi on CREATE TABLE taulun_nimi ( attribuutti_1,..., attribuutti_n, CONSTRAINT symbolinen_nimi PRIMARY KEY (pääavainattribuutit) Seuraavassa tietokannan määrittelykielisessä esimerkissä luodaan tyontekija -taulu, jossa on hetu-, etunimi-, sukunimi- ja puhelinnro -attribuutit. CONSTRAINT -määreillä luodaan nimettyjä eheysrajoitteita, jotka määräävät hetu-attribuutin relaation pääavaimeksi sekä etunimi-sukunimi-yhdistelmät ja puhelinnumeron yksilöllisiksi. CREATE TABLE tyontekija ( hetu, etunimi,

3 sukunimi, puhelinnro, CONSTRAINT tyontekija_hetu_pk PRIMARY KEY (hetu), CONSTRAINT tyontekija_nimi_unique UNIQUE (etunimi, sukunimi), CONSTRAINT tyontekija_puh_unique UNIQUE (puhelinnro) Tietokannan määrittelykielen kielioppi sallii Silberschatzin ja kumppaneiden mukaan [SKS06] avainrajoitteiden määrittämisen myös attribuuttikohtaisesti nimeämättä niitä CONSTRAINT-määreellä. Tällöin voidaan lausua luontilauseessa esimerkiksi vain CREATE TABLE (..., puhelinnro UNIQUE,... sen sijaan, että määriteltäisiin erikseen attribuutti ja siihen liittyvä yksilöllisyysrajoite. Luontilauseen yksinkertaistumisen vastapainona eheysrajoitteen myöhempi muokkaaminen hankaloituu, kun siihen ei voida viitata nimellä. Poistettaessa symbolisesti nimettyä rajoitetta voidaan poisto kohdistaa vain nimenomaiseen rajoitteeseen komennolla ALTER TABLE taulun_nimi DROP CONSTRAINT symbolinen_nimi kun nimeämätön rajoite vaatii kyseisen attribuutin uudelleenmäärittelyn ALTER TABLE MODIFY -lauseella. Tietokannanhallintajärjestelmä huolehtii avainrajoitteiden valvonnasta, eikä salli yksilöllisiksi määriteltyjen attribuuttien tai attribuuttijoukkojen kaksoiskappaleiden olemassaoloa estäen lisäys- tai päivitysoperaatiot, jotka uhkaisivat avainrajoittein määriteltyä eheyttä. 3 Viite-eheysrajoitteet Tietokanta koostuu lähes poikkeuksetta useista relaatioista, joiden monikot ovat kytköksissä toisiinsa. Relaatiotietokannoissa loogiset yhteydet kuvataan viittaamal-

4 la taulusta toiseen viiteavaimien avulla. Viite-eheysrajoitteilla määrätään, että viiteavaimena toimivan attribuutin arvon on relaatiomallin [Cod70] mukaisesti joko löydyttävä viitatun taulun pääavaimen arvosta tai arvon on oltava tyhjä. Viiteeheysrajoitteilla estetään näin ollen viittaamasta objektiin, jota viitatussa relaatiossa ei ole. Määriteltäessä edellisen esimerkin tyontekija-relaatioon myös osasto-attribuutti, jonka arvo viittaa osasto-relaatioon tunnus-pääavaimeen, voidaan viiteavainrajoitteilla lausua relaatiomallin mukaisen viite-eheyden ylläpitävä rajoite. CREATE TABLE tyontekija ( hetu, etunimi, sukunimi, puhelinnro, osasto CONSTRAINT tyontekija_hetu_pk PRIMARY KEY (hetu), CONSTRAINT tyontekija_osasto_fk FOREIGN KEY (osasto) REFERENCES osasto (tunnus), CONSTRAINT tyontekija_nimi_unique UNIQUE (etunimi, sukunimi), CONSTRAINT tyontekija_puh_unique UNIQUE (puhelinnro) CREATE TABLE osasto ( tunnus, nimi, CONSTRAINT osasto_tunnus_pk PRIMARY KEY (tunnus) Kuvatun kaltaisten luontilauseiden jälkeen tyontekija-taulusta ei olisi mahdollista viitata osasto-taulun riviin, jota siellä ei ole. Tietokannanhallintajärjestelmä oletusarvoisesti estää kaikki viite-eheyttä uhkaavat operaatiot, joten näin ollen se myös estää syöttämästä seuraavan esimerkin mukaisesta tyontekija-tauluun riviä, jossa Seppo Suuren osasto-attribuutin arvoksi on määritelty 3, sillä osasto-taulusta ei vastaavaa riviä löydy.

5 hetu etunimi sukunimi puhelinnro osasto 010160-123X Seppo Suuri 5000 3 020270-456Y Atte Avulias 5020 1 030380-789Z Minna Mallikas 5010 2 tunnus nimi 1 Hallinto 2 Asiakaspalvelu Viite-eheysrajoitteita voidaan ylläpitää paitsi estämällä viite-eheyttä uhkaavat operaatiot, myös määrittämällä toimintaohjeita, joita noudatetaan viite-eheyden rikkovan päivitysoperaation tapahtuessa. Silberschatz ja kumppanit [SKS06] listaavat oppikirjassaan erilaisiksi toimintamalleiksi estämisen, tyhjentämisen, vyöryttämisen, sekä korvaamisen oletusarvolla. Toimintaohje on määriteltävissä erikseen niin viite-eheyden rikkoville päivitys- kuin poisto-operaatioillekin, jolloin poikkeustilannemenettely voidaan määritellä operaatiokohtaisesti. Estäminen (restrict) on oletusarvoinen toimintatapa, joka on voimassa, jos muuta toimintaohjetta ei ole määritelty. Toimintaohje estää viite-eheyttä uhkaavan päivitysoperaation. Tyhjentäminen (set null) tyhjentää viiteavaimen arvon asettaen attribuutin arvoksi tyhjän arvon (null), jos viitatun relaation pääavaimen arvo muuttuu tai relaatio poistetaan, ja tyhjä-arvot on sallittu attribuutin arvoksi. Vyöryttäminen (cascade) muuttaa viiteavainattribuuttien arvot vastaamaan viitattuja arvoja päivitysoperaation yhteydessä. Vastaavasti se poistaa viittaavat monikot poisto-operaation kohdistuessa viitattuun riviin. Esimerkkitaulujen tapauksessa Minna Mallikas -rivi poistettaisiin tyontekija-taulusta, jos

6 Asiakaspalvelu -rivi poistettaisiin osasto-taulusta, ja vastaavasti viiteavaimen arvo päivitettäisiin arvoon 5, jos sellainen päivitysoperaatio kohdistuisi osasto-taulun Asiakaspalvelu -riviin. Korvaaminen oletusarvolla (set default) korvaa viiteavaimen arvon sille mahdollisesti määritetyllä oletusarvolla, jos viitatun relaation pääavaimen arvo muuttuu tai relaatio poistetaan. Tietokannan määrityskielen syntaksi toimintaohjeiden määrittämiseksi viiteavainrajoitteen yhteydessä on seuraava CONSTRAINT symbolinen_nimi FOREIGN KEY (viiteavain-attribuutti) REFERENCES viitatun_taulun_nimi (viitatun taulun pääavain) ON UPDATE (RESTRICT CASCADE SET NULL SET DEFAULT) ON DELETE (RESTRICT CASCADE SET NULL SET DEFAULT) Esimerkkitaulumme viiteavainmääritys voisi olla siis muotoa CREATE TABLE tyontekija (... CONSTRAINT tyontekija_osasto_fk FOREIGN KEY (osasto) REFERENCES osasto (tunnus) ON UPDATE CASCADE ON DELETE RESTRICT,... jolloin viitatun taulun ylläpito-operaatiot vyöryisivät viittaavaan tauluun, mutta viitattavan taulun monikoiden poisto-operaatioita ei sallittaisi, jos viittaavassa taulussa on yksikin viite niihin. 4 Arvojoukkorajoitteet Tietokannan relaatioiden monikot koostuvat attribuuttien arvoista, jotka ilmaisevat mitä moninaisimpia asioita. Karkeasti attribuuttien arvojoukot voidaan Mannilan ja Räihän mukaan [MaR92] jakaa tietotyyppinsä perusteella vähintäänkin numeerisiin

7 ja merkkijonoattribuutteihin. Usein on tarkoituksenmukaista, että kukin attribuutti voi saada vain tietynlaisia määrämuotoisia arvoja eikä esimerkiksi laskutoimituksissa käytettävä, lukumäärää ilmaiseva attribuutti saa arvokseen merkkijonoa. Arvojoukkorajoitteilla voidaan määrittää muun muassa attribuutin tietotyyppi, pituus, oletusarvo, sallitut arvot ja pakollisuus. Tietotyyppi ja pituus määritellään tietokannan määrittelykielisissä taulujen luontilauseissa lähtökohtaisesti aina, ja muut täsmentävät määritykset tarpeen vaatiessa. Tietotyyppi mainitaan luontilauseissa kunkin attribuutin jälkeen, muut rajoitteet voidaan määrittää joko nimeämällä ne symbolisesti CONSTRAINT-määrein tai attribuuttikohtaisesti arvojoukkorajoitteita tietotyyppimäärityksen jälkeen antamalla. Aiemmin esimerkkinä käytettyyn tyontekija-tauluun voitaisiin lisätä arvojoukkorajoitteiden havainnollistamiseen soveltuva palkka-attribuutti, ja luoda taulu luontilauseella CREATE TABLE tyontekija ( hetu CHAR(10), etunimi VARCHAR(16), sukunimi VARCHAR(32), puhelinnro CHAR(4), osasto INTEGER(2), palkka DECIMAL(4,2) NOT NULL DEFAULT 1600.00,... CONSTRAINT tyontekija_palkka_check CHECK (palkka >= 1600 AND palkka <= 6000) Attribuuteille on nyt määritetty SQL-standardin mukaiset tietotyypit ja annettu niille maksimipituudet. Palkka-attribuutin arvojoukko on tietotyypiltään kaksi desimaalia sisältävä nelinumeroinen luku, sitä on pakollisuusvaatimuksella estetty saamasta arvokseen tyhjiä arvoja, oletusarvoksi on oletusmääreellä määritetty 1600.00, ja tarkistusmääreellä mahdollisiksi arvoiksi intensionaalisesti määritelty arvojoukko 1600 6000. Taulun luontilauseessa voidaan käyttää myös itse määriteltyjä tietotyyppejä. Esimerkin kaltainen kkpalkka-tietotyyppi voidaan luoda CREATE DOMAIN -lauseella: CREATE DOMAIN kkpalkka DECIMAL(4,2)

8 DEFAULT 1600.00 CONSTRAINT kkpalkka_check CHECK (VALUE >= 1600 AND VALUE <= 6000) Itse määriteltyä tietotyyppiä voidaan käyttää taulujen luontilauseissa aivan, kuten SQL-standarditietotyyppejäkin eli edellinen esimerkki voitaisiin nyt lausua kkpalkkatietotyypin avulla CREATE TABLE tyontekija ( hetu CHAR(10), etunimi VARCHAR(16), sukunimi VARCHAR(32), puhelinnro CHAR(4), osasto INTEGER(2), palkka kkpalkka,... Tietokannanhallintajärjestelmä ylläpitää arvojoukkorajoitteita estämällä syöttämästä rajoitteiden vastaisia arvoja attribuuttien arvoiksi. Arvojoukkorajoitteilla ei ole mahdollista huomioida tilasiirtymiä, esimerkiksi määrittää palkka-attribuuttiarvoa siten, että sen arvo saisi vain kasvaa ei koskaan laskea. Tilasiirtymiin kohdistuvat rajoitteet on mahdollista toteuttaa tapahtumaperustaisten tietokantaherättimien avulla, jotka myös mahdollistavat mielivaltaisten rajoitteiden luomisen, mutta tässä kirjoitelmassa ei proseduraalista eheysvalvontaa tarkastella. 5 Yhteenveto Eheysrajoitteet tarjoavat joukon sääntöjä tietokannan eheän tilan määrittämiseksi ja siitä poikkeavien tilojen estämiseksi. SQL-standardin yli 20-vuotisen historian aikana eheysrajoitteiden staattinen määrittelymekanismi on kehittynyt kattamaan niin relaation monikot yksilöivät pääavaimet, toiseen relaatioon viittaavat viiteavaimet toimintaohjeineen kuin yksilöinti-, tarkistus-, oletus- ja pakollisuusmääreetkin. Eheysrajoitteiden määrittely on tietokantaperuskurssien tyypillistä sisältöä ja kenen tahansa relaatiotietokantojen hallinnan kanssa työskentelevän arkipäivää. Standardinmukaisista menetelmistä huolimatta eheysrajoitteiden määrittelyssä ongelmaksi saattaa muodostua eri järjestelmätoimittajien toisistaan poikkeava tuki standardin

9 ominaisuuksille. Vuoden 1992 SQL-standardissa määriteltyjä eheysrajoitteita puuttuu Behrendin ja kumppanien mukaan [BMP01] edelleen kaikista kaupallisista tuotteista ja kunkin tuotteen tarjoamat mahdollisuudet on käyttäjän itse selvitettävä dokumentaatiosta. Lähteet ABC76 BMP01 CAB81 Cod70 CPM96 MaR92 SKS06 Sto75 Astrahan, M. M., Blasgen, M. W., Chamberlin, D. D., Eswaran, K. P., Gray, J. N., Griffiths, P. P., King, W. F., Lorie, R. A., McJones, P. R., Mehl, J. W., Putzolu, G. R., Traiger, I. L., Wade, B. W. ja Watson, V., System R: relational approach to database management. ACM Trans. Database Syst., 1,2(1976), sivut 97 137. Behrend, A., Manthey, R. ja Pieper, B., An amateur s introduction to constraints and integrity checking in SQL3. Datenbanksysteme in Büro, Technik und Wissenschaft (BTW). Springer, 2001, sivut 405 423. Chamberlin, D. D., Astrahan, M. M., Blasgen, M. W., Gray, N. N., King, W. F., Lindsay, B. G., Lorie, R., Mehl, J. W., Price, T. G., Putzolu, F., Selinger, P. G., Schkolnick, M., Slutz, D. R., Traiger, I. L., Wade, B. W. ja Yost, R. A., A history and evaluation of System R. Commun. ACM, 24,10(1981), sivut 632 646. Codd, E. F., A relational model of data for large shared data banks. Commun. ACM, 13,6(1970), sivut 377 387. Cochrane, R., Pirahesh, H. ja Mattos, N., Integrating triggers and declarative constraints in SQL database systems. VLDB 96: Proceedings of 22th International Conference on Very Large Data Bases, 1996, sivut 567 578. Mannila, H. ja Räihä, K., The Design of Relational Databases. Addison- Wesley Publishing Company, Wokingham, 1992. Silberschatz, A., Korth, H. F. ja Sudarshan, S., Database System Concepts. Fifth Edition. McGraw-Hill, New York, 2006. Stonebraker, M., Implementation of integrity constraints and views by query modification. SIGMOD 75: Proceedings of the 1975 ACM SIG-

MOD International Conference on Management of Data, New York, 1975, ACM, sivut 65 78. 10