Normalización en SQL: 1NF, 2NF, 3NF y BCNF

La normalización es un proceso sistemático para garantizar que un modelo de base de datos relacional sea eficiente, adecuado para consultas de propósito general y libre de características indeseables, como anomalías de inserción, actualización y eliminación, que conducen a la pérdida de la integridad de los datos. Este proceso de normalización también ayuda a eliminar la redundancia de datos y reduce las posibilidades de inconsistencia después de cualquier operación de inserción, actualización o eliminación.

Para una mejor comprensión, considere el siguiente esquema: Estudiante (Nombre, Dirección, Materia, Grado)

Hay algunos problemas o ineficiencias en este esquema.

1) Redundancia : La Dirección del estudiante se repite para cada materia en la que está matriculado.

2) Anomalía de actualización : es posible que hayamos actualizado la dirección en una tupla (fila) mientras la dejamos sin cambios en las otras filas. Por lo tanto, no tendríamos una dirección consistentemente única para cada estudiante.

3) Anomalía de Inserción : No registraremos la Dirección de un estudiante sin registrarse en al menos una Materia. De manera similar, cuando un estudiante quiere inscribirse en una nueva Materia, es posible que se inserte una Dirección diferente.

4) Anomalía de Eliminación : Si un estudiante decide descontinuar todas las materias matriculadas, entonces la dirección del estudiante también se perderá en el proceso de eliminación.

Por lo tanto, es importante representar los datos del usuario mediante relaciones que no creen anomalías después de las operaciones de agregar, eliminar o actualizar tuplas. Esto solo se puede lograr mediante un análisis cuidadoso de las restricciones de integridad, especialmente las dependencias de datos de la base de datos.

Las relaciones deben diseñarse de modo que solo se agrupen aquellos atributos que existen naturalmente juntos. Esto se puede hacer principalmente mediante una comprensión básica del significado de todos los atributos de datos. Sin embargo, todavía necesitamos alguna medida formal para garantizar nuestro objetivo de diseño.

La normalización es esa medida formal. Responde a la pregunta de por qué un grupo particular de atributos será mejor que cualquier otro.

Siete formas normales existen a partir de hoy:

• Primera forma normal (1NF)
• Segunda forma normal (2NF)
• Tercera Forma Normal (3NF)
• Forma normal de Boyce-Codd (BCNF)
• Cuarta Forma Normal (4NF)
• Quinta Forma Normal (5NF)
• Sexta forma normal o clave de dominio (6NF)

Leer: Tipos de Vistas en SQL

Primera forma normal (1NF o forma mínima)

• No hay un orden de arriba a abajo en las filas ni de izquierda a derecha en las columnas.
• No hay filas duplicadas.
• Cada intersección de fila y columna contiene exactamente un valor del dominio aplicable o valor nulo. Esta condición indica que todos los valores de columna deben ser atómicos, escalares o contener un solo valor. Aquí no se permite la repetición de información o valores en varias columnas.
• Todas las columnas son regulares (es decir, las filas no tienen componentes ocultos, como ID de fila, ID de objeto o marcas de tiempo ocultas).

Tomemos un ejemplo de un esquema que no está normalizado. Suponga que un diseñador desea registrar los nombres y números de teléfono de los clientes. Definen una tabla de clientes como se muestra:

Aquí, no está en 1NF. La columna de Números de Teléfono no es atómica o no tiene valor escalar, es decir ha tenido más de un valor, lo cual no se puede permitir en 1 NF.

Para hacerlo 1 NF

• Primero dividiremos (descompondremos) nuestra única tabla en dos.
• Cada tabla debe tener información sobre una sola entidad.

En este diseño no se repiten grupos de números de teléfono. En su lugar, cada enlace de Cliente a número de teléfono aparece en su propio registro.

Pago: Preguntas y respuestas más comunes de la entrevista de SQL

Segunda forma normal

Cada forma normal tiene más criterios restrictivos que su predecesora. Entonces, cualquier tabla que esté en la segunda forma normal (2FN) o superior está, por definición, también en 1FN. Por otro lado, una mesa que está en 1NF puede estar o no en 2NF; si está en 2FN, puede estar o no en 3FN, y así sucesivamente.

Se dice que una tabla 1NF está en 2NF si y solo si ninguno de sus atributos no primos depende funcionalmente de una parte (subconjunto adecuado) de una clave candidata. (Un atributo no principal no pertenece a ninguna clave candidata).

Tenga en cuenta que cuando una tabla 1NF no tiene claves candidatas compuestas (claves candidatas que constan de más de un atributo), la tabla está automáticamente en 2NF.

Compruebe si una relación R (A, B, C, D, E) con FD se establece como { BC ? D, CA? SER, B? E } está en 2NF?

• Como podemos ver, el cierre de AC es (AC)+ = {A, C, B, E, D} aplicando el algoritmo de pertenencia. Pero ninguno de sus subconjuntos puede determinar todos los atributos de la relación por sí mismos, por lo que AC es la clave candidata para esta relación. Además, ni A ni C pueden derivarse de ningún otro atributo de la relación, por lo que solo habrá 1 clave candidata que es {AC}.
• Aquí {A, C} son los atributos primos y {B, D, E} son los atributos no primos.
• La relación R ya está en la primera forma normal, ya que un DBMS relacional en 1NF no permite atributos multivaluados o compuestos.

ANTES DE CRISTO ? D está en la segunda forma normal porque BC no es un subconjunto propio de la clave candidata AC,

CA? BE está en la segunda forma normal ya que AC en sí es la clave candidata, y

B ? E está en la segunda forma normal B no es un subconjunto propio de la clave candidata AC.

Por lo tanto, la relación dada R está en la segunda forma normal.

Tercera forma normal

Se dice que una tabla está en 3NF si y solo si para cada una de sus dependencias funcionales.

X → A , se cumple al menos una de las siguientes condiciones:

• X contiene A (es decir, X → A es una dependencia funcional trivial), o
• X es una superclave, o
• A es un atributo principal (es decir, A está presente dentro de una clave candidata)

Otra definición de 3NF establece que cada atributo no clave de R depende de manera no transitiva (es decir, depende directamente) de la clave principal de R. Esto significa que ningún atributo no principal (que no forma parte de la clave candidata) depende funcionalmente de otros atributos no principales. Si hay dos dependencias tales que A ? B y BC, entonces a partir de estos FD, podemos derivar A ? C. Esta dependencia AC es transitiva.

Ejemplo de 3NF:

Considere la siguiente relación Pedido (Número de pedido, Pieza, Proveedor, Precio unitario, Cantidad ordenada) con el conjunto dado de FD:

Pedido# ? Pieza, Proveedor, Cantidad solicitada y Proveedor, Pieza ? Precio unitario)

Aquí Order# es clave para la relación.

Usando los axiomas de Amstrong, obtenemos

Pedido# ? Parte, Orden ? Proveedor y Orden ? Cantidad ordenada.

Pedido# ? Parte, Proveedor y Proveedor, Parte ? Precio unitario, ambos dan Order# ? Precio unitario.

Por lo tanto, vemos que todos los atributos no primos dependen de la clave (Order#). Sin embargo, existe una dependencia transitiva entre Order# y UnitPrice. Entonces esta relación no está en 3FN. ¿Cómo lo hacemos en 3NF?

No podemos almacenar el Precio por unidad de ninguna Parte suministrada por ningún Proveedor a menos que alguien haga un pedido de esa Parte. Así que tendremos que descomponer la tabla para que siga 3FN de la siguiente manera.

Pedido (n.° de pedido, pieza, proveedor, cantidad solicitada) y maestro de precios (pieza, proveedor, precio unitario).

Ahora no hay dependencias transitivas presentes. La relación está en 3NF.

Lea también: SQL para ciencia de datos

Aprenda cursos de software en línea de las mejores universidades del mundo. Obtenga programas Executive PG, programas de certificados avanzados o programas de maestría para acelerar su carrera.

Conclusión

Hay más en la normalización, como BCNF, 4NF, 5NF y 6NF. En resumen, BCNF no es más que una extensión de 3NF, ya que la última regla de 3NF no se aplica aquí. Todas las dependencias funcionales deben tener los atributos clave a la izquierda y ninguno a la derecha. (BCNF también se llama 3.5NF). Sin embargo, las formas normales de 4NF y más allá apenas se implementan en la práctica habitual.

Si está interesado en obtener más información sobre el desarrollo de pila completa, consulte el programa Executive PG de upGrad & IIIT-B en desarrollo de software de pila completa, que está diseñado para profesionales que trabajan y ofrece más de 500 horas de capacitación rigurosa, más de 9 proyectos, y asignaciones, estado de ex alumnos de IIIT-B, proyectos finales prácticos y asistencia laboral con las mejores empresas.