Una dependencia transitiva en una base de datos es una relación indirecta entre valores en la misma tabla que causa una dependencia funcional. Para lograr el estándar de normalización de la Tercera Forma Normal (3NF), debe eliminar cualquier dependencia transitiva.
Por su naturaleza, una dependencia transitiva requiere tres o más atributos (o columnas de base de datos) que tienen una dependencia funcional entre ellos, lo que significa que la columna A en una tabla se basa en la columna B a través de una columna C intermedia.
Vamos a ver cómo podría funcionar esto.
Ejemplo de dependencia transitiva
AUTORES
Autor_ID | Autor | Libro | Autoridad nacional |
---|---|---|---|
Auth_001 | Orson Scott Card | juego de Ender | Estados Unidos |
Auth_001 | Orson Scott Card | juego de Ender | Estados Unidos |
Auth_002 | Margaret Atwood | El cuento de la criada | Canadá |
En el ejemplo de AUTORES arriba:
- Libro → Autor : Aquí el Libro atributo determina el Autor atributo. Si conoce el nombre del libro, puede aprender el nombre del autor. Sin embargo, Autor no determina Libro , porque un autor puede escribir varios libros. Por ejemplo, solo porque sabemos el nombre del autor Orson Scott Card, todavía no sabemos el nombre del libro.
- Autor → Autoridad nacional : Del mismo modo, el Autor atributo determina el Autoridad nacional , pero no al revés; solo porque sabemos que la nacionalidad no significa que podamos determinar el autor.
Pero esta tabla introduce una dependencia transitiva:
- Libro → Autoridad nacional: Si conocemos el nombre del libro, podemos determinar la nacionalidad a través de la columna Autor.
Evitar las dependencias transitivas
Para asegurar la tercera forma normal, eliminemos la dependencia transitiva.
Podemos comenzar eliminando la columna Libro de la tabla Autores y creando una tabla de Libros separada:
LIBROS
Book_ID | Libro | Autor_ID |
---|---|---|
Libro_001 | juego de Ender | Auth_001 |
Libro_001 | Hijos de la mente | Auth_001 |
Book_002 | El cuento de la criada | Auth_002 |
AUTORES
Autor_ID | Autor | Autoridad nacional |
---|---|---|
Auth_001 | Orson Scott Card | Estados Unidos |
Auth_002 | Margaret Atwood | Canadá |
¿Esto lo solucionó? Examinemos nuestras dependencias ahora:
Mesa de libros:
- Book_ID → Libro: los Libro depende de Book_ID .
- No existen otras dependencias en esta tabla, así que estamos bien. Tenga en cuenta que la clave externa Autor_ID vincula esta tabla a la tabla AUTORES a través de su clave principal Autor_ID . Hemos creado una relación para evitar una dependencia transitiva, un diseño clave de bases de datos relacionales.
Tabla de autores:
- Autor_ID → Autor: los Autor depende de Autor_ID .
- Autor → Autoridad nacional: La nacionalidad puede ser determinada por el autor.
- Autor_ID → Autoridad nacional: La nacionalidad puede determinarse a partir de la Autor_ID a través de Autor atributo. Todavía tenemos una dependencia transitiva.
Necesitamos agregar una tercera tabla para normalizar estos datos:
PAÍSES
ID de país | País |
---|---|
Coun_001 | Estados Unidos |
Coun_002 | Canadá |
AUTORES
Autor_ID | Autor | ID de país |
---|---|---|
Auth_001 | Orson Scott Card | Coun_001 |
Auth_002 | Margaret Atwood | Coun_002 |
Ahora tenemos tres tablas, haciendo uso de claves foráneas para enlazar entre las tablas:
- La clave externa de la mesa LIBRO Autor_ID vincula un libro a un autor en la tabla AUTORES.
- La clave externa de la tabla AUTORES ID de país vincula un autor a un país en la tabla PAÍSES.
- La tabla PAÍSES no tiene clave externa porque no necesita vincularse a otra tabla en este diseño.
¿Por qué las dependencias transitivas son un mal diseño de la base de datos?
¿Cuál es el valor de evitar las dependencias transitivas para ayudar a garantizar 3NF? Consideremos nuevamente nuestra primera tabla y veamos los problemas que crea:
AUTORES
Autor_ID | Autor | Libro | Autoridad nacional |
---|---|---|---|
Auth_001 | Orson Scott Card | juego de Ender | Estados Unidos |
Auth_001 | Orson Scott Card | Hijos de la mente | Estados Unidos |
Auth_002 | Margaret Atwood | El cuento de la criada | Canadá |
Este tipo de diseño puede contribuir a anomalías e inconsistencias de datos, por ejemplo:
- Si elimina los dos libros "Children of the Mind" y "Ender's Game", eliminaría el autor "Orson Scott Card" y su nacionalidad por completo de la base de datos.
- No puede agregar un nuevo autor a la base de datos a menos que también agregue un libro; ¿Qué sucede si la autora aún no está publicada o no sabe el nombre de un libro que ella ha escrito?
- Si "Orson Scott Card" cambió su ciudadanía, tendría que cambiarla en todos los registros en los que aparece. Tener varios registros con el mismo autor puede resultar en datos inexactos: ¿qué sucede si la persona que ingresa los datos no se da cuenta de que hay varios registros para él y cambia los datos en un solo registro?
- No puedes eliminar un libro como "El cuento de una criada" sin eliminar también al autor por completo.
Estas son solo algunas de las razones por las que la normalización, y evitar las dependencias transitivas, protegen los datos y garantizan la consistencia.