QUÈ ÉS LA TERCERA FORMA NORMAL? (BASES DE DADES) - TECNOLOGIA - 2026

La tercera forma normal (bases de dades) és una tècnica de disseny de base de dades relacional, on les diferents taules que la componen no només compleixen amb la segona forma normal, sinó que tots els seus atributs o camps depenen directament de la clau principal.

Quan es dissenya una base de dades, l'objectiu principal és crear una representació precisa de les dades, de les relacions existents entre ells i de les restriccions en les dades que siguin pertinents.

Font: pixabay.com

Per aconseguir aquest objectiu, es poden fer servir algunes tècniques de disseny de base de dades, entre les quals es troba la normalització.

Aquesta és un procés d'organització de les dades en una base de dades per evitar redundàncies i possibles anomalies en la inserció, actualització o eliminació de les dades, generant per a això un disseny simple i estable de el model conceptual.

Comença examinant la relació o dependència funcional entre els atributs. Aquests descriuen alguna propietat de les dades o de la relació entre ells.

formes normals

La normalització utilitza una sèrie de proves, anomenades formes normals, per ajudar a identificar l'agrupació òptima d'aquests atributs i finalment establir el conjunt de relacions adequades que donin suport als requeriments de dades d'una empresa

És a dir, la tècnica de normalització es construeix al voltant del concepte de forma normal, que defineix un sistema de restriccions. Si una relació compleix amb les restriccions d'una forma normal en particular, es diu que la relació està en aquesta forma normal.

Primera forma normal (1FN)

Es diu que una taula està en 1FN si tots els atributs o camps dins de la mateixa només contenen valors únics. És a dir, tot valor per a cada atribut ha de ser indivisible.

Per definició, una base de dades relacional sempre estarà normalitzada a la primera forma normal, perquè els valors dels atributs són sempre atòmics. Totes les relacions en una base de dades estan en 1FN.

No obstant això, deixar la base de dades simplement així estimula una sèrie de problemes, com ara redundància i possibles anomalies d'actualització. Les formes normals més altes van ser desenvolupades per corregir aquests problemes.

Segona forma normal (2FN)

S'ocupa d'eliminar d'una taula les dependències circulars. Es diu que una relació està en 2FN si està en 1FN i més cada camp o atribut no clau depèn completament de la clau primària, o més específicament, s'assegura que la taula tingui un únic propòsit.

Un atribut no clau és qualsevol atribut que no formi part de la clau primària per a una relació.

Tercera forma normal (3FN)

S'ocupa d'eliminar d'una taula les dependències transitives. És a dir, eliminar els atributs no claus que no depenen de la clau primària, sinó d'un altre atribut.

Una dependència transitiva és un tipus de dependència funcional en la qual el valor d'un atribut o camp no clau ve determinat pel valor d'un altre camp que tampoc és clau.

S'han de buscar els valors repetits en els atributs no claus per assegurar que aquests atributs que no són clau no depenguin sinó res més que de la clau primària.

Es diu que els atributs són mútuament independents si cap d'ells depèn funcionalment d'una combinació d'altres. Aquesta independència mútua garanteix que es puguin actualitzar els atributs individualment, sense perill d'afectar a un altre atribut.

Per tant, perquè una relació d'una base de dades estigui en tercera forma normal ha de complir amb:

- Tots els requeriments de 2FN.

- Si hi ha atributs que no tenen relació amb la clau primària, cal eliminar-los i col·locar-los en una taula separada, relacionant les dues taules per mitjà d'una clau externa. És a dir, no hauria d'haver cap dependència transitiva.

Exemples de tercera forma normal

exemple 1

Sigui la taula ESTUDIANT, la clau primària és la identificació de l'estudiant (ID_ESTUDIANTE) i està composta pels següents atributs: NOMBRE_ESTUDIANTE, CARRER, CIUTAT i CODIGO_POSTAL, complint les condicions per a ser 2FN.

En aquest cas, CARRER i CIUTAT no tenen una relació directa amb la clau primària ID_ESTUDIANTE, ja que no estan directament relacionats amb l'estudiant, sinó que depenen totalment de el codi postal.

Com l'estudiant se situa pel lloc determinat per CODIGO_POSTAL, CARRER i CIUTAT es relacionen és amb aquest atribut. A causa d'aquest segon grau de dependència, no cal emmagatzemar aquests atributs en la taula ESTUDIANT.

Crear una taula

Suposem que hi ha múltiples estudiants situats en un mateix codi postal, amb la taula ESTUDIANT tenint una immensa quantitat de registres, i es requereix canviar el nom del carrer o la ciutat, llavors s'haurà de buscar i actualitzar aquest carrer o ciutat en tota la taula ESTUDIANT.

Per exemple, si es requereix canviar el carrer "La Llimona" per "La Llimona II", s'haurà de buscar "La Llimona" en tota la taula ESTUDIANT i després actualitzar-la a "La Llimona II".

Cercar en una taula enorme i actualitzar els registres únics o múltiples requerirà molt de temps i, per tant, afectarà el rendiment de la base de dades.

En el seu lloc, aquests detalls es poden tenir en una taula separada (POSTAL) que estigui relacionada amb la taula ESTUDIANT usant l'atribut CODIGO_POSTAL.

La taula POSTAL tindrà una quantitat comparativament menor de registres i només s'haurà d'actualitzar un cop aquesta taula POSTAL. Això es reflectirà automàticament a la taula ESTUDIANT, simplificant la base de dades i les consultes. Així les taules estaran en 3FN:

exemple 2

Sigui la següent taula amb el camp Num_Proyecto com a clau principal i amb valors repetits en atributs que no són claus.

El valor de Telèfon es repeteix cada vegada que es repeteix el nom d'un gerent. Això és perquè el número de telèfon només té una dependència de segon grau amb el número de projecte. Realment primer depèn de l'gerent, i aquest al seu torn depèn de el nombre de projecte, la qual cosa fa una dependència transitiva.

L'atribut Gerente_Proyecto no pot ser una possible clau en la taula Projectes perquè un mateix gerent maneja més d'un projecte. La solució per a això és eliminar l'atribut amb les dades repetits (Telèfon), creant una taula separada.

S'han d'agrupar els atributs que corresponguin, creant una nova taula per guardar-los. Les dades s'ingressen i es verifica que els valors que es repeteixin no formin part de la clau primària. S'estableix la clau primària per a cada taula i, si cal, s'agreguen claus externes.

Per complir amb la tercera forma normal es crea una nova taula (Gerents) per així solucionar el problema. Les dues taules es relacionen a través de el camp Gerente_Proyecto:

referències

1. Teradata (2019). First, Second, and Third Normal Forms. Pres de: docs.teradata.com.
2. Tutorial Cup (2019). Third Normal Form (3NF). Pres de: tutorialcup.com.
3. Database Dev (2015). Third Normal Form (3NF) - Normalising Your Database. Pres de: databasedev.co.uk.
4. Relational DB Design (2019). Introduction to Third Normal Form. Pres de: relationaldbdesign.com.
5. Dummies (2019). SQL First, Second and Third Normal Forms. Pres de: dummies.com.