La primera forma normal es la primera de las reglas de normalización de bases de datos y por tanto es la más importante, ya que si no se cumple con esta regla no se pueden cumplir con las demás.
Esta regla se asegura que una tabla es una representación válida de una entidad, cumple con varias propiedades de las tablas y no tiene grupos repetitivos. Debe cumplir con varios subreglas
No hay orden de arriba-a-abajo en las filas.
Es necesario que el orden en el que son dados de alta los registros no tenga ningún significado. En un registro de empleados, no se debe asumir que el primer registro que se dió de alta en la tabla se refiere al empleado con mayor antigüedad. Para controlar eso, será necesario colocar un campo de fecha de ingreso.
No hay orden de izquierda-derecha en las columnas.
Haciendo el mismo razonamiento que la subregla anterior, el orden de los campos de una tabla no debe tener ningún significado. Asumiento una tabla con varios campos, entre ellos
- UnApellido (de tipo texto)
- OtroApellido (de tipo texto)
No se debe,por tanto, a asumir que el campo UnApellido se trata al Apellido paterno y OtroApellido al apellido materno. En lugar de eso se debe nombrar correctamente cada campo
- ApellidoMaterno (o SegundoApellido)
- ApellidoPaterno (o PrimerApellido)
De esa manera no importa en qué orden se definan los campos en la tabla, el nombre del campo nos da el siginifcado de cada uno de ellos.
No hay filas duplicadas.
Es decir, hay unicidad de registro; y esto se obtiene fácilmente teniendo una llave primaria en la tabla.
Cada intersección de fila-columna contiene exactamente un valor del dominio aplicable (y nada más).
Cuando se define un campo en la tabla, todos los registros tendrán valores en sus campos de los valores esperados (por el control del tipo de datos) y dentro del dominio esperado también (por las restricciones o CONSTRAINT configurados)
No debe haber campos que permitan nulos
Una manera de asegurarse que la calidad de los datos es óptima es asegurándose que los campos no acepten valores nulos. Esto se logra enla configuración de los campos, con la directiva de NOT NULL.
Esta subregla de la 1FN parecería que se contrapone con las Reglas de Codd donde se especifica que la base de datos debe poder manejar valores nulos; sin embargo, la posibilidad de que pueda manejar valores nulos no significa que debe utilizarse.
Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
Cada campo dentro de la tabla debe hablar del concepto que se guarda en la tabla, y además debe depender de todas las llaves candidatas (la llave primaria y las llaves secundarias).
En el caso de la siguiente tabla de una tienda departamental
- Ticket (Número)
- Cajero (Texto)
- FechaDeVenta (Año, Mes, Día, Hora, Minuto, Segundo)
- Cliente (Texto)
- ClaveDePuestoDelCajero (Número)
- Producto1 (Texto)
- CantidadVendidaDeProducto1 (Número)
- Producto2 (Texto)
- CantidadVendidaDeProducto2 (Número)
- Producto3 (Texto)
- CantidadVendidaDeProducto3 (Número)
- Producto4 (Texto)
- CantidadVendidaDeProducto4 (Número)
Las llaves candidatas quedarían como sigue
- Ticket (Llave primaria)
- Cajero + FechaDeVenta (Llave secundaria)
En este caso, se encuentra que la tabla no cumple con la primera forma normal ya que el campo ClaveDePuestoDelCajero depende del Cajero, y no de la llave secundaria que está formada por Cajero Y FechaDeVenta . En este caso es necesario sacar ese campo y ubicarlo en otra tabla (probablemente en la tabla de Empleados)
No debe contar con grupos repetitivos
Un grupo repetitivo es un conjunto de campos que permiten guardar varios valores de un mismo tipo.
Otros ejemplos de grupos repetitivos son:
- Telefóno1, Telefono2, Teléfono3.
- Descuento1, Descuento2, Descuento3.
- HorarioEntradaLunes, HorarioEntradaMartes, HorarioEntradaMiércoles, … HorarioEntradaDomingo.
- Habilidad1, Habilidad2, Habilidad3.
En esos casos será necesario crear una nueva tabla (con los grupos repetitivos) y crear una relación 1:n con la tabla principal. En la tabla ejemplificada en el punto anterior, existen 4 campos para los Productos vendidos. En esta situación será necesario dividir la tabla original en dos nuevas tablas con
TablaDeVenta
- Ticket (Número)
- Cajero (Texto)
- FechaDeVenta (Año, Mes, Día, Hora, Minuto, Segundo)
- Cliente (Texto)
- ClaveDePuestoDelCajero (Número)
TablaDeProductosVendidos
- Ticket (Número)
- Producto (Texto)
- CantidadVendidaDeProducto (Número)
Ejemplos de tablas que NO cumplen con la primera forma normal
- Una tabla que carece de una clave primaria.
- Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista.
- Una tabla con, por lo menos, un atributo que pueda ser nulo.
- Una tabla con un grupo repetitivo de campos.