Kan ikke forstå Boyce-Codd

Hej…


Jeg læser og lærer fra bogen ”Database Systems the Complete Book” (isbn: 0-13-031995-3)

Jeg er i gang med afsnittet omkring Boyce-Codd Normal Form, hvilket volder mig store problemer.

I det følgende vil jeg prøve at opridse bogens definition af BCNF og gengive et eksempel som bryder BCNF

Jeg vil mene at jeg har nogenlunde styr på regler for functional dependencies.

”The goal of decomposition is to replace a relation by several that do not exhibit anomalies”
    |
- ... BCNF is a simple (hmm) condition under which the anomalies discussed above can be guaranted not to exist.


·    A realtion R is in BCNF if and only if: whenever there is a nontrivial functional dependency A2 A1 ...... An -> B for R, it is the case that {A1, A2,...,An} is a superkey for R


Example 3.25

Hosstående eksempel viser en relation (Movies2) der bryder med BCNF. (nøgler angivet med store bogstaver)

Movies2(TITLE : string , YEAR : integer , length : integer , inColor : boolean , studioName : string,  STARNAME : string)
   
Movies2 bygger på en tidligere version af relationen Movies1 som ikke bryder med BCNF Movies1(TITLE, YEAR, length, inColor, studioName).


En Movie-relation indgår i et database-skema, med relationerne:



Movies1(TITLE, YEAR, length, inColor, studioName) 

eller

Movies2(TITLE : string , YEAR : integer , length : integer , inColor : boolean , studioName : string,  STARNAME : string)

og

StarsIn(MovieTitle: string , MOVIEYEAR : integer , STARNAME : string)
MovieStar(NAME : string , addresse : string , gender: char, birthdate: date)
MovieExec(name : string, address: string , CERT# : integer , netWorth : integer)
Studio(NAME : string , address : string , presC#: integer)


I Movies2, har man valgt at tilføre variablen ’starname’, for at vise at der er for meget information, i en enkelt relation, hvilket helt tydeligt fremgår af nedenstående ’instance’, hvor samtlige informationer gentages for hver enkelt ’star’.


title      year    length    inColor    studioName          starname

Star W    1977    124    true    Fox          CarrieFisher   
Star W    1977    124    true    Fox          Mark Hamill
Star W    1977    124    true    Fox          Harrison Ford
Wayne´s W    1992    95    true    Paramount          Mike Meyers   

Men når dette eksempel nu skal bruges til at vise, hvorfor denne relation ikke er på BCNF, så er det at filmen knækker for mig L


Gentagelse af BCNF :
   
A realtion R is in BCNF if and only if: whenever there is a nontrivial functional dependency A2 A1 ...... An -> B for R, it is tha case that {A1, A2,...,An} is a superkey for R


Nedenstående attributter udgør nøglen i Movies2 – da nøglen er den minimale mængde attributter, der kan funktionelt bestemme alle andre attributter :

TITLE, YEAR , STARNAME

Hvorimod hvis vi havde med Movies1 at gøre, ville nøglen være:

    TITLE, YEAR



En nontrivial FD :  En funktionel afhængighed, hvor mindst en af de attributter der befinder sig på højre side af pilen, ikke befinder sig på venstre side.


En ’superkey’ (superset of a key) = En nøgle som indeholder den minimale nøgle, men kan også indeholde andre attributter fra relationen.



I hosstående eksempel (dvs. example 3.25), fastslås det derfor, at man ikke kan have en supernøgle for Movies2, uden de tre attributter TITLE, YEAR, STARNAME indgår.


Er der nogen her, der kan forklare mig, hvordan Movies2 bryder med BCNF, og gerne i forlængelse af det ovenstående.


Bogens videre argumentation går på, at man skal betragte den funktionelle afhængighed:

    title year - > length filmType inColor
        |
        |
        -> skal det forstås sådan, at en delmængde af ens nøgle ikke må kunne funktionelt bestemme andet end trivial attributter (ved ikke om dette begreb eksisterer – men altså attributter på højre siden, som kun befinder sig på venstre siden (dvs. en delmængde af nøglens delmængde)??)
   
Jeg har fundet det ret svært at skulle adskille mit problem fra den kontekst bogen har oparbejdet igennem flere kapitler, så hvis der er noget som virker uklart/indforstået i min fremlægning, vil jeg meget gerne forsøge at uddybe det.

Hvis jeg husker det rigtigt, er det, lidt populært sagt, fordi alle dele af nøglen skal være mulige primære nøgler.
Title kan ikke være primær nøgle, når du tilføjer starname.

Men så ville movies1 heller ikke følge BCNF på grund af year.
Sorry.

Dårlig bog efter min mening.

3NF = 2NF og ikke primær nøgle felterne er gensidigt uafhængige

BCNF = alle determinanter er en mulig primær nøgle

Forskellen på 3NF og BCNF eksisterer kun hvis:
- der er flere mulige primær nøgler
- de mulige primær nøgler består af flere felter
- de overlapper (d.v.s. et eller flere felter er fælles)

Movies2 er klart ikke BCNF fordi title+year ikke er en mulig
primær nøgle men alligevel er en determinant (bestemmer length, inColor
og studioName).

Og så har jeg brugt meget tid på at lede efter den anden mulige
primær nøgle som overlatter med title+year+starname for at se hvorfor
der forskel på 3NF og BCNF.

Lige indtil jeg opdagede at movies2 ikke er 3NF. Fordi den ikke er 2NF.

2NF = alle ikke nøgle felter afhænger af hele primær nøgle (ikke kun dele deraf)

Lorte eksempel.

[tilgiv mit sprog]

Og en rigtig dårlig bog !

Hej

Tak for dit svar arne_v, det har hjulpet til min forståelse.

Håber at kunne trække på dine veksler igen en anden gang