Instituto Federal de Educação, Ciência e
Tecnologia de São Paulo - IFSP
Campus de Caraguatatuba
Tecnólogo em Análise e Desenvolvimento de Sistemas
10 Semestre de 2013
Banco de Dados I – BD I
Prof. Lineu Mialaret
Aula 18: Teoria da Normalização
Banco de Dados I
Aula 18 - 1/68
©Prof. Lineu Mialaret
Desenvolvimento de Aplicativos de BD
nome
Modelo Conceitual
Produto
preco
Pessoa
compra
nome
rg
Modelo Relacional
Normalização
Banco de Dados I
Aula 18 - 2/68
©Prof. Lineu Mialaret
Introdução (1)
 Normalização é uma técnica para produzir relações (tabelas) com
propriedades desejáveis. É formalmente fundamentada em conceitos
matemáticos.
 Por meio do processo de normalização, pode-se substituir ou
decompor, gradativamente, um conjunto de tabelas por um outro,
mais adequado, que contenha uma menor redundância de dados.
 Esta decomposição requer que nenhuma informação seja perdida e a
reconstrução das tabelas originais seja possível.
 O conceito de normalização foi introduzido por E. F. Codd em 1970, e
desde então vem sendo muito estudado na pesquisa científica em
Tecnologia de de Banco de Dados.
 A normalização pode ser:
 Utilizada depois da modelagem conceitual ou de forma independente.
 Especialmente útil para base de dados que já tenham sido projetadas e
implementadas sem o uso de técnicas formais.
Banco de Dados I
Aula 18 - 3/68
©Prof. Lineu Mialaret
Introdução (2)
 O propósito da normalização é desenvolver esquemas relacionais que
minimizem redundâncias e anomalias de atualizações.
 Redundância ocorre quando o mesmo valor de dado ou informação é
armazenado mais de uma vez na tabela. Redundância ocupa espaço
e reduz a performance do SGBD.
 Anomaly: is an undesirable consequence of a data modification.
 Anomalias de Atualização surgem quando se tenta inserir, remover ou
atualizar linhas numa tabela. Essa anomalias numa base de dados
surgem devido a ocorrência de, por exemplo:
 Grupos repetitivos de dados.
 Dependências parciais de chave.
 Inexatidão de representações de fatos da realidades (modelos).
 Dependências transitivas entre atributos.
Banco de Dados I
Aula 18 - 4/68
©Prof. Lineu Mialaret
Introdução (3)
 Todas essas dificuldades podem ser reduzidas ou minimizadas por
meio do uso da técnica de normalização.
 Esta técnica torna o Modelo Relacional que se está utilizando,
bastante estável, isto é, sujeito a poucas manutenções.
 Resumindo:
 O objetivo da normalização é produzir um conjunto de esquemas
relacionais ajustados R1,R2,...,Rm de um conjunto de atributos
A1,A2,A3,...,An.
 Supondo que todos os atributos estejam originalmente em uma grande
relação R = {A1,A2,...,An}, a qual pode ser chamada de relação universal,
a normalização vai dividir essa relação em várias relações otimizadas
R1,R2,...,Rm.
Banco de Dados I
Aula 18 - 5/68
©Prof. Lineu Mialaret
Anomalias de Atualização (1)
 Há três principais tipos de anomalias de atualização:
 Anomalia de inserção, onde a inserção de uma linha numa tabela requer a
inserção de informação redundante ou não pode ser realizada por atribuir
valores nulos para atributos chaves.
 Anomalia de remoção, em que a remoção de uma linha da tabela pode
causar a perda de informação que ainda precisa ser armazenada.
 Anomalia de modificação, quando a mudança de um atributo de uma linha
da tabela pode exigir múltiplas mudanças desse valor em várias outras
linhas da mesma.
Banco de Dados I
Aula 18 - 6/68
©Prof. Lineu Mialaret
Anomalias de Atualização (2)
 Seja a seguinte tabela COMPANHIA que representa informações
sobre uma determinada companhia.
COMPANHIA
Nome
Endereco
DataFundacao
NomeDono
Cargo
#Acoes
 Se a companhia possui três donos, há três linhas na tabela
COMPANHIA para esta empresa.
COMPANHIA
Nome
Endereco
DataFundacao
NomeDono
Cargo
#Acoes
Walita
Rua X
1970
José
Presidente
500
Walita
Rua X
1970
João
Gerente
400
Walita
Rua X
1970
Joaquim
Supervisor
100
Banco de Dados I
Aula 18 - 7/68
©Prof. Lineu Mialaret
Anomalias de Atualização (3)
COMPANHIA
Nome
Endereco
DataFundacao
NomeDono
Cargo
#Acoes
Walita
Rua X
1970
José
Presidente
500
Walita
Rua X
1970
João
Gerente
400
Walita
Rua X
1970
Joaquim
Supervisor
100
 Se a companhia muda para um novo endereço, o mesmo (novo
endereço) deve ser atualizado consistentemente em todas as três
linhas da tabela COMPANHIA:
 A atualização em apenas uma ou duas linhas da tabela deixará o banco
de dados num estado inconsistente (ou seja, gera uma anomalia).
 Seria melhor ou mais adequado se o nome e o endereço da
companhia estivessem numa tabela separada de modo que o
endereço de cada companhia aparecesse em uma só linha dessa
tabela.
Banco de Dados I
Aula 18 - 8/68
©Prof. Lineu Mialaret
Anomalias de Atualização (4)
 Supondo que duas pessoas criem uma nova empresa e que:
 Os dois fundadores ainda não possuem cargos.
 A distribuição do número de ações também não foi definida.
 A nova empresa pode não ser inserida na tabela COMPANHIA pois
não não há bastante informação para preencher todos aos atributos
de uma linha da tabela, ou no máximo, valores nulos deverão ser
usados para preencher uma linha.
 Seria
mais adequado que as informações sobre cargos e
quantidade de ações fossem armazenadas numa tabela diferente.
COMPANHIA
Nome
Endereco
DataFundacao
NomeDono
Cargo
#Acoes
Walita
Rua X
1970
José
Presidente
500
Walita
Rua X
1970
João
Gerente
400
Walita
Rua X
1970
Joaquim
Supervisor
100
Xerox
Rua Y
2004
Jairo
Null
Null
Xerox
Rua Y
2004
James
Null
Null
Banco de Dados I
Aula 18 - 9/68
©Prof. Lineu Mialaret
Anomalias de Atualização (5)
 Supondo que um dos donos da companhia se retire do negócio
mas ainda continue de posse de ações da mesma.
 Se a linha da tabela COMPANHIA referente a esse dono é
removida, perde-se a informação de quantas ações (#Acões) ele
possui.
 Se essa informação (a quantidade de ações possuída) estivesse
armazenada numa tabela diferente, poderia-se manter ela
armazenada, mesmo depois que a pessoa deixasse de ser dona
da companhia.
COMPANHIA
Nome
Endereco
DataFundacao
NomeDono
Cargo
#Acoes
Walita
Rua X
1970
José
Presidente
500
Walita
Rua X
1970
João
Gerente
400
Walita
Rua X
1970
Joaquim
Supervisor
100
Banco de Dados I
Aula 18 - 10/68
©Prof. Lineu Mialaret
Exemplo de Anomalia
 Seja a seguinte tabela exemplo EMPDEPT:
EMPDEPT
 Seja a seguinte atualização nesta tabela:
 Inserir um departamento D4 que não possui empregados ainda.
 O que ocorre?
Banco de Dados I
Aula 18 - 11/68
©Prof. Lineu Mialaret
Propriedades Desejáveis de BD´s
 A técnica de normalização refere-se ao processo de converter um
Modelo Relacional arbitrário em outro com melhores propriedades
operacionais.
 Projetar um Banco de Dados Relacional não é apenas uma questão
de especificar um conjunto de tabelas, que contém todos os atributos
requeridos.
 Tabelas que são bem projetadas possuem várias importantes
características:
 A mais importante propriedade básica que a tabela possui é que seus
atributos são relacionados logicamente, ou seja os atributos nativos de
uma tabela devem se referir a uma mesma entidade ou relacionamento.
 A propriedade de lossless-join garante que a informação decomposta em
muitas tabelas pode ser reconstruida usando-se junções naturais.
 A propriedade de preservação de dependências garante que as
restrições (requsitos) na tabela original podem ser reforçadas nas
relações normalizadas.
 Dessa forma, a normalização tem por objetivo produzir um Modelo
Relacional que garanta a integridade dos dados, uma redundância
mínima e sua evolução com o mínimo de efeito colateral.
Banco de Dados I
Aula 18 - 12/68
©Prof. Lineu Mialaret
Formas Normais (1)
 Uma tabela está numa particular Forma Normal – FN, se ela satisfaz
certas propriedades de normalização, ou seja, se ela atende os
requisitos de uma determinada forma normal.
 Há várias formas normais definidas:
Níveis de Formas Normais
 1NF – First Normal Form (Primeira Forma Normal)
 2NF – Second Normal Form (Segunda Forma Normal)
 3NF – Third Normal Form (Terceira Forma Normal)
 BCNF – Boyce-Codd Normal Form (Forma Normal de Boyce-Codd)
 4NF – Fourth Normal Form (Quarta Forma Normal)
 5NF – Fifth Normal Form (Quinta Forma Normal)
 DK/NF – Domain/Key Normal Form (Forma Normal de Domínio/Chave)
 A teoria da normalização é tradicionalmente expressa por meio de um
conjunto de formas normais, as quais progressivamente otimizam as
estruturas esquemáticas das tabelas de um Banco de Dados.
Banco de Dados I
Aula 18 - 13/68
©Prof. Lineu Mialaret
Formas Normais (2)
DK/NF
 As formas normais são aninhadas (nesteds), ou seja, se uma
determinada tabela R está na Terceira Forma Normal – 3FN,
automaticamente ela está em 1FN e 2FN.
Banco de Dados I
Aula 18 - 14/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (1)
 Domínio de um atributo:
 O conjunto de possíveis valores permitidos a esse atributo.
 Exemplos de domínios:
X = { x   | x  -5 e x  5 }
Y={y|y0}
 Definição: Uma tabela está na Primeira Forma Normal - 1FN se, e
somente se, todos os seus atributos são atômicos. Grupos repetidos
de valores devem ser eliminados.
 Uma tabela se encontra na 1FN quando todos os atributos são
simples (não sendo admitidos itens estruturados ou itens repetitivos),
ou seja, o valor de uma coluna da tabela é indivisível (ou único).
 Quando uma tabela não está em 1FN diz-se que ela está em 0FN.
Banco de Dados I
Aula 18 - 15/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (2)
 A 1FN é o primeiro passo do processo de normalização. Ela elimina
os atributos multivalorados e compostos, permitindo apenas a
ocorrência de atributos atômicos.

Exemplo de uma tabela EMPREGADO na 0FN:
EMPREGADO
Matricula
120
Nome
CodCargo
João
01
NomeCargo
Programador
CodProj
DataFim
Horas
01
17/07/95
37
08
12/01/96
12
 Uma linha deve armazenar informações sobre os vários diferentes
projetos nos quais um determinado empregado já trabalhou:
 Caso se coloque estas informações numa tabela relacional, já se está
normalizando para a 1FN.
 Uma tabela no Modelo Relacional implicitamente já está em 1FN.
Banco de Dados I
Aula 18 - 16/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (3)
 Há dois modos de converter uma tabela 0FN numa tabela que se
encontre em 1FN.
 Método da Divisão (Division Method) - dividir a tabela existente em
duas tabelas, uma com os atributos não repetidos e a outra com os
atributos repetidos:
 Criar uma nova tabela contendo a chave primária original mais os
atributos monovalorados.
 Criar uma outra tabela tendo como chave primária a chave primária da
tabela original concatenada com algum atributo multivalorado, e tendo
como colunas os outros atributos multivalorados.
 Método da Planificação (Flatenning Method) - criar novas linhas para
os dados repetidos combinados com os dados que não são repetidos,
e gerar uma nova chave primária (chave primária antiga concatenada
com algum atributo multivalorado):
 Isto introduz redundância que será removida posteriormente pela
normalização.
Banco de Dados I
Aula 18 - 17/68
©Prof. Lineu Mialaret
1FN – Método da Divisão (1)
EMPREGADO
Matricula
120
121
270
CodCargo
1
1
2
NomeCargo
CodProj
Programador
DataFim
Horas
01
17/07/95
37
08
12/01/96
12
01
17/07/95
45
08
12/01/96
21
Programador
12
21/03/96
107
Analista
08
12/01/96
10
12
21/03/96
38
Programador
273
3
Projetista
01
17/07/95
22
274
2
Analista
12
21/03/96
31
279
1
Programador
01
17/07/96
27
08
12/01/96
20
12
21/03/96
51
301
1
Programador
12
21/03/96
16
306
3
Projetista
17
21/03/96
67
Tabela EMPREGADO na 0FN.
Banco de Dados I
Aula 18 - 18/68
©Prof. Lineu Mialaret
1FN – Método da Divisão (2)
EMPREGADO
Matricula
120
Nome
CodCargo
João
01
NomeCargo
CodProj
Programador
DataFim
Horas
01
17/07/95
37
08
12/01/96
12
Matricula
Nome
CodCargo
NomeCargo
Matricula
CodProj
120
João
1
Programador
120
01
17/07/95
37
121
Hélio
1
Programador
120
08
12/01/96
12
270
Gabriel
2
Analista
121
01
17/07/95
45
273
Silva
3
Projetista
121
08
12/01/96
21
274
Abraão
2
Analista
121
12
21/03/96
107
279
Carla
1
Programador
270
08
12/01/96
10
301
Ana
1
Programador
270
12
21/03/96
38
306
Manoel
3
Projetista
273
01
17/07/95
22
274
12
21/03/96
31
279
01
17/07/96
27
279
08
12/01/96
20
279
12
21/03/96
51
301
12
21/03/96
16
306
17
21/03/96
67
Banco de Dados I
Aula 18 - 19/68
DataFim
Horas
©Prof. Lineu Mialaret
1FN – Método da Divisão (3)
Banco de Dados I
Aula 18 - 20/68
©Prof. Lineu Mialaret
1FN – Método da Planificação (1)
Banco de Dados I
Aula 18 - 21/68
©Prof. Lineu Mialaret
1FN – Método da Planificação (2)
EMPREGADO
Matricula
120
Nome
CodCargo
João
01
NomeCargo
Programador
CodProj
DataFim
Horas
01
17/07/95
37
08
12/01/96
12
EMPREGADO
Matrícula
Nome
CodCargo
NomeCargo
CodProj
DataFim
Horas
120
João
1
Programador
01
17/07/95
37
120
João
1
Programador
08
12/01/96
12
121
Hélio
1
Programador
01
17/07/95
45
121
Hélio
1
Programador
08
12/01/96
21
121
Hélio
1
Programador
12
21/03/96
107
270
Gabriel
2
Analista
08
12/01/96
10
270
Gabriel
2
Analista
12
21/03/96
38
273
Silva
3
Projetista
01
17/07/95
22
274
Abraão
2
Analista
12
21/03/96
31
279
Carla
1
Programador
01
17/07/96
27
279
Carla
1
Programador
08
12/01/96
20
279
Carla
1
Programador
12
21/03/96
51
301
Ana
1
Programador
12
21/03/96
16
306
Manoel
3
Projetista
17
21/03/96
67
Banco de Dados I
Aula 18 - 22/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (4)
 Um dos objetivos da normalização é reduzir a redundância de dados,
porém com a tabela EMPREGADO apresentada anteriormente ainda
há a ocorrência dessa redundância.
 É necessário realizar outros passos de normalização para se ter um
bom projeto (eliminando-se desse modo as redundâncias).
 A 1FN ainda possui características indesejáveis.
 Uma tabela na 1FN pode apresentar anomalias de:
 Inclusão, Atualização e Remoção.
 É necessário refinar a normalização, e para isso usa-se o conceito de
Dependência Funcional - DF.
Banco de Dados I
Aula 18 - 23/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (5)
EMPREGADO
Matrícula
Nome
CodCargo
NomeCargo
CodProj
DataFim
Horas
120
João
1
Programador
01
17/07/95
37
120
João
1
Programador
08
12/01/96
12
121
Hélio
1
Programador
01
17/07/95
45
121
Hélio
1
Programador
08
12/01/96
21
121
Hélio
1
Programador
12
21/03/96
107
270
Gabriel
2
Analista
08
12/01/96
10
270
Gabriel
2
Analista
12
21/03/96
38
273
Silva
3
Projetista
01
17/07/95
22
274
Abraão
2
Analista
12
21/03/96
31
279
Carla
1
Programador
01
17/07/96
27
279
Carla
1
Programador
08
12/01/96
20
279
Carla
1
Programador
12
21/03/96
51
301
Ana
1
Programador
12
21/03/96
16
306
Manoel
3
Projetista
17
21/03/96
67
308
Mané
3
null
null
null
null
 Anomalia de Inserção: não se pode inserir um empregado sem que
este esteja alocado a um projeto, nem inserir um projeto sem que haja
um empregado trabalhando nele.
Banco de Dados I
Aula 18 - 24/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (6)
EMPREGADO
Matrícula
Nome
CodCargo
NomeCargo
CodProj
DataFim
Horas
120
João
1
Programador
01
17/07/95
37
120
João
1
Programador
08
12/01/96
12
121
Hélio
1
Programador
01
17/07/95
45
121
Hélio
1
Programador
08
12/01/96
21
121
Hélio
1
Programador
12
21/03/96
107
270
Gabriel
2
Analista
08
12/01/96
10
270
Gabriel
2
Analista
12
21/03/96
38
273
Silva
3
Projetista
01
17/07/95
22
274
Abraão
2
Analista
12
21/03/96
31
279
Carla
1
Programador
01
17/07/96
27
279
Carla
1
Programador
08
12/01/96
20
279
Carla
1
Programador
12
21/03/96
51
301
Ana
1
Programador
12
21/03/96
16
306
Manoel
3
Projetista
17
21/03/96
67
 Anomalia de Remoção: se for necessário remover um projeto, as
informações dos empregados que estiverem trabalhando apenas
naquele projeto serão perdidas.
Banco de Dados I
Aula 18 - 25/68
©Prof. Lineu Mialaret
1FN – 1a Forma Normal (7)
EMPREGADO
Matrícula
Nome
CodCargo
NomeCargo
CodProj
DataFim
Horas
120
João
1
Programador
01
17/07/95
37
120
João
1
Programador
08
12/01/96
12
121
Hélio
1
Programador
01
17/07/95
45
121
Hélio
1
Programador
08
12/01/96
21
121
Hélio
1
Programador
12
21/03/96
107
270
Gabriel
2
Analista
08
12/01/96
10
270
Gabriel
2
Analista
12
21/03/96
38
273
Silva
3
Projetista
01
17/07/95
22
274
Abraão
2
Analista
12
21/03/96
31
279
Carla
1
Programador
01
17/07/96
27
279
Carla
1
Programador
08
12/01/96
20
279
Carla
1
Programador
12
21/03/96
51
301
Ana
1
Programador
12
21/03/96
16
306
Manoel
3
Projetista
17
21/03/96
67
 Anomalia de Atualização: se um empregado for promovido de cargo,
deve-se atualizar os atributos CodCargo e NomeCargo em todas as
linhas nas quais este empregado está presente.
Banco de Dados I
Aula 18 - 26/68
©Prof. Lineu Mialaret
Dependência Funcional (1)
 O Modelo Relacional fundamentou, baseado na teoria de funções
da matemática, o conceito de Dependência Funcional - DF.
 Será utilizada a teoria de funções para explicar o conceito de
dependência funcional do Modelo Relacional.

Considere os seguintes conjuntos X e Y:
Banco de Dados I
X
Y
1
11
2
12
3
13
4
14
Aula 18 - 27/68
©Prof. Lineu Mialaret
Dependência Funcional (2)
 Observa-se que há uma dependência entre os valores dos
conjuntos, que pode ser expressa pela função f(x) = x + 10, ou seja,
y é função de x, ou y = f(x) = x + 10.
 Esta dependência pode também ser expressa através do gráfico
apresentado abaixo:
Y
13
12
11
0
0
Banco de Dados I
1
2
X
3
Aula 18 - 28/68
©Prof. Lineu Mialaret
Dependência Funcional (3)
 Agora, sejam os conjuntos apresentados abaixo:
CPF
Nome
1
José
2
João
3
Rui
4
Manoel
 Observa-se que há uma dependência entre os valores dos conjuntos,
que pode ser expressa pela função f(CPF) = nome.
 O atributo nome é função do atributo CFP, ou seja, se houver um
número de CPF,
correspondente.
Banco de Dados I
pode-se
encontrar
Aula 18 - 29/68
o
nome
da
pessoa
©Prof. Lineu Mialaret
Dependência Funcional (4)
 Esta dependência é expressa no Modelo Relacional da seguinte
maneira:
CPF  NOME
 Lê-se a notação acima do seguinte modo:
 Com um número de CPF pode-se encontrar o nome da pessoa, ou ainda
 O nome da pessoa depende funcionalmente do CPF.
 Há uma série de regras formais para se manipular e raciocinar sobre
dependências funcionais.
 O Axioma de Armstrong estabelece várias regras de inferência para
dependências funcionais.
Banco de Dados I
Aula 18 - 30/68
©Prof. Lineu Mialaret
Dependência Funcional (5)
 Definição: Dada uma tabela R e os atributos X e Y, um atributo Y é
funcionalmente dependente do atributo X se, e somente se, para
cada valor de X está associado apenas um valor de Y.
 Em outras palavras, o atributo X determina univocamente Y.
 Simbologia:
X  Y,
onde lê - se: X funcionalmente determina Y
Y é funcionalmente dependente de X
Y é função de X.
 Para cada valor de X só existe um valor de Y.
Banco de Dados I
Aula 18 - 31/68
©Prof. Lineu Mialaret
Dependência Funcional (6)
 Exemplo:
 O atributo eno determina funcionalmente o atributo ename.
 Ou seja, pode-se dizer que eno  ename.
Banco de Dados I
Aula 18 - 32/68
©Prof. Lineu Mialaret
Dependência Funcional (7)
Matricula
Nome
CodCargo
NomeCargo
CodProj
DataFim
Horas
120
João
1
Programador
01
17/07/95
37
120
João
1
Programador
08
12/01/96
12
121
Hélio
1
Programador
01
17/07/95
45
121
Hélio
1
Programador
08
12/01/96
21
121
Hélio
1
Programador
12
21/03/96
107
270
Gabriel
2
Analista
08
12/01/96
10
270
Gabriel
2
Analista
12
21/03/96
38
273
Silva
3
Projetista
01
17/07/95
22
274
Abraão
2
Analista
12
21/03/96
31
279
Carla
1
Programador
01
17/07/96
27
279
Carla
1
Programador
08
12/01/96
20
279
Carla
1
Programador
12
21/03/96
51
301
Ana
1
Programador
12
21/03/96
16
306
Manoel
3
Projetista
17
21/03/96
67
 Exemplo: na tabela EMPREGADO acima há três linhas com valor 121
para matrícula, com o mesmo valor no atributo Nome (Hélio). Há um
relacionamento semelhante entre Matricula e Nome nas demais linhas.
 O atributo Nome é funcionalmente dependente de Matricula. Os
atributos CodCargo e NomeCargo também são funcionalmente
dependentes do atributo Matricula.
Banco de Dados I
Aula 18 - 33/68
©Prof. Lineu Mialaret
Dependência Funcional (8)
 Uma dependência funcional tem o lado esquerdo denominado de
determinante, podendo ser um conjunto de atributos e um atributo do
lado direito (que também pode ser um conjunto de atributos).
 Exemplo:
eno, pno  hours
Banco de Dados I
Aula 18 - 34/68
©Prof. Lineu Mialaret
Dependência Funcional (9)
 Geralmente há um só atributo do lado direito, mas pode-se combinar
várias dependências funcionais em uma só.
 Exemplo:
eno, pno  hours
eno, pno  resp
eno, pno  hours, resp
Banco de Dados I
Aula 18 - 35/68
©Prof. Lineu Mialaret
Dependência Funcional (10)
 Restrições (constraints) são regras que se aplicam a base de dados e
limitam os valores de dados que podem ser armazenados.
 Como toda restrição de integridade, dependências funcionais - DF´s
são baseadas na semântica da aplicação:
 Pode-se checar uma instância de uma tabela e ver se uma DF é violada
ou não. Mas apenas com o exame de uma instância de uma tabela nunca
se pode concluir se uma DF deve ser imposta ou não.
 Uma dependência funcional - DF diz respeito a todas as possíveis
instâncias de uma tabela.
Banco de Dados I
Aula 18 - 36/68
©Prof. Lineu Mialaret
Dependência Funcional (11)
 Dependências Funcionais são direcionais:
eno  ename não é o mesmo que ename  eno
 Exemplo:
 Dado um nome de empregado podem existir diversos valores para o
atributo eno se há empregados na base de dados com o mesmo nome.
 Dessa forma, sabendo-se o valor do atributo ename não há como
identificar unicamente o valor do atributo eno.
Banco de Dados I
Aula 18 - 37/68
©Prof. Lineu Mialaret
Dependência Funcional (12)
 Uma dependência funcional é chamada de trivial se os atributos do
seu lado esquerdo formam um superconjunto (superset) dos atributos
do lado direito. Ou seja, um determinante (conjunto de atributos do
lado esquerdo) com mais de um atributo pode determinar seus
próprios membros quando isolado.
 Exemplo:
 eno  eno
 eno, ename  eno
 eno, pno, hours  eno, hours
 Dependências funcionais triviais não são de interesse devido ao fato
delas não dizerem absolutamente nada.
 O interesse na normalização é pelas dependências não triviais.
Banco de Dados I
Aula 18 - 38/68
©Prof. Lineu Mialaret
Dependência Funcional (13)
 Dependências Funcionais podem ser utilizadas para se determinar
as chaves candidatas e primárias de uma relação.
 Por exemplo, caso se saiba que um atributo funcionalmente
determina todos os outros atributos numa relação, este atributo pode
ser uma chave candidata.
 Exemplo:
 eno  eno, ename, bdate, title, salary, supereno, dno
 O atributo eno é uma chave candidata para a tabela Employee.
Employee
Banco de Dados I
Aula 18 - 39/68
©Prof. Lineu Mialaret
Dependência Funcional (14)
 Definição alternativa de chaves:
 Um conjunto de atributos K é uma superchave para uma tabela R se o
conjunto dos atributos K funcionalmente determina todos os atributos
em R.
 Um conjunto de atributos K é uma chave candidata para uma tabela R
se K é uma superchave mínima de R.
Banco de Dados I
Aula 18 - 40/68
©Prof. Lineu Mialaret
Regras para Dependências Funcionais (1)
 Sejam A, B, C e D subconjuntos dos atributos de uma tabela R.
 Regra 1: Reflexão
Se A  B então A  B
 Um conjunto de atributos, sempre e trivialmente, determina qualquer
subconjunto de si mesmo.
 Exemplo:
Se {CPF, nome}  {nome} então CPF, nome  nome
 Lê-se o exemplo acima do seguinte modo:
 Se o atributo nome é um subconjunto do conjunto formado pelos atributos
CPF e nome, então os atributos CPF e nome conjuntamente permitem
encontrar o nome de uma pessoa.
Banco de Dados I
Aula 18 - 41/68
©Prof. Lineu Mialaret
Regras para Dependências Funcionais (2)
 Regra 2: Ampliação
Se A  B então A,C  B,C
 A adição de um conjunto de atributos a ambos os lados da
dependência funcional resulta em outra dependência funcional válida.
 Exemplo:
Se CPF  nome então CPF, endereco  CPF, endereco
 Lê-se o exemplo acima do seguinte modo:
 Se com um número de CPF encontra-se o nome de uma pessoa, então
com o número de CPF e o endereço pode-se encontrar o nome e o
endereço de uma pessoa.
Banco de Dados I
Aula 18 - 42/68
©Prof. Lineu Mialaret
Regras para Dependências Funcionais (3)
 Regra 3: Transitividade
Se A  B e B  C então A  C
 Se um atributo determina um segundo atributo, e este atributo
determina um terceiro atributo, então o primeiro atributo determina o
terceiro atributo.
 Exemplo:
Se CPF  codigo-cidade e codigo-cidade  nome-cidade
então
CPF  nome-cidade
 Lê-se o exemplo acima do seguinte modo:
 Se com um número de CPF pode-se encontrar o código da cidade e com o
código da cidade encontra-se o nome da cidade, então com o número do
CPF pode-se encontrar o nome da cidade.
Banco de Dados I
Aula 18 - 43/68
©Prof. Lineu Mialaret
Regras para Dependências Funcionais (4)
 Há outras três regras que são derivadas das regras anteriores.
 Regra 4: Decomposição
Se A  B,C então A  B
e
AC
 Uma dependência funcional com dois atributos no lado direito pode
ser decomposta em duas dependências funcionais com um atributo
no lado direito.
 Exemplo:
Se CPF  nome, endereço então
e
CPF  nome
CPF  endereco
 Lê-se o exemplo acima do seguinte modo:
 Se com um número de CPF encontra-se o nome e o endereço de uma
pessoa, então com este mesmo CPF pode-se encontrar apenas o nome,
e com este mesmo CPF pode-se encontrar apenas o endereço.
Banco de Dados I
Aula 18 - 44/68
©Prof. Lineu Mialaret
Regras para Dependências Funcionais (5)
 Regra 5: União
Se A  B e A  C então A  B,C
 É o reverso da regra anterior.
 Exemplo:
Se
CPF  nome e CPF  endereço
então CPF  nome, endereco
 Lê-se o exemplo acima do seguinte modo:
 Se com um número de CPF encontra-se o nome de uma pessoa e com o
o mesmo número de CPF encontra-se seu endereço, então com este
mesmo CPF pode-se encontrar o nome e o endereço da pessoa.
Banco de Dados I
Aula 18 - 45/68
©Prof. Lineu Mialaret
Regras para Dependências Funcionais (6)
 Regra 6: Composição
Se A  B e C  D então A,C  B,D
 É uma regra mais geral que a união, ou seja, ela combina duas
dependências funcionais
dependência funcional.
não
sobrepostas
em
uma
única
 Exemplo:
Se
CPF  código-funcionario e RG  endereço
então CPF, RG  código-funcionario, endereco
 Lê-se o exemplo acima do seguinte modo:
 Se com um número de CPF encontra-se o código do funcionário, e com o
número de RG encontra-se seu endereço, então com os números de
CPF e RG pode-se determinar o código do funcionário e seu endereço.
Banco de Dados I
Aula 18 - 46/68
©Prof. Lineu Mialaret
Dependência Funcional Completa (1)
 Conceito de Dependência Funcional Completa:
 Um atributo é considerado como tendo dependência funcional completa
de um outro conjunto de atributos, quando é funcionalmente dependente
do conjunto inteiro, mas não de qualquer subconjunto do determinante.
 A dependência funcional A  B é considerada uma dependência
funcional completa de B se a remoção de algum atributo de A resulta na
inexistência (quebra) da dependência.
 Diz-se que o atributo B é completamente dependente do atributo A.
 Se há a remoção de algum atributo de A e a dependência funcional ainda
existe, diz-se que o atributo B é parcialmente dependente do atributo A.
Banco de Dados I
Aula 18 - 47/68
©Prof. Lineu Mialaret
Dependência Funcional Completa (2)
 Exemplo:
 eno  ename (dependência funcional completa)
 eno, ename  salary, title (dependência parcial, pois pode-se remover
o atributo ename sem afetar a dependência)
 eno, pno  hours, resp (dependência funcional completa).
Banco de Dados I
Aula 18 - 48/68
©Prof. Lineu Mialaret
Dependência Funcional Completa (3)

Exemplo:
 O atributo Horas está em dependência funcional completa dos atributos
Matricula e CodProj.
 O atributo DataFim não está em dependência funcional completa de
Matricula e CodProj pois DataFim é funcionalmente dependente do
atributo CodProj sozinho.
Matricula
120
120
121
121
121
270
270
273
274
279
279
279
301
306
Banco de Dados I
Nome
João
João
Hélio
Hélio
Hélio
Gabriel
Gabriel
Silva
Abraão
Carla
Carla
Carla
Ana
Manoel
CodCargo
1
1
1
1
1
2
2
3
2
1
1
1
1
3
NomeCargo
Programador
Programador
Programador
Programador
Programador
Analista
Analista
Projetista
Analista
Programador
Programador
Programador
Programador
Projetista
Aula 18 - 49/68
CodProj
01
08
01
08
12
08
12
01
12
01
08
12
12
17
DataFim
17/07/95
12/01/96
17/07/95
12/01/96
21/03/96
12/01/96
21/03/96
17/07/95
21/03/96
17/07/96
12/01/96
21/03/96
21/03/96
21/03/96
Horas
37
12
45
21
107
10
38
22
31
27
20
51
16
67
©Prof. Lineu Mialaret
2FN – 2a Forma Normal (1)
 Uma tabela R está na Segunda Forma Normal - 2FN se:
 Ela está na 1FN.
 Todo atributo não chave for totalmente funcionalmente dependente da
chave primária. Isto é, não deve haver dependências parciais na chave.
 Se uma tabela não está em 2FN, divide-se essa tabela em tabelas
separadas, cada uma em 2FN, garantindo-se que a chave primária de
cada nova tabela funcional e completamente determina todos os
atributos da relação.
 Por definição, qualquer tabela com uma chave primária de um único
atributo sempre está na 2FN.
Banco de Dados I
Aula 18 - 50/68
©Prof. Lineu Mialaret
2FN – 2a Forma Normal (2)
 Seja a seguinte tabela EmpProj, com as seguintes DF´s:
df1
df2
df3
df4
 Normaliza-se essa tabela para as seguintes tabelas:
 Emp (eno, ename, title, bdate, salary, supereno, dno)
 WorksOn (eno, pno, resp, hours)
 Proj (pno, pname, budget)
Banco de Dados I
Aula 18 - 51/68
©Prof. Lineu Mialaret
2FN – 2a Forma Normal (3)
df1
df2
df4
df3
Banco de Dados I
Aula 18 - 52/68
©Prof. Lineu Mialaret
2FN – 2a Forma Normal (4)
Matricula
Nome
CodCargo
NomeCargo
CodProj
DataFim
Horas
120
João
1
Programador
01
17/07/95
37
120
João
1
Programador
08
12/01/96
12
121
Hélio
1
Programador
01
17/07/95
45
121
Hélio
1
Programador
08
12/01/96
21
121
Hélio
1
Programador
12
21/03/96
107
270
Gabriel
2
Analista
08
12/01/96
10
270
Gabriel
2
Analista
12
21/03/96
38
273
Silva
3
Projetista
01
17/07/95
22
274
Abraão
2
Analista
12
21/03/96
31
279
Carla
1
Programador
01
17/07/96
27
279
Carla
1
Programador
08
12/01/96
20
279
Carla
1
Programador
12
21/03/96
51
301
Ana
1
Programador
12
21/03/96
16
306
Manoel
3
Projetista
17
21/03/96
67
Exemplo: Tabela Empregado em 1FN.
Banco de Dados I
Aula 18 - 53/68
©Prof. Lineu Mialaret
2FN – 2a Forma Normal (5)
 Na 2FN, a tabela EMPREGADO resulta em três novas tabelas:
Empregado, Projeto e Alocação:
Empregado
Matricula
Nome
CodCargo
NomeCargo
Alocacao
Matricula
CodProj
Horas
120
01
37
120
08
12
120
João
1
Programador
121
Hélio
1
Programador
121
01
45
270
Gabriel
2
Analista
121
08
21
273
Silva
3
Projetista
121
12
107
274
Abraão
2
Analista
270
08
10
279
Carla
1
Programador
270
12
38
301
Ana
1
Programador
273
01
22
306
Manuel
3
Projetista
274
12
31
279
01
27
279
08
20
279
12
51
301
12
16
306
17
67
Projeto
CodProj
01
08
12
Banco de Dados I
DataFim
17/07/95
12/01/96
21/03/96
A característica básica dessas
novas tabelas geradas é que os
atributos não chave estão em
dependência total das chaves
(não há dependência parcial).
Aula 18 - 54/68
©Prof. Lineu Mialaret
2FN – 2a Forma Normal - Anomalias
 Entretanto, há anomalias que ocorrem na 2a Forma Normal - 2FN:
 Anomalia de Inserção - Só pode-se criar cargos se houver empregados
designados para ele.
 Anomalia de Remoção - Caso seja removido o empregado que ocupa um
único cargo na empresa, por exemplo um Gerente Geral, perde-se a
informação sobre este cargo.
 Anomalia de Atualização - Se um cargo mudar de nome, por exemplo,
precisa-se alterar todas as tabelas nas quais este cargo aparece.
 Definição: uma tabela R está em 3FN se, e somente se:
 Ela estiver em 2FN
 Todos os atributos não chave (ou atributos não primos) de R forem
dependentes não transitivos da chave primária.
 Ou seja, uma tabela está em 3FN se todas as colunas da tabela são
funcionalmente dependentes da chave inteira e de nenhum outro
atributo além da chave. A 3FN elimina características potencialmente
indesejáveis dos dados representados na 2FN ou 1FN.
Banco de Dados I
Aula 18 - 55/68
©Prof. Lineu Mialaret
Dependência Transitiva (1)
 Suponha que se tenha uma tabela R com os atributos A, B e C.
 Se o atributo C é funcionalmente dependente de B e B é
funcionalmente dependente de A, então C é funcionalmente
dependente de A.
Banco de Dados I
Aula 18 - 56/68
©Prof. Lineu Mialaret
Dependência Transitiva (2)
 Exemplo: ao se analisar a tabela Emp descobre-se a dependência
transitiva eno  salary:
fd1
fd2
 Remove-se essa dependência para uma nova tabela Pay:
fd1
Banco de Dados I
fd2
Aula 18 - 57/68
©Prof. Lineu Mialaret
3FN – 3a Forma Normal (2)
 Exemplo: ao analisar a nova Tabela Empregado que está em 2FN
Matrícula
Nome
CodCargo
NomeCargo
120
João
1
Programador
121
Hélio
1
Programador
270
Gabriel
2
Analista
273
Silva
3
Projetista
274
Abraão
2
Analista
279
Carla
1
Programador
301
Ana
1
Programador
306
Manuel
3
Projetista
 Tem-se que NomeCargo é dependente transitivo de Matricula.
Matricula
Banco de Dados I
CodCargo
NomeCargo
Aula 18 - 58/68
©Prof. Lineu Mialaret
3FN – 3a Forma Normal (3)
 Removendo a dependência transitiva, obtém-se além das tabelas
Projeto e Alocacao, as seguintes novas tabelas: Empregado e
Cargo.
Empregado
Matrícula
Nome
CodCargo
120
João
1
121
Hélio
1
270
Gabriel
2
273
Silva
3
274
Abraão
2
279
Carla
1
301
Ana
1
306
Manuel
3
Cargo
CodCargo
NomeCargo
1
Programador
2
Analista
3
Projetista
 A característica básica dessas novas tabelas geradas é que os
atributos não chave estão em dependência total das chaves (e não há
dependências transitivas).
Banco de Dados I
Aula 18 - 59/68
©Prof. Lineu Mialaret
Chaves de uma Relação
 Superchave:
 Um ou mais atributos que permitem identificar cada linha da tabela
como única.
 Chave Candidata:
 Corresponde a uma superchave mínima, ou seja, não existe um
subconjunto desta superchave que seja superchave.
{ cpf } é chave candidata?
{ cpf, nome } é chave candidata?
 Chave Primária:
 Chave candidata escolhida para a tabela no projeto da base de dados.
 Atributo Chave ou Atributo Primo:
 Atributo que compõe uma chave candidata.
Banco de Dados I
Aula 18 - 60/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (1)
 É uma forma normal mais restritiva que 3FN.
 Relembrando, chama-se de determinante um atributo do qual algum
outro atributo é funcionalmente dependente numa DF.
 Definição: uma relação está na Forma Normal de Boyce-Codd -
BCNF se, e somente se, cada determinante for uma chave candidata.
 Para testar se uma relação está em BCNF, toma-se o determinante
de cada DF na tabela e verifica-se se ele é uma chave candidata.
 A diferença entre 3FN e BCFN é que a primeira permite uma DF do
tipo A  B permanecer na tabela se o atributo B é um atributo primo
e o atributo A não é um atributo de chave candidata. A BCFN só
permite essa DF se o atributo A é um atributo de chave candidata.
 A BCFN é mais restritiva que a 3FN. Entretanto, na prática a maioria das
relações em 3FN também estão em BCFN.
 Essa forma normal cobre situações tais como: a tabela possui mais de
uma chave candidata, as chaves candidatas são compostas ou as chaves
candidatas se sobrepõem (possuem atributos em comum).
Banco de Dados I
Aula 18 - 61/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (2)
 Seja a tabela WoksOn onde tenha sido adicionada a restrição de que
dado o número de horas trabalhadas, sabe-se exatamente o
empregado que realizou determinado trabalho (ou seja, cada
empregado é determinado funcionalmente pelo número de horas que
trabalhou num determinado projeto).
df1
df2
 A tabela WoksOn está em 3FN, mas não está em BCFN.
 Caso se queira deixar a tabela em BCFN, deve-se dividir essa relação
em duas, conforme apresentado a seguir.
Banco de Dados I
Aula 18 - 62/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (3)
df2
 A tabela WoksOn é dividida em duas tabelas.
 Entretanto, observa-se que a dependência funcional
eno, pno  resp, hours
não foi preservada nesta transformação.
Banco de Dados I
Aula 18 - 63/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (4)
 Exemplo: Seja a tabela AULA apresentada abaixo.
 Cada linha desta tabela informa que um aluno E estuda uma
disciplina A de um professor P.
AULA
Banco de Dados I
Aula 18 - 64/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (5)
 Sejam as seguintes regras (ou restrições):
 Para cada disciplina, cada estudante da mesma recebe instrução de
um só professor.
 Cada professor leciona apenas um assunto.
 Dependências funcionais da tabela AULA:
 Chaves candidatas:
{Aluno, Disciplina}
 A relação AULA está em 3FN.
Banco de Dados I
Aula 18 - 65/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (6)
 Anomalia:
 Se for removida a informação que o aluno Carlos estuda Física, perdese a informação que o professor Antonio ensina a disciplina de Física.
 Solução: Decompor a tabela AULA nas seguintes tabelas:
R1
R2
 Portanto tem-se as relações em BCNF.
 Observa-se também que foi perdida a dependência funcional
aluno, disciplina  professor
Banco de Dados I
Aula 18 - 66/68
©Prof. Lineu Mialaret
Forma Normal de Boyce-Codd (BCNF) (7)
 Pode-se sempre decompor de 3FN para BCNF, mas as vezes isso
não é interessante caso se perca uma dependência funcional.
 A decisão de usar 3FN ou BCFN depende da quantidade de
redundância que se está disposto a aceitar e da disposição para se
perder uma dependência funcional.
 Observa-se que sempre se pode reconstruir as tabelas originais numa
BCFN, mas nem sempre se pode recuperar as dependências
perdidas.
 Ao contrário, na 3FN sempre se pode recuperar as tabelas originais,
bem como as dependências funcionais.
Banco de Dados I
Aula 18 - 67/68
©Prof. Lineu Mialaret