Relaatioista TIETOJENKÄSITTELYTIETEIDEN LAITOS, JUHA IISAKKA 11-14



Samankaltaiset tiedostot
HELIA 1 (17) Outi Virkki Tiedonhallinta

HELIA 1 (21) Outi Virkki Tietokantasuunnittelu

Relaatiomalli ja -tietokanta

TIETOKANNAN NORMALISOINTI JA NORMAALIMUODOT

HELIA TIKO-05 1 (20) ICT03D Tieto ja tiedon varastointi O.Virkki

NORMALISOINTI TIETOJEN MALLINNUS JOUNI HUOTARI & ARI HOVI

TIEDONHALLINNAN PERUSTEET - SYKSY 2013

5.1 Normalisoinnin tarkoitus 5.2 Funktionaalinen riippuvuus 5.3 Normaalimuodot. Luku 5. Normalisointi. ITKA204 kevät

Relaatiotietokantojen perusteista. Harri Laine Helsingin yliopisto

HELIA 1 (17) Outi Virkki Tiedonhallinta

HELIA 1 (19) Outi Virkki Tietokantasuunnittelu

Tietokantojen suunnittelu, relaatiokantojen perusteita

HAAGA-HELIA Heti-09 1 (27) ICT05 Tiedonhallinta ja Tietokannat O.Virkki

Normalisointi. Jouni Huotari & Ari Hovi. kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003, 2005) luku 5

CS-A1150 Tietokannat CS-A1150 Tietokannat / 43

CS-A1150 Tietokannat CS-A1150 Tietokannat / 43

CSE-A1200 Tietokannat

Luento L: Normalisointi

CS-A1150 Tietokannat CS-A1150 Tietokannat / 51

HELIA 1 (20) Outi Virkki Tiedonhallinta

HAAGA-HELIA TIKO-05 1 (19) ICT23a Tietokannan suunnittelu ja toteutus O.Virkki

SQL-perusteet, SELECT-, INSERT-, CREATE-lauseet

Mikä on tietomalli? Relaatiomallin käsitteitä 1/2 (kuva 5.1) Relaatiomallin taustaa

Kirjoita kuhunkin erilliseen vastauspaperiin kurssin nimi, tentin päiväys, oma nimesi, syntymäaikasi ja nimikirjoituksesi.

HAAGA-HELIA heti09 1 (27) ICT05 Tiedonhallinta ja tietokannat O.Virkki Relaatiomalli

2. Käsiteanalyysi ja relaatiomalli

Helsingin yliopisto Tietojenkäsittelytieteen laitos (H.Laine) Tietokantojen perusteet. Liitteenä: Tiivistelmä SQL-syntaksista

Helsingin yliopisto, Tietojenkäsittelytieteen laitos Tietokantojen perusteet, , H.Laine

Helsingin yliopisto/tktl Kyselykielet, s 2006 Relaatiokalkyylit. Harri Laine 1

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

TIEDONHALLINNAN PERUSTEET - SYKSY 2013

Kirjoita jokaiseen erilliseen vastauspaperiin kurssin nimi, tenttipäivä, oma nimesi (selkeästi), opiskelijanumerosi ja nimikirjoituksesi

HELIA 1 (19) Outi Virkki Tietokantasuunnittelu

HELIA TIKO-05 1 (28) ICT03D Tieto ja tiedon varastointi O.Virkki

Tietokantojen perusteet k2004helsingin yliopisto/tktl Tietokantojen perusteet, s 2005 relaatiomalli Harri Laine 1.

Kyselyt: Lähtökohtana joukko lukuja Laskukaava kertoo miten luvuista lasketaan tulos soveltamalla laskentaoperaatioita

Tietomallit. Näkökulmat tietoon. Näkökulmat tietoon. Mitä malleja olisi tarjolla? Abstraktiotasot tiedon käsittelyssä

CSE-A1200 Tietokannat

Helsingin yliopisto/tktl DO Tietokantojen perusteet, s 2000 Relaatiomallin peruskäsitteet Harri Laine 1. Relaatiotietokannat DONOTP

Relaatioalgebra. Kyselyt:

Tietokannan suunnittelu

CS-A1150 Tietokannat CSE-A1150 Tietokannat / 29

Relaatioalgebra. Relaatioalgebra. Relaatioalgebra. Relaatioalgebra - erotus (set difference) Kyselyt:

TIEDONHALLINTA - SYKSY Luento 11. Hannu Markkanen /10/12 Helsinki Metropolia University of Applied Sciences

HELIA 1 (12) Outi Virkki Tiedonhallinta

Helsingin yliopisto/ tktl DO Tietokantojen perusteet, s 2000 Relaatioalgebra Harri Laine 1. Relaatioalgebra

Tietokannan rakenteen suunnittelu

Tietokantasuunnittelun pääperiaatteena on tiedon toiston välttäminen. Tiedon toistumiseen liittyy monenlaisia ongelmia.

Hannes Ranta SOVELLUKSEN TIETOKANNAN UUDELLEENSUUNNITTELU

TIETOKANNAT JOHDANTO

Opintopiiritehtävä 3: Verkkohuutokauppa

TIETOKANTOJEN SUUNNITTELU

Tietokantojen perusteet k2004helsingin yliopisto/tktl Tietokantojen perusteet, k 2006 relaatioalgebra. Harri Laine 1

Luento 3 Tietokannan tietosisällön suunnittelu

CS-A1150 Tietokannat CS-A1150 Tietokannat / 44

Tiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas

Tietokantasuunnittelun pääperiaatteena on tiedon toiston välttäminen. Tiedon toistumiseen liittyy monenlaisia ongelmia

On autoja, henkilöitä, Henkilöllä on nimi Autolla on omistaja, joka on henkilö. Taulu AUTO(rekno, malli) Taulu HENKILO(nimi, )

Helsingin yliopisto/tktl Tietokantojen perusteet, k 2003 Relaatiomallin peruskäsitteet Harri Laine 1. Tietomallit. Näkökulmat tietoon

CSE-A1200 Tietokannat

TIEDONHALLINTA - SYKSY Luento 7. Pasi Ranne /10/17 Helsinki Metropolia University of Applied Sciences

millainen on se kohde, jota tiedoilla pitäisi kuvata asiat, joita pitäisi esittää Mitä tietoelementtien arvot tarkoittavat

CS-A1150 Tietokannat CS-A1150 Tietokannat / 34

Joukossa X määritelty relaatio R on. (ir) irrefleksiivinen, jos x Rx kaikilla x X,

CS-A1150 Tietokannat CSE-A1150 Tietokannat / 32

Relaation ominaisuuksia. Ominaisuuksia koskevia lauseita Sulkeumat. Joukossa X määritelty relaatio R on. (ir) irrefleksiivinen, jos x Rx kaikilla x X,

Tietokannan hallinta. Kevät 2004 Jan Lindström R&G Chapter 1

CS-A1150 Tietokannat CS-A1150 Tietokannat / 34

Käsitteellinen mallintaminen

Tietokannan suunnittelu

FinFamily PostgreSQL installation ( ) FinFamily PostgreSQL

TIETOKANTOJEN PERUSTEET MARKKU SUNI

Tietomallit. Näkökulmat tietoon. Näkökulmat tietoon. Näkökulmat tietoon. Abstraktiotasot tiedon käsittelyssä

Helsingin yliopisto, TKTL Tietokantojen perusteet, k 2004 Tietokannan suunnittelusta. Harri Laine 1

Valitsemalla sopivat alkiot joudutaan tämän määritelmän kanssa vaikeuksiin, jotka voidaan välttää rakentamalla joukko oppi aksiomaattisesti.

Denormalisointia turvallisesti. Ougf syysseminaari Pörssitalo Helsinki Timo Raitalaakso

FYYSINEN SUUNNITTELU

SQL - STRUCTURED QUERY LANGUAGE

TIETOKANTOJEN PERUSTEET OSIO 8 MARKKU SUNI

TIETOKANNAN JÄRKEISTÄMINEN

Other approaches to restrict multipliers

HELIA 1 (13) Outi Virkki Tietokantasuunnittelu

TIEDONHALLINTA - SYKSY Luento 2. Pasi Ranne /8/17 Helsinki Metropolia University of Applied Sciences

Tietokantojen suunnittelu

Helsingin yliopisto/tktl Kyselykielet, s 2006 Optimointi Harri Laine 1. Kyselyn optimointi. Kyselyn optimointi

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena

ETL-DEMO. Esimerkki ETL-kuvauskielen käyttöstä

Helsingin yliopisto, TKTL Tietokantojen perusteet, k 2000 Tietokannan suunnittelusta Harri Laine 1

Helsingin yliopisto/ tktl D Tietokantojen perusteet, s 2000 Relaatioalgebra. Harri Laine 1. Relaatioalgebra.

Predikaattilogiikan malli-teoreettinen semantiikka

Tietokannat. CREATE TABLE table(col1,col2,... ); Luo uuden taulun. CREATE TABLE opiskelijat(opnumero,etunimi,sukunimi);

VAASAN YLIOPISTO TEKNILLINEN TIEDEKUNTA TIETOTEKNIIKAN LAITOS. Petteri Kaikkonen

DOORSin Spreadsheet export/import

Liitosesimerkki Tietokannan hallinta, kevät 2006, J.Li 1

Kirjasto Relaatiotietokannat Kevät Auvinen Annemari Niemi Anu Passoja Jonna Pulli Jari Tersa Tiina

Opettajana Mika Sorsa, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija

Insert lauseella on kaksi muotoa: insert into taulu [(sarakenimet)] values (arvot)

Operatioanalyysi 2011, Harjoitus 2, viikko 38

TIETOKANTOJEN PERUSTEET OSIO 11 MARKKU SUNI

Alternative DEA Models

Transkriptio:

Relaatioista

Sarakenimistä relaation kaava tulisi olla yksiselitteinen attribuutin roolinimen tulisi auttaa ymmärtämään attribuutin tarkoituksen OSASTO(NIMI,NRO, TNRO, SIJAINTI) mitä tarkoittaa TNRO? viiteavaimella ei tarvitse olla sama roolinimi kuin perusavaimella, johon se viittaa!

Null (Null values) ei arvoa tyhjä arvo voi tarkoittaa: monikolle ei kuulu ko. arvo (entäs "-"?) arvoa ei tiedetä (entäs "?"?) arvoa ei ole ehditty tallettaa TIETOJENKÄSITTELYTIEIDEN LAITOS, JUHA IISAKKA 11-14

Null käytetään: arvoa ei tiedetä uusi rivi luodaan ja ei ehditä heti tallettaa tietoja uusi sarake luodaan ryhmitysfunktiot voivat ohittaa ko. rivin pyrittävä mahd. mukaan välttämään jos ei ole relevanttia tietoa. SQL:ssä omat vertailuoperaattorit. SQL:ssä ei saa verrata normaalitietoa ja nullia!

valheelliset monikot liitos muiden kuin avainehdokkaiden kesken on vaarallinen esim: on olemassa relaatio: PROJEKTILAISET(PNRO,TNRO,PNIMI, TNIMI,TUNNIT,SIJAINTI) josta projektioidaan kaksi relaatiota SIJAINNIT(TNRO,SIJAINTI) ja PROJ1(PNRO,SIJAINTI) tehdään liitos SIJAINTI-attribuutin avulla (SIJAINNIT JOIN PROJ1)

Normalisointi

redundanssi Samaa tai samanarvoista tietoa säilytetään useammassa kuin yhdessä paikassa tietokannassa. Tieto, jota ei voi johtaa toisaalle talletetusta tiedosta, ei ole redundanttista Periaatteessa täysin ei-redundanttinen vaatii surrogaatit

redundanssi redundanssin muodot Fyysinen redundanssi Infologinen redundanssi Huomiotta jätetty redundanssi Tuntematon redundanssi Redundanssia pyritään poistamaan, mutta joskus sitä tiedostetusti jätetään tietokantaan

redundanssi Hyödyt: Harkiten käytettynä nopeuttaa hakuja Auttaa tietokannan palautuksessa, jos tietokanta vaurioituu Haitat: Talletettu enemmän tietoa -> isompi tietokanta Useaan paikkaan talletettu tieto on työläämpi päivittää

Normalisointi normalisointi tarkoittaa epätyydyttävän relaatiokaavan hajoittamista pienempiin relaatiokaavoihin, joiden relaatiot yhdessä säilyttävät peruskaavan relaatioon talletettavan informaation. normalisointi ei takaa tietokannan laatua, jos infologinen malli (ER kaavio esim.) ei vastaa todellisuutta. normalisointimalleja ovat (järjestyksessä) 1., 2., 3., BCNF, 4., 5. ja DKNF.

Normalisointi tavoitetilana voidaan pitää BCNF muotoa. tietokantaa ei tarvitse aina normalisoida loppuun saakka normalisoinnin tarkoituksena on ennenkaikkea poistaa rendundanssi tietokannasta. täysin normalisoidussa tietokannassa ainoastaan entiteetin perusavain on redundanttinen tieto

Normalisointi tietokannan suunnittelussa ollaan kiinnostuneita tiedon ominaisuuksista, jotka ovat aina tosia (ajasta riippumattomia), ei sellaisista, jotka sattuvat olemaan tosia tiettynä ajanhetkenä. suunnittelun perusperiaate on se, että yksi tieto esitetään vain yhdessä paikassa (vältytään redundanssilta) ja yhdessä relaatiossa esitetään vain yhtä entiteettiä koskevaa tietoa.

Funktionaalinen riippuvuus (functional dependency) semanttinen käsite löytäminen osa tiedon ymmärtämisprosessia

Funktionaalinen riippuvuus X ja Y ovat attribuuttiyhdistelmiä relaatiossa R, Y on funktionaalisesti riippuvainen X:stä (X à Y), joss niissä monikoissa joissa on X:ssä yksi ja sama arvo, on myös aina Y:ssä sama arvo. kaikki relaation attribuutit ovat aina funktionaalisesti riippuvia avainehdokkaista. ei vaadita, että X olisi avainehdokas eli ei ole välttämätöntä, että X:n arvo esiintyisi ainoastaan yhdellä R:n rivillä.

täydellinen (funktionaalinen) riippuvuus Y on täysin funktionaalisesti riippuvainen X:stä, joss X à Y ja ei ole olemassa X:n osajoukkoa, josta Y olisi funktionaalisesti riippuvainen. jos Y on funktionaalisesti riippuva X:stä, mutta ei täydellisesti, niin X on luonnollisesti attribuuttikombinaatio.

Funktionaaliset riippuvuudet X,Y,Z, W ovat saman relaation attribuuttien joukkoja 1 Jos X Y, niin X à Y 2 Jos X à Y, niin XZ à YZ 3 Jos X à Y ja Y à Z, niin X à Z (Transitiivinen riippuvuus) 4 Jos X à YZ, niin X à Y 5 Jos X à Y ja X à Z, niin X à YZ 6 Jos X à Y ja WY à Z, niin WX à Z

1. NF Kaikkien attribuuttien tulee olla atomisia ja niiden arvojen homogeenisia eikä toistokenttiä hyväksytä. Periaatteessa kaikki oikeat relaatiot ovat 1NF.

1NF... Törppöware on laadukkaiden muovisten keittiötavaroiden valmistaja, joka myy tuotteitaan esittelijäverkoston kautta. Vakituiset emännät (tai isännät) järjestävät kotonaan Törppöware-kutsuja, joissa esittelijä esittelee (ja myy) yrityksen tuotteita TÖRPPÖkutsut(esittelijä#, esittelijännimi, esittelijänosoite, esittelykunta, piiri, emäntä#, emäntänimi, emäntäosoite, vieraita, pvm).

1 NF Ongelma : Esittelijä ei ole pitänyt vielä yhtään esittelyä -> emäntä# ja pvm saisivat NULL arvon, eli esittelijää ei voi tallettaa relaatioon, Sama koskee emäntiä

2 NF. Relaatio on 2 NF, joss jokainen attribuutti, joka ei sisälly perusavaimeen, on täydellisesti funktionaalisesti riippuva perusavaimesta. Jaetaan Törppökutsut 3 relaatioon Törppöesittelijä(esittelijä#, nimi, osoite, esittelykunta, piiri) Emäntä(emäntä#,nimi, osoite, esittelykunta, piiri) Kutsut(esittelijä#, emäntä#, vieraita, pvm).

2 NF. Ongelmia : 1) Jos kunnassa ei ole yhtään esittelijää, ei voida tietää, mihin piiriin se kuuluu, 2) Jos kunnan piiri vaihtuu, tulee se muuttaa kaikkiin kunnassa toimivien esittelijöiden tietoihin (redundanssia!).

BCNF (Boyce-Codd Normal Form) Boycen parantama versio 3 NF:stä. Arkikielen 3 NF relaatio on BCNF, joss se on 2 NF ja yksikään attribuutti ei ole funktionaalisesti riippuvainen mistään muusta kuin avainehdokkaista. siis transitiivisia riippuvaisuuksia ei saa olla (X->Z kun: X -> Y ja Y->Z ja Y ei ole avainehdokas).

BCNF yleisesti relaation tulisi olla BCNF (tai vähintään 3NF), mikäli ER malli on tehty huolella, pitäisi relaation olla 3 NF. Jatketaan Törppöesittelijä-relaation jakoa ja jaetaan se kahtia. Esittelijä(esittelijä#, nimi, osoite, esittelykunta)" Esittelykunta(kunta, piiri)"

3 NF. Coddin alkuperäinen normaalimuoto superavain on sellainen attribuutti(yhdistelmä), joka on jokaisella relaation rivillä yksilöllinen. kaikki avainehdokkaat ovat superavaimia, mutta superavain voi sisältää myös muita attribuutteja

3 NF. relatio on 3. NF joss aina kun relaatiossa esiintyy täydellinen funtionaalinen riipuvuus X à Y, niin joko X on superavain tai Y on osa jotain avainehdokasta eli avainehdokkaisiin kuulumattomat attribuutit eivät ole täydellisesti funktionaalisesti riippuvia toisistaan ja ovat täydellisesti funktionaalisesti riippuvaisia avainehdokkaista

3 NF. 3NF:n määritelmä kärsii puutteista, kun relaatiossa: On useita avainehdokkaita Nämä avainehdokkaat ovat attribuuttikombinaatioita Avainehdokkaat ovat päällekkäisiä (niillä on ainakin yksi yhteinen attribuutti). näitä puutteita varten on kehitetty BCNF normaalimuoto.

A DATABASE IS IN THRID NORMAL FORM WHEN EVERY ATTRIBUTE DEPENDS ON THE KEY, THE WHOLE KEY, AND NOTHING BUT THE KEY, SO HELP ME CODD. (SCOTT W. AMBLER: BUILDING OBJECT APPLICATIONS THAT WORK.) "Key" = perusavain HUOM: Tarkoittaa itseasiassa BCNF:ää Koskee samalla tavoin mahdollisia avainehdokkaita.

Moniarvoinen riippuvuus Jos relaation attribuutit voidaan jakaa kolmeen ryhmään A, B ja C siten että A:n yhtä arvoa kohden on hyvin määritelty joukko arvoja B:lle ja A:n yhtä arvoa kohden on hyvin määritelty joukko arvoja C:lle" Mutta B ja C ovat toisistaan riippumattomia. " Silloin A ->>B ja A->>C "

4 NF. Relaation r kaava R on 4NF joss relaatiossa on attribuuttien osajoukot A ja B, joilla on ei triviaali moniarvoinen riippuvuus A=>>B, niin kaikki R:n attribuutit ovat myös funktionaalisesti riippuvaisia A:sta, jonka tulee olla avainehdokas. (Triviaali moniarvoinen riippuvuus: relaatiossa ei ole muita attribuutteja kuin A ja B.)

4 NF. Kuvitellaan koulu, jossa on opettajia, kursseja ja kurssikirjoja. Jokainen opettaja, joka voi opettaa jotain kurssia, voi opettaa mistä tahansa kurssikirjasta, joka kurssilla on. Nyt on relaatio: KURSSI(kurssinNimi, ope, kirja) jossa ovat seuraavat monikot: matikka Heikki Algebra ja me matikka Tuomas Differentiaalit relaatiossa voi myös olla seuraavat monikot: matikka Tuomas Algebra ja me matikka Heikki Differentiaalit

4 NF. Nyt ope on moniarvoisesti riippuvainen kurssin nimestä. (Kuvitellaan kurssin nimi X:ksi ja ope y:ksi.) Myös kirja on moniarvoisesti riippuvainen kurssin nimestä. Ope ja kirja sen sijaan eivät ole riippuvia toisistaan, tätä merkitään: kurssinimi ->> ope kirja

4 NF. Tällainen relaatio joudutaan normalisoimaan neljänteen normaalimuotoon kahdeksi pienemmäksi relaatioksi: OPETUS(kurssiNimi, ope) ja KURSSIKIRJA(kurssiNimi, kirja) eli OPETUS kertoo, ketkä osaavat opettaa tiettyä kurssia, ja KURSSIKIRJA taas kertoo, mitkä kirjat soveltuvat tietylle kurssille. Tämä oli haluttu kertoa myös alkuperäisellä relaatiolla.

liitosriippuvuus ja 5. normaalimuoto (join dependency) relaatio r toteuttaa liitosriippuvuuden, jos sen projektioiden yhteenliittäminen tuottaa täydellisen relaation r 5. normaalimuoto (5NF): (myös: PJ/NF projection-join normal form) relaatio r on 5NF joss jokainen liitosriiip-puvuuden täyttävä projektio r:stä sisältää avainehdokkaan. Muussa tapauksessa r pitää jakaa hajottaa liitosriippuvuuden toteuttaviin projektiorelaatioihin.

Domain-Key Normal Form (DKNF) Jokainen relaation ehto on looginen seuraus relaation avainten ja arvoalueiden määrityksistä Avain: perus- ja ehdokasavain Arvoalue (domain): attribuutin arvoalue DK/NF on ylin normaalimuoto, eli sitä korkeampia normaalimuotoja ei teoreettisesti voi olla.

DKNF... "If every table has a single theme, then all functional dependencies will be logical consequences of keys. All data value constraints can them be expressed as domain constraints Since keys are enforced by the DBMS and domains are enforced by edit checks on data input, all modification anomalies can be avoided by just these two simple measures." --Michael Nicewarner DKNF:n ongelmana on, että ei ole aina selvää, milloin relaatio on siinä. Samoin sen määritys ei kerro miten, huono relaatio saadaan siihen.