Indholdsfortegnelse:
Video: DBMS - Domain Key Normal Form (DKNF) and Sixth Normal Form (6NF) 2024
Efter at en SQL-database er i tredje normale form, har du elimineret de fleste, men ikke alle, chancerne for ændring af anomalier. Normale former ud over tredje er defineret til at squash de få resterende bugs.
Domæne-nøgle normal form (DK / NF)
Boyce-Codd normal form (BCNF), fjerde normal form (4NF) og femte normal form (5NF) er eksempler på sådanne former. Hver formular eliminerer en mulig ændring af anomali, men garanterer ikke forebyggelse af alle mulige modifikationsanomalier. Domæne-nøgleformularen giver dog en sådan garanti.
En relation er i domæne-nøgleformel (DK / NF) hvis enhver begrænsning på forholdet er en logisk konsekvens af definitionen af nøgler og domæner. En begrænsning i denne definition er en regel, der er præcis nok til, at du kan vurdere, hvorvidt det er sandt eller ej. En nøgle er en unik identifikator af en række i en tabel. Et domæne er sætet af tilladte værdier af en attribut.
Kig på denne database, som er i 1NF, for at se, hvad du skal gøre for at sætte databasen i DK / NF.
Tabel: SALG (Customer_ID, Product, Price)
Nøgle: Customer_ID
Begrænsninger:
-
Customer_ID bestemmer Produkt
-
Produkt bestemmer Pris
-
Customer_ID skal være et helt tal > 1000
For at håndhæve begrænsning 3 (at Customer_ID skal være et helt tal større end 1000), kan du simpelthen definere domænet for Customer_ID for at indarbejde denne begrænsning. Det gør begrænsningen til en logisk konsekvens af domænet i CustomerID-kolonnen. Produktet afhænger af Customer_ID, og Customer_ID er en nøgle, så du har ikke noget problem med Begrænsning 1, hvilket er en logisk konsekvens af definitionen af nøglen.
Begrænsning 2 er et problem. Pris afhænger af (er en logisk konsekvens af) Produkt, og Produkt er ikke en nøgle. Løsningen er at opdele SALES bordet i to tabeller. Én tabel bruger Customer_ID som en nøgle, og den anden bruger Produkt som en nøgle. Databasen er udover at være i 3NF, også i DK / NF.
Design dine databaser, så de er i DK / NF, hvis det er muligt. Hvis du kan gøre det, vil håndhævelse af nøgle- og domænerestriktioner medføre, at alle begrænsninger er opfyldt, og ændringer i anomalier er ikke mulige. Hvis en databasestruktur er designet til at forhindre dig i at sætte den ind i DK / NF, så skal du opbygge begrænsningerne i applikationsprogrammet, der bruger databasen. Databasen selv garanterer ikke, at begrænsningerne vil blive opfyldt.
Unormal form
Som i livet, så i databaser: Nogle gange er unormal lønnet.Du kan blive båret væk med normalisering og gå for langt. Du kan opdele en database i så mange tabeller, at hele sagen bliver uhåndterlig og ineffektiv. Ydeevne kan dæmpe. Ofte er den optimale struktur for din database noget denormaliseret.
Faktisk er praktiske databaser (de virkelig store) alligevel aldrig normaliseret helt til DK / NF. Du vil dog normalisere de databaser, du designer så meget som muligt, for at eliminere muligheden for datakorruption, der skyldes ændringer i anomalier.
Når du har normaliseret databasen, så vidt du kan, gør du nogle hentninger som et tørt løb. Hvis ydeevnen ikke er tilfredsstillende, skal du undersøge dit design for at se, om selektiv denormalisering vil forbedre ydeevnen uden at ofre integriteten. Ved omhyggeligt at tilføje redundans på strategiske steder og denormaliserende lige nok , kan du komme til en database, der er både effektiv og sikker mod uregelmæssigheder.
