Resumo TI Banco de Dados: Forma Normal de Boyce-Codd (BCNF)

O resumo anterior mostrou que a definição formal de 3FN tem uma válvula de escape: uma dependência X → A não viola 3FN se A for atributo primo, mesmo que X não seja superchave. Essa válvula resolve pegadinhas de prova, mas também significa que uma tabela pode estar perfeitamente em 3FN e ainda ter uma anomalia real, causada por uma dependência cujo determinante não é superchave. A Forma Normal de Boyce-Codd (BCNF) fecha esse buraco removendo a exceção.

Neste resumo, você vai ver a definição de BCNF sem a válvula de escape do atributo primo, entender um exemplo clássico de chaves candidatas sobrepostas que passa em 3FN mas falha em BCNF, decompor esse exemplo e conhecer o principal trade-off entre as duas formas normais.

🔒 Definição formal (sem a válvula de escape)

Uma relação está na Forma Normal de Boyce-Codd quando, para toda dependência funcional não trivial X → A, X é superchave — ponto final, sem a alternativa “ou A é primo” que a 3FN admite. BCNF é estritamente mais rigorosa que 3FN: toda relação em BCNF está em 3FN, mas o contrário nem sempre é verdade.

🎓 Exemplo clássico: chaves candidatas sobrepostas

Considere Ensina(aluno, disciplina, professor), com duas regras de negócio: (1) cada professor leciona só uma disciplina — professor → disciplina; (2) para uma disciplina, um aluno tem só um professor — {aluno, disciplina} → professor. Essa tabela tem duas chaves candidatas sobrepostas: {aluno, disciplina} (determina professor pela regra 2) e {aluno, professor} (determina disciplina porque professor já determina disciplina pela regra 1) — as duas compartilham o atributo aluno, exatamente o caso de “chaves candidatas compostas e sobrepostas” citado no resumo anterior sobre 3FN.

⚖️ Por que passa em 3FN mas falha em BCNF

Como todo atributo de Ensina participa de alguma chave candidata (aluno, disciplina e professor são todos primos), a dependência professor → disciplina não viola 3FN: professor não é superchave, mas disciplina é atributo primo — a válvula de escape se aplica. Só que essa mesma dependência viola BCNF, porque professor não é superchave e, em BCNF, não existe exceção para atributo primo. Na prática, isso ainda gera redundância: o nome da disciplina de um professor se repete em toda linha em que ele aparece, e trocar a disciplina de um professor exige atualizar várias linhas.

✂️ Decomposição

A correção separa a dependência problemática em sua própria tabela: Professor_Disciplina(professor, disciplina), onde professor agora é chave, e Aluno_Professor(aluno, professor), registrando quais professores cada aluno tem. Reconstruir o original é um JOIN das duas tabelas por professor — decomposição sem perda, porque professor é chave de Professor_Disciplina.

⚠️ O trade-off: sem perda, mas nem sempre com preservação de dependências

A decomposição acima é lossless (sem perda de informação), mas a dependência original {aluno, disciplina} → professor deixa de ser verificável dentro de uma única tabela — para checá-la, é preciso fazer o JOIN das duas tabelas decompostas. Isso é um trade-off conhecido: a decomposição para BCNF garante ausência de perda, mas nem sempre preserva todas as dependências funcionais originais como restrições verificáveis localmente — diferente do algoritmo de síntese para 3FN, que garante as duas propriedades ao mesmo tempo. É por isso que, na prática, alguns projetos aceitam parar em 3FN. A trilha aprofunda essas duas propriedades (decomposição sem perda e preservação de dependências) em um resumo futuro.

⚠️ Pegadinhas comuns

• BCNF exige 3FN como pré-requisito — mas a volta não é automática: uma tabela pode estar em 3FN sem estar em BCNF, exatamente o caso de Ensina;
• A diferença entre 3FN e BCNF só aparece quando há chaves candidatas compostas e sobrepostas — se a relação tem uma única chave candidata, 3FN e BCNF coincidem;
• Não existe exceção de atributo primo em BCNF: qualquer dependência não trivial cujo determinante não seja superchave viola BCNF, mesmo que o dependente seja atributo primo;
• Mais rigor não é sempre melhor na prática: a banca pode explorar o trade-off entre “decomposição sem perda garantida” (BCNF) e “preservação de dependências garantida” (3FN via síntese) como duas propriedades desejáveis que nem sempre coexistem.

🎯 Dica Final para a Prova

Para identificar violação de BCNF, liste todas as chaves candidatas da relação e, para cada dependência funcional não trivial, pergunte só uma coisa: “o determinante é superchave?” Se não for, é violação de BCNF — não importa se o dependente é primo ou não. Essa pergunta única, sem exceção, é o que diferencia BCNF de 3FN.

✓ BCNF elimina toda redundância causada por dependência funcional. Mas existe um tipo de redundância que nem BCNF resolve: quando dois atributos multivalorados de uma mesma entidade são independentes entre si, sem nenhuma dependência funcional envolvida. Esse é o problema que a Quarta e a Quinta Formas Normais atacam, tema do próximo resumo.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Quarta e Quinta Formas Normais (4FN e 5FN)

📘 BCNF é a 3FN sem a válvula de escape do atributo primo — mais rigorosa, mas nem sempre a decomposição preserva as dependências originais. Continue estudando!