Normalización de bases de datos (Parte 2): Primera forma de normalización (1NF)

La primera forma de normalización (1NF) de las bases de datos fue presentada por vez primera en 1970 por el Dr. Edgar F. Codd, un científico inglés de la computación que trabajaba para IBM en los sistemas de administración de bases de datos relacionales. La segunda (2NF) y tercera (3NF) formas de normalización se presentaron en 1971. Al final, los Dres. Edgar F. Codd y Raymond F. Boyce presentaron la forma de normalización Boyce-Codd en 1974 que comprendió cinco formas de normalización, mismas que, con el paso del tiempo, se han ido puliendo y aumentando. Hoy son hasta 6 formas de normalización con algunos addendums.

Durante estos artículos asumiré que ya se sabe qué es un campo, qué es un registro, qué es una tabla, qué son las relaciones y qué son las bases de datos.

Ahora bien, para cumplir con la primera forma de normalización se necesita cumplir con cuatro reglas:

1. Cada columna debe tener un nombre único.
2. Una columna debe contener valores del mismo tipo.
3. Cada columna debe tener valores atómicos o únicos.
4. No importa el orden en el que se guardan los datos.

Vamos a desmenuzar una a una cada regla:

Cada columna debe tener un nombre único

Esta regla se refiere a una tabla en particular. En una tabla no debe haber nombres de columnas repetidos para evitar confusiones (en la mayoría de los modernos motores de bases de datos, no se permite repetir nombres de columnas). Esto, así, es un gran apoyo para evitar la duplicación de nombres, de manera que este aspecto queda resuelto con el uso de los modernos motores de bases de datos relacionales.

Ahora bien, tablas diferentes sí pueden tener campos con nombres iguales: El campo "Nombre" en la tabla "Clientes", por ejemplo, significa algo diferente al campo "Nombre" de la tabla "Empleados". Lo que da el contexto es el "Dominio de datos". El "dominio de datos" se refiere al tipo de valores que puede contener un elemento de datos. El dominio de datos comprende un campo y el dominio como tal a una tabla, cuyo grupo de campos establece un tipo de dato adaptado o customizado (también se le conoce como "tipo de dato definido por el usuario" o UDT). En el campo, el "dominio de datos" se refiere al tipo de dato que se espera encontrar en el campo. Por ejemplo, y para retomar lo que mencioné hace unos momentos, en "Nombre" se espera que se coloque el nombre de pila de una persona en cualquiera de los dos casos. Ahora bien, el dominio en una tabla se refiere al tipo de datos que se espera que contenga la tabla. En la tabla "Clientes" el dominio serían los datos del cliente, y, por ende, "Nombre" se refiere al dominio de los clientes. En la tabla "Empleados" el dominio serían los datos de los empleados y, por ende, "Nombre" en esta tabla se refiere al dominio de los empleados. Así, aunque haya "Nombre" en "Clientes" y "Nombre" en "Empleados", estos campos pertenecen a dominios diferentes, por lo que no se repiten.

Una columna debe contener valores del mismo tipo

Ésta es una regla de sentido común. Resulta que si tenemos el campo "Nombre" en la tabla "Empleados" no se espera que haya un número o un código allí, sino que se coloque el nombre de pila del empleado. Así, todos los datos que se graben en el campo "Nombre" deberían pertenecer al tipo de dato que se pretende almacenar en el campo. Ciertamente, algunas bases de datos permiten almacenar números en campos de texto, pero hay una diferencia importante: No se almacenaría el valor numérico, sino la representación del número. No es lo mismo 1 que "1". El primero es el valor 1 y el segundo es la representación tipográfica de "1". Para la computadora son cosas diferentes y esta diferencia debe ser importante para nosotros también.

Cada columna debe tener valores atómicos o únicos

Ésta es una parte primordial de la regla en sí. Cada una de las columnas debería tener sólo un valor y no un grupo de valores. Por ejemplo, en el campo "Nombre" se esperaría que se almacenara un valor como "Ileana", "Gloria Patricia", "María del Carmen Silvia" o algo así. Lo que no se esperaría es que se almacenara algo como "Alejandro Enrique Garza Marín", pues en ese campo se está almacenando no solo el nombre, sino, también, los apellidos. Se esperaría que hubiese otro par de campos llamados "Apellido1" y "Apellido2" para almacenar los dos apellidos (en su caso) de las personas (al menos, el primero). Lo mismo pasaría si en el campo "Nombre" se almacenara "Víctor, Jessica" para referirse a dos clientes. Debería haber un registro para "Víctor" y otro para "Jessica". Parece algo lógico, pero, la verdad, es que éste es un problema muy recurrente en bases de datos que dificultan sensiblemente su proceso de limpieza.

Otro ejemplo de violación a esta regla se daría en una situación como la que sigue (tabla "Clientes"):

IDCliente | Nombre | Apellido1 | Apellido2 | FPago1 | FPago2 | Fpago3 |

En este ejemplo simple, la tabla está diseñada para poner en perspectiva las distintas formas de pago con las que el cliente cuenta. Sin embargo, ésta no es una buena práctica, dado que se desperdiciaría espacio en caso de que el cliente sólo tuviera una forma de pago, y faltaría espacio si el cliente tuviera más de tres formas de pago. Esto no debería pasar. La tabla debería escindirse en dos tablas: 1: Clientes, 2: FormasDePago.

"Clientes"

IDCliente | Nombre | Apellido1 | Apellido2 |

"FormasDePago"

IDCliente | FPago |

Así, el cliente puede tener una cantidad incontable de formas de pago (desde una hasta las que requiera). Claro está que este diseño es extremadamente simplista, pero, al menos, permite tener una idea. Así que hay que estar atento con esto de la atomicidad de los datos.

No importa el orden en el que se guardan los datos

Esto es más un aspecto informativo, pues del orden se encargaría el motor de la base de datos. Así, los datos pueden agregarse en cualquier orden, y las herramientas provistas por la base de datos se encargarán de ordenarlos como sea requerido. Cabe hacer notar que si se tienen relaciones con una integridad referencial, la clave a la que se haga referencia deberá existir so pena de que haya alguna queja o error proveniente de la base de datos que se utilice.

La base de datos de los códigos postales

En el sentido estricto, la tabla que bajamos de los códigos postales cumple por completo con la primera forma de normalización. 1) Cada columna tiene un nombre único, 2) Cada columna tiene valores de un solo tipo, 3) Los valores son atómicos y 4) aunque hay un orden basado en los códigos postales, el resto de las columnas están sin un orden en particular.

Así, en esta primera forma de normalización, no hay cambios por hacer en la tabla de códigos postales. Pero sí las habrá con la segunda forma de normalización (2NF). ¡Nos seguimos leyendo!