Resumo TI Banco de Dados: Anomalias de Inserção, Atualização e Exclusão

Mesmo a consulta mais bem otimizada não resolve um problema mais profundo: um esquema mal projetado, com redundância desnecessária, gera inconsistências independentemente de qualquer regra de equivalência algébrica. Esse problema tem nome — anomalias de atualização (a família que reúne os três problemas vistos a seguir: inserção, atualização e exclusão) — e é o ponto de partida da teoria de normalização.

Neste resumo, você vai entender essas três anomalias clássicas, ver um exemplo único de tabela mal projetada que sofre das três ao mesmo tempo e identificar a causa raiz que a normalização existe para eliminar.

🗄️ O exemplo base: uma tabela que mistura duas entidades

Considere uma tabela única Funcionario(matricula, nome, departamento, gerente_departamento), em que cada linha representa um funcionário, mas também carrega o nome do departamento e o nome do gerente daquele departamento. Como vários funcionários pertencem ao mesmo departamento, os dados departamento e gerente_departamento ficam repetidos em várias linhas — essa redundância é a raiz das três anomalias a seguir.

➕ Anomalia de inserção

Não é possível registrar um departamento novo (com seu gerente) enquanto ele não tiver pelo menos um funcionário lotado nele — a informação do departamento só existe como atributo de uma linha de funcionário. A alternativa, permitir matricula nula para inserir só o departamento, quebra a própria ideia de chave primária da tabela.

🔄 Anomalia de atualização

Se o departamento troca de gerente, é preciso atualizar todas as linhas de todos os funcionários daquele departamento. Esquecer uma única linha deixa o banco em estado inconsistente — parte dos registros aponta o gerente antigo, parte aponta o novo, sem nenhuma violação de restrição que acuse o erro.

➖ Anomalia de exclusão

Se o único funcionário de um departamento for desligado e sua linha excluída, a informação do departamento (nome, gerente) desaparece junto — mesmo que o departamento continue existindo na realidade. A exclusão de um fato (o funcionário) apaga, como efeito colateral, outro fato que não tinha relação nenhuma com ele (a existência do departamento).

🧩 Causa raiz: atributos de duas entidades diferentes numa tabela só

Nos três casos, o problema é o mesmo: departamento e gerente_departamento não dependem do funcionário — dependem só do próprio departamento. Misturar, numa única tabela, atributos que descrevem duas entidades diferentes (funcionário e departamento) é o que gera a redundância e, por consequência, as três anomalias. Formalizar essa relação de dependência entre atributos — e não apenas descrevê-la informalmente, como aqui — é exatamente o objeto do próximo resumo, sobre dependências funcionais.

⚠️ Pegadinhas comuns

• Anomalia não é bug do SGBD: é consequência do projeto do esquema — o mesmo SGBD, tecnicamente correto, produz anomalias se a tabela estiver mal projetada;
• As três anomalias não são mutuamente exclusivas: uma única tabela mal projetada, como a do exemplo, costuma sofrer das três ao mesmo tempo;
• Cada anomalia tem uma operação SQL associada — inserção → INSERT bloqueado ou forçado a valores nulos; atualização → UPDATE precisa repetir em várias linhas; exclusão → DELETE apaga informação que não deveria sumir. A banca costuma trocar essas associações como distrator;
• Redundância não é sempre proibida: em contextos analíticos (data warehouse, desnormalização proposital), redundância controlada é uma troca aceita por desempenho — o problema tratado aqui é a redundância não intencional, fruto de projeto malfeito.

🎯 Dica Final para a Prova

Diante de um cenário descrito na questão, identifique primeiro qual operação está em jogo (inserir, atualizar ou excluir) e só depois classifique a anomalia — a operação aponta diretamente para o nome certo. E lembre-se: a causa estrutural de qualquer uma das três é sempre a mesma, atributos de entidades diferentes espremidos numa tabela só.

✓ Agora que você já reconhece os sintomas de um esquema mal projetado, o próximo passo é entender a causa raiz de forma sistemática e formal: as dependências funcionais entre atributos, base de todo o processo de normalização.

📍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!

👉 Em breve no Dicionário do Concurseiro: Resumo TI Banco de Dados: Dependências Funcionais

📘 Toda anomalia de atualização nasce do mesmo pecado de projeto: misturar, numa tabela só, fatos que pertencem a entidades diferentes. Continue estudando!