TIEDONHALLINNAN PERUSTEET - SYKSY 2013

Samankaltaiset tiedostot
NORMALISOINTI TIETOJEN MALLINNUS JOUNI HUOTARI & ARI HOVI

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

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

HELIA 1 (17) Outi Virkki Tiedonhallinta

TIETOKANNAN SUUNNITTELU

HELIA 1 (17) Outi Virkki Tiedonhallinta

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

3. Käsiteanalyysi ja käsitekaavio

TIETOKANNAN NORMALISOINTI JA NORMAALIMUODOT

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

Tietokantojen suunnittelu, relaatiokantojen perusteita

HELIA 1 (21) Outi Virkki Tietokantasuunnittelu

Tietokannan suunnittelu

Luento 3 Tietokannan tietosisällön suunnittelu

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

TIEDONHALLINNAN PERUSTEET - SYKSY 2013

HELIA 1 (20) Outi Virkki Tiedonhallinta

2. Käsiteanalyysi ja relaatiomalli

Tietokannan suunnittelu

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

TIEDONHALLINTA - SYKSY Luento 8. Saapumisryhmä: Pasi Ranne /9/13 Helsinki Metropolia University of Applied Sciences

TIETOKANTOJEN SUUNNITTELU

Relaatiotietokantojen perusteista. Harri Laine Helsingin yliopisto

Relaatioista TIETOJENKÄSITTELYTIETEIDEN LAITOS, JUHA IISAKKA 11-14

POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN

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

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

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

Jouni Huotari & Ari Hovi. Käsitemallinnuksesta relaatiokantaan KÄSITEMALLI. LOOGINEN MALLI: tietomalli valittu. FYYSINEN MALLI: DBMS valittu

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

TIETOKANNAN JÄRKEISTÄMINEN

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

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

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

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

HARJOITUS 2. Kasvattamot ja mittaukset

Relaatiomalli ja -tietokanta

HELIA 1 (19) Outi Virkki Tietokantasuunnittelu

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

Tietokantojen suunnittelu

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

HELIA 1 (19) Outi Virkki Tietokantasuunnittelu

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

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

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

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

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

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

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

Tietokannan suunnittelu

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

Tietokannan rakenteen suunnittelu

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

Opintopiiritehtävä 3: Verkkohuutokauppa

KÄSITEANALYYSI JA -MALLINNUS HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 3

FROM-lausekkeessa voidaan määritellä useampi kuin yksi taulu, josta tietoja haetaan: Tuloksena on taululistassa lueteltujen taulujen rivien

HELIA 1 (12) Outi Virkki Tiedonhallinta

Tieto/datamallit. Marttila-Kontio/Unicta Oy

Opettajana Mika Sorsa, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija

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

SELECT-lauseen perusmuoto

Luento L: Normalisointi

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

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

Tiedonhallinnan perusteet. H11 Ovien ja kulun valvontajärjestelmän tietokanta

Tietokannat II -kurssin harjoitustyö

HAAGA-HELIA Heti-09 1 (12) ICT05 Tiedonhallinta ja Tietokannat O.Virkki Näkymät

Tietokannat I. c 2007 Olli Luoma olli.luoma@it.utu.fi

Tiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas

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

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

CS-A1150 Tietokannat CS-A1150 Tietokannat / 43

Visual Case 2. Miika Kasnio (C9767)

FYYSINEN SUUNNITTELU

Fyysinen suunnittelu

HELIA 1 (14) Outi Virkki Tiedonhallinta

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

CS-A1150 Tietokannat CS-A1150 Tietokannat / 43

Tietokannat II -kurssin harjoitustyö

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

CSE-A1200 Tietokannat

CSE-A1200 Tietokannat

RELAATIOTIETOKANNAN SUUNNITTELU JA TOTEUTUS

IIO30100 TIETOKANTOJEN SUUNNITTELU (6 OP)

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

Mikko Mäkelä KONEHUOLTOJEN TIETOKANNAN SUUNNITTELU JA TOTEUTUS

HELIA 1 (11) Outi Virkki Tiedonhallinta

SQL - STRUCTURED QUERY LANGUAGE

HELIA 1 (14) Outi Virkki Tiedonhallinta

KÄSITEANALYYSI PROSESSINA JA TARVEANALYYSI

CS-A1150 Tietokannat CS-A1150 Tietokannat / 51

Janina Puistovaara RELAATIOTIETOKANNAN SUUNNITTELU JA MALLINTAMINEN KÄSITEANALYYSI- MENETELMÄLLÄ

IIO30100 Tietokantojen suunnittelu (6 op)

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

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

TIETOKANTOJEN PERUSTEET OSIO 11 MARKKU SUNI

Hannes Ranta SOVELLUKSEN TIETOKANNAN UUDELLEENSUUNNITTELU

Kari Aalto Saariston IT

YHTEYSSUHDE (assosiation)

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen

Transkriptio:

TIEDONHALLINNAN PERUSTEET - SYKSY 2013 Kurssikoodi: Saapumisryhmä: Luento 4 XX00AA79-3013 TU12S2 Pasi Ranne 11.9.2013 11/9/13 Helsinki Metropolia University of Applied Sciences 1

Relaatiotietokannan suunnitteluprosessin vaiheet Vaihe Tavoite Tehtävät Tuotokset Käsitteellinen mallintaminen Looginen mallintaminen Fyysinen mallintaminen Selvittää kohdealueen keskeiset käsitteet, niiden ominaisuudet ja väliset suhteet Esittää käsitemallin sisältö relaatiomallin mukaisesti Fyysinen tallennusratkaisu relaatiotietokantatuotteella Käsiteanalyysi Käsitekaavion suunnittelu Relaatiomallin normalisointi Relaatiokaavion suunnittelu Tietokannan toteutuksen suunnittelu Käsitekaavio Relaatiokaavio Eheysmäärittelyt SQL-lauseet tietokannan luomiseksi Pasi Ranne Metropolia Ammattikorkeakoulu 2

Tietokannan suunnittelu: Looginen mallintaminen

Looginen mallintaminen Vaihe Tavoite Tehtävät Tuotokset Käsitteellinen mallintaminen Looginen mallintaminen Fyysinen mallintaminen Selvittää kohdealueen keskeiset käsitteet, niiden ominaisuudet ja väliset suhteet Esittää käsitemallin sisältö relaatiomallin mukaisesti Fyysinen tallennusratkaisu relaatiotietokantatuotteella Käsiteanalyysi Käsitekaavion suunnittelu Relaatiomallin normalisointi Relaatiokaavion suunnittelu Tietokannan toteutuksen suunnittelu Käsitekaavio Relaatiokaavio Eheysmäärittelyt SQL-lauseet tietokannan luomiseksi Pasi Ranne Metropolia Ammattikorkeakoulu 4

Looginen mallintaminen Tehdään käsitemallin pohjalta relaatiokaavio Käsitteistä tulee taulu Käsitteen attribuutit (ominaisuudet) sarakkeiden nimeksi Käsitteen yksilöivä attribuutti taulun pääavaimeksi (primary key) Jos ei luonnollista attribuuttia, luodaan keinotekoinen tunniste(numero) Yhteydet luodaan viiteavaimien avulla Pasi Ranne Metropolia Ammattikorkeakoulu 5

Yhteydet 1 : M suhteesta tehdään viiteavain suhteen M-puolen tauluun Pasi Ranne Metropolia Ammattikorkeakoulu 6

Viiteavaimen määrittely Määrittele viiteavaimen arvo pakollisiksi eli älä salli tyhjää arvoa avainkenttään (NOT NULL), jos yhteys on pakollinen Salli tyhjä arvo, jos yhteys ei ole pakollinen Indeksoi viiteavainsarakkeet, koska se parantaa taulujen liitosten tehokkuutta huomattavasti Pasi Ranne Metropolia Ammattikorkeakoulu 7

Viiteavaimista koottu pääavain Pää/perusavain voi muodostua kahdesta tai useammasta viiteavaimesta Huotari Pasi Ranne Metropolia Ammattikorkeakoulu 8

Tietokannan suunnittelu: Normalisointi

Relaatiomallin normalisoinnin tavoitteet Normalisointi on menetelmä, jonka avulla relaatiomallin rakenne voidaan (mahdollisesti) saattaa parempaan muotoon tietojen toistaminen on minimoitu tehokas päivitysten kannalta yksinkertainen päivitysten kannalta (tieto vain yhdessä paikassa) rakenne on joustavasti muutettavissa Normalisointi perustuu nk. normaalimuotoihin Normaalimuodot ovat asteittain tiukkenevia ehtoja, jotka relaatioiden on täytettävä (kukin normaalimuoto rakentuu edeltäjänsä päälle) Normaalimuotoja tunnetaan kaikkiaan kuusi Kolmas normaalimuoto on usein riittävä taso Pasi Ranne Metropolia Ammattikorkeakoulu 10

Attribuuttien riippuvuus Ylempien normaalimuotojen kohdalla joudutaan tarkastelemaan attribuuttien riippuvuutta Funktionaalinen riippuvuus Attribuutti B on funktionaalisesti riippuva attribuutti A:sta, jos A:n arvo määrää yksikäsitteisesti B:n arvon Toisin sanoen; jokaista A:n arvoa vastaa kullakin hetkellä korkeintaan yksi B:n arvo Merkitään: A -> B esim. sotu -> henkilön nimi Moniarvoinen riippuvuus Attribuutin A arvoon voi liittyä useita attribuutin B arvoja Merkitään: A ->> B esim. projektiid ->> työntekijäid Jos A -> B, niin ei välttämättä B -> A Riippuvuus voi olla toiseen suuntaan funktionaalinen ja toiseen suuntaan moniarvoinen esim. sotu<<-> henkilön nimi Pasi Ranne Metropolia Ammattikorkeakoulu 11

Normalisoinnin vaiheet lyhyesti 1. Ensimmäinen normaalimuoto Erota toistuvat ryhmät ja moniarvoiset attribuutit omiksi käsitteikseen 2. Toinen normaalimuoto Jokaisen ei-avaintiedon tulee olla riippuvainen koko perusavaimesta 3. Kolmas normaalimuoto Poista sisäiset (ei-avaimeen kohdistuvat) riippuvuudet Pasi Ranne Metropolia Ammattikorkeakoulu 12

Ensimmäinen normaalimuoto (1NF, 1NM) Relaatio on ensimmäisessä normaali-muodossa, jos kaikki arvot ovat atomisia l. jakamattomia Tämä tarkoittaa että relaatiossa ei saa olla moniarvoisia attribuutteja (attribuutin on oltava jakamaton kokonaisuus) toistuvia attribuutteja (osoite1, osoite2, ) Moniarvoiset ja toistuvat attribuutit tulee purkaa relaatioiksi viiteavainten avulla. Pasi Ranne Metropolia Ammattikorkeakoulu 13

Ensimmäinen normaalimuoto - esimerkki Kuljetus1 (k_id, lahto, perilla, matk1, matk2, matk3, matk4) Kuljetus1 k_id lahto perilla matk1 matk2 matk3 matk4 1 Lahnus, 20.3.2011 8:00 Hki, 20.3.2011 8:45 Lea Kai 2 Hki, 20.3.2011 16:30 Lahnus, 20.3.2011 17:30 Kim Lea Kai Kuljetus2 (k_id, lahto, perilla, matkustajat) Kuljetus2 k_id lahto perilla matkustajat 1 Lahnus, 20.3.2011 8:00 Hki, 20.3.2011 8:45 Kai, Lea 2 Hki, 20.3.2011 16:30 Lahnus, 20.3.2011 17:30 Kai, Lea, Kim Esimerkki normalisoidusta ratkaisusta: Matkustaja (m_id, nimi, osoite, puhno) Ajo (k_id, lahtopaikka, lahtoaika, tulopaikka, tuloaika) Kuljetus (m_id, k_id) Pasi Ranne Metropolia Ammattikorkeakoulu 14

Toinen normaalimuoto (2NF) Ensimmäisessä normaalimuodossa oleva relaatio on toisessa normaalimuodossa, jos kaikki attribuutit ovat funktionaalisesti riippuvia koko perusavaimesta (huom. moniosaiset perusavaimet). Mikään perusavaimen osa ei saa määritellä attribuutin arvoa. Toista normaalimuotoa on tarpeen tutkia vain jos perusavain koostuu useammasta kuin yhdestä attribuutista. Pasi Ranne Metropolia Ammattikorkeakoulu 15

Toinen normaalimuoto - esimerkki Tilaus (asiakasnro, tuotenro, tuotenimi, maara, pvm, nimi, osoite) Onko 1. normaalimuodossa? nimi, osoite? Onko 2. normaalimuodossa? asiakasnro nimi, osoite tuotenro tuotenimi Normalisointi: Asiakas (asiakasnro, nimi, osoite) Tuote (tuotenro, tuotenimi) Tilaus (asiakasnro, tuotenro, maara, pvm) Jos ei normalisoida, niin Ei voi tallentaa asiakkaan tietoja etukäteen Vanhoja tilauksia poistettaessa asiakkaan tiedot voivat kadota Asiakkaan osoitteen muutos tallennettava moneen paikkaan Pasi Ranne Metropolia Ammattikorkeakoulu 16

Kolmas normaalimuoto (3NF) Toisessa normaalimuodossa oleva relaatio on kolmannessa normaalimuodossa, jos jokainen eiavainattribuutti on funktionaalisesti riippuva vain perusavaimesta (eikä mistään nk. tavallisista attribuuteista). Pasi Ranne Metropolia Ammattikorkeakoulu 17

Kolmas normaalimuoto - esimerkki Henkilo (htun, sukunimi, etunimi, lahiosoite, postinumero, postitoimipaikka) Onko toisessa normaalimuodossa? On. Onko kolmannessa normaalimuodossa? Ei, koska postinumero postitoimipaikka Pasi Ranne Metropolia Ammattikorkeakoulu 18

Kolmas normaalimuoto - esimerkki Henkilo (htun, sukunimi, etunimi, lahiosoite, postinumero, postitoimipaikka) Normalisointi kolmanteen normaalimuotoon: Henkilo (htun, sukunimi, etunimi, lahiosoite, postinumero) Posti (postinumero, postitoimipaikka) Jos ei normalisoida Postitoimipaikkoja ei voi tallentaa ennen henkilön tallentamista Postitoimipaikan nimen muutos tulee moneen paikkaan Pasi Ranne Metropolia Ammattikorkeakoulu 19

Normalisointi - yhteenveto Suunnittelussa normalisoidaan käsitteitä Käsitemallin normalisointi tarkistetaan käsite käsitteeltä Melko työläs operaatio, mutta vaivannäkö yleensä kannattaa Käytännössä tehdään nk. ideaalimalli, jossa normalisointi on ulotettu kaikkiin tilanteisiin ja sen jälkeen tehdään perustellut rajaukset siitä, mikä tulee olemaan toteutettava ratkaisu (ts. palataan lähelle toista normaalimuotoa) Yhteenvetona: kaikkien ei-avaintietojen tulee olla funktionaalisesti riippuvia perusavaimesta (1NF), koko perusavaimesta (2NF) ja vain perusavaimesta (3NF) Pasi Ranne Metropolia Ammattikorkeakoulu 20

Tietokoneavusteinen suunnittelu CASE (Computer Aided Software Engineering, tietokoneavusteinen ohjelmistotuotanto) CASE-työkalut ovat ohjelmia, joiden avulla voi organisoida ja visualisoida ohjelmistotuotannon prosesseja Tuotteita - perusmallinnus ja kaavioiden piirto PowerDesigner, MS Visio, ER/studio, MagicDraw, ArgoUML, Poseidon, DBDesigner, Kehittyneitä mallinnus- ja ohjelmointityökaluja Prosa: http://www.insoft.fi/fin/index.htm MetaEdit: http://www.metacase.com Rational Rose: http://www.rational.com/ MySQL Workbench: http://dev.mysql.com/downloads/workbench/5.0.html Pasi Ranne Metropolia Ammattikorkeakoulu 21