Video: Web Programming - Computer Science for Business Leaders 2016 2025
En rekke problemer - kalt modifikasjonsanomalier - kan plage en database hvis du ikke strukturerer SQL database riktig. For å forhindre disse problemene kan du normalisere databasestrukturen. Normalisering innebærer generelt å dele en databastabell i to enklere tabeller.
Modifikasjonsanomalier er oppkalt fordi de genereres ved å legge til, endre til eller slette data fra en databasetabell.
Anta at firmaet ditt selger rengjøringsprodukter til husholdningen, og du belaster alle kunder samme pris for hvert produkt. SALES-bordet holder styr på alt for deg. Anta at kunde 1001 beveger seg bort og ikke lenger er kunde. Du bryr deg ikke hva han har kjøpt tidligere, fordi han ikke kommer til å kjøpe noe fra deg igjen. Du vil slette sin rad fra bordet.
Hvis du gjør det, mister du ikke bare det faktum at kunden 1001 har kjøpt vaskemiddel; du mister også det faktum at vaskemiddel koster $ 12. Denne situasjonen kalles sletting avvik. Ved å slette et faktum (at kunden 1001 kjøpte vaskemiddel), sletter du et annet faktum (dette vaskemiddel koster $ 12).
Du kan bruke det samme tabellen for å illustrere en innføringsanomali. For eksempel, anta at du vil legge til deodorant til din produktlinje til en pris på $ 2. Du kan ikke legge til disse dataene i SALES-tabellen til en kunde kjøper stikk deodorant.
Problemet med SALES-tabellen er at denne tabellen omhandler mer enn én ting: Det dekker ikke bare hvilke produkter kundene kjøper, men også hva produktene koster. For å eliminere uregelmessighetene må du dele SALES-tabellen i to tabeller, som hver omhandler bare ett tema eller en ide.
-
CUST_PURCH, som omhandler den eneste ideen om kundekjøp.
-
PROD_PRICE, som omhandler den enkle ideen om produktprising.
Du kan nå slette raden for kunde 1001 fra CUST_PURCH uten å miste at vaskemiddel koster $ 12. (Kostnaden for vaskemiddel er nå lagret i PROD_PRICE.) Du kan også legge til deodorant til PROD_PRICE om noen har kjøpt produktet. Kjøpsinformasjon lagres andre steder, i CUST_PURCH-tabellen.
Prosessen med å bryte opp et bord i flere tabeller, som hver har et enkelt tema, kalles normalisering. En normaliseringsoperasjon som løser et problem, kan ikke påvirke andre problemer.Det kan hende du må utføre flere påfølgende normaliseringsoperasjoner for å redusere hver resulterende tabell til et enkelt tema.
Hver databasetabell skal omhandle ett - og bare ett - hovedtema. Noen ganger (som du sikkert gjettet) bestemmer deg for at et bord virkelig omhandler to eller flere temaer kan være vanskelig.
Du kan klassifisere tabeller i henhold til de typer modifikasjonsanomalier som de er underlagt. I et 1970-dokument identifiserte E. F. Codd tre kilder til modifikasjonsanomalier og definerte første, andre og tredje normale former (1NF, 2NF, 3NF) som rettsmidler for disse typer anomalier. I de påfølgende årene oppdaget Codd og andre flere typer anomalier og angav nye normale former for å håndtere dem.
Den normale form for Boyce-Codd (BCNF), den fjerde normale form (4NF) og den femte normalformen (5NF) gir hver en høyere grad av beskyttelse mot modifikasjonsanomalier. Først i 1981 skrev imidlertid et papir, skrevet av Ronald Fagin, domene-nøkkelform eller DK / NF. Ved å bruke denne siste vanlige skjemaet kan du garantere at et bord er fritt for endringsforstyrrelser.
De vanlige skjemaene er nestet i den forstand at en tabell som er i 2NF automatisk også i 1NF. Tilsvarende er et bord i 3NF automatisk i 2NF, og så videre. For de fleste praktiske applikasjoner er det å sette en database i 3NF tilstrekkelig for å sikre en høy grad av integritet. For å være helt sikker på integriteten, må du sette databasen til DK / NF.
Når du normaliserer en database så mye som mulig, vil du kanskje gjøre valgte denormaliseringer for å forbedre ytelsen. Hvis du gjør det, vær oppmerksom på hvilke typer anomalier som nå kan bli mulig.
