¿Qué es la tercera forma normal? (Bases de datos)
La tercera forma normal (bases de datos) es una técnica de diseño de base de datos relacional, donde las diferentes tablas que la componen no solo cumplen con la segunda forma normal, sino que todos sus atributos o campos dependen directamente de la clave principal.
Cuando se diseña una base de datos, el objetivo principal es crear una representación precisa de los datos, de las relaciones existentes entre ellos y de las restricciones en los datos que sean pertinentes.
Para lograr este objetivo, se pueden usar algunas técnicas de diseño de base de datos, entre las cuales se encuentra la normalización.
Esta es un proceso de organización de los datos en una base de datos para evitar redundancias y posibles anomalías en la inserción, actualización o eliminación de los datos, generando para ello un diseño simple y estable del modelo conceptual.
Comienza examinando la relación o dependencia funcional entre los atributos. Estos describen alguna propiedad de los datos o de la relación entre ellos.
Índice del artículo
La normalización utiliza una serie de pruebas, llamadas formas normales, para ayudar a identificar la agrupación óptima de estos atributos y finalmente establecer el conjunto de relaciones adecuadas que respalden los requerimientos de datos de una empresa
Es decir, la técnica de normalización se construye alrededor del concepto de forma normal, que define un sistema de restricciones. Si una relación cumple con las restricciones de una forma normal en particular, se dice que la relación está en esa forma normal.
Se dice que una tabla está en 1FN si todos los atributos o campos dentro de la misma solo contienen valores únicos. Es decir, todo valor para cada atributo debe ser indivisible.
Por definición, una base de datos relacional siempre estará normalizada a la primera forma normal, porque los valores de los atributos son siempre atómicos. Todas las relaciones en una base de datos están en 1FN.
Sin embargo, dejar la base de datos simplemente así estimula una serie de problemas, tales como redundancia y posibles anomalías de actualización. Las formas normales más altas fueron desarrolladas para corregir estos problemas.
Se ocupa de eliminar de una tabla las dependencias circulares. Se dice que una relación está en 2FN si está en 1FN y además cada campo o atributo no clave depende completamente de la clave primaria, o más específicamente, se asegura que la tabla tenga un único propósito.
Un atributo no clave es cualquier atributo que no forme parte de la clave primaria para una relación.
Se ocupa de eliminar de una tabla las dependencias transitivas. Es decir, eliminar los atributos no claves que no dependen de la clave primaria, sino de otro atributo.
Una dependencia transitiva es un tipo de dependencia funcional en la que el valor de un atributo o campo no clave viene determinado por el valor de otro campo que tampoco es clave.
Se deben buscar los valores repetidos en los atributos no claves para asegurar que estos atributos que no son clave no dependan sino nada más que de la clave primaria.
Se dice que los atributos son mutuamente independientes si ninguno de ellos depende funcionalmente de una combinación de otros. Esta independencia mutua garantiza que se puedan actualizar los atributos individualmente, sin peligro de afectar a otro atributo.
Por tanto, para que una relación de una base de datos esté en tercera forma normal debe cumplir con:
– Todos los requerimientos de 2FN.
– Si hay atributos que no tienen relación con la clave primaria, hay que eliminarlos y colocarlos en una tabla separada, relacionando ambas tablas por medio de una clave externa. Es decir, no debería haber ninguna dependencia transitiva.
Sea la tabla ESTUDIANTE, cuya clave primaria es la identificación del estudiante (ID_ESTUDIANTE) y está compuesta por los siguientes atributos: NOMBRE_ESTUDIANTE, CALLE, CIUDAD y CODIGO_POSTAL, cumpliendo las condiciones para ser 2FN.
En este caso, CALLE y CIUDAD no tienen una relación directa con la clave primaria ID_ESTUDIANTE, ya que no están directamente relacionados con el estudiante, sino que dependen totalmente del código postal.
Como el estudiante se ubica por el sitio determinado por CODIGO_POSTAL, CALLE y CIUDAD se relacionan es con este atributo. Debido a este segundo grado de dependencia, no es necesario almacenar estos atributos en la tabla ESTUDIANTE.
Crear nueva tabla
Supongamos que hay múltiples estudiantes ubicados en un mismo código postal, con la tabla ESTUDIANTE teniendo una inmensa cantidad de registros, y se requiere cambiar el nombre de la calle o la ciudad, entonces se deberá buscar y actualizar esta calle o ciudad en toda la tabla ESTUDIANTE.
Por ejemplo, si se requiere cambiar la calle “El Limón” por “El Limón II”, se tendrá que buscar “El Limón” en toda la tabla ESTUDIANTE y luego actualizarla a “El Limón II”.
Buscar en una tabla enorme y actualizar los registros únicos o múltiples requerirá mucho tiempo y, por tanto, afectará el rendimiento de la base de datos.
En su lugar, estos detalles se pueden tener en una tabla separada (POSTAL) que esté relacionada con la tabla ESTUDIANTE usando el atributo CODIGO_POSTAL.
La tabla POSTAL tendrá una cantidad comparativamente menor de registros y solo se tendrá que actualizar una vez esta tabla POSTAL. Esto se reflejará automáticamente en la tabla ESTUDIANTE, simplificando la base de datos y las consultas. Así las tablas estarán en 3FN:
Sea la siguiente tabla con el campo Num_Proyecto como clave principal y con valores repetidos en atributos que no son claves.
El valor de Teléfono se repite cada vez que se repite el nombre de un gerente. Esto es porque el número de teléfono solo tiene una dependencia de segundo grado con el número de proyecto. Realmente primero depende del gerente, y este a su vez depende del número de proyecto, lo cual hace una dependencia transitiva.
El atributo Gerente_Proyecto no puede ser una posible clave en la tabla Proyectos porque un mismo gerente maneja más de un proyecto. La solución para esto es eliminar el atributo con los datos repetidos (Teléfono), creando una tabla separada.
Se deben agrupar los atributos que correspondan, creando una nueva tabla para guardarlos. Los datos se ingresan y se verifica que los valores que se repitan no formen parte de la clave primaria. Se establece la clave primaria para cada tabla y, si es necesario, se agregan claves externas.
Para cumplir con la tercera forma normal se crea una nueva tabla (Gerentes) para así solucionar el problema. Ambas tablas se relacionan a través del campo Gerente_Proyecto:
- Teradata (2019). First, Second, and Third Normal Forms. Tomado de: docs.teradata.com.
- Tutorial Cup (2019). Third Normal Form (3NF). Tomado de: tutorialcup.com.
- Database Dev (2015). Third Normal Form (3NF) – Normalising Your Database. Tomado de: databasedev.co.uk.
- Relational DB Design (2019). Introduction to Third Normal Form. Tomado de: relationaldbdesign.com.
- Dummies (2019). SQL First, Second and Third Normal Forms. Tomado de: dummies.com.