Unha dependencia funcional completa é un estado de normalización da base de datos que equivale ao estándar de normalización do segundo formulario normal (2NF) . En resumo, isto significa que cumpre os requisitos do Primeiro Formulario Normal (1NF) e todos os atributos non-clave dependen totalmente funcionalmente da chave primaria.
Isto non é tan complicado como pode soar. Vexamos isto con máis detalle.
Resumo do primeiro formulario normal
Antes de que unha base de datos poida depender totalmente funcionalmente, primeiro debe cumprir o primeiro formulario normal .
Todo isto significa que cada atributo debe ter un único valor atómico.
Por exemplo, a seguinte táboa non cumpre con 1NF, porque a empregada Tina está ligada a dúas ubicacións, ambas nunha única cela:
Empregado | Localización |
---|---|
John | os anxos |
Tina | Os Ánxeles, Chicago |
Permitir que este proxecto afecte negativamente as actualizacións ou as entradas de datos. Para garantir o cumprimento de 1NF, reorganice a táboa para que todos os atributos (ou columnas) conteñan un único valor:
Empregado | Localización |
---|---|
John | os anxos |
Tina | os anxos |
Tina | Chicago |
Pero 1NF aínda non é suficiente para evitar problemas cos datos.
Como funciona 2NF para garantir a dependencia completa
Para ser totalmente dependentes, todos os atributos de claves non candidatos deben depender da clave primaria. (Lembra que un atributo de chave candidato é calquera tecla (por exemplo, unha chave primaria ou estranxeira) que se usa para identificar de forma exclusiva un rexistro de base de datos.
Os deseñadores de bases de datos usan unha notación para describir as relacións dependentes entre atributos:
Se o atributo A determina o valor de B, escribimos este A -> B - o que significa que B depende funcionalmente de A. Nesta relación, A determina o valor de B, mentres que B depende de A.
Por exemplo, na seguinte táboa de Departamentos de empregados , EmployeeID e DeptID son as dúas claves candidatas: EmployeeID é a chave primaria da táboa mentres que DeptID é unha chave estranxeira.
Calquera outro atributo - neste caso, EmployeeName e DeptName - debe depender da clave primaria para obter o seu valor.
EmpregadoID | Nome do empregado | DeptID | DeptName |
---|---|---|---|
Emp1 | John | Dept001 | Finanzas |
Emp2 | Tina | Dept003 | Vendas |
Emp3 | Carlos | Dept001 | Finanzas |
Neste caso, a táboa non é totalmente dependente porque, mentres o EmployeeName depende da clave primaria EmployeeID, o DeptName depende diso no DeptID. Isto chámase dependencia parcial .
Para facer esta táboa conforme a 2NF, necesitamos separar os datos en dúas táboas:
EmpregadoID | Nome do empregado | DeptID |
---|---|---|
Emp1 | John | Dept001 |
Emp2 | Tina | Dept003 |
Emp3 | Carlos | Dept001 |
Retiremos o atributo DeptName da táboa Empregados e creamos unha nova táboa Departamentos :
DeptID | DeptName |
---|---|
Dept001 | Finanzas |
Dept002 | Recursos humanos |
Dept003 | Vendas |
Agora as relacións entre as táboas son totalmente dependentes ou en 2NF.
Porque a dependencia completa é importante
A dependencia completa entre os atributos da base de datos axuda a garantir a integridade dos datos e evita anomalías de datos.
Por exemplo, considere a táboa na sección anterior que se adhire só a 1NF. Aquí está, de novo:
Empregado | Localización |
---|---|
John | os anxos |
Tina | os anxos |
Tina | Chicago |
Tina ten dous rexistros. Se actualizamos un sen darnos conta de que hai dous, o resultado sería datos inconsistentes.
Ou, e se queremos engadir un empregado a esta mesa, pero aínda non sabemos a situación? Poderíamos deshabilitar incluso engadir un novo empregado se o atributo Location non permite valores NULL.
A dependencia completa non é toda a imaxe, pero cando se trata de normalización. Debes asegurarte de que a túa base de datos estea en terceiro formulario normal (3NF).