Introduktion til databasens normalisering

Databasens normalisering er en proces, der bruges til at organisere en database i tabeller og kolonner. Hovedideen med dette er, at en tabel skal handle om et bestemt emne og kun understøtte emner inkluderet. Tag et regneark med oplysningerne som et eksempel, hvor dataene indeholder sælgere og kunder, der tjener flere formål:

• Identificer sælgere i din organisation
• Liste over alle kunder, som din virksomhed opfordrer til at sælge et produkt
• Identificer, hvilke sælgere der kalder på bestemte kunder.

Ved at begrænse en tabel til et formål reducerer du antallet af duplikatdata indeholdt i din database. Dette eliminerer nogle problemer, der skyldes databasemodifikationer.

For at nå disse mål bruger vi nogle etablerede regler. Når du anvender disse regler, dannes der nye tabeller. Forløbet fra uregerlig til optimeret passerer gennem flere normale former.

Der er tre normale former, som de fleste databaser overholder brugen. Da tabeller opfylder hver på hinanden følgende database normaliseringsformular, bliver de mindre tilbøjelige til at ændre databasemodifikationsafvigelser og mere fokuseret mod et eneste formål eller emne. Inden vi går videre, skal du være sikker på at du forstår definitionen af en databasetabel.

Årsager til databasens normalisering

Der er tre hovedårsager til at normalisere en database. Den første er at minimere duplikatdata, den anden er at minimere eller undgå problemer med datamodifikation, og den tredje er at forenkle forespørgsler.

Når vi gennemgår de forskellige normaliseringstilstande, diskuterer vi, hvordan hver form behandler disse problemer, men for at starte, lad os se på nogle data, der ikke er normaliseret, og diskutere nogle potentielle faldgruber.

Jeg tror, at når du først har forstået problemerne, sætter du bedre pris på normalisering. Overvej følgende tabel:

Den første ting at bemærke er, at denne tabel tjener mange formål, herunder:

1. Identificering af organisationens sælgere
2. Notering af salget kontorer og telefonnumre
3. Tilknytning af en sælger til et salgskontor
4. Visning af hver sælgers kunder

Som DBA rejser dette et rødt flag. Generelt kan jeg godt lide at se tabeller, der har et formål. At have bordet tjener mange formål introducerer mange af udfordringerne; nemlig dataduplikering, dataopdateringsproblemer og øget indsats for at forespørge data.

Data duplikering og modifikationsanomalier

Bemærk, at vi for hver SalesPerson har angivet både SalesOffice og OfficeNumber. Der er duplikerede sælgerdata. Dupliceret information giver to problemer:

1. Det øger lagring og mindsker ydeevnen.
2. Det bliver sværere at vedligeholde dataændringer.

For eksempel:

Overvej om vi flytter Chicago-kontoret til Evanston, IL. For korrekt at afspejle dette i vores tabel er vi nødt til at opdatere posterne for alle SalesPersons, der i øjeblikket er i Chicago. Vores tabel er et lille eksempel, men du kan se, om den var større, at dette potentielt kunne involvere hundredvis af opdateringer.

Disse situationer er ændringer i ændringer. Databasens normalisering løser dem. Der er tre ændringer, der kan forekomme:

Indsæt anomali

Der er fakta, vi ikke kan registrere, før vi kender information for hele rækken. I vores eksempel kan vi ikke optage et nyt salgskontor, før vi også kender sælgeren. Hvorfor? Fordi for at oprette posten skal vi give en primær nøgle. I vores tilfælde er dette Medarbejder-ID.

Opdater anomali

I dette tilfælde har vi de samme oplysninger i flere rækker. For eksempel, hvis kontornummeret ændres, er der flere opdateringer, der skal foretages. Hvis vi ikke opdaterer alle rækker, vises uoverensstemmelser.

Sletningsanomali

Sletning af en række medfører fjernelse af mere end et sæt fakta. For eksempel, hvis John Hunt går på pension, så når vi sletter denne række, mister vi oplysninger om New York-kontoret.

Problemer med søgning og sortering

Den sidste grund, vi overvejer, er at gøre det lettere at søge og sortere dine data. I SalesStaff-tabellen, hvis du vil søge efter en bestemt kunde som Ford, bliver du nødt til at skrive en forespørgsel som

SELECT SalesOfficeFROM SalesStaffWHERE Customer1 = ‘Ford’ OR Customer2 = ‘Ford’ OR Customer3 = ‘Ford’

Klart, hvis kunden på en eller anden måde var i en kolonne ville vores forespørgsel være enklere. Overvej også, om du vil køre en forespørgsel og sortere efter kunde.

Vores nuværende tabel gør dette svært. Du bliver nødt til at bruge tre separate UNION-forespørgsler!Du kan fjerne eller reducere disse uregelmæssigheder ved at adskille dataene i forskellige tabeller. Dette placerer dataene i tabeller, der tjener et enkelt formål.

Processen til at redesigne tabellen er databasens normalisering.

Definition af database normalisering

Der er tre almindelige former for database normalisering: 1., 2. og 3. normal form. De forkortes også som henholdsvis 1NF, 2NF og 3NF.

Der er flere yderligere former, såsom BCNF, men jeg betragter dem som avancerede og ikke alt for nødvendige for at lære i starten.

Formularerne er progressive, hvilket betyder at for at kvalificere sig til 3. normal form skal en tabel først opfylde reglerne for 2. normal form, og 2. normal form skal overholde dem for 1. normal form. Før vi diskuterer de forskellige former og regler i detaljer, lad os opsummere de forskellige former:

• Første normale form – Oplysningerne gemmes i en relationstabel med hver kolonne, der indeholder atomværdier. Der er ingen gentagne grupper af kolonner.
• Anden normal form – Tabellen er i første normale form, og alle kolonnerne afhænger af tabellens primære nøgle.
• Tredje normal form – tabellen er i anden normal form, og alle dens kolonner er ikke afhængigt af den primære nøgle transit

Hvis reglerne ikke giver for meget mening, skal du ikke bekymre dig. Jeg har linket til artiklen for at hjælpe dig med at forstå dem.

Indtil videre er det vigtigt at forstå, at der er tre regler for databasens normalisering, der gælder for hinanden. Nogle mennesker får databasens normalisering til at virke kompliceret.

men det behøver ikke at være, og når du først forstår det, bliver det intuitivt.