Un buen diseño de una Base de Datos nos garantiza su correcto funcionamiento en el futuro. De allí la importancia de comprender muy bien los conceptos de Normalización de Bases de Datos. Cuando el diseño de una base de datos viola las reglas de normalización, posteriormente pueden presentarse anomalías en la actualización de los datos (Oppel, 2010). Ahora nos corresponde estudiar la Tercera Forma Normal (3FN) para evitar esas anomalías.
Comenzamos analizando qué es una relación que cumple la 3FN:
“Una relación se encuentra en Tercera Forma Normal si, y solo si, se encuentra en 2FN y si los atributos no clave dependen de forma no transitiva de la clave primaria” (Reynosa E., Maldonado C., Muñoz R., Damiano L., Abrutsky M, 2012).
De nuevo encontramos que el primer requisito es cumplir con la 2FN, que analizamos en el tema anterior.
El siguiente requisito es que ningún subconjunto de atributos tendrá una dependencia transitiva. Para analizar si una relación no se encuentra en 3FN buscamos un subconjunto de atributos que no pertenezca a la clave primaria y que al cambiar el valor de un atributo, necesariamente cambia el valor de los demás atributos del subconjunto. Por ejemplo, observemos una de las relaciones que hemos estado utilizando de ejemplo, y que llamaremos Factura.
| Factura | ||||||
| PK | ||||||
| Sucursal | Número de factura | Fecha de la factura | Forma de pago | Código de cliente | Nombre de cliente | Total de factura |
| 01 | 100 | 1/10/15 | Crédito | 01 | PEREZ | 440 |
| 01 | 101 | 2/10/15 | Contado | 33 | GARCÍA | 100 |
| 02 | 100 | 3/10/15 | Crédito | 45 | GOMEZ | 550 |
Observemos ahora lo que pasa con los atributos Código de cliente y Nombre de Cliente. ¿Qué pasaría si cambiamos el código de cliente? Que necesariamente cambiaría el nombre de cliente. Esto quiere decir que existe una dependencia funcional entre estos dos campos, y eso indica que la relación NO se encuentra en 3FN (Tercera forma normal).
Transformación a Tercera Forma Normal (3FN)
Utilizamos la misma técnica que implica mover los atributos en conflicto a una nueva relación. En nuestro caso, llamaremos a la relación nueva con el nombre de Clientes, y estaría representada de la siguiente manera:
| Clientes | |
| Pk | |
| Código de cliente | Nombre de cliente |
| 01 | PEREZ |
| 33 | GARCÍA |
| 45 | GOMEZ |
Entonces, la relación Factura queda de la siguiente manera:
| Factura | |||||
| PK | |||||
| Sucursal | Número de factura | Fecha de la factura | Forma de pago | Código de cliente | Total de factura |
| 01 | 100 | 1/10/15 | Crédito | 01 | 440 |
| 01 | 101 | 2/10/15 | Contado | 33 | 100 |
| 02 | 100 | 3/10/15 | Crédito | 45 | 550 |
| Fk | |||||
Observamos que el atributo Código de cliente ahora es una clave foránea que nos permite relacionar el dato con las tuplas correspondientes de la relación Clientes. Además, desapareció el campo Nombre de cliente, con lo que desaparece a su vez la dependencia transitiva que nos impedía tener la relación en 3FN.
En conclusión: en estos últimos artículos hemos analizado el diseño de una base de datos mediante normalización. Recuerda que en una relación en 3FN, cada atributo que no es una clave debe depender de la clave y solamente de la clave.
Referencias
- Oppel A. (2010). Fundamentos de Bases de Datos. Ed. McGraw-Hill. México.
- Reynosa E., Maldonado C., Muñoz R., Damiano L., Abrutsky M. (2012). Bases de datos. Ed. Alfaomega.
- Soler, J., Prados, F., Boada, I., & Poch, J. (2006). Utilización de una plataforma de e-learning en la docencia de Bases de Datos. Proc. of JENUI, 581-588.
Tu comentario
opiniones