Banco de Dados I — 2026.2

Aula 4
Modelo Relacional & Normalização

👨‍🏫 Prof. Gustavo Pinto 🏛️ UFPA 📅 09 de abril de 2026 🕣 7h30 – 9h10

Agenda de hoje

Modelo Relacional

O Modelo Relacional representa dados em tabelas (relações). Cada linha é uma tupla; cada coluna, um atributo. Proposto por E. F. Codd (IBM, 1970).

Relação (Tabela)

Conjunto de tuplas com o mesmo esquema. Nome único no banco.

Tupla (Linha)

Uma ocorrência / instância da relação. Não há ordem entre tuplas.

Atributo (Coluna)

Propriedade com nome e domínio. Valores atômicos (sem repetição).

Chave Primária (PK)

Identifica unicamente cada tupla. Não pode ser NULL.

Chave Estrangeira (FK)

Referencia a PK de outra tabela. Garante integridade referencial.

Mapeamento MER → Relacional

O DER é um modelo conceitual. O Modelo Relacional é lógico. O mapeamento traduz um para o outro seguindo regras.

MER (conceitual)

Entidade, Atributo, Relacionamento, Cardinalidade, Especialização

Relacional (lógico)

Tabela, Coluna, PK, FK, Restrições

Regra 1 — Entidade Forte

Cada entidade forte do DER vira uma tabela. Seus atributos viram colunas. O atributo identificador vira a chave primária.

DER Aluno Relacional Aluno( matricula , nome, email, dataNasc) PK: matricula

Atributos multivalorados NÃO viram colunas diretamente — geram uma tabela auxiliar com FK para a entidade-pai.

Regra 2 — Relacionamento 1:N

A chave primária do lado 1 migra como chave estrangeira para a tabela do lado N.

Turma (lado 1)

codTurmasalahorario
T01Lab 2Ter 7h30
T02205Qui 9h10

Aluno (lado N)

matriculanomecodTurma (FK)
2024001AnaT01
2024002BiaT01
2024003CarlosT02

codTurma na tabela Aluno é a FK — cada aluno pertence a uma turma, mas uma turma tem vários alunos.

Regra 3 — Relacionamento N:M

Relacionamentos N:M geram uma tabela associativa cujas colunas são as chaves primárias das duas entidades participantes (formando uma PK composta).

Exemplo: Aluno se matricula em várias Disciplinas; cada disciplina tem vários alunos.

TabelaColunasObservação
Alunomatricula, nomePK: matricula
DisciplinacodDisc, nome, cargaPK: codDisc
Matriculamatricula, codDisc, nota, semestrePK composta; FKs p/ Aluno e Disciplina

Atributos do relacionamento (ex.: nota) ficam na tabela associativa.

Regra 3 — As três tabelas

Aluno

matriculanome
2024001Ana
2024002Bia
2024003Carlos

Disciplina

codDiscnomecarga
BD1Banco de Dados I60h
POOProg. Orientada a Obj.60h

Matricula (associativa)

matriculacodDiscnota
2024001BD18.5
2024001POO7.0
2024002BD19.0
2024003POO6.5

PK de Matricula é composta: matricula + codDisc. Ambas são também FKs. A nota (atributo do relacionamento) fica na tabela associativa.

Exercício em sala

Regras 4 e 5 — Mapeie você mesmo

Cenário A — Relacionamento 1:1

Um Funcionário (CPF, nome) é alocado em exatamente uma Sala (número, andar). Cada sala pertence a no máximo um funcionário.

Como ficam as tabelas? Onde vai a FK?

Cenário B — Entidade Fraca

Um Funcionário (CPF, nome) pode ter vários Dependentes (nome, parentesco, dataNasc). Dependente não existe sem o funcionário.

Qual é a PK da tabela Dependente?

Escreva as tabelas no formato: NomeTabela(PK, col1, col2, FK)

Gabarito

Regras 4 e 5 — Resposta

Cenário A — 1:1

Funcionario(CPF, nome, numSala)

Sala(numero, andar)

FK numSala em Funcionário (lado com participação total). Sala pode existir sem funcionário; funcionário sempre tem sala.

Cenário B — Entidade Fraca

Funcionario(CPF, nome)

Dependente(cpfFunc, nome, parentesco, dataNasc)

PK composta: CPF do funcionário (FK) + nome do dependente. Sem o funcionário, o dependente não existe.

Regra geral: na entidade fraca, a PK = FK da entidade forte + chave parcial da entidade fraca.

O problema da redundância

pedidoIDclienteNomeclienteEmailprodutoNomecategoriapreco
1Anaana@x.comNotebookEletrônicos3200
2Anaana@x.comMouseEletrônicos80
3Brunobru@y.comNotebookEletrônicos3200

Anomalia de inserção

Não posso cadastrar produto sem pedido associado.

Anomalia de atualização

Mudar o e-mail de Ana exige atualizar múltiplas linhas.

Anomalia de deleção

Remover o pedido 3 apaga informação do produto Notebook.

Dependência Funcional

Dizemos que X → Y (X determina Y) quando, para cada valor de X, existe exatamente um valor de Y.

Dependência Parcial

Y depende de parte de uma chave composta. Viola a 2FN.

Dependência Transitiva

X → Z via Y (X → Y → Z, Y não é chave). Viola a 3FN.

Primeira Forma Normal (1FN)

Uma relação está em 1FN quando todos os seus atributos contêm apenas valores atômicos (indivisíveis) e não há grupos repetitivos.

❌ Viola 1FN

Pedido(pedidoID, cliente, itens: {prod1, prod2, ...})

Atributo multivalorado dentro da tupla.

✅ Em 1FN

Pedido(pedidoID, cliente)
ItemPedido(pedidoID, codProd, qtd)

Cada célula tem um único valor.

Segunda Forma Normal (2FN)

Uma relação está em 2FN se está em 1FN e todo atributo não-chave depende funcionalmente da chave primária inteira (sem dependências parciais).

⚠️ Só é relevante quando a chave primária é composta.

❌ Viola 2FN

ItemPedido(pedidoID, codProd, qtd, nomeProd, preco)

nomeProd e preco dependem só de codProd, não da chave inteira.

✅ Em 2FN

ItemPedido(pedidoID, codProd, qtd)
Produto(codProd, nomeProd, preco)

Dependência parcial removida.

Terceira Forma Normal (3FN)

Uma relação está em 3FN se está em 2FN e não há dependências transitivas: nenhum atributo não-chave depende de outro atributo não-chave.

❌ Viola 3FN

Funcionario(id, nome, codDept, nomeDept)

id → codDept → nomeDept. nomeDept depende de codDept (não da PK diretamente).

✅ Em 3FN

Funcionario(id, nome, codDept)
Departamento(codDept, nomeDept)

Dependência transitiva removida.

Regra prática: "Todo atributo não-chave deve depender da chave, de toda a chave, e somente da chave."

Resumo: 1FN → 2FN → 3FN

Forma NormalCondição eliminadaComo resolver
1FN Valores não-atômicos / grupos repetitivos Extrair em nova tabela com FK
2FN Dependência parcial da chave composta Separar atributo + parte da chave em nova tabela
3FN Dependência transitiva (não-chave → não-chave) Extrair o determinante em nova tabela com FK

Normalizar = eliminar redundância + preservar dados + manter integridade.

Exemplo — Normalização passo a passo

Tabela original (não normalizada):

pedidoIDdataclienteNomeclienteCidadeprodutos (lista)
1012026-04-01AnaBelémNotebook, Mouse

→ 1FN

Separar produtos em ItemPedido(pedidoID, codProd, qtd). Pedido(pedidoID, data, clienteNome, clienteCidade).

→ 2FN

nomeProd / preco dependem só de codProd → Produto(codProd, nome, preco).

→ 3FN

clienteCidade depende de clienteNome, não de pedidoID → Cliente(codCliente, nome, cidade). Pedido recebe codCliente (FK).

Exercício

Mapeamento & Normalização

Um hospital tem médicos (CRM, nome, especialidade) que atendem pacientes (CPF, nome, cidade). Cada atendimento tem uma data e diagnóstico. Um paciente pode ser atendido por vários médicos; um médico atende vários pacientes.

① Identifique

Quais entidades? Qual cardinalidade do relacionamento? Há entidade fraca?

② Mapeie

Converta para tabelas relacionais com PKs e FKs. Onde fica o atributo diagnóstico?

③ Normalize

Suas tabelas estão em 3FN? Identifique e elimine dependências parciais ou transitivas.

Banco de Dados I — 2026.2

Próxima aula: Avaliação 1

📖 Heuser, cap. 4–5  |  Silberschatz, cap. 7