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:
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)
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)
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.
