Este post ha sido aprobado por nuestros especialistas así se garantiza la veracidad de nuestra esta reseña.
Solución:
Lo 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
Coursepuedes conseguirlo fácilmenteInstructorasi queCourse->Instructor. - Si tienes un
Instructorno puedes conseguir el suyoCourseya que podría estar impartiendo diferentes cursos. - Si tienes un
Instructorpuedes conseguir fácilmente suPhoneasi queInstructor->Phone.
Eso significa que si tienes un Course entonces puedes conseguir el Instructor Phone lo que significa Course->Instructor Phone (es decir, dependencia transitiva)
Ahora para los problemas:
- Si elimina tanto el
FrenchyEnglishcursos, entonces eliminarás su instructorJohn Doetambién y su número de teléfono se perderá para siempre. - No hay forma de agregar un nuevo
Instructora su base de datos a menos que agregue unCoursepara él primero, o puede duplicar los datos en unInstructors tableque es aún peor. - Si Instructor
John Doecambia su número de teléfono, entonces tendrás que actualizar todos los cursos que enseña con la nueva información que puede ser muy propensa a errores. - No puede eliminar un instructor de su base de datos a menos que elimine todos los cursos que imparte o establezca todos sus campos en null.
- ¿Qué pasa si decide mantener la fecha de nacimiento de sus instructores? Tendrás que agregar un
Birth Datecampo alCoursesmesa. ¿Suena esto siquiera lógico? ¿Por qué mantener la información de un instructor en la tabla de cursos en primer lugar?
Una forma de expresar el 3NF es:
Todos attributes debería depender de la key, entero key y nada más que el key.
La dependencia transitiva X-> Y-> Z viola ese principio, lo que genera redundancia de datos y posibles anomalías de modificación.
Analicemos esto:
- Por definición, para un funcional dependencia X-> Y-> Z para ser también transitivo, el X <-Y debe no sostener.
- Si Y fuera un key, el X <-Y se mantendría, por lo que Y no puede ser un key. (NOTA AL PIE 1)
- Dado que Y no es un key, cualquier Y puede repetirse en varias filas.
- Y-> Z implica que todas las filas que tienen la misma Y también deben tener la misma Z. (NOTA AL PIE 2)
- Repitiendo el mismo La tupla (Y, Z) en varias filas no aporta ninguna información útil al sistema. Está redundante.
En resumen, dado que Y no es un key e Y-> Z, hemos violado la 3NF.
Las redundancias dan lugar a anomalías de modificación (por ejemplo, actualización de algunos pero no todos de las Z “conectadas” a la misma Y esencialmente corrompe los datos, ya que ya no sabe qué copia es correcta). Por lo general, esto se resuelve dividiendo la tabla original en dos tablas, una que contiene X, Y y la otra que contiene Y, Z. De esta manera, Y puede ser un key en la segunda tabla y Z no se repite.
Por otro lado, si la X<-Y does hold (i.e. X->Y-> Z no es transitivo), entonces podemos retener una sola tabla, donde tanto X como Y son keys. Z no se repetirá innecesariamente en este escenario.
(NOTA AL PIE1) A key es un conjunto (mínimo) de attributes que determinan funcionalmente todos los attributes en una relacion. Justificación: si K es un key, no puede haber varias filas con el mismo valor de K, por lo que cualquier valor dado de K siempre está asociado precisamente a un valor de todos los demás attribute (asumiendo 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 de Y está asociado precisamente con un valor de 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 conduciría 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_IDs, pero mantengamos las cosas simples aquí).
Ahora, ¿qué sucede si Jon decide cambiar su correo electrónico a, digamos, “[email protected]”? Necesitaríamos actualizar ambos de las 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 el correcto. ¡Básicamente hemos perdido los datos!
La situación es especialmente mala ya que no hay ninguna restricción declarativa que podamos utilizar para obligar al DBMS a que nos aplique ambas actualizaciones. El código de cliente voluntad tiene errores y probablemente esté escrito sin tener en cuenta las interacciones complejas 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 sabe sobre 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.
Si hay dependencias transitivas en su tabla, entonces no es compatible con 3NF; por lo que existe una alta probabilidad de que haya datos redundantes en su tabla. Marque esto para aclarar este concepto.