La primera forma normal ( 1NF ) es una propiedad de una relación en una base de datos relacional . Una relación está en primera forma normal si y solo si ningún dominio de atributo tiene relaciones como elementos. [1] O más informalmente, que ninguna columna de tabla puede tener tablas como valores. La normalización de la base de datos es el proceso de representar una base de datos en términos de relaciones en formas normales estándar, donde la primera normalidad es un requisito mínimo. SQL no admite la creación o el uso de columnas con valores de tabla, lo que significa que la mayoría de las bases de datos relacionales estarán en la primera forma normal por necesidad. Los sistemas de bases de datos que no requieren la primera forma normal a menudo se denominan sistemas sin SQL .
Descripción general
En una base de datos jerárquica como IBM Information Management System, un registro puede contener conjuntos de registros secundarios, conocidos como grupos repetidos o atributos con valores de tabla. Si tal modelo de datos se representa como relaciones, un grupo repetido sería un atributo donde el valor es en sí mismo una relación. La primera forma normal elimina las relaciones anidadas convirtiéndolas en relaciones separadas de "nivel superior" asociadas con la fila principal a través de claves externas en lugar de mediante contención directa.
El propósito de esta normalización es aumentar la flexibilidad, la independencia de los datos y simplificar el lenguaje de los datos. También abre la puerta a una mayor normalización que elimina redundancias y anomalías.
La mayoría de los sistemas de administración de bases de datos relacionales no admiten registros anidados, por lo que las tablas están en la primera forma normal de forma predeterminada. En particular, SQL no tiene facilidades para crear o explotar tablas anidadas. Por lo tanto, la normalización a la primera forma normal sería un paso necesario al mover datos de una base de datos jerárquica a una base de datos relacional.
Razón fundamental
El fundamento de la normalización a 1NF: [2]
- Permite presentar, almacenar e intercambiar datos relacionales en forma de matrices bidimensionales regulares. El soporte de relaciones anidadas requeriría estructuras de datos más complejas.
- Simplifica el lenguaje de los datos, ya que cualquier elemento de datos puede identificarse solo por el nombre de la relación, el nombre del atributo y la clave. El soporte de relaciones anidadas requeriría un lenguaje más complejo con soporte para rutas de datos jerárquicas para abordar elementos de datos anidados.
- Representar relaciones mediante claves externas es más flexible, donde un modelo jerárquico solo puede representar relaciones de uno a varios.
- Dado que la ubicación de elementos de datos no está directamente relacionada con la jerarquía de padres e hijos, la base de datos es más resistente a los cambios estructurales a lo largo del tiempo.
- Hace posibles más niveles de normalización que eliminan la redundancia de datos y las anomalías.
Inconvenientes y críticas
- Rendimiento para determinadas operaciones. En un modelo jerárquico, los registros anidados se almacenan físicamente después del registro principal, lo que significa que se puede recuperar un subárbol completo en una sola operación de lectura. En un formulario 1NF, requerirá una operación de combinación por tipo de registro, lo que puede ser costoso, especialmente para árboles complejos. Por esta razón , las bases de datos de documentos evitan 1NF.
- Los lenguajes orientados a objetos representan el estado de tiempo de ejecución como árboles o gráficos de objetos conectados por punteros o referencias. Esto no se asigna limpiamente a una base de datos relacional 1NF, un problema que a veces se denomina desajuste de impedancia relacional de objeto y que las bibliotecas ORM intentan salvar.
- Se ha interpretado que 1NF no permite tipos de datos complejos para valores. Sin embargo, esto está abierto a interpretación, y CJDate ha argumentado que los valores pueden ser objetos arbitrariamente complejos.
Historia
La primera forma normal fue introducida por EF Codd en el artículo "Un modelo relacional de datos para grandes bancos de datos compartidos", aunque inicialmente se llamó simplemente "Forma normal". Se le cambió el nombre a "Primera forma normal" cuando se introdujeron formas normales adicionales en el documento Más normalización del modelo relacional [3]
Ejemplos de
Los siguientes escenarios ilustran primero cómo el diseño de una base de datos podría violar la primera forma normal, seguidos de ejemplos que cumplen.
Diseños que violan 1NF
Esta tabla sobre las transacciones con tarjeta de crédito de los clientes no se ajusta a la primera forma normal:
Cliente | Identificación del cliente | Actas | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Abrahán | 1 |
| ||||||||||||
Isaac | 2 |
| ||||||||||||
Jacob | 3 |
|
A cada cliente le corresponde 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, ya que SQL no admite tablas anidadas.
La evaluación automatizada de cualquier consulta relacionada con las transacciones de los clientes implicaría, en líneas generales, dos etapas:
- Desembalar uno o más grupos de transacciones de clientes que permitan examinar las transacciones individuales de un grupo, y
- Derivar un resultado de consulta basado en los resultados de la primera etapa
Por ejemplo, para averiguar la suma monetaria de todas las transacciones que ocurrieron en octubre de 2003 para todos los clientes, el sistema tendría que saber que primero debe descomprimir el grupo de Transacciones de cada cliente, luego sumar los Montos de todas las transacciones así obtenidas. donde la Fecha de la transacción cae en octubre de 2003.
Una de las ideas importantes de Codd fue que se puede reducir la complejidad estructural. La complejidad estructural reducida brinda a los usuarios, aplicaciones y DBMS más poder y flexibilidad para formular y evaluar las consultas. Un equivalente más normalizado de la estructura anterior podría verse así:
Diseños que cumplen con 1NF
Para llevar el modelo a la primera forma normal, podemos realizar la normalización. La normalización (a la primera forma normal) es un proceso en el que los atributos con dominios no simples se extraen para separar relaciones independientes. Las relaciones extraídas se modifican con claves externas que se refieren a la clave primaria de la relación que la contenía. El proceso se puede aplicar de forma recursiva a dominios no simples anidados en varios niveles. [4]
En este ejemplo, el ID de cliente es la clave principal de las relaciones contenedoras y, por lo tanto, se agregará como clave externa a la nueva relación:
Cliente | Identificación del cliente |
---|---|
Abrahán | 1 |
Isaac | 2 |
Jacob | 3 |
Identificación del cliente | ID de transacción | Fecha | Monto |
---|---|---|---|
1 | 12890 | 14 de octubre de 2003 | −87 |
1 | 12904 | 15 de octubre de 2003 | −50 |
2 | 12898 | 14 de octubre de 2003 | −21 |
3 | 12907 | 15 de octubre de 2003 | −18 |
3 | 14920 | 20 de noviembre de 2003 | −70 |
3 | 15003 | 27 de noviembre de 2003 | −60 |
En la estructura modificada, la clave principal es {ID de cliente} en la primera relación, {ID de cliente, ID de transacción} en la segunda relación.
Ahora cada fila representa una transacción de tarjeta de crédito individual, y el DBMS puede obtener la respuesta de interés, simplemente encontrando todas las filas con una Fecha que cae en octubre y sumando sus Cantidades. La estructura de datos coloca todos los valores en pie de igualdad, exponiendo a cada uno directamente al DBMS, por lo que cada uno puede potencialmente participar directamente en las consultas; mientras que en la situación anterior algunos valores estaban incrustados en estructuras de nivel inferior que debían manejarse de manera especial. En consecuencia, el diseño normalizado se presta al procesamiento de consultas de propósito general, mientras que el diseño no normalizado no lo hace.
Vale la pena señalar que este diseño cumple con los requisitos adicionales para la segunda y tercera forma normal .
Atomicidad
La definición de 1NF de Edgar F. Codd hace referencia al concepto de "atomicidad". Codd afirma que "los valores en los dominios en los que se define cada relación deben ser atómicos con respecto al DBMS ". [5] Codd define un valor atómico como uno que "no puede ser descompuesto en partes más pequeñas por el DBMS (excluyendo ciertas funciones especiales)" [6] lo que significa que una columna no debe dividirse en partes con más de un tipo de datos en ella que lo que una parte significa para el DBMS depende de otra parte de la misma columna.
Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor atómico" es ambiguo, y que esta ambigüedad ha llevado a una confusión generalizada sobre cómo debería entenderse 1NF. [7] [8] En particular, la noción de un "valor que no se puede descomponer" es problemática, ya que parecería implicar que pocos tipos de datos, si es que hay alguno, son atómicos:
- Una cadena de caracteres parecería no ser atómica, ya que el RDBMS normalmente proporciona operadores para descomponerla en subcadenas.
- Un número de punto fijo no parecería ser atómico, ya que el RDBMS generalmente proporciona a los operadores para descomponerlo en componentes enteros y fraccionarios.
- Un ISBN no parece ser atómico, ya que incluye el idioma y el identificador del editor.
Date sugiere que "la noción de atomicidad no tiene un significado absoluto ": [9] [10] 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, 1NF no se puede definir con referencia a la atomicidad. Las columnas de cualquier tipo de datos imaginable (desde tipos de cadena y tipos numéricos hasta tipos de matriz y tipos de tabla) son aceptables en una tabla 1NF, aunque quizás no siempre sea deseable; por ejemplo, puede ser más conveniente separar una columna Nombre del cliente en dos columnas separadas como Nombre, Apellido.
Tablas 1NF como representaciones de relaciones
Según la definición de 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: [11]
- No hay un orden de arriba a abajo en las filas.
- No hay un orden de izquierda a derecha para las columnas.
- No hay filas duplicadas.
- Cada intersección de filas y columnas contiene exactamente un valor del dominio aplicable (y nada más).
- 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].
La violación de cualquiera de estas condiciones significaría que la tabla no es estrictamente relacional y, por lo tanto, no está en la primera forma normal.
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. Tal tabla podría acomodar filas duplicadas, en violación de 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 filas sea un aspecto intrínseco y significativo de la vista. (Estas vistas no se pueden crear usando SQL que cumpla con el estándar SQL: 2003 ). Esto viola la condición 1. Las tuplas en relaciones verdaderas no están ordenadas entre sí.
- Una tabla con al menos un atributo que acepta valores NULL . Un atributo que acepta valores NULL infringe la condición 4, que requiere que cada columna contenga exactamente un valor del dominio de su columna. Este aspecto de la condición 4 es controvertido. Marca una desviación importante de la visión posterior de Codd del modelo relacional , [12] que hizo una provisión explícita para los nulos. [13] La primera forma normal, según la define Chris Date, permite atributos con valores de relación (tablas dentro de tablas). Date sostiene que los atributos con valores de relación, por medio de los cuales una columna dentro de una tabla puede contener una tabla, son útiles en casos excepcionales. [14]
Ver también
Referencias
- ^ Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM. Clásicos. 13 (6): 377–87. pag. 380-381
- ^ Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM. Clásicos. 13 (6): 377–87.
- ^ Codd, EF (1971). Mayor normalización del modelo relacional. Courant Computer Science Symposium 6 in Data Base Systems editado por Rustin, R.
- ^ Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM. Clásicos. 13 (6): 377–87. pag. 381
- ^ Codd, EF The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
- ^ Codd, EF The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
- ^ Darwen, Hugh. "Atributos con valores de relación; o, ¿se levantará la primera forma normal real?", En CJ Date y Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992).
- ^ Fecha, CJ (2007). Lo que realmente significa la primera forma normal . Fecha en la base de datos: Escritos 2000-2006 . Presione. pag. 108. ISBN 978-1-4842-2029-0.
'[P] o muchos años', escribe Date, 'estaba tan confundido como cualquier otra persona. Lo que es peor, hice lo mejor (¿peor?) Para difundir esa confusión a través de mis escritos, seminarios y otras presentaciones '.
- ^ Fecha, CJ (2007). Lo que realmente significa la primera forma normal . Fecha en la base de datos: Escritos 2000-2006 . Presione. pag. 112. 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-7. Consultado el 31 de octubre de 2018 .
- ^ Fecha, CJ (2007). Lo que realmente significa la primera forma normal . Fecha en la base de datos: Escritos 2000-2006 . Presione. págs. 127-128. ISBN 978-1-4842-2029-0.
- ^ Fecha, 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 nulos hasta 1979
- ^ Date, CJ (14 de octubre de 1985). "¿Es su DBMS realmente relacional?". Computerworld .
Los valores nulos ... [deben] ser admitidos en un DBMS completamente relacional para representar información faltante e información inaplicable de una manera sistemática, independiente del tipo de datos.
(la tercera de las 12 reglas de Codd) - ^ Fecha, CJ (2007). Lo que realmente significa la primera forma normal . Fecha en la base de datos: Escritos 2000-2006 . Presione. págs. 121-126. ISBN 978-1-4842-2029-0.
Otras lecturas
- Date, CJ y Lorentzos, N. y 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 simple de cinco formas normales en la teoría de bases de datos relacionales , Communications of the ACM, vol. 26, págs. 120-125
- Codd, EF (1970). Un modelo relacional de datos para. Grandes bancos de datos compartidos. Laboratorio de Investigación de IBM, San José, California.
- Codd, EF (1971). Mayor normalización del modelo relacional. Courant Computer Science Symposium 6 in Data Base Systems editado por Rustin, R.