A arquitetura
do caos.
Objetivos da Aula — Taxonomia de Bloom
Lembrar Identificar os conceitos de entidade, atributo, relacionamento, cardinalidade e chave em um modelo de dados.
Compreender Explicar as diferenças entre os tipos de chave (PK, FK, natural, substituta) e o papel de cada forma normal.
Aplicar Construir um diagrama Entidade-Relacionamento a partir da descrição textual de um processo de negócio.
Analisar Identificar anomalias de inserção, alteração e exclusão em um modelo desnormalizado e apontar sua causa.
Avaliar Julgar se um esquema relacional atinge a 3ª Forma Normal, diagnosticando dependências parciais e transitivas.
Criar 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.

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.

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?

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.