Resumo TI Banco de Dados: Erros Frequentes de Modelagem e Como Evitá-los

Chegamos ao fechamento da seção de modelagem de dados desta trilha. Antes de avançar para o modelo relacional formal, vale consolidar os erros que mais aparecem — tanto na prática de quem projeta bancos de dados quanto nas pegadinhas de prova — em cada etapa que você já percorreu: do levantamento de requisitos ao mapeamento para tabelas.

Neste resumo, você vai revisar, de forma objetiva, os erros mais frequentes de modelagem agrupados por etapa, como reconhecê-los num enunciado e a forma correta de evitá-los.

📋 Erros no levantamento e na modelagem conceitual

• Modelar antes de concluir o levantamento: começar a desenhar entidades sem ter mapeado requisitos de dados e requisitos funcionais gera retrabalho quando uma regra de negócio esquecida aparece depois — o levantamento vem sempre primeiro;
• Confundir entidade com atributo: transformar “Endereço” numa entidade separada quando o negócio nunca precisa tratá-lo de forma independente é modelar complexidade desnecessária — o teste é sempre “isso tem identidade própria e vida própria no negócio?”;
• Esquecer a dependência de existência da entidade fraca: não incluir a FK da entidade proprietária na chave primária da entidade fraca é o erro mais citado sobre o tema.

🏷️ Erros na classificação de atributos e chaves

• Tratar atributo multivalorado como várias colunas: criar Telefone1, Telefone2, Telefone3 em vez de uma tabela própria é uma violação clássica da 1ª Forma Normal;
• Escolher chave primária instável: usar um atributo que muda com frequência (e-mail, telefone) como PK propaga impacto em cascata para todas as chaves estrangeiras que a referenciam;
• Trocar chave candidata por chave primária nas afirmações: “toda candidata é primária” é falso — só a escolhida vira primária, as demais seguem como alternativas.

🔗 Erros em relacionamentos e cardinalidade

• Colocar a chave estrangeira no lado errado de um 1:N: a FK vai sempre no lado “N” — colocá-la no lado “1” é um dos erros mais cobrados de todo o tema de mapeamento;
• Modelar relacionamento N:N sem tabela associativa: tentar resolver muitos-para-muitos só com FKs cruzadas nas duas tabelas originais viola integridade — a tabela associativa é obrigatória;
• Confundir participação com cardinalidade máxima: são dimensões independentes — uma pode ser total com cardinalidade 1:1, outra pode ser parcial com cardinalidade 1:N.

🧬 Erros em especialização, agregação e EER

• Dar chave primária própria a uma subclasse: subclasse sempre compartilha a PK da superclasse — criar uma chave independente quebra a identidade única da hierarquia;
• Escolher a estratégia de mapeamento errada para a especialização: usar “uma tabela por subclasse, sem tabela para a superclasse” quando a especialização não é total faz perder as ocorrências da superclasse sem subclasse definida — e se, além disso, for sobreposta, ainda gera duplicação de atributos comuns entre as tabelas das subclasses;
• Confundir agregação com relacionamento ternário: agregação tem hierarquia de dois níveis, com o relacionamento interno fazendo sentido sozinho; o ternário é uma única associação simultânea entre três entidades;
• Confundir categoria com herança múltipla: numa categoria (tipo união), cada instância pertence a exatamente uma das superclasses de origem, nunca a todas simultaneamente — por isso a categoria costuma exigir uma chave substituta própria, diferente da regra geral de subclasse herdando a PK da superclasse.

🏗️ Erros no mapeamento para o modelo lógico

• Assumir que NOT NULL garante participação total nos dois lados: só garante do lado que carrega a FK — o lado oposto exige trigger ou regra de aplicação;
• Mapear atributo composto como uma única coluna: só os componentes do atributo composto viram colunas — o atributo composto em si não gera coluna própria;
• Ignorar o trade-off ao escolher estratégia de mapeamento de hierarquia: não existe estratégia universalmente “melhor” entre as três de especialização — cada uma troca fidelidade ao modelo por simplicidade de consulta ou por menos valores nulos.

⚠️ O meta-erro por trás de quase todos os outros

A maioria dos erros acima tem uma raiz comum: tratar uma etapa do processo de modelagem como isolada das demais. Um erro no levantamento de requisitos se propaga para o modelo conceitual; um erro de classificação de atributo se propaga para o mapeamento; uma escolha errada de chave primária se propaga para toda chave estrangeira dependente. Revisar o modelo de ponta a ponta — não só a etapa que acabou de ser feita — é o hábito que evita a maior parte dessas armadilhas.

🎯 Dica Final para a Prova

Quando uma questão descrever um cenário de modelagem e pedir para apontar o erro, comece eliminando pelo tipo de decisão envolvida: é erro de levantamento (regra de negócio ignorada), de classificação (atributo/entidade/chave trocados), de cardinalidade/participação, de estratégia de especialização, ou de mapeamento lógico (tabelas, PK/FK)? Identificar a categoria do erro antes de julgar o detalhe reduz muito a chance de cair numa pegadinha de superfície.

✓ Com a modelagem conceitual e o mapeamento para tabelas consolidados, o próximo passo da trilha é formalizar o modelo relacional em si — a partir dos conceitos de relação, tupla e atributo, a base matemática que sustenta tudo o que você já viu até aqui.

📍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: Conceitos de Relação, Tupla e Atributo

📘 Modelagem de dados é, no fundo, uma sequência de decisões encadeadas — e a maioria dos erros graves nasce de tratar uma dessas decisões como se fosse independente das outras. Continue estudando!