"Kristian Damm Jensen" <REdammMOVE@ofir.dk> skrev:
> Trine Banke Brenneche wrote:
<snip>
> > Det er vel noget isar relationel-model-purister gar ind for - fx.
> > hvis du har en database over musik, sa er den ene halvdel maske pa
> CD
> > og den anden halvdel pa noder. Pa CDerne er man maske interesseret i
> > hvem der spiller musikken, mens der i noderne selvfolgelig ikke er
> > nogen, der spiller - det skal du selv gore
Men hvis man har
> > samlet al musik i een tabel vil det give NULL-vardier i "udfort af"
> > ved samtlige noder. Nogle valger at leve med det, mens puristerne
> > mener, at sa bor man splitte tabellen i 2 tabeller, hvor det sa kun
> > er CDerne, der har relation til den ny tabel hvori i de udovende
> > musikere befinder sig. Dermed undgar man en masse NULL-vardier, som
> > alligevel optager unodig plads, da det er irrelevant med "udfort
> af",
> > nar vi taler om noder.
>
> "Purister" som du kalder dem, bekymrer sig ikke om pladsforbrug, men
> om den logiske sammenhæng i databasen.
Yup, men _samtidig_ sparer det vel plads, når man ikke længere har
NULL-"værdierne", idet man jo ikke har sat en værdi ind i stedet?
<snip>
> Problemet er (efter min mening) ikke så meget NULL i sig selv. Men
> NULL kan være en indikation af, at man kunne gøre et bedre stykke
> arbejde med at modellere basen.
Ja, det er vel også netop det puristerne mener, og i hvert fald det jeg har
_forsøgt_ at forklare med mit musik-eksempel...
<snip>
> > Desuden er der jo
> > ogsa (i hvert fald med det eksempel jeg har navnt) noget med en
> > normalform, der siger, at een vardi i en tabel ikke ma vare afhangig
> > af en anden vardi i tabellen, ligesom NULL altid vil vare kadet
> > sammen med Noder.
>
> Nej, det er der ingen regler der siger, tværtimod. Alle værdier vil jo
> (oplagt) være afhængige af primærnøglen (som også er en værdi). 3NF
> siger, at der ikke må findes funktionelle afhængigheder (dvs. at du
> kan identificere en værdi ud fra en anden) uden at den funktionelle
> afhængighed indikerer en _mulig_ primærnøgle i tabellen.
Jeg giver dig ret i at det måske er et tvivlsomt eksempel med musikken, da
vi ikke kan sige om der der kun vil være NULL ved "udført af" hvis det er
noder, og det kun vil være noder, hvis der er NULL ved "udført af".
Det jeg havde forestillet mig var en tabel med:
> > Men, er det ikke primart sadan, at man ideelt set gerne vil minimere
> > brugen af NULL-vardier, bade af ovenstaende grund og ogsa fordi de
> sa
> > at sige unodvendigt optager plads (omend lidt plads) ?
>
> Et NULL vil i mange tilfælde optage lige så meget plads som en værdi
> ville gøre. I en tabel med et par millioner poster kan det hurtigt
> løbe op.
Min pointe var, at NULL optager unødvendig plads idet NULL kunne udraderes
ved at splitte op i to tabeller. Så er NULL ikke længere NULL, NULL er
heller ikke erstattet af en værdi, den er simpelthen elimineret.
<snip>
> Vær opmærksom på, at de skelner mellem 3NF og BCNF, hvilket man ikke
> altid gør. BCNF er en anelse mere restriktiv en 3NF (uden at jeg kan
> forklare hvordan). Den beskrivelse jeg giver ovenfor er i
> virkeligheden BCNF.
Sådan som jeg har forstået det er BCNF mere restriktiv, fordi man ikke kan
overholde den uden at overholde 2NF og 3NF. Man kan selvf. heller ikke
overholde 3NF uden at overholde 2NF idet det er en del af definitionen på
3NF at den skal overholde 2NF - men i definitionen af BCNF behøver man altså
ikke at skrive at den skal overholde 3NF, for det kommer helt af sig selv:
- 2NF taler om, at alle ikke-nøgleattributter skal være fuldt funktionelt
afhængige af kandidatnøglen. (-nøglerne). BCNF kræver, at alle
determinantfelter skal være kandidatnøgler. Hvis vi har et tilfælde, hvor en
ikke-nøgleattribut er funktionelt afhængig af en del af nøglen, vil denne
del af nøglen jo være en determinant-attribut, som ikke i sig selv er en
kandidatnøgle. Definitionen på BCNF "fanger" altså tilfælde, hvor der ikke
er fuldt funktionel afhængighed af kandidatnøglen.
- 3NF taler om transitive afhængigheder, hvori der jo indgår afhængigheder
mellem attributter, som ikke deltager i nøglen. Eksisterer der en
transitiv-afhængighed i en tabel, eksisterer der altså en
determinant-attribut, som ikke er kandidatnøgle. BCNF "fanger" altså også
dette tilfælde.
Altså kan man være grov at sige, at man kan nøjes med at fokusere på
definitionen på BCNF og blot opfatte de øvrige normalformer, som
"baggrundsmateriale, der kan være med til at forklare, hvad def. på BCNF
egentlig drejer sig om".
> I praksis ville jeg aldrig give mig i kast med at normalisere forbi
> BCNF.
Jeg tror slet ikke jeg ved, hvad 4NF og 5NF går ud på...
Mvh
Trine Banke Brenneche
--
http://www.brenneche.dk/