Hispanopedia WikiLa primera forma normal ( 1FN ) es el nivel más básico de normalización de bases de datos definido por el informático inglés Edgar F. Codd , inventor de la base de datos relacional . Se dice que una relación (o una tabla , en SQL ) está en primera forma normal si cada campo es atómico , es decir, contiene un único valor en lugar de un conjunto de valores o una tabla anidada . En otras palabras, una relación cumple con la primera forma normal si ningún dominio de atributos (el conjunto de valores permitidos en una columna determinada) tiene relaciones como elementos. [ 1 ]
La mayoría de los sistemas de gestión de bases de datos relacionales, incluido SQL estándar, no admiten la creación ni el uso de columnas con valores de tabla, lo que significa que la mayoría de las bases de datos relacionales estarán necesariamente en primera forma normal. De lo contrario, la normalización a 1NF implica eliminar las relaciones anidadas dividiéndolas en relaciones separadas asociadas entre sí mediante claves foráneas . [ 2 ] : 381 Este proceso es un paso necesario al mover datos de una base de datos no relacional (o NoSQL ), como una que utiliza un modelo jerárquico u orientado a documentos , a una base de datos relacional.
Una base de datos debe cumplir con la primera forma normal (1NF) para poder cumplir con otras formas normales , como la segunda y la tercera , que permiten reducir la redundancia y las anomalías. Otras ventajas de adoptar la 1NF incluyen una mayor independencia y flexibilidad de los datos (incluidas características como las relaciones de muchos a muchos ) y la simplificación del álgebra relacional y el lenguaje de consulta necesarios para describir las operaciones en la base de datos.
Codd consideraba que la 1NF era obligatoria para las bases de datos relacionales, mientras que las demás formas normales eran simplemente directrices para el diseño de bases de datos. [ 3 ] : 439
Fondo
La primera forma normal fue introducida en 1970 por Edgar F. Codd en su artículo "Un modelo relacional de datos para grandes bancos de datos compartidos" [ 2 ] , aunque inicialmente se la denominó simplemente "normalización" o "forma normal". Se la renombró como "primera forma normal" cuando Codd introdujo formas normales adicionales en su artículo "Mayor normalización del modelo relacional de base de datos" en 1971 [ 4 ].
El modelo relacional se propuso como una mejora respecto a las bases de datos jerárquicas , que eran predominantes en ese momento. [ 2 ] : 377 Una diferencia clave radica en cómo se representan las relaciones entre los registros. En una base de datos jerárquica, las relaciones de uno a muchos se representan mediante la contención: un único registro puede contener conjuntos de registros (conocidos como grupos repetitivos) como valores de atributos. Sin embargo, Codd argumentó que la jerarquía no es lo suficientemente flexible ni expresiva para modelos de datos más complejos. Por ejemplo, las relaciones de muchos a muchos no pueden representarse mediante la jerarquía. [ 2 ] : 378 Por lo tanto, sugirió eliminar los registros anidados y, en su lugar, representar las relaciones mediante claves foráneas . Esto permite expresar relaciones más ricas, ya que un registro ahora puede participar en múltiples relaciones. [ 2 ] : 378
Una traducción directa de una base de datos jerárquica a relaciones representaría los grupos repetidos como relaciones anidadas. Por lo tanto, la normalización se define como la eliminación de relaciones anidadas y, en su lugar, la representación de la relación uno a muchos mediante claves foráneas. [ 2 ] : 381
Codd distingue entre datos "atómicos" y "compuestos". Los datos atómicos (o "no descomponibles") incluyen tipos básicos como números y cadenas ; en términos generales, " no pueden ser descompuestos en partes más pequeñas por el SGBD (excepto ciertas funciones especiales)". Los datos compuestos están formados por estructuras como relaciones (o tablas , en SQL ) que contienen varias partes de datos atómicos y, por lo tanto, " pueden ser descompuestos por el SGBD". [ 5 ] : 6
En una relación, cada atributo (o columna ) tiene un conjunto de valores permitidos conocido como su dominio (por ejemplo, el dominio de un atributo "Precio" puede ser el conjunto de números no negativos con hasta 2 dígitos fraccionarios). Cada tupla (o fila ) en la relación contiene un valor por atributo, y cada uno debe ser un elemento en el dominio de ese atributo. Codd distingue los atributos que tienen "dominios simples" que contienen solo datos atómicos de los atributos con "dominios no simples" que contienen al menos algunas formas de datos compuestos. [ 2 ] : 380 Los dominios no simples introducen un grado de complejidad estructural que puede ser difícil de navegar, consultar y actualizar; por ejemplo, será lento operar a través de varias relaciones anidadas (es decir, tablas que contienen más tablas), que se pueden encontrar en algunas bases de datos no relacionales .
Por lo tanto, la primera forma normal requiere que todos los dominios de atributos sean dominios simples , de modo que los datos en cada campo sean atómicos y ninguna relación tenga atributos con valores relacionales. Precisamente, Codd afirma que, en el modelo relacional, "se requiere que los valores en los dominios sobre los que se define cada relación sean atómicos con respecto al SGBD". [ 5 ] : 6 La normalización a 1NF es, por lo tanto, un proceso de eliminación de dominios no simples de todas las relaciones.
Ejemplos
Diseño que viola la 1NF
Esta tabla de transacciones con tarjeta de crédito de los clientes no se ajusta a la primera forma normal, ya que cada cliente corresponde a un grupo repetitivo de transacciones. Este diseño se puede representar en una base de datos jerárquica , pero no en una base de datos SQL, puesto que SQL no admite tablas anidadas.
La evaluación de cualquier consulta relacionada con las transacciones de los clientes generalmente constaría de dos etapas:
- desempaquetar uno o más grupos de transacciones de clientes, permitiendo examinar las transacciones individuales en un grupo y
- obtener un resultado de consulta a partir de los resultados de la primera etapa.
Por ejemplo, para averiguar la suma monetaria de todas las transacciones que se produjeron en octubre de 2003 para todos los clientes, el sistema de gestión de bases de datos (DMBS) tendría que descomprimir primero el campo Transacciones de cada cliente y luego sumar el Importe de cada transacción así obtenida, siempre que la Fecha de la transacción caiga en octubre de 2003.
Diseño que cumple con 1NF
Codd describió cómo una base de datos de este tipo podría hacerse menos compleja estructuralmente y más flexible transformándola en una base de datos relacional en primera forma normal. Para normalizar la tabla y que cumpla con la primera forma normal, los atributos con dominios no simples deben extraerse a relaciones separadas e independientes. Cada relación extraída obtiene una clave externa que hace referencia a la clave primaria de la relación que la contenía inicialmente. Este proceso puede aplicarse recursivamente a dominios no simples anidados en múltiples niveles (es decir, dominios que contienen tablas dentro de tablas dentro de tablas, y así sucesivamente). [ 2 ] : 380–381
En este ejemplo, CustomerID es la clave primaria de la relación contenedora y, por lo tanto, se agregará como clave foránea a la nueva relación:
En este diseño modificado, la clave primaria es {CustomerID} en la primera relación y {CustomerID, TransactionID} en la segunda relación.
Ahora que una única relación de nivel superior contiene todas las transacciones, será más sencillo ejecutar consultas en la base de datos. Para hallar el total de las transacciones de octubre, el sistema de gestión de bases de datos (DBMS) simplemente buscaría todas las filas con una fecha correspondiente a octubre y sumaría los importes. Todos los valores están ahora fácilmente accesibles para el DBMS, mientras que anteriormente algunos valores estaban integrados en estructuras de nivel inferior que requerían un tratamiento especial. Por consiguiente, el diseño normalizado se presta bien al procesamiento de consultas de propósito general, a diferencia del diseño no normalizado.
Cabe destacar que el diseño revisado también cumple con los requisitos adicionales para la segunda y tercera forma normal .
Razón fundamental
La normalización a 1NF es el principal componente teórico para transferir una base de datos al modelo relacional . El uso de una base de datos relacional en 1NF ofrece ciertas ventajas:
- Permite almacenar datos en matrices bidimensionales regulares ; admitir relaciones anidadas requeriría estructuras de datos más complejas. [ 2 ] : 381
- Permite el uso de un lenguaje de consulta más sencillo , como SQL , ya que cualquier elemento de datos se puede identificar utilizando solo un nombre de relación, un nombre de atributo y una clave; para abordar elementos de datos anidados se requeriría un lenguaje más complejo con soporte para rutas de datos jerárquicas.
- Representar las relaciones mediante claves foráneas es más flexible y permite características como las relaciones de muchos a muchos , mientras que un modelo jerárquico solo puede representar relaciones de uno a uno o de uno a muchos .
- Dado que la localización de los elementos de datos no está vinculada a una jerarquía padre-hijo, una base de datos en 1NF crea una mayor independencia de los datos y es más resistente a los cambios estructurales a lo largo del tiempo.
- A partir de la primera forma normal (1NF), es posible una mayor normalización (por ejemplo, a la segunda forma normal o a la tercera ), lo que puede reducir la redundancia de datos y las anomalías.
Controversia sobre los valores compuestos
Existe cierto debate sobre hasta qué punto se permiten valores compuestos o complejos distintos de las relaciones (como matrices o datos XML ) en la 1NF. Codd afirma que las relaciones son el único tipo de datos compuestos permitidos dentro del modelo relacional (si no en los dominios de atributos), ya que cualquier otro tipo de datos compuestos añadiría complejidad sin aumentar la potencia; sin embargo, el modelo permite específicamente "ciertas funciones especiales", como descomponer valores que de otro modo se considerarían atómicos. [ 5 ] : 6,340SUBSTRING
Hugh Darwen y Christopher J. Date han sugerido que el concepto de "valor atómico" de Codd es ambiguo, y que esta ambigüedad ha llevado a una confusión generalizada sobre cómo debe entenderse la 1NF. [ 6 ] [ 7 ] En particular, la noción de un valor atómico como un "valor que no puede descomponerse" es problemática, ya que parecería implicar que pocos, si acaso alguno, tipos de datos son atómicos:
- Una cadena de caracteres no parece ser atómica, ya que un sistema de gestión de bases de datos relacionales (RDBMS) normalmente proporciona operadores para descomponerla en subcadenas .
- Un número de punto fijo no parece ser atómico, ya que un sistema de gestión de bases de datos relacionales (RDBMS) normalmente proporciona operadores para descomponerlo en componentes enteros y fraccionarios.
- Un ISBN no parece ser una unidad básica, ya que incluye varias partes, entre ellas el grupo de registro , el registrante y los elementos de publicación .
Date sugiere que "la noción de atomicidad no tiene un significado absoluto ": [ 8 ] : 112 [ 9 ] un valor puede considerarse atómico para algunos propósitos, pero puede considerarse un conjunto de elementos más básicos para otros propósitos. Si se acepta esta posición, la 1NF no puede definirse con referencia a la atomicidad. Las columnas que contienen cualquier tipo de dato imaginable (desde cadenas y tipos numéricos hasta matrices y tablas) son entonces aceptables en una tabla 1NF, aunque tal vez no siempre deseables; por ejemplo, puede ser deseable separar una columna CustomerName en dos columnas, FirstName y Surname.
Definición de 1NF según Christopher J. Date
Según la definición de Christopher J. Date , una tabla está en primera forma normal si y solo si es " isomorfa a alguna relación", lo que significa, específicamente, que satisface las siguientes cinco condiciones: [ 8 ] : 127–128
- No existe un orden específico de arriba a abajo para las filas.
- No existe un orden específico de izquierda a derecha para las columnas.
- No hay filas duplicadas.
- Cada campo (o intersección de una fila y una columna) contiene exactamente un valor del dominio correspondiente y nada más.
- Todas las columnas son regulares (es decir, las filas no tienen componentes ocultos como identificadores de fila, identificadores de objeto o marcas de tiempo ocultas).
La violación de cualquiera de estas condiciones significaría que la tabla no es estrictamente relacional y, por lo tanto, que no está en primera forma normal.
Esta definición de 1NF permite atributos con valores relacionales (tablas dentro de tablas), que Date argumenta que son útiles en casos excepcionales. [ 8 ] : 121–126 Ejemplos de tablas (o vistas ) que no cumplirían con esta definición de primera forma normal son:
- Una tabla que carece de una restricción de clave única . Dicha tabla podría contener filas duplicadas, lo que violaría la condición 3.
- Una vista cuya definición exige que los resultados se devuelvan en un orden particular, de modo que el orden de las filas sea un aspecto intrínseco y significativo de la vista, en violación de la condición 1. Las tuplas en las relaciones verdaderas no están ordenadas entre sí (dichas vistas no se pueden crear utilizando SQL que cumpla con el estándar SQL:2003 ).
- Una tabla con al menos un atributo que admite valores nulos . Un atributo que admite valores nulos violaría la condición 4, que requiere que cada columna contenga exactamente un valor de su dominio. Este aspecto de la condición 4 es controvertido; marca una importante desviación de la visión posterior de Codd sobre el modelo relacional , [ 10 ] que contemplaba explícitamente los valores nulos. [ 11 ]
Véase también
- Sistema de atributos y valores
- Segunda forma normal (2FN)
- Tercera forma normal (3FN)
- Forma normal de Boyce-Codd (BCNF o 3.5NF)
- Cuarta forma normal (4FN)
- Quinta forma normal (5NF)
- Sexta forma normal (6NF)
Referencias
- ↑ Codd, EF (1972). "Mayor normalización del modelo relacional de bases de datos". pág. 27
- 1 2 3 4 5 6 7 8 9 Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Communications of the ACM . 13 (6): 377– 387. doi : 10.1145/362384.362685 .
- ↑ Codd, EF (1979). "Extending the database relational model to capture more meaning". ACM Transactions on Database Systems . 4 (4): 397– 434. doi : 10.1145/320107.320109 .
- ↑ Codd, EF (1971). "Mayor normalización del modelo relacional de bases de datos". Sistemas de bases de datos. Simposio de Ciencias de la Computación de Courant 6 editado por Rustin, R.
- 1 2 3 Codd, EF (1 de enero de 1990). El modelo relacional para la gestión de bases de datos: versión 2. Addison -Wesley . ISBN 978-0-201-14192-4.
- ↑ Darwen, Hugh. "Atributos con valor relacional; o, ¿Se pondrá de pie la primera forma normal real?", en CJ Date y Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992).
- ↑ Date, CJ (2007). «Capítulo 8: Qué significa realmente la primera forma normal». Date en la base de datos: Escritos 2000–2006 . Apress. pág. 108. ISBN 978-1-4842-2029-0.
«Durante muchos años», escribe Date, «estuve tan confundido como cualquiera. Lo que es peor, hice todo lo posible (¿o lo peor?) por difundir esa confusión a través de mis escritos, seminarios y otras presentaciones».
- 1 2 3 Date, CJ (2007). «Capítulo 8: Qué significa realmente la primera forma normal». Date en la base de datos: Escritos 2000–2006 . Apress. ISBN 978-1-4842-2029-0.
- ↑ Date, CJ (6 de noviembre de 2015). SQL y teoría relacional: Cómo escribir código SQL preciso . O'Reilly Media. págs. 50–. ISBN 978-1-4919-4115-7Consultado el 31 de octubre de 2018 .
- ↑ Date, CJ (2009). "Apéndice A.2". SQL y teoría relacional . O'Reilly.
Codd definió por primera vez el modelo relacional en 1969 y no introdujo los valores nulos hasta 1979.
- ↑ Date, CJ (14 de octubre de 1985). "¿Es realmente relacional su DBMS?". Computerworld .
Los valores nulos... [deben] ser compatibles en un DBMS totalmente relacional para representar información faltante e información no aplicable de manera sistemática, independientemente del tipo de datos.
(la tercera de las 12 reglas de Codd)
Lecturas adicionales
- Date, CJ, & Lorentzos, N., & Darwen, H. (2002). Datos temporales y el modelo relacional (1.ª ed.). Morgan Kaufmann. ISBN 1-55860-855-9.
- Date, CJ (1999), Introducción a los sistemas de bases de datos (8.ª ed.). Addison-Wesley Longman. ISBN 0-321-19784-4.
- Kent, W. (1983) Una guía sencilla de cinco formas normales en la teoría de bases de datos relacionales , Communications of the ACM , vol. 26, págs. 120-125.
- Normalización de la base de datos
