sql - sencillos - ¿Qué pasa con una dependencia transitiva?

normalizacion de base de datos ejemplos sencillos (5)

Acabo de armar una publicación que aborda por qué las dependencias transitivas son generalmente una mala idea: http://www.essentialsql.com/get-ready-to-learn-sql-11-database-third-normal-form-explained-in-simple-english/

Tengo algunas dependencias transitivas en el diseño de mi base de datos. Mis superiores me han dicho que estos pueden causar errores. Me resulta difícil encontrar recursos que me digan cómo tener estas dependencias causará errores. ¿Qué tipo de problemas van a causar?

No discuto el hecho, solo estoy ansioso por saber qué tipo de problemas pueden causar.

Editar para más detalles:

De la wikipedia:

Dependencia transitiva
Una dependencia transitiva es una dependencia funcional indirecta, una en la que X → Z solo en virtud de X → Y e Y → Z.

Eche un vistazo a este enlace:

http://en.wikipedia.org/wiki/Transitive_dependency

Usando el ejemplo, ¿qué pasaría si actualizo la nacionalidad de Jules Verne en una fila, pero no en la otra? La nacionalidad del autor está determinada solo por el autor, no por la combinación de libro y autor. Entonces, con la estructura de datos de ejemplo, podría solicitarle a la base de datos la nacionalidad de Julio Verne. Si ejecuté el siguiente comando SQL

SELECCIONAR TOP 1 author_nationality FROM books WHERE autor = ''Julio Verne''

Podría obtener una respuesta diferente dependiendo de cómo la base de datos selecciona TOP 1.

Explicaré con un ejemplo:

------------------------------------------------------------------- | Course | Field | Instructor | Instructor Phone | ------------------------------------------------------------------- | English | Languages | John Doe | 0123456789 | | French | Languages | John Doe | 0123456789 | | Drawing | Art | Alan Smith | 9856321158 | | PHP | Programming | Camella Ford | 2225558887 | | C++ | Programming | Camella Ford | 2225558887 | -------------------------------------------------------------------

Si tienes un Course , puedes obtener fácilmente su Instructor para Course ->Instructor .
Si tienes un Instructor no puedes obtener su Course ya que podría estar enseñando diferentes cursos.
Si tiene un Instructor , puede obtener fácilmente su Phone para Instructor->Phone .

Eso significa que si tienes un Course entonces puedes obtener el Instructor Phone del Instructor Phone que significa Course ->Instructor Phone (es decir, dependencia Transitiva)

Ahora para los problemas:

Si elimina los cursos de French e English , también eliminará su instructor John Doe y su número de teléfono se perderá para siempre.
No hay forma de agregar un nuevo Instructor a su base de datos a menos que primero le agregue un Course , o puede duplicar los datos en una Instructors table que es aún peor.
Si el Instructor John Doe cambia su número de teléfono, deberá actualizar todos los Cursos que enseñe con la nueva información que puede ser muy propensa a cometer errores.
No puede eliminar un Instructor de su base de datos a menos que elimine todos los cursos que enseña o configure todos sus campos como nulos.
¿Qué sucede si decide mantener la fecha de nacimiento de sus instructores? Deberá agregar un campo Birth Date a la tabla Courses . ¿Esto suena lógico? Por qué mantener la información de un instructor en la tabla de cursos en primer lugar.

Si hay dependencias transitivas en su tabla, entonces no es compatible con 3NF; entonces hay una alta probabilidad de que haya datos redundantes en su tabla. Verifique this para aclarar este concepto.

Una forma de expresar el 3NF es:

Todos los atributos deben depender de la clave, la clave completa y nada más que la clave.

La dependencia transitiva X-> Y-> Z viola ese principio, lo que lleva a redundancia de datos y posibles anomalías de modificación.

Vamos a desglosar esto:

Por definición , para una dependencia funcional X-> Y-> Z para que también sea transitiva , la X <-Y no se debe mantener.
Si Y fuera una clave, la X <-Y se mantendría, entonces Y no puede ser una clave. (FOOTNOTE1)
Como Y no es una clave, cualquier Y dada se puede repetir en múltiples filas.
La Y-> Z implica que todas las filas que tienen la misma Y también deben contener la misma Z. (FOOTNOTE2)
Repetir la misma tupla (Y, Z) en varias filas no aporta ninguna información útil al sistema. Es redundante

En resumen, dado que Y no es una clave y Y-> Z, hemos violado el 3NF.

Las redundancias conducen a anomalías de modificación (por ejemplo, actualizar algunas pero no todas las Z "conectadas" a la misma Y esencialmente corrompe los datos, ya que usted ya no sabe qué copia es la correcta). Esto normalmente se resuelve al dividir la tabla original en dos tablas, una que contiene {X, Y} y la otra que contiene {Y, Z}. De esta manera, Y puede ser una clave en la segunda tabla y Z no se repite.

Por otro lado, si X <-Y se mantiene (es decir, X-> Y-> Z no es transitivo), entonces podemos retener una sola tabla, donde tanto X como Y son claves. Z no se repetirá innecesariamente en este escenario.

(FOOTNOTE1) Una clave es un conjunto (mínimo) de atributos que determinan funcionalmente todos los atributos en una relación. Justificación: si K es una clave, no puede haber varias filas con el mismo valor de K, por lo que cualquier valor dado de K siempre está asociado a un valor exacto de cada otro atributo (suponiendo 1NF). Por definición (ver FOOTNOTE2), "estar asociado a uno precisamente" es lo mismo que "estar en una dependencia funcional".

(FOOTNOTE2) Por definición , Y-> Z si, y solo si, cada valor Y se asocia con precisamente un valor Z.

Ejemplo:

Suponiendo que cada mensaje tiene exactamente un autor y cada autor tiene exactamente un correo electrónico principal, intentar representar mensajes y usuarios en la misma tabla provocaría la repetición de correos electrónicos:

MESSAGE USER EMAIL ------- ---- ----- Hello. Jon [email protected] Hi, how are you? Rob [email protected] Doing fine, thanks for asking. Jon [email protected]

(En realidad, estos serían MESSAGE_ID s, pero permítanos mantener las cosas simples aquí.)

Ahora, ¿qué sucede si Jon decide cambiar su correo electrónico a, por ejemplo, "[email protected]"? Tendríamos que actualizar ambas filas de Jon. Si solo actualizamos uno, entonces tenemos la siguiente situación ...

MESSAGE USER EMAIL ------- ---- ----- Hello. Jon [email protected] Hi, how are you? Rob [email protected] Doing fine, thanks for asking. Jon [email protected]

... y ya no sabemos cuál de los correos electrónicos de Jon es correcto. ¡Hemos perdido esencialmente los datos!

La situación es especialmente mala ya que no existe una restricción declarativa que podamos utilizar para obligar al SGBD a aplicar ambas actualizaciones para nosotros. El código del cliente tendrá errores y probablemente esté escrito sin tener en cuenta las complejas interacciones que pueden ocurrir en el entorno concurrente.

Sin embargo, si divide la mesa ...

MESSAGE USER ------- ---- Hello. Jon Hi, how are you? Rob Doing fine, thanks for asking. Jon USER EMAIL ---- ----- Jon [email protected] Rob [email protected]

... ahora solo hay una fila que conoce el correo electrónico de Jon, por lo que la ambigüedad es imposible.

Por cierto, todo esto puede verse como una expresión más del principio DRY .