Normalização
Álvaro Vinícius de Souza Coêlho
[email protected]
Dependência Funcional
• “Dada uma tabela T, a coluna Y de T é
funcionalmente dependente da coluna X de
T se e somente se cada valor de Y em T
tiver a ele associado precisamente um valor
X em T”
Dependência Funcional
• Opcionalmente, diz-se que X determina Y
• Exemplos
– Matrícula determina Nome_Aluno (e endereço,
telefone, etc.)
– Placa determina Veículo
– Número determina Competidor
Dependência Funcional
• A coluna determinante pode ser composta
– (Aluno, Disciplina) determina Média
– (Veículo, Condutor, Data) determina Multa
• Existem tipos variados de dependência
funcional
– Transitiva
– Multivalorada
– de Junção
Dependência Funcional
• Chaves: “Coluna que funciona como
determinante funcional em uma tabela”
• Em Bancos de Dados Relacionais
– Colunas que orientam para a seleção de uma ou
mais linhas específicas em uma tabela
Dependência Funcional
• Exemplos de chaves
– A matrícula de um aluno (existe outro com a
sua?)
– A Placa de um carro (ou o número do Chassi,
ou o Renavam)
– O Número de Inscrição de um competidor (só
há um piloto com o carro número 1)
Dependência Funcional
• O CRA de um médico mais a Identificação
de um plano de saúde identifica somente
uma inscrição (Não dá para um CRA
aparecer duas vezes na UNIMED).
Dependência Funcional
• Chave primária – Conjunto único de
colunas (muitas vezes unitário) escolhido
como identificador de uma Linha (como nos
exemplos acima)
Dependência Funcional
• Chave Alternativa (ou candidata) - Conjunto
único de colunas (normalmente unitário)
que pode ser usado alternativamente como
chave primária (como o número de chassis
no lugar da placa do veículo).
Dependência Funcional
• Chave Estrangeira - Conjunto de colunas
(muitas vezes unitário) que aponta uma
Linha em outra tabela (é chave primária de
outra tabela)
Dependência Funcional
• Exemplo:
– Tabela (Vendedor#, NumNota, Loja#)
– Colunas Vendedor# e Loja# são identificadores
únicos (Chaves Primárias) em outras tabelas
que contém:
– Mais dados do vendedor – salário, nome, etc.
– Ou da Loja – razão social, endereço, etc.
Normalização
• Normalização: “Colocar relações dentro de
uma organização tal que atenda a um
conjunto específico de restrições”
– Usualmente determina-se 3 formas normais
(acrescidas eventualmente de mais uma), que
podem ser estendidas em mais 2.
– mas no total são 8
Normalização
• Porque?
• Para diminuir as dificuldades e os
problemas (anomalias) em operações de
transação (inclusão, exclusão, alteração) nos
dados.
Primeira Forma Normal
• 1FN: “Uma tabela está na 1FN sse todos os
domínios básicos contiverem somente
valores atômicos”
• Toda tabela que não possua colunas
multivaloradas está na 1FN.
– Tabelas em Bancos de Dados Relacionais
tradicionais estão necessariamente na 1FN.
Primeira Forma Normal
• Ex: R1(F#, Status, Cidade, P#, Qtd) onde.
– F# é o número do Fornecedor (uma chave
estrangeira)
– Status é a situação atual (em termos de
probabilidade de negócio) de uma cidade
– P# é a identificação (código) de uma peça
(outra chave estrangeira)
– Cidade e Qtd são auto-explicativos.
Primeira Forma Normal
• R1
F#
Status
Cidade
P#
Qtd
F1
20
Itabuna
P1
300
F1
20
Itabuna
P2
200
F1
20
Itabuna
P3
400
F1
20
Itabuna
P4
200
F1
20
Itabuna
P5
100
F1
20
Itabuna
P6
100
Primeira Forma Normal
• R1 (continuação)
F2
F2
F3
F4
F4
F4
10
10
10
20
20
20
Ilhéus
Ilhéus
Ilhéus
Itabuna
Itabuna
Itabuna
P1
P2
P2
P2
P4
P5
300
400
200
200
300
400
Primeira Forma Normal
• R1 está na 1FN!
• Anomalias
– Inclusão: Só se sabe que um fornecedor está em
uma determinada cidade quando ele passa a
oferecer alguma peça
Primeira Forma Normal
• Anomalias
– Exclusão: Se for excluída a última linha de um
fornecedor, não se saberá mais em que cidade
ele está
– Alteração: Se um fornecedor troca de cidade,
muitas linhas precisam ser alteradas (sob pena
de haver inconsistência!)
Segunda Forma Normal
• Qual o problema?
• Há dependência entre colunas não chave e
chaves diferentes ao mesmo tempo
• F# determina Cidade e o par F# e P#
determina Qtd
Segunda Forma Normal
• 2FN: “Uma tabela está na 2FN sse ela está
em 1FN e todas as colunas não-chave forem
totalmente dependentes da chave primária”
Segunda Forma Normal
• R2(F#, Status, Cidade) e FP(F#, P#, Qtd)
F#
F1
F2
F3
F4
F5
Status
20
10
10
20
30
Cidade
Itabuna
Ilhéus
Ilhéus
Itabuna
Itapetin
ga
Segunda Forma Normal
• FP(F#, P#, Qtd) (continuação)
F#
F1
F1
F1
F1
F1
F1
P#
P1
P2
P3
P4
P5
P6
Qtd
300
200
400
200
100
100
F2
F2
F3
F4
F4
F4
P1
P2
P2
P2
P4
P5
300
400
200
200
300
400
Segunda Forma Normal
• R2 e FC estão na 2FN!
• Observar que não há perda de informação!
• Anomalias
– Inclusão: O Status de uma cidade só é
determinado se houver algum fornecedor para
ela
Segunda Forma Normal
• Anomalias
– Exclusão: Removendo-se o último fornecedor
de uma cidade, perde-se o seu Status
– Atualização: Para se substituir o Status de uma
cidade, muitas linhas precisam ser trocadas
Terceira Forma Normal
• Qual o problema?
• Há dependência entre colunas não chave e
outras colunas também não chave.
• Dependência funcional transitiva:
– “Diz-se que A depende transitivamente de C se
A depende de B e B depende de C”
Terceira Forma Normal
• No exemplo,
– Status depende de Cidade, e Cidade depende de
F#.
– Daí que Status depende transitivamente de F#
Terceira Forma Normal
• 3FN: “Uma tabela está na 3FN sse está na
2FN e todos as colunas não-chave forem
dependentes não transitivas da chave
primária”
Terceira Forma Normal
• FC(F#, Cidade) CS(Cidade, Status)
P#, Qtd)
F#
F1
F2
F3
F4
F5
Cidade
Itabuna
Ilhéus
Ilhéus
Itabuna
Itapetinga
FP(F#,
Cidade
Status
Itabuna
30
Ilhéus
20
Itapetinga
10
Terceira Forma Normal
• FC(F#, Cidade)
CS(Cidade, Status)
• FC, CS E FP estão na 3FN!
S#
F1
F1
F1
F1
F1
F1
P#
P1
P2
P3
P4
P5
P6
Qtd
300
200
400
200
100
100
F2
F2
F3
F4
F4
F4
P1
P2
P2
P2
P4
P5
FP(F#, P#, Qtd)
300
400
200
200
300
400
Forma Normal de Boyce-Codd
• Forma normal de Boyce-Codd (BCNF):
“Uma tabela está em BCNF se cada
determinante for candidato a chave
primária”
• Pra que essa novidade?
Forma Normal de Boyce-Codd
• Suposição:
Há
um
“Cadastro
de
Fornecedores” F(F#, FNome, ...). Sendo que
FNome é chave candidata (alternativa), pois
também é única.
• A relação alternativa FP’(F#, FNome, P#,
Qtd) está na 3FN?
Forma Normal de Boyce-Codd
• Vejamos:
– Não há colunas multivaloradas. Logo, está na
1FN
– A chave é (F#, P#). Todos os demais colunas
dependem dela. Logo, está na 2FN
– Não há dependência entre Qtd e FNome ou
vice-versa (as colunas não-chave). Logo, está
na 3FN
• Resposta: SIM!
Forma Normal de Boyce-Codd
• Mas não está na BCNF.
• Anomalias:
– Alteração: Para se trocar o nome de um
fornecedor, muitas linhas terão que ser
modificadas, ou gera-se inconsistência
• Esta Forma normal é, então, interessante
como um aperfeiçoamento da 3a forma.
Quarta Forma Normal
• Dependência de Múltiplos Valores (ou
Multivalorada)
• Até o presente estudo a Dependência
Funcional é o fato de que uma coluna
determina unicamente o valor de outra
– Não é, porém, a visão mais completa
Quarta Forma Normal
• Tomemos um exemplo:
• (Projeto, Funcionários, Computadores)
• Um projeto tem vários funcionários
alocados para ele, e será desenvolvido em
vários computadores.
• Cada computador e cada funcionário é
associado a apenas um projeto
Quarta Forma Normal
• Uma visão (não normalizada) seria:
P#
FNome
C#
P1
José
João
Carlos
Ana
C1
C5
C4
C6
C7
C2
C3
P2
P3
Pedro
Marta
Julia
Quarta Forma Normal
• Como se poderia implementar isso num
Banco de Dados Relacional?
• Uma alternativa seria a criação de uma
tabela PFC(P#, Fnome, C#) com todas as
combinações de alocações possíveis
Quarta Forma Normal
• Ficaria:
P#
Fnome
C#
P1
José
C1
P1
José
C5
P1
João
C1
P1
João
C5
P2
Carlos
C4
P2
Carlos
C6
P2
Carlos
C7
Quarta Forma Normal
• Continuação:
P2
Ana
C4
P2
Ana
C6
P2
Ana
C7
P3
Pedro
C2
P3
Pedro
C3
P3
Marta
C2
P3
Marta
C3
P3
Julia
C2
P3
Julia
C3
Quarta Forma Normal
• A relação PFC está na 3FN?
– Não possui multivalorados
– Não possui dependências parciais
– Não possui dependências transitivas
• SIM!
• Está na BCNF?
– Todo mundo é chave (não há determinantes não chaves
candidatos)
• SIM!
Quarta Forma Normal
• Anomalias:
• De inclusão: Como incluir um novo projeto
ainda sem computador e/ou funcionários?
• De exclusão: Excluindo-se todos os
computadores de um projeto, como saber os
funcionários dele?
Quarta Forma Normal
• Anomalias:
• De alteração
– Trocar um computador de um projeto para
outro, ou um funcionário: Alteração de várias
linhas
– Alocar mais um computador ou funcionário
para um projeto: Idem
Quarta Forma Normal
• Qual o problema?
• Há uma dependência multivalorada: Apesar
de não determinar unicamente um
funcionário ou um computador, P#
determina um conjunto bem definido e
único de C# ou de FNome
Quarta Forma Normal
• Dependência de Múltiplos Valores (MVD):
• Dada uma relação R com atributos A, B e C,
a dependência de múltiplos valores R.A
R.B vale para R sse o conjunto de
valores que se combinam com um dado par
(valores de A e de C) depender somente de
A e for independente de C.
Quarta Forma Normal
• MVD R.A R.B  R.A R.C
– Se R.A determina multivaloradamente R.B,
então também determina multivaloradamente
R.C
• MVD R.A R.B|R.C
• Como na dependência funcional vista até
agora uma coluna determina apenas um
elemento em outra, pode-se dizer que a DP
é um caso especial de MVD
Quarta Forma Normal
• 4NF: Uma relação R está na quarta forma
normal sse sempre que existir uma MVD em
R (AB), todos os atributos de R sejam
funcionalmente dependentes de A ( ou seja, A
X para qualquer X em R)
Quarta Forma Normal
• Como fica?
– Cria-se uma tabela PF(P#, Fnome) e uma tabela
PC(P#, C#)
• Temos P#  Fnome e P#C#
• Ou P#  C# e P#Fnome
• Atendendo à 4FN
Quarta Forma Normal
• Relações:
P#
Fnome
P#
C#
P1
José
P1
C1
P1
João
P1
C5
P2
Carlos
P2
C4
P2
Ana
P2
C6
P3
Pedro
P2
C7
P3
Marta
P3
C2
P3
Julia
P3
C3
Normalização
• De modo geral os diagramas de modelagem
de dados (diagramas de classes, MER, etc.)
tendem a distribuir os dados já na 3FN,
normalmente já na BCNF, salvo raríssimas
exceções
• Em circunstâncias de projeto, com
freqüência, considerações de performance
acabam se impondo à observância das
Formas Normais
Normalização
• Projetos
de
bancos
de
dados
multidimensionais ou OLAP não devem se
espelhar na normalização tradicional
• A Normalização destina-se a atender melhor
às transações (OLTP)
Normalização.
FIM!
Manet
“Qualquer idéia, por mais simples que seja, pode
ser expressa em termos complicados”
Lei de Murphy aplicada à Tecnocracia