Desde o resumo sobre BCNF, ficou uma promessa em aberto: a decomposição de Ensina era sem perda, mas não preservava a dependência {aluno, disciplina} → professor como restrição verificável localmente. Chegou a hora de formalizar as duas propriedades por trás dessa afirmação — decomposição sem perda (lossless-join) e preservação de dependências — e mostrar, com teste formal, por que elas nem sempre andam juntas.
Neste resumo, você vai ver o teste formal de decomposição sem perda para o caso binário, a definição formal de preservação de dependências, a verificação passo a passo de que a decomposição de Ensina realmente não preserva a dependência original e por que o algoritmo de síntese para 3FN consegue as duas propriedades ao mesmo tempo.
📲 Canal Oficial do Dicionário do Concurseiro no WhatsApp
Receba resumos, questões comentadas e novidades diretamente no seu celular!
💡 Conteúdo exclusivo para concurseiros. Totalmente gratuito!
⚙️ Duas propriedades desejáveis, nem sempre simultâneas
Toda decomposição de uma relação R em R1, R2, …, Rn deveria idealmente ter duas propriedades: decomposição sem perda (reconstruir R exatamente via JOIN das partes, sem linhas fantasmas nem perda de combinações válidas) e preservação de dependências (conseguir verificar todas as dependências funcionais originais localmente, dentro de uma única tabela decomposta, sem precisar fazer JOIN para checar uma restrição). BCNF sempre garante a primeira; como visto no resumo sobre BCNF, nem sempre garante a segunda.
✅ Teste formal de decomposição sem perda (caso binário)
Para uma decomposição de R em apenas R1 e R2, existe um teste simples: ela é sem perda se e somente se o conjunto de atributos comuns às duas — R1 ∩ R2 — é superchave de pelo menos uma delas, ou seja, (R1 ∩ R2) → R1 ou (R1 ∩ R2) → R2. Na decomposição de Ensina(aluno, disciplina, professor) em Professor_Disciplina(professor, disciplina) e Aluno_Professor(aluno, professor), a interseção é {professor}, que é chave de Professor_Disciplina — o teste passa, confirmando (agora formalmente) o que o resumo sobre BCNF já tinha afirmado.
🔍 Preservação de dependências: definição formal
Uma decomposição preserva dependências quando o fechamento da união das dependências funcionais projetadas em cada Ri — ou seja, (F1 ∪ F2 ∪ … ∪ Fn)⁺ — implica logicamente todas as dependências do conjunto original F. Em outras palavras: se for possível reconstruir cada FD original só raciocinando com as FDs que sobraram dentro de cada tabela separada (sem precisar fazer JOIN), a decomposição preserva dependências.
🧮 Verificando Ensina passo a passo
Projetando as FDs de Ensina nas tabelas decompostas: em Professor_Disciplina(professor, disciplina), vale professor → disciplina; em Aluno_Professor(aluno, professor), não sobra nenhuma FD não trivial (a chave já é a tabela inteira). A união das FDs projetadas é só {professor → disciplina}. Calculando o fecho de {aluno, disciplina} usando apenas essa FD: como professor não está no conjunto de partida, a regra professor → disciplina não pode ser aplicada, e o fecho para em {aluno, disciplina} — sem incluir professor. Ou seja, a dependência original {aluno, disciplina} → professor não é implicada pelas FDs projetadas: a decomposição, de fato, não preserva essa dependência.
⚖️ Por que a síntese para 3FN consegue as duas coisas
O algoritmo de síntese para 3FN — construir uma tabela para cada dependência de uma cobertura mínima, mais uma tabela extra com uma chave candidata se nenhuma delas contiver uma — garante, por construção, tanto decomposição sem perda quanto preservação de dependências. O preço dessa garantia dupla é aceitar o rigor de 3FN em vez de BCNF: como o resumo sobre BCNF mostrou, é justamente a válvula de escape do atributo primo que permite à síntese de 3FN preservar dependências que a decomposição rumo a BCNF, às vezes, sacrifica.
⚠️ Pegadinhas comuns
- O teste de interseção-superchave só vale para decomposição em duas partes: para decompor em três ou mais tabelas de uma vez, é preciso um teste mais geral (o algoritmo de “chase”), fora do escopo mais cobrado em concurso;
- Decomposição sem perda é sobre reconstruir os dados; preservação de dependências é sobre reconstruir as regras — são propriedades independentes, e uma decomposição pode ter uma sem a outra;
- BCNF garante sem perda sempre, mas não garante preservação de dependências sempre — não confundir “BCNF é mais rigorosa” com “BCNF é estritamente melhor” em todo critério;
- Toda decomposição em 3FN via síntese é sem perda e preserva dependências — mas nem toda decomposição em 3FN foi necessariamente feita por síntese; uma tabela pode chegar a 3FN por outro caminho e ainda assim não preservar alguma dependência.
🎯 Dica Final para a Prova
Para testar decomposição sem perda em duas tabelas, ache a interseção dos atributos e verifique se ela é superchave (ou, no caso mais comum em prova, a própria chave) de pelo menos uma das duas. Para testar preservação de dependências, projete as FDs em cada tabela, junte tudo e calcule o fecho do lado esquerdo de cada FD original usando só essas FDs projetadas — se o fecho não alcançar o lado direito, a dependência não foi preservada.
✓ Com as propriedades de decomposição formalizadas, a teoria de normalização está completa. Mas normalizar até o fim nem sempre é a decisão certa na prática: bancos de altíssimo desempenho às vezes desfazem esse trabalho de propósito. Esse é o tema do próximo resumo, sobre desnormalização orientada a desempenho.
📍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: Desnormalização Orientada a Desempenho
📘 Sem perda garante que os dados voltam inteiros; preservar dependências garante que as regras continuam verificáveis sem precisar de JOIN — nem toda decomposição entrega as duas coisas. Continue estudando!
Comentários
Seja o primeiro a comentar.
Você precisa fazer o login para publicar um comentário.