Profa.

: Sandra Bianca Henriques Geroldo

 A normalização é um procedimento que
examina os atributos de uma entidade com o
objetivo de evitar anomalias que possam
ocorrer na inclusão, na exclusão ou na
alteração de uma ocorrência específica em
uma entidade.

 Baseada em relações matemáticas (teoria dos

conjuntos).
 Na inclusão uma anomalia acontece quando o
registro de uma entidade possui dados
incompletos. Nesse caso, os dados podem ser
parte de outras entidades ainda não definidas,
ocasionando por exemplo, a existência de nulo.

 Na exclusão de dados, por sua vez, uma anomalia

ocorre quando a exclusão de um dado pode causar
a eventual perda de outro.

 Na alteração uma anomalia ocorre quando há

redundância no armazenamento de dados,
havendo a necessidade de atualização em
diferentes entidades.
 Após obter o modelo relacional passa-se para o
processo de normalização.

 Esse processo se baseia no conceito de forma

normal.
 Uma forma normal é uma regra que deve ser
obedecida por uma tabela para que esta seja
considerada “bem projetada”.
 A fim de estabelecer critérios para realizar a
normalização das entidades, Codd, em 1972,
definiu as Formas Normais (FN), as quais foram
apresentadas inicialmente como:
◦ Primeira Forma Normal (1FN);
◦ Segunda Forma Normal (2FN);
◦ Terceira Forma Normal (3FN);

 Posteriormente, foram acrescidas as:

◦ Forma Normal Boyce-Codd(FNBC);
◦ Quarta Forma Normal (4FN);
◦ Quinta Forma Normal (5FN);
 Assim normalização consiste em um conjunto
de regras aplicadas em uma tabela com o
objetivo de corrigir possíveis erros de projeto.

 Aplicar formas normais significa

principalmente, organizar um projeto de
banco de dados a fim de minimizar a
redundância de dados, aumentar a integridade
de dados e o desempenho.
 Há algumas formas normais, isto é, algumas
regras, cada vez mais rígidas, para verificar
tabelas relacionais.

 Aqui vamos considerar, inicialmente, três

formas normais (primeira, segunda, terceira
forma normal, abreviadamente 1FN, 2FN, e
3FN) por ser um acontecimento mais comum
durante uma modelagem.
 Considere um caso em que não foi realizada todos os passos
observados até o momento da disciplina e observe o
formulário a seguir:
FORMULÁRIO DE PEDIDO
Código do Vendedor: 1234
Nome do Vendedor: Ana dos Santos
Data dos Pedidos: 10/07/2020
 Considere ainda que essa entidade foi
implementada como uma tabela em um
banco de dados
 Nesse caso, teríamos vários problemas
 E esses problemas seriam definidos como
anomalias que iriam aparecer, tais como:
 Anomalia de inclusão: se existir a necessidade de
incluir um novo cliente, será necessário relacionar o
cliente a uma venda obrigatoriamente;
 Ao ser cadastrado uma nova venda, o mesmo cliente
deverá ser cadastrado novamente;
  Anomalia de exclusão: ao ser excluído um cliente, os
dados referentes as suas compras serão perdidos

 Anomalia de alteração: ao ser alterado por exemplo, o

preço unitário de um determinado produto, será
preciso atualizar todos os pedidos já cadastrados que
tenham aquele determinado produto alterado, e alterar
o valor do mesmo produto;

◦ Nesse caso observa-se a importância de rever os

itens que são considerados (entidades, atributos,
...)
 Considerando que através do mapeamento do
modelo lógico para o modelo relacional, uma
tabela foi derivada da entidade formada com
os dados presentes no documento
apresentado, o primeiro passo será listar os
atributos observados

 Ou seja, destaque as colunas da Tabela

FORMULÁRIO DE PEDIDOS
 Assim, é possível identificar
 Código do Vendedor
 Nome do Vendedor
 Data dos Pedidos
 Número do Pedido Cliente (*)
 Nome do Cliente (*)
 CNPJ (*)
 Inscrição Estadual (*)
 Código do Produto (*)
 Quantidade do Produto (*)
 Descrição do Produto (*)
 Valor unitário do produto (*)
 Unidade(*)
 Valor total (*)

(*) Atributos que se repetem no documento

 Consiste na transformação do esquema de
tabela não normalizada em um esquema
relacional na primeira forma normal (1FN).
 Uma tabela encontra-se na 1FN quando não
contém tabelas aninhadas. Portanto, a
passagem à 1FN consta da eliminação das
tabelas aninhadas eventualmente existentes.
 Assim, a primeira forma normal (1FN)
estabelece que uma entidade está em
conformidade com ela somente se:

◦ Não possuir atributos multivalorados ou grupos

repetitivos (obs: importante lembrar que não pode
existir tabelas aninhadas);

◦ Todos os atributos estiverem no formato atômico,

isto é, não forem compostos por múltiplas partes;
 Continuação:
◦ Existe uma chave primária (PK - Primary Key) que
identifica apenas uma ocorrência da entidade; e
◦ As ocorrências da entidade forem todas distintas
entre si.

 Mas o que fazer?

◦ Cada atributo multivalorado ou composto deve ser
transformado em uma nova tabela
◦ Nessa nova tabela deve-se adicionar uma chave
estrangeira (FK - Foreign Key)
 Aqui percebemos que alguns atributos (produtos solicitados)
se repetem (número de ocorrências não definidas) ao longo
do processo de entrada de dados na entidade. Porém, a 1FN
diz que a tabela não deve atributos multivalorados
 A fim de obter uma tabela na primeira forma normal ( 1FN ), é
necessário:

◦ Decompor a tabela não normalizada em tantas tabelas

quanto for o número de conjuntos de atributos repetitivos;
◦ Ou seja, criar uma tabela para a tabela nao-normalizada e
uma tabela para cada tabela aninhada na tabela não-
normalizada.
◦ Nas novas entidades criadas, a chave primária é a
concatenação da chave primária original mais os atributos
do grupo repetitivo visualizados como chave primária deste
grupo.
◦ Tabela Pedido
PEDIDO

Código do Vendedor
Nome do Vendedor
Data do Pedidos
Número do Pedido Cliente
Nome do Cliente
CNPJ
IE
Código do Produto
Quantidade do Produto
Descrição do Produto
Valor Unitário
Unidade
Valor Total
 Considerando a 1FN sobre a tabela PEDIDO, será necessário
criar uma nova tabela chamada ITEM-DE-PEDIDO, que
possuirá os atributos da tabela PEDIDO.
 Um PEDIDO possui no mínimo 1 e no máximo N
ocorrências em ITEM-DE-PEDIDOS e um ITEM-DE-PEDIDOS
pertence a 1 e somente 1 PEDIDO, logo o relacionamento
POSSUI é do tipo 1 para N (1:N).
◦
PEDIDO ITEM-DE-PEDIDO

Número do Pedido(PK) Número do Pedido (PK)(FK)

Data do Pedido Código do Produto (PK)
Nome do Cliente Quantidade do Produto
CNPJ Descrição do Produto
IE (1,1) (1,N) Valor Unitário
Código do Vendedor Unidade
Nome do Vendedor Valor Total
 PEDIDO ITEM-DE-PEDIDO
◦ Número do Pedido(PK) Número do Pedido (PK)(FK)
Data do Pedido Código do Produto (PK)
Nome do Cliente Quantidade do Produto
CNPJ Descrição do Produto
IE (1,1) (1,N) Unidade
Código do Vendedor Valor Unitário
Nome do Vendedor Valor Total

Problemas ainda existem

PEDIDO

Número do Pedido(PK) PRODUTO

ITEM-DE-PEDIDO
Data do Pedido
Nome do Cliente Número do Pedido (PK)(FK) (0,N) Código do Produto(PK)
CNPJ (1,1) (1,N) Código do Produto (PK)(FK) (1,1) Descrição do Produto
IE Quantidade do Produto Unidade
Código do Vendedor Valor Total Valor Unitário
Nome do Vendedor
Entidade fraca
 PEDIDO

Número do Pedido(PK) PRODUTO

◦ Pedido
Data do
ITEM-DE-PEDIDO
Nome do Cliente Número do Pedido (PK)(FK) (0,N) Código do Produto(PK)
CNPJ (1,1) (1,N) Código do Produto (PK)(FK) (1,1) Descrição do Produto
IE Quantidade do Produto Unidade
Código do Vendedor Valor Total Valor Unitário
Nome do Vendedor

Problemas ainda existem na tabela PEDIDO

PEDIDO ITEM-DE-PEDIDO PRODUTO
Número do Pedido (PK)
Número do Pedido (PK)(FK) (0,N) Código do Produto(PK)
Data do Pedido (1,1) (1,N) Código do Produto (PK)(FK) (1,1) Descrição do Produto
CNPJ (FK)
Quantidade do Produto Unidade
Código do Vendedor (FK)
(0,N) Valor Total Valor Unitário
(1,N)

CLIENTE (1,1)
VENDEDOR
(1,1)
CNPJ (PK)
Código do Vendedor (PK)
Nome do Cliente Nome do Vendedor
CNPJ
IE
Projeto (CodProj, Tipo, Descricao, (CodEmpregado, NomeEmp, Categoria,
Salario, DataInicio, Tempo))

1FN

Projeto (CodProj, Tipo, Descricao)

EmpProj(CodEmpregado, CodProj, NomeEmp, Categoria, Salario, DataInicio,
Tempo)
Projeto (CodProj, Tipo, Descricao, (CodEmpregado, NomeEmp, Categoria,
Salario, DataInicio, Tempo))

Projeto (CodProj, Tipo, Descricao)

EmpProj(CodEmpregado, CodProj, NomeEmp, Categoria, Salario, DataInicio,
Tempo)
 A segunda forma normal (2FN) analisa se
algum atributo possui dependência da chave
primária.

 Esse caso aplica-se, somente, para entidades

cuja chave primária é composta, ou seja, cuja
chave primária possua mais de um atributo
para garantir a unicidade de suas ocorrências.
 É a principal ferramenta de avaliação para
identificar se o agrupamento de atributos de
uma tabela está apropriado.

◦ Evitando redundância de dados

◦ Inconsistências

◦ Perda de dados em operações de remoções ou

alterações
 A segunda forma normal (2FN) estabelece
que uma entidade está em conformidade com
ela somente se:
◦ Estiver na 1FN; e
◦ Não possuir atributos com dependência parcial da
chave primária
 Obs: esse caso aplica-se, somente, para entidades cuja
chave primária é composta, ou seja, cuja chave
primária possua mais de um atributo para garantir a
unicidade das ocorrências.
 A passagem à segunda forma normal (2FN)
objetiva eliminar um certo tipo de
redundância de dados.
 Mas o que é Dependência Funcional?

◦ Total

◦ Parcial

◦ Transitiva
◦ Obs1: para o entendimento das dependências funcionais total e
parcial considere uma situação simples em que temos a tabela
ALOCAÇÃO, a qual se refere a alocação de empregados a projetos.
◦ Obs2: para o entendimento da dependência funcional transitiva
considere a tabela EMPREGADO.
 Os atributos não chave de uma tabela têm
que depender totalmente da chave primária e
somente dela.
 Ex: Uma determinada tabela possui sua chave
primária composta pelos atributos A e B.
Logo, C será dependente funcional total se e
somente se C depender funcionalmente de A
e B.

A B C
 Os atributos não chave de uma tabela
dependem de parte da chave primária.
 Ex: Uma determinada tabela possui sua chave
primária composta pelos atributos A e B.
Logo, C será dependente funcional parcial se
e somente se o atributo C depender
funcionalmente de A ou B.

A B C
 Solução para dependência funcional parcial
 O atributo C é dependente funcional
transitivo de A se C é funcionalmente
dependente de B e B funcionalmente
dependente de A, na mesma tabela.

A B C
 Relembrando:
◦ Uma tabela está na 2FN se ela já estiver na 1FN;
◦ Todo atributo que não for chave primária for
dependente funcional TOTAL.
◦ Ou seja, não deve existir dependência funcional
parcial.

A B C
 Solução para dependência funcional parcial
(relembrando)
Projeto (CodProj, Tipo, Descricao, (CodEmpregado, NomeEmp, Categoria,
Salario, DataInicio, Tempo))

Projeto (CodProj, Tipo, Descricao)

EmpProj(CodEmpregado, CodProj, NomeEmp, Categoria, Salario, DataInicio,
Tempo)
 Os dados referentes a empregados (Nome,
Cat e Sal) estão redundantes, para os
empregados que trabalham em mais de um
projeto.
 Um exemplo é o do empregado de código
“8191”. A passagem à segunda forma normal
objetiva eliminar este tipo de redundância de
dados.
 Veja o exemplo:

2FN
Projeto (CodProj, Tipo, Descricao, (CodEmpregado, NomeEmp, Categoria,
Salario, DataInicio, Tempo))
1FN
Projeto (CodProj, Tipo, Descricao)
EmpProj(CodEmpregado, CodProj, NomeEmp, Categoria, Salario, DataInicio,
Tempo)
2FN
Projeto (CodProj, Tipo, Descricao)
EmpProj(CodEmpregado, CodProj, DataInicio, Tempo)
Empregado(CodEmpregado, NomeEmp, Categoria, Salario)
Projeto (CodProj, Tipo, Descricao)
EmpProj(CodEmpregado, CodProj, DataInicio, Tempo)
Empregado(CodEmpregado, NomeEmp, Categoria, Salario)

Após aplica a 2FN percebe-se

que ainda é necessário trabalhar
a tabela Empregado
 Uma tabela está na 3FN se ela já estiver na
2FN.
 Não deve existir dependência funcional
transitiva entre atributos, ou conjunto de
atributos, não pertencentes à chave primária.
 Todos os atributos que não pertencem à
chave primária dependerem exclusivamente
da chave primária.
 Relembrando

A B C
 Uma dependência funcional transitiva ou
indireta acontece quando uma coluna não
chave primária depende funcionalmente de
outra coluna ou combinação de colunas não
chave primária.
 A passagem à 3FN consta em dividir tabelas
de forma a eliminar as dependências
transitivas.
 Dependência transitiva
 Veja o exemplo:

A B C

3FN
 Resultado:

Projeto (CodProj, Tipo, Descricao)

ProjEmp (CodProj, CodEmp, DataInicio, Tempo)
Empregado (CodEmp, Nome, Categoria)
Categorias (Categoria, Salario)
Projeto (CodProj, Tipo, Descricao, (CodEmpregado, NomeEmp, Categoria,
Salario, DataInicio, Tempo))
1FN
Projeto (CodProj, Tipo, Descricao)
EmpProj(CodEmpregado, CodProj, NomeEmp, Categoria, Salario, DataInicio,
Tempo)
2FN
Projeto (CodProj, Tipo, Descricao)
ProjEmp(CodProj, CodEmpregado, DataInicio, Tempo)
Empregado(CodEmpregado, NomeEmp, Categoria, Salario)

3FN

Projeto (CodProj, Tipo, Descricao)

ProjEmp(CodProj, CodEmpregado, DataInicio, Tempo)
Empregado(CodEmpregado, NomeEmp, Categoria)
Categorias (Categoria, Salario)
 A normalização permite evitar anomalias de
inserção, alteração e exclusão de dados

 O objetivo NÃO é melhorar performance de

consultas

 Projetos conceituais bem feitos naturalmente

resultam em esquemas normalizados
 Considere a tabela FATURA a seguir para analisar se a
mesma está de acordo com as 3 formas normais (1FN,
2FN e 3FN).
 Dica:
◦ Liste os atributos para a entidade FATURA
Ex: Para aplicar a 1FN (não deve
NumeroFatura
DataEmissao
DataVencimento possuir atributos multivalorados
NomeConveniada ou grupos repetitivos) é feita a
CodigoConveniada
transformação dos atributos
multivalorados em ocorrências.
CNPJ
Endereco
Descricao Servico 1 - Data da corrida Nesse caso, percebe-se que a
Descricao Servico 1 - Numero Boleto descrição do serviço se repete n
Descricao Servico 1 - Valor da corrida
vezes e é composto pelos
Descricao Servico 2 - Data da corrida
Descricao Servico 2 - Numero Boleto atributos Data da corrida, Numero
Descricao Servico 2 - Valor da corrida Boleto e Valor da corrida
Descricao Servico n - Data da corrida
Descricao Servico n - Numero Boleto
Descricao Servico n - Valor da corrida
 1FN: uma entidade “não deve possuir
atributos multivalorados ou grupos
repetitivos”

 Nesse caso o grupo repetitivo é a descrição

do serviço que repete n vezes e é composto
pelos atributos data da corrida, número do
boleto e valor da corrida.
 Verificar o que se repete
NumeroFatura
DataEmissao
DataVencimento
NomeConveniada
CodigoConveniada
CNPJ
Endereco
Data da corrida (*)
Numero Boleto (*)
Valor da corrida (*)
SubTotal
TaxaAdm
Total
1) Criar uma nova entidade (tabela) que contenha os
atributos que formam a chave primária e os
atributos multivalorados ou grupos repetitivos
2) Reorganizar a entidade inicial sem os atributos
multivalorados ou grupos repetitivos

 Defina uma nova entidade com o nome FaturaItem.

Nesse caso, os atributos que formam a chave
primária, agora, serão numeroFatura,
codigoConveniada e numeroCorrida, além de serem
acrescentados os atributos dataCorrida e
valorCorrida.
Fatura(NumeroFatura, DataEmissao, DataVencimento,
CodigoConveniada, NomeConveniada, CNPJ, Endereco,
Data da corrida (*), Numero Boleto (*), Valor da corrida
(*)), SubTotal, TaxaAdm, Total)

1FN

Fatura(NumeroFatura, DataEmissao, DataVencimento,

CodigoConveniada, NomeConveniada, CNPJ, Endereco,
SubTotal,TaxaAdm, Total)
FaturaItem (NumeroFatura, CodigoConveniada, Numero
Boleto, Data da corrida, Valor da corrida)
A 2FN analisa se algum atributo possui
dependência parcial da chave primária e irá se
aplicar para a entidade cuja chave primária é
composta, e nesse caso será necessário:

1) Criar uma nova entidade (tabela), contendo

atributos que possuam dependência parcial da
chave primária, juntamente com o atributo que é
parte da chave primária
2) Reorganizar a entidade (tabela) inicial sem os
atributos que continham dependência parcial da
chave primária
Fatura(NumeroFatura, DataEmissao, DataVencimento,
CodigoConveniada, NomeConveniada, CNPJ, Endereco,
SubTotal, TaxaAdm, Total)
FaturaItem (NumeroFatura, CodigoConveniada, Numero
Boleto, Data da corrida, Valor da corrida)

2FN (Dependência Parcial)

Fatura(NumeroFatura, DataEmissao, DataVencimento,
SubTotal,TaxaAdm, Total, CodigoConveniada)
Conveniada(CodigoConveniada, NomeConveniada, CNPJ,
Endereco)
Obs: a chave primária da entidade Conveniada foi
propagada como chave estrangeira na entidade fatura
FaturaItem (NumeroFatura, CodigoConveniada, Numero
Boleto, Data da corrida, Valor da corrida)
3FN (somente seria identificada caso o endereço fosse
desmembrado em CEP, tituloLogradouro, nomeLogradouro,
numeroLogradouro, complemento, bairro, cidade, UF)

Fatura(NumeroFatura, DataEmissao, DataVencimento,

SubTotal,TaxaAdm, Total, CodigoConveniada)

Conveniada(CodigoConveniada, NomeConveniada, CNPJ, CEP,

tituloLogradouro, nomeLogradouro, numeroLogradouro,
complemento, bairro, cidade, UF)
FaturaItem (NumeroFatura, CodigoConveniada, Numero
Boleto, Data da corrida, Valor da corrida)
Conveniada(CodigoConveniada, NomeConveniada, CNPJ, CEP,
tituloLogradouro, nomeLogradouro, numeroLogradouro,
complemento, bairro, cidade, UF)

3FN

Conveniada(CodigoConveniada, NomeConveniada, CNPJ, cep,

numeroLogradouro, complemento)

CEP (cep, tituloLogradouro, nomeLogradouro, bairro, cidade,

UF)
Fatura(NumeroFatura, DataEmissao, DataVencimento,
SubTotal,TaxaAdm, Total, CodigoConveniada)

FaturaItem (NumeroFatura, CodigoConveniada, Numero

Boleto, Data da corrida, Valor da corrida)

Conveniada(CodigoConveniada, NomeConveniada, CNPJ,

cep, numeroLogradouro, complemento)

CEP (cep, tituloLogradouro, nomeLogradouro, bairro,

cidade, UF)