SQL Domain-Key Normal Form (DK / NF) og Unormal Form

Etter at en SQL-database er i tredje vanlig form, har du eliminert de fleste, men ikke alle, sjansene for endringsavvik. Normale skjemaer utover det tredje er definert for å squash de få gjenstående bugs.

Domeneknapp normal form (DK / NF)

Boyce-Codd normal form (BCNF), fjerde normal form (4NF) og femte normal form (5NF) er eksempler på slike former. Hvert skjema eliminerer en mulig modifikasjonsanomali, men garanterer ikke forebygging av alle mulige modifikasjonsanomalier. Domeneknappens normale form gir imidlertid en slik garanti.

En relasjon er i domene-nøkkel normal form (DK / NF) hvis alle begrensninger på relasjonen er en logisk konsekvens av definisjonen av nøkler og domener. En begrensning i denne definisjonen er en regel som er presis nok til at du kan vurdere om det er sant. En nøkkel er en unik identifikator av en rad i et bord. Et domene er settet av tillatte verdier av et attributt.

Se på denne databasen, som er i 1NF, for å se hva du må gjøre for å sette databasen i DK / NF.

Tabell: SALG (Customer_ID, Product, Price)

Nøkkel: Customer_ID

Begrensninger:

• Customer_ID bestemmer Produkt

• Produktet bestemmer Pris

• Customer_ID må være et heltall > 1000

For å håndheve Begrensning 3 (at Customer_ID må være et heltall større enn 1000), kan du enkelt definere domenet for Customer_ID for å inkorporere denne begrensningen. Det gjør begrensningen en logisk konsekvens av domenet til CustomerID-kolonnen. Produktet avhenger av Customer_ID, og ​​Customer_ID er en nøkkel, så du har ikke noe problem med begrensning 1, noe som er en logisk konsekvens av nøkkeldefinisjonen.

Begrensning 2 er et problem. Prisen avhenger av (er en logisk konsekvens av) Produkt, og Produkt er ikke en nøkkel. Løsningen er å dele SALES-tabellen i to tabeller. Ett bord bruker Customer_ID som en nøkkel, og den andre bruker Produkt som en nøkkel. Databasen, i tillegg til å være i 3NF, er også i DK / NF.

Design databasene dine slik at de er i DK / NF hvis det er mulig. Hvis du kan gjøre det, vil håndheving av nøkkel- og domenestriksjoner føre til at alle begrensninger blir oppfylt, og endringsforstyrrelser er ikke mulige. Hvis en databasestruktur er utformet for å hindre deg fra å sette den inn i DK / NF, må du bygge begrensningene i applikasjonsprogrammet som bruker databasen. Databasen selv garanterer ikke at begrensningene vil bli oppfylt.

Unormal form

Som i livet, så i databaser: Noen ganger blir unormal lønn.Du kan bli båret med normalisering og gå for langt. Du kan slå opp en database i så mange tabeller at hele greien blir uhåndterlig og ineffektiv. Ytelsen kan plummet. Ofte er den optimale strukturen for databasen noe deformalisert.

Faktisk er praktiske databaser (de egentlig store, uansett) nesten aldri normalisert helt til DK / NF. Du vil normalisere databasene du designer så mye som mulig, for å eliminere muligheten for data korrupsjon som skyldes endringsendringer.

Etter at du har normalisert databasen så langt du kan, gjør du noen retrievals som et tørr løp. Hvis ytelsen ikke er tilfredsstillende, undersøk ditt design for å se om selektiv denormalisering vil forbedre ytelsen uten å ofre integritet. Ved å nøye legge til redundans på strategiske steder og denormaliserende akkurat nok , , kan du komme til en database som er både effektiv og sikker fra anomalier.