Kap 02 Relasjonsdatabaser I dette kapitlet skal vi benytte kunnskapene våre fra de foregående kapitlene til å utarbeide ulike diskrete sannsynlighetsmodeller. For en gitt oppgave vil det da kunne være hensiktsmessig å finne ut om betingelsene er oppfylt for å kunne benytte en eller flere av disse modellene med tilhørende ferdige utarbeidede metoder. Simuleringer knyttet til dette kapitlet finner du her.

Tabeller Dataene i en relasjonsdatabase er plassert i to-dimensjonale tabeller. En relasjons-database består av tabeller. Definering av begrepet tabell.

Eksempel på innhold i en database Views Procedures Rules Tables Datatypes Indexes La oss se litt nærmere på selve databasen der dataene ligger lagret. I en relasjons-database ligger alle dataene lagret i såkalte tabeller. Dette er to-dimensjonale arrays bestående av rader og kolonner. Views: Virtuelle tabeller. Dataene kan være deler av tabell-data eller en sammenslåing av data fra flere relaterte tabeller. Indexes: Hjelpetabeller for raskere oppslag i tabeller. Procedures: Ferdigkompilerte sekvenser av SQL-statement. Triggers: Ferdigkompilerte rutiner som eksekveres under gitte forutsetninger. Rules: Regler for kolonne-verdier (eks: Datoer skal være innen 1-31. Datatypes: Opplysninger om datatyper i de enkelte kolonner (eks: Number) Defaults: Kolonne-verdier hvis ingenting annet er spesifisert (eks: Dagens dato hvis ingenting annet er spesifisert) Defaults Triggers

Database / Tabell / Rad / Kolonne 5 Nilsen 5002 2 Olsen 6400 1 Hansen 9000 4 Berg 6400 Rad Post Record En del viktige begrep: - Database - Tabell - Rad / Post / Record - Kolonne / Felt Kolonne Felt

Hva er en relasjons-database ? En relasjons-database er en database hvor alle dataene er samlet i to-dimensjonale tabeller og hvor tabellene eventuelt står i en 1:1 eller 1:n relasjon til hverandre. Tabellene er inndelt i rader (records) og kolonner (felter). n 1 Nr Navn PNr 5 Nilsen 4890 7 Olsen 6400 3 Hansen 4890 8 Karlsen 4890 PNr Sted 4890 Grimstad 5002 Bergen 6400 Molde Eksempel på to tabeller Person og Adr som det eksisterer en relasjon mellom. Relasjonen er innebygget i tabellen Person (kolonnen PNr). Relasjonen kalles en 1:n (leses: en til n relasjon), fordi det til hver rad (post) i tabellen Adr finnes 0, 1 eller flere rader (poster) i tabellen Person. Omvendt vil det til hver rad (post) i tabellen Person finnes nøyaktig en rad (post) i tabellen Adr.

Viktige fortrinn ved relasjons-database Reduserer lagring av redundante data. Data kan lett omorganiseres og kombineres i nye relasjoner, de er ikke låst til faste relasjoner pga måten de er lagret på. Data kan lett oppdateres i det disse vil bli oppdatert på et minimum antall steder. Reduserer behovet for disk-plass. Noen hovedgrunner til at relasjons-database idag er en standard blant ulike database-typer.

3 sentrale gjenfinnings-operasjoner i Codd’s relasjons-algebra Selection Ekstraherer alle rader fra en tabell, hvor radene oppfyller gitte kriterier. Projection Ekstraherer en eller flere kolonner fra en tabell. Join Ekstraherer kolonner fra flere relaterte tabeller. Selection Projection Join Gjenfinnings-operasjoner i relasjons-databaser.

Normal-former SNr Navn PNr Sted VNr Pris Mg VNr Pris Mg VNr Pris Mg 5 Nilsen 5002 Bergen 8 500 30 2 Olsen 6400 Molde 1 200 20 3 400 10 1 Hansen 9000 Tromsø 5 300 50 8 500 40 4 Berg 6400 Molde 1 200 70 3 400 50 5 300 20 SNr Selger-nummer Navn Selger-navn PNr Post-nummer Sted Post-sted VNr Vare-nummer Pris Vare-pris Mg Vare-mengde Her har vi startet med en stor tabell hvor vi har samlet opplysninger om hver enkelt selger og de varer som denne selgeren har solgt. Tabell-formen inneholder flere svakheter: - Et varierende antall kolonner for hver enkelt selger - Datadublering Eks: 6400 Molde er gjentatt flere ganger Vareprisen på vare nr 8 er gjentatt flere ganger - Vanskelig å programmere gjenfinning og oppdatering i tabellen.

1NF Første normalform Hver tabell skal ha en fast postlengde Det skal være kun en post-type pr tabell Hver post skal ha et eget identifikasjons-felt ( ID ) SNr Navn PNr Sted VNr Pris Mg 5 Nilsen 5002 Bergen 8 500 30 2 Olsen 6400 Molde 1 200 20 2 Olsen 6400 Molde 3 400 10 1 Hansen 9000 Tromsø 5 300 50 1 Hansen 9000 Tromsø 8 500 40 4 Berg 6400 Molde 1 200 70 4 Berg 6400 Molde 3 400 50 4 Berg 6400 Molde 5 300 20 Tabellen fra foregående side er endret slik at samtlige rader (records) har samme antall kolonner. Tabellen sies å være på såkalt første normalform (1NF) når de tre kravene nevnt ovenfor er oppfylt. I vår selger-tabell vist ovenfor er disse tre kravene oppfylt. SNr og VNr utgjør tilsammen ID. Ulemper: - Opplysninger om hver enkelt selger må gjentas flere ganger, en gang for hver vare denne selgeren selger. - Fortsatt datadublering.

2NF Andre normalform Databasen må være på 1.normalform Deler av ID skal ikke kunne være determinantfelt for andre felt, dvs deler av ID skal ikke entydig kunne bestemme verdier i et annet felt SNr Navn PNr Sted 5 Nilsen 5002 Bergen 2 Olsen 6400 Molde 1 Hansen 9000 Tromsø 4 Berg 6400 Molde VNr Pris 8 500 1 200 3 400 5 300 SNr VNr Mg 5 8 30 2 1 20 2 3 10 1 5 50 1 8 40 4 1 70 4 3 50 4 5 20 En tabell sies å være på såkalt andre normalform (2NF) når de to kravene nevnt ovenfor er oppfylt. Tabellen vist på foregående side oppfyller ikke 2NF. Hvis vi derimot splitter tabellen i tre slik som vist ovenfor, så vil hver enkelt av disse tre tabellene være på 2NF. Vi skal seinere gå nærmere inn på hvordan en slik oppsplitting gjøres. Vi har fortsatt en del ulemper med tabellene ovenfor selv om disse oppfyller 2NF, nemlig datadublering ved at sammenhengen mellom PNr (PostNumer) og Sted er nevnt flere ganger (6400 Molde er nevnt to ganger).

3NF Tredje normalform Databasen må være på 2.normalform Det må ikke eksistere noen funksjonelle avhengigheter mellom egenskapsfeltene (felter utenom ID-feltene) SNr Navn PNr 5 Nilsen 5002 2 Olsen 6400 1 Hansen 9000 4 Berg 6400 VNr Pris 8 500 1 200 3 400 5 300 SNr VNr Mg 5 8 30 2 1 20 2 3 10 1 5 50 1 8 40 4 1 70 4 3 50 4 5 20 En tabell sies å være på såkalt tredje normalform (3NF) når de to kravene nevnt ovenfor er oppfylt. Tabellen Selger vist på foregående side oppfyller ikke 3NF. Hvis vi derimot splitter tabellen i to (Selger og Adr) slik som vist ovenfor, så vil hver enkelt av disse tabellene være på 3NF. Det finnes flere normalformer enn de tre vi til nå har nevnt, men vi skal ikke gå nærmere inn på disse her. PNr Sted 5002 Bergen 6400 Molde 9000 Tromsø

3NF Tredje normalform Adr Selger Vare PNr Sted SNr Navn PNr 5002 Bergen 6400 Molde 9000 Tromsø SNr Navn PNr 5 Nilsen 5002 2 Olsen 6400 1 Hansen 9000 4 Berg 6400 VNr Pris 8 500 1 200 3 400 5 300 Salg SNr VNr Mg 5 8 30 2 1 20 2 3 10 1 5 50 1 8 40 4 1 70 4 3 50 4 5 20 Vår opprinnelige selger-tabell er blitt splittet i fire deler. Hver av de fire tabellene oppfyller 3NF. Mellom disse tabellene eksisterer det tre 1:n relasjoner.

Modellator - Notasjon Kråkefot Selger Adr Uten attributter Selger Adr I Modellator kan relasjoner tegnes på ulike vis. Ovenfor vises 1:n relasjon ved hjelp av såkalte kråkeføtter. Tabellene er vist med og uten attributter. Selger Adr Med attributter SNr Navn *PNr PNr Sted

Modellator Selger Adr Kråkefot Selger Adr Gaffel Selger Adr Pil Selger Pil / Dobbeltpil Selger 1..1 Adr Antall Ulike representasjoner av 1:n relasjoner i Modellator. 0..m Selger Adr Niam-basert Selger Adr Kan / Må

Generell metode for tilordning av 3NF-tabeller (0) Vi går tilbake til vår opprinnelige Selger-tabell på 1NF form. Følgende felter er med i denne 1NF-tabellen ( ID er markert med * ). * SNr Selger-nummer Navn Selger-navn PNr Post-nummer Sted Post-sted * VNr Vare-nummer Pris Vare-pris Mg Vare-mengde Vi skal se litt nærmere på en metode for å transformere en 1NF tabell via 2NF over til 3NF. Vi starter med vår 1NF selger-tabell. Denne tabellen består av 7 kolonner. To av kolonnene, SNr og VNr danner til sammen ID (markert med *)

Generell metode for tilordning av 3NF-tabeller (1) 1. Vi tegner inn relasjoner (piler) fra de feltene som entydig bestemmer verdien i andre felter til disse andre feltene. Total (1NF) * SNr Navn PNr Sted * VNr Pris Mg Vi tegner inn relasjoner (vha piler) fra de feltene som entydig bestememer verdien i andre felter.

Generell metode for tilordning av 3NF-tabeller (2) 2. Lag en ny tabell ved å plukke ut alle *-feltene samt alle feltene som er funksjonelt avhengig av alle disse *-feltene. Denne nye tabellen vil være på 2NF. Salg (2NF) * SNr * VNr Mg Lag en ny tabell ved å plukke ut alle *-feltene samt alle feltene som er funksjonelt avhengig av disse *-feltene. Denne nye tabellen vil være på 2NF.

Generell metode for tilordning av 3NF-tabeller (3) 3. Hvis det i 1NF-tabellen finnes felt som er avhengig av en ekte delmengde av *-feltene, plukkes disse ut sammen med tilhørende *-felt i egne tabeller. Disse nye tabellene vil være på 2NF. Selger (2NF) Vare (2NF) * SNr Navn PNr Sted * VNr Pris Hvis det i 1NF tabellene finnes felt som er avhengig av en ekte delmengde av *-feltene, plukkes disse ut sammen med tilhørende *-felt i egne tabeller. Disse nye tabellene vil være på 2NF.

Generell metode for tilordning av 3NF-tabeller (4) 4. Hvis det i noen av våre 2NF-tabeller ( Salg, Selger, Vare ) finnes ikke-*-felter (ikke ID-felter) som entydig bestemmer verdier i andre ikke-*-felter, plukkes disse nevnte feltene ut i egne tabeller. I vårt eksempel gjelder dette tabellen Selger (PNr bestemmer Sted). Tabellen Selger splittes i to: Tabellene Selger og Adr (Adresse). Selger-tabellen beholder informasjon om PNr. ID i disse nye tabellene vil være de feltene som entydig bestemmer andre felt-verdier. Alle tabellene vil nå være på 3NF. Selger (3NF) Adr (3NF) * SNr Navn PNr * PNr Sted Hvis det i noen av våre 2NF-tabeller (Salg, Selger, Vare) finnes ikke-*-felter (ikke ID-felter) som entydig bestemmer verdier i andre ikke-*-felter, plukkes disse nevnte feltene ut i egne tabeller. I vårt eksempel gjelder dette tabellene Selger(PNr bestemmer Sted). Tabellen Selger splittes i to: Tabellene Selger og Adr (Adresse). Selger-tabellen beholder informsjonen PNr. ID i disse nye tabellene vil være de feltene som entydig bestemmer andre felt-verdier. Alle tabellene vil nå være på 3NF.

Generell metode for tilordning av 3NF-tabeller (5) Alle våre 4 tabeller ( Selger, Adr, Vare, Salg ) vil nå oppfylle 3NF. Selger (3NF) Adr (3NF) * SNr Navn PNr * PNr Sted Salg (3NF) Vare (3NF) Alle våre 4 tabeller (Selger, Adr, Vare, Salg) vil nå oppfylle 3NF. * SNr * VNr Mg * VNr Pris

Generell metode for tilordning av 3NF-tabeller (6) Følgende relasjoner gjelder mellom våre 4 tabeller ( Selger, Adr, Vare, Salg ) vil nå oppfylle 3NF. Selger Adr Vare * SNr Navn PNr * PNr Sted * VNr Pris Figuren viser relasjonene mellom de 4 3NF-tabellene Selger, Adr, Vare, Salg. Relasjons-informasjonen er inneholdt i tabellene slik at pilene (som skal illustrere relasjonene) ikke inneholder noen ny informasjon. Salg * SNr * VNr Mg