ESPM · Gestão BD & BI · 26.09.2026
Aula 2 — A Arquitetura
do Caos
Entidades · Atributos · Cardinalidade · Chaves · 1FN · 2FN · 3FN
O que você vai
saber fazer.
Objetivos da Aula
Identificar os conceitos de entidade, atributo, relacionamento, cardinalidade e chave em um modelo de dados.
Explicar as diferenças entre os tipos de chave (PK, FK, natural, substituta) e o papel de cada forma normal.
Construir um diagrama Entidade-Relacionamento a partir da descrição textual de um processo de negócio.
Identificar anomalias de inserção, alteração e exclusão em um modelo desnormalizado e apontar sua causa.
Julgar se um esquema relacional atinge a 3ª Forma Normal, diagnosticando dependências parciais e transitivas.
Projetar um modelo de dados completo — do diagrama ER conceitual ao esquema físico normalizado — para um processo de negócio real, garantindo integridade referencial e conformidade com a 3ª Forma Normal.
A arquitetura
do caos.
Antes de Começar
Em grupos, abram o catálogo desnormalizado da SoundByte e identifiquem as inconsistências escondidas nele. Vocês têm 5 minutos. Depois, o professor libera a senha para desbloquear a aba com as respostas.
📊
SoundByte_Catalogo_Desnormalizado.xlsx
Excel · Aba de respostas protegida por senha
Um único catálogo desnormalizado, com redundâncias e inconsistências propositais — o mesmo tipo de problema visto na tela de Normalização mais adiante.
SoundByte_Catalogo_Desnormalizado.xlsx
Conceitos Trabalhados

Entidade e atributo

O que existe e merece uma tabela própria — e o que descreve essa entidade. Endereço começa como atributo de Cliente, mas se o cliente tem múltiplos endereços, precisa virar entidade.

Entidade, atributo, registro e coluna na tabela Clientes

Relacionamento e cardinalidade

Como as entidades se conectam e quantos de um lado podem se relacionar com quantos do outro. Se Faixa e Álbum estão na mesma tabela, como armazenar uma faixa em dois álbuns?

Relacionamento e cardinalidade entre Produtos e Categorias

Modelagem aplicada

Os grupos constroem o modelo ER de um processo de vendas em linguagem de negócio — sem jargão técnico — e comparam com o modelo relacional real ao final.

O mundo real
vira banco de dados.
MODELO ER BANCO DE DADOS ENTIDADE Cliente TABELA tbl_clientes ATRIBUTO email COLUNA email VARCHAR(100) INSTÂNCIA João Silva REGISTRO / LINHA 1 · joao@email.com
Entidade
Objeto do mundo real com existência independente. Vira uma tabela no banco.
Atributo
Propriedade que descreve a entidade. Vira uma coluna na tabela.
Instância
Um valor concreto da entidade. Vira uma linha (registro) na tabela.
Como as entidades
se conectam.
1:1 1:N N:M Pessoa 1 1 CPF Uma pessoa tem um CPF. Categoria 1 N Produto Uma categoria agrupa muitos produtos. Cliente N Pedido N Produto Tabela associativa.
1:1
Um registro de A corresponde a exatamente um de B. Ex: Pessoa ↔ CPF.
1:N
Um registro de A corresponde a vários de B. Ex: Categoria → Produtos.
N:M
Muitos de A para muitos de B. Requer tabela associativa no modelo físico.
Três formas.
Um dado limpo.
ORIGINAL Desnor- malizada Caos PRIMEIRA 1FN Valores atômicos Sem grupos repetitivos SEGUNDA 2FN Dep. total na PK Sem dep. parciais TERCEIRA 3FN Atributos → só a PK Sem dep. transitivas
Anomalia de Inserção
Não é possível inserir um cliente sem que ele tenha comprado algum produto.
Anomalia de Alteração
Para atualizar o telefone de um cliente, todos os seus registros devem ser alterados.
Anomalia de Exclusão
Excluir os produtos de um cliente apaga também seus dados cadastrais.
Quando o modelo
trai o dado.

Tabela desnormalizada — um único modelo para cliente, pedido e produto. Parece simples, mas esconde três armadilhas:

PedidoID ClienteID Cliente Email ProdutoID Produto Preço
P001C01João joao@email.com PR01Fone BTR$ 150
P002C01João joao@email.com PR02Caixa SomR$ 300
P003C02Maria maria@email.com PR03HeadphoneR$ 200
＋
Anomalia de Inserção
Não é possível cadastrar um cliente sem que exista um pedido. Como preencher ProdutoID e Preço para um cliente que ainda não comprou?
✎
Anomalia de Alteração
O email de João aparece em duas linhas. Atualizar apenas uma cria inconsistência — o banco passa a ter dois emails diferentes para o mesmo cliente.
✕
Anomalia de Exclusão
Excluir o pedido P003 apaga o cadastro de Maria. Um cancelamento de compra destrói permanentemente os dados do cliente.
Três formas.
Um dado limpo.
1FN

Primeira Forma Normal — Atomicidade

Cada célula deve conter um único valor. Sem listas, sem grupos repetitivos dentro de uma coluna.

✗ Violação
ClienteIDNomeTelefones
C01João99999-1111, 88888-2222
C02Maria77777-3333
✓ Corrigido
ClienteIDNomeTelefone
C01João99999-1111
C01João88888-2222
C02Maria77777-3333
2FN

Segunda Forma Normal — Dependência Total

Todo atributo não-chave deve depender da chave primária inteira. Proíbe dependências parciais em chaves compostas.

✗ Violação — PK = (PedidoID + ProdID)
PedidoIDProdIDNomeProdQtd
P001PR01Fone BT2
P002PR01Fone BT1
P002PR02Caixa Som3

NomeProd depende só de ProdID — não da chave completa.

✓ Corrigido — tabelas separadas
PedidoIDProdIDQtd
P001PR012
P002PR011
ProdIDNomeProd
PR01Fone BT
PR02Caixa Som
3FN

Terceira Forma Normal — Sem Transitividade

Nenhum atributo não-chave pode depender de outro atributo não-chave. Proíbe cadeias de dependência indireta.

✗ Violação
ClienteIDNomeCEPCidade
C01João01310-100São Paulo
C02Maria01310-100São Paulo
C03Pedro30112-000Belo Horizonte

ClienteID → CEP → Cidade (dependência transitiva).

✓ Corrigido
ClienteIDNomeCEP
C01João01310-100
C02Maria01310-100
C03Pedro30112-000
CEPCidade
01310-100São Paulo
30112-000Belo Horizonte
A identidade
de cada registro.

Clique em cada tipo para ver definição e exemplo.

Chave Primária (PK) +
Definição
Identificador único de cada linha. Não aceita nulos. Só existe uma por tabela.
Exemplo
Número da conta em uma instituição financeira.
Chave Estrangeira (FK) +
Definição
Coluna que referencia a PK de outra tabela. Estabelece o relacionamento entre tabelas.
Exemplo
CodFabricante em Produtos referencia CodFabricante em Fabricantes.
Chave Natural +
Definição
Atributo que já existe no mundo real e identifica um registro de forma única.
Exemplo
CPF, CNPJ, nome do país. Risco: regras de negócio podem mudar.
Chave Substituta (Surrogate) +
Definição
Atributo criado exclusivamente para ser chave primária, sem significado para o negócio.
Exemplo
id_cliente (inteiro auto-incremento), UUID. Impacto mínimo com mudanças de negócio.
Chave Composta +
Definição
PK formada pela combinação de dois ou mais atributos que juntos identificam uma linha.
Exemplo
Rua + Número + Cidade + CEP identifica um endereço de forma única.
Chave Candidata +
Definição
Qualquer atributo (ou combinação) que poderia ser usado como PK por ser único na tabela.
Exemplo
Em Clientes: CPF, Código do Cliente e Nome+Sobrenome+Data são todas candidatas.
Chave Alternativa / Única +
Definição
Chave candidata que não foi escolhida como PK. Garante unicidade mas não é o identificador principal.
Exemplo
Se CPF é a PK, então Código do Cliente é a chave alternativa.
A FK deve encontrar
sua PK.
FABRICANTES CodFabricante Nome PK 2001 Sony 2002 JBL 2003 Bose FK → PK PRODUTOS CodProd Nome CodFab PK FK P001 Headphone 2001 P002 Caixa Som 2002 P003 Fone BT 2001 P004 Amplif. 9999 ✗ Violação referencial
Regra
O valor de uma FK deve existir como PK na tabela referenciada.
Violação
FK com valor sem PK correspondente — o registro fica "órfão" no banco.
Consequência
O SGBD rejeita inserções, updates e exclusões que violem a integridade.
Três camadas.
Uma só realidade.
CAMADA 1 Modelo Conceitual Entidades Relacionamentos Regras de negócio refina CAMADA 2 Modelo Lógico Tabelas · Colunas PKs · FKs Independente de BD implementa CAMADA 3 Modelo Físico SQL · Tipos de dados Índices · Partições Específico para o BD
Conceitual
O quê e como os dados se relacionam. Sem detalhes técnicos.
Lógico
Tabelas, colunas, chaves e relacionamentos — independente do banco escolhido.
Físico
SQL, tipos de dados (INT, VARCHAR…), índices e otimizações para o BD específico.
Modelando no Lucid
Os exercícios abaixo são feitos no Lucid, integrado ao Canvas da disciplina. Siga o passo a passo do link para conectar as duas ferramentas antes de começar.
Integrar o Lucid ao Canvas ↗
Exercícios — Modelagem de Dados com Lucid

Clique em cada exercício para ver o cenário, as regras de negócio e a tarefa. Use a notação Crow's Foot.

Exercício 1 — Catálogo de Filmes Animados +
Cenário

Uma plataforma de streaming deseja organizar seu catálogo de filmes animados e contratou você para projetar o modelo de dados relacional. Para cada filme são registrados um ID, o título, o ano de lançamento e a duração em minutos. Cada filme é dirigido por um único diretor e produzido por um único estúdio — mas um diretor pode ter dirigido vários filmes, assim como um estúdio pode ter produzido vários filmes diferentes. Diretores e estúdios possuem, cada um, um ID e um nome.

Regras de Negócio
  • Um filme está sempre associado a um único diretor e um único estúdio.
  • Um diretor pode ter dirigido vários filmes, mas um filme tem apenas um diretor.
  • Um estúdio pode ter produzido vários filmes, mas um filme pertence a apenas um estúdio.
Tarefa
  1. Identifique as entidades do problema.
  2. Modele os relacionamentos entre as entidades, indicando as cardinalidades mínimas e máximas.
  3. Crie os modelos conceitual, lógico e físico, utilizando a notação Crow's Foot.
Exercício 2 — Sistema Acadêmico Simplificado +
Cenário

Uma instituição de ensino contratou você para desenvolver o modelo conceitual de um sistema acadêmico para um curso oferecido por ela — organizando disciplinas, professores e estudantes, e os relacionamentos entre esses elementos.

Regras de Negócio
  • O curso é composto por várias disciplinas. Cada disciplina tem número de identificação, um nome, e é lecionada por apenas um professor.
  • Cada professor possui um número de identificação e um nome. Um professor pode lecionar várias disciplinas.
  • Cada estudante possui um número de identificação, um nome e uma turma. Um estudante pode se matricular em várias disciplinas, e uma disciplina pode ter vários estudantes matriculados. Cada matrícula deve registrar a data em que o estudante se matriculou na disciplina.
Tarefa
  1. Identifique e desenhe todas as entidades envolvidas no sistema.
  2. Defina corretamente os relacionamentos entre as entidades e suas cardinalidades.
  3. Crie os modelos conceitual, lógico e físico utilizando a notação Crow's Foot.
Exercício 3 — Sistema de Agendamento de Consultas em Clínica Médica +
Cenário

Uma clínica médica está desenvolvendo um sistema para gerenciar suas consultas, médicos, pacientes e faturamento. O corpo clínico é composto por diversos médicos, cada um podendo realizar várias consultas ao longo do tempo — ou nenhuma, em determinado momento. As consultas são marcadas com data, hora, duração e motivo, sempre com exatamente um médico e um paciente. Os pacientes são identificados por código, nome, sobrenome, endereço, cidade e estado, e podem agendar uma ou mais consultas. Cada consulta resulta na emissão de uma única fatura, identificada por número, valor, data de envio e status.

Regras de Negócio
  • Médico — identificado por código, nome e sobrenome. Pode estar associado a muitas consultas, ou a nenhuma.
  • Paciente — identificado por código, nome, sobrenome, endereço, cidade e estado. Pode ter várias consultas agendadas; cada consulta está associada a exatamente um paciente.
  • Consulta — identificada por código, data, hora, duração e motivo. Associada a exatamente um médico e um paciente.
  • Fatura — identificada por número, valor, data de envio e status. Associada a uma única consulta; cada consulta gera exatamente uma fatura.
Tarefa
  1. Identifique as entidades envolvidas no sistema.
  2. Defina os relacionamentos entre as entidades, com suas respectivas cardinalidades.
  3. Crie os modelos conceitual, lógico e físico utilizando a notação de Crow's Foot.