La primera forma normal (1NF) — Diseño de bases de datos

• Forma normal
• Primera forma normal
  • Cada celda es un valor
  • Datos de un tipo
  • Registros únicos
• Conclusiones

Para facilitar la legibilidad de la información en la tabla, los programadores llevan los datos que se presentan en el modelo relacional a una forma normal. En esta lección, aprenderemos qué es esta forma, y también desglosaremos su primer nivel.

Forma normal

Tomemos como ejemplo una tienda en línea que vende electrónicos. Cuando un usuario hace un pedido, se introduce un registro en la base de datos al respecto. Incluye toda la información necesaria: datos del usuario, qué producto compró, cuánto costó y la dirección de entrega. Luego, estos datos son utilizados por todos los departamentos de la tienda en línea, desde los contadores hasta el servicio de entrega.

Tabla order_items (artículos del pedido)

Ver en DBFiddle

En la primera línea de la última columna, el precio está en dólares, en los demás registros, estos son COP. El último registro repite el anterior porque fue realizado por la misma persona, pero en un momento diferente.

Esta tabla tiene mucha información repetida. Vamos a darle la estructura correcta desde el punto de vista del modelo relacional. Para hacer esto, llevaremos los datos a la forma normal. Estos requisitos minimizan la redundancia de datos, lo que reduce la posibilidad de errores lógicos.

Hay seis formas normales en total, las cuales incluyen ciertos requisitos. Con cada nivel siguiente, los requisitos se hacen más estrictos, ya que incluyen niveles anteriores.

En el marco del curso de Códica, abordaremos tres formas normales. En esta lección, nos familiarizaremos con la primera.

Primera forma normal

La primera forma normal se puede condensar en tres reglas:

• Cada celda de la tabla puede almacenar solo un valor.
• Todos los datos en una columna solo pueden ser de un tipo.
• Cada registro en la tabla debe distinguirse de forma única de los demás.

Analicemos cada regla en detalle.

Cada celda es un valor

Volviendo al ejemplo de arriba. En un registro los campos item y price contienen dos valores separados por comas. Esta manera de organizar los datos tiene muchas desventajas. Por ejemplo, pierdes la capacidad de hacer una selección común basada en condiciones:

-- ¿Cómo encontrar registros de todas las planchas vendidas?
SELECT * FROM order_items WHERE item = "?";

Otro problema está relacionado con los tipos de datos. El campo price en la tabla order_items tiene un tipo numérico (numeric). Si queremos almacenar más de un valor aquí, el tipo se convertirá en una cadena, y todos los datos se convertirán en cadenas regulares.

Con esta organización, es imposible verificar la corrección de los datos y el formato del número. Se vuelve problemático realizar consultas de agregación, por ejemplo, calcular los ingresos de un mes determinado en una sola consulta.

Para deshacernos de las enumeraciones en las celdas, podemos crear nuevos registros:

Ahora en una línea se encuentra información solo de un artículo. Así eliminamos las enumeraciones en el campo, permitiendo realizar consultas de agregación sin confusiones con tipos de datos.

Datos de un tipo

Una vez más, volvamos a la tabla. El primer registro en ella contiene el precio en dólares, aunque todos los demás precios están en COP. Técnicamente, la base no indicará esto. Tanto el dólar como el COP están representados por números, pero desde el punto de vista de la programación, estos números son de naturaleza diferente.

Diferentes datos dentro de un solo campo tampoco permiten realizar consultas de agregación, por ejemplo, buscar sumas, máximo, mínimo. Esto complica aún más el procesamiento de datos a nivel de código. En el código, tendrás que entender de alguna manera qué son los datos.

Aquí hay varios ejemplos más de una situación similar:

• Almacenar la fecha de la boda en el campo "cumpleaños".
• Almacenar el número de teléfono en lugar del dirección en el campo "dirección".

Versión corregida de la tabla:

Hemos convertido el precio de la plancha en la primera línea de dólares a COP. Ahora, los datos en el campo price son del mismo tipo. Así, la programación facilita la realización de consultas de agregación.

Registros únicos

Los dos últimos registros en la tabla se ven idénticos aunque son dos pedidos diferentes. Fueron realizados por la misma persona, pero en diferentes momentos:

El modelo relacional nos exige la unicidad de cada registro. De lo contrario, no se puede entender qué pertenece a qué y con qué registro es necesario trabajar al hacer cambios. Podríamos empezar a arreglar algo incorrecto y perder información importante. No podemos confiar en el orden de los datos dentro de la tabla, ya que no está garantizado.

Hay varias maneras para llevar a cabo la unicidad de la información, por ejemplo, agregar un nuevo campo con la fecha del pedido, lo cual hará que el registro sea único. Este método no es muy confiable ni muy conveniente para trabajar. Siempre tendrás que analizar todo el conjunto de campos.

Es mejor agregar una clave primaria (PRIMARY KEY), que es un campo o un conjunto de campos con valores únicos para cada registro. La clave primaria debe ser inmutable, y su valor permite identificar de manera única cada registro en la tabla.

Profundicemos en dos tipos de llave primaria:

🔑 Natural (Natural) es cuando se usan valores del entorno, por ejemplo, email, nombre completo o datos del pasaporte. Debes asegurarte de que la llave no se repita. Estos tipos de claves primarias se usan raramente debido a su falta de confiabilidad. A menudo no son únicas y pueden cambiar o repetirse. Por ejemplo, el número de pasaporte cambia cuando se renueva el documento.

🔑 Sustituta (Surrogate) es cuando se utilizan valores generados automáticamente y son únicos. Este tipo de llave es soportado por cualquier base de datos lista para usar. A veces son simplemente números y otras se pueden convertir en cadenas complejas numéricas y alfabéticas o hashes.

Añadamos una llave primaria a nuestra tabla:

Es costumbre poner la llave primaria al inicio con el nombre id. Para la llave primaria necesitas especificar PRIMARY KEY en la descripción de la tabla:

-- La llave primaria es única por tabla
CREATE TABLE products (
    id bigint PRIMARY KEY,
    first_name varchar(255),
    last_name varchar(255),
    address varchar(255),
    item varchar(255),
    price numeric -- tipo de dato especial adecuado para trabajar con dinero, 
    -- proporciona alta precisión en los cálculos
);

Ver en DBFiddle

Todavía necesitas generar manualmente este tipo de llave pero ahora la base de datos te ayuda a mantener su unicidad por sí misma. Al intentar crear un registro con una llave primaria repetida, se producirá un error.

Conclusiones

En esta lección, aprendimos qué es la forma normal en el modelo relacional. Esta ayuda a facilitar la legibilidad de la información en la tabla. También examinamos detenidamente el primer nivel de la forma. Así aprendimos que cada celda de la tabla solo puede almacenar un valor. De lo contrario, puede haber confusión con los tipos de datos, lo que hace imposible verificar su corrección.

También todos los datos en una columna solo pueden ser de un tipo. Diferentes tipos de datos dificultan el trabajo con la tabla, ya que en el código tendrás que entender de alguna manera qué son los datos. Y para distinguir los registros entre sí, necesitamos usar una clave primaria sustituta, que haga que cada registro sea único.

Materiales adicionales

1. Clave primaria 🔑 Wikipedia
2. Clave externa 🔑 Wikipedia
3. Clave sustituta 🔑 Wikipedia