Video: How To Install MySQL on Windows 10 2025
En lang række problemer - kaldet modifikationsanomalier - kan plage en database, hvis du ikke strukturerer SQL database korrekt. For at forhindre disse problemer kan du normalisere databasestrukturen. Normalisering indebærer generelt opdeling af en database tabel i to enklere tabeller.
Modifikationsanomalier er så navngivet, fordi de genereres ved at tilføje, ændre til eller slette data fra en database tabel.
Antag for eksempel at din virksomhed sælger rengøringsprodukter til husholdningerne, og du opkræver alle kunder samme pris for hvert produkt. SALES bordet holder styr på alt for dig. Antag at kunde 1001 bevæger sig væk og ikke længere er kunde. Du er ligeglad med hvad han har købt i fortiden, fordi han ikke vil købe noget fra dig igen. Du vil slette sin række fra bordet.
Hvis du gør det, mister du ikke bare det faktum, at kunden 1001 har købt vaskemiddel; du mister også det faktum, at vaskemiddel koster $ 12. Denne situation kaldes en sletningsanomali. Ved at slette en kendsgerning (at kunden 1001 købte vaskemiddel), fjerner du utilsigtet en anden kendsgerning (det vaskemiddel koster $ 12).
Du kan bruge det samme bord til at illustrere en indsætningsanomali. Antag for eksempel at du vil tilføje stok deodorant til din produktlinje til en pris på $ 2. Du kan ikke tilføje disse data til SALES-bordet, før en kunde køber stick deodorant.
Problemet med SALES-tabellen er, at denne tabel beskæftiger sig med mere end én ting: Det dækker ikke kun hvilke produkter kunderne køber, men også hvad produkterne koster. For at eliminere uregelmæssighederne skal du opdele SALES-tabellen i to tabeller, der kun omhandler et tema eller en ide.
-
CUST_PURCH, der omhandler den eneste ide om kundekøb.
-
PROD_PRICE, der beskæftiger sig med den enkeltes idé om produktpriser.
Du kan nu slette rækken for kunde 1001 fra CUST_PURCH uden at miste det faktum, at vaskemiddel koster $ 12. (Vaskene til vaskemiddel opbevares nu i PROD_PRICE.) Du kan også tilføje stok deodorant til PROD_PRICE, uanset om nogen har købt produktet. Købsoplysningerne gemmes andre steder i CUST_PURCH-tabellen.
Processen med at opdele et bord i flere tabeller, der hver har et enkelt tema, kaldes normalisering. En normalisering, der løser et problem, kan ikke påvirke andre problemer.Du skal muligvis udføre flere på hinanden følgende normaliseringsoperationer for at reducere hver resulterende tabel til et enkelt tema.
Hver database tabel skal omhandle et - og kun et hovedtema. Nogle gange (som du sandsynligvis gættede) at bestemme, at en tabel virkelig omhandler to eller flere temaer kan være svært.
Du kan klassificere tabeller i henhold til de typer af modifikationsanomalier, som de er underlagt. I et 1970-dokument identificerede E. F. Codd tre kilder til modifikationsanomalier og definerede første, anden og tredje normale former (1NF, 2NF, 3NF) som retsmidler til disse typer af anomalier. I de efterfølgende år opdagede Codd og andre yderligere typer af anomalier og specificerede nye normale former for at håndtere dem.
Den normale form for Boyce-Codd (BCNF), den fjerde normale form (4NF) og den femte normale form (5NF) gav hver især en højere grad af beskyttelse mod modifikationsanomalier. Men først i 1981 beskriver et papir, skrevet af Ronald Fagin, domæne-nøgleformularen eller DK / NF. Ved hjælp af denne sidste normale form kan du garantere , at et bord er fri for ændringer i anomalier.
De normale formularer er indlejret i den forstand, at en tabel der er i 2NF automatisk også i 1NF. Tilsvarende er et bord i 3NF automatisk i 2NF og så videre. For de fleste praktiske applikationer er det tilstrækkeligt at sætte en database i 3NF for at sikre en høj grad af integritet. For at være helt sikker på dens integritet skal du sætte databasen i DK / NF.
Når du har normaliseret en database så meget som muligt, vil du måske gøre udvalgte denormaliseringer for at forbedre ydeevnen. Hvis du gør det, skal du være opmærksom på de typer af anomalier, der nu kan lade sig gøre.
