Estoy tratando de obtener una versión definitiva de lo que es la primera forma normal. Todo lo que leo tiene un giro ligeramente diferente.

Muchas autoridades, como Fecha, dicen que, por definición, una relación siempre está en Primera forma normal, mientras que otras dan una lista de requisitos. Esto significa que hay de cero a muchos requisitos para 1NF.

Supongo que la diferencia es que entre tablas y relaciones: las tablas pueden ser un completo desastre, mientras que una relación sigue ciertas restricciones. El hecho de que una relación se represente como una tabla en SQL crea cierta confusión.

Me estoy centrando específicamente en 1NF en lo que se refiere a bases de datos SQL. La pregunta es: ¿qué propiedades son necesarias para garantizar que una tabla esté en la primera forma normal?

Muchas autoridades sugieren que si una tabla representa una relación , entonces ya está en 1NF. Esto empuja la definición de 1NF a la definición de una relación.

Estas son algunas propiedades de una tabla en 1NF:

• El orden de las columnas es insignificante [1]
• El orden de las filas es insignificante
• Todas las filas tienen la misma longitud (es decir, los datos de la fila coinciden con los encabezados de las columnas)
• No hay filas duplicadas (esto se puede garantizar con una clave primaria sustituta, pero la PK no es necesaria)
• No hay columnas repetidas.
• Cada columna contiene un solo valor (atómico)

[1] Técnicamente, los atributos no están ordenados, pero en una tabla, los datos de la fila deben estar en el mismo orden que los encabezados de columna. Sin embargo, el orden real es insignificante.

En múltiples datos :

El concepto de datos atómicos es que un elemento no puede desglosarse aún más. Este concepto ha sido calificado porque, aunque técnicamente todo se puede desglosar ad nauseum , los datos en cuestión no se pueden desglosar prácticamente más, dependiendo de cómo se usarán los datos.

Por ejemplo, una dirección completa o un nombre completo normalmente deberían desglosarse aún más, pero los componentes como el nombre de pila o el nombre de la ciudad probablemente no deberían desglosarse más, a pesar de que pueden ser cadenas.

En cuanto a las columnas repetidas, es una columna de diseño pobre tener columnas casi repetidas, como phone1, phone2etc. En general, los datos repetidos indican la necesidad de una tabla relacionada adicional.

Dependencia

No debería haber ninguna relación entre filas, aparte de que se ajustan a los mismos encabezados.

Tampoco debería haber relación entre columnas, pero creo que es el tema de formas normales más altas.

La pregunta es: ¿cuánto de lo anterior está en la definición de 1NF? ¿Las filas independientes también entran en juego?

Preliminar

La definición de forma normal (que a partir de la presentación de "Normalización adicional del modelo relacional de la base de datos" en 1971 se conoce como la primera forma normal ) y la definición del paradigma relacional en sí se publicó en 1970 en el artículo científico que proporcionó un fuerte base para la práctica de la administración de bases de datos, es decir, "Un modelo relacional de datos para grandes bancos de datos compartidos" (RM por brevedad) creado por el Dr. EF Codd , quien es un receptor del Premio Turing y la autoridad con respecto al marco relacional.

Sí, hay muchas explicaciones, interpretaciones, exposiciones, desviaciones y opiniones sobre el texto del Dr. Codd, pero personalmente prefiero seguir con la fuente original y le sugiero que lo analice usted mismo para poder sacar sus propias conclusiones.

Ciertamente no entiendo el RM en su totalidad, pero lo que sí entiendo me permite apreciar su excelencia, visión, intención y alcance, y aunque décadas después uno puede notar que tiene algunas pequeñas imprecisiones, no reducen, de ninguna manera, su genio y elegancia. En su campo, el RM ha resistido la prueba del tiempo de una manera única, y sigue siendo inigualable.

El acto de enfatizar las imprecisiones antes mencionadas sería —utilizando un término caritativo— injusto porque, viéndolo desde una distancia considerable, este material seminal requería algunos refinamientos y extensiones, sí, pero el cuerpo principal del trabajo era sólido como una roca. misma concepción (y, de hecho, el Dr. Codd hizo la mayoría, si no todos, de tales refinamientos y extensiones él mismo).

Continúo releyendo el RM constantemente para fortalecer mi comprensión de esta fuente excepcional de conocimiento (y mi estima sigue creciendo en cada lectura); El objetivo es pararse sobre los hombros de gigantes.

Relaciones y mesas

Es importante tener en cuenta que, como las relaciones son recursos abstractos , el Dr. Codd imaginó la utilidad de representarlos en forma tabular (inicialmente utilizó el término "representación de matriz", pero luego utilizó "tabla" o "tabla r"), de modo que Los usuarios, diseñadores y administradores de una base de datos relacional (RDB) pueden acercarse a ellos de una manera más familiar o concreta . Por lo tanto, dentro del contexto de una implementación de RDB, es válido usar la tabla como una forma abreviada de relación, siempre que dicha tabla represente una relación real. Esta característica es, aunque obvia, bastante significativa porque antes de evaluar si una tabla representa o no una relación que cumple con la primera forma normal (1NF), tiene que representar, precisamente, una relación.

El RM contiene naturalmente las cualidades que una tabla debe tener para determinar si en realidad retrata una relación, pero ofreceré una interpretación informal y sin pretensiones sobre ellos aquí (¡otra, sí!):

• Debe tener un nombre (cada relación particular en una estructura de base de datos debe distinguirse del resto).
• Cada una de sus filas debe representar exactamente una tupla de la relación pertinente.
• El orden de sus filas no es importante en absoluto.
• Cada una de sus columnas debe tener un nombre que represente el significado de exactamente un dominio de la relación en cuestión, y dicho nombre debe ser diferente del nombre del resto de las columnas de la tabla (una columna debe diferenciarse de manera única y debe llevar un significado distintivo y, sí, el papel desempeñado por un modelador de bases de datos y los expertos empresariales para definir cada dominio de importancia con precisión es primordial)
• El orden de sus columnas no tiene importancia.
• Todas sus filas deben tener el mismo número de columnas.
• Debe tener al menos una columna, o una combinación de columnas, que identifique de manera única cada una de las tuplas representadas a través de filas; de esta manera, todas las filas deben ser diferentes (sí, esto enfatiza la importancia de tener al menos una CLAVE declarada, y cuando hay dos o más CLAVES, una debe definirse como PRIMARIA en función de razones pragmáticas, mientras que el resto puede ser considerado como ALTERNATIVO, pero sí, antes de tomar la decisión, cada una de las CLAVES era un "candidato" para una definición como PRIMARIA).

Tener una tabla que en realidad represente una relación es fundamental ya que, cuando se somete a operaciones de manipulación de tipo relacional, el resultado es, nuevamente, una tabla que representa una relación. De esta manera, el comportamiento de dicha tabla es predecible .

Dominios atómicos (columnas)

En las primeras secciones del RM, el Dr. Codd presenta varias muestras de relaciones para introducir algunos conceptos; entonces, para comprender el significado del dominio atómico , comencemos con el siguiente extracto del RM que detalla algunos puntos pertinentes:

Hasta ahora, hemos discutido ejemplos de relaciones que se definen en dominios simples, dominios cuyos elementos son valores atómicos (no descomponibles). Los valores no atómicos pueden discutirse dentro del marco relacional. Por lo tanto, algunos dominios pueden tener relaciones como elementos. Estas relaciones pueden, a su vez, definirse en dominios no simples, y así sucesivamente.

De esta manera, se puede decir que cada una de las relaciones expositivas mencionadas anteriormente se ajusta a uno de dos tipos, digamos tipo A o tipo B :

• La clase A agrupa solo relaciones (tablas) que están estructuradas con dominios (columnas) que contienen valores exclusivamente simples en cada una de sus tuplas (filas), es decir, dichos dominios (columnas) no contienen relaciones (tablas) como valores, que en Este contexto significa que los valores son atómicos porque no pueden descomponerse sucesivamente en nuevas relaciones (tablas). Por lo tanto, las relaciones de esta clase son las que están normalizadas , es decir, cumplen con 1NF, su forma es deseable.

• Tipo B está integrado exclusivamente por las relaciones (tablas) que tienen uno o más dominios (columnas) que las relaciones de retención como valores en cada tupla correspondiente (fila), y eso significa que dichos valores son no atómica ya que pueden ser posteriormente degradados en nuevas relaciones (tablas), es decir, son descomponibles . Por lo tanto, las relaciones de este tipo no están normalizadas, es decir, infringen 1NF, están en una forma indeseable.

Normalización

El Dr. Codd presenta la sección sobre normalización en el RM con el siguiente párrafo:

Una relación cuyos dominios son todos simples puede representarse en el almacenamiento mediante una matriz bidimensional de columna homogénea del tipo discutido anteriormente. Se necesita una estructura de datos más complicada para una relación con uno o más dominios no simples. Por esta razón (y otras que se citarán a continuación), parece que vale la pena investigar la posibilidad de eliminar dominios no simples. De hecho, hay un procedimiento de eliminación muy simple, que llamaremos normalización.

Luego pasa a mostrar:

1. Un grupo de relaciones donde uno no está normalizado (tiene dominios que contienen relaciones como valores, es decir, no son atómicas; es decir, no son simples)

2. Un grupo de relaciones que están normalizadas (es decir, una que se descompuso; es decir, una relación de dominios valorados se desglosó en simples que significa que son atómicos)

Y luego describe el procedimiento para obtener relaciones normalizadas de relaciones no normalizadas.

A este respecto, las relaciones que empleó para ilustrar un ejercicio de normalización y la descripción del ejercicio en sí son bastante claras, y le recomiendo nuevamente que las analice usted mismo (y espero que esto anime a algunos lectores a involucrarse con el texto).

Sucesivamente, él indica:

Son posibles operaciones adicionales de tipo normalizador. Estos no se discuten en este documento.

Y dichas operaciones, es decir, la segunda y tercera forma normal (2NF y 3NF) se detallan realmente en "Normalización adicional del modelo relacional de la base de datos", y como se mencionó anteriormente, después de la presentación (y la posterior impresión y publicación) de este documento , la forma normal original se conoció como primera forma normal.

Como puede observar un profesional, tener relaciones no normalizadas (tablas) introduce una convolución (casi siempre innecesaria) en las implementaciones de RDB.

Una relación que satisface 1NF facilita la definición de restricciones y operaciones de manipulación de datos que pueden implementarse mediante un sublenguaje de datos que es menos complejo que el requerido para las relaciones no normalizadas (tablas), como señala el Dr. Codd en las siguientes líneas:

La adopción de un modelo relacional de datos, como se describió anteriormente, permite el desarrollo de un sublenguaje universal de datos basado en un cálculo predicado aplicado. Un cálculo de predicado de primer orden es suficiente si la colección de relaciones está en forma normal. Tal lenguaje proporcionaría un criterio de poder lingüístico para todos los demás lenguajes de datos propuestos, y sería en sí mismo un fuerte candidato para incrustar (con la modificación sintáctica apropiada) en una variedad de lenguajes host (programación, comando u orientado a problemas). [...]

[...]

La universalidad del sublenguaje de datos radica en su capacidad descriptiva (no en su capacidad informática).

El desconcierto

Desde mi punto de vista, el desconcierto ha surgido, debido a (a) el exceso antes mencionado de interpretaciones, explicaciones, etc., acerca de 1NF y el propio RM, y debido a (b) nuevos intentos de redefinir 1NF ese estado que tiene relaciones con dominios que contienen valores que, a su vez, las relaciones cumplen con 1NF siempre que sean un solo valor para cada tupla correspondiente.

Mi opinión sobre tus otros puntos

No debería haber ninguna relación entre filas, aparte de que se ajustan a los mismos encabezados.

No estoy seguro si entiendo la intención de esa declaración correctamente, pero, además de cumplir con los mismos encabezados, debe haber una conexión entre las filas (tuplas) de una relación (tabla) ya que cada una de ellas debería ser una afirmación sobre un ocurrencia particular del tipo de entidad específica (definida en términos del contexto comercial de interés) que se supone que representa la relación (tabla).

Tampoco debería haber relación entre columnas, pero creo que es el tema de formas normales más altas.

No sé si estoy interpretando correctamente el significado de esa declaración tampoco, pero, de hecho, y de acuerdo con mi respuesta al aspecto anterior, también debe haber una relación entre los dominios (columnas) de una relación (tabla) , que es precisamente por qué es una relación (la estructura esencial del modelo relacional y de una implementación concreta de RDB).

Para ejemplificar, con respecto a la relación hipotética (tabla)

• Salary (PersonNumber, EffectiveDate, Amount)

la tupla (fila)

• Salary (x, y, z)

transmitiría el significado

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Por lo tanto, cada tupla (fila) de la Salaryrelación (tabla) debe encajar en la estructura de la afirmación que se muestra arriba, y la diferencia sería el reemplazo de los valores de dominio (columna) pertinentes, pero debe existir una relación entre (a) todos los Salarydominios (columnas) y también entre (b) todos sus valores correspondientes con respecto a cada tupla (fila); Tal relación es indispensable.

Las formas normales más altas (2NF y 3NF) son útiles para deshacerse de las dependencias funcionales entre dominios (columnas) de una relación (tabla), ayudan a evitar conexiones indeseables entre dominios (columnas), ya que dichas conexiones indeseables permiten la introducción de anomalías de actualización . Tanto 2NF como 3NF son útiles para probar la solidez de la estructura de las relaciones (tablas) en una determinada implementación de RDB.

Una ilustración. Tome una cadena de texto que contenga una dirección típica de EE. UU .:

"123 Cornhusk Rd., South Succotash, NY 12345"

Escribir una consulta para encontrar a todos los residentes de Cornhusk Road o un residente particular de la ciudad de South Succotash o el estado de Nueva York sería una tarea desalentadora. Particularmente cuando tiene las siguientes cadenas en los datos:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Cada uno de estos especifica la misma dirección real (y esto ni siquiera considera posibles errores ortográficos como "Succatash"), pero escribir el algoritmo para compararlos con éxito es algo a lo que NO me gustaría dedicar mis últimos años restantes en esta Tierra.

Ingrese la primera forma normal. No entraré en detalles sobre cómo se hace, solo considere una forma común como se ve en la mayoría de las bases de datos:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Esto no es una normalización completa. Por ejemplo, podría dividir aún más Street en StreetNum y StreetName, pero esto es lo suficientemente lejos como para una ilustración simple y realmente es lo más lejos que se lleva el proceso de normalización en la vida real. Todavía hay un pequeño problema de encontrar a todos los residentes de Cornhusk Road, pero si buscas en la calle la subcadena "Cornhusk" y hay una ciudad llamada Cornhusk en algún lugar, al menos eso no causaría confusión.

El problema con la definición proporcionada por Date, et al, es que no pueden mirar dentro de un dato y no consideran el significado de esos datos. No es que los culpe particularmente, puede ser bastante difícil.

Entonces tenemos que tomar una "cadena de caracteres" y convertirla en una "dirección". Pero proponer una definición de dirección que lo incluya todo no es tan simple como parece. Especialmente cuando se trabaja con direcciones en más de un país.

Primero, arreglamos el contexto. Nada tiene sentido sin contexto. Nuestro contexto aquí es la dirección . Dentro de ese contexto, podemos ver partes de los datos que tienen significados específicos, como Calle , Ciudad , etc. Asignamos a cada significado un campo separado.

La parte difícil es que los datos, como las palabras, pueden tener diferentes significados para diferentes personas o algunas personas pueden ver el significado donde otros no. Puede ser un proyecto en sí mismo y requerir una gran cantidad de esfuerzo cooperativo. Pero es un elemento crítico en el buen diseño de la base de datos.

El punto de normalización es eliminar o al menos minimizar los datos anómalos . Considere el hecho de que, en la tabla anterior, se puede ingresar un código de ciudad o código postal que no existe en el estado seleccionado. O una calle ingresada que en realidad no existe en la ciudad seleccionada. Ah, pero ahora estamos llegando a la segunda y tercera forma normal y ese es otro tema.

Piense en 1NF como una introducción al concepto matemático de las relaciones, en lugar de una estructura de datos particular o un conjunto fijo de reglas. Las estructuras matemáticas como las relaciones se pueden representar de diferentes maneras: las tablas son solo una de las formas más convenientes. Cuando se usan tablas, existen restricciones para garantizar que representen claramente sus relaciones previstas y que las operaciones en las tablas sean lógicamente sólidas con respecto a las relaciones representadas.

Cuando decimos que el orden y la duplicación de columnas y filas son insignificantes, esto es para asegurar que toda la información significativa se registre como valores en la tabla y sea accesible para nuestras consultas, y no se codifique en la presentación de la tabla. Si bien pocos autores, si es que hay alguno, han prohibido explícitamente el uso del color en las tablas, comprender el propósito de las restricciones anteriores nos llevaría a excluir de manera similar el uso de colores de presentación significativos para que los valores de color significativos tengan que registrarse explícitamente. La fecha y otros autores también desprecian los identificadores de fila ocultos por la misma razón.

El concepto de atomicidad se trata de garantizar que toda la estructura significativa se exprese como relaciones, de modo que podamos analizar las dependencias en todos nuestros datos y prevenir anomalías, y para que toda estructura significativa sea accesible de manera uniforme para las operaciones relacionales. Los valores compuestos no son inválidos, pero requieren que los operadores específicos del dominio se descompriman, lo que aumenta la complejidad y pueden introducir redundancia. Por supuesto, en la práctica, algunos tipos compuestos simples y operadores asociados son convenientes y ayudan a aumentar la compacidad y la expresividad de las consultas, pero esto no contradice la teoría.

Las dependencias de fila como las dependencias de valores múltiples no violan 1NF, pero al igual que las dependencias entre columnas, son objeto de formas normales más altas. Casi columnas repitiendo como phone1, phone2, etc no violan 1NF tampoco, a pesar de que están mal diseño.

La definición y explicación de WikiPedia sobre 1NF, creo que es bastante buena. - joanolo

Ampliando una frase en el artículo de Wikipedia:

Visto como números de teléfono, el texto no es atómico

Esto puede darle una idea de por qué hay tanta confusión. Si esto es solo una gota de texto, entonces es atómico. Pero si se ve como números de teléfono, entonces no es atómico. Date y otros eluden este problema. Tiene que ver con lo que significan los datos. Cuando analiza el tema, debe lidiar con lo que significan los datos.

Si hay algún punto para desglosarlo aún más es relevante para la pregunta de si se ha cumplido la primera forma normal. El punto detrás de 1NF es proporcionar acceso con clave a todos los datos. Pero si lo que recupera mediante acceso con clave tiene subestructura, entonces no tiene acceso con clave a la subestructura. - Walter Mitty

"1NF" se usa para significar un montón de cosas diferentes , muchas de las cuales son al mismo tiempo sin sentido y comunes. Vea mi respuesta a "Normalización en el sistema de gestión de bases de datos" , incluidos sus enlaces. Una de esas es mi respuesta a "¿Qué es la atomicidad en dbms" . (Ambos en Stack Overflow.) - philipxy

_{Respuesta de Community Wiki creada a partir de los comentarios que quedan sobre la pregunta}