stringtranslate.com

Primera forma normal

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 bases de datos es el proceso de representar una base de datos en términos de relaciones en formas normales estándar, donde la primera forma normal es un requisito mínimo. SQL-92 no admite la creación o el uso de columnas con valores de tabla, lo que significa que al usar solo las "características tradicionales de las bases de datos relacionales" (excluyendo las extensiones incluso si se estandarizaron más tarde), la mayoría de las bases de datos relacionales estarán en primera forma normal por necesidad. Los sistemas de bases de datos que no requieren la primera forma normal a menudo se denominan sistemas NoSQL . Los estándares SQL más nuevos como SQL:1999 han comenzado a permitir los llamados tipos no atómicos, que incluyen tipos compuestos . Incluso las versiones más nuevas como SQL:2016 permiten JSON .

Descripción general

En una base de datos jerárquica , un registro puede contener conjuntos de registros secundarios, conocidos como grupos repetitivos o atributos con valores de tabla. Si dicho modelo de datos se representa como relaciones, un grupo repetitivo sería un atributo donde el valor es en sí mismo una relación. La primera forma normal elimina las relaciones anidadas al convertirlas en relaciones de "nivel superior" independientes asociadas con la fila principal a través de claves externas en lugar de a través de contención directa.

El objetivo de esta normalización es aumentar la flexibilidad y la independencia de los datos , y simplificar el lenguaje de los datos. También abre la puerta a una mayor normalización, que elimina la redundancia y las anomalías.

La mayoría de los sistemas de gestión de bases de datos relacionales no admiten registros anidados, por lo que las tablas se presentan en la primera forma normal de forma predeterminada. En particular, SQL no tiene ninguna función para crear o explotar tablas anidadas. Por lo tanto, la normalización a la primera forma normal sería un paso necesario al trasladar datos de una base de datos jerárquica a una base de datos relacional.

Razón fundamental

La justificación para normalizar a 1NF: [2]

Desventajas y críticas

Historia

La primera forma normal fue introducida en 1970 por Edgar F. Codd en el artículo A Relational Model of Data for Large Shared Data Banks (Un modelo relacional de datos para grandes bancos de datos compartidos ), aunque inicialmente se la llamó simplemente "forma normal". Se le cambió el nombre a "primera forma normal" cuando se introdujeron formas normales adicionales en el artículo Further Normalization of the Relational Model (Normalización adicional del modelo relacional) en 1971. [3]

Ejemplos

Los siguientes escenarios ilustran primero cómo un diseño de base de datos podría violar la primera forma normal, seguido de ejemplos que la cumplen.

Diseños que violan la 1NF

Esta tabla sobre las transacciones con tarjetas de crédito de los clientes no se ajusta a la primera forma normal:

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:

  1. Descomprimir uno o más grupos de transacciones de clientes, lo que permite examinar las transacciones individuales de un grupo, y
  2. Derivación de 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 Transacciones de cada cliente y 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 más importantes de Codd fue que la complejidad estructural se puede reducir. La reducción de la complejidad estructural brinda a los usuarios, las aplicaciones y los 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 una 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 hacen referencia a la clave principal de la relación que las contenía. El proceso se puede aplicar de forma recursiva a dominios no simples anidados en múltiples niveles. [4]

En este ejemplo, el ID del cliente es la clave principal de las relaciones que lo contienen y, por lo tanto, se agregará como clave externa a la nueva relación:

En la estructura modificada, la clave principal es {ID de cliente} en la primera relación y {ID de cliente, ID de transacción} en la segunda relación.

Ahora, cada fila representa una transacción individual con tarjeta de crédito y el DBMS puede obtener la respuesta de interés simplemente buscando todas las filas con una fecha correspondiente al mes de octubre y sumando sus importes. La estructura de datos coloca todos los valores en igualdad de condiciones, exponiendo cada uno de ellos directamente al DBMS, de modo que cada uno puede participar potencialmente de manera directa en las consultas; mientras que en la situación anterior algunos valores estaban integrados 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 de modo que lo que una parte significa para el DBMS dependa 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 debe entenderse la 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:

La fecha 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, la 1NF no puede definirse con referencia a la atomicidad. Las columnas de cualquier tipo de datos concebible (desde tipos de cadena y tipos numéricos hasta tipos de matriz y tipos de tabla) son entonces aceptables en una tabla 1NF, aunque quizás no siempre sea deseable; por ejemplo, puede ser más deseable separar una columna de Nombre de 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 sólo si es " isomorfa a alguna relación", lo que significa, específicamente, que satisface las siguientes cinco condiciones: [11]

  1. No hay un orden de arriba a abajo en las filas.
  2. No hay orden de izquierda a derecha en las columnas.
  3. No hay filas duplicadas.
  4. Cada intersección de fila y columna contiene exactamente un valor del dominio aplicable (y nada más).
  5. 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.

Ejemplos de tablas (o vistas ) que no cumplirían con esta definición de primera forma normal son:

Referencias

  1. ^ Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM. Clásicos. 13 (6): 377–87. pág. 380-381.
  2. ^ Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM. Clásicos. 13 (6): 377–87.
  3. ^ Codd, EF (1971). Normalización adicional del modelo relacional. Courant Computer Science Symposium 6 en Data Base Systems editado por Rustin, R.
  4. ^ Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM. Clásicos. 13 (6): 377–87. pág. 381
  5. ^ Codd, EF El modelo relacional para la gestión de bases de datos versión 2 (Addison-Wesley, 1990).
  6. ^ Codd, EF El modelo relacional para la gestión de bases de datos versión 2 (Addison-Wesley, 1990), pág. 6.
  7. ^ Darwen, Hugh. "Atributos con valores relacionales; o, ¿podría la primera forma normal real ponerse de pie, por favor?", en CJ Date y Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992).
  8. ^ Date, CJ (2007). Qué significa realmente la primera forma normal . Apress. p. 108. ISBN 978-1-4842-2029-0.«Durante muchos años», escribe Date, «estuve tan confundido como cualquier otra persona. Y lo que es peor, hice todo lo posible (¿lo peor?) por difundir esa confusión a través de mis escritos, seminarios y otras presentaciones». {{cite book}}: |work=ignorado ( ayuda )
  9. ^ Date, CJ (2007). Qué significa realmente la primera forma normal . Apress. p. 112. ISBN 978-1-4842-2029-0. {{cite book}}: |work=ignorado ( ayuda )
  10. ^ Date, CJ (6 de noviembre de 2015). SQL y teoría relacional: cómo escribir código SQL preciso. O'Reilly Media. pp. 50–. ISBN 978-1-4919-4115-7. Recuperado el 31 de octubre de 2018 .
  11. ^ Date, CJ (2007). Qué significa realmente la primera forma normal . Apress. págs. 127-128. ISBN 978-1-4842-2029-0. {{cite book}}: |work=ignorado ( ayuda )
  12. ^ 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.
  13. ^ Date, CJ (14 de octubre de 1985). "¿Su sistema de gestión de bases de datos es realmente relacional?". Computerworld . Los valores nulos... [deben] ser compatibles con un sistema de gestión de bases de datos totalmente relacional para representar la información faltante y la información inaplicable de manera sistemática, independientemente del tipo de datos.(la tercera de las 12 reglas de Codd)
  14. ^ Date, CJ (2007). Qué significa realmente la primera forma normal . Apress. págs. 121–126. ISBN 978-1-4842-2029-0. {{cite book}}: |work=ignorado ( ayuda )

Lectura adicional