Først normal form de fem normale formene

Normalisering er en databasedesigntilnærming for systematisk å dekomponere tabellene for å fjerne dataredundansen og forhindre anomalier som kan følge med innsetting, oppdatering og sletting av data. Det er den første normale formen (1NF), andre normale form (2NF), tredje normal form (3NF), Boyce-Codd normal form (BCNF), fjerde normal form (4NF) og femte normal form (5NF). Den sjette normale formen utvikles fremdeles (fremdeles i forskningsstatus) og vil ikke bli diskutert i denne serien. Boyce-Codd normal form er som 3½ (3.5) Normal form. En relasjonsdatabase består av relaterte tabeller, som burde vært normalisert.

Denne artikkelen (tutorial) forklarer om den første normale skjemaet. Dette er den første delen av serien, de fem normale formene. Eksempeldatabasen som brukes er en nærbutikk. I Storbritannia kalles en nærbutikk en hjørnebutikk. I noen land kalles det en bestemmelsesbutikk.

FN-normalisert transaksjonstabell

En transaksjon er kjøp av produkter av en kunde, fra butikken, eller mottar produkter fra butikken fra leverandørene, til salgs. Det antas i denne delen av serien (i denne opplæringen) at kontorist som registrerer transaksjonene ikke er opplært til slik innspilling. Det kan være mer enn en kontorist som ikke vet noe om normalisering. Hvis det er mer enn én kontorist, registrerer alle funksjonærene i samme treningsbok, og ingen av dem vet noe om normalisering. Innehaver (butikkeier) vet heller ingenting om normalisering. Faren hans har nettopp død og etterlatt ham penger, og han bestemte seg for å investere i en nærbutikk. Så, kontorist (eller funksjonærer) starter (er) med en tabell for å registrere alle transaksjonene. Tabellen har følgende kolonneoverskrifter der trans betyr transaksjon:

Trans (produkt, kategori, kunde, leverandør, ansatt, pris)

Overtredelse refererer til en rad i tabellen. Tabellen er en transaksjonstabell. Eksemplene på produkter som selges i butikken er: søtsaker, sjokolade, sprite, coca-cola, fanta, pepsi, melk, yoghurt, ost, tannkrem, vev, bleier, godteri, chips og nøtter. Noen av disse navnene kan vises i produktkolonnen.

Disse produktene faller inn i kategorier som er: konfekt, brus, meieriprodukt, toalettsaker og snackmat.

Kundekolonnen har navnene på personene som kjøper fra butikken. Leverandørkolonnen har navnene på selskapene som leverer produktene som skal selges av butikken. Ansattes kolonne har navnet på kontorist som selger et produkt eller mottar et produkt fra en leverandør og registrerer det. Handlingskolonnen indikerer om et salg ble gjort til en kunde eller en bestilling ble foretatt (kjøpt) fra en leverandør.

Hver pris er den totale prisen på produktene som selges eller kjøpes i en transaksjon.

Og så er de første radene på bordet:

Før du fortsetter, vet du at tabellkolonner i en databasetabell også kalles attributter. Radene med verdier kan omtales som objekter.

Legg merke til at i priskolonnen er ikke valutaen indikert. Enten valutaen er dollar eller euro eller annen valuta, trenger den ikke å være angitt. Imidlertid er det indikert i et kommentarområde som ikke er en del av tabellen.

Fra bordet: Det er tre funksjonærer så langt, unntatt innehaveren, og en av dem har gjennomført transaksjonen to ganger; Det er tre kunder så langt, og en av dem har kjøpt to ganger; Det er fire leverandørselskaper så langt, og hver er opptatt av en transaksjon.

Overflødighet:

Merk at "John Smith" vises som verdi i to rader i samme kolonne. Gjentakelse av samme verdi i samme kolonne er redundans som kan føre til regnskapsproblemer.

Første normale skjemaregler

For at en tabell skal være i første normale form, må følgende regler respekteres. Ellers ville det være regnskapsproblemer:

1) Alle kolonnene i en tabell skal ha unike toppnavn.

2) Hver celle må bare ha en enkelt verdi.

3) Verdiene som er lagret i en kolonne skal være av samme type.

4) Radene skal være forskjellige.

5) Rekkefølgen på kolonnene eller rekkefølgen av rader spiller ingen rolle.

Du, leseren, som endelig fullfører denne serien og vet alt om normale former, har blitt en databaseutvikler. Innehaveren av bekvemmelighetsbutikken er din venn. Du bestemte deg for å besøke vennens forretningsside (butikk).

Du ser på forrige tabell som de produserte. Du reflekterer i noen tid, og rister deretter på hodet og sier: "HM-HM-HM". Du forteller da vennen din, innehaveren og hans arbeidere, at ikke alle reglene for den første normale formen er respektert; Og det vil føre til regnskapsfeil.

Du har deretter tenkt å lære dem reglene for den første normale form, og undersøkte de gitte fem reglene når de er relatert til forrige tabell, en-for-en.

Regel 1: Alle kolonnene i en tabell skal ha unike toppnavn.

Har alle kolonnene i forrige tabell unike navn? Ja, og det er ok. Medlemmer av personalet er tross alt ikke uintelligente. De har rett og slett ikke blitt utdannet til normale former. Regel 1 er ikke krenket, og det utgjør ikke et problem.

Regel 2: Hver celle må bare ha en enkelt verdi.

En celle er skjæringspunktet mellom en rad og en kolonne. Ser du på den siste attributtet (kolonnen) med overskriften, prisen, er det et tall i hver celle, og det er bare ett tall per celle. Det er helt greit. Hver celle der er en verdsatt.

Når vi ser på ansattes kolonne, har hver celle ett navn på en person. Ett navn består av første og etternavn, og danner en streng (tekst). Det er helt greit. Hver celle i kolonnen har en streng, og så har hver celle en verdi.

Cellene for kunde- og leverandørkolonnene har en enkelt streng hver og så, en enkelt verdi. Det er helt greit. I kundekolonnen er “John Smith” i to forskjellige celler (rader). Det er redundans (repetisjon) og problemet vil bli diskutert senere i opplæringen for 2NF.

I kategorikolonnen skal hver celle ha en kategori. Én kategoritekst (en verdi) er en streng. I den andre cellen fra toppen er det imidlertid to kategorier (to strenger): "brus" og "meieriprodukt" atskilt med et komma. Dette er to verdier i en celle. Resten av cellene i kategorikolonnen har enkeltverdier, men denne cellen har to. Regelen om at hver celle bare må ha en enkelt verdi, er blitt krenket her i den andre cellen. Dette vil føre til regnskapsproblemer. Siden det er to verdier i en celle, er løsningen å dele opp datadata i tilsvarende to rader, og sette de to verdiene i to celler, to rader, i samme kolonne som følger:

De to kategoriene som var i en celle, er blitt satt i to celler i samme kolonne. Imidlertid har de andre cellene blitt gjentatt i kolonnene sine, og introduserer mer redundans. I løpet av å løse ett problem ble repetisjoner (redundans) lagt til, og la til et annet problem. Løsningen på repetisjoner vil bli diskutert i neste tutorial på den andre normale skjemaet.

Ser vi på den første kolonnen på produktet, har den første cellen to verdier: “søtsaker” og “sjokolade” atskilt med komma. Dette er også to produkter. Løsningen er å dele raden i to, sette de to verdiene i to forskjellige celler i samme kolonne og dessverre også doble de andre cellene.

Den andre cellen i den samme produktkolonnen har syv verdier. I likhet med den første cellen bryter dette regelen: Hver celle må bare ha en enkelt verdi. Løsningen er å erstatte raden med syv nye rader, med hver av disse verdiene i sin egen celle i samme kolonne og repetisjoner av de andre cellene i sine egne kolonner. De nye repetisjonene øker redundansen.

Av de syv produktene faller fire i kategorien brus og tre i kategorien Dairy Product. De fire produktene (Sprite, Coca-Cola, Fanta og Pepsi) er hver assosiert med kategorien, brus. Produktene (melk, yoghurt og ost) er hver tilknyttet kategorien, meieriprodukt.

Det nye bordet blir:

Regelen om at hver celle bare må ha en enkelt verdi er nå fornøyd. Det er ingen celle med mer enn en verdi i tabellen nå. Denne løsningen kom til en pris. Flere celler ble gjentatt i kolonnene sine, og la flere repetisjoner til den gitte doble (originale) repetisjonen av “John Smith”. Å sette et bord i den andre normale formen løser problemet med repetisjon (redundans) fra den første normale formen.

Merk: Repetisjon i priskolonnen blir ikke betraktet som et problem og blir ikke tatt i betraktning når du produserer 2NF. Legg også merke til at i denne resulterende tabellen har noen av de gitte prisene blitt delt og anses som passende.

Regel 3: Verdiene som er lagret i en kolonne skal være av samme type.

Det siste attributtet, priskolonnen har bare tall. Så alle verdiene i den kolonnen er av samme type kalt tall (nettopp, heltall). Hver av de andre kolonnene har verdier av typen streng. Strengtypen kalles tekst i noen databasetabellkoder. Og så, regelen om at verdiene som er lagret i en kolonne skal være av samme type, er oppfylt uten endring av hva personalet hadde gjort. De er tross alt ikke uintelligente.

Regel 4: Radene skal være forskjellige.

I den resulterende forrige tabellen er ingen to rader de samme. Noen celler forekommer i mer enn en rad i samme kolonne, men ingen to rader har de samme cellene i samme rekkefølge. Og så, regelen om at radene skal være distinkt er fornøyd uten endring av det personalet hadde gjort. De er tross alt ikke uintelligente.

Regel 5: Rekkefølgen på kolonnene eller rekkefølgen av rader spiller ingen rolle.

Enhver kolonne kan være den første eller siste kolonnen. Enhver rad kan være den første eller siste raden. Og så, regelen om at rekkefølgen på kolonnene eller rekkefølgen på radene ikke betyr noe er tilfreds uten endring av hva personalet hadde gjort. De er tross alt ikke uintelligente.

Tabellen er nå i første normal form fordi de fem reglene er fornøyde.

Av de fem reglene for å ha en tabell i første normal form, krenket personalet, inkludert deres innehaver, bare en av uvitenhet som ikke er av deres feil. Du, nettutvikleren som trener dem, må gratulere dem. Du må imidlertid insistere på at regelen om at hver celle bare må ha en enkelt verdi er den viktigste regelen for å sette en tabell i første normale form.

Vel, det er ikke alt. Du forlater ikke menneskene du trener ennå. Tabellen må gis en nøkkel (en primærnøkkel). Med andre ord, hver rad må identifiseres med en eller flere celleverdier av den raden. Hvis det ikke er mulig, må en ny kolonne opprettes på venstre side av tabellen for å bli kalt nøkkelsøylen.

Primærnøkkel

Er det noen kolonne i forrige tabell der ingen celle kan være tomme eller ha en nullverdi, og alle verdiene vil alltid være unike? Det er ingen. Hvis det var en, ville det bli gjort til den primære nøkkelen. Leseren tror kanskje at produktkolonnen har unike verdier, men dette vil ikke være tilfelle hele tiden. For eksempel kan kunden “John Smith” eller en ny kunde fremdeles komme og kjøpe søtsaker i fremtiden, som en ny transaksjon (rad). Deretter ville det være to strengverdier av søtsaker i to celler i produktkolonnen.

Er det to eller flere kolonner i den resulterende forrige tabell hvis kombinasjon av radceller er unike og ikke kan ha noen repetisjon i følgende tabell? Hvis ja, vil gruppen av kolonner danne den primære nøkkelen. Som det skjer, er det ingen slik gruppe; Med mindre alle kolonnene i tabellen skal betraktes som den primære nøkkelen siden ingen rad kan gjenta. Det må være en primærnøkkel, og det må være ikke-nøkkelkolonner i en normalisert tabell.

Siden en eller flere kolonner ikke kan være den primære nøkkelen til den resulterende tidligere tabellen, må en ny kolonne legges til på venstre ende av tabellen for å være den primære nøkkelen. I en slik primær nøkkelkolonne er ingen celle tom og ingen celle har en nullverdi. Alle verdiene i cellen må være unike. Den enkleste måten å ha slike verdier for den primære nøkkelkolonnen er å ha tall fra 1 og oppover. Det vil si at for den første raden vil verdien av den primære nøkkelen være 1. For andre rad ville verdien for den primære nøkkelen være 2. For den tredje raden ville verdien for den primære nøkkelen være 3, og så videre. Når en ny transaksjonsrekke blir lagt til i bunnen, er den nye primære nøkkelverdien en pluss den rett over den. Så den komplette tabellen for den første normale formen er som følger:

Den primære nøkkelkolonnen kalles transid for "Transaksjons -ID". Id betyr identifikator. En slik primær nøkkel er auto-increment-type som er den samme som auto-nummeret. En ny rad vil ha en primær ID på 12. Denne tabellen er en transaksjonstabell. Det er det eneste bordet som butikken har så langt.

Som fullfører tabelldesignet for den første normale skjemaet. Imidlertid, du som nettutvikleren, ikke går bort fra menneskene du trener ennå. Du må fremdeles forklare personalet (traineene) betydningen av funksjonell avhengighet. Med det vil de kunne håndtere spørsmålet om primærnøkkel, så vel som de fem reglene du lærte dem i ditt fravær.

Funksjonell avhengighet

Ideen om funksjonell avhengighet eller bare avhengighet er at når den primære nøkkelen til en rad er kjent, kan enhver annen verdi i den raden hentes. Så den primære nøkkelen er den avhengige verdien. Det avhenger av resten av de andre verdiene i raden. For eksempel, hvis transiden av 3 er gitt for forrige tabell, er det tilsvarende produktet Sprite. Den tilsvarende kategorien er "brus". Den tilsvarende kunden er “John Smith”. Den tilsvarende leverandøren er "drikkeselskap". Den tilsvarende ansatte (kontorist) er "Mary Baker". Den tilsvarende handlingen er "salg". Og beløpet (pris) som kunden betalte er $ 12 ($ er ikke angitt i tabellen).

På dette tidspunktet kan du som databaseutvikler forlate. Imidlertid, før du drar, oppsummerer du hva du lærte dem.

Konklusjon

En tabell i den første normale formen må ikke bryte noen av følgende regler:

1) Alle kolonnene i en tabell skal ha unike toppnavn.

2) Hver celle må bare ha en enkelt verdi.

3) Verdiene som er lagret i en kolonne skal være av samme type.

4) Radene skal være forskjellige.

5) Rekkefølgen på kolonnene eller radene spiller ingen rolle.

Enhver tabell i enhver normal form skal ha en primærnøkkel.

Ideen om den funksjonelle avhengigheten eller bare avhengighet er at når den primære nøkkelen til en rad er kjent, kan enhver annen verdi i den raden hentes.

På dette tidspunktet kan du som databaseutvikler ta permisjon. Imidlertid vil du komme tilbake for å lære dem om den andre normale formen fordi en tabell i 1NF fremdeles kan ha noen sårbarheter.