Forma Normal de Boyce-Codd

A Forma Normal de Boyce-Codd (FNBC)

A Forma Normal de Boyce-Codd representa um refinamento da Terceira Forma Normal (3FN), estabelecendo critérios mais rigorosos para a eliminação de anomalias que podem persistir mesmo em esquemas já normalizados.

Embora muitas vezes seja aplicada após a 3FN, não há obrigatoriedade de seguir essa ordem: um esquema pode ser projetado diretamente para atender à FNBC, sem necessariamente passar pelas formas normais anteriores. A restrição adicional imposta é que, para toda dependência funcional não trivial do tipo $X \rightarrow Y$, o determinante $X$ deve ser obrigatoriamente uma superchave da relação.

A principal distinção reside na flexibilidade da 3FN: ela permite dependências em que o determinante não é uma superchave, desde que o atributo dependente seja um atributo principal (primo), ou seja, parte de alguma chave candidata. A FNBC remove esta exceção, exigindo que qualquer atributo que determine outro identifique unicamente as tuplas da relação. Este nível de normalização é frequentemente ocorre em tabelas que possuem múltiplas chaves candidatas compostas que compartilham atributos entre si.

Análise de Caso: Registro de Atendimentos Médicos

Para compreender a aplicação prática, considere uma base de dados da Secretaria de Saúde estruturada sob as seguintes regras:

• cada médico atua em apenas uma Unidade Básica de Saúde (UBS);
• um paciente pode ser atendido em diversas UBSs, mas possui apenas um médico de referência em cada uma delas;
• e cada UBS possui diversos médicos.

A partir destas premissas, identificamos as seguintes dependências funcionais:

1. $(Paciente, UBS) \rightarrow Médico$
2. $Médico \rightarrow UBS$

Desta análise, derivamos que a relação possui duas chaves candidatas distintas: $(Paciente, UBS)$ e $(Paciente, Médico)$.

Embora a tabela satisfaça os critérios da 3FN, ela viola a FNBC devido à segunda dependência funcional. Nela, o Médico atua como determinante da UBS, mas não é, isoladamente, uma chave candidata.

Como o atributo determinado (UBS) faz parte de uma das chaves candidatas, a 3FN aceita a estrutura, mas a FNBC exige a sua correção para evitar redundâncias e inconsistências, como a repetição desnecessária de qual médico pertence a qual unidade em cada novo registro de atendimento.

Decomposição e Resolução

A correção de uma violação da FNBC exige a decomposição da tabela original em relações menores, de modo que cada determinante se torne uma chave no seu novo contexto.

Tabela: MEDICOS

Nesta relação, o vínculo entre o profissional e a unidade é isolado. O Médico torna-se a chave primária, garantindo que a informação sobre a sua UBS seja armazenada uma única vez.

Tabela: ATENDIMENTOS

Esta tabela passa a registar apenas a associação entre o paciente e o profissional que o atende. A chave primária desta relação é a combinação (PACIENTE, MÉDICO).

Após a decomposição, ambas as tabelas estão na FNBC. É importante notar que, embora a redundância tenha sido eliminada, a restrição original de que um paciente tem apenas um médico por UBS ($(Paciente, UBS) \rightarrow Médico$) não é mais garantida automaticamente pelas dependências funcionais preservadas na decomposição. Em implementações reais, esta regra de negócio deve ser assegurada através de mecanismos de integridade adicionais, como gatilhos (triggers) ou lógica de aplicação, evidenciando que a normalização rigorosa é um processo de escolha entre eficiência de armazenamento e complexidade de validação.