Primera forma normal

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 atributos tiene relaciones como elementos. O, de manera más informal, que ninguna columna de tabla puede tener tablas como valores (o sin grupos repetidos). 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 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 el uso exclusivo de las "características tradicionales de la base de datos relacional" (excluyendo las extensiones, incluso si se estandarizaron más tarde), la mayoría de las bases de datos relacionales estarán en su 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.

Resumen

En una base de datos jerárquica, un registro puede contener conjuntos de registros secundarios, conocidos como grupos repetidos 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 en sí mismo es una relación. La primera forma normal elimina las relaciones anidadas convirtiéndolas en relaciones separadas de "nivel superior" relaciones asociadas con la fila principal a través de claves foráneas en lugar 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 datos. También abre la puerta a una mayor normalización, lo 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 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.

Fundamento

La justificación para normalizar a 1NF:

• Permite presentar, almacenar e intercambiar datos relacionales en forma de arrays bidimensionales regulares. Apoyar las relaciones anidadas requeriría estructuras de datos más complejas.
• Simplifica el lenguaje de datos, ya que cualquier elemento de datos puede ser identificado sólo por nombre de relación, nombre de atributo y clave. Apoyar las relaciones anidadas requeriría un lenguaje más complejo con el apoyo de rutas jerárquicas de datos para abordar los elementos de datos anidados.
• Representar relaciones usando claves extranjeras es más flexible, donde un modelo jerárquico sólo puede representar una a muchas relaciones.
• Dado que la localización de elementos de datos no se asocia directamente a la jerarquía entre padres e hijos, la base de datos es más resistente a los cambios estructurales a lo largo del tiempo.
• Hace posible un mayor nivel de normalización que elimina la redundancia de datos y anomalías.

Inconvenientes y críticas

• Ejecución para ciertas operaciones. En un modelo jerárquico, los registros anidados se almacenan físicamente después del registro de los padres, lo que significa que un subárbol entero se puede recuperar en una sola operación de lectura. En un formulario 1NF, necesitará una operación de unión por tipo de registro, que puede ser costoso, especialmente para árboles complejos. Por esta razón, las bases de datos de documentos eschew 1NF.
• Los lenguajes orientados a objetos representan el estado del tiempo de ejecución como árboles o gráficos dirigidos de objetos conectados por punteros o referencias. This does not map cleanly to a 1NF relational database, a problem sometimes called the Object-Relational Impedance Mismatch and which ORM library try to bridge.
• 1NF ha sido interpretado como no permitir tipos complejos de datos para valores. Esto está abierto a la interpretación, sin embargo, y C.J.Date ha argumentado que los valores pueden ser objetos arbitrariamente complejos.

Historia

La primera forma normal fue presentada por E. F. Codd en el documento "Un modelo relacional de datos para grandes bancos de datos compartidos", aunque inicialmente solo se llamó "Forma normal". Se le cambió el nombre a "Primera forma normal" cuando se introdujeron formas normales adicionales en el documento Mayor normalización del modelo relacional

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 cumplen.

Diseños que violan 1NF

Esta mesa sobre los clientes' las transacciones con tarjeta de crédito no se ajustan a la primera forma normal:

A cada cliente le corresponde un 'grupo repetido' de transacciones Dicho 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 los clientes' Las transacciones implicarían en términos generales dos etapas:

1. Desembalaje de uno o más grupos de transacciones de clientes que permiten examinar las transacciones individuales en un grupo, y
2. Conducir 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 debería saber que primero debe desempaquetar el grupo Transacciones de cada cliente, luego sume los Importes 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 la complejidad estructural se puede reducir. 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 foráneas que hacen referencia a la clave principal de la relación que las contenía. El proceso se puede aplicar recursivamente a dominios no simples anidados en múltiples niveles.

En este ejemplo, 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:

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 montos. La estructura de datos coloca todos los valores en pie de igualdad, exponiendo cada uno directamente al DBMS, por lo que potencialmente cada uno puede 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.

Cabe 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." Codd define un valor atómico como uno que "el DBMS no puede descomponer en partes más pequeñas (excluyendo ciertas funciones especiales)" lo que significa que una columna no debe dividirse en partes con más de un tipo de datos, de modo que lo que significa una parte 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 debe entenderse 1NF. En particular, la noción de un "valor que no se puede descomponer" es problemático, 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 a los operadores para descomponerla en subestrings.
• Un número de puntos fijos parece no ser atómico, ya que el RDBMS normalmente proporciona a los operadores para descomponerlo en componentes enteros y fraccionados.
• Un ISBN parece no ser atómico, ya que incluye el identificador de lenguaje y editor.

La fecha sugiere que "la noción de atomicidad no tiene un significado absoluto": un valor puede considerarse atómico para algunos propósitos, pero puede considerarse un conjunto de elementos más básicos para otros fines. Si se acepta esta posición, 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 aceptables en una tabla 1NF, aunque tal vez no siempre sean deseables; por ejemplo, puede ser más conveniente separar una columna de 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 cumple las siguientes cinco condiciones:

1. No hay orden de arriba a abajo en las filas.
2. No hay orden de izquierda a derecha a 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 los IDs de fila, los IDs de objetos o los horarios ocultos].

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 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 limitación clave única. Tal tabla sería capaz de acomodar filas duplicadas, en violación de la condición 3.
• A view whose definition mandates that results be returned in a particular order, so that the row-ordering is an intrinsic and meaningful aspect of the view. (Estas vistas no se pueden crear usando SQL que se ajusta al estándar SQL:2003). Esto viola la condición 1. Los tuples en las relaciones verdaderas no se ordenan con respecto a uno al otro.
• Una tabla con al menos un atributo nullable. Un atributo nullable estaría en violación de 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 polémico. Marca una importante salida de la visión posterior de Codd del modelo relacional, que hizo provisión explícita para nulos. Primera forma normal, definida por Chris Date, permite atributos valorados en relación (cuadros dentro de tablas). La fecha argumenta que los atributos valorados en relación, por medio de los cuales una columna dentro de una tabla puede contener una tabla, son útiles en casos raros.