Hva er den tredje normale formen? (Databaser)

De Tredje normal form (databaser) Det er en relasjonell databasedesignteknikk, der de forskjellige tabellene som komponerer den ikke bare oppfyller den andre normale skjemaet, men alle attributtene eller feltene deres er direkte avhengig av hovednøkkelen.

Når en database er designet, er hovedmålet å lage en presis representasjon av dataene, av sammenhengene mellom dem og begrensningene for dataene som er relevante.

Kilde: Pixabay.com

For å oppnå dette målet, kan noen databasedesignteknikker brukes, blant dem er standardiseringen.

Dette er en prosess med å organisere data i en database for å unngå oppsigelser og mulige anomalier i innsetting, oppdatering eller avhending av dataene, og genererer for det en enkel og stabil design av den konseptuelle modellen.

Begynner med å undersøke det funksjonelle forholdet eller avhengigheten mellom attributter. Disse beskriver en viss egenskap av dataene eller forholdet mellom dem.

[TOC]

Normale former

Standardisering bruker en serie tester, kalt normale former, for å identifisere den optimale gruppering av disse attributtene og til slutt etablere settet med tilstrekkelige forhold som støtter datakravene til et selskap

Det vil si at normaliseringsteknikken er konstruert rundt begrepet normal måte, som definerer et system med begrensninger. Hvis et forhold oppfyller begrensningene på en bestemt normal måte, sies det at forholdet er på den normale måten.

Første normale form (1FN)

Det sies at en tabell er i 1FN hvis alle attributter eller felt i den bare inneholder unike verdier. Det vil si at all verdi for hvert attributt må være udelelig.

Per definisjon vil en relasjonsdatabase alltid normaliseres til den første normale formen, fordi attributterverdier alltid er atom. Alle forhold i en database er i 1FN.

Kan tjene deg: konstant (programmering): konsept, typer, eksempler

Å forlate databasen stimulerer ganske enkelt en serie problemer, for eksempel redundans og mulige oppdatering av anomalier. De høyeste normale formene ble utviklet for å rette opp disse problemene.

Second Normal Form (2FN)

Den omhandler eliminering fra en tabell de sirkulære enhetene. Det sies at et forhold er i 2FN hvis det er i 1FN, og også hvert felt eller attributt ikke er helt avhengig av den primære nøkkelen, eller mer spesifikt, er det sikret at tabellen har et enkelt formål.

Et attributt som ikke er nøkkel, er noen attributt som ikke er en del av den primære nøkkelen for et forhold.

Tredje normal form (3FN)

Den handler fra å eliminere transitive avhengigheter fra et bord. Det vil si eliminere ikke -nøkkelattributter som ikke er avhengig av den primære nøkkelen, men av et annet attributt.

En transitiv avhengighet er en type funksjonell avhengighet der verdien av et attributt eller felt ikke bestemmes av verdien av et annet felt som ikke er nøkkelen heller.

Gjentatte verdier bør søkes i ikke -nøkkelattributtene for å sikre at disse attributtene som ikke er nøkkelen, ikke bare avhenger av den primære nøkkelen.

Det sies at attributter er gjensidig uavhengige hvis ingen av dem funksjonelt er avhengige av en kombinasjon av andre. Denne gjensidige uavhengigheten garanterer at attributter kan oppdateres individuelt, uten fare for å påvirke et annet attributt.

Derfor, for at et databaseforhold skal være i tredje normal form, må det være i samsvar med:

- Alle 2FN -krav.

Kan tjene deg: IKT i huset

- Hvis det er attributter som ikke er relatert til den primære nøkkelen, må de elimineres og plasseres i en egen tabell, relatere begge tabellene gjennom en ekstern nøkkel. Det vil si at det ikke skal være noen transitive avhengighet.

Eksempler på tredje normal form

Eksempel 1

Vær studentbordet, hvis primære nøkkel er identifisering av studenten (id_estudiant) og er sammensatt av følgende attributter: studentnavn, gate, by og_postalkode, og oppfyller betingelsene for å være 2FN.

I dette tilfellet har gate og by ikke et direkte forhold til den primære identitetsnøkkelen, siden de ikke er direkte relatert til studenten, men de er helt avhengige av postnummeret.

Ettersom studenten er lokalisert av nettstedet bestemt av Code_Postal, er gaten og byen relatert til dette attributtet. På grunn av denne andre grad av avhengighet er det ikke nødvendig å lagre disse attributtene i studentbordet.

Lag ny tabell

Anta at det er flere studenter som er lokalisert i samme postnummer, med studentbordet som har en enorm mengde poster, og det er nødvendig å endre navnet på gaten eller byen, så bør denne gaten eller byen søkes og oppdateres gjennom hele Tabellstudent.

For eksempel, hvis det er nødvendig å endre "El Limón" -gaten for "El Limón II", vil den måtte se etter "El Limón" gjennom studentbordet og deretter oppdatere den til “El Limón II”.

Finn i et stort bord og oppdater de unike eller flere postene vil kreve mye tid, og vil derfor påvirke databaseytelsen.

I stedet kan disse detaljene få i et eget (postkort) tabell som er relatert til studenttabellen ved hjelp av Code_Postal -attributtet.

Postbordet vil ha en relativt mindre mengde poster og trenger bare å oppdatere når dette posttabellen. Dette vil automatisk gjenspeiles i studentbordet, og forenkle databasene og konsultasjonene. Dermed vil bordene være i 3FN:

Det kan tjene deg: Metabustere: Karakteristikker, typer og eksempler

Eksempel 2

Vær følgende tabell med NUM_PROJECT -feltet som hovednøkkel og med gjentatte verdier i attributter som ikke er nøkkelen.

Telefonverdien gjentas hver gang navnet på en leder gjentas. Dette er fordi telefonnummeret bare har en annen gradsavhengighet med prosjektnummeret. Det avhenger virkelig av manageren, og dette avhenger igjen av prosjektnummeret, noe som gjør en transitiv avhengighet.

Manager_project -attributtet kan ikke være en mulig nøkkel i tabellprosjektene fordi den samme lederen håndterer mer enn ett prosjekt. Løsningen for dette er å eliminere attributtet med gjentatte data (telefon), og lage en egen tabell.

De tilsvarende attributtene må grupperes, og lage en ny tabell for å redde dem. Dataene legges inn og det er bekreftet at verdiene som gjentas ikke er en del av den primære nøkkelen. Den primære nøkkelen for hver tabell er etablert, og om nødvendig blir eksterne nøkler lagt til.

For å møte den tredje normale skjemaet opprettes en ny tabell (ledere) for å løse problemet. Begge tabellene er relatert gjennom feltet Manager_Project:

Referanser

1. Teradata (2019). Første, andre og tredje normale former. Hentet fra: dokumenter.Teradata.com.
2. Cup Tutorial (2019). Normal tredje form (3NF). Hentet fra: tutorialcup.com.
3. Database Dev (2015). Normal tredje form (3NF) - Normaliserer databasen din. Hentet fra: Databasedev.co.Storbritannia.
4. Relational DB Design (2019). Introduksjon til tredje normal form. Hentet fra: relationDbdesign.com.
5. Dummies (2019). SQL Første, andre og tredje normale former. Hentet fra: dummies.com.