Uma dependência funcional completa é um estado de normalização de banco de dados que equivale ao padrão de normalização da Segunda Forma Normal (2NF). Em resumo, isso significa que ele atende aos requisitos da primeira forma normal (1NF) e todos os atributos não-chave dependem totalmente da chave primária.
Isso não é tão complicado quanto parece. Vamos ver isso com mais detalhes.
Resumo da primeira forma normal
Antes que um banco de dados possa ser totalmente funcionalmente dependente, ele deve primeiro obedecer ao Primeiro Formulário Normal.
Tudo isso significa que cada atributo deve conter um único valor atômico.
Por exemplo, a tabela a seguir faz não cumprir com 1NF, porque o funcionário Tina está ligado a dois locais, ambos em uma única célula:
| Empregado | Localização |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Permitir esse design pode impactar negativamente as atualizações ou entradas de dados. Para garantir a conformidade com 1NF, reorganize a tabela para que todos os atributos (ou células da coluna) mantenham um único valor:
Primeira Conformidade com Forma Normal
Empregado Localização John Los Angeles Tina Los Angeles Tina Chicago
Mas 1NF ainda não é suficiente para evitar problemas com os dados.
Como a 2NF trabalha para garantir total dependência
Para ser totalmente dependente, todos os atributos de chave não candidatos devem depender da chave primária. (Lembre-se de que um atributo-chave candidato é qualquer chave (por exemplo, uma chave primária ou estrangeira) usada para identificar exclusivamente um registro do banco de dados.
Os designers de banco de dados usam uma notação para descrever os relacionamentos dependentes entre os atributos:
Se o atributo A determina o valor de B, escrevemos issoA -> B- significando que B é funcionalmente dependente de A. Nessa relação, A determina o valor de B, enquanto B depende de A.
Por exemplo, no seguinte Departamentos de funcionários table, EmployeeID e DeptID são ambas as chaves candidatas: EmployeeID é a chave primária da tabela, enquanto DeptID é uma chave estrangeira.
Qualquer outro atributo - neste caso, EmployeeName e DeptName - deve depender da chave primária para obter seu valor.
| ID do Empregado | Nome do empregado | DeptID | DeptName |
|---|---|---|---|
| Emp1 | John | Dept001 | Finança |
| Emp2 | Tina | Dept003 | Vendas |
| Emp3 | Carlos | Dept001 | Finança |
Nesse caso, a tabela não é totalmente dependente porque, enquanto o EmployeeName depende da chave primária EmployeeID, o DeptName depende do DeptID. Isso é chamado dependência parcial .
Para tornar esta tabela em conformidade com a 2NF, precisamos separar os dados em duas tabelas:
| ID do Empregado | Nome do empregado | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Nós removemos o atributo DeptName do Funcionários mesa e criar uma nova mesa Departamentos :
| DeptID | DeptName |
|---|---|
| Dept001 | Finança |
| Dept002 | Recursos humanos |
| Dept003 | Vendas |
Agora as relações entre as tabelas são totalmente dependentes ou em 2NF.
Por que a dependência completa é importante
A dependência total entre os atributos do banco de dados ajuda a garantir a integridade dos dados e evita anomalias nos dados.
Por exemplo, considere a tabela na seção acima que adere apenas a 1NF. Aqui está, novamente:
| Empregado | Localização |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina tem dois registros. Se atualizarmos um sem perceber que existem dois, o resultado seria dados inconsistentes.
Ou, e se quisermos adicionar um funcionário a essa tabela, mas ainda não sabemos o local? Poderemos ser impedidos até mesmo de adicionar um novo funcionário se o atributo Localização não permitir valores NULL.
Dependência total não é o quadro completo, no entanto, quando se trata de normalização. Você deve certificar-se de que seu banco de dados está na terceira forma normal (3NF).
