- Normale former
- Første normale form (1FN)
- Andre normal form (2FN)
- Tredje normalform (3FN)
- Eksempler på tredje normalform
- Eksempel 1
- Lag ny tabell
- Eksempel 2
- referanser
Den tredje normale formen (databaser) er en relasjonell databasedesignteknikk, der de forskjellige tabellene som komponerer den ikke bare samsvarer med den andre normale formen, men alle dens attributter eller felt avhenger direkte av den primære nøkkelen.
Når du designer en database, er hovedmålet å lage en nøyaktig representasjon av dataene, sammenhengene mellom dem og begrensningene for dataene som er relevante.
Kilde: pixabay.com
For å oppnå dette målet kan noen databaseteknikk-teknikker brukes, blant annet normalisering.
Dette er en prosess for å organisere dataene i en database for å unngå oppsigelser og mulige avvik ved innsetting, oppdatering eller eliminering av dataene, og genererer en enkel og stabil design av den konseptuelle modellen.
Det begynner med å undersøke det funksjonelle forholdet eller avhengigheten mellom attributtene. Disse beskriver noe av dataene eller forholdet mellom dem.
Normale former
Normalisering bruker en serie tester, kalt normale skjemaer, for å identifisere den optimale gruppering av disse attributtene og til slutt etablere et passende sett av relasjoner som støtter et selskaps datakrav.
Det vil si at normaliseringsteknikken er bygd rundt begrepet normalform, som definerer et system med begrensninger. Hvis et forhold oppfyller begrensningene for en bestemt normal form, sies forholdet å være i den normale formen.
Første normale form (1FN)
En tabell sies å være i 1FN hvis alle attributter eller felt i den bare inneholder unike verdier. Det vil si at hver verdi for hvert attributt må være udelelig.
Per definisjon vil en relasjonsdatabase alltid normaliseres til den første normale formen, fordi attributtverdiene alltid er atomiske. Alle relasjoner i en database er i 1FN.
Bare å forlate databasen som denne stimulerer imidlertid en rekke problemer, for eksempel redundans og mulige oppgraderingsfeil. Høyere normale former ble utviklet for å rette opp i disse problemene.
Andre normal form (2FN)
Den tar for seg å fjerne sirkulære avhengigheter fra et bord. Et forhold sies å være i 2FN hvis det er i 1FN og dessuten avhenger hvert felt eller attributt som ikke er nøkkel helt av den primære nøkkelen, eller mer spesifikt, det sikrer at tabellen har et enkelt formål.
Et ikke-nøkkelattributt er ethvert attributt som ikke er en del av den primære nøkkelen for et forhold.
Tredje normalform (3FN)
Den tar for seg å eliminere transitive avhengigheter fra en tabell. Det vil si fjerne de ikke-nøkkelattributtene som ikke er avhengig av primærnøkkelen, men på et annet attributt.
En transitiv avhengighet er en type funksjonell avhengighet der verdien til et felt eller attributt som ikke er nøkkel bestemmes av verdien til et annet felt som heller ikke er nøkkel.
Du må se etter gjentatte verdier i ikke-nøkkelattributter for å sikre at disse ikke-nøkkelattributtene ikke er avhengig av noe annet enn den primære nøkkelen.
Attributter sies å være gjensidig uavhengige hvis ingen av dem er funksjonelt avhengig av en kombinasjon av andre. Denne gjensidige uavhengigheten sikrer at attributter kan oppdateres individuelt uten fare for å påvirke en annen attributt.
For at et forhold i en database skal være i tredje normal form, må det derfor være i samsvar med:
- Alle kravene til 2FN.
- Hvis det er attributter som ikke er relatert til primærnøkkelen, må de fjernes og plasseres i en egen tabell, som angår begge tabellene ved hjelp av en fremmed nøkkel. Det vil si at det ikke skal være noen transitive avhengigheter.
Eksempler på tredje normalform
Eksempel 1
La tabellen være STUDENT, hvis primære nøkkel er studentens identifikasjon (STUDENT_ID) og er sammensatt av følgende attributter: STUDENT_NAME, STREET, CITY og POST_CODE, og oppfyller betingelsene for å være 2FN.
I dette tilfellet har STREET og CITY ikke et direkte forhold til den primære nøkkelen STUDENT_ID, siden de ikke er direkte relatert til studenten, men er helt avhengige av postnummeret.
Siden studenten befinner seg ved siden bestemt av CODE_POSTAL, er STREET og CITY relatert til dette attributtet. På grunn av denne andre grad av avhengighet, er det ikke nødvendig å lagre disse attributtene i STUDENT-tabellen.
Lag ny tabell
Anta at det er flere studenter som ligger i samme postnummer, med STUDENT-tabellen med en enorm mengde poster, og det kreves å endre navnet på gaten eller byen, så denne gaten eller byen må bli funnet og oppdatert i hele tabellen STUDENT.
For eksempel, hvis du trenger å endre gaten "El Limón" til "El Limón II", må du søke etter "El Limón" i hele STUDENT-tabellen og deretter oppdatere den til "El Limón II".
Det vil ta lang tid å søke i en enorm tabell og oppdatere enkelt- eller flere poster, og påvirke derfor databasens ytelse.
I stedet kan disse detaljene oppbevares i en egen tabell (POSTCARD) som er relatert til STUDENT-tabellen ved hjelp av POST_CODE-attributtet.
POST-tabellen vil ha relativt færre poster, og denne POST-tabellen trenger bare å oppdateres en gang. Dette reflekteres automatisk i STUDENT-tabellen, og forenkler databasen og spørringene. Så tabellene vil være i 3FN:
Eksempel 2
La følgende tabell brukes med Project_Num-feltet som primærnøkkel og med gjentatte verdier i attributter som ikke er nøkler.
Telefonverdien gjentas hver gang navnet på en leder gjentas. Dette er fordi telefonnummeret bare har en annen graders avhengighet av prosjektnummeret. Det avhenger virkelig av lederen først, og dette avhenger igjen av prosjektnummeret, noe som gjør en transitiv avhengighet.
Project_Manager-attributtet kan ikke være en mulig nøkkel i Prosjekttabellen fordi den samme lederen administrerer mer enn ett prosjekt. Løsningen for dette er å fjerne attributtet med de gjentatte dataene (Telefon), lage en egen tabell.
De tilsvarende attributtene må grupperes sammen, og opprette en ny tabell for å lagre dem. Dataene legges inn, og det blir bekreftet at de gjentatte verdiene ikke er en del av den primære nøkkelen. Primærnøkkelen er satt for hver tabell, og om nødvendig blir utenlandske nøkler lagt til.
For å overholde den tredje normalformen opprettes en ny tabell (Managers) for å løse problemet. Begge tabellene er relatert gjennom Project_Manager-feltet:
referanser
- Teradata (2019). Første, andre og tredje normalskjema. Hentet fra: docs.teradata.com.
- Tutorial Cup (2019). Tredje normal form (3NF). Hentet fra: tutorialcup.com.
- Database Dev (2015). Third Normal Form (3NF) - Normalisering av databasen din. Hentet fra: databasedev.co.uk.
- Relational DB Design (2019). Introduksjon til tredje normalform. Hentet fra: relationaldbdesign.com.
- Dummies (2019). SQL første, andre og tredje normalskjema. Hentet fra: dummies.com.