hyväksymispäivä arvosana arvostelija Tietokantaherättimet Tuomas Husu Helsinki 10.5.2010 Kandidaatin tutkielma 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 Tietojenkäsittelytieteen laitos Tietokantaherättimet Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Kandidaatin tutkielma 10.5.2010 20 sivua + 0 liitesivua Tiivistelmä Referat Abstract Tietokannat ovat perinteisesti olleet passiivisia tietovarastoja ja suorittaneet transaktioita vain käyttäjän tai sovellusohjelman pyynnöstä. Lyhyehkössä ajassa aktiivisen tietokannan ominaisuudet ovat tulleet osaksi standardinmukaisia tietokannanhallintajärjestelmiä. Tutkielma käsittelee tietokantaherättimiä aktiivisen tietokannan toteutusmekanismina. Tutkielmassa käydään läpi deklaratiiviset eheysrajoitteet, aktiivisen tietokannan määritelmä sekä tietokantaherättimet erilaisine käyttötapoineen ja toimintaperiaatteineen. ACM Computing Classification System (CCS): H.2.0 [Database Management - General]: Security, integrity, and protection, H.2.3 [Database Management - Languages]: Data description languages Avainsanat Nyckelord Keywords herätin, aktiivinen tietokanta, eheysvalvonta, relaatiotietokanta Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information
Sisältö ii 1 Johdanto 1 2 Tietokannan eheysrajoitteet 2 3 Aktiivinen tietokanta ja tapahtuma-ehto-toiminta -sääntö 6 4 Tietokantaherätin 9 5 Herättimien ja deklaratiivisten rajoitteiden yhteistoiminta 14 6 Tärkeitä sovellusalueita 17 7 Yhteenveto 18 Lähteet 19
1 Johdanto 1 Tavanomaiset passiiviset tietokannat suorittavat kyselyjä ja tapahtumia joko käyttäjän tai sovellusohjelman pyynnöstä. Tietokannan eheä ja käyttökelpoinen tila määritellään reliaatiomallissa [Cod70] esitetyin tavoin deklaratiivisin eheysrajoittein, joiden perusteella voidaan lausua, onko jokin tietty tietokannan tila eheä vai ei. Deklaratiiviset eheysrajoitteet mahdollistavat monipuolisen staattisen määrittelyn, mutta eivät huomioi eheän tilan puitteissa tapahtuvia tilasiirtymiä eli esimerkiksi tietyn attribuutin arvon eheyttä loukkaamatonta suhteellista muutosta, vaan ainoastaan kaksijakoisen eron: onko jokin tietty tila eheä vai ei [BMP01]. Aktiivinen tietokanta on tietokanta, joka mahdollistaa reaktiivisen reagoinnin määrättyihin tietokannan sisäisiin ja ulkoisiin tapahtumiin myös edellä mainittuihin tilasiirtymiin. Aktiivisuuden käsite ehtovartioituine toimenpiteineen laajentaa perinteisen tietokannan passivisesta tietovarastosta aktiiviseksi tiedonhallintajärjestelmän osaksi [ElN94, CCW00]. Aktiivisen tietokannan toiminta perustuu tapahtumaehto-toiminta -sääntömalliin [LMC02], jossa käyttäjä määrittelee säännön laukaisevan tapahtuman, säännön suorituksen toimeenpanon edellytyksenä olevan ehdon sekä toimenpiteet, joihin tapahtumaketjun seurauksena ryhdytään. Tietokannan aktiivisuuden toteutusmekanismi on tietokantaherätin [SKS06]. Siinä missä deklaratiiviset rajoitteet ovat staattisia ja jatkuvasti läsnäolevia määräyksiä tietokannan eheyden ylläpitämiseksi, herättimet ovat dynaamisia, tietyn ennalta määritellyn tapahtuman seurauksena automaattisesti suoritettavia toimintoja. Tietokantaherättimet eivät ole rajoitteiden kanssa kilpaileva konstruktio vaan toimintaa laajentava ominaisuus. Herätin on intuitiivisesti miellettävissä SQL-lausejoukoksi, joka suoritetaan tietyn ennalta määritellyn ehdon täytyttyä. Tyypillinen tietokantatapahtuma, johon tietokanta voidaan määritellä reagoimaan, on esimerkiksi tiedonpäivitys, kuten kuvassa 1. Valjastamalla tietokanta huolehtimaan eheysvalvonnasta deklaratiivisten rajoitteiden ja herättimien avulla saavutetaan monia etuja sovellusohjelmatasolla suoritettuun valvontaan verrattuna. Tietokantatasoinen valvonta mahdollistaa sääntöjen ulottamisen yhdellä määrittelyllä kaikkiin nykyisiin ja tuleviin sovellusohjelmiin. Tietokantatasolla määritellyt säännöt ovat keskitetysti hallittavissa ja ne ovat voimassa kaikissa erikoistapauksissakin [SiK95]. Tietokantaherättimet tulivat osaksi SQL-standardia sen kolmannessa versiossa vuonna 1999 [CPM96]. Suoraviivaisesta toimintaperiaatteestaan huolimatta tietokan-
2 Kuva 1: Tietokantaherätin. taherättimien suoritusarkkitehtuurin liittyy hyvin täsmällinen suoritusjärjestyksen määritelmä, jolla varmistetaan yhteistoiminta eheysrajoitteiden viite-eheyden valvontaa monipuolistavien vyörytyssääntöjen kanssa. Tämän tutkielman luvussa 2 esitellään passivisen tietokannan keinot eheysvalvontaan, luvussa 3 aktiivisen tietokannan käsite toimintaperiaatteineen ja luvussa 4 tietokantaherättimet määrittelysyntakseineen. Luvussa 5 tarkastellaan herättimien ja deklaratiivisten eheysrajoitteiden yhteistoimintaan liittyvää toimintalogiikkaa sekä luvussa 6 herättimien tarjoamia erilaisia käyttökohteita. Lopuksi luvussa 7 on yhteenveto ja pohdintaa siitä, mikä on aktiivisuuden merkitys tietokannanhallintajärjestelmille. 2 Tietokannan eheysrajoitteet Tietokannan eheysrajoitteet (integrity constraint) ovat sääntöjä, joilla pidetään huoli tietokannan tietojen määrämuotoisuudesta ja sisäisestä ristiriidattomuudesta [BMP01]. 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 (nonfunctional requirement), jotka voivat ihmiselle olla hyvinkin itsestään selviä, mutta tietojärjestelmän tapauksessa ne on määriteltävä yksikäsitteisesti. Eheysrajoitteilla voidaan esimerkiksi määrätä, että henkilörekisterissä tietty henkilötunnus voi esiintyä vain kerran tai sallia henkilörekisteriin lisätyn henkilön palkan olla vain tietyllä vaihteluvälillä oleva kokonaisluku.
3 Tietokantojen ollessa keskitettyjä tietovarastoja niitä saattavat samanaikaisesti käyttää lukuisat eri käyttäjät ja sovellusohjelmat. Kitkattoman yhteistoiminnan edellytyksenä ovat yksiselitteiset pelisäännöt, jotka huolehtivat tietokannan määrämuotoisuudesta käyttäjien ja sovellusohjelmien tahattomista ja tahallisista eheyttä horjuttavista toimista huolimatta. Osa eheysrajoittein määrättävistä säännöistä liittyy relaatiomallin [Cod70] määräämiin reunaehtoihin tietokanta saa sisältää vain yksilöitäviä monikoita, sen sisällä voidaan viitata vain olemassaoleviin monikoihin ja attribuuttien arvojen on sisällyttävä niille määrättyihin arvojoukkoihin ja osa laajentaa relaatiomallin vaatimuksia ylläpitäjän tietokannalta edellyttämän toimintalogiikkan toteuttamiseksi eli esimerkiksi määräämällä palkka-attribuutin arvoksi työehtosopimuksen määrämään vaihteluväliin. Eheysrajoitteet voidaan jakaa avain-, viite-eheys- ja arvojoukkorajoitteisiin [SKS06]. Avainrajoitteilla määrätään relaatioiden pääavaimet ja taataan siten monikoiden yksilöllisyys. Viite-eheysrajoitteilla määritetään tietokannan tietojen väliset loogiset yhteydet ja voidaan lausua tiettyjä vaihtoehtoisia toimintaohjeita eheyden ylläpitämiseksi viite-eheyttä horjuttavien päivitysten varalle. Arvojoukkorajoitteilla asetetaan reunaehdot attribuuttien arvoille ja pakotetaan siten tietokantaan syötettävä sisältö haluttujen puitteiden mukaiseksi. Esimerkkirelaatiot Työntekijä (taulukko 1) ja Osasto (taulukko 2) kuvaavat henkilörekisteriä, jossa Työntekijä-relaatio sisältää kuvitteellisen yrityksen työntekijöiden yksilölliset henkilötunnukset, nimet, viittaukset osastoon, palkat sekä viittaukset kunkin työntekijän esimieheen. Osasto-relaatiossa on listattu osastojen yksilölliset tunnukset, nimet, viittaukset osaston päällikköön sekä kunkin osaston yhteenlasketut palkkakulut. Työntekijä hetu nimi osasto palkka esimies 001A Maisa Hiiri 3 5400.00 NULL 002B Nipa Norsu 2 4200.00 001A 003C Arttu Orava 1 3600.00 001A 004D Keke Krokotiili 2 3000.00 002B 005E Tellu Kana 1 2400.00 003C 006F Osku Strutsi 1 1600.00 003C Taulukko 1: Esimerkkirelaatio Työntekijä.
4 Osasto tunnus nimi päällikkö palkkayht 1 Asiakaspalvelu 003C 7600.00 2 Tuotekehitys 002B 7200.00 3 Hallinto 001A 5400.00 Taulukko 2: Esimerkkirelaatio Osasto. Taulukossa 1 esitetyn Työntekijä-relaation deklaratiiviset eheysrajoitteet olisivat esitettävissä SQL-kielen osajoukoksi miellettävällä tietokannan määrittelykielellä (DDL, data definition language) muodossa [SKS06]: CREATE TABLE Työntekijä ( hetu CHAR(4), nimi VARCHAR(16), osasto INTEGER(1), palkka FLOAT(4,2), CONSTRAINT tyontekija_hetu_pk PRIMARY KEY (hetu), CONSTRAINT tyontekija_osasto_fk FOREIGN KEY (osasto) REFERENCES Osasto (tunnus) ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT tyontekija_esimies_fk FOREIGN KEY (esimies) REFERENCES Tyontekija (hetu) ON UPDATE CASCADE ON DELETE SET NULL, CONSTRAINT tyontekija_palkka_check CHECK (palkka >= 1600 AND palkka <= 6600) );. Tietokantataulun luontilauseessa määritellään relaation attribuutit tietotyyppeineen, yksilöllinen hetu-pääavainattribuutti, Osasto-relaatioon viittaava osasto-attribuutti, samaan relaatioon viittaava (self-referencing) esimies-attribuutti, toimintaohjeet viiteeheyttä uhkaavien ylläpito-operaatioiden varalle sekä palkka-attribuutin vaihteluvälin 1600 6600 määräävä arvojoukkorajoite. Toimintaohjeet määräävät, että työntekijät poistetaan rekisteristä, jos heidän osastonsa poistetaan. Sen sijaan poistettaes-
5 sa työntekijän esimies ei työntekijää poisteta, vaan poistetaan tältä arvo esimiesattribuutista. Vastaavasti taulukossa 2 kuvattu Osasto-relaatio voisi olla määrittelykieliseltä syntaksiltaan seuraava: CREATE TABLE Osasto ( tunnus INTEGER(1), nimi VARCHAR(16), päällikkö CHAR(4), palkkayht FLOAT(6,2), CONSTRAINT osasto_tunnus_pk PRIMARY KEY (tunnus), CONSTRAINT osasto_päällikkö_fk FOREIGN KEY (päällikkö) REFERENCES Työntekijä (hetu) ON UPDATE CASCADE ON DELETE SET NULL );. Osasto-tietokantataulun luontilauseessa listataan attribuutit tietotyyppeineen, määritellään yksilöllinen tunnus-pääavainattribuutti ja Työntekijä-taulun pääavaimeen viittaava päällikkö-viiteavainattribuutti sekä lausutaan toimintaohje viite-eheyttä uhkaavien päivitys- ja poisto-operaatioiden varalle. Päivitettäessä Työntekijä-taulun viitattua hetu-pääavainattribuuttia muutokset vyöryvät myös Osasto-taulun päällikköviiteavaimeen. Poistettaessa jonkin osaston päällikkö Työntekijä-taulusta tyhjennetään viiteavainattribuutin arvo. Deklaratiiviset eheysrajoitteet mahdollistavat viite-eheyden ylläpidon paitsi estämällä viite-eheyttä uhkaavat operaatiot, myös tarjoamalla molemmissa määrittelykielisissä esimerkeissä esitetyn kaltaisen toimintaohjemäärittelyn. Toimintaohjeet ovat määriteltävissä erikseen viite-eheyden rikkoville päivitys- ja poisto-operaatioille. Näin ollen viitatun attribuutin ollessa joko päivitys- tai poisto-operaation kohteena voidaan toimintaohjeiden avulla Silberschatzin ja kumppaneiden [SKS06] mukaan estää (restrict) operaatio, tyhjentää (set null) viittaava attribuutti, vyöryttää (cascade) viitatun attribuutin muutos viittaavaan attribuuttiin, tai korvata viittaava attribuutti oletusarvolla (set default).
6 Toimintaohjemäärittelyn puuttuessa viite-eheyttä uhkaavat päivitys- ja poisto-operaatiot estetään. Toimintaohjemäärittely on deklaratiivisen eheysrajoitemäärittelyn reaktiivisin ominaisuus ja monipuolistaa siten muilta osin varsin staattista valvontamekanismia. Toimintaohjeet on kuitenkin määriteltävissä vain muutamiin edellä mainittuihin viite-eheyden ylläpitoon tarkoitettuihin erikoistapauksiin, joten tilasiirtymäperustaiseen eheysvalvontaan tai taulukon 2 esimerkkirelaation palkkayhtkokonaispalkkasarakkeen automaattiseen päivittämiseen eivät toimintaohjeet tarjoa keinoja. 3 Aktiivinen tietokanta ja tapahtuma-ehto-toiminta -sääntö Aktiivinen tietokanta (active database) on nimitys tietokannalle, joka aktiivisesti reagoi määrättyihin tietokannan sisäisiin tai ulkoisiin tapahtumiin. Sen sijaan, että tietokanta suorittaisi kyselyjä ja transaktioita ainoastaan käyttäjän tai sovellusohjelman eksplisiittisen ohjauksen mukaisesti, mahdollistaa aktiivisen tietokannan hallintajärjestelmä myös automatisoitujen ehtovartioitujen toimenpiteiden määrittelyn. Toimenpiteet pannaan täytäntöön ennalta määritellyn ehdon täytyttyä ja sisällöltään ne ovat erityisesti seurannaistransaktioiden suorittamista, eheyttä rikkovien transaktioiden peruutuksia ja ihmiskäyttäjän huomion herättämistä [SKS06]. Tietokantojen aktiiviset ominaisuudet ovat olleet tiedonhallintatutkimuksen merkittävimpiä tutkimuskohteita 1980-luvun lopulta lähtien [WiC96]. Tavanomaiseen passiviseen tietokantaan verrattuna aktiivisen tietokannan etu on nimenomaisesti aktiivinen, tapahtumaperustainen reagointi, joka passivisen tietokannan avulla toteutettuna edellyttäisi Elmasrin ja Navathen [ElN94] mukaan joko erillistä periodisesti tietokantaan kyselyjä suorittavaa ohjelmaa, joka samalla kun tietokantaa normaalisti päivittävät sovellusohjelmat suorittavat tilojen muutoksia tarkistaisi kerta toisensa jälkeen onko jokin monitoroitava tapahtuma tapahtunut, tai monitoroitavan tilan tarkistamisen lisäämistä erikseen jokaiseen tietokantaan päivityksiä tekevään sovellusohjelmaan. Aktiivisuus on vaikea toteuttaa toistuvien kyselyjen avulla, koska optimaalisen tahdin määrittely tehtäville kyselyille on vaikeaa. Tahdiltaan liian harva kysely voi
7 johtaa kriittisen tapahtuman käsittelyyn tarkoitetun aikajakson ohittamiseen, ja liian nopeatahtinen kyselyjen suorittaminen johtaa puolestaan järjestelmän suorituskyvyn romahtamiseen. Sovellusohjelmien räätälöinnin ongelmana on niiden hallittavuuden ja ylläpidettävyyden heikkeneminen. Aivan kuten deklaratiivisten eheysrajoitteidenkin kohdalla, tietokantaperustainen määrittely mahdollistaa keskitetyn sääntöjen hallinnan ja voimassaolon kaikissa niin nykyisissä kuin tulevissakin käyttötilanteissa, ad hoc -poikkeustilanteet mukaan lukien. Aktiivisen tietokannan toiminta perustuu tapahtuma-ehto-toiminta -sääntömalliin (ECA, event-condition-action) [LMC02]. Sääntömallin semanttinen toimintamalli on suoraviivainen: tapahtuma (event) aktivoi säännön, ehto (condition) evaluoidaan ja sen ollessa tosi... toiminta (action) suoritetaan. Tapahtuma kuvaa, milloin tietokannan tulee reagoida eli minkälainen tilamuutos ansalankamaisesti laukaisee säännön. Tapahtuman ilmenemisen jälkeen testataan toimenpiteisiin ryhtymisen ehdoksi asetettu ehto ja ehdon ollessa tosi suoritetaan määrätyt toiminnot. Ehdon ollessa epätosi ei toimintoa luonnollisestikaan suoriteta. Käytännössä säännöt ovat siis muotoa: ON EVENT IF CONDITION THEN ACTION. Yleisellä tasolla aktiivinen tietokanta tarkoittaa lähinnä vain tapahtumaperustaiseen reagointiin kykenevää tietokantaa. Dittrich ja Simon ovat kumppaneineen [DGG95, SiK95] esittäneet kuitenkin huomattavasti täsmällisempiäkin määritelmiä aktiiviselle tietokannalle: 1. Aktiivinen tietokanta on tavallinen tietokanta. Kaikki passiiviselta tietokannalta vaadittava toiminnallisuus vaaditaan myös aktiiviselta tietokannalta. Jos aktiivisia ominaisuuksia ei käytetä, tulee kannan toimia kuten passiivinen tietokanta.
8 2. Aktiivinen tietokanta mahdollistaa tapahtuma-ehto-toiminta -sääntöjen hallinnan ja määrittelyn. Reaktiivinen käyttäytyminen on käyttäjän määriteltävissä ECA-sääntöjen avulla. (a) Aktiivisella tietokannalla on keinot tapahtumien, ehtojen ja toimintojen määrittelyyn. Toimenpiteitä aiheuttavien tilanteiden tulee olla määriteltävissä tapahtuma-ehto-pareina, jotta pystytään määräämään, milloin toimenpiteisiin ryhdytään. (b) Aktiivinen tietokanta on mahdollistaa sääntöjen hallinnan. Uusia sääntöjä on pystyttävä lisäämään, vanhoja poistamaan ja olemassa olevia muokkaamaan. Säännöt on voitava kytkeä päälle tai pois. 3. Aktiivisella tietokannalla on suoritusmalli. Tapahtumien esiintymät on havaittava ja niihin liittyvät ehdot on oltava arvioitavissa. Sääntöjen suoritusjärjestyksen tulee olla ennalta määrätty. (a) Aktiivinen tietokanta havaitsee tapahtumien esiitymät. Tietokanta havaitsee eri tyyppiset tapahtumat ilman käyttäjän tai sovellusohjelman tekemää signalointia. (b) Aktiivinen tietokanta pystyy arvoimaan ehdon. Tapahtuman havaitsemisen jälkeen informaatio on pystyttävä välittämään ehto-osille ja ehdot on pystyttävä evaluoimaan. (c) Aktiivinen tietokanta pystyy suorittamaan toimintoja. Tapahtuman jälkeen ehto-osan ollessa tosi tiedot on pystyttävä välittämään ehto-osalta toiminta-osalle ja tietokannan tulee pystyä suorittamaan tapahtuman seurauksena toimeenpantavaksi määrätyt toiminnot. (d) Aktiivisella tietokannalla on määritelty suoritussemantiikka. Tapahtumien käsittely, tunnistaminen ja signalointi ovat hyvin määriteltyjä. Tulee olla määritelty, miten, milloin ja mitä tietokannan tilaan liittyviä ehtoja evaluoidaan ja mitä toimito-osia suoritetaan tietokannan asettamien rajoitusten mukaisesti. (e) Aktiivisen tietokannan sääntöjen suoritusjärjestys on käyttäjän määriteltävissä. Tietokannan on pystyttävä määrittelemään sääntöjen suoritusjärjestys, jos samaan tapahtumaan on sidottu useita sääntöjä. Simon ja Kotz-Dittrich [SiK95] korostavat myös, että ollakseen aktiivinen tietokannan tulee paitsi olla edellä mainitut aktiiviset ominaisuudet sisältävän tietokannan
9 hallintajärjestelmän tukema, myös käyttää automaattisia toimintoja hyväkseen: tietokantatuotteiden tarjoamat ominaisuudet eivät vielä yksinään tee tietokannasta aktiivista, vaan ominaisuuksien on oltava käytössä. Kuva 2: Aktiivinen tietokanta [ElN94]. Kuvassa 2 on esitetty aktiivisen tietokannan toiminta. 4 Tietokantaherätin Tietokantaherätin (trigger) on tietokantaproseduuri ja aktiivisen tietokannan toteutusmekanismi. Tietokantaherätin on miellettävissä tapahtuma-ehto-toiminta -säännön SQL-standardin mukaiseksi ilmentymäksi ja tietokantatason toteutukseksi. Herättimen laukaisevaksi tapahtumaksi määritetään tiettyyn tauluun tai sarakkeeseen kohdistuva ylläpito-operaatio (UPDATE-, DELETE- ja/tai INSERT -lause), ehdoksi tarvittaessa halutun kaltainen SQL-kielinen ehtolause ja ehdon täyttyessä suoritettäväksi toiminnoksi mielivaltainen SQL-lausejoukko. Herättimelle määritetään aktivaatioaika (activation time), joka määrää, suoritetaanko herättimen toiminto ennen vai sen jälkeen sen aktivoineen operaation: esiherätin (before trigger) suoritetaan ennen sen aktivoinutta ylläpito-operaatiota ja jälkiherätin (after trigger) vastaavasti vasta sen aktivoineen ylläpito-operaation jälkeen. Esiherättimet eivät voi muokata tietokannan sisältöä, vaan niitä käytetään ensisijaisesti ehtojen tarkistukseen ja siten eheysvalvontaan esimerkiksi tarkistamaan, kasvattaako ylläpito-operaatio työntekijän palkka-attribuutin arvoa yli 20 prosentilla ja estämään muutos tarvittaessa. Jälkiherättimet voivat sisältää toimintoinaan tietokantaa muokkaavia ylläpito-operaatioita ja siksi niille ominainen käyttötapa on
10 toimintalogiikkaa monipuolistavien automaattisten seurannaisoperaatioiden toteutus. Tilasiirtymäperustaisia tarkasteluja voidaan tietokantaherättimen ehto-osassa tehdä viittaamalla (referencing) siirtymämuuttujiin (transition variables) päivityksen jälkeiseen ja alkuperäiseen attribuutin arvoon sekä vertaamalla näitä toisiinsa [SKS06]. Jokaisella herättimellä on käytössään molemmat arvot sisältävät tilasiirtymätaulut (transition table) [CPM96], jolloin vertaaminen on varsin suoraviivaista. Tietokantaherättimen rakeisuus (granularity) määrää herättimen suorituskertojen lukumäärän. Rakeisuus voi olla joko lause- (statement-level) tai rivitasoinen (rowlevel). Lausetasoinen herätin suoritetaan kerran jokaista sen laukaissutta ylläpitooperaatiota kohden myös silloin, kun ylläpito-operaatio ei vaikuta yhteenkään monikkoon. Rivitasoinen herätin suoritetaan kerran jokaista ylläpito-operaation vaikutuksen kohteena ollutta monikkoa kohden, mutta jätetään suorittamatta kokonaan, jos vaikutuksenalaisia rivejä ei ole. Luvussa 1 esitetyssä kuvassa 1 hahmotellun kaltainen, yli 20 prosentin palkankorotuksen estävä herätintoiminto on määriteltävissä SQL-kielessä antamalla komento: CREATE TRIGGER palkkavalvonta BEFORE INSERT OR UPDATE OF palkka ON Työntekijä REFERENCING NEW AS uusi, OLD AS vanha FOR EACH ROW WHEN (uusi.palkka > 1.2 * vanha.palkka) SQLSTATE 75001 ( Palkka ei voi kasvaa yli 20 prosenttia. );. Määrittelylauseessa herättimelle annetaan nimi palkkavalvonta. Herätin määritellään ennen varsinaista ylläpito-operaatiota suoritettavaksi esiherättimeksi ja aktivoituvaksi Työntekijä-taulun palkka-attribuuttiin kohdistuvien INSERT- ja UPDATEoperaatioiden seurauksena. Ylläpito-operaation seurauksena muuttuneeseen riviin viitataan peitenimellä (alias) uusi ja vanhaan peitenimellä vanha. Herätin määritellään FOR EACH ROW -määreellä rakeisuudeltaan rivitasoiseksi, jolloin herätintoiminto suoritetaan erikseen jokaiselle alkuperäisen ylläpito-operaation vaikutuksen alaiselle riville. Herättimen ehto-osassa testataan onko uusi attribuutin arvoksi päivitettävä palkka yli viidenneksen suurempi kuin vanha palkka, ja ehdon ollessa tosi suoritetaan herättimen toiminto, joka tässä tapauksessa on IBM:n DB2-syntaksin [IBM06] mukainen transaktion peruuttava ja virheilmoituksen tulostava SQLSTA-
11 TE. Oraclen kohdalla toiminto voisi olla vastaavan lopputuloksen tuottava RAI- SE_APPLICATION_ERROR -proseduuri [AAC05]. Tietokantaherättimen edellä kuvatun kaltaisen määrittelyn jälkeen sen suorittamisesta aina määrätyn tapahtuman yhteydessä huolehtii tietokannanhallintajärjestelmä. Herättimen toiminnot suoritetaan tietokannassa herättimen määrittelijän käyttöoikeuksin eli käyttäjä, jonka ylläpito-operaatiot laukaisevat herättimiä, ei tarvitse mitään oikeuksia tauluihin, joita herätintoiminnot mahdollisesti muokkaavat. Tietokantaherätinmäärityksen voi kytkeä pois päältä ALTER TRIGGER palkkavalvonta DISABLE -komennolla ja lopullisesti poistaa DROP TRIGGER palkkavalvonta -komennolla [SKS06]. Luvun 2 taulukoissa 1 ja 2 esitetyssä esimerkkitietokannassa tietokantaherättimien avulla voidaan vapauttaa sovellusohjelmat Osasto-taulun palkkayht-attribuutin ylläpidosta määrittelemällä attribuutin arvo päivittymään automaattisesti. Tapahtumat, jotka voivat aiheuttaa muutoksia osaston palkkojen summan sisältävään attribuuttiin, ovat uuden työntekijän lisääminen henkilörekisteriin, olemassa olevan työntekijän palkan muokkaaminen, olemassa olevan työntekijän siirtäminen osastolta toiselle sekä työntekijän poistaminen henkilörekisteristä. Seuraavassa tarkastelemme toiminnallisuuden mahdollistavaa tietokantaherätinmäärittelyä [SKS06, IBM06, AAC05]. Uuden työntekijän lisääminen henkilörekisteriin Herätin määritetään aktivoituvaksi, kun Työntekijä-tauluun lisätään yksi tai useampia uusia rivejä. Rivin päivityksen jälkeiseen tilaan viitataan siirtymämuuttujan peitenimellä uusi. Rivitasoisen herättimen toiminnan ehdoksi määritellään, että uudella työntekijällä on oltava osasto, jotta palkkasumman muutos voidaan osoittaa oikealle osastolle. Herättimen toiminnaksi määritetään Osasto-tauluun kohdistuva UPDATE-operaatio, joka lisää työntekijän osaston palkkayht-attribuuttin arvoon henkilörekisteriin lisätyn työntekijän palkan. CREATE TRIGGER h1 AFTER INSERT ON Työntekijä REFERENCING NEW AS uusi FOR EACH ROW WHEN (uusi.osasto IS NOT NULL) UPDATE Osasto SET palkkayht = palkkayht + uusi.palkka
12 WHERE osasto = uusi.osasto; Olemassa olevan työntekijän palkan muokkaaminen Herätin määritetään aktivoituvaksi, kun työntekijän palkka-attribuutin arvoa muokataan. Laukaisevaa tapahtumaa seuraavaan ja sitä edeltäneeseen tilaan viitataan siirtymämuuttujilla uusi ja vanha. Toiminnan ehtona on muutoksen kohteena olevan henkilön osastomäärityksen poikkeaminen tyhjästä arvosta. Herättimen toimintana suoritetaan UPDATE-operaatio Osasto-tauluun, mikä sekä vähentää kokonaissummasta vanhan palkan että lisää siihen uuden. CREATE TRIGGER h2 AFTER UPDATE OF palkka ON Työntekijä REFERENCING NEW AS uusi, OLD AS vanha FOR EACH ROW WHEN (uusi.osasto IS NOT NULL) UPDATE Osasto SET palkkayht = palkkayht + uusi.palkka - vanha.palkka WHERE osasto = uusi.osasto; Olemassa olevan työntekijän siirtäminen osastolta toiselle osastolle Herätin määritetään aktivoituvaksi, kun työntekijän osasto-attribuutin arvoa muutetaan. Herättimelle ei määritetä ehtoa, vaan toiminto suoritetaan aina, kun herätin aktivoituu. Toiminnaksi määritetään kaksi SQL-lausetta, joista ensimmäinen lisää työntekijän palkan uuden osaston kokonaispalkkaan ja toinen vähentää palkan vanhan osaston kokonaispalkasta. CREATE TRIGGER h3 AFTER UPDATE OF osasto ON Työntekijä REFERENCING NEW AS uusi, OLD AS vanha FOR EACH ROW BEGIN UPDATE Osasto SET palkkayht = palkkayht + uusi.palkka WHERE osasto = uusi.osasto; UPDATE Osasto SET palkkayht = palkkayht - vanha.palkka
13 WHERE osasto = vanha.osasto; END; Työntekijän poistaminen henkilörekisteristä Herätin määritetään aktivoituvaksi, kun Työntekijä-taulusta poistetaan yksi tai useampia rivejä. Herättimen ehdoksi määritetään osasto-määrityksen olemassaolo poistettavalla henkilöllä. Herättimen toiminto on vähentää poistettavan henkilön palkka tämän osaston kokonaispalkasta. CREATE TRIGGER h4 AFTER DELETE ON Työntekijä REFERENCING OLD AS vanha FOR EACH ROW WHEN (vanha.osasto IS NOT NULL) UPDATE Osasto SET palkkayht = palkkayht - vanha.palkka WHERE osasto = vanha.osasto; Tietokantaherättimien määrittelysyntaksin voi huomata olevan täsmälleen luvussa 3 esitetyn tapahtuma-ehto-toiminta -säännön mukainen: ensin määritetään tapahtuma, jonka seurauksena herätin aktivoituu, sen jälkeen evaluoidaan WHEN-lauseen ehto, ja ehdon osoittauduttua todeksi suoritetaan herättimen toiminta. Tiivistettynä jo edellä pääpiirteittäin esitetyn määrittelysyntaksin eri variaatiot ovat lausuttavissa muodossa: CREATE TRIGGER <herättimen nimi> {BEFORE AFTER} {INSERT DELETE UPDATE} ON <taulu> [REFERENCING [NEW AS <uusi alias>] [OLD AS <vanha alias>]] [FOR EACH {ROW STATEMENT} [WHEN (<herättimen ehtolause>)]] <herättimen toiminta>. Määrittelysyntaksissa on järjestelmätoimittajakohtaisia eroavaisuuksia, joten täsmällinen muoto on syytä tarkistaa käytössä olevan tietokannanhallintajärjestelmän dokumentaatiosta.
14 Herättimiä määritettäessä on syytä muistaa niihin liittyvä problematiikka: automaattisia toimintoja suorittavat herättimet saattavat laukaista toisia herättimiä, jotka taas vuorostaan laukaisevat toisia. Yksinkertainen tietyn taulun INSERToperaatiosta aktivoituva herätin, joka toimintanaan lisää samaiseen tauluun uuden rivin generoimillaan arvoilla, aiheuttaa jo yksinään ikuisen kierteen, jossa jokainen lisäys aktivoi aina uuden lisäyksen. Tietokannanhallintajärjestelmissä on järjestelmätoimittajakohtaisia suojauksia, jotka sallivat vain tietyn määrän (esimerkiksi 32) iteraatioita, mutta ne eivät vähennä herättimien huolellisen suunnittelun merkitystä [SKS06]. 5 Herättimien ja deklaratiivisten rajoitteiden yhteistoiminta Tietokantaherättimet tulivat osaksi SQL-standardia vuonna 1999. Tarve aktiivisille toiminnoille oli ollut olemassa jo aiemmin, mikä oli johtanut 1990-luvulla järjestelmätoimittajien omiin herätintoteutuksiin [CPM96, SKS06]. Eri toimittajien ratkaisuja eivät ohjanneet mitkään standardit, mikä johti väistämättä niiden keskinäiseen yhteensopimattomuuteen. Viite-eheysrajoitteiden automaattisten vyörytystoimintojen ja tietokantaherättimien saumaton yhteenliittäminen osoittautui haasteelliseksi, minkä seurauksena järjestelmätoimittajakohtaisten herätinratkaisujen toiminta vyörytyssääntöjen rinnalla oli niin ikään varsin vaihtelevaa ja epäluotettavaa. IBM:n tutkijat esittivät vuonna 1996 artikkelissaan sittemmin standardiksi päätyneen ratkaisuehdotuksensa herättimien ja deklaratiivisten eheysrajoitteiden yhteistoiminnasta. Suoritusmalli on paitsi edellytys eri järjestelmätoimittajien tietokantaherättimien yhdenmukaiselle toiminnalle, on sen ymmärtäminen tarpeen tietokantasuunnittelijalle, tietokannan ylläpitäjälle sekä sovellusohjelmoijalle, joille voi muutoin olla epäselvää miten menetellään, kun esimerkiksi esiherättimen toiminto sisältää virheitä, mutta jälkiherätin on toimiva, tai kun jälkiherätin aktivoi toisen jälkiherättimen ja tämä vielä seuraavan, joka pyrkiikin lisäämään duplikaattipääavaimen tietokantatauluun. Kuvassa 3 esitetään tietokantatauluun muutoksia tekevän SQL-lauseen suoritusjärjestys aktiivisessa tietokannassa. Seuraavassa käydään läpi kuvassa mallinnettu Cochranen ja kumppaneiden [CPM96] esittämä suoritus vaiheittain. SQL-lause S 1 on suorituksen aloittava UPDATE-, DELETE- tai INSERT
15 Kuva 3: SQL-lauseen suoritus aktiivisessa tietokannassa [CPM96, IBM06]. -ylläpito-operaatio, joka yksilöi ylläpidettävän kohdetaulun (target table) eli muutosten kohteena olevan tietokantataulun. Vaikutuksen alaisten rivien määritys on suoritusprosessin ensimmäinen vaihe, jossa määritellään ylläpito-operaation ja sen seurannaisprosessien muutoksille alttiina olevien rivien joukko. Ylläpito-operaation muutoksille ovat alttiina muokkaus- ja poisto-operaation tapauksessa lauseen hakuehtoa vastaavat rivit ja lisäys-operaatiossa VALUES-lauseen yksilöimän rivit. Esiherättimien käsittely -vaiheessa kaikki SQL-lauseen S 1 seurauksena aktivoituneet esiherättimet suoritetaan tekojärjestyksessään. Rivitasoinen esiherätin suorittaa määrätyt toimenpiteet kerran jokaista vaikutuksen alaista riviä kohden. Lausetasoisen esiherättimen toiminto suoritetaan puolestaan tasan yhden kerran vaikutuksen alaisien rivien määrästä riippumatta. Esiherättimien toiminnot eivät voi muokata tietokannan sisältöä, joten ne eivät voi aiheuttaa vyöryviä toimenpiteitä tai laukaista toisia herättimiä. He-
16 rättimen toiminnoksi määritelty toimenpide voi kuitenkin sisältää virheitä ja sellaisen ilmetessä päädytään virhetilanteeseen (P), minkä seurauksena SQLlauseen S 1 suoritus peruutetaan (rollback). Vaikutuksen alaisten rivien kohdistus kohdetauluun tarkoittaa selkeämmin ilmaistuna S 1 :n ylläpitotoimenpiteiden täytäntöönpanoa. Toimenpiteitä tehtäessä huomioidaan rivitasoisten esiherättimien mahdollisesti muokkaamat toimet. Virhetilanteeseen johtaa muun muassa toistuvan rivin (duplicate row) lisäämisyrityksestä seurauksena oleva avainrajoitteiden loukkaus. Kuten kaikissa muissakin virhetilanteissa, sen seurauksena peruutetaan koko SQL-lause S 1 :n suoritus ja palataan sitä edeltäneeseen tilaan. Rajoitteiden tarkistus tarkoittaa S 1 :n aiheuttamien tilamuutosten arviointia avain-, viite-eheys- ja arvojoukkorajoitteiden kannalta. Jos vaikutuksen alaisia rivejä ei ole, vaihe ohitetaan. Viite-eheysrajoitteiden ON DELETE CASCA- DE- ja ON DELETE SET NULL -toimintaohjeet voivat aiheuttaa muiden herättimien aktivoitumisen. Mikä tahansa havaittu eheysrajoitteiden loukkaus aiheuttaa virheen ja siten S 1 :n peruuttamisen. Jälkiherättimien käsittely -vaiheessa kaikki SQL-lauseen S 1 seurauksena aktivoituneet jälkiherättimet suoritetaan tekojärjestyksessään. Lausetasoiset jälkiherättimet suoritetaan yhden kerran riippumatta vaikutuksen alaisten rivien määrästä. Rivitasoiset jälkiherättimet prosessoidaan kerran jokaista vaikutuksen alaista riviä kohden. Prosessoinnissa tapahtuva virhe johtaa S 1 :n suorituksen peruuttamiseen. Jälkiherättimien toimintoja voivat olla UPDATE-, DELETE- tai INSERT -operaatiot, jotka voivat tunnetusti aiheuttaa uusien herättimien aktivoitumisen. Vyöryvä SQL-lause tarkoittaa kuvassa 3 tällaista herätintoiminnon aktivoimaa herätintä. Vyöryvät SQL-lauseet käsitellään yksittäin rekursiivisesti jälkiherättimien käsittelyn yhteydessä. Jokaista vyöryvää SQL-lausetta kohden suoritetaan tässä luvussa kuvattu suoritusketju siten, että kukin uusi lause on miellettävissä omaksi S 1 :ksi. Kun kaikki jälkiherättimien toimintojen aktivoimat ylläpito-operaatiot on käyty rekursiivisesti läpi eikä virhetilanteeseen ole päädytty missään suorituksen vaiheessa, on alkuperäinen SQL-lause S 1 onnistuneesti suoritettu.
17 Huomion arvoista, että mikä tahansa virhe johtaa alkuperäistä operaatiota edeltäneen tietokannan tilan palauttamiseen. Täsmällisesti määritelty suoritusjärjestys ei salli mitään välimuotoja, eikä herätintoimintojen keskeneräinen suoritus siten ole mahdollinen: ylläpito-operaatio kaikkine seurannaisvaikutuksineen suoritetaan joko menestyksekkäästi tai jätetään kokonaan suorittamatta. 6 Tärkeitä sovellusalueita Monilla sovellusalueilla, kuten prosessin ohjauksessa, voimalaitoksissa ja sähkövoiman siirtoverkkojen hallinnassa, joissa tarvitaan tarkkaa vastetta aikakriittisiin tilanteisiin, ovat tietokannan tapahtumaperustaiset toiminnot välttämättömiä [ElN94]. Sovellusalasta riippumatta tietokantaherättimien avulla vastuuta ja taakkaa tietokannan määrämuotoisuudesta on siirrettävissä sovellusohjelmilta tietokannalle [SiK95]. Määrittelemällä toimintalogiikka tietokantatasoiseksi voi sovellusohjelmasta tehdä ohjelmistotuotannon näkökulmasta kevyemmän ja laadukkaamman: siirrettävämmän, uudelleenkäytettävämmän ja yhteentoimivamman. Kesken suorituksen kaatuva tietokannan eheydestä huolehtiva sovellusohjelma saattaa jättää tietokannan epätasapainoiseen tilaan, jonka eheyttäminen voi olla työlästä kun omasta eheydestään huolehtiva aktiivinen tietokanta sen sijaan huolehtisi määrämuotoisuudestaan itsenäisesti. Automaattiset toiminnot ovat varsin lavea käsite ja herättimiä voi käyttää hyvin moninaisiin tarkoituksiin. Ceri ja kumppanit [CCW00] listaavat lukuisia erilaisia tietokantaherättimien soveltamistapoja: 1. Eheyttä varjelevat herättimet (constraint-preserving triggers), jotka havaitsevat eheyttä uhkaavia operaatioita ja eheysrajoitteiden tavoin estävät niiden suorituksen kuten yli 20 % palkankorotuksen estävä tilasiirtymäperustainen esimerkkiherätin luvussa 4. 2. Eheyden palauttavat herättimet (constraint-restoring triggers), jotka havaitsevat eheyttä horjuttavia tilamuutoksia ja tekevät korjaavia operaatioita tietokantaan. 3. Kumoavat herättimet (invalidating triggers), jotka signaloivat havaitsemiaan eheysuhkia sovellusohjelmille mahdollistaakseen näiden reagoinnin niihin. 4. Yhteenvetoherättimet (materializing triggers), jotka luvun 4 esimerkkien ta-
18 voin laskevat johdettuja arvoja muiden attribuuttien arvoista esimerkiksi osaston työntekijöiden palkkojen summan tai kompleksisen tilastollisen testin lukemattomien arvojen perusteella. 5. Replikointiherättimet (replication triggers), jotka tuottavat reaaliaikaisesti varmuuskopioita ja lokitiedostoja tietokannan sisällöstä ja käytöstä. 6. Herätinlaajennokset (extenders), jotka validoivat tietokantaan tallennettavia syötteitä yksinkertaisimmillaan esimerkiksi korvaavat pelkän välilyönnin NULLarvolla. 7. Hälytinherättimet (alerters), jotka informoivat käyttäjää tietokannan tapahtumista. 8. Ad hoc -herättimet (ad-hoc triggers), jotka ovat toimialakohtaisia toimintalogiikka monipuolistavia toimintoja. Tutkijoiden viimeaikainen mielenkiinto on kohdistunut erityisesti aikaperustaisten tietyllä ajanhetkellä ja tietyin väliajoin aktivoituvien herättimien lisäämiseen SQLstandardiin. Behrend ja kumppanit [BDM09] katsovat aikaperustaisuuden moninaistavan herättimien käyttömahdollisuuksia huomattavasti entisestään. Nykystandardein tietokantaoperaatioiden ajastustoiminnot on tehtävä sovellusohjelmien laukaisemina, mutta artikkelissan Behrend kollegoineen ehdottaa herättimien tapahtumaehdon monipuolistamista SQL-standardiin. Ehdotuksen mukaan ehto voisi olla tiettyyn tauluun kohdistuvan tietokannan ylläpito-operaation lisäksi myös aikaleima ja tahtimääre, esimerkiksi FROM 2010-05-10 12:15 EVERY 7 DAYS, joka aktivoisi herättimien 10.5.2010 kello 12.15 ja sen jälkeen seitsemän vuorokauden välein. 7 Yhteenveto Aktiivinen tietokanta mahdollistaa tapahtumaperustaisten toimenpiteiden automaattisen suorittamisen passiivisen tietokannan edellyttäessä jokaiseen toimeensa käyttäjän tai sovellusohjelman eksplisiittistä pyyntöä. Aktiivinen tietokanta ei ole tavanomaisen tietokannan rinnalla kilpaileva konstruktio, vaan toiminnallisuutta automatisoinnin osalta laajentava, tapahtuma-ehto-toiminta -sääntömalliin perustuva keinovalikoima. Tietokantaherättimien tarjoama aktiivisuus ei ole käyttäjän näkökulmasta binäärinen on tai ei ole -suure, vaan toimintoja voi hyödyntää tarpeensa mukaan yk-
19 sinkertaisesta eheysvalvonnan monipuolistamisesta koko sovellusympäristöä kontrolloivaan automatisointiin asti. Herättimet tarjoavat miltei rajattoman keinopaletin tietokannan toimintojen automatisointiin, mutta oikotie onneen ne eivät ole. Herätintoimintojen suunnittelijalta edellytetään huolellista ja suunnitelmallista otetta sekä luvussa 5 esitetyn toimintaperiaatteen ymmärtämistä tarkoitusta palvelevia ratkaisuja tuottaakseen. Herättimien tarkoitus on sama kuin deklaratiivisten eheysrajoitteidenkin: pitää tietokanta eheässä ja toimintalogiikan kannalta tarkoituksenmukaisessa muodossa. Herättimien tässä tutkielmassa esitetty määrittelysyntaksi on varsin suoraviivainen ja esimerkit yksinkertaisia, mutta asiaa moniuloitteistaa se, että keinovalikoiman laajuus kumpuaa mielivaltaisesta SQL-lausejoukosta, joka on määriteltävissä herättimen toiminnoksi. Näin ollen tietokantaherättimien arvo käyttäjälle muotoutuu kyvystä yksilöidä automatisoitavat tarpeet ja valmiuksista pukea visionsa SQL-kielellä määriteltäviksi herättimiksi. Lähteet AAC05 BDM09 BMP01 CCW00 Cod70 Ashdown, L., Adams, D., Cowan, M., Moran, R., Melnick, J., Paapanen, E., Russel, J. ja Strohm, R., Oracle Database Application Developer s Guide Fundamentals, 10g Release 2. Oracle, 2005. Behrend, A., Dorau, C. ja Manthey, R., SQL triggers reacting on time events: An extension proposal. ADBIS 2009: Advances in Databases and Information Systems, 13th East European Conference. Proceedings, 2009, sivut 179 193. 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), 2001, sivut 405 423. Ceri, S., Cochrane, R. ja Widom, J., Practical applications of triggers and constraints: Success and lingering issues (10-year award). VLDB 00: Proceedings of the 26th International Conference on Very Large Data Bases, 2000, sivut 254 262. Codd, E. F., A relational model of data for large shared data banks. Commun. ACM, 13,6(1970), sivut 377 387.
20 CPM96 DGG95 ElN94 IBM06 LMC02 SiK95 SKS06 WiC96 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. Dittrich, K. R., Gatziu, S. ja Geppert, A., The active database management system manifesto: A rulebase of ADBMS features. RIDS 95: Second International Workshop on Rules in Database Systems, 1995, sivut 3 20. Elmasri, R. ja Navathe, S. B., Fundamentals of Database Systems. 2nd Edition. Benjamin/Cummings, 1994. IBM, DB2 version 9 for Linux, UNIX, and Windows. SQL reference volume 1, Yhdysvallat, 2006. Li, X., Marín, J. M. ja Chapa, S. V., A structural model of ECA rules in active database. MICAI 02: Proceedings of the Second Mexican International Conference on Artificial Intelligence, 2002, sivut 486 493. Simon, E. ja Kotz-Dittrich, A., Promises and realities of active database systems. VLDB 95: Proceedings of the 21st International Conference on Very Large Data Bases, 1995, sivut 642 653. Silberschatz, A., Korth, H. F. ja Sudarshan, S., Database System Concepts. Fifth Edition. McGraw-Hill, New York, 2006. Widom, J. ja Ceri, S., Active Database Systems: Triggers and Rules for Advanced Database Processing. Morgan Kaufmann, 1996.