Evite as dependencias transitivas para axudar a garantir a normalización
Unha dependencia transitiva nunha base de datos é unha relación indirecta entre valores na mesma táboa que causa unha dependencia funcional . Para acadar o estándar de normalización do terceiro formulario normal (3NF), debes eliminar calquera dependencia transitiva.
Pola súa natureza, unha dependencia transitiva require tres ou máis atributos (ou columnas de base de datos) que teñen unha dependencia funcional entre eles, o que significa que a columna A nunha táboa depende da columna B a través dunha columna intermedia C.
Vexamos como iso podería funcionar.
Exemplo de dependencia transitiva
AUTORES
| Autor_ID | Autor | Libro | Autor_Nacionalidade |
|---|---|---|---|
| Auth_001 | Orson Scott Card | Xogo de Ender | Estados Unidos |
| Auth_001 | Orson Scott Card | Xogo de Ender | Estados Unidos |
| Auth_002 | Margaret Atwood | O Conto da Esma | Canadá |
No exemplo de AUTORES anterior:
- Libro → Autor : Aquí, o atributo Book determina o atributo Autor . Se coñeces o nome do libro, podes aprender o nome do autor. Non obstante, o autor non determina o Libro porque un autor pode escribir varios libros. Por exemplo, só porque coñecemos o nome do autor Orson Scott Card, aínda non sabemos o nome do libro.
- Autor → Autor_Nationality : Do mesmo xeito, o atributo Autor determina a Autor_Nationality , pero non o contrario; só porque sabemos que a nacionalidade non significa que poidamos determinar o autor.
Pero esta táboa introduce unha dependencia transitiva:
- Libro → Autor_Nationality: Se coñecemos o nome do libro, podemos determinar a nacionalidade a través da columna Autor.
Evitando as dependencias transitivas
Para garantir o terceiro formulario normal, eliminemos a dependencia transitiva.
Podemos comezar eliminando a columna Libro da táboa Autores e creando unha táboa de libros separada:
LIBROS
| Libro_ID | Libro | Autor_ID |
|---|---|---|
| Libro_001 | Xogo de Ender | Auth_001 |
| Libro_001 | Fillos da mente | Auth_001 |
| Libro_002 | O Conto da Esma | Auth_002 |
AUTORES
| Autor_ID | Autor | Autor_Nacionalidade |
|---|---|---|
| Auth_001 | Orson Scott Card | Estados Unidos |
| Auth_002 | Margaret Atwood | Canadá |
¿Fixouse isto? Examinemos agora as nosas dependencias:
TABLA DE LIBROS :
- Book_ID → Libro: o libro depende do Book_ID .
- Non existen outras dependencias nesta táboa, polo que estamos ben. Teña en conta que a clave externa Autor_ID enlaza esta táboa á táboa AUTOR a través da súa clave principal Autor_ID . Creamos unha relación para evitar unha dependencia transitiva, un proxecto clave de bases de datos relacionales.
Táboa de autores :
- Autor_ID → Autor: O autor depende do Author_ID .
- Autor → Autor_Nationality: A autoridade pode determinar a nacionalidade.
- Autor_ID → Autor_Nationality: A nacionalidade pódese determinar a partir do Author_ID a través do atributo Autor . Aínda temos unha dependencia transitiva.
Necesitamos engadir unha terceira táboa para normalizar estes datos:
PAÍSES
| País_ID | País |
|---|---|
| Coun_001 | Estados Unidos |
| Coun_002 | Canadá |
AUTORES
| Autor_ID | Autor | País_ID |
|---|---|---|
| Auth_001 | Orson Scott Card | Coun_001 |
| Auth_002 | Margaret Atwood | Coun_002 |
Agora temos tres táboas, facendo uso de chaves estranxeiras para vincular entre as táboas:
- A clave externa da táboa LIBRO Autor_ID enlaza un libro a un autor na táboa AUTORES.
- A clave externa da táboa AUTHORS Country_ID enlaza un autor a un país da táboa COUNTRIES.
- A táboa COUNTRIES non ten chave estranxeira porque non ten necesidade de ligar a outra táboa neste deseño.
Por que as dependencias transitivas son un bo deseño de base de datos
Cal é o valor de evitar dependencias transitivas para axudar a garantir 3NF? Consideremos de novo a nosa primeira mesa e vexa os problemas que crea:
AUTORES
| Autor_ID | Autor | Libro | Autor_Nacionalidade |
|---|---|---|---|
| Auth_001 | Orson Scott Card | Xogo de Ender | Estados Unidos |
| Auth_001 | Orson Scott Card | Fillos da mente | Estados Unidos |
| Auth_002 | Margaret Atwood | O Conto da Esma | Canadá |
Este tipo de deseño pode contribuír a anomalías de datos e inconsistencias, por exemplo:
- Se eliminas os dous libros "Children of the Mind" e "Ender's Game", eliminarías o autor "Orson Scott Card" ea súa nacionalidade completamente da base de datos.
- Non podes engadir un novo autor á base de datos a menos que tamén engades un libro; e se o autor aínda non está publicado ou non sabe o nome dun libro que escribiu?
- Se "Orson Scott Card" cambiou a súa cidadanía, tería que cambialo en todos os rexistros nos que apareza. O feito de ter varios rexistros co mesmo autor pode xerar datos inexactos: e se a persoa de entrada de datos non se dá conta de que hai moitos rexistros para el e cambia os datos en só un rexistro?
- Non podes borrar un libro como "The Handmaid's Tale" sen borrar por completo o autor.
Estas son só algunhas razóns polas que a normalización e a evitación das dependencias transitivas protexen os datos e aseguran a coherencia.