Estou tendo problemas para identificar a combinação de atributos que compõem as Dependências Funcionais (FDs) de uma determinada tabela. Embora eu entenda como o processo de normalização funciona quando recebe os FDs, não consigo traduzir e identificar FDs para uma determinada tabela.
Fui encarregado de criar um banco de dados de uma empresa que rastreie todas as despesas de vendas/pacotes etc. Naturalmente isso significa armazenar informações de clientes para a empresa identificar todos os consumidores.
CREATE TABLE Customers (
id integer primary key,
address text not null,
name text not null,
email text unique not null,
phone text unique not null,
unique(name, address)
);
Optei por representar as informações da tabela de clientes como tal, já que cada número de telefone e e-mail está vinculado exclusivamente ao cliente. A restrição exclusiva permite que várias pessoas do mesmo endereço residencial estejam presentes na tabela.
Quero ver se consigo normalizar ainda mais essa tabela, porém não consigo identificar os atributos para determinar os FDs necessários.
Um conjunto de atributos Y é funcionalmente dependente de outro conjunto X se e somente se Y for determinado exclusivamente por X, ou seja, você não pode ter dois valores diferentes de Y associados ao mesmo valor de X. Assim, por exemplo, supondo que um telefone número está sempre vinculado a apenas uma pessoa, e que uma pessoa tem sempre apenas um endereço, pode-se dizer que a dependência funcional se
phone -> addressmantém, pois, dado um determinado número de telefone, apenas o endereço da pessoa com esse número pode aparecer junto com ele .Assim, uma dependência funcional especifica de forma formal um fato importante da realidade que é modelada em seu banco de dados.
Um problema com dependências funcionais é que você pode ter muitas delas, mesmo para relações pequenas. Uma maneira inteligente de resolver esse problema é definir apenas um pequeno conjunto de dependências, suficiente para “capturar” todas as informações essenciais sobre uma determinada realidade, pois podemos derivar todas as outras dependências desse conjunto de forma mecânica (e existem programas que podem fazer isso, por exemplo, aplicando os conhecidos “axiomas de Armstrong”). No entanto, às vezes não é tão fácil definir tal conjunto “essencial” de dependências funcionais e devemos olhar atentamente para a especificação do problema que estamos modelando.
Normalmente partimos das chamadas “chaves candidatas”, que são os atributos ou conjuntos de atributos que são “naturalmente” únicos dentro de uma relação. Como são únicos, sabemos que determinam todos os outros atributos. No seu exemplo, você já identificou quatro chaves candidatas,
id(a chave primária),(name, address),phoneeemail(declaradounique), então já podemos dizer que:(note que é suficiente dizer que um atributo determina uma chave candidata, pois deste fato podemos derivar que ele determina todos os outros atributos, ou seja, que determina exclusivamente uma pessoa).
Então podemos ver se algum outro atributo de combinação de atributos determina exclusivamente outro(s) atributo(s), ou uma chave candidata (o que é equivalente a determinar todos os outros atributos).
Existem outras dependências funcionais (não triviais, interessantes) em sua relação? Provavelmente não, dada a semântica óbvia dos dados (por exemplo, duas pessoas diferentes podem ter o mesmo endereço, então um endereço não “determina exclusivamente” nada, ou duas pessoas diferentes podem ter o mesmo nome, etc.). Assim, poderíamos ter um certo grau de confiança de que os quatro FDs são um conjunto “essencial” de DFs (tecnicamente, isso é chamado de “cobertura” do conjunto de FDs da relação).
E assim a partir desta capa podemos começar a normalizar a relação (que já está normalizada, neste caso).