Inhoudsopgave:
Video: Tune in for Microsoft Connect(); 2018 2024
Nadat een SQL-database zich in de derde normale vorm bevindt, hebt u de meeste, maar niet alle, kansen op afwijkingen van wijzigingen geëlimineerd. Normale vormen voorbij de derde zijn gedefinieerd om die paar overgebleven fouten te pletten.
Normsleutel standaardvorm (DK / NF)
Boyce-Codd normaalvorm (BCNF), vierde normaalvorm (4NF) en vijfde normaalvorm (5NF) zijn voorbeelden van dergelijke vormen. Elke vorm elimineert een mogelijke wijzigingsanomalie, maar biedt geen garantie voor het voorkomen van alle mogelijke aanpassingsanomalieën. De standaardsleutel voor de normale vorm biedt echter een dergelijke garantie.
Een relatie bevindt zich in domeinsleutel normale vorm (DK / NF) als elke beperking van de relatie een logisch gevolg is van de definitie van sleutels en domeinen. Een -beperking in deze definitie is een regel die precies genoeg is om te evalueren of deze klopt. Een -sleutel is een unieke ID van een rij in een tabel. Een domein is de reeks toegestane waarden van een kenmerk.
Kijk naar deze database, die zich in 1NF bevindt, om te zien wat u moet doen om die database in DK / NF te plaatsen.
Tabel: SALES (Customer_ID, Product, Prijs)
Sleutel: Customer_ID
Constraints:
-
Customer_ID bepaalt Product
-
Product bepaalt Prijs
-
Customer_ID moet een geheel getal zijn > 1000
Om Constraint 3 af te dwingen (dat Customer_ID moet een geheel getal groter dan 1000 zijn), kunt u eenvoudig het domein definiëren voor Customer_ID om deze beperking op te nemen. Dat maakt de beperking een logisch gevolg van het domein van de kolom CustomerID. Product is afhankelijk van Customer_ID en Customer_ID is een sleutel, dus je hebt geen probleem met Constraint 1, wat een logisch gevolg is van de definitie van de sleutel.
Constraint 2 is een probleem. Prijs is afhankelijk van (is een logisch gevolg van) Product en Product is geen sleutel. De oplossing is om de SALES-tabel op te splitsen in twee tabellen. Eén tabel gebruikt Customer_ID als een sleutel en de andere gebruikt Product als een sleutel. De database bevindt zich behalve in 3NF ook in DK / NF.
Ontwerp uw databases zodat ze indien mogelijk in DK / NF zijn. Als u dat kunt doen, zorgt het afdwingen van sleutel- en domeinbeperkingen ervoor dat aan alle beperkingen wordt voldaan en dat er geen aanpassingsanomalieën mogelijk zijn. Als de structuur van een database is ontworpen om te voorkomen dat u deze in DK / NF plaatst, moet u de beperkingen bouwen in het toepassingsprogramma dat de database gebruikt. De database zelf garandeert niet dat aan de beperkingen zal worden voldaan.
Afwijkende vorm
Zoals in het leven, dus in databases: soms loont het abnormaal zijn.Je kunt je laten meeslepen door normalisatie en te ver gaan. Je kunt een database in zoveel tabellen opdelen dat het hele ding onpraktisch en inefficiënt wordt. De prestaties kunnen kelderen. Vaak is de optimale structuur voor uw database enigszins gedenormaliseerd.
Eigenlijk zijn praktische databases (de echt grote zelfs) vrijwel nooit genormaliseerd tot helemaal DK / NF. U wilt de databases die u ontwerpt zoveel mogelijk normaliseren om echter de mogelijkheid van gegevensbeschadiging die het gevolg is van wijzigingsafwijkingen te voorkomen.
Nadat u de database zo ver mogelijk hebt genormaliseerd, maakt u enkele retrievals als een droge run. Als de prestaties niet bevredigend zijn, onderzoekt u uw ontwerp om te zien of selectieve denormalisatie de prestaties zou verbeteren zonder concessies te doen aan de integriteit. Door zorgvuldig redundantie toe te voegen op strategische locaties en te denormaliseren, net genoeg , kunt u komen tot een database die zowel efficiënt als veilig is voor anomalieën.
