Una dependencia funcional completa es un estado de normalización de la base de datos que equivale al estándar de normalización de la Segunda Forma Normal (2NF). En resumen, esto significa que cumple con los requisitos de la Primera Forma Normal (1NF), y todos los atributos que no son clave dependen completamente funcionalmente de la clave principal.
Esto no es tan complicado como puede parecer. Veamos esto con más detalle.
Resumen de la primera forma normal
Antes de que una base de datos pueda ser totalmente funcional, primero debe cumplir con la primera forma normal.
Todo esto significa que cada atributo debe contener un solo valor atómico.
Por ejemplo, la siguiente tabla hace no cumplir con 1NF, porque la empleada Tina está vinculada a dos ubicaciones, ambas en una sola celda:
| Empleado | Ubicación |
|---|---|
| Juan | los Angeles |
| Tina | Los angeles, chicago |
Permitir este diseño podría tener un impacto negativo en las actualizaciones o entradas de datos. Para garantizar el cumplimiento de 1NF, reorganice la tabla para que todos los atributos (o celdas de columna) tengan un solo valor:
Cumplimiento de la primera forma normal
Pero 1NF todavía no es suficiente para evitar problemas con los datos.
Cómo funciona 2NF para asegurar la plena dependencia
Para ser totalmente dependiente, todos los atributos de clave no candidatos deben depender de la clave principal. (Recuerde, un atributo de clave candidata es cualquier clave (por ejemplo, una clave primaria o externa) utilizada para identificar de forma única un registro de base de datos.
Los diseñadores de bases de datos utilizan una notación para describir las relaciones dependientes entre atributos:
Si el atributo A determina el valor de B, escribimos estoA -> B- lo que significa que B depende funcionalmente de A. En esta relación, A determina el valor de B, mientras que B depende de A.
Por ejemplo, en el siguiente Departamentos de empleados table, EmployeeID y DeptID son ambas claves candidatas: EmployeeID es la clave principal de la tabla, mientras que DeptID es una clave externa.
Cualquier otro atributo, en este caso, EmployeeName y DeptName, debe depender de la clave principal para obtener su valor.
| ID de empleado | Nombre de empleado | DeptID | DeptName |
|---|---|---|---|
| Emp1 | Juan | Dept001 | Financiar |
| Emp2 | Tina | Dept003 | Ventas |
| Emp3 | Carlos | Dept001 | Financiar |
En este caso, la tabla no es totalmente dependiente porque, mientras que EmployeeName depende de la clave principal EmployeeID, DeptName depende de DeptID. Se llama dependencia parcial .
Para que esta tabla se ajuste a 2NF, necesitamos separar los datos en dos tablas:
| ID de empleado | Nombre de empleado | DeptID |
|---|---|---|
| Emp1 | Juan | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Eliminamos el atributo DeptName de la Empleados tabla y crear una nueva tabla Departamentos :
| DeptID | DeptName |
|---|---|
| Dept001 | Financiar |
| Dept002 | Recursos humanos |
| Dept003 | Ventas |
Ahora las relaciones entre las tablas son totalmente dependientes, o en 2NF.
¿Por qué la dependencia completa es importante?
La dependencia total entre los atributos de la base de datos ayuda a garantizar la integridad de los datos y evitar anomalías en los datos.
Por ejemplo, considere la tabla en la sección anterior que se adhiere solo a 1NF. Aquí está de nuevo:
| Empleado | Ubicación |
|---|---|
| Juan | los Angeles |
| Tina | los Angeles |
| Tina | Chicago |
Tina tiene dos registros. Si actualizamos uno sin darnos cuenta de que hay dos, el resultado sería datos inconsistentes.
O, ¿qué sucede si queremos agregar un empleado a esta tabla, pero aún no conocemos la ubicación? Se nos puede negar incluso a agregar un nuevo empleado si el atributo Ubicación no permite valores NULL.
Sin embargo, la dependencia total no es la imagen completa cuando se trata de la normalización. Debe asegurarse de que su base de datos esté en la tercera forma normal (3NF).
