HVAD ER DEN TREDJE NORMALE FORM? (DATABASER) - TEKNOLOGI

Den tredje normale form (databaser) er en relationel databasedesignteknik, hvor de forskellige tabeller, der sammensætter den, ikke kun overholder den anden normale form, men alle deres attributter eller felter afhænger direkte af den primære nøgle.

Når man designer en database, er hovedmålet at skabe en nøjagtig repræsentation af dataene, forholdet mellem dem og begrænsningerne for de data, der er relevante.

Kilde: pixabay.com

For at nå dette mål kan nogle databasedesignteknikker bruges, herunder normalisering.

Dette er en proces til organisering af dataene i en database for at undgå afskedigelser og mulige afvigelser ved indsættelse, opdatering eller eliminering af dataene, hvilket genererer et enkelt og stabilt design af den konceptuelle model.

Det begynder med at undersøge det funktionelle forhold eller afhængighed mellem attributter. Disse beskriver nogle egenskaber ved dataene eller forholdet mellem dem.

Normale former

Normalisering bruger en række test, kaldet normale formularer, til at identificere den optimale gruppering af disse attributter og i sidste ende etablere det passende sæt af relationer, der understøtter en virksomheds datakrav.

Det vil sige, at normaliseringsteknikken er bygget op omkring begrebet normal form, som definerer et system med begrænsninger. Hvis et forhold opfylder begrænsningerne for en bestemt normal form, siges forholdet at være i den normale form.

Første normal form (1FN)

En tabel siges at være i 1FN, hvis alle attributter eller felter i den kun indeholder unikke værdier. Det vil sige, at hver værdi for hver attribut skal være udelelig.

Per definition normaliseres en relationsdatabase til den første normale form, fordi attributværdier altid er atomare. Alle relationer i en database er i 1FN.

Imidlertid simpelthen at forlade databasen som denne stimulerer en række problemer, såsom redundans og mulige opgraderingsfejl. Højere normale former blev udviklet for at rette op på disse problemer.

Anden normal form (2FN)

Den omhandler fjernelse af cirkulære afhængigheder fra en tabel. Et forhold siges at være i 2FN, hvis det er i 1FN, og derudover afhænger hvert felt eller attribut, der ikke er nøgle, helt af den primære nøgle, eller mere specifikt, det sikrer, at tabellen har et enkelt formål.

En ikke-nøgleattribut er enhver attribut, der ikke er en del af den primære nøgle til et forhold.

Tredje normal form (3FN)

Den omhandler eliminering af transitive afhængigheder fra en tabel. Det vil sige fjerne de ikke-nøgleattributter, der ikke afhænger af den primære nøgle, men af en anden attribut.

En transitiv afhængighed er en type funktionel afhængighed, hvor værdien af et ikke-nøglefelt eller attribut bestemmes af værdien af et andet felt, der heller ikke er nøglen.

Du skal kigge efter gentagne værdier i ikke-nøgleattributter for at sikre, at disse ikke-nøgleattributter ikke afhænger af andet end den primære nøgle.

Attributter siges at være gensidigt uafhængige, hvis ingen af dem er funktionelt afhængige af en kombination af andre. Denne gensidige uafhængighed sikrer, at attributter kan opdateres individuelt uden fare for at påvirke en anden attribut.

For at et forhold i en database skal være i tredje normal form, skal det derfor overholde:

- Alle kravene i 2FN.

- Hvis der er attributter, der ikke er relateret til den primære nøgle, skal de fjernes og placeres i en separat tabel, der vedrører begge tabeller ved hjælp af en fremmed nøgle. Det vil sige, der skal ikke være nogen transitive afhængigheder.

Eksempler på tredje normal form

Eksempel 1

Lad tabellen være STUDENT, hvis primære nøgle er den studerendes identifikation (STUDENT_ID) og består af følgende attributter: STUDENT_NAME, STREET, CITY og POST_CODE, der opfylder betingelserne for at være 2FN.

I dette tilfælde har STREET og CITY ikke et direkte forhold til den primære nøgle STUDENT_ID, da de ikke er direkte relateret til den studerende, men er helt afhængige af postnummeret.

Da den studerende er placeret ved det sted, der er bestemt af CODE_POSTAL, er STREET og CITY relateret til denne attribut. På grund af denne anden grad af afhængighed er det ikke nødvendigt at gemme disse attributter i STUDENT-tabellen.

Opret en ny tabel

Antag, at der er flere studerende i samme postnummer, hvor STUDENT-tabellen har en enorm mængde poster, og det er påkrævet at ændre navnet på gaden eller byen, så denne gade eller by skal søges og opdateres i hele tabellen STUDERENDE.

For eksempel, hvis du har brug for at ændre gaden "El Limón" til "El Limón II", bliver du nødt til at søge efter "El Limón" i hele STUDENT-tabellen og derefter opdatere den til "El Limón II".

Søgning i en enorm tabel og opdatering af de enkelte eller flere poster vil tage lang tid og påvirker derfor databasens ydelse.

I stedet kan disse detaljer opbevares i en separat tabel (POSTCARD), der er relateret til STUDENT-tabellen ved hjælp af attributten POST_CODE.

POST-tabellen vil have relativt færre poster, og denne POST-tabel skal kun opdateres én gang. Dette reflekteres automatisk i STUDENT-tabellen, hvilket forenkler databasen og forespørgsler. Så tabellerne vil være i 3FN:

Eksempel 2

Lad følgende tabel bruges med Project_Num-feltet som den primære nøgle og med gentagne værdier i attributter, der ikke er nøgler.

Telefonværdien gentages, hver gang en manager navn gentages. Dette skyldes, at telefonnummeret kun har en anden grad afhængighed af projektnummeret. Det afhænger virkelig af manager først, og dette afhænger igen af projektnummeret, hvilket skaber en transitiv afhængighed.

Attributten Project_Manager kan ikke være en mulig nøgle i projekttabellen, fordi den samme manager administrerer mere end et projekt. Løsningen til dette er at fjerne attributten med de gentagne data (Telefon) ved at oprette en separat tabel.

De tilsvarende attributter skal grupperes sammen, så der oprettes en ny tabel for at gemme dem. Data indtastes, og det verificeres, at de gentagne værdier ikke er en del af den primære nøgle. Den primære nøgle indstilles for hver tabel, og om nødvendigt tilføjes udenlandske nøgler.

For at overholde den tredje normale form oprettes en ny tabel (Managers) for at løse problemet. Begge tabeller er relateret gennem feltet Project_Manager:

Referencer

Teradata (2019). Første, anden og tredje normale formularer. Taget fra: docs.teradata.com.
Tutorial Cup (2019). Tredje normal form (3NF). Taget fra: tutorialcup.com.
Database Dev (2015). Tredje normal form (3NF) - Normalisering af din database. Hentet fra: databasedev.co.uk.
Relational DB Design (2019). Introduktion til tredje normal form. Taget fra: relationaldbdesign.com.
Dummies (2019). SQL første, anden og tredje normale formularer. Taget fra: dummies.com.

HVAD ER DEN TREDJE NORMALE FORM? (DATABASER) - TEKNOLOGI - 2025