Full presentasjon

Transcription

Full presentasjon

INF130 – Datahåndtering og
analyse
Normalisering
INF130: Normalisering
10.03.15
1.1
Repetisjon av standard terminologi i databaser
10.03.15
2
Normalisering
•  Motivasjon
•  Redundans
•  Funksjonelle avhengigheter
•  Determinanter
•  Partielle avhengigheter
•  Transitive avhengigheter
•  Normalformer: 1NF, 2NF, 3NF, BCNF
•  Normaliseringsstegene
Pensum: Kapittel 8.2
10.03.15
3
Hva er normalisering ?
•  Formell metode for å designe relasjonsdatabaser for å unngå
dobbellagring og redundans (som fører til inkonsistenser)
•  I praksis resulterer normalisering i splitting opp av tabeller inn i
mindre tabeller
•  (En tabell som ikke er normalisert er i UNF - unormalisert
form)
10.03.15
4
Normalisering
•  Normalisering består i å dekomponere (splitte opp)
tabeller til flere enklere tabeller slik at:
– Redundans ikke oppstår
– Informasjonsinnholdet bevares
•  Normaliseringsteori gir oss:
– Presise regler for å avgjøre om og hvordan tabeller
skal dekomponeres basert på kunnskap om
funksjonelle avhengigheter.
10.03.15
5
Redundans: Informasjon som blir gjentatt
OrdreNr
Ordredato
KNr
Adresse
20505
20.8.2011
5022
Kongens gate 3
20505
20.8.2011
5022
Kongens gate 3
20506
20.8.2011
5009
Furulia 72
20506
20.8.2011
5009
Furulia 72
20506
20.8.2011
5009
Furulia 72
20507
20.9.2011
5188
Svingen 7
q  Tabellen inneholder data om både ordrer og kunder.
q  OrdreNr er primærnøkkel, men KNr bestemmer (nåværende) Adresse.
q  Redundans er sløsing med plass og øker sjansen for inkonsistens
(hvis vi endrer adresse for en kunde ett sted, men ikke alle).
q  Kunder som ikke har kjøpt noe lar seg ikke representere.
q  Tabellen bør splittes i to enklere tabeller: Kunde og Ordre!
10.03.15
6
Et unormalisert register
repeterende
gruppe
ansatt
bopel
priv.tlf
lønn
22334466
250000
avdeling
avd.adr
avd.tlf
avd.budsj prosjekt prosj.timer prosjekt prosj.timer
Salg
Oslo
22876543
Salg
Oslo
22876543
120
Oslo
2000000
110
Skedsmo 63298765
2000000
081
Asker
1500000
240000
Produksj.
Bærum 22878855
230
Bærum
1000000
300000
Økonomi
Bærum 22878850
Bryter kravene til relasjoner:
•  Varierende antall attributter for hvert tuppel
•  Duplikate attributtnavn
10.03.15
Alfa
200
Alfa
75
Alfa
150
Beta
100
Beta
250
Vi går gjenom
normalisering
med et nytt
eksempel!
7
Eksempel på repeterende grupper
(ikke atomiske verdier)
studnavn
Hansen
telefonnr
63804356 47328990
10.03.15
8
Eksempel på
oppdateringsanomalier
ansattnr
navn
stilling
filial
filialadresse
s001
Hansen
leder
f01
Liavn 5
s203
Larsen
saksbeh. f03
Storgt 10
p011
Olsen
assistent f01
Liavn 5
1.  Kan ikke legge inn en ny filial uten at man har en ansatt der
fordi man ikke kan sette ansattnr=NULL (ansattnr er
primærnøkkel) (innleggingsanomali)
2.  Hvis Larsen slutter mister vi info om filial f03 (slettingsanomali)
3.  Hvis vi ønsker å endre f01’s filialadresse må vi gjøre det i to
tupler ellers får vi datainkonsistens (endringsanomali)
10.03.15
9
Hvorfor er redundans så farlig?
•  Kan føre til oppdateringsanomalier (avvik fra reglene,
uregelmessighet). Det finnes tre forskjellige typer av disse
avvikene:
- Innleggingsanomalier
- Slettingsanomalier
- Endringsanomlier
10.03.15
10
Forut for normalisering …
•  En god database-design begynner med en ”Entity
Relationship” (ER-)modell, som er et godt utgangspunkt for
normalisering. (Vi tar opp modellering litt senere.)
•  Hva ønsker vi å søke på i databasen? For å gjøre søkingen så
rask som mulig bør de tingene vi søker på være attributter i en
relasjon.
10.03.15
11
Funksjonelle avhengigheter I
•  En funksjonell avhengighet X → Y uttrykker en
beskrankning: Hvis to rader har samme verdi i X må
de ha samme verdi i Y.
– Eks: Hvis to rader har samme KNr (5022), så må
de ha samme Adresse. Dvs. at KNr → Adresse.
•  Vi sier at X bestemmer Y, og kaller X en determinant.
•  For å avgjøre om X → Y må vi kjenne betydningen til
X og Y. Beskrankningen skal gjelde for alle mulige
tabellinnhold.
10.03.15
12
Funksjonelle avhengigheter II
•  Eksempler:
– VareNr → Betegnelse
– VareNr → Pris
– OrdreNr, VareNr → Antall
•  Kan disse «forenkles»?
– VareNr, Betegnelse → Pris
– OrdreNr, VareNr, Antall, Betegnelse → Pris
– VareNr → Pris, Kategori
10.03.15
13
Funksjonelle avhengigheter III
•  Grafisk notasjon:
A
B
C
D
E
•  X kandidatnøkkel: X → Y for alle Y
•  Noen avhengigheter lar vi være underforstått.
10.03.15
14
Normaliseringsprosessen
Tabell på 1NF
Fjern partielle
avhengigheter.
Tabell på 2NF
Fjern transitive
avhengigheter.
Tabell på 3NF
Fjern resterende
redundans.
Tabell på BCNF
10.03.15
15
Normaliseringssteg
A
A
B
A
B
C
B
C
D
C
D
D
E
E
D
F
E
F
E
10.03.15
16
1. NormalForm (1NF)
q En tabell tilfredsstiller 1NF hvis alle verdier er atomære.
Ø 1NF er kun av historisk interesse; enhver tabell er pr.
definisjon på 1NF.
Ø Restriksjonen til atomære verdier hindrer «tabeller i
tabeller» / «repeterende grupper».
Ø Vi har ikke jobbet med tabeller som ikke er på 1NF.
10.03.15
17
2. NormalForm (2NF)
q En tabell tilfredsstiller 2NF hvis den er på 1NF og
dessuten ikke har attributter som er partielt avhengig av
primærnøkkelen.
A
B
C
D
Brudd!
E
10.03.15
18
3. NormalForm (3NF)
q En tabell tilfredsstiller 3NF hvis den er på 2NF og dessuten
ikke inneholder transitive funksjonelle avhengigheter.
A
B
C
D
Brudd!
E
10.03.15
19
Boyce-Codd NormalForm (BCNF)
•  En tabell er på BCNF hvis enhver minimal
determinant er en kandidatnøkkel.
A
B
C
D
Brudd!
E
10.03.15
20
Repeterende gruppe i egen relasjon
ansatt
bopel
priv.tlf
lønn
250000
120
Oslo
22334466
110
Skedsmo
63298765
081
Asker
230
Bærum
prosjekt
ansatt
Alfa
120
200
Beta
120
250
Alfa
110
75
Alfa
081
150
Beta
230
100
prosj.timer
avdeling
avd.adr
avd.tlf
avd.budsj
Salg
Oslo
22876543
2000000
Salg
Oslo
22876543
2000000
240000
Produksj.
Bærum
22878855
1500000
300000
Økonomi
Bærum
22878850
1000000
•  Bare atomiske verdier
•  Fast antall attributter i hver relasjon
•  Primærnøkkel definert
•  Ikke null i primærnøkkel
Tilfredsstiller de formelle krav for
relasjoner, men . . .
10.03.15
21
Partielle og transitive funksjonelle
avhengigheter
prosjekt
ansatt
Alfa
120
200
250000
Beta
120
250
250000
Alfa
110
75
Alfa
081
150
240000
Beta
230
100
300000
ansatt
bopel
prosj.timer
priv.tlf
lønn
250000
120
Oslo
22334466
110
Skedsmo
63298765
081
Asker
230
Bærum
lønn
avdeling
Partiell funksjonell avhengighet
avd.budsj
Salg
2000000
Salg
2000000
240000
Produksj.
1500000
300000
Økonomi
1000000
10.03.15
Transitiv
funksjonell avhengighet
22
Funksjonelle avhengigheter
Dersom det i en relasjon til ethvert tidspunkt er to
(muligens sammensatte attributter) X og Y der verdiene
alltid er slik at det like verdier av X gir like verdier av Y, er
Y funksjonelt avhengig av X.
Sagt på en annen måte:
Y er funksjonelt avhengig av X hvis X entydig bestemmer
Y
ansatt
bopel
priv.tlf
120
Oslo
22334466
110
Skedsmo
63298765
081
Asker
230
Bærum
lønn
250000
avdeling
avd.adr
avd.tlf
avd.budsj
Salg
Oslo
22876543 2000000
Salg
Oslo
22876543 2000000
240000
Produksj.
Bærum
22878855 1500000
300000
Økonomi
Bærum
22878850 1000000
10.03.15
23
Eksempel på funksjonelle avhengigheter
ansatt
bopel
priv.tlf
lønn
250000
120
Oslo
22334466
110
Skedsmo
63298765
081
Asker
230
Bærum
avdeling
avd.adr
avd.tlf
avd.budsj
Salg
Oslo
22876543 2000000
Salg
Oslo
22876543 2000000
240000
Produksj.
Bærum
22878855 1500000
300000
Økonomi
Bærum
22878850 1000000
Husk at en funksjonell avhengighet skal gjelde for alle
lovlige forekomster i et relasjonsskjema.
Et tilfeldig øyeblikksbilde av tupler kan derfor bare gi et
ufullstendig bilde av hvilke funksjonelle avhengigheter
som finnes. Derfor må de funksjonelle avhengigheter
avledes fra “virkelighetens” regler!
10.03.15
24
Normaliseringsprosessen
Til 1. normalform:
• 
A
B
C
D
E
C
Skill ut repeterende
grupper
D
E
C
D
E
F
G
A
B
F
G
A
C
D
E
A
C
D
C
E
A
B
B
G
Til 2. normalform:
• 
Skill ut attributter som er
funksjonelt avhengige av
en del av primærnøkkelen
sammen med en kopi av
denne
Til 3. normalform:
• 
Skill ut attributter som
er funksjonelt
avhengige av andre
attributter sammen
med en kopi av disse
A
A
C
B
D
F
E
G
F
GS: Dataorientert systemutvikling figur 6.6
10.03.15
25
Normalformer 1NF, 2NF, 3NF
•  Tabellene skal bare ha én kandidatnøkkel og denne
er primærnøkkelen –dette er en forenkling
•  1NF (Første normalform) har ingen repeterende
grupper, dvs hver rute inneholder kun én verdi
•  En tabell i 2NF er i 1NF og ingen av de ikke-nøkkel
kolonnene determineres av en mindre del av
nøkkelen
•  En tabell i 3NF er i 2NF og det er ingen transitive
determineringer (en ikke-nøkkelkolonne
determineres av en annen ikke-nøkkelkolonne)
10.03.15
26
Disse tabellene er i 3NF.
10.03.15
27
Dette var et overblikk over
normalisering
• Informasjon skal ikke gå tapt pga normalisering,
verken entitetsinformasjon eller reelle bindinger
mellom relasjoner
• Men ønsker vi alltid å normalisere fullt ut?
• Det er kjent at søkingen går raskere over færre tabeller
• Hvis vi bevisst avkorter normaliseringen, burde vi
dokumentere hvorfor vi har valgt å gjøre det.
10.03.15
28
Normalformene (1)
•  1. normalform (1NF)
–  Primærnøkkelattributtene er definert
–  Ingen repeterende grupper
–  Alle attributter funksjonelt avhengig av
primærnøkkelen
10.03.15
29
Normalformene (2)
–  1. normalform
–  Ingen partielle funksjonelle avhengigheter
–  2. normalform
–  Ingen transitive funksjonelle avhengigheter
•  Boyce-Codd
–  Er det flere avhengigheter? Disse bør eventuelt
fjernes / legges til egne tabeller
10.03.15
30
Øvingsoppgaver
•  Oppgave 6
– Normalisering av tabellet
•  DimPostnummer(Postnummer;Poststed;FylkeKode;Fylke;
KommuneKode;Kommune;PostnummerKategoriKode;Po
stnummerKategori;Latitude;Longitude)
•  Fyker(nummer,navn);
– BLOGGINNLEGG
10.03.15
31
Normalisering av tabeller
10.03.15
32

Full presentasjon

Transcription

Similar documents

Opptrening SAPS - Hanche

Verdivurderingsseminar

Pålitelighet i fremtidens kraftnett (DEPICT)

Sikring av kritisk infrastruktur og kritiske samfunnsfunksjoner

Eksamen 2015 - Universitetet i Oslo

79,00 99,00 129,00 Aura LED-lyskilder

Øving 5: Transaksjonshåndtering, logging og normalisering

NOARK-4