O Modelo Relacional organiza os dados em tabelas (relações), onde cada linha é uma tupla e cada coluna é um atributo. Proposto por Edgar Codd em 1970.
Conjunto de tuplas com o mesmo esquema
Uma instância/registro da tabela
Uma propriedade com nome e domínio
Cada entidade do MER vira uma tabela. Cada atributo vira uma coluna. O atributo identificador vira a chave primária.
A chave primária do lado "1" é adicionada como chave estrangeira na tabela do lado "N".
A FK vai para o lado N — cada funcionário pertence a um departamento.
Coloque a FK no lado com participação total (se houver). Assim evita NULLs.
Ex: Funcionário gerencia Departamento → FK cod_gerente em Departamento
Cria-se uma nova tabela contendo as PKs das duas entidades como FKs. A PK da nova tabela é a combinação das duas FKs.
Ex: Aluno cursa Disciplina → tabela Matrícula(aluno_id, disc_id, nota)
Vira uma tabela cuja PK = FK da entidade forte + chave parcial.
Dependente(func_cpf (FK), nome, dt_nascimento)
Três estratégias possíveis:
① Uma tabela por hierarquia — todos os atributos juntos + coluna "tipo"
② Uma tabela por subclasse — cada subclasse com FK para superclasse
③ Tabelas independentes — atributos da superclasse repetidos em cada subclasse
Estratégia ② é a mais comum e recomendada.
Normalização é o processo de organizar tabelas para minimizar redundância e evitar anomalias de inserção, atualização e exclusão.
Não consigo inserir dados de uma entidade sem dados de outra
Ex: cadastrar departamento sem funcionário
Alterar um dado exige atualizar várias linhas
Ex: mudar nome do departamento em todos os funcionários
Excluir uma tupla causa perda de dados não relacionados
Ex: excluir o último funcionário perde dados do departamento
Um atributo B é funcionalmente dependente de A (A → B) se, para cada valor de A, existe exatamente um valor de B.
A normalização usa DFs para decidir como decompor tabelas.
Uma tabela está em 1FN se todos os atributos contêm apenas valores atômicos (indivisíveis) — sem grupos repetitivos ou atributos multivalorados.
| CPF | Nome | Telefones |
|---|---|---|
| 111 | Ana | 9999, 8888 |
| 222 | Bia | 7777 |
Telefones tem múltiplos valores numa célula
| CPF | Telefone |
|---|---|
| 111 | 9999 |
| 111 | 8888 |
| 222 | 7777 |
Tabela separada Telefone(CPF, Telefone)
Uma tabela está em 2FN se está em 1FN e todo atributo não-chave depende da chave inteira (sem dependências parciais).
| aluno_id | disc_id | nota | nome_aluno |
|---|---|---|---|
| 1 | BD1 | 8.5 | Ana |
| 1 | POO | 7.0 | Ana |
nome_aluno depende só de aluno_id, não da chave toda
| aluno_id | disc_id | nota |
|---|---|---|
| 1 | BD1 | 8.5 |
| aluno_id | nome_aluno |
|---|---|
| 1 | Ana |
Separou: nome_aluno vai para tabela Aluno
Uma tabela está em 3FN se está em 2FN e nenhum atributo não-chave depende de outro atributo não-chave (sem dependências transitivas).
| CPF | nome | cod_depto | nome_depto |
|---|---|---|---|
| 111 | Ana | D1 | TI |
| 222 | Bia | D1 | TI |
CPF → cod_depto → nome_depto (transitiva)
| CPF | nome | cod_depto (FK) |
|---|---|---|
| 111 | Ana | D1 |
| cod_depto | nome_depto |
|---|---|
| D1 | TI |
Separou: Departamento vira tabela própria
Valores atômicos
Sem grupos repetitivos
1FN + sem dependências parciais
(atributo depende da chave inteira)
2FN + sem dependências transitivas
(não-chave não depende de não-chave)
Regra prática: "cada atributo não-chave deve depender da chave, da chave inteira, e de nada além da chave" — Bill Kent
Uma loja tem clientes (CPF, nome, cidade) que fazem pedidos (número, data). Cada pedido contém vários produtos (código, descrição, preço) com uma quantidade. Cada produto pertence a uma categoria (código, nome).
Identifique os relacionamentos (1:N, N:M) e crie as tabelas com PKs e FKs.
Suas tabelas estão em 3FN? Se não, normalize mostrando cada passo.
📖 Próxima aula presencial: 23/04 — Avaliação 1