Tietokannat Kevät 2009.

Tietokannat Kevät 2009

Kurssin järjestelyt Luennot, Erja Mustonen-Ollila
Harjoitukset, Erja Mustonen-Ollila Harjoitustyö, Erja Mustonen-Ollila SQL-Viope verkkokurssi, Erja Mustonen-Ollila Luentomateriaalin on alun perin laatinut Lasse Lehtimäki Kurssimoniste Aalefin kirjakaupasta, Erja Mustonen-Ollila Kurssipaketti ja luentomateriaali täydentävät toisiaan

Aikataulu 3. ja 4. periodilla
Johdatus tiedonhallintajärjestelmiin ja tietokantojen suunnitteluun Tietokannan suunnittelu jatkuu SQL –kielen perusteita Tietokannan suunnittelun vaiheita Vaativampia SQL –komentoja

Aikataulu 3. ja 4. periodilla
SQL ja QBE (Query By Example) Tietokannan suojaaminen Tapahtumakäsittely Varmuuskopiointi ja palautus, hakujen käsittely Tietokantojen hajauttaminen Katsaus oliotietokantoihin Tietojen varastointi

Kurssin kirjallisuus Luennot Kirjoja
Luentomoniste sama kuin viime vuonna Luentomoniste saatavana Aalef-kirjakaupasta Kirjoja Connolly, Thomas and Begg, Carolyn : Database Systems, A Practical Approach to Design, Implementation, and Management, 2nd Edition Date, C.J. : An Introduction to Database Systems, 7th Edition Elmasri, R. and Navathe, S.B. : Fundamentals of Database Systems, 3rd Edition

Tietokantojen historiaa
Juuret juontuvat 1950-luvun lopulle ja 1960-luvun alkuun. Ensimmäiset "tietokannat" olivat yksinkertaisia tiedostojärjestelmiä, joista puuttui keskitetty hallinta. Ensimmäiset varsinaiset tietokannat olivat hierarkisia tietokantasysteemejä, kuten esim. IMS ja System 2000. 1960 -luvun lopulla ja luvun alussa tulivat verkkotietokannat, kuten esim. Codasyl. Näissä oli vielä paljon puutteita, esim. tiedon etsiminen vaati monimutkaisten puumaisten rakenteiden läpikäyntiä. Suuri mullistus oli E.F. Codd:in julkistama relaatiomalli 1972. Käyttäjän kannalta relaatiomallin edut ovat sen yksinkertaisuus ja helppokäyttöisyys. Relaatiotietokannoissa on käytössä hakukieli, jolla ilmaistaan mitä tietoa halutaan, eikä miten tiedon löytää. 1970-luvun jälkeen on syntynyt monia kaupallisia relaatiotietokantoja, esim. Oracle, Sybase ja DB2.

Historiasta tähän päivään
Viime vuosikymmeninä on perinteisten kaupallisten sovellusalueiden lisäksi tietokantojen hallintajärjestelmät vallanneet alaa uusilta sovellusalueilta, kuten esim. CAD/CAM CASE Paikkatietojärjestelmät (GIS, Geographical Information Systems) Lääketieteen informaatiojärjestelmät Multimedia Näille sovelluksille tyypillisiä piirteitä ovat esim. tiedon monimutkaisuus ja monimuotoisuus, tiedon suuri määrä sekä tietokantaoperaatioiden monimuotoisuus. Sisältävät kuvaa, ääntä ja tekstimuotoista tietoa. Näille uusille sovellusalueille uusia tietomalleja ovat semanttiset tietomallit ja oliotietokannat. Relaatiotietokantojen jälkeen on alkanut kiinnostus siirtyä seuraaviin: Oliotietokannat Älykkäät tietokannat

Johdatus tiedonhallintaan
Esimerkki yksinkertaisesta tietokannasta

Yksinkertainen tietokanta
Yksinkertaisimmillaan tietokanta on automatisoitu kortisto. Tietokantaan kohdennettavat toiminnot ovat: Uuden tietueen lisäys INSERT INTO VARASTO (ID, MERKKI, MALLI, KORI, MOOTTORI, VM, ML, HINTA) VALUES (31, "Volvo", "740 GL 2.3 A", "S4", 2.3, 1990, , 79500); Tietueiden haku tietokannasta SELECT MERKKI, MALLI, VM, HINTA FROM VARASTO WHERE VM < 1993 AND HINTA < ; Tietueiden päivitys UPDATE VARASTO SET MITTARILUKEMA = , HINTA = WHERE ID = 31; Tietueiden poisto DELETE FROM VARASTO WHERE ID = 31;

Mikä on tiedonhallintajärjestelmä?
Tietokanta on paikka, johon talletetaan käyttökelpoista tietoa. Tiedonhallintajärjestelmä (THJ, DBMS, Database Management System) on joukko ohjelmia, jotka mahdollistavat tietokannan keskitetyn luonnin ja ylläpidon. Tietokannan määrittelyprosessissa määritellään, minkä tyyppistä tietoa tietokantaan talletetaan. Tietokannan rakentamisprosessissa tehdään varsinainen tietokanta. Tietokannan käsittelyprosessissa tietoa päivitetään ja haetaan. Esimerkki edellä autoliikkeestä, jossa erilaisia vaihtoautoja. Operaatiot, joita tarvitaan tietokantaan: uusien tiedostojen lisäys uusien automerkkien lisäys olemassa olevan tiedon päivitys: muutos, lisäys ja poisto erilaisten kriteerien mukaisen tiedon haku tiedostosta

Mitä tiedonhallintajärjestelmässä on?
Tiedonhallintajärjestelmä voi olla yksi- tai monikäyttöjärjestelmä. Tieto tietokannassa voi olla sekä integroitua että jaettua. Integroitu tieto: tietokanta koostuu erillisistä tiedostoista, joissa päällekkäisyys (redundancy) on osittain tai kokonaan eliminoitu. Jaettu tieto: usea käyttäjä voi käyttää samoja tietoja eri tarkoituksiin, käyttö voi olla samanaikaista (concurrency). Käyttäjät näkevät tietokannan eri tavoin käyttötarpeesta riippuen (näkymät, views). Tiedonhallintajärjestelmä koostuu: tiedosta (integroitu, jaettu) ohjelmista (DBMS) raudasta (levyt) käyttäjistä (sovellusohjelmoija, loppukäyttäjä, tietokannan hoitaja)

Kuka tarvitsee tiedonhallintaa?
Tyypillisiä käyttäjiä Tuotantoyritys, pankki, sairaala, yliopisto ja valtion virasto Tyypillistä tietoa: Tuotteisiin liittyvä tieto, tilitiedot, potilastiedot, opiskelijatiedot ja suunnittelua tukevat tiedot Tiedon muoto ja erilaiset tietotyypit: "Perinteinen" tieto on merkkityyppistä tietoa. Se koostuu perustietotyypeistä, kuten luvuista ja merkeistä. Uusia sovellusalueita, jotka sisältävät lisäksi esim. kuvaa ääntä Uusia vaatimuksia tietomallille ja tiedonhallintajärjestelmälle

Joitakin käsitteitä Käsitemalli (entity-relationship model) on perustana tiedon käsitteistämisessä. Käyttötieto koostuu olioista (entities) ja niiden välisistä suhteista (ralationships). Olioita ovat esim. tuottajat ja työntekijät yrityksessä. Olioiden ominaisuuksia ovat esim. työntekijän nimi ja ikä. Käsitteiden väliset suhteita ovat: yksinkertaiset, binääriset ja ternääriset suhteet.

Tietokantasysteemin etuja
Tiedon keskitetty hallinta. Tietojen päällekkäisyys vähenee tai on hallittua. Tiedon ristiriitaisuus (inconsistency) voidaan välttää. Useampi käyttäjä voi käyttää tietoa, myös samanaikaisesti. Standardointi on helpompaa. Tietojen käyttöoikeudet voidaan varmistaa. Tietojen luotettavuus ja oikeellisuus on parempi. Järjestelmää rakennettaessa voidaan ottaa eri käyttötarpeet huomioon. Uusien sovellusten käyttöönotto helpompaa. Tarjoaa tiedon varmistukseen ja toipumiseen mekanismit.

Tietokantojen haittoja
Kalleus lyhyellä tähtäimellä THJ:t melko raskaita ja joskus jopa monimutkaisia Toiminnan riippuvuus tietokannasta (esim. lehtiyhtiö)

Käytä tiedostoratkaisua seuraavissa
Tietokanta ja sovellukset yksinkertaisia, hyvin määriteltyjä ja melko muuttumattomia. Esimerkiksi hyvin yksinkertainen kortisto, jossa tietokantaan tulisi vain yksi taulu. Aikavaatimus on suuri. Järjestelmä yksinkertainen, jolloin tietokannan rakentaminen vie enemmän aikaa kuin tiedostoratkaisu. Tietoon ei tarvita useamman käyttäjän pääsyä. Ei tarvita monen käyttäjän ympäristöä. Tietojen oltava kuitenkin yksinkertaisia, jotka eivät sisällä monimutkaisia relaatioita.

Tiedonhallintajärjestelmän arkkitehtuuri
Suosituin tapa kuvata THJ-arkkitehtuuria on ns. ANSI/SPARC -ehdotus standardiksi (vuonna 1978). ANSI = American National Standards Institute SPARC = Standards Planning and Requirements Committee Arkkitehtuuri jakautuu kolmeen tasoon: Sisäinen taso (Internal level) Käsitteellinen taso (Conceptual level) Ulkoinen taso (External level)

Ulkoinen taso Yksittäisen käyttäjän taso Sovellusohjelmoija:
käytössä kieli, jossa osana on ns. Tietoalikieli (Data sublanguage, DSL) tietokantaan kohdistuvat käskyt Data definition language (DDL) tiedon määrittelyyn ja kuvaukseen Data manipulation language (DML) tiedon käsittelyyn Loppukäyttäjä: käyttöliittymä (valikot, kaavakkeet yms.)

Käsitetaso Kaikille käyttäjille yhteinen taso
Erillään fyysisestä talletuksesta Erillään ulkoisesta tasosta

Sisäinen taso Kuvaa todellisia talletettuja tietueita
Kuvaa myös indeksit (B-puut, hajautus) Ei kuitenkaan fyysinen taso, joka kuvaa sivut, lohkot, sylinterit, urat ja sektorit

Kuvaukset tasojen välillä
Käsitetaso  Sisäinen taso Esittää käsitetason ja sisäisen tason tietueiden vastaavuudet Kertoo, kuinka käsitetason tietueet talletetaan sisäisellä tasolla Jos sisäinen taso muuttuu, tulee kuvausta muuttaa Ulkoinen taso  Käsitetaso Eri käyttäjillä näkemyksiä -> erilaisia kuvauksia tasojen välillä Tietojen esitystapojen muunnokset

DBA (Database Administrator, tietokannan hoitaja)
Päättää tietokannan sisällöstä Päättää talletustavasta ja käsittelystrategiasta Valtuuttaa käyttäjät Määrittää turvallisuusasiat Toipuminen ja palautus Suorituskyvyn tarkkailu ja tarvittavien muutosten tekeminen Työkaluja: tietokannan luonti dump/restore tiedon uudelleenjärjestely tietokannassa tilastolliset rutiinit esim. tiedostojen koko analyysirutiinit Tietohakemisto (Data Dictionary) "Data about data", "metadata" sisältää talletettuna kaaviot ja kuvaukset tiedon ohjelmista, käyttäjistä

Johdatus tietokantoihin
Käyttäjän ei tarvitse tietää tiedon fyysisiä talletusrakenteita, vaan hänellä on ulkoinen näkemys (external view) talletettuun tietoon. THJ:n on tuettava tätä näkemystä sovelluksesta toiseen (ns. tietoriippumattomuus, data independence) Tietomalleja Hierarkinen malli Verkkomalli Relaatiomalli Semattiset tietomallit: ER-malli Oliopohjainen tietomalli

Hierarkinen tietomalli
Organisoi tiedon puurakenteeksi. Tietokanta muodostuu tietueista, jotka ovat erillisten puiden muodostamassa metsässä. Tietueiden väliset suhteet (1:N) kuvataan linkkien välillä. Kullakin tietueella on täsmälleen yksi isätietue. Seuraavassa esimerkki käsitekaaviosta: Asiakas -tunnus -nimi -osoite Osto -asiakas -tuote -määrä Tuote -numero -nimi -hinta

Hierarkinen esitystapa edellisestä

Tyypillisiä kyselyjä (query)
Q1: Etsi niiden asiakkaiden nimet, jotka ostavat tuotetta 08 DO UNTIL ei enää asiakkaita tuotteella; ota seuraava asiakas tälle osalle; tulosta asiakasnumero; END; Q2: Etsi niiden tuotteiden numerot, joita ostaa asiakas nimeltä Miettinen DO UNTIL ei enää tuotteita; ota seuraava tuote; ota seuraava asiakas tämän tuotteen alla, jonka nimi on Miettinen; IF löytyy THEN tulosta tuote; END; Huom! Algoritmien epäsymmetria.

Verkkomalli Kuten hierarkisessa mallissa, tietueet ovat solmuja ja niiden välisiä kytkentöjä. Esimerkissä kolmenlaisia tietueita: asiakas, tuote ja yhdistäjät näiden välillä. Yhdistäjät ketjuissa (silmukoissa). Kaikki tiettyyn asiakkaaseen liittyvät tuotteet ovat silmukassa, joka alkaa asiakkaalta ja loppuu samaan asiakkaaseen.

Q1: Ota seuraava tuote, jonka numero on 01; DO UNTIL ei enää yhdistäjiä tämän tuotteen alla; ota seuraava yhdistäjä tämän tuotteen alla; ota asiakas tämän yhdistäjän yllä; tulosta asiakas; END; Q2: Ota seuraava asiakas, jonka nimi on Miettinen; DO UNTIL ei enää yhdistäjiä tämän asiakkaan alla; ota seuraava yhdistäjä tämän asiakkaan alla; ota tuote tämän yhdistäjän yllä; tulosta tuote; Huom! Algoritmit ovat symmetriset.

Relaatiomalli Relaatiomalli koostuu vain tauluista eli relaatioista.
Tauluissa on rivejä (tuple) ja sarakkeita eli attribuutteja (ominaisuuksia). Relaatio Asiakas Asiakastunnus Nimi Osoite A2 Heikkinen Alakylä 18 A5 Mutikainen Yläkylä 1 Mattila Yläkylä 10 A9 Miettinen Rapakatu 13

Relaatiomalli jatkuu Relaatio Tuote Relaatio Osto Tuotenumero Nimi 01
Ruuvi 02 Pultti 08 Maalitölkki Tuotenumero Asiakastunnus Määrä 01 A2 20 A5 50 A8 10 02 2 5 A9 3 08 1

Q1: Ota seuraava tuote, jonka numero on 01; DO UNTIL ei enää ostoja ota seuraava osto, missä tuotteen numero on 01; tulosta asiakas taulusta tätä ostoa vastaava asiakasnimi; END Q2: Etsi niiden tuotteiden numerot, joita ostaa asiakas nimeltä Miettinen DO UNTIL ei enää ostoja ota seuraava osto, missä asiakas on Miettinen; tulosta tuote taulusta tätä ostoa vastaava tuotenimi; END;

Sisäinen taso ja talletusrakenteet
Sisäisellä tasolla kuvataan, kuinka tieto on todellisuudessa tallennettu. Yleensä tieto tallennetaan levylle, josta hakuaika suurempi kuin keskusmuistista. Tavoitteena on levyhakujen lukumäärän minimointi. Tiedon talletustapa vaikuttaa hakujen määrään. Fyysisen tietokannan suunnittelu Tiedon järjestystä levyllä kutsutaan tiedon fyysiseksi talletusrakenteeksi. Talletusrakenteen valinta vaatii tietoa: tietokannan käyttötavoista sovelluksista käytön määrästä

Tietokantahaun periaate
THJ pyytää tiedostonhallintajärjestelmää hakemaan tietueen. Tiedostonhallintajärjestelmä selvittää, millä sivulla haluttu tietue on. Tiedostonhallintajärjestelmä pyytää ko. sivun levynhallintajärjestelmältä. Sivu on I/O yksikkö - tiedon määrä, joka siirretään levyn ja muistin välillä yhdellä levyhaulla. Tyypillinen sivun koko on 1024, 2048 tai 4096 tavua. Levynhallintajärjestelmä määrittää sivun sijainnin levyllä ja tekee tarvittavat I/O toiminnot.

Levynhallintajärjestelmän tehtäviä
Osa käyttöjärjestelmää (Basic I/O System). Tuntee fyysiset levyosoitteet (sylinteri, ura, sektori). Levynhallintajärjestelmä ohjaa tiedostonhallintajärjestelmää, joka näkee levyn joukkona sivuja. Jokaiselle joukolle sivuja on oma tunniste (page set ID). Jokaisella sivulla on sivunumero. Levynhallintajärjestelmä pitää yllä kuvausta: sivunumero  fyysinen levyosoite Perusoperaatiot sivuille: Hae sivu p joukosta s Päivitä sivu p joukossa s Lisää uusi sivu p joukkoon s Poista sivu p joukosta s

Tiedostonhallintajärjestelmän tehtäviä
Kuuluu joko käyttöjärjestelmään tai tiedonhallintajärjestelmään. Tiedostonhallintajärjestelmän käyttäjä näkee levyn joukkona tiedostoja. Tiedostoilla on tunniste (File ID), tietueilla numero (Record ID). Tuntee tiedostojen ja tietueiden sivujoukot ja sivut. Perusoperaatioita ovat: Hae talletettu tietue r talletetusta tiedostosta f. Päivitä talletettu tietue r talletetusta tiedostosta f. Lisää tietue r tiedostoon f ja palauta uusi ID. Poista tietue r talletetusta tiedostosta f. Luo uusi tiedosto f. Tuhoa tiedosto f.

Relaatiomalli Relaatiomalliin liittyviä termejä: Suom. käsite
Eng. käsite Selite taulu, taulukko, relaatio relation attribuutti attribute sarake, ominaisuus rivi, monikko tuple rivi arvoalue, arvojoukko domain perusavain, primääriavain primary key pääavain avainehdokas candidate key viiteavain, vierasavain foreign key taulun aste table degree sarakkeiden lkm taulun koko cardinality rivien lkm skeema schema malli näkymä view käyttäjän näkemys

Relaatiotietokannat Tietokanta on loogisesti yhtenäinen kokoelma tietoa, jolla on jotain sille ominaisesti kuuluva tarkoitus. Tietokanta on suunniteltu, rakennettu ja täytetty tiedoilla tiettyä tarkoitusta varten. Käyttäjäryhmät ovat tiedossa, samoin sovellukset. Esittää osaa reaalimaailmasta. Tietokannalla on tietomalli, joka esittää miten tieto näkyy käyttäjälle (ANSI/SPARC arkkitehtuurin ulkoinen taso). Relaatiotietokanta on tietokanta, joka näkyy käyttäjälle kokoelmana tauluja (ja ainoastaan tauluja). Codd esitti relaatiomallin 1970 –luvulla.

Relaatioiden välinen yhteys, tiedonkäsittely
Relaatio-operaatiot kohdistuvat tauluihin. Relaatioalgebran operaatioita ovat: yhdiste, leikkaus, erotus, tulo, valinta, projektio, liitos ja jako. Relaatiokalkkyyli määrittelee formalismin, jonka mukaan operaatiot suoritetaan (perustuu predikaattilogiikkaan). Tiedon käsittelykieliä (query languages), jotka toteuttavat ralaatioalgebran ja relaatiokalkkyylin, ovat esim. SQL - Structured Query Language QUEL – Ingres QBE - Query By Example, IBM DB2 QBF - Query By Form Focus - 4 GL OLE - On-Line-English

Tiedon eheys Eheys tarkoittaa tiedon ristiriidattomuutta ja oikeellisuutta. Tavoitteena on estää tietokannan tietojen sellainen käsittely, joka johtaa ristiriitaisuuksiin tietokannan tietosisällössä. Eheyssäännöt määritellään tietokannan skeemassa. On olemassa neljänlaisia eheyssääntöjä, joista kolme ensimmäistä liittyy pääavaimeen ja viiteavaimeen: Avaineheys: avainehdokkaiden tulee olla yksikäsitteisiä jokaiselle riville. Käsitteellinen eheys: pääavaimen arvo ei saa olla NULL. Yhteyseheys: viittauksen toisesta relaatiosta toiseen relaatioon täytyy olla viittaus olemassaolevaan tietoon. Semanttiset eheyssäännöt, esim. työntekijän palkka ei saa olla suurempi kuin hänen esimiehensä palkka. THJ ylläpitää eheyssääntöjä.

Arvoalue (Domain) Atomiset ja yhdistetyt arvoalueet
Lähellä ohjelmointikielten tietotyyppejä. Esim. Pascal -kielessä type month = (1..12); var palkkakausi: month; ‘month’ on arvoalue, jolle ominaisuus ‘palkkakausi’ ts. ‘palkkakausi’ on tyyppiä ‘month’. Atomiset ja yhdistetyt arvoalueet Jos tietyn ominaisuuden arvoja ei voida järkevästi jakaa, niin arvo on atominen ja ko. attribuutin arvoalue on atominen. Esim. tuottaja -esimerkissä tuottajan sukunimi on atominen. Atomisten arvoalueiden karteesinen tulo (D1 x D2 x D3 x D4 x … x Dn) on yhdistetty arvoalue. Esim. Asiakas - Tuote –esimerkissä Asiakkaan nimi on atomisten alueiden etunimini ja sukunimi karteesinen tulo.

Relaatio (Relation) Relaatio koostuu otsikosta ja sisällöstä.
Otsikko koostuu joukosta ominaisuuksia (attribuutteja) A1, A2, … An, siten, että ne vastaavat alueita D1, D2, … Dn. Sisällössä on joukko (monikkoja) rivejä, jotka koostuvat ominaisuus-arvo -pareista (A1:v1), i = 1,…,n, missä vi<Di. Relaation R ominaisuuksia ovat: Samaa vaakariviä ei esiinny useaan kertaan. Jokaisella rivillä on yksikäsitteinen pääavain. Monikkojen (vaakarivien) järjestyksellä ei ole väliä. Haettaessa rivejä voidaan tulos järjestää halutun sarakkeen mukaisesti. Kaikki ominaisuusarvot ovat atomisia, tätä kutsutaan 1. normaalimuodoksi. Esimerkiksi etunimi ja sukunimi täytyy erottaa omiksi sarakkeikseen. Relaation ominaisuuksilla ei ole järjestystä. Tietojen tallennus ei voi perustua sarakejärjestykseen.

Perusavain (Primary key)
Relaation perusavain on yksikäsitteinen tunniste kyseiselle relaatiolle. Perusavain voi olla yhdiste useammasta relaation ominaisuudesta (kuitenkin harvinainen). Perusavainehdokkaita voi olla useampia, mutta lopulta tehtävä valinta, mistä tehdään perusavain ja muut ehdokkaat ovat nk. toissijaisia avaimia.

Määritelmä avainehdokkaille
Relaation R ominaisuus K on avainehdokas, jos se toteuttaa seuraavat ajasta riippumattomat vaatimukset: Yksikäsitteisyys (Uniqueness) Relaatiosta R ei löydy minään ajanhetkenä arvoa ominaisuudelle K. Minimaalisuus (Minimality) Jos ominaisuus K on useamman ominaisuuden yhdistelmä, niin mitään osaa ominaisuudesta K ei voida poistaa rikkomatta yksikäsitteisyyden periaatetta. Perusavain tuottaa tavan viitata relaation riveihin. Viittaus on tyypiltään assosiatiivinen ei osoitteellinen. Ainoa varma tapa etsiä joku tietty rivi on etsiä sitä perusavaimen perusteella. Kaikilla relaatioilla on vähintään yksi avainehdokas. Perusavain on oleellinen relaatiotietokannan toimimiseksi.

Avainhakuesimerkki Haku pääavaimen mukaan:
select * from P where P# = ‘P3’; Tämä haku antaa tulokseksi enintään yhden rivin, kun taas haku select * from P where city = ‘Paris’; antaa tulokseksi mahdollisesti useampia rivejä.

Viiteavain (Vierasavain, Foreign key)
Viiteavaimella kuvataan viittauksia toisesta relaatiosta toiseen eli relaatiotietokannan taulujen välisiä yhteyksiä (yhden suhde yhteen, yhden suhde moneen ja monen suhde moneen). Viiteavain on taulun R2 ominaisuus tai ominaisuusyhdistelmä, jonka arvot ovat samat kuin pääavaimella relaatiossa R1. R1 ja R2 voivat olla yksi ja sama taulu.

Skeema (Schema) Relaatiotietokannan skeema S on joukko relaatioita S = {R1, R2,…,Rm} ja joukko eheyssääntöjä IC. Relaatiotietokantajoukon ilmentymä DB joukosta S on joukko relaation ilmentymiä DB = {r1, r2,…rm} siten, että ri on joukon Rj ilmentymä ja että ri:t noudattavat eheyssääntöjä, jotka on määritelty joukossa IC. Kaikki tuotteet eivät välttämättä tue skeemojen käyttöä.

Näkymä (View) Sovellusohjelmilla ja käyttäjillä on tarve nähdä relaatio hieman erilaisena kuin se todellisuudessa on. He voivat katsella relaatiota johdettujen (laskettujen) relaatioiden, eräänlaisten virtuaalirelaatioiden kautta. Joku käyttäjä ei voi nähdä joitakin relaation ominaisuuksia esim. työntekijän palkkaa. Käyttäjän tarve tietoon on vain osa-alue koko organisaation tarpeesta. Näkymä ei ole pysyvästi talletettu tietokantaan, vaan THJ tallentaa kuvauksen, jolla näkymä on tehty. Näkymien päivitys normaalirelaatioiden päivityksen yhteydessä ja toisinpäin ? Ongelmaksi muodostuu tilanne, jolloin ko. ominaisuutta ei kaikista näkymistä löydykään. Kaksi mahdollisuutta ratkaista ongelma: Hylätään operaatiot ei määritellyille ominaisuuksille. Korvataan null-arvot: kaikki vertailut, joiden tuloksena null –arvo katsotaan epätosiksi.

Coddin säännöt Codd E.F., 1985 “12 sääntöä tietokannoille”
Relaatiotietokannan THJ:n tulee pystyä hallitsemaan tietokanta käyttämällä vain relaatio-ominaisuuksia. Relaatiotietokannan kaikki tieto esitetään loogisella tasolla ja arvoina tauluissa. Kaikki atomiset arvot löytyvät taulun nimen, perusavaimen ja sarakkeen perusteella. NULL -arvot esitetään kuvaamaan puuttuvia tietoja systemaattisesti, riippumatta tietotyypistä. Tietokannan kuvaus tehdään samaan tapaan kuin muunkin tiedon kuvaus. Tiedon määrittely, luonti ja haku (DDL, DML) on muodostettava yksi DSL, joka käsittää seuraavat toimet: tiedon määritys näkymien määritys tiedon käsittely eheyden käsittely valtuutukset tiedonsiirron rajoitukset (pysyvä tieto vai ei)

Coddin säännöt Codd E.F., 1985 “12 sääntöä tietokannoille”
Näkymien päivitys oltava mahdollista (Näkymien päivitys) Haun lisäksi tulee tauluun voida kohdistaa toiminnot lisäys, päivitys ja poisto (Korkean tason tiedon lisäys, muutos ja poisto). Päätetyöskentely tai sovellusohjelmat eivät muutu vaikka tiedon fyysinen esitystapa muuttuu (Fyysisen tiedon riippumattomuus). Päätetyöskentely tai sovellusohjelmat eivät muutu vaikka tiedonsäilyttäviä muutoksia tehdään tietokannan tauluihin (Loogisen tiedon riippumattomuus). Eheysrajoitteet määritetään DSL:ssä ja talletetaan tietokannan tauluihin (Eheys-riippumattomuus). Tiedon käsittely on samanlaista olipa tieto keskitetty tai hajautettu (Hajautus-riippumattomuus). Alemman tason tiedonkäsittely ei voi kiertää ylemmän tason määrityksiä.

Relaatioalgebra Relaatiomallin tiedonkäsittely koostuu kahdesta osasta: Joukko operaatioita Sijoituslause Määritetään joukko operaatioita, joilla tehdään uusi haluttu relaatio olemassa olevasta relaatiosta Esim. C := A È B, jossa A, B ja C ovat relaatioita ja È on unioni. Syöttötietona on yksi tai kaksi relaatiota (tai useampia), tuloksena on yksi uusi relaatio. Relaatioalgebra koostuu joukosta joukko-opillisia operaatioita, jotka käsittelevät relaatioita. Perinteiset joukko-opilliset relaatiot: Yhdiste (union) Leikkaus (intersect) Erotus (difference, minus) Tulo, karteesinen tulo (cartesian product)

Relaatioalgebra Erityiset relaatio-operaatiot:
Valinta (selection) Projektio (projection) Liitos (join) Jako (division) Yhdistetyt relaatiokuvaukset ovat joukko relaatio-operaatioita, joissa yhden operaation tuloksesta muodostuu toisen operaation syöte esim. otetaan projektio unionista, liitetään kaksi erotusta.

Yhdiste ja leikkaus Yhdiste Leikkaus
A È B = { monikko t | t Î A Ú t Î B } Vaatimukset: A:n ja B:n aste on sama (=n) (attribuuttien lukumäärä). A:n ja B:n i:nsillä attribuuteilla on yhteinen määrittelyalue (i=1,…,n). Leikkaus A Ç B = { monikko t | t Î A Ù t Î B } Vaatimukset ovat samat kuin yhdisteellä.

Erotus ja tulo Erotus Tulo A - B = { monikko t | t Î A Ù t Ï B }
Vaatimukset ovat samat kuin edellä. Tulo A ´ B = { monikko (t, s) | t Î A Ù s Î B } Ei ole samaa vaatimusta kuin edellä. Yhdiste, leikkaus, erotus ja tulo -operaatiot toteuttavat liitännäislain (associativity).

Valinta (R where F) sF(R) = { monikko t | t Î R Ù ehto F on tosi }
F on ominaisuusarvoja koskeva ehto, joka on muotoa “t.X vertailu t.Y”. “vertailu” on X:n ja Y:n määrittelyalueeseen sopiva vertailuoperaatio (=, ~, <, >, jne.). F voi olla myös muotoa “t.X vertailu vakio”. Syntaksi on siis: R where R.X vertailu R.Y. Siis: niiden R:n monikkojen joukko, jotka toteuttavat annetun ehdon. Ehto F voi olla myös muotoa “F1 and F2”. Tuloksena tulevalla relaatiolla on samat ominaisuudet kuin R:llä. Valinta kohdistuu monikkoihin (riveihin).

Projektio (R[X,…]) Õ X, Y, …, Z(R) = { (x, y, …, z) | $ t Î R, jossa x = X, y = Y, z = Z } Syntaksi on R[X, Y, …, Z] Siis poimitaan ominaisuuksia X, Y, …, Z vastaavat sarakkeet R:stä. Poistetaan redundantit rivit.

Liitos (Join (A times B) where F)
FA ¥ B = { monikko (t, s) | t Î A Ù s Î B Ù ehto F on tosi } Siis karteesiseen tuloon A ´ B kohdistettu valinta FA ¥ B = sF((A ´ B) F on samanlainen kuin valintaoperaatiolla, mutta veraa A:n ja B:n ominaisuuksia, siis muotoa "t.X vertailu s.Y", t Î A, s Î B. Jos F on "t.X = s.Y" on kyseessä tasaliitos "equijoin". Jos tasaliitoksessa hävitetään vielä toinen samoista attribuuteista (projektiolla), saadaan luonnollinen liitos (natural join), jota merkitään A JOIN B.

Esimerkki liitoksesta
Olkoon A:n ominaisuudet A.A1, …, A.Am ja B:n ominaisuudet B.B(m+1), …, B.B(m+n). Olkoot li, …, lj attribuutit A:n ja B:n yhteiset attribuutit. Olkoot Br, …, Bs ne B:n attribuutit, jotka jäävät B:stä jäljelle, kun joukosta { B(m+1), …, B(m+n) } vähennetään li, …, lj. Nyt A JOIN B on (A TIMES B) [A.A1, …, A.Am, B.Br, …, B.Bs] WHERE A.li = B.li AND … AND A.lj = B.lj Yleisesti liitos tarkoittaa luonnollista liitosta. Liitännäislaki toteutuu.

Jako (Divideby) X ÷ B = { monikko t | $ s Î B pätee (t, s) Î X }
Jako on karteesisen tulon vastaoperaatio: jos X := A ´ B, niin A = X ÷ B. Jos jaettava X asetta m+n ja jakaja B astetta n tulos A astetta m Tuloksena A siis niiden X:n monikkojen alkuosat, jotka esiintyvät kaikkien B:n monikkojen kanssa.

Huomioita relaatioalgebrasta
Perusoperaatioita ovat valinta, projektio, tulo, unioni ja erotus. Johdettuja operaatioita ovat liitos, jako ja leikkaus. Tavoitteena on mahdollistaa kyselyjen teko relaatiotietokannasta. Codd: minkä tahansa relaatiokielen on tarjottava ainakin relaatioalgebran voima kyselyihin (ralaatiotäydellisyys, relational completeness). Relaatioalgebra ei ole erityisen käyttäjäystävällinen. Algebraa käytetään usein vertailun pohjana, kun vertaillaan kyselykielten voimaa. Relaatio-operaatio lausekkeet tarjoavat korkean tason symbolisen esitysmuodon tietokannasta. Hyvä perusta hakujen optimoinnille.

Tietokannan suunnittelu
Tietokannan suunnittelu on osa systeemityötä. Tietokannan suunnittelu painottaa enemmän tietojen suunnittelua kuin sovellusten ja niiden toimintojen suunnittelua => tietokeskeinen näkökulma. Suunnitellaan yhden tai useamman tietokannan looginen ja fyysinen rakenne, joilla toteutetaan organisaation henkilöiden tietotarpeet tiettyjä sovelluksia käyttäen. Tietokannan suunnittelun tavoitteet ovat moninaiset: tietosisältö käyttäjien ja sovellusohjelmien kannalta tiedon esittämistapa tiedon käsittelyn vaatimukset: vasteaika, prosessointiaika, tilantarve

Tietokannan suunnittelu
Sama tieto voidaan esittää erilaisilla tietorakenteilla. Tavoitteena on tietokantarakenne, joka toteuttaa seuraavat vaatimukset: suunnittelun tuloksena tietorakenne, joka on 'oikea' siinä mielessä, että se kuvaa hyvin toimintayksikön 'tietoavaruutta' tietokannan oltava yhtenäinen ja ristiriidaton tietokantaa voi käyttää moni sovellus tai käyttäjäryhmä. Tietojen hallinnan tulee tapahtua kuitenkin yhtenäisesti mitä tarpeita käyttäjillä prioriteetit käyttäjille sovellusten tärkeysjärjestys avainhenkilöiden haastattelut: tiedon merkityksellisyys vakiotavat tiedonkeräykseen

Tulokset Vaatimukset kuvattuna sanallisesti tai jollain formalismilla
Tietokantaan talletettava tieto, tietojen väliset suhteet Käyttäjien näkymät tietoon Operatiiviset vaatimukset turvallisuus, eheys, vaste-aika, varmuuskopiot, pysyvä talletus, kasvumahdollisuudet Tietohakemisto kuvataan kukin yksittäinen tieto millainen tieto ja millainen käyttö Tiedon määrä ja käyttö, tietovirrat kuinka paljon tietoa tiedon käyttö kyselyt, päivitykset

Käsiteanalyysi Käsiteanalyysin kohteena voi olla koko toimintayksikkö tai rajattu pienempi alue. Kohdealuetta kutsutaan reaalimaailmaksi. Käsiteanalyysin tuloksena syntyy kohdealuetta kuvaava looginen malli, käsitemalli. Yleensä käsitemalli esitetään graafisesti käsitekaaviona ja täydennetään tietokuvauksin. Jäsentävä lähestymistapa Malli luodaan ensin karkealla tasolla, sitten edetään näkökulmittain tarkempiin asioihin. Lopuksi yhdistetään näkökulmat yhdeksi malliksi.

Hyödyt Auttaa suunnittelijoiden ja käyttäjäryhmien vlisessä viestinnässä. Auttaa asian jäsentämisessä. Selkeyttää ja yhtenäistää käytettävää käsitteistöä. Tieto- ja toteutusriippumattomat tietokantaratkaisut. Käsiteanalyysin pohjana on ER -malli.

Tiedonhallintajärjestelmän valinta
Sopiiko ko. tiedonhallintajärjestelmä kyseessä olevan tehtävän suoritukseen? tietomalli, kuinka hyvin onnistuu muunnos käsitemallista tietomalliksi? talletusrakenteet, hajautus käyttöliittymät näkymät ohjelmointiympäristö kyselykieli Vaikuttavat taloudelliset seikat Tietomallin valinta hierarkkinen tietomalli verkkotietomalli relaatiotietomalli oliotietomalli Tiedonhallintajärjestelmän arkkitehtuuri

ER-malli, käsitteistö Oliotyypit (Entity Types)
Oliotyyppi on objekti tai käsite, jolla on muista riippumaton ilmentymä Olio on jonkin oliotyypin ilmentymä, joka voidaan yksilöidä Heikko (Weak) oliotyyppi on riippuvainen jostakin toisesta oliotyypistä tai useammasta Vahva (Strong) oliotyyppi ei ole riippuvainen muiden oliotyyppien olemassaolosta Attribuutit (Attributes) Attribuutti on olio- tai yhteystyypin ominaisuus Attribuutin arvoalueella (Domain) tarkoitetaan niitä arvoja, joita ko. attribuutti voi saada Yksinkertainen attribuutti (Simple attribute) sisältää yhden riippumattoman komponentin Yhdistelmäattribuutti (Composite attribute) sisältää useita komponentteja, jotka ovat riippumattomia Yksiarvoinen attribuutti (Single-valued attribute) sisältää vain yhden arvon yhdelle oliolla Moniarvoinen attribuutti (Multi-valued attribute) sisältää useita arvoja yhdelle oliolle Johdettu attribuutti (Derived attribute) sisältää arvon, joka on johdettu toisesta attritbuutista tai attribuuttijoukosta, jotka eivät välttämättä kuulu samaan olioon

ER-malli, käsitteistö Avaimet (Keys) Yhteystyypit (Relationship Types)
Avainehdokas (Candidate key) on attribuutti tai joukko attribuutteja, jotka yksikäsitteisesti yksilöivät oliotyypin ilmentymän Pääavain (Primary key) on avainehdokas, joka on valittu yksilöimään olion. Yhdistelmäavain (Composite key) on avainehdokas, joka koostuu kahdesta tai useammasta attribuutista Yhteystyypit (Relationship Types) Yhteystyypit (lyhyesti yhteydet, relationships) yhdistävät oliotyypit toisiinsa mielekkäällä tavalla Yhteyden aste kertoo, kunka monta oliota on ko. yhteydellä yhdistetty toisiinsa Rekursiivinen yhteys tarkoittaa sellaista yhteyttä, jossa sama oliotyyppi esiintyy useammin kuin kerran eri rooleissa

Rakenteelliset pakotteet (Structural Constraints)
Peruspakotteet (Cardinality Constraints) Perussuhde (Cardinality ratio) kuvaa mahdollisten yhteyksien määrää jokaiselle osallistuvalle oliolle Perussuhde on yleensä binäärinen, jonka muotoja ovat yksi-yksi (1:1), yksi-monta (1:M) ja monta-monta (M:N) Osanottopakotteet (Participation Constraints) Osanottopakotteilla kuvataan olion esiintymisen riippuvuutta toisesta oliosta yhdistettynä yhteyden avulla Osanottopakotteita voi olla kahta tyyppiä: täydellinen (total) tai osittainen (partial) Täydellinen tarkoittaa sitä, että esim. ostotapahtumaa ei voi olla ilman asiakasta so. ostotapahtumassa asiakastieto on välttämätön Osittainen tarkoittaa sitä, että esim. ostotapahtumasta voi puuttua asiakastieto, jolloin tapahtuman asiakas on tuntematon.

SQL -kielen perusteita
Tietokannan määrittely Tietokannan käsittely Apufunktiot

Tietokannan määrittely
CREATE TABLE (perusta taulu) CREATE TABLE taulun_nimi (sarake_nimi tietotyyppi [NULL | NOT NULL] [, …]) taulun_nimi on perustettavan taulun nimi sarake_nimi on tauluun perustettan sarakkeen nimi tietotyyppi on sarakkeen tietotyyppi, joka on jotain tietokannan hyväksymää tietotyyppiä NULL -määreellä määritellään, että sarake voi sisältää tyhjän arvon NOT NULL -määreellä määritellään, että sarakkeella on pakko olla jokin arvo ALTER TABLE (muuta taulua) Tähän palataan myöhemmin vaativamman SQL:n luvussa DROP TABLE (poista taulu + rivit) DROP TABLE taulun_nimi taulun_nimi on poistettavan taulun nimi

Tietokannan määrittely
CREATE VIEW (perusta näkemys) Tähän palataan myöhemmin vaativamman SQL:n luvussa DROP VIEW (poista näkemys) CREATE INDEX (perusta indeksi) CREATE [UNIQUE] INDEX indeksin_nimi ON taulun_nimi (sarake_nimi [ASC | DESC] [, …]) UNIQUE -määreellä määritellään indeksi yksilöiväksi indeksiksi indeksin_nimi on indeksille annettava nimi taulun_nimi on sen taulun nimi, johon indeksi luodaan sarake_nimi kertoo, mihin sarakkeisiin indeksi kiinnitetään ASC -määreellä määritellään indeksi nousevaan järjestykseen DESC -määreellä määritellään indeksi laskevaan järjestykseen DROP INDEX (poista indeksi) DROP INDEX indeksin_nimi indeksin_nimi on poistettavan indeksin nimi

Tietokannan käsittely
SELECT (hae) SELECT [DISTINCT | ALL] {* | [sarakemäärittely[AS uusi_nimi]] [, …]} FROM taulun_nimi [synonyymi] [, …] [WHERE ehto] [GROUP BY sarake_lista] [HAVING ehto] [ORDER BY sarake_lista] DISTINCT -määreellä poistetaan hakutuloksesta duplikaatit (samanlaiset rivit) ALL -määreellä saadaan haettua duplikaatit liitoksissa * -määreellä saadaan haettua kaikkien sarakkeiden arvot sarakemäärittelyssä kerrotaan, mitä sarakkeita hakuun sisällytetään AS -määreellä saadaan haetuille sarakkeille määriteltyä uusi otsikko FROM -osassa määritellään taulut, joista haetaan synonyymi tarkoittaa taululle annettua synonyymiä, jota voidaan käyttää sarakkeiden yksilöintiin WHERE -osassa kerrotaan hakua rajaavat hakuehdot GROUP BY -osassa kerrotaan, miten haetut tiedot ryhmitellään HAVING -osassa kerrotaan, mitä ehtoja ryhmiteltyjen tietojen tulee täyttää, jotta ne tulisivat hakutulokseen ORDER BY -osassa kerrotaan, miten hakutulos lajitellaan

Tietokannan käsittely
UPDATE (päivitä) UPDATE taulun_nimi SET sarake_nimi = arvo [, …] [WHERE ehto] vain ne rivit päivitetään, joihin WHERE -kohdassa oleva ehto pätee DELETE (poista) DELETE FROM taulun_nimi [WHERE ehto] vain ne rivit poistetaan, joihin WHERE -kohdassa oleva ehto pätee INSERT (lisää) INSERT INTO taulun_nimi [(sarake_lista)] VALUES (arvo_lista) molemmissa listoissa tulee olla sama määrä alkioita listojen täytyy vastata alkioiden järjestyksen suhteen toisiaan listojen tietotyyppien tulee vastata toisiaan

Apufunktiot AVG (keskiarvo) SUM (summa) MIN (minimi) MAX (maksimi)
Palauttaa tietyn sarakkeen arvojen keskiarvon SUM (summa) Palauttaa tietyn sarakkeen arvojen summan MIN (minimi) Palauttaa tietyn sarakkeen arvoista pienimmän MAX (maksimi) Palauttaa tietyn sarakkeen arvoista suurimman COUNT (lukumäärä) Palauttaa tietyn sarakkeen arvojen lukumäärän

Esimerkkejä SQL -lauseista
Taulun luonti tietokantaan SQL> create table l_kurssitieto ( 2 nimi varchar2(20) not null, 3 kurssi number); Table created.

Indeksin luonti luodulle taululle ja sen testaus SQL> create unique index pk_kurssitieto 2 on l_kurssitieto (nimi asc, kurssi desc); Index created. SQL> insert into l_kurssitieto (nimi, kurssi) 2 values ('lasse',1740); 1 row created. SQL> insert into l_kurssitieto (nimi, kurssi) 2 values ('lasse',1740); insert into l_kurssitieto (nimi, kurssi) * ERROR at line 1: ORA-00001: unique constraint (SCOTT.PK_KURSSITIETO) violated SQL> insert into l_kurssitieto (nimi, kurssi) 2 values ('lasse',1511); 1 row created.

Indeksin poisto taulusta SQL> drop index pk_kurssitieto; Index dropped. Taulun poisto SQL> drop table l_kurssitieto; Table dropped.

Taulun määrityksen haku ORACLE:ssa SQL> desc emp Name Null? Type EMPNO NOT NULL NUMBER(4) ENAME VARCHAR2(10) JOB VARCHAR2(9) MGR NUMBER(4) HIREDATE DATE SAL NUMBER(7,2) COMM NUMBER(7,2) DEPTNO NUMBER(2)

Taulun tietojen haku (projektio) SQL> select empno, ename, job, deptno 2 from emp; EMPNO ENAME JOB DEPTNO SMITH CLERK ALLEN SALESMAN WARD SALESMAN JONES MANAGER MARTIN SALESMAN BLAKE MANAGER CLARK MANAGER SCOTT ANALYST KING PRESIDENT TURNER SALESMAN ADAMS CLERK JAMES CLERK FORD ANALYST MILLER CLERK MILLER PUMMI rows selected.

Rivin lisäys tauluun ja uusien tietojen haku SQL> insert into emp (empno, ename, job, deptno) 2 values (7777, 'LEHTIMÄKI', 'INSTRUCTO', 10); 1 row created. SQL> select empno, ename, job, deptno 2 from emp; EMPNO ENAME JOB DEPTNO SMITH CLERK ALLEN SALESMAN WARD SALESMAN JONES MANAGER MARTIN SALESMAN BLAKE MANAGER CLARK MANAGER SCOTT ANALYST KING PRESIDENT TURNER SALESMAN ADAMS CLERK JAMES CLERK FORD ANALYST MILLER CLERK MILLER PUMMI LEHTIMÄKI INSTRUCTO rows selected.

Taulun tietojen päivitys ja haku SQL> update emp set 2 job = 'INSTR.', 3 sal = where empno = 7777; 1 row updated. SQL> select empno, ename, job, sal, deptno 2 from emp 3 where empno = 7777; EMPNO ENAME JOB SAL DEPTNO LEHTIMÄKI INSTR

Taulun tietojen poisto SQL> delete from emp 2 where empno = 7777; 1 row deleted.

Apufunktioiden käyttö SQL> select sum(sal), min(sal), max(sal), avg(sal) 2 from emp; SUM(SAL) MIN(SAL) MAX(SAL) AVG(SAL) SQL> select sum(sal) as yhteensa, 2 min(sal) as minimi, 3 max(sal) as maksimi, 4 avg(sal) as keskiarvo 5 from emp; YHTEENSA MINIMI MAKSIMI KESKIARVO SQL> select count(*) from emp; COUNT(*)

Tietojen ryhmittely SQL> select deptno, count(*) 2 from emp 3 group by deptno; DEPTNO COUNT(*)

Tietokannan suunnittelu Jako osaprosesseihin
Käsitteellinen tietokannan suunnittelu Prosessi, jossa luodaan tietomalli reaalimaailman käsitteistä Luotu tietomalli on riippumaton kaikista fyysisistä ratkaisuista Looginen tietokannan suunnittelu Prosessi, jossa luodaan tietomalli reaalimaailman käsitteistä perustuen spesifiin tietomalli –käsitteeseen Luotu tietomalli on riippumaton tiedonhallintajärjestelmistä ja muista fyysisistä ratkaisuista Fyysinen tietokannan suunnittelu Prosessi, jossa tehdään kuvaus tietokannan rakenteesta tietylle tiedonhallintajärjestelmälle Luotu tietomalli kuvaa tiedon rakenteen tietokannassa, käytettävät metodit tiedon hyödyntämiseen

Käsitteellinen taso Ensin luodaan jokaisen käyttäjän paikallinen käsitteellinen tietomalli Etsitään oliotyypit Etsitään yhteystyypit Etsitään attribuutit sekä oliotyypeille että yhteystyypeille Määritellään attribuuttien arvoalueet Määritellään avainehdokkaat ja perusavaimet Tarkennetaan oliotyyppejä Piirretään ER –malli Käydään saatu käsitteellinen tietomalli käyttäjien kanssa läpi

Looginen taso Rakennetaan jokaiselle käyttäjälle oma paikallinen looginen tietomalli Yhdistetään käyttäjän käsitteellinen tietomalli loogiseen tietomalliin Luodaan yhteydet loogiseen tietomalliin Normalisoidaan saatu tietomalli Varmennetaan saadun mallin kelpoisuus käyttäjän tarpeisiin Piirretään ER –malli Määritellään eheysrajoitteet Käydään saatu looginen tietomalli käyttäjien kanssa läpi Rakennetaan globaali looginen tietomalli Yhdistetään käyttäjien kanssa rakennetut loogiset tietomallit globaaliksi loogiseksi tietomalliksi Varmennetaan globaalin tietomallin toimivuus Tarkistetaan tulevaisuuden kasvumahdollisuudet Piirretään lopullinen ER –malli Käydään saatu yleinen looginen tietomalli käyttäjien kanssa läpi

Fyysinen taso Käännetään yleinen looginen tietomalli käytettävälle tiedonhallintajärjestelmälle Suunnitellaan perusrelaatiot käytettävälle tiedonhallintajärjestelmälle Suunnitellaan rajoitukset THJ:lle Suunnitellaan fyysinen esitys Analysoidaan tietovirrat Valitaan tiedostojärjestelmä jokaiselle oliotyypille Suunnitellaan toissijaiset indeksit Arvioidaan tarvittava levytila Suunnitellaan suojausmekanismit Suunnitellaan käyttäjien näkymät Suunnitellaan käyttöoikeudet Tarkkaillaan ja viritetään kunnossa olevaa järjestelmää

Käsitteellinen tietokannan suunnittelumetodi
Etsitään oliotyypit (käsitteet) Ensin etsitään ne objektit, joista käyttäjä on eniten kiinnostunut Nämä objektit ovat oliotyyppejä mallissa Etsitään substantiiveja (työntekijä, työntekijän nimi, asunto, osoite) Etsitään myös suurempia kokonaisuuksia (henkilö, koti) Ryhmitellään löydetyt substantivit (kotiin kuuluu asunto ja osoite) Aina ei ole selvää, onko löydetty objekti itse käsite vai sen ominaisus (naimisissa voi olla käsite, ominaisuus tai yhteys kahden käsitteen välillä) Etsitään yhteystyypit Käsitteiden löytämisen jälkeen etsitään ne yhteydet, jotka yhdistävät eri käsitteet toisiinsa Etsitään verbejä, jotka liittyvät kahteen käsitteeseen ja näin yhdistää niitä (osastolla on työntekijöitä) Usein yhteys on binäärinen eli liittää kaksi käsitettä toisiinsa, mutta täytyy huolellisesti tarkastella myös sellaiset mahdollisudet, että yhteys muodostuu useammasta käsitteestä kuin kahdesta tai vain yhden käsitteen sisältävä rekursiivinen yhteys Määritellän, onko yhteys 1:1, 1:M vai M:N (huom! Pakollisuus)

Käsitteellinen tietokanan suunnittelumetodi
Etsitään attribuutit sekä oliotyypeille että yhteystyypeille Etsitään substantiiveja, jotka liittyvät käsitteeseen tai yhteystyyppiin Etsitään vastausta kysymykseen, mitä tietoja tarvitaan käsitteestä tai yhteystyypistä Attribuuttien etsimisessä on huomioitava, onko kyseessä yksinkertainen attribuutti vai kokoelma-attribuutti Kokoelma-attribuutit eritellään yksinkertaisiksi attribuuteiksi Attribuuteista dokumentoidaan nimi, selite, synonyymit, tietotyyppi, pituus, oletusarvot, pakollisuus (null/not null), kokoelma-attribuuteista ne attribuutit, joista se koostuu, perityn attribuutin laskentatapa, ja moniarvoisuus

Käsitteellinen tietokanan suunnittelumetodi
Määritellään attribuuttien arvoalueet Arvoalueella rajoitetaan niitä arvoja, joita attribuutti voi saada Monella attribuutilla voi olla sama arvoalue Määritellään avainehdokkaat ja perusavaimet Etsitään kaikki mahdolliset avainehdokkaat Valitaan yksi avainehdokas pääavaimeksi Avainehdokas on sellainen attribuutti tai joukko attribuutteja, jotka yksikäsitteisesti yksilöivät käsitteen jokaisen ilmentymän Jos avainehdokkaita on useita, niistä valitaan vain yksi pääavaimeksi Jäljelle jääneet avainehdokkaat ovat toissijaisia avaimia Pääavaimen valinnassa huomioitavaa: Pienin mahdollinen attribuuttimäärä Avainehdokkaan arvoa ei tarvitse muuttaa usein (ollenkaan) Avainehdokas ei menetä yksikäsitteisyyttä tulevaisuudessa Avainehdokas sisältää pienimmän määrän tekstitietoa Avainehdokas, jota käyttäjän näkymästä on helpointa käyttää

Käsitteellinen tietokannan suunnittelumetodi
Tarkennetaan oliotyyppejä (valinnainen) Määritellään vanhempi-lapsi oliotyypit (luokkahierarkia) Tähän palataan tarkemmin oliomallin yhteydessä Piirretään ER –malli Piirretään ER -malli käyttäjän määrittelemien käsitteiden ja niihin liittyvien ominaisuuksien perusteella ER -malleja tulee yksi jokaista käyttäjää / käyttäjäryhmää kohden ER -malli perustuu käyttäjän näkemykseen tulevan järjestelmän rakenteesta Käydään saatu käsitteellinen tietomalli käyttäjien kanssa läpi Saatu malli käydään vielä perusteellisesti käyttäjän (erikseen jokaisen käyttäjän / käyttäjäryhmän) kanssa läpi niin, että käyttäjälle jää käsitys, että malli on oikea hänen näkökulmastaan katsottuna Lopputuloksena saadaan ER -malli ja dokumentti, joka kuvaa tietomallin käsitteellisellä tasolla

Looginen tietokannan suunnittelumetodi
Yhdistetään käyttäjän käsitteellinen tietomalli loogiseen tietomalliin Poistetaan käsitteellisestä tietomallista sellaiset objektit, jotka eivät ole toivottuja Poistetaan M:N yhteystyypit Poistetaan kompleksiset yhteystyypit (kolme tai useampi käsite) Poistetaan rekursiiviset yhteystyypit Poistetaan yhteystyypit, jotka sisältävät attribuutteja Poistetaan moniarvoiset attribuutit Tarkistetaan 1:1 yhteydet ja poistetaan tarpeettomat käsitteet Poistetaan ylimääräiset yhteystyypit; jos jokin yhteystyyppi on mahdollista kuvata muilla yhteystyypeillä, on ko. yhteystyyppi tarpeeton

Luodaan yhteydet loogiseen tietomalliin Luodaan yhteydet käyttäjän käsitteellisen tietomallin mukaan Aloitetaan attribuuttien lisääminen vahvoista oliotyypeistä Puretaan kokoelma-attribuutit yksinkertaisiksi attribuuteiksi Määritellään pääavaimet vahvoille oliotyypeille Jatketaan attribuuttien lisäämistä heikoista oliotyypeistä Lisätään vierasavaimiksi vahvan oliotyypin pääavain Määritellään pää- ja vierasavaimet heikoille oliotyypeille

Normalisoidaan saatu tietomalli Normalisoimalla saadaan poistettua funktionaaliset riippuvuudet Normalisointi auttaa ymmärtämään paremmin jokaista attribuuttia, joka on tietomalliin kirjoitettu 1NF poistaa toistot ja ryhmäattribuutit 2NF poistaa osan riippuvuudet muista kuin pääavaimesta 3NF poistaa epäsuorat riippuvuudet muista kuin pääavaimesta BCNF poistaa jäljellä olevat funktionaaliset riippuvuudet Varmennetaan saadun mallin kelpoisuus käyttäjän tarpeisiin Käydään käyttäjän kanssa hänen käyttötarpeensa läpi Katsotaan yksityiskohtaisesti jokainen käyttäjän tarvitsema toiminto Tietojen lisäykset ja niiden järjestys Tietojen poisto ja niiden mahdollinen poistojärjestys Tietojen päivittäminen Tietojen haku

Piirretään ER –malli Piirretään lopullinen ER -malli käyttäjän yksittäisen käyttäjän näkökulmasta ER -malleja tulee yksi jokaista käyttäjää / käyttäjäryhmää kohden ER -malli perustuu käyttäjän näkemykseen tulevan järjestelmän rakenteesta sen jälkeen, kun malli on normalisoitu Määritellään eheysrajoitteet Mitkä tiedot ovat pakollisia ja mitkä eivät Attribuuttien arvoaluerajoitteet määritellään Oliotyypin yhtenäisyys; pääavaimessa ei saa olla NULL -arvoja Viite-eheys; vierasavaimena oleva attribuutti täytyy löytyä peritystä oliotyypistä pääavaimena Lisäys perittyyn oliotyyppiin => tarkistus Poisto peritystä oliotyypistä => ei ongelmia Päivitys perittyyn oliotyyppiin => tarkistus Lisäys perittävään oliotyyppiin => ei ongelmia Poisto perittävästä oliotyypistä => tarkistus Päivitys perittävään oliotyyppiin => tarkistus

Määritellään eheysrajoitteet Viite-eheys; vierasavaimena oleva attribuutti täytyy löytyä peritystä oliotyypistä pääavaimena, poistossa eri mahdollisuuksia NO ACTION => poisto ei ole sallittu CASCADE => poistetaan kaikki perityt oliotyyppien ilmentymät SET NULL => ei-pakollisissa yhteyksissä merkitään peritty attribuutti NULL -arvoiseksi SET DEFAULT => ei-pakollisissa yhteyksissä merkitään peritty attribuutti oletusarvoiseksi NO CHECK => mitään tarkistuksia ei tehdä Sisältörajoitteet; tietojen yhteneväisyys todellisen maailman kanssa so. vain sellaiset arvot ovat sallittuja, jotka ovat todellisuudessa mahdollisia Käydään saatu looginen tietomalli käyttäjien kanssa läpi Tehdään tietovirtakaavio, jonka tulee olla yhdenmukainen loogisen tietomallin kanssa Tietovirtakaaviolla kuvataan tietojen lisäykset, muutokset ja poistot ja niiden vaikutukset eri oliotyyppeihin

Yhdistetään käyttäjien kanssa rakennetut loogiset tietomallit globaaliksi loogiseksi tietomalliksi Tarkastellaan oliotyyppien nimiä ja niiden perusavaimia Sama nimi eri oliotyypeillä Eri nimi samaa tarkoittavilla oliotyypeillä Tarkastellaan yhteystyyppien nimiä Yhdistetään käyttäjäkohtaisista malleista oliotyypit, jotka merkitsevät samaa Yhdistetään ne oliotyypit,joilla on sama nimi ja sama perusavain Yhdistetään ne oliotyypit, joilla on sama nimi mutta eri perusavain Yhdistetään ne oliotyypit, jotka ovat eri nimisiä mutta joilla on sama (tai eri) perusavain Lisätään ne oliotyypit, jotka ovat vain tietyssä käyttäjämallissa Yhdistetään käyttäjäkohtaisista malleista yhteystyypit, jotka merkitsevät samaa Lisätään ne yhteystyypit, jotka ovat vain tietyssä käyttäjämallissa Etsitään puuttuvat oliotyypit ja yhteystyypit Tarkistetaan vierasavaimet Tarkistetaan eheyssäännöt Piirretään yleinen looginen tietomalli Päivitetään dokumentteja Varmennetaan globaalin tietomallin toimivuus Vastaava tarkistus kuin aikaisemmissa vaiheissa (käyttäjien kanssa käydään läpi malli ja todetaan sen toteuttavan käyttäjän tarpeet)

Tarkistetaan tulevaisuuden kasvumahdollisuudet Onko malliin jätetty mitään mahdollisuuksia laajentaa sitä? Uusien vaatimusten lisääminen, miten hoidetaan Pitää miettiä mallia siltä kannalta, että loppukäyttäjän näkemä järjestelmä muuttuu mahdollisimman vähän järjestelmään tulevien lisäominaisuuksien seurauksena Piirretään lopullinen ER –malli Kun ollaan varmistuttu siitä, että yleinen malli kattaa kaikkien eri käyttäjätyyppien tarpeet, voidaan piirtää lopullinen ER –malli Myös kaikki dokumentit on päivitettävä yleisen mallin mukaiseksi Käydään saatu yleinen looginen tietomalli käyttäjien kanssa läpi Varmistetaan ER –mallin avulla ja dokumentteja tarkastellen, että jokainen käyttäjäryhmä tuntee vähintään sen osan mallista, jota tulee käyttämään Käyttäjiltä tulee saada hyväksyntä mallille

Fyysinen tietokannan suunnittelumetodi
Suunnitellaan perusrelaatiot käytettävälle tiedonhallintajärjestelmälle Jokaiselle yleisessä loogisessa tietomallissa olevalle relaatiolle mietitään Relaation nimi Lista yksinkertaisista attribuuteista Perusavain ja mikäli tarpeellista, niin toissijaiset ja vierasavaimet Eheyssäännöt vierasavaimille Jokaiselle attribuutille mietitään Arvoalue sisältäen tietotyypin, pituuden ja mahdolliset rajoitteet Mahdollinen oletusarvo attribuutille Voiko attribuutti sisältää NULL –arvon Miten attribuutti on peritty (jos on) ja miten se lasketaan Päätetään relaatioiden esitystapa; tämä riippuu THJ:n tarjoamista vaihtoehdoista 1992 ISO SQL standardin (SQL2) mukaisesti Käytetään liipaisufunktioita (triggers) Jätetään eheyssäännöt sovelluksen huoleksi Käytetään yksilöiviä indeksejä (unique indexes)

Suunnitellaan rajoitukset THJ:lle Rajoitteet voidaan toteuttaa THJ:n tarjoamilla välineillä Jos THJ toteuttaa täysin SQL2:n mukaiset määrittelyt, voidaan rajoitteet määritellä tämän mukaisesti Mikäli SQL2:n mukaisia määrityksiä ei voida tehdä, mutta THJ tarjoaa mahdollisuuden luoda liipaisufunktioita, voidaan näiden avulla toteuttaa samat rajoite-ehdot kuin standardin mukaisella määritelmälläkin Näillä rajoitteilla estetään sellaisten tietojen tallentaminen tai tietojen muuttaminen, joka ei ole yhtenevä todellisen maailman kanssa Rajoitteet voivat perustua jo olemassa olevaan tietoon, jolloin arvoaluemäärittelyt tai vierasavainmäärittelyt eivät vielä ole riittäviä rajoitteita tallennettavalle tiedolle

Seuraavat asiat tulee ottaa huomioon, ennen kuin jatketaan Tapahtumien (transactions) määrä tietyssä ajassa Vasteaika, yksinkertaisen tapahtuman suorittamiseen kuluva aika Levytila, joka tulisi minimoida (mahdollisimman vähällä levytilalla voidaan tallentaa tarvittavat tiedot)

Vielä ennen varsinaisen fyysisen esityksen suunnittelua tulee huomioida järjestelmän resurssit Muisti Muistista tietojen haku on huomattavasti nopeampaa kuin levyltä Järjestelmässä tulisi olla aina vähintään 5% vapaata muistia Yli 10%:n vapaa muisti tarkoittaa muistin tehotonta käyttöä CPU Kontrolloi järjestelmää ja suorittaa käyttäjän prosessit Levy I/O Järjestelmätiedostot erotettu tietokantatiedostoista Varsinaiset tietokantatiedostot erotettu indeksitiedostoista Lokitiedostot erotettu muista tietokannan tiedostoista106 Verkko Verkko voi olla pullonkaula tietojen siirrossa

Analysoidaan tietovirrat Tietovirtojen analysoinnissa huomioidaan sekä laadulliset että määrälliset tietovirrat Tapahtumista määritellään Odotettu tapahtumien taajuus Tapahtumaan liittyvät relaatiot ja attribuutit sekä tapahtuman laatu (haku, lisäys, päivitys tai poisto) Attribuutit, joita käytetään hakuehtoina Attribuutit, jotka liittävät tapahtumassa käsiteltävät relaatiot toisiinsa Tapahtuman vaadittu vasteaika Tapahtumien käytöstä tehdään kartta Valitaan tiedostojärjestelmä jokaiselle oliotyypille (relaatiolle) Valitaan joku seuraavista tiedostotyypeistä: kasa, hajautus, indeksoitu peräkkäissaanti metodi (Indexed Sequential Access Method) tai B -puu

Suunnitellaan toissijaiset indeksit Toissijaisilla indekseillä nopeutetaan tietojen hakua Toisaalta on otettava huomioon Lisättäessä relaatioon on aina päivitettävä indeksitiedot myös toissijaiselle indeksille Päivitettäessä relaatiota on aina päivitettävä indeksitiedot myös toissijaiselle indeksille Levytilan lisätarve toissijaisten indeksien tallentamiseen Toissijaisten indeksien määrä hakujen nopeutukseen (järjestelmän tulee ensin valita se toissijainen indeksi, jolla haku lopulta nopeutuu eniten) Muutama ohje indeksointiin Perusavain indeksoidaan; pelkkä perusavainmääritys ei välttämättä luo indeksiä Pieniä relaatioita ei indeksoida Luodaan toissijainen indeksi niille attribuuteille, joita käytetään erittäin paljon esim. Hakuehtoina Luodaan toissijaiset indeksit vierasavaimille, joita käytetään usein relaatioiden liittämiseen Niitä attribuutteja ei indeksoida, joita muutetaan usein Niitä attribuutteja ei indeksoida, jotka ovat hakuehtoina, mutta hakutuloksena saadaan kuitenkin suurin osa relaation riveistä Niitä attribuutteja ei indeksoida, jotka sisältävät vapaata tekstitietoa

Tarkastellaan kriittisesti rakennettuja relaatioita Voidaan joutua purkamaan normalisointia, jolloin on huomioitava Denormalisointi tuo toteutukseen kompleksisuutta Denormalisointi uhkaa saavutettua dynaamisuutta Denormalisointi voi nopeuttaa hakuja, mutta hidastaa päivityksiä Laskettujen (perittyjen) tietojen huomioiminen, esim. Työntekijöiden määrä tietyllä osastolla Kaikkien työntekijöiden yhteinen kuukausiansio Yhden työntekijän hoitamien asioiden määrä Perityt attribuutit eivät useinkaan esiinny loogisessa tietomallissa, mutta ovat kuitenkin mukana dokumentoinnissa Jos peritty attribuutti esiintyy ER -kaaviossa, se on pisteviivalla ymräröity attribuutti Suunnittelijan tehtävänä on laskea Kustannukset perityn attribuutin tallentamisesta tietokantaan Kustannukset perityn attribuutin laskennallinen hakeminen jokaisella hakukerralla

Tarkastellaan kriittisesti rakennettuja relaatioita Harkitaan attribuuttien toistamista ja relaatioiden yhdistämistä Esimerkiksi postitoimipaikka on funktionaalisesti riippuvainen postinumerosta, joten normalisoinnin yhteydessä relaatioon jää vain postinumero ja postinumerolle tehdään oma relaatio, jossa on toimipaikka Koska lähes aina haettaessa postinumeroa haetaan myös postitoimipaikka, liittämällä postitoimipaikka em. relaatioon liitosten määrä eri relaatioiden välillä vähenee Arvioidaan tarvittava levytila Arvioinnissa on otettava huomioon käytettävissä olevata (valittu) tiedostojärjestelmä Jokaisesta relaatiosta lasketaan aste (attribuuttien lukumäärä) ja rivien määrä tietyllä ajanjaksolla Laskennan tuloksena saadaan tarvittava levytila kutakin relaatiota kohden ja koko tietokannan levytilan tarve

Suunnitellaan käyttäjien näkymät Ensimmäisessä vaiheessa (käsitteellinen taso) saatiin käyttäjien näkemykset asioista ER -malliksi Tämä malli huomioiden suunnitellaan saadusta fyysisestä tietokannan esityksestä käyttäjille mahdollisimman toimivat näkymät Näkymät luodaan usein SQL -kielellä Näkymien luomisessa tulee huomioida käyttöoikeudet Suunnitellaan käyttöoikeudet Käyttöoikeudet tulee suunnitella perusrelaatioille sekä näkymille Käyttäjille tulisi antaa oikeudet tietoihin vain näkymien kautta, ei siis suoraan perusrelaatioihin (tietokannan tauluihin) Jokainen käyttäjä määritellään (käyttäjätunnus ja siihen liittyvä salasana) Jokaisella objektilla tietokannassa on omistaja (käyttäjä, joka on luonut ko. objektin) Relaatioille voidaan antaa erikseen suojaukset (haku, lisäys, muutos, poisto) eri käyttäjille tai käyttäjäryhmille

Kun tietojärjestelmä on otettu käyttöön, tarkastellaan sen käyttöä eri käyttäjien näkökulmasta Jos tietojärjestelmästä löytyy virheellisiä toimintoja, ne korjataan ja tarkistetaan tietokannan toimivuus Tarvittaessa korjataan tietokannassa olevat relaatiot vastaamaan todellista käyttöä Tarkastellaan liipaisufunktioiden ja tietokantafunktioiden toimivuutta Kerätään tietoa käyttäjiltä tietojärjestelmän muutostarpeista Tavoitteena on maksimoida tietojärjestelmän hyöty käyttäjille

Tietokannan käsittely SQL -lauseilla
Tietojen haku käyttäen SQL:n ominaisuuksia

Duplikaattien poisto kyselystä
Mikä on duplikaatti? Kun kysely tuottaa useita samanlaisia rivejä, puhutaan duplikaateista. Duplikaatti syntyy siitä, että taulusta haetaan vain projektio, jolloin hakutuloksessa on samanlaisia rivejä, vaikka taulussa itsessään ei olisikaan samanlaisia rivejä. Miten duplikaateista päästään eroon? UNION –määreellä linkitetään useampi SELECT –lause ja samalla päästään eroon duplikaateista. Mikäli halutaan UNION –määreen tapauksessa tulokseen duplikaatit, tarvitaan SELECT –lauseessa ALL –määre DISTINCT –määreellä poistetaan yksinkertaisesta SELECT –lauseesta duplikaatit

Duplikaattien poisto, esimerkki
Yksinkertainen haku: SELECT Postinumero, Toimipaikka FROM Yhteystieto; Haku, jossa ei duplikaatteja: SELECT DISTINCT Postinumero, Toimipaikka FROM Yhteystieto;

Ulkoinen liitos (outer join)
Mikä on ulkoinen liitos? Haettaessa tietoja kahdesta taulusta, normaalilla liitoksella (inner join) saadaan vain ne rivit, joiden liitoksessa määritellyt kenttien arvot löytyvät molemmista tauluista. Joskus on tarve saada kaikki rivit yhdestä taulusta ja lisäksi vastaavat rivit toisesta taulusta niin, että rivien puuttuminen toisesta taulusta ei vaikuta päätaulun tietojen hakuun. Ulkoisella liitoksella saadaan aikaan tällainen hakutulos. Ulkoisessa liitoksessa on vaaransa ja rajoituksensa: Usein yhdessä kyselyssä voi olla vain ulkoinen liitos yhteen tauluun (ja tästä edeleen seuraavaan jne.), mutta yhdestä taulusta ei voi olla moneen tauluun ulkoista liitosta. On oltava tarkkana päätaulun ja liitostaulun järjestyksestä.

Ulkoinen liitos esimerkki
Yksinkertainen haku: SELECT Y.Nimi, H.Nimi FROM Yhteystieto Y, Henkilo H WHERE Y.ID = H.YhteystietoID; Haku ulkoisen liitoksen avulla: SELECT Y.Nimi, H.Nimi FROM Yhteystieto Y LEFT JOIN Henkilo H ON Y.ID = H.YhteystietoID;

Ryhmittely Mitä ryhmittelyllä tarkoitetaan?
Kun halutaan hakea tietoa niin, että jonkin sarakkeen arvoja ei haluta sellaisenaan vaan halutaan koottu informaatio sarakkeen arvoista, tarvitaan ryhmittelyä Sarakkeen minimiarvo (min) Sarakkeen maksimiarvo (max) Sarakkeen keskiarvo (avg) Sarakkeen arvojen lukumäärä (count) Sarakkeen arvojen summa (sum) Ryhmittelyyn tarvitaan sarake (sarakkeita), jonka (joiden) mukaan ryhmittely tehdään

Ryhmittely esimerkki Haku yksinkertaisesti ryhmitellen:
SELECT Y.Nimi, Count(H.ID) AS Maara FROM Yhteystieto Y, Henkilo H WHERE Y.ID = H.YhteystietoID GROUP BY Y.Nimi; Lisätään ryhmittelyyn ulkoinen liitos: SELECT Y.Nimi, Count(H.ID) FROM Yhteystieto Y LEFT JOIN Henkilo H ON Y.ID = H.YhteystietoID GROUP BY Y.Nimi;

Ryhmittelyn rajoittaminen
Mitä erikoista on ryhmittelyn rajoittamisessa? Normaalin kyselyn rajaus tapahtuu WHERE –osiossa määriteltyjen ehtojen mukaan. Ryhmittelyn tapauksessa WHERE –osiossa voidaan rajoittaa hakua vain niiden sarakkeiden osalta, joihin ei kohdistu koontifunktioita. Koontifunktioiden käyttö rajoittamisessa: Tähän tarkoitukseen on oma osionsa SQL –lauseessa: HAVING HAVING –osio tulee mahdollisen WHERE –osion jälkeen

Ryhmittelyn rajoitusesimerkki
WHERE –osion käyttö: SELECT Y.Nimi, Y.Toimipaikka, Count(H.ID) AS Määrä FROM Yhteystieto AS Y LEFT JOIN Henkilo AS H ON Y.ID=H.YhteystietoID WHERE Y.Nimi='MaestroYhtiöt’ GROUP BY Y.Nimi, Y.Toimipaikka; HAVING –osion käyttö: SELECT Y.Nimi, Y.Toimipaikka, Count(H.ID) AS Määrä FROM Yhteystieto Y LEFT JOIN Henkilo H ON Y.ID = H.YhteystietoID GROUP BY Y.Nimi, Y.Toimipaikka HAVING Count(H.ID) = 0;

Hakujen rajaaminen Haku rajaamalla arvoalue: Haku luettelemalla arvot:
Hae ne henkilöt, joiden bonus on 3:n ja 5:n välillä: SELECT H.ID, H.Nimi, H.Bonukset FROM Henkilo AS H WHERE H.Bonukset Between 3 AND 5 ORDER BY H.Nimi; Rajat (3 ja 5) otetaan mukaan. Haku luettelemalla arvot: SELECT H.ID, H.Nimi, H.Bonukset FROM Henkilo AS H WHERE H.Bonukset IN (1,3,5) ORDER BY H.Nimi; Vältetään usean OR –ehdon käyttö.

Hakujen rajaaminen jatkuu …
Haku alikyselyn avulla: Hae ne henkilöt, joilla on maksimibonukset: SELECT H.ID, H.Nimi, H.Bonukset FROM Henkilo AS H WHERE H.Bonukset IN (SELECT MAX(Bonukset) FROM Henkilo) ORDER BY H.Nimi; Vältetään usean OR –ehdon käyttö eikä tarvitse tietää kaikkia mahdollisia arvoja, koska ne haetaan alikyselyllä.

Yhteenvetotietojen haku
Miten haen bonukset yrityksittäin jaoteltuna myös toimipaikan mukaan? Käytetään haussa apuna UNION:a SELECT Y.Nimi, Y.Toimipaikka, Sum([Bonukset]) AS Bonus FROM Yhteystieto Y LEFT JOIN Henkilo H ON Y.ID = H.YhteystietoID GROUP BY Y.Nimi, Y.Toimipaikka UNION SELECT Y.Nimi, 'Yhteensä', Sum([Bonukset]) AS Bonus FROM Yhteystieto Y LEFT JOIN Henkilo H ON Y.ID = H.YhteystietoID GROUP BY Y.Nimi ORDER BY 1,2;

Alikyselyt Mikä on alikysely?
Varsinaisen kysyn sisällä on toinen kysely. Kysely voi olla SELECT –osassa Ei SQL –standardin mukainen. Kysely voi olla FROM –osassa. Harvoin käytetty. Kysely voi olla WHERE –osassa, jolloin se liittyy johonkin seuraavista: Verrataan yhtäsuuruutta (tai erisuuruutta) (NOT) IN ANY ALL SOME (NOT) EXISTS

Alikyselyt, yhtäsuuruus
Hae ne henkilöt, jotka työskentelevät samassa toimipaikassa kuin Joona: SELECT YhteystietoID FROM Henkilo WHERE Nimi = ”Joona” Saadaan tietää YhteystietoID, joka on 1 SELECT * FROM Henkilo WHERE YhteystietoID = 1 Haetaan edellisen haun tuloksen perusteella tiedot

Alikyselyt, yhtäsuuruus
Samaan lopputulokseen päästään yhdellä kyselyllä, joka sisältää alikyselyn: SELECT * FROM Henkilo WHERE YhteystietoID = ( SELECT YhteystietoID FROM Henkilo WHERE Nimi = ”Joona”) Yhtäsuuruutta verrattaessa täytyy varmistaa, että alikysely tuottaa vain yhden rivin tulokseksi!

Alikyselyt, IN Hae ne yritykset, joilla on henkilöitä Henkilo –taulussa SELECT Nimi, Toimipaikka FROM Yhteystieto WHERE ID IN ( SELECT YhteystietoID FROM Henkilo) Hae ne yritykset, joilla ei ole henkilöitä Henkilo –taulussa: SELECT Nimi, Toimipaikka FROM Yhteystieto WHERE ID NOT IN ( SELECT YhteystietoID FROM Henkilo)

Alikyselyt, ANY (SOME) ja ALL
Yhtäsuuruus ja IN vaihtoehdot edellyttivät, että ehtona testataan yhtä- tai erisuuruutta. Mikäli tarvitaan vertailuoperaattoria (<, >, <= tai >=), niin on käytettävä tilanteesta riippuen ANY- (SOME-) tai ALL –määreitä. ANY ja ALL voidaan kuvata seuraavan kaavion avulla: X op ANY {a, b, …} Tarkoittaa samaa kuin X op a OR X op b OR … X op ALL {a, b, …} Tarkoittaa samaa kuin X op a AND X op b AND …

Kenellä on vähemmän bonuksia kuin Savonlinnalaisilla (vähemmän kuin kenellä tahansa Savonlinnalaisella): SELECT Nimi FROM Henkilo WHERE Bonukset < ALL ( SELECT Bonukset FROM Henkilo WHERE YhteystietoID = ( SELECT ID FROM Yhteystieto WHERE Toimipaikka = ”Savonlinna”))

Kenellä on enemmän bonuksia kuin Timolla tai Helvillä: SELECT Nimi, Bonukset FROM Henkilo WHERE Bonukset > ANY ( SELECT Bonukset FROM Henkilo WHERE Nimi = ”Timo” OR Nimi = ”Helvi”)

Alikyselyn kytkeminen pääkyselyyn
Edellä alikysyt olivat riippumattomia pääkyselystä, ts. ne hakivat tietoa itsenäisesti ja tätä tietoa verrattiin sitten johonkin pääkyselyn tietoon. Mikäli alikyselyn tulos on riippuvainen pääkyselystä, on pääkyselyn sarake liitettävä alikyselyn sarakkeeseen. Alikyselyssä viitataan nimeltä pääkyselyn sarakkeeseen ns. korrelaatioviitteellä ja alikysely suoritetaan uudestaan jokaista pääkyselyn riviä kohti. Järjestys onkin nyt ”ylhäältä alas”: Lue pääkyselyn mukainen yksi rivi. Suoritetaan alikysely, jossa viitataan johonkin (tai joihinkin) juuri luettuun arvoon. Lue seuraava pääkyselyn rivi jne.

Alikyselyn kytkeminen pääkyselyyn
Hae ne henkilöt, joilla on toimipaikkansa suurin bonus: SELECT H1.Nimi, H1.Bonukset, Y.Toimipaikka FROM Henkilo H1, Yhteystieto Y WHERE H1.Bonukset = ( SELECT MAX(H2.Bonukset) FROM Henkilo H2 WHERE H2.YhteystietoID = H1.YhteystietoID) AND H1.YhteystietoID = Y.ID ORDER BY Y.Toimipaikka Kytkentöjä kyselyjen välillä voi olla useampiakin. Kytkettävää kenttää ei välttämättä tarvitse olla pääkyselyn SELECT –osassa.

Alikyselyt, EXISTS EXISTS –operaattoria voidaan käyttää, kun testataan, ovatko tietyt rivit olemassa vai eivät. EXISTS –alikysely antaa tulokseksi vain joko tosi tai epätosi, ei mitään arvoja kuten tähänastiset alikyselyt. EXISTS on tosi, mikäli alikysely tuottaa ainakin yhden rivin, ja epätosi jos ei löydy yhtään riviä. Kaikki IN-, ALL- ja ANY- (SOME) –rakenteet voidaan muuntaa EXISTS –tai NOT EXISTS –rakenteeksi. EXISTS –rakenteet ovat käytännössä aina kytkettyjä (korreloituja) alikyselyjä eli niissä esiintyy korrelaatioviite pääkyselyyn. EXISTS –alikysely ei välitä suoraan arvoa pääkyselylle vaan on joko tosi tai epätosi. Ei ole väliä, mitä sarakenimiä SELECT –listassa on; tapana on käyttää muotoa ”SELECT *”.

Alikyselyt, EXISTS Hae ne yritykset, joilla on henkilöitä Henkilo –taulussa SELECT Y.Nimi, Y.Toimipaikka FROM Yhteystieto Y WHERE EXISTS ( SELECT * FROM Henkilo H WHERE H.YhteystietoID = Y.ID) Hae ne yritykset, joilla ei ole henkilöitä Henkilo –taulussa: SELECT Y.Nimi , Y.Toimipaikka FROM Yhteystieto Y WHERE NOT EXISTS ( SELECT * FROM Henkilo H WHERE H.YhteystietoID = Y.ID)

Vaativampi SQL Näkymät (1/4)
Näkymä on dynaaminen tulos yhdestä tai useammasta perusrelaatiosta Näkymä on virtuaalinen relaatio, joka ei esiinny sellaisenaan tietokannassa, vaan sen kautta haetaan tietoa perusrelaatioista Luonti CREATE VIEW näkymän_nimi [(sarake_nimi [,…])] AS alikysely [WITH [CASCADED | LOCAL] CHECK OPTION] Näkymän_nimi on luotavan näkymän nimi (uuden relaation nimi) Sarake_nimi on luotavalle näkymälle annettu sarakkeen nimi. Jos tämä jätetään antamatta, sarakkeen nimeksi tulee perusrelaation (tai näkymän, josta tämä näkymä luodaan) sarakkeen nimi Alikysely on mikä tahansa tietokantaan tehtävä kysely (SELECT…) WITH CHECK OPTION määrää, miten päivitetyt (lisätyt, poistetut, muutetut) rivit näkyvät (näkymän kautta mahdollisuus päivittää perusrelaatioiden tietoja) Poisto DROP VIEW näkymän_nimi [RESTRICT | CASCADE] Näkymän_nimi on poistettavan näkymän nimi CASCADE –optiolla poistetaan kaikki ne objektit, jotka on johdettu tästä näkymästä RESTRICT –optiolla ei poisteta johdettuja objekteja; niiden käytöstä tulee virhe

Rajoituksia näkymien käyttöön Jos kertymäfunktioita (MIN, MAX, AVG, SUM, COUNT) on käytetty näkymän sarakkeen määrittelyssä, haettaessa tietoja näkymän kautta ei voida käyttää kertymäfunktioita Ryhmiteltyä (GROUP BY) näkymää ei voi käyttää uuden näkymän luomisessa perusrelaation tai näkymän kanssa Rajoituksia näkymien päivityksiin DISTINCT –määrettä ei voi olla näkymässä, jonka kautta tietoja päivitetään SELECT –listassa on vain sarakkeiden nimiä, ei kaavoja, kertymäfunktioita tms. FROM –osassa on vain viittaus yhteen tauluun WHERE –osassa ei ole alikyselyä, jossa FROM –osassa viitataan ko. tauluun Alikyselyssä ei esiinny GROUP BY- tai HAVING -lauseita

Hyödyt Tietoriippumattomuus Näkymien päivittäminen ei ole tarpeen, jos perusrelaatioihin lisätään sarakkeita tai poistetaan sellaisia sarakkeita, joita ei käytetä näkymässä Käyttäjän näkemän perusrelaation hajottaminen kahteen osaan ei muuta käyttäjän näkemää tietokannan relaatioita, kun uusista perusrelaatioista tehdään vanhan kaltainen näkymä Hyväksyntä Muutos perusrelaatioon näkyy automaattisesti myös näkymässä Parantunut turvallisuus Voidaan paremmin rajata käyttäjän oikeudet vain niihin tietoihin, jotka ovat välttämättömiä Monimutkaisuuden vähentyminen Näkymät voivat olla hyvin yksinkertaisia, vaikka ne kasaavat tietoa useista tauluista monimutkaisin ehdoin Yksilöllisyys Eri käyttäjät voivat tarpeen vaatiessa nähdä samat tietokannan tiedot hyvinkin erilaisessa muodossa Tietojen eheys Näkymän määrityksessä voidaan rajoittaa käyttäjän mahdollisuuksia esim. päivittää tietokannan tietoja

Haitat Päivitykset eivät aina mahdollisia Em. rajoitukset huomioiden Rakenteelliset rajoitteet Jos näkymä on luotu käyttäen SELECT * …, niin näkymään on nimenomaan luotu ne sarakkeet, joita perusrelaatiossa on ollut näkymän luontihetkellä. Jos myöhemmin perusrelaatioon lisätään sarakkeita, ne eivät näy näkymässä muutoin kuin luomalla näkymä uudestaan Esitystapa Aina näkymää käytettäessä tehdään tietokantaan se kysely, jonka perusteella näkymä on luotu. Tämä voi aiheuttaa turhaan perusrelaatioiden liittämistä, mikäli halutaan hakea vain osaa näkymän sarakkeista ja nämä sarakkeet löytyisivät yksinkertaisemmin ilman näkymää

Vaativampi SQL Eheyden parantaminen (1/3)
Pakolliset tiedot Sarakkeen määrityksessä määritellään NOT NULL –optio Arvoaluerajoitteet CHECK (hakuehto) Voidaan määritellä sarakkeen sisältämä tieto tietyn hakuehdon mukaiseksi esim. sukupuoli CHAR NOT NULL CHECK (sukupuoli IN(’M’,’N’)) CREATE DOMAIN arvoalueen_nimi [AS] tieto_tyyppi [DEFAULT oletus_arvo] [CHECK (hakuehto)] Voidaan määritellä arvoalue, jolla hakuehdon mukaiset rajoitteet ja jota käytetään sarakkeen määrityksessä CREATE DOMAIN sukupuoli_tyyppi AS CHAR CHECK (VALUE IN (’M’,’N’)) sukupuoli SUKUPUOLI_TYYPPI NOT NULL DROP DOMAIN arvoalueen_nimi [RESTRICT | CASCADE]

Relaation eheys PRIMARY KEY (sarakemäärittely) Voidaan määritellä vain yksi perusavain taulua kohden Määrittelee yksikäsitteisyyden UNIQUE (sarakemäärittely) Voidaan määritellä perusavaimen lisäksi sarakkeet, jotka yksilöivät relaation rivit Viite-eheys FOREIGN KEY (sarakemäärittely) REFERENCES taulun_nimi Määrittelee, mitkä sarakkeet ovat perusaivaimena jossakin toisessa relaatiossa ON UPDATE / ON DELETE CASCADE Poistetaan/päivitetään kaikista johdetuista relaatioista löytyvät sarakeviittaukset SET NULL Asetetaan johdetuissa tauluissa sarakkeen arvo NULL –arvoksi. Toimii vain, mikäli sarakkeen arvo voi olla NULL SET DEFAULT Asetetaan johdetussa taulussa sarakkeen arvo oletusarvoksi. Toimii vain, jos sarakkeelle on määritelty oletusarvo NO ACTION Tapahtumaa ei sallita, jos johdetuissa tauluissa viittauksia. Tämä on oletusarvo ON DELETE -optiolla

Looginen eheys CREATE ASSERTION ehdon_nimi CHECK (hakuehto) Ei liity suoranaisesti taulun määrittelyyn Ehtoon voi sisältyä hakuja useammasta taulusta esim. CREATE ASSERTION valvottavat_vuokraukset CHECK(NOT EXISTS(SELECT nro FROM vuokraus GROUP BY nro HAVING COUNT(*) > 10)) Tarkistaa, ettei henkilöllä ole jo valvottavanaan enempää kuin 10 vuokrausta

Vaativampi SQL Taulun määritysten muuttaminen
Tauluihin voidaan tehdä seuraavia muutoksia Lisätä uusia sarakkeita Poistaa sarakkeita Lisätä rajoituksia Poistaa rajoituksia Asettaa oletusarvoja sarakkeille Poistaa oletusarvoja sarakkeilta ALTER TABLE taulun_nimi [ADD [COLUMN] sarake_nimi tietotyyppi [NOT NULL] [UNIQUE] [DEFAULT oletusarvo] [CHECK (hakuehto)]] [DROP [COLUMN] sarake_nimi [RESTRICT | CASCADE]] [ADD [CONSTRAINT [rajoituksen_nimi]] rajoituksen_määrittely] [DROP CONSTRAINT rajoituksen_nimi [RESTRICT | CASCADE]] [ALTER [COLUMN] SET DEFAULT oletusarvo] [ALTER [COLUMN] DROP DEFAULT]

Vaativampi SQL Käyttöoikeudet (1/2)
Standardin mukaiset käyttöoikeudet voidaan antaa seuraavan jaottelun mukaan SELECT: oikeus hakea tietoa taulusta / sarakkeesta INSERT: oikeus lisätä rivejä tauluun UPDATE: oikeus päivittää tietoja taulussa / sarakkeessa DELETE: oikeus poistaa rivejä taulusta REFERENCES: oikeus viitata taulun sarakkeisiin eheysrajoitteissa USEGE: oikeus käyttää mm. arvoaluemäärittelyjä Oikeuksien antaminen GRANT {lista_oikeuksista | ALL PRIVILEGES} ON objektin_nimi TO {käyttäjälista | PUBLIC} [WITH GRANT OPTION]

Vaativampi SQL Käyttöoikeudet (2/2)
Oikeuksien poistaminen REVOKE [GRANT OPTION FOR] {lista_oikeuksista | ALL PRIVILEGES} ON objektin_nimi FROM {käyttäjälista | PUBLIC} [RESTRICT | CASCADE] Esimerkki GRANT ALL PRIVILEGES ON työntekijä TO pomo WITH GRANT OPTION GRANT SELECT, UPDATE (palkka) ON työntekijä TO tietokannan_hoitaja REVOKE SELECT ON osasto FROM PUBLIC

Luennot jatkuvat… SQL ja QBE (Query By Example), Tietokannan suojaaminen Tapahtumakäsittely Varmuuskopiointi ja palautus, hakujen käsittely Tietokantojen hajauttaminen Katsaus oliotietokantoihin Tietojen varastointi

Turvallisuus Tietokannan suojaus
Suojautumista tahallista tai tahatonta hyökkäystä vastaan käyttäen joko teknisiä (esim. ohjelmallisia) keinoja tai ei-teknisiä keinoja Turvallisuuteen vaikuttavia tekijöitä Varkaus ja huijaus Ei liity pelkästään tietokantoihin, vaan koko yritykseen Salassapitovelvollisuus ja sen menetys Voi heikentää kilpailukykyä Yksityisyys ja sen menetys Voi johtaa oikeustoimiin Yhtenäisyys ja sen rakoileminen Tietokannan yhtenäisyyden murentuessa tietoihin ei voida enää luottaa Voi olla vakavia vaikutuksia yrityksen liiketoimintaan Tietojen saatavuus ja saatavuuden rajoittuminen Tietojen käyttökatkot voivat vaikeuttaa yrityksen toiminnan ylläpitämistä Tietojen saatavuuteen vaikuttaa sekä tietokantajärjestelmän toimivuus että käytettävän ympäristön (käyttöjärjestelmä, lähiverkko tms.) pysyminen käyttökunnossa

Turvallisuus Tietokannan suojaus
Uhkatekijät Mikä tahansa tilanne tai tapahtuma, tahallinen tai tahaton, joka vaikuttaa epäsuotuisasti tietojärjestelmään ja sitä kautta koko yritykseen Laitteiden ja järjestelmien käytettävyys Milloin viimeisin varmuuskopiointi on otettu? Aika, joka tarvitaan järjestelmän palauttamiseen Voidaanko kadotetut tiedot saada jotenkin takaisin? Uhkataulukon tekeminen

Turvallisuus Vastatoimet – järjestelmään pohjautuvat
Valtuutukset Luodaan sellaiset oikeudet ja käyttömahdollisuudet, jotka oikeuttavat järjestelmän tai sen osan käyttöön siinä määrin kuin se on välttämätöntä On pyrittävä luomaan sellainen mekanismi, jolla käyttäjä voidaan tunnistaa oikeaksi käyttäjäksi Oikeuksien periytyminen Kun käyttäjälle annetaan oikeudet tietokantaan (luodaan käyttäjätunnus ja salasana), mitä muita oikeuksia käyttäjä saa? Voi olla tarpeen luoda käyttäjälle kaikki tarvittavat oikeudet tunnuksen luomisen jälkeen tai rajoittaa automaattisesti luotuja käyttöoikeuksia Omistajan oikeudet ja muiden oikeudet Käyttäjien ja käyttäjäryhmien oikeuksista tehdään taulukko Näkymät Näkymät ovat yhden tai useamman relaation dynaaminen liitos Näkymien avulla voidaan ”piilottaa” käyttäjälle tarpeettomat tiedot tietokannasta

Varmuuskopiointi ja niiden palautus Varmuuskopioinnilla tarkoitetaan tietyin väliajoin otettavaa kopiota tietokannasta ja sen lokitiedostoista Varmuuskopioon otetaan mahdollisesti myös ohjelmat (loppukäyttäjän ohjelmat) Varmuuskopio otetaan sellaiselle tallennusvälineelle, jota ei voi käyttää aktiivisesti ja joka talletetaan turvalliseen paikkaan (esim. kassakaappi) Varmuuskopioiden lisäksi otetaan lokitiedostot talteen sopivin väliajoin, jolloin tietokannan palautus käyttökatkon jälkeen voi onnistua nopeammin ilman varsinaisen varmuuskopion palautusta Tarkistuspisteiden käyttö, jolloin tietokannan ja lokitiedostojen tiedot synkronoidaan Varmuuskopioiden palautuksen tulisi olla sellainen, että järjestelmä saadaan varmuuskopion ottamista edeltävään tilaan Palautuksen yhteydessä tietokantaan ei pitäisi päästä eheysrikkomuksia tms.

Yhtenäisyys (eheys) Tästä on ollut puhetta jo aikaisemmin Eheys liittyy turvallisuuteen siinä mielessä, että eheyden ollessa kunnossa, tietokantaan ei voida tallentaa sellaisia tietoja, jotka esim. saattavat tietokannan tiedot yritykselle epäedulliseen tilaan Salaus (salaus) Suojauksella tiedot muunnetaan erityisellä algoritmilla niitä siirrettäessä Tiedot ovat luettavissa vain käyttämällä suojauksen purkuavainta Suojaukseen tarvitaan Suojausavain Suojausalgoritmi Suojauksen purkuavain Suojauksen purkualgoritmi Yhdistetyt aliohjelmat

Turvallisuus Vastatoimet – järjestelmästä riippumattomat
Turvallisuuspolitiikka ja varasuunnitelma Liiketoiminnan osa (alue), jota turvallisuuspolitiikka koskee Työntekijöiden vastuut ja velvollisuudet Mitä toimenpiteitä vaaditaan turvallisuuspolitiikan ylläpitämiseen? Toimintasuunnitelmat, joita täytyy noudattaa Ketkä ovat avainhenkilöitä ja miten heidät tavoittaa? Mitä henkilökunnalta vaaditaan? Mistä voidaan saada ulkopuolista apua tarvittaessa? Henkilökohtainen kontrolli Sijoittaminen ja varastointi Mihin sijoitetaan esim. tulostimet, jotka tulostavat arkaluonteista tietoa Lukittuja huoneita (kaappeja tms.) pitää olla sopivasti

Turvallisuus Vastatoimet – järjestelmästä riippumattomat
PC turvallisuus Yksi suuri epäkohta, mikäli työasemiin jätetään esim. lounasajaksi tietokantasovelluksia aktiivisiksi Virukset Tiedonhallintajärjestelmät ja tietoverkko Proxy –palvelimet Palomuurit Digitaalinen allekirjoitus Suojattujen protokollien käyttö (SSL, SHTTP) Riskianalyysi Riskianalyysin tekemiseen kannattaa perustaa ”turvallisuusryhmä”, joka perehtyy yrityksen tarvitsemiin suojautumiskeinoihin

Tapahtumien hoitaminen Mitä tapahtumilla tarkoitetaan? (1/2)
Tapahtuma on toimenpide tai toimenpidesarja, jonka yksittäinen käyttäjä tai ohjelma käskee suorittamaan ja joka hakee tai päivittää tietokannan sisältöä Tapahtuma on siis looginen kokonaisuus tietokannassa tapahtuvia toimenpiteitä, jotka liittyvät toisiinsa Esimerkki tapahtumasta, jossa käytetään relaatiota Staff (Sno, Fname, Lname, Address, Tel_No, Position, Sex, DOB, Salary, NIN, Bno) read(Sno = x, salary) salary = salary * 1.1 write(Sno = x, new_salary) Esimerkki kasvattaa henkilön palkkaa 10%:lla Tapahtumalle annetaan henkilön tunniste (x, joka on perusavain) ja haetaan sekä tunniste että palkka Palkan korottamisen jälkeen muuttuneet tiedot kirjoitetaan takaisin tietokantaan

Tapahtumien hoitaminen Mitä tapahtumilla tarkoitetaan? (2/2)
Esimerkki, jossa käytetään em. relaation lisäksi relaatiota Property_for_Rent (Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno) delete(Sno = x) for all Property_for_Rent records, pno begin read(Pno = pno, sno ) if (sno = x) then begin sno = new_sno write (Pno = pno, sno) end end Esimerkissä poistetaan työntekijä ja päivitetään viittaukset relaatiossa, jossa viiteavaimena on poistetut työntekijän tunnus Lopputuloksena tapahtuman tulee saattaa tietokanta sallittuun tilaan (eheäksi)

Tapahtumien hoitaminen Tapahtumien ominaisuuksia
Kaikkien tapahtumien pitäisi sisältää seuraavat neljä ominaisuutta (ACID) Atomicity: jokainen tapahtuma on jakamaton, joka suoritetaan joko kokonaan tai ei ollenkaan Consistency: jokainen tapahtuma on johdonmukainen ja saattaa tietokannan jostakin sallitusta (eheästä) tilasta toiseen tällaiseen tilaan Isolation: jokainen tapahtuma on erillinen (riippumaton) muista tapahtumista; toisin sanoen tapahtuman, joka koostuu useasta eri toimenpiteestä, näkyvyys toiselle tapahtumalle on koko tapahtuma tai ei mitään, tapahtuman sisällä olevat toimenpiteet eivät näy toiselle tapahtumalle erillisinä Durability: loppuun saatetun tapahtuman (annettu commit) vaikutus tallennetaan tietokantaan lopullisena tapahtumana eikä tätä hävitetä, jotta myöhemmin ei tulisi virheitä (esim. eheydestä johtuvia)

Tapahtumien hoitaminen Samanaikaisuuden hallinta
Samanaikaisten prosessien (tapahtumien) hoitaminen niin, etteivät ne sekoita toisiaan tai aiheuta sekaannusta tietokantaan Samanaikaisuuden hallintaa tarvitaan silloin, kun tietokantaan kohdistuu useamman kuin yhden käyttäjän toimenpiteitä koskien samoja tietokannan tietoja (relaatioita) Samanaikaisuuden hallintaa tarvitaan myös silloin, kun useampi kuin yksi ohjelma tekee päivityksiä tai hakuja tietokantaan samoihin tietoihin (relaatioihin) Kaksi tapahtumaa voivat toimia yksinäisinä tapahtumien moitteettomasti, mutta niiden samanaikainen suorittaminen voi tuottaa ongelmia Päivityksen menetys Riippuvuus keskeneräisestä tapahtumasta Ristiriitaisuuden ongelma

Tapahtumien hoitaminen Päivityksen menetys
Yhden käyttäjän / ohjelman tekemä päivitys voidaan menettää, kun toinen käyttäjä / ohjelma tekee päivityksen ensimmäisen päivityksen jälkeen käyttäen kuitenkin alkuarvonaan tietokannassa ollutta arvoa ennen ensimmäistä päivitystä Aika-akselilla kuvattuna tapahtumat ja niiden vaikutus voisi olla vaikka seuraava

Tapahtumien hoitaminen Riippuvuus keskeneräisestä tapahtumasta
Tapahtuman tuottamien tulosten näkyminen toiselle tapahtumalle ennen kuin koko tapahtuma on suoritettu loppuun voi tuottaa ongelmia Em. esimerkistä tapahtumien suoritus hieman toisessa järjestyksessä muutamalla lisäyksellä voi tuottaa esim. seuraavan tuloksen

Tapahtumien hoitaminen Ristiriitaisuuden ongelma
Em. esimerkit olivat sellaisia, joissa tietokannan tietoja päivitettiin ja siitä syntyi ei-toivottu tilanne tietokantaan Tapahtuman, joka pelkästään lukee tietokantaan, lopputuloksena voi myös tulla ei-toivottuja tuloksia, jos tapahtuman sallitaan lukea toisen päättymättömän tapahtuman tietoja

Tapahtumien hoitaminen Sarjoittaminen ja palauttaminen (1/3)
Tapahtumien sarjoittamisella pyritään siihen, että tapahtumien suorittaminen ei aiheuttaisi odottamattomia tai ei-toivottuja tilanteita tietokantaan Yksinkertainen ratkaisu ongelmaan olisi se, että sallitaan vain yksi tapahtuma kerrallaan tietokantaan, jolloin tapahtuman suorittamisen jälkeen (commit) voi toinen tapahtuma alkaa Monen käyttäjän järjestelmän tavoitteena on usein yhtäaikaisen käytön salliminen maksimaalisesti, joten tapahtumien suorittaminen vain peräkkäin on huono vaihtoehto Niiden tapahtumien, jotka käsittelevät eri osia (relaatioita) tietokannasta, suhteen ei ole tarpeen rajoittaa suoritusjärjestystä tai samanaikaista suorittamista Tapahtumat, jotka käsittelevät samoja tietoja (relaatioita), täytyy hallita niin, ettei edellä mainittuja tilanteita pääse tapahtumaan

Jos kaksi tapahtumaa vain lukee samoja tietoja (relaatioita), niiden suorituksessa ei ole sekaannuksen vaaraa ja järjestyksellä ei ole väliä Jos kaksi tapahtumaa lukee ja kirjoittaa eri tietoja (relaatioita), niiden suorituksessa ei ole sekaannuksen vaaraa ja järjestyksellä ei ole väliä Jos yksi tapahtuma kirjoittaa samoja tietoja (relaatioita) kuin toinen tapahtuma lukee tai kirjoittaa, niin tulee suorittaa tietyssä järjestyksessä

Seuraavassa esimerkki tapahtumista, joiden järjestys on tärkeä Ensimmäinen tapahtuma siirtää 100 yksikköä yhdestä tietokannan objektista (relaation ominaisuudesta) toiseen Toinen tapahtuma korottaa edellä mainittujen kummankin tietokannan objektin (relaation ominaisuuden) arvoa 10%:lla

Tapahtumien hoitaminen Lukitukset (1/6)
Lukitusta käytetään tapahtumien toimenpiteiden kontrollointiin tietojen hakujen / päivitysten saattamiseksi loogisiksi Kun yksi tapahtuma päivittää jotain tietokannan objektia (relaatiota), muut tapahtumat eivät pääse muuttamaan tätä objektia, ennen kuin lukitus on ensimmäinen tapahtuma on vapauttanut objektin Lukitus voi olla luku- tai kirjoituslukko Read lock Jos tapahtumalla on lukulukko, se voi lukea tietoa mutta ei kirjoittaa Write lock Jos tapahtumalla on kirjoituslukko, se voi sekä lukea että kirjoittaa Lukulukko ei voi saada sekaannusta aikaan, joten useammalla tapahtumalla voi olla lukulukko samaan objektiin (relaatioon)

Lukituksia käytetään seuraavasti: Tapahtuma, joka haluaa käyttöön jonkin tietokannan objektin (relaation), lukitsee ko. objektin käyttöönsä sen mukaan, tarvitseeko sen lukea vai kirjoittaa tietoa Jos tietokannan objekti (relaatio) ei ole ennestään lukittu minkään toisen tapahtuman toimesta, lukitus onnistuu Jos tietokannan objekti (relaatio) on jo lukittu toisen tapahtuman toimesta, tietokanta tarkistaa, voiko uuden lukituspyynnön toteuttaa; kirjoituslukko estää toisen tapahtuman saamasta edes lukulukkoa toteutumaan Tapahtuma pitää tietokannan objektin (relaation) lukitusta itsellään, kunnes se joko vapauttaa lukituksen tai tapahtuman suoritus päättyy (commit); kun kirjoituslukko vapautuu, muut tapahtumat voivat nähdä muuttuneen tiedon Yksinkertaisella lukituksella ei vielä päästä eroon sekaannuksista

S = {write_lock(T9, balx), read(T9, balx), write(T9, balx), unlock(T9, balx), write_lock(T10, balx), read(T10, balx), write(T10, balx), unlock(T10, balx), write_lock(T10, baly), read(T10, baly), write(T10, baly), unlock(T10, baly), commit(T10), write_lock(T9, baly), read(T9, baly), write(T9, baly), unlock(T9, baly), commit(T9)}

Kaksivaiheinen lukitus (two-phase locking, 2PL) Kun tapahtuma noudattaa kaksivaiheista lukitusta, kaikki lukitusoperaatiot edeltävät kaikkia lukituksien vapautusoperaatioita Kun tapahtuma vapauttaa jonkin lukon, se ei voi enää lukita mitään tietokannan objektia (relaatiota)

Tapahtumien hoitaminen Lukkotilanne (deadlock)
Lukkotilanne syntyy silloin, kun kaksi tai useampi tapahtuma jää odottamaan toisen / toisien tapahtumien lukkojen vapautusta Lukkotilanteesta päästään vai yhdellä tavalla eroon: keskeyttämällä yksi tai useampi tapahtuma, jolloin tämän tapahtuman lukitukset vapautuvat

Tapahtumien hoitaminen Lukitustasot

Tietokannan palautus Tietokannan palautuksella tarkoitetaan sitä prosessia, jossa tietokanta saatetaan eheään ja toimivaan tilaan sen jälkeen, kun se on syystä tai toisesta joutunut epäsuotuisaan tilaan tai kaatunut Milloin tietokannan palautusta tarvitaan? Järjestelmä kaatuu ohjelmistosta tai laitteista johtuneeseen virheeseen ja menetetään muistinvaraiset operaatiot Median toimimattomuus: media (esim. kiintolevy), joka on osa järjestelmää, tuhoutuu Sovellusohjelman virhe aiheuttaa loogisen virheen, kun jokin tai jotkin tapahtumat toimivat virheellisesti Luonnonkatastrofi tms. (tulipalo, sähkökatkos) Huolimattomuus (käyttäjät, ylläpitäjät) Ilkivalta, joka voi kohdistua järjestelmään, ohjelmistoon, laitteisiin tms.

Tapahtumat ja niiden palautus
Tapahtumat ovat perusyksikköjä palautettaessa järjestelmää Palautuksen hoitajan tulee tarkistaa, että kaikki tapahtuman vaikutukset (toiminnot) ovat lopullisesti tallennettu tietokantaan tai ei mitään tapahtuman toimintoa Asiasta tekee mutkikkaan se, että tapahtuman hyväksymisen (commit) jälkeen tapahtumatietoja ei välttämättä ole ehditty kirjoittaa tietokantaan ennen kuin virhe ilmaantuu

Mitä tapahtumassa oikein tapahtuu Esimerkki palkankorotuksesta
Lukuoperaatio Etsitään levyosoite, jossa haettavan rivin tiedot sijaitsevat (perusavaimen mukaan haetaan) Siirretään levyltä tiedot (lohko, sivu) tietokannan puskuriin muistiin Kopioidaan palkka tietokannan puskurista muuttujaan Kirjoitusoperaatio Etsitään levyosoite, jossa päivitettävän rivin tiedot sijaitsevat (perusavaimen mukaan etsitään) Kopioidaan palkka muuttujasta tietokannan puskuriin Kirjoitetaan tietokannan puskurin sisältö levylle

Virhetilanne Virhetilanne voi tulla kesken mitä tahansa em. toimintoa
Jos virhe tulee silloin, kun tapahtuma on suoritettu loppuun, mutta kirjoitus tietokantaan ei ole valmis, niin palautuksessa tämä on otettava huomioon Palautuksen hoitaja voi suorittaa kesken jääneet toiminnot loppuun (rollforward) tai hylätä tapahtuman (undo,rollback) Jos vain yksittäinen tapahtuma joudutaan hylkäämään, on kyseessä osittainen hylkääminen (partial undo) Jos taas kaikki tapahtumat, jotka ovat jääneet kesken, joudutaan hylkäämään, kyseessä on kokonaisvaltainen hylkääminen (global undo)

Tapahtumat ja virhetilanne
Kuvassa yllä on havainnollistettu tapahtumien T1-T6 kulkua Tapahtumat alkavat ajanhetkellä t0 ja ajanhetkellä tf tapahtuu virhetilanne Tapahtumat T1 ja T6 jäävät kesken virhetilanteen sattuessa (nämä täytyy peruuttaa palautuksen yhteydessä) Mitä tehdään tapahtumille T2 – T5

Palautuksen mahdollisuudet
Varmuuskopioinnin mahdollisuus, joka tapahtuu säännöllisesti tietyn ajanjakson välein Lokitiedostojen olemassaolo, jotka huolehtivat tietokannan tapahtumien nykytilan muutosten tallennukset Tarkistuspisteiden olemassaolo, jolloin tietokannan tietojen kirjoitus varsinaiseen tietokantaan tapahtuu Palautuksen hoitaja, joka mahdollistaa tietokannan palautuksen johonkin virhettä edeltäneeseen sallittuun tilaan

Lokitiedosto Tiedonhallintajärjestelmä käyttää lokitiedostoa tallentaakseen tietokantaan tehtävät päivitykset ennen niiden kirjaamista varsinaiseen tietokantaan Tapahtumatiedot (transaction records) Tapahtuman tunniste Tapahtumatiedon tyyppi (aloitus, lisäys, päivitys, poisto, kumous, commit) Tietoalkioiden (tietueiden) tunnistetiedot Kuvaus ennen tapahtumaa Kuvaus tapahtumien jälkeen Tiedot esim. edellisestä ja seuraavasta tapahtumasta Tarkistuspisteen tiedot (checkpoint records) Lokitiedostoa käytetään moneen muuhunkin tarkoitukseen kuin tietokannan tietojen palautukseen, mutta näistä ei tässä vaiheessa enempää

Tarkistuspiste Tarkistuspisteitä (check point) käytetään synkronoimaan tietokannan ja lokitiedoston Tarkistuspisteessä suoritetaan: Kirjoitetaan kaikki lokitiedot tietokantaan Kirjoitetaan tietokantapuskureissa olevat tiedot tietokantaan Kirjoitetaan tarkistuspisteen tiedot lokitiedostoon, joka sisältää mm. tiedot loppuun suorittamattomista tapahtumista Edellä esimerkissä tc oli tarkistuspiste, jolloin ym. toimenpiteet suoritetaan Palautus helpottuu, koska vain tapahtumat T4 ja T5 täytyy kirjoittaa tietokantaan sekä peruuttaa tapahtumat T1 ja T6

Hakujen käsittely Hakujen käsittelyssä on tarkoitus kirjoittaa hakulause korkean tason kielellä (kuten SQL) oikein ja tehokkaasti käyttäen matalan tason kuvausta hyväksi (relaatioalgebra) Hakujen optimoinnilla yritetään saada tietty tietojoukko haettua tietokannasta mahdollisimman tehokkaalla tavalla Usein saman lopputuloksen voi saada useammalla eri hakutavalla; näistä eri tavoista valitaan se, joka on tehokkain Esimerkki: ajatellaan, että taulussa STAFF on 1000 riviä, BRANCH –taulussa 50 riviä, 50 esimiestä (yksi jokaisessa yksikössä) ja 5 yksikköä Lontoossa SELECT * FROM STAFF S, BRANCH B WHERE S.BNO = B.BNO AND (S.POSITION = ’MANAGER’ AND B.CITY = ’LONDON’); Miten haku esitetään relaatioalgebralla?

Hakujen käsittely voidaan jakaa neljään osaan

Hakujen käsittely Haun hajottaminen
Muunnetaan korkean tason kysely relaatioalgebraksi Tarkistetaan, että haun syntaksi ja semantiikka ovat oikein Tämä vaihe jaetaan seuraaviin osiin: Analyysi Luodaan lehtisolmu jokaisesta perusrelaatiosta Seuraava solmu luodaan relaatioalgebran operaatiosta Juurisolmu kuvaa haun lopputulosta Operaatioiden järjestys kulkee lehdistä juureen Normalisointi Muutetaan haku normalisoituun muotoon, jota on helpompi muokata Konjunktio: sisältää konjunktioita, jotka ovat kytketty toisiinsa Ù (AND) –operaattorilla (position = ’Manager’ Ú salary > 20000) Ù bno = ’B3’ Disjunktio: sisältää disjunktioita, jotka ovat kytketty toisiinsa Ú (OR) –operaattorilla (position = ’Manager’ Ù bno = ’B3’) Ú (salary > Ù bno = ’B3’)

Hakujen käsittely Haun hajottaminen
Jatkoa… Semantiikan tarkistus Tarkistetaan, ettei haku sisällä loogisesti mahdottomia ehtoja (position = ’Manager’ Ù position = ’Assistant’) Yksinkertaistaminen Karsitaan turhat ehdot, esimerkiksi: p Ù (p) º p p Ú (p) º p p Ù (~p) º false p Ú (~p) º true Uudelleenjärjestely Haku järjestellään niin, että edellä esitetyt tulevat huomioiduiksi ja saadaan relaatioalgebran kannalta oikeanlainen haku

Hakujen käsittely Hakujen optimointi
Käytetään relaatioalgebran muunnossääntöjä Hakuehtojen järjestyksen vaihtaminen Esimerkkejä Projektioiden yksinkertaistaminen (sisäkkäiset projektiot) Relaatioiden järjestyksen vaihtaminen Liitosten vaihdannaisuus Leikkausten vaihdannaisuus

Hajautetut tietokannat Johdantoa 1
Loogisesti yhteenkuuluva jaettu tietokokoelma (ja kuvaus tästä tiedosta), joka on fyysisesti hajautettu tietoverkon yli Hajautettu tiedonhallintajärjestelmä tarkoittaa järjestelmää, joka huolehtii hajautettujen tietokantojen hoitamisesta niin, että ne ovat läpinäkyviä käyttäjille (käyttäjien ei tarvitse tietää, että tietokanta on hajautettu) Hajautettu tiedonhallintajärjestelmä koostuu yksittäisistä loogisesti toimivista tiedonhallintajärjestelmistä, jotka kukin hoitaa yhtä osaa hajautetusta tietokannasta Jokainen yksittäinen tietokanta on yhdellä (tai useammalla) palvelimella, joka on yhdistetty yhteiseen tietoverkkoon Jokainen yksittäinen tiedonhallintajärjestelmä toimii itsenäisesti palvellen ”omia” käyttäjiään, jotka ovat kytkeytyneet paikalliseen tietokantaan Käyttäjät käyttävät tietokantaa sovellusohjelmilla

Käyttäjillä on kahdenlaisia sovellusohjelmia: Paikallisia, jotka operoivat vain paikallisen tietokannan kanssa Globaaleja, jotka operoivat sekä paikallisen että etätietokannan kanssa Vaatimuksena on, että vähintään yksi sovellusohjelma on globaali Käyttäjillä ei tarvitse välttämättä olla paikallista tietokantaa ollenkaan, jolloin operoidaan ainoastaan etätietokantojen kanssa

Hajautettujen tietokantojen kohdalla on tehtävä ero hajautettuun tiedonkäsittelyyn Hajautetulla tiedonkäsittelyllä tarkoitetaan keskitettyä tietokantaa, johon otetaan yhteys tietoverkossa olevilta työasemilta Oleellinen näkökohta hajautettujen tietokantojen kohdalla on se, että tiedot (tietokannoissa) on hajautettu fyysisesti verkossa Jos tietokanta on keskitetysti jossakin (palvelimella) kyseessä on hajautettu tiedonkäsittely, vaikka työasemat olisivat verkotettuna

Tietokantojen hajauttamisessa on tehtävä ero rinnakkaisten tiedonhallintajärjestelmien osalta Tiedonhallintajärjestelmä toimii usean prosessorin ja levyn järjestelmässä, joka on suunniteltu suorittamaan operaatiot rinnakkaisesti mikäli mahdollista Kolme pääarkkitehtuuria rinnakkaisissa tiedonhallintajärjestelmissä Jaettu muisti Esimerkki Jaettu levytila Ei mitään jaettua

Hajautetut tietokannat Katsaus verkkoihin
Tietoverkko Itsenäisistä tietokoneista yhdistetty kokonaisuus, jossa eri komponentit voivat vaihtaa tietoja Hajautetut tiedonhallintajärjestelmät ovat rakennettu niin, että käyttäjä ei näe tietoverkkoa, vaan ainoastaan käyttää sitä (tietämättään) Tietojen siirtoon vaikuttaa käytössä oleva tietoverkko LAN Local area network – paikallisverkko Siirtonopeus 10 – 100 Mb/s WAN Wide area network – laaja-alainen verkko Siirtonopeus 2 – 2000 kb/s Koostuu usein useammasta LAN -verkosta

Hajautetut tietokannat Funktiot ja arkkitehtuuri
Toimiakseen hajautettujen tiedonhallintajärjestelmien on Laajennettu yhteyspalvelu etäpalvelimilta ja mahdollisuus hakujen ja tiedon siirtoon palvelinten välillä Laajennettu järjestelmähakemisto, jossa tiedot yksityiskohtaisesti hajautetuista tiedoista Hajautettu hakujen käsittely sisältäen hakujen optimoinnin ja etäkäytön Laajennettu samanaikaisuuden hallinta toistetun tiedon yhtenäisyyden säilyttämiseen Laajennettu palautusmekanismi yksittäisessä tiedonhallintajärjestelmässä ja tietoverkossa sattuvien virheiden varalta

Hajautetut tietokannat Hajautetun relaatiotietokannan suunnittelu
Paloittelu (fragmentation) Relaatio voidaan jakaa lukuisiin alirelaatioihin, jotka ovat hajautettuja Horisontaalinen paloittelu jakaa relaation rivit Vertikaalinen paloittelu jakaa relaation ominaisuudet (attribuutit, sarakkeet) Jakautuminen Jokainen pala (fragment) on talletettu palvelimelle optimaalisesti hajautettuna Toistaminen Hajautettu tiedonhallintajärjestelmä voi sisältää kopion palasta (fragment) toisella palvelimella

Hajautetut tietokannat Hajautetun relaatiotietokannan suunnittelu
Miksi suunnitella hajautettu tietokanta? Käyttö Sovellukset käyttävät näkymiä eivätkä suoraan relaatioita, jolloin näkymän tiedot ovat yksi hajautuksen osa Tehokkuus Tiedot on tallennettu lähelle käyttäjää ja näin ei tarvita hidasta tietojen siirtoa palvelimelta toiselle Rinnakkaisuus Hakujen jako alihakuihin, jotka käsittelevät paloja (fragments), mahdollistaa hakujen rinnakkaisuuden ja näin parantaa vasteaikaa Turvallisuus Tiedot, joita ei tarvita jossakin tietyssä paikassa, eivät myöskään ole siellä ja näin niiden väärinkäyttö on vaikeampaa Haittoja Suorituskyky sovelluksilla, jotka käyttävät tietoja eri palvelimilta, laskee Yhtenäisyyden hallinta on mutkikkaampaa

Hajautetut tietokannat Läpinäkyvyys
Perusajatus tiedonhallintajärjestelmän hajauttamisessa on se, ettei käyttäjän tarvitse tietää hajauttamisesta mitään Myöskään käyttäjän ei tuli nähdä hajautusta millään tavalla käyttäessään sovelluksia Läpinäkyvyys voidaan jakaa neljään alueeseen Hajautuksen läpinäkyvyys Käyttäjä näkee tietokannan yhtenäisenä kokonaisuutena Tapahtumien läpinäkyvyys Tapahtumat jaetaan alitapahtumiin, jotka ohjataan oikealle palvelimelle Käyttäjälle tapahtuman tulokset näkyvät kuin ne tulisivat keskitetystä tietokannasta Suorituskyvyn läpinäkyvyys Käyttäjän ei tulisi huomata suorituskyvyssä eroa keskitettyyn tietokantaan Tiedonhallintajärjestelmän läpinäkyvyys Käyttäjän ei tarvitse tietää eri tiedonhallintajärjestelmien eroja, mikäli käytössä on eri järjestelmät eri palvelimilla

Hajautetut tietokannat Sääntöjä
Perusperiaate Käyttäjälle hajautettu tiedonhallintajärjestelmä tulisi näyttää samanlaiselta kuin keskitetty tiedonhallintajärjestelmä Paikallinen itsenäisyys Paikallinen tieto on paikallisen ylläpitäjän omistama ja ylläpitämä Paikalliset toiminnot ovat puhtaasti paikallisia Kaikki tietyn palvelimen toiminnot ovat ko. palvelimen hallinnoimia Käytön jatkuminen Ei ole tarvetta järjestelmän alasajoon, kun yksi palvelin poistetaan käytöstä Palvelimiin voidaan lisätä tai poistaa dynaamisesti paloja (fragments) Paikkariippumattomuus Käyttäjän tulee päästä mistä tahansa tietoverkossa haluttuun tietoon käsiksi Paloitteluriippumattomuus Käyttäjä pääsee tarvitsemiinsa tietoihin käsiksi, oli ne miten tahansa paloiteltuja

Hajautetut tietokannat Sääntöjä 2
Toistoriippumattomuus Käyttäjän ei tule tietää tietojen kopioimisesta palvelimelta toiselle Hajautettu hakujen käsittely Järjestelmän osaa käsitellä hakuja, jotka kohdistuvat eri palvelimille Hajautettu tapahtumien käsittely Tapahtumat käsitellään jakamattomina yksiköinä (palautuksessa) Rautariippumattomuus Järjestelmä ei ole riippuvainen tietystä arkkitehtuurista Käyttöjärjestelmäriippumattomuus Järjestelmä ei ole riippuvainen tietystä käyttöjärjestelmästä Tietoverkkoriippumattomuus Järjestelmä ei ole riippuvainen tietoverkon rakenteesta Tietokantariippumattomuus Eri palvelimilla voi olla erilainen tietokanta

Hajautetut tietokannat Tapahtumien käsittely
Globaalin tapahtuman hoitaminen tapahtuu seuraavasti: Tapahtumien koordinoija (transaction coordinator, TC) TC1 palvelimella S1 jakaa tapahtuman alitapahtumiin käyttäen hyväkseen globaalia järjestelmäluetteloa (system catalog) Tiedonvälityspalvelu palvelimella S1 lähettää alitapahtumat muille palvelimille (S2, S3, …) Tapahtumien koordinoijat palvelimilla S2, S3, … käsittelevät saamansa tapahtumat ja tulokset lähetetään takaisin lähettävälle tapahtumien käsittelijälle TC1

Hajautetut tietokannat Lukitukset
Keskitetty kaksivaiheinen lukitus Tapahtumien koordinaattori palvelimella S1 jakaa tapahtuman alitapahtumiin, jotka lähetetään eteenpäin Jos päivitettävästä tiedosta on kopioita eri palvelimilla, nämä täytyy huomioida Ensin asetetaan kirjoituslukko kaikkiin kopioihin ja sitten vasta tehdään päivitys Paikallinen tapahtumien hoitaja, joka on osa globaalia tapahtumien kutsua, hoitaa pakallisesti lukitusten vapauttamisen normaalin kaksivaiheisen lukitustavan mukaisesti Keskitetty lukitusten hoitaja tarkistaa, että lukituspyynnöt ovat yhdenmukaiset olemassa olevien lukitusten kanssa Jos kaikki on kunnossa, lähtee alkuperäiselle tapahtumien koordinaattorille palaute onnistuneesta lukituksesta Muussa tapauksessa lukituspyynnöt laitetaan odottamaan

Hajautetut tietokannat Lukkotilanne
Lukkotilanne syntyy seuraavasti: Tapahtuma T1 käynnistyy palvelimella S1 ja pyytää kirjoituslukkoa palvelimelle T2 Tapahtuma T2 käynnistyy samaan aikaan palvelimella S2 ja pyytää kirjoituslukkoa palvelimelle T3 Tapahtuma T3 käynnistyy edellisten tapahtumien kanssa samanaikaisesti ja pyytää kirjoituslukkoa palvelimelle T1

Hajautetut tietokannat Palautus
Virhetilanteita hajautetussa tietojärjestelmässä Viestin menetys Tiedonvälityslinkissä on jokin vika Jokin palvelin ei vastaa pyyntöihin Tietoverkon jaossa on vikaa Asiasta tekee monimutkaisemman se, ettei tiedonvälityslinkki tai palvelin toimi halutussa ajassa (ja näin ollen pyynnöstä tulee virhe), koska Palvelin on pois käytöstä Tiedonvälityslinkki ei toimi Palvelin on niin kuormitettu, ettei se pysty vastaamaan pyyntöön vaaditussa ajassa

Oliotietokannat Johdantoa
Perinteisiä tietokantasovelluksia ovat Kaupalliset sovellukset, kuten tilausten käsittely, inventaarioiden hallinta, pankkitoiminta ja lentokoneiden varausjärjestelmä Olemassa olevat relaatiotietokannat eivät ole riittäviä perinteisiä kaupallisia sovelluksia vaativampiin sovellusalueisiin Tietokoneavusteinen suunnittelu (CAD) Tietokoneavusteinen tuotanto (CAM) Tietokoneavusteinen ohjelmistotuotanto (CASE) Toimistojen tietojärjestelmät (OIS) Digitaalinen kustannustoiminta Maantieteelliset tietojärjestelmät (GIS)

Oliotietokannat Relaatiotietokantojen heikkoudet (1/2)
Reaalimaailman olioiden puutteellinen kuvausmahdollisuus Normalisoinnissa oliot (relaatiot) muuntuvat ei-reaalisiksi Merkitysten liikakuormittaminen Kahden relaation välille voidaan luoda vain relaatiomallissa kuvattu yhteys Puutteellinen tuki rajoituksille ja yhtenäisyyden muodostamiselle Kaikki kaupalliset järjestelmät eivät toteuta SQL:n mukaisia rajoitteita ja osa näistä joudutaan rakentamaan sovelluksiin Yhtenäinen tietorakenne Kaikki relaation rivit sisältävät samat ominaisuudet, vaikka niitä ei tarvittaisi Tietyn ominaisuuden arvot kaikilla riveillä ovat peräisin samasta arvojoukosta Rajoitetut operaatiot Relaatio-operaatiot perustuvat joukko ja rivi operaatioihin Johdettujen operaatioiden mahdollisuutta ei ole Joillekin reaalimaailman olioille ei ole operaatioita ollenkaan (esim. pisteiden, viivojen, monikulmioiden operaatiot)

Oliotietokannat Relaatiotietokantojen heikkoudet (2/2)
Hankalasti hallittavat sisäkkäiset haut Ominaisuuksien jakamattomuus tarkoittaa sitä, ettei ryhmäominaisuuksia sallita Tämä tuottaa ongelmia sisäkkäisissä hakutarpeissa, esimerkiksi haetaan kaikki esimiehet tietylle työntekijälle: SELECT manager_id FROM staff WHERE staff_id = ’S1’ UNION SELECT manager_id FROM staff WHERE staff_id = (SELECT manager_id FROM staff WHERE staff_id = ’S1’) Näennäinen yhdistäminen SQL –standardin puutteita on paikattu eri tuotteissa eri tavoilla Tietotyyppimuunnokset SQL:n ja sovellusohjelman välillä

Oliotietokannat Oliokeskeiset käsitteet
Ennen kuin saamme käsitystä oliomallista, tarvitaan taustatietoa joistakin käsitteistä Abstraktio (abstraction) Abstraktiolla tarkoitetaan prosessia, jossa identifioidaan olion tärkeät piirteet Unohdetaan vähemmän tärkeät ominaisuudet Ensin suunnitellaan, mikä olio on ja mitä se tekee, sen jälkeen kuinka se toteutetaan Kapselointi (encapsulation) Kapseloinnilla tarkoitetaan sitä, että olion sisältämät tiedot ja niiden muokkaamiseen tarkoitetut operaatiot on koottu olion sisälle Tiedon piilottaminen (information hiding) Tiedon piilottamisella tarkoitetaan sitä, että olio sisältää sellaisia ominaisuuksia, joita ei ulkomaailma (olion ulkopuolinen) näe Piilotettuihin tietoihin pääsee käsiksi vain olioon liitettyjen operaatioiden avulla

Oliotietokannat Oliot ja ominaisuudet
Useat oliosuuntautuneet käsitteet on johdettu Simula –ohjelmointikielestä, joka suunniteltiin Norjassa 1960 –luvun puolivälissä Vasta SmallTalk –ohjelmointikieli toi olio-ohjelmoinnin todella näkyville 1980 –luvulla Olio on yksikäsitteisesti identifioitu kokonaisuus, joka sisältää sekä ominaisuudet, jotka kuvaavat sen ilmentymää todellisessa maailmassa, että operaatiot, jotka ovat yhdistetty siihen

Oliotietokannat Olioiden yksilöinti
Olion määrittelyn avainasioihin kuuluu yksikäsitteinen tunnistaminen Oliosuuntautuneissa järjestelmissä jokainen olio sisältää tunnisteen (OID, Object Identifier), joka on Järjestelmän generoima Numeerinen, jolloin vie vähän tilaa ja nopea käsitellä Ei muodostu useasta ominaisuudesta, kuten relaatioissa on mahdollista Kahdella eri tyyppisellä oliolla ei ole samaa tunnistetta Yksikäsitteinen jokaiselle oliolle Riippumatta siitä, minkä tyyppinen olio on Invariantti eli olion elinkaaren aikana sitä ei voi muuttaa Järjestelmä ei generoi ”puuttuvia” tunnisteita uudestaan Riippumaton olion sisältämistä ominaisuuksista Käyttäjälle näkymätön (ideaalitapauksessa)

Oliotietokannat Jäsenfunktiot ja viestit
Olioon on kapseloituna sekä olion sisältämä tieto että näiden tietojen käsittelyyn tarvittavat funktiot, joita kutsutaan jäsenfunktioiksi (metodit) Jäsenfunktio voi olla esim. method void update_salary(float increment) { salary = saraly + increment; } Jäsenfunktio koostuu nimestä ja funktion rungosta Jäsenfunktioon voidaan tehdä tarkistukset, joiden perusteella päivitys hyväksytään tai hylätään Viesteillä objektit kommunikoivat keskenään, ts. objekti lähettää toiselle objektille viestin ”päivitä palkka 1000 mk:lla”, jolloin viestin saavan objektin jäsenfunktio päivittää ko. tiedon Esim. staff_object.update_salary(1000)

Oliotietokannat Luokat
Luokka –käsitteellä voidaan määritellä samanlaiset oliot Oliot, joilla on samat ominaisuudet ja jotka vastaavat samanlaisiin viesteihin, ryhmitellään saman luokan olioiksi Ominaisuudet ja jäsenfunktiot määritellään vain luokalle, joten niitä ei tarvitse määritellä jokaiselle oliolle erikseen Kuitenkin jokaisella oliolla on omat arvonsa olion sisältämille ominaisuuksille Luokan olioita kutsutaan myös luokan ilmentymiksi (instance) Joissakin oliosuuntautuneissa järjestelmissä luokka voidaan käsittää myös jonkinlaiseksi olioksi, jolla on omat luokkaominaisuudet ja luokan jäsenfunktiot Nämä luokan ominaisuudet ovat samoja kaikille luokan ilmentymille (olioille)

Oliotietokannat Luokan ilmentymät

Oliotietokannat Alaluokat, yliluokat ja perintä
Jotkin oliot voivat olla hyvin samankaltaisia, mutta eivät kuitenkaan niin samanlaisia, että ne voisivat olla saman luokan ilmentymiä Jos suuri osa ominaisuuksista ja jäsenfunktioista ovat samanlaisia, ei ole järkevää tehdä täysin erillistä luokkaa, vaan hyödyntää olemassa olevan luokan ominaisuuksia ja jäsenfunktioita Perintä mahdollistaa jonkin luokan määrittelyn samankaltaiseksi kuin olemassa oleva luokka, mutta kuitenkin ko. luokalla voi olla omat lisäominaisuutensa ja jäsenfunktionsa Toisesta luokasta määritelty luokka on aliluokka (subclass) ja luokka, josta tämä on peritty on yliluokka (superclass) Etsittäessä useasta luokasta samoja ominaisuuksia ja tekemällä näille yhteinen yliluokka kyseessä on yleistys (generalization) Määrittelemällä jollekin luokalle erikoistapaus (aliluokka) kyseessä on erikoistuminen (specialization)

Oliotietokannat Perintä

Oliotietokannat Ylikirjoittaminen
Joskus yliluokassa on sellainen ominaisuus tai jäsenfunktio, jota tarvitaan aliluokassa, mutta ominaisuudet ovat erilaiset Tällaisessa tilanteessa yliluokan jäsenfunktio ylikirjoitetaan aliluokassa niin, että aliluokassa käytetään omaa jäsenfunktiota, vaikka yliluokassa on samanlainen jäsenfunktio Esim. yliluokassa method void give_commission(float branch_profit) { salary = salary * branch_profit; } Ja aliluokassa method void give_commission(float branch_profit) { salary = salary * branch_profit; }

Oliotietokannat Ylikuormittaminen
Joskus jäsenfunktiot voivat olla hyvin samankaltaisia, mutta kuitenkin toisessa jäsenfunktiossa tarvitaan useampi parametri kuin toisessa Tällaiset jäsenfunktiot voidaan kirjoittaa täysin toisistaan erillisiksi jäsenfunktioiksi, mutta tällöin tehdään turhaan samankaltaisia määrittelyjä Ylikuormittamalla jäsenfunktio voidaan tehdä useampi saman niminen jäsenfunktio, jotka eroavat toisistaan parametriensa suhteen Oliolle tuleva viesti määrää, mitä jäsenfunktiota käytetään, koska viestin mukana tulevat parametrit sopivat vain yhteen jäsenfunktioon Jäsenfunktiot voidaan rakentaa niin, että ne kutsuvat toisiaan, jolloin samaa määritystä ei tarvitse kirjoittaa useaan kertaan

Tietoverkko ja tiedonhallintajärjestelmät Johdantoa (1/3)
Mikä on tietoverkko (internet)? Maailmanlaajuinen kokoelma toisiinsa liitettyjä tietokoneverkkoja Liitetyt tietoverkot eivät ole välttämättä samanlaisia arkkitehtuuriltaan Internet sisältämiin palveluihin kuuluu mm. sähköposti Lyhenteitä TCP/IP (Transmission Control Protocol and Internet Protocol) Tietojen välitykseen tietokoneiden välillä oikein ja oikeaa osoitteeseen FTP (File Transfer Protocol) Käytetään tiedostojen siirtoon SMTP (Simple Mail Transfer Protocol) Sähköpostitietojen välittämiseen Telnet (Telecommunication Network) Pääteyhteys DNS (Domain Name Service) POP (Post Office Protocol)

Intranet Tietoverkon osa, joka on tietyn organisaation käytettävissä eikä siihen ole pääsyä ulkopuolelta Extranet Tietoverkon osa, joka on tietyn organisaation käytettävissä ja siihen on pääsy myös ulkopuolelta tietyille käyttäjille The World Wide Web Hypermediapohjainen järjestelmä, joka mahdollistaa yksinkertaisten ’osoita ja napsauta’ hyperlinkkien olemassaolon dokumenteissa HyperText Transfer Protocol (HTTP) Dokumenttien siirtoon tarkoitettu internet protokolla HyperText Markup Language (HTML) Dokumenttien tekoon tarkoitettu kuvauskieli Uniform Resource Locator URL Merkkijono tai numeerinen osoite internet-resurssiin

Staattiset sivut HTML dokumentti on staattinen, jos se on tallennettu sellaisessa muodossa, että se näkyy jokaisella katselukerralla samanlaisena Sivu sisältää vain muotoiluun liittyviä HTML määrittelyjä Dynaamiset sivut HTML dokumentti on dynaaminen, jos se generoidaan jokaisella katselukerralla erikseen, jolloin dokumentti voi näyttää hyvinkin erilaiselta eri kerroilla Käyttäjän antamien syötteiden perusteella voidaan generoida sivu; esimerkiksi käyttäjä täyttää lomakkeen ja syötettyjen tietojen perusteella vastauksen Käyttäjäkohtaisesti voidaan näyttää jokin sivu erilaisena eri käyttäjille esimerkiksi käyttäjän aikaisempien käyntikertojen perusteella luodun profiilin avulla Tiedonhallintajärjestelmien kannalta ollaan kiinnostuneita lähinnä dynaamisten sivujen käytöstä, jolloin sivun sisältöön vaikuttaa esim. tietokannasta saatu hakutulos

Tietoverkko ja tiedonhallintajärjestelmät Tietoverkko tietokantasovelluksen alustana (1/3)
Perinteinen kaksitasoinen työasema-palvelin ratkaisu ei kelpaa enää tietoverkkojen kanssa Kaksitasoisessa ratkaisussa tietokantapalvelimeen on kytkeytyneenä työasemia, joilta lähtevät tietokantapyynnöt menevät suoraan tietokantapalvelimelle suoritettavaksi Työasema Käyttäjän liittymä Tiedonkäsittelylogiikka Tietokantapalvelin Palvelimen vahvistus operaatioille Tietokantaoperaatiot

Mitä vaatimuksia tietoverkko asettaa tietokantasovelluksille? Mahdollisuus päästä yrityksen tietoihin suojatulla tavalla Mahdollisuus valita tietokantaratkaisu Riippumaton käytettävästä selaimesta ja verkkopalvelimesta Ratkaisun täytyy ottaa huomioon kaikki yrityksen tietokannan eri piirteet Avoin arkkitehtuuri Toimii erilaisilla verkkopalvelimilla Riippumaton käytettävästä protokollasta Ratkaisun tulee olla kannattava, jota voi laajentaa ja muuttaa tarpeiden mukaan Useamman HTTP –pyynnön hallinta Sovellus ja istuntokohtainen tunnistaminen Pääkäyttäjän tarpeen minimoiminen Korkean tason työkaluja sovellusten suunnitteluun ja rakentamiseen

Kaksitasoisen ratkaisun ongelmia Työaseman suorituskyky Pääkäyttäjän tarve Kolmetasoisessa ratkaisussa on edelliseen seuraavat edut Yksinkertainen työasema Tiedonhallintalogiikka ei ole hajautettu työasemille vaan on keskitetysti hallittavissa Parempi mahdollisuus korvata jokin komponentti toisella Kuormittavuuden tasapainottaminen helpompaa, kun tasoille on jaettu sopivasti tehtäviä

Tietoverkko ja tiedonhallintajärjestelmät Yhdyskäytävä (Common Gateway Interface, CGI)
Määritelmä tiedon siirtoon verkkopalvelimen ja CGI –sovelluksen välille

Tietoverkko ja tiedonhallintajärjestelmät Server-Side Includes, SSI
Miten SSI liittyy tietokantasovelluksiin? Normaalisti verkkopalvelin ei tutki HTML –tiedostoja, jotka se lähettää työasemalle (selaimelle) Verkkopalvelimeen on kuitenkin (usein) mahdollista määritellä, että tietyn tyyppiset sivut täytyy parsia ennen niiden lähettämistä työasemalle Parsinnassa HTML –dokumenttiin lisätään lähdetiedostossa olevien määritysten mukaisesti esim. dokumentin muutosaika tai lisätään jokin toinen tiedosto HTML –dokumentissa voi olla määritelty sellainen SSI –elementti, joka suoritetaan CGI –ohjelmana ja ohjelman tulokset lähetetään dokumentin osana Käyttäjä ei näe saamastaan dokumentista, että se on parsittu ja että siinä on esim. tietokannasta tulleita tietoja muuten kuin hakemalla dokumentin uudestaan, jolloin dokumentin sisältö voi olla erilainen

Tietoverkko ja tiedonhallintajärjestelmät HTTP:n keksit (Cookies)
Kekseihin voidaan tallentaa erilaista tietoa käyttäjästä tai hänen valinnoistaan Keksit talletetaan käyttäjän työasemaan, mikäli käyttäjä on tämän sallinut Voidaan käyttää esimerkiksi ostoskoria, johon kerätään palvelusta tietoja sen mukaan, kun käyttäjä on tehnyt valintoja Lopuksi käyttäjä lähettää ostoksensa, jolloin ostoskorin sisältö lähetetään palvelimelle Keksejä voidaan käyttää myös tietokantojen käyttäjätunnusten ja salasanojen tallentamiseen, jolloin käyttäjä tunnistetaan automaattisesti, kun hän vierailee uudestaan samalla sivulla / käyttää samaa sovellusta

Tietoverkko ja tiedonhallintajärjestelmät Mitä Java tuo tietokantasovelluksiin?
CGI –ohjelmat ajetaan palvelimella, joten suorittaakseen jonkin toimenpiteen käyttäjä lähettää pyynnön palvelimelle, joka lähettää vastauksen Tiedonsiirto voi muodostua pullonkaulaksi Javalla tehty sovellus (applet) toimii työasemassa (selaimessa), joten tiedonsiirtoa ei tarvita samassa mittakaavassa kuin CGI -ohjelmilla

Tietoverkko ja tiedonhallintajärjestelmät JDBC

Tietoverkko ja tiedonhallintajärjestelmät Turvallisuus
Mitä turvallisuusnäkökohtia liittyy tietoverkkoympäristöön? Turvallisuusnäkökohdat liittyvät lähinnä tietojen siirtoon Tietoon saa koskea vain lähettäjä ja vastaanottaja Tietoa ei ole muutettu lähetyksen aikana Vastaanottaja voi luottaa siihen, että tieto tulee lähettäjältä Lähettäjä voi luottaa siihen, että vastaanottaja on aito Lähettäjä ei voi kieltää lähettäneensä tietoa

Tietojen varastointi Johdantoa
Mitä tarkoitetaan tietojen varastoinnilla? Yrityksessä käytettävä tietojärjestelmä, jonka avulla tehdään pieniä muutoksia yrityksen tietokantaan päivittäisessä työskentelyssä, on ns. online transaction processing (OLTP) Päivittäisessä käytössä olevan tietokannan koko voi olla pieni (muutama MB), keskikokoinen (muutama GB) tai suuri (muutamasta TB:stä muutamaan PB:hen) Yrityksen päätöksentekijöillä on joskus tarve saada päivittäisten tietojen lisäksi käyttöönsä historiallista tietoa järjestelmässä olleista tiedoista, jolloin aktiivisista tietokannoista saatu tieto ei ole riittävä Tietojen varastointi (Data Warehousing) on syntynyt em. tarpeesta saada yrityksen historiallista tietoa käyttöön Haittoja Tiedon löytäminen Näkymättömät ongelmat esim. tiedon eheydessä nykyiseen järjestelmään Tiedon suojaus / omistus Varastointiprojektin pituus

Tietojen varastointi Arkkitehtuuri
Mitä komponentteja liittyy tietojen varastointiarkkitehtuuriin?

Tietokannat Tentti Pääpaino tentissä on relaatiotietokannoissa
Tietokannan suunnittelu / ER-malli Avainten etsiminen Normalisointi Relaatiomallin käsitteistö Relaatioalgebra ja –kalkyyli Tapahtumien hoitaminen / lukitukset Palautus ja hakujen käsittely Lisäksi kurssilla olleet Oliotietokantojen perusteita Mitä Web –teknologia tuo mukanaan tietokantoihin? Viimeisellä luentokerralla käydään koko kurssin sisältö läpi erilaisten kysymysten avulla

Onnea tenttiin !!!

Tietokannat Kevät 2009.

Samankaltaiset esitykset

Esitys aiheesta: "Tietokannat Kevät 2009."— Esityksen transkriptio:

Samankaltaiset esitykset

Projektista

Palaute

Kirjaudu sisään

Kirjaudu sisään sosiaaliverkostojen kautta:

Tietokannat Kevät 2009.

Samankaltaiset esitykset

Esitys aiheesta: "Tietokannat Kevät 2009."— Esityksen transkriptio:

Samankaltaiset esitykset

Projektista

Palaute