Bacharelado em Sistemas de Informao

Banco de Dados

Prof. Dory Gonzaga Rodrigues

Sumrio
Captulo 1 O que Normalizao..........................................................................................................3
Dependncias Funcionais.....................................................................................................................3
Anomalias em esquemas de Banco de Dados......................................................................................5
O que Normalizao..........................................................................................................................6
Primeira Forma Normal (1FN).............................................................................................................6
Segunda Forma Normal (2FN).............................................................................................................8
Terceira Forma Normal (3FN)..............................................................................................................9
Forma Normal de Boyce-Cood...........................................................................................................10

Captulo 1 O que Normalizao

Neste captulo, vamos entender o que Normalizao e como implementar em um projeto de banco de dados relacional.
O Banco de dados um conjunto de informaes agrupadas (atributos) em tabelas. Este esquema (conjunto de tabelas)
deve permitir que os relacionamentos mapeados no modelo conceitual sejam facilmente encontrados.
Mas o que seria um bom esquema?
Um bom esquema quando as armazenamos e acessamos de forma eficiente as relaes (compostas pelas tuplas) que
ocorrem entre as entidades (tabelas).
Objetivos da Normatizao
- Evitar a redundncia nos dados (evitar que a mesma informao seja armazenada mais de uma vez);
- Garantir a integridade dos dados (evitar que informaes sem sentido sejam inseridas);
- Minimizar, ao mximo, as anomalias;
- Otimizar e simplificar o processo de insero, atualizao e excluso das informaes.

Dependncias Funcionais
Vamos explicar o conceito de Dependncia Funcional atravs de um dilogo entre duas pessoas.
Joo: Oi Maria ! Quanto tempo, onde voc est morando agora ?
Maria: Oi Joo ! Eu estou morando em Goinia !
Quando Maria diz que mora em Goinia (atributo Cidade X) permite ao Joo descobrir que ela vive no estado de Gois
(atributo Estado Y) e tambm que ainda vive no Brasil (atributo Pas Z).
Neste sentido, sempre que um atributo X identifica um atributo Y dizemos que entre eles h uma dependncia funcional !
Temos, portanto, que X o determinante e que Y funcionalmente dependente de X.
A representao :

XY

Logo, a dependncia funcional caracterizada pela existncia de campos em uma determinada tabela cuja a ocorrncia de
valores est associada a valores que so preenchidos em outros campos na mesma tabela. Um exemplo clssico e
bastante explicativo a dependncia funcional que ocorre em uma tabela EMPREGADO entre os atributos CPF e Nome.
Sabemos que um determinado nmero de CPF permite que seja encontrado o nome correspondente de um empregado.
Sendo assim, CPF Nome (CPF determina Nome ! E o nome dependente funcional do CPF !).

Para efetuar a normalizao de um modelo de dados relacional, como veremos daqui a pouco, alguns tipos de
dependncias funcionais so de extrema relevncia:
Dependncia Parcial Ocorre quando a chave primria composta e existe um campo da relao que depende
somente de parte desta chave primria composta.
Empregado
CPF_Empregado
(PK)

Cod_Projeto
(PK)

Nome_Empregado

Nome_Projeto

Horas_Trabalhadas

11111

10

Ana Silva

Eleies 2014

40

22222

20

Maria Jos

Biometria 2015

20

33333

30

Pedro Antnio

Referendo 2015

40

Por exemplo, veja a tabela acima. Ela possui a chave composta CPF_Empregado e Cod_Projeto. O ideal seria que todos os
campos (atributos) da relao dependessem (fossem funcionalmente dependentes) de toda a chave primria. Porm, o
campo Nome_Empregado depende apenas de parte da chave primria (no caso, do CPF_Empregado). O mesmo ocorre
com o atributo Nome_Projeto que s depende do atributo Cod_Projeto. Apenas o atributo Horas_Trabalhadas
funcionalmente dependente da chave primria completa (porque para determinar as horas trabalhadas, precisamos saber
o CPF do empregado e para qual projeto ele est trabalhando atravs do cdigo do projeto).
Dependncia Transitiva Ocorre quando uma coluna depende no somente da chave primria da tabela, mas tambm
de uma segunda coluna (ou conjunto de colunas) da tabela, que no fazem parte da chave primria.
Em outras palavras, a dependncia funcional transitiva a dependncia funcional indireta existente entre dois ou mais
atributos. Assim, se um atributo C depende funcionalmente de um atributo B e o atributo B depende funcionalmente de
um atributo A, ento dizemos que o atributo C depende indiretamente (transitivamente) do atributo A. Exemplificamos
abaixo:
Pedido_Venda
Cod_Pedido
(PK)

Data_Pedido

Situao_Pedido

CPF_Cliente

Nome_Cliente

18/03/2014

Pendente

22014

Pedro

22/04/2014

Entregue

12014

Caroline

10/05/2014

Entregue

32014

Maria

Por exemplo, a tabela Pedido_Venda acima tem como chave primria o atributo Cod_Pedido. Os atributos Data_Pedido,
Situao_Pedido e CPF_Cliente dependem funcionalmente dessa chave primria. Porm, o atributo Nome_Cliente
depende funcionalmente do CPF_Cliente (que no a chave primria) e, apenas, indiretamente do Cod_Pedido, o que
uma anomalia, visto que, todos os atributos de uma relao deveriam depender funcionalmente apenas da sua chave
primria.

 Dependncia Multivalorada Ocorre quando o valor de um atributo determina um conjunto de valores de um outro
atributo.
Por exemplo, at agora vimos que um atributo (que deve ser a chave primria da relao) determina outro atributo. o
caso do CPF Nome (ou seja, o CPF determina o nome, sendo um nome para cada CPF). Porm, se considerarmos: CPF
Dependente teremos um problema para expressar a realidade, porque atravs de um CPF poderia determinar
(relacionar) mais de um dependente e no apenas um. Isso caracteriza uma dependncia multivalorada.
Temos, portanto, que X multidetermina Y e que Y multidependente de X.
A representao :

XY

Resumo
Uma dependncia funcional (DF) uma propriedade do esquema da relao e no de uma instncia particular da relao
(tupla). Assim, DF deve ser vlida para todas as tuplas de uma relao, ou seja, para a definio do esquema da relao
como um todo.

Anomalias em esquemas de Banco de Dados

A mistura de atributos de vrias entidades pode gerar problemas conhecidos como anomalias de atualizao e essas
anomalias podem, por sua vez, causar problemas tais como a ocorrncia de:
Dependncias parciais de chave;
Redundncias desnecessrias de dados;
Perdas acidentais de informaes;
Dificuldade de representao de fatos da realidade (modelos); e
Dependncias transitivas entre atributos.
As anomalias de atualizao podem ser de 3 tipos:
Anomalias de insero Causam a repetio desnecessria de dados (redundncia);
Anomalias de alterao Levam as inconsistncias e aumentam o esforo para a atualizao dos dados;
Anomalias de excluso Causam a perda de informaes associadas a um dado registro.
Vendas
Nome_Cliente
(PK)

Cod_CD
(PK)

Dt_Compra
(PK)

Nome_CD Cantor

Preo

Considere uma nica tabela VENDAS para representar as relaes e as informaes sobre os negcios de uma loja de CDs.
Agora imagine a seguinte situao: o cliente Pedro deseja comprar 5 CDs iguais (por exemplo, Copa do Mundo 2014, que
custa 15 reais). Como essa operao refletiria na tabela Vendas? Seria possvel realiz-la?
Anomalia de insero Redundncia em quase todas as colunas (5 linhas praticamente iguais com possibilidade de
diferena apenas no campo Dt_Compra se ele no comprar em um nico dia), afinal, o mesmo CD e o mesmo cliente.
Anomalia de alterao se houvesse um aumento de preo do CD, a atualizao do preo deveria ser feita em todas as
linhas referentes quele CD na tabela.
Anomalia de excluso A tabela s guarda registro dos CDs que foram comprados. Dessa forma, se s ocorreu uma
nica venda de um CD e ela fosse apagada, no haveria no banco de dados informao sobre aquele CD.

O que Normalizao
Em 1970, o Professor Dr. Edgar F. Codd, analista da IBM, desenvolveu uma srie de estudos sobre como tratar os dados, a
fim de eliminar as anomalias de atualizao e as suas consequncias desagradveis para as organizaes. Deste esforo
surgiram duas inovaes que revolucionaram a maneira de tratar os dados. A primeira destas inovaes foi o Modelo
Relacional, no qual se basearam os Sistemas Gerenciadores de Base de Dados(SGBD) da metade da dcada de 1980 e
incio de 1990. A segunda inovao foi o processo de Normalizao, sendo que ambas esto intimamente relacionadas.
O processo de normalizao como foi proposto por Codd sujeita um esquema de relao a uma srie de testes para
certificar-se de que ele satisfaa certa forma normal.
Na verdade, a normalizao de dados pode ser vista como o processo de anlise de determinadas tabelas (os esquemas
de relaes) com base em suas dependncias funcionais e chaves primrias para alcanar as propriedades desejveis de:
(1) minimizao de redundncias e
(2) minimizao de anomalias de insero, excluso e alterao.
Assim, podemos dizer que o processo de normalizao tem as seguintes funes:
Analisar tabelas e organiz-las de forma que a sua estrutura seja simples, relacional e estvel, para que o gerenciamento
delas possa ser tambm simples, eficiente e seguro;
Evitar a perda e a repetio da informao;
Conseguir uma forma de representao adequada para o que se deseja armazenar;
Oferecer mecanismos para analisar o projeto do BD (identificao de erros e possibilidades de melhorias) e oferecer
mtodos para corrigir problemas que, por ventura, sejam encontrados.
Sendo assim, a normalizao tem como objetivo fazer com que todas as tabelas atendam s regras da forma normal.
Nesse processo, as tabelas que no alcanam estas condies (no caso, os testes de forma normal) so decompostas, ou
seja, sua estrutura redesenhada atravs da projeo (jogar para fora) de alguns atributos, levando a construo de novas
tabelas contendo algum atributo (chave) capaz de refazer o contedo da tabela original atravs da juno (reunir) das
tabelas resultantes.
Inicialmente Codd props trs formas normais que ele chamou de primeira (1FN), segunda (2FN) e terceira (3FN) forma
normal. Uma definio mais forte da 3FN (chamada forma normal BOYCE-CODD - FNBC ou BCNF) foi depois proposta por
Boyce e Codd. Todas essas formas normais so baseadas nas dependncias funcionais entre os atributos de uma relao.
Posteriormente, uma quarta (4FN) e quinta (5FN) forma normal foram propostas.
Ateno:
Redundncia de dados um fato gerador de inconsistncias.
Anomalias de atualizao criam dificuldades operacionais para manuteno do banco de dados, quebrando a
confiabilidade no dado ou ferindo a integridade dos dados.
Uma forma normal engloba todas as outras anteriores, ou seja, a hierarquia entre as formas normais indica que uma
tabela s pode estar numa forma mais avanada se, alm de atender as condies necessrias, j estiver na forma normal
imediatamente anterior.
Na prtica, o mais comum normalizar relaes apenas at a 3FN. Isso porque as trs primeiras formas normais (1FN,
2FN e 3FN) atendem maioria dos casos de normalizao e j so suficientes para organizar as tabelas de um BD.

Primeira Forma Normal (1FN)

Para o Modelo Relacional a Forma Normal mais importante consiste da Primeira Forma Normal, pois considerada parte
da prpria definio de uma relao. Uma relao se encontra na Primeira Forma Normal (1FN) se todos os domnios de
atributos possuem apenas valores atmicos (indivisveis), e que o valor de cada atributo na tupla seja um valor simples.
Ou seja, a 1FN no permite a construo de relaes que apresentem atributos compostos e nem possibilita a existncia
de atributos multivalorados em suas tuplas. Os nicos valores de atributos permitidos devem ser simples (atmicos).

Ento, para normalizar a tabela para a Primeira Forma Normal deve-se:

Atributos Compostos cada um dos atributos compostos (ou no simples) devem ser divididos em seus atributos
componentes. Com essa quebra, a tabela passa a ter apenas atributos so indivisveis (simples).
Exame

Exame (1FN)

CPF

Nome

Grau_Olhos*

CPF

Nome

Grau_Esq Grau_Dir

1111

Maria

0.25 e 0.75

1111

Maria

0.25

0.75

2222

Joo

1.1 e 1.0

2222

Joo

1.1

1.0

3333

Pedro

2.5 e 0.85

3333

Pedro

2.5

0.85

Atributos Multivalorado temos dois tratamentos possveis

a) Quando a quantidade de valores a serem preenchidos no atributo multivalorado for pequena e conhecida.
substitui-se o atributo multivalorado por um conjunto de atributos de mesmo domnio, cada um monovalorado
representando uma ocorrncia do valor.
Funcionrio

Funcionrio (1FN)

CPF
(PK)

Nome

Telefones

CPF
(PK)

Nome

Tel_1

Tel_2

Tel_3

1111

Maria

999999;
888888;
333333;

1111

Maria

999999; 888888; 333333;

2222

Joo

777777;

2222

Joo

777777;

3333

Pedro

666666;

3333

Pedro

666666;

b) Quando a quantidade de valores no for conhecida ou grande, retira-se da tabela o atributo multivalorado, e
cria-se uma nova tabela que tem o mesmo conjunto de atributos chave, mais o atributo multivalorado tambm
como chave, mas tomado como monovalorado.
Ateno: a opo b a mais utilizada por no dar origem a campos de preenchimento null. S seria usado o
espao de armazenamento necessrio.
Aluno_Curso
CPF
(PK)

Nome

Cursos

1111

Maria

Programao, Arquitetura, Ingls

2222

Joo

Artes, Ingls

3333

Pedro

Programao

Aluno (1FN)

Curso (1FN)

CPF
(PK)

Nome

CPF
(PK)

Curso
(PK)

1111

Maria

1111

Programao

2222

Joo

1111

Arquitetura

3333

Pedro

1111

Ingls

2222

Artes

2222

Ingls

3333

Programao

Observe que mesmo que a tabela esteja na 1FN, ela pode apresentar redundncias e anomalias de atualizao. Para
eliminar ou minimizar estes problemas, devemos prosseguir no processo de normalizao, aplicando as outras formas
normais. Veja na tabela Curso (1FN), o texto Programao trata-se do mesmo curso. Ou seja, a informao est
redundante na 1 e 6 linhas.

Segunda Forma Normal (2FN)

Uma relao est na segunda forma normal quando duas condies so satisfeitas:
A relao est na primeira forma normal;
Todos os atributos que no fazem parte da chave primria dependem funcionalmente de toda a chave primria, ou seja,
nenhum dos atributos da relao possui dependncia parcial. Ou sejam, todo atributo da tabela dependente funcional
da chave primria.
Ateno: Tabelas que esto na 1FN e que possuam chave primria simples esto, automaticamente, na 2FN.
Empregado
CPF_Empregado
(PK)

Cod_Projeto
(PK)

Nome_Empregado

Nome_Projeto

Horas_Trabalhadas

11111

10

Ana Silva

Eleies 2014

40

22222

20

Maria Jos

Biometria 2015

20

33333

30

Pedro Antnio

Referendo 2015

40

A tabela Empregado est na 1FN porque possui apenas atributos simples e monovalorados. Porm, no est na 2FN
porque o campo Nome_Empregado depende apenas de parte da chave primria (do CPF_Empregado) e o atributo
Nome_Projeto s depende do atributo Cod_Projeto. Apenas o atributo Horas_Trabalhadas funcionalmente dependente
da chave primria completa. Dessa forma, como existe dependncia parcial, a relao no est na 2FN.
Ento, para normalizar a tabela para a Segunda Forma Normal deve-se:
Dependncias Parciais temos 2 tratamentos a serem feitos para eliminar a dependncia parcial:
1) Para cada atributo que no faa parte da chave primria da relao, analisar se existe dependncia parcial da chave
primria.
2) Para cada grupo de atributos que tenham a mesma dependncia parcial da chave primria, retiramos da tabela origem
e levamos para uma nova tabela que criaremos e que ter como chave primria o atributo da chave composta que
identifica o grupo de atributos;
Por exemplo, a tabela Empregado (acima) daria origem a duas novas tabelas, uma vez que existem dois grupos com
dependncias parciais:
Alocao

Empregado

CPF_Empregado Cod_Projeto
Horas
(PK)
(PK)
Trabalhadas

CPF_Empregado Nome_Empregado
(PK)

Projeto
Cod_Projeto
(PK)

Nome_Projeto

11111

10

40

11111

Ana Silva

10

Eleies 2014

22222

20

20

22222

Maria Jos

20

Biometria 2015

33333

30

40

33333

Pedro Antnio

30

Referendo 2015

Relaes que no esto na 2FN podem apresentar problemas de inconsistncia devido duplicidade dos dados e perda
de dados em operaes de remoo/alterao (anomalias de atualizao).

Terceira Forma Normal (3FN)

Uma relao est na terceira forma normal quando duas condies so satisfeitas:
A relao est na segunda forma normal;
No existir dependncia transitiva na tabela, ou seja, todos os atributos devem depender completa e exclusivamente da
chave primria.
Ateno: Tabelas que estejam na 2FN e que tenha apenas um (ou nenhum) atributo alm da chave esto
automaticamente na 3FN.
Empregado
Cod_Empregado Nome_Empregado
(PK)

Cargo

Salrio

100

Carlos Alves

Programador

2000

101

Jos Souza

Analista

3500

102

Maria Ramos

Programador

2000

O atributo Salrio depende do atributo Cargo (que no faz parte da chave primria). J o atributo Cargo, por sua vez,
depende da chave primria Cod_Empregado.
Assim, temos: Cod_Empregado Cargo Salrio.
Ento, para normalizar a tabela para a Terceira Forma Normal deve-se:
Dependncia Transitiva temos 2 tratamentos a serem feitos para eliminar a dependncia transitiva:
1) Analisar se o valor de um atributo no-chave pode ser determinado por algum outro atributo que tambm no
pertena chave primria da relao;
2) Para cada grupo de atributos no-chaves dependentes funcionalmente de outros atributos no-chaves, cria-se uma
nova tabela e leva os atributos dependentes e os atributos que causam a dependncia (determinantes) como chave
primria. Lembrando que os atributos determinantes devem permanecer na tabela original para manter a ligao entre
elas.
Por exemplo, a tabela Empregado (acima) daria origem a duas novas tabelas, uma vez que existe uma dependncia
transitiva:
Empregado
Cargo
Cod_Empregado Nome_Empregado
(PK)

Cargo

Cargo
(PK)

Salrio

100

Carlos Alves

Programador

Programador

2000

101

Jos Souza

Analista

Analista

3500

102

Maria Ramos

Programador

Programador

2000

Forma Normal de Boyce-Cood

Uma relao considerada pertencente FNBC quando estiver na Primeira Forma Normal (1FN) e quando todo
determinante, existente na tabela, fizer parte da chave primria.
Ateno: A FNBC uma forma mais restritiva de 3FN, isto , toda relao em FNBC est tambm em 3FN; entretanto, uma
relao em 3FN no est necessariamente em FNBC.
Turma
Aluno
(PK)

Disciplina
(PK)

Professor

Carlos

IP

Augusto

Carlos

BD

Joo

Jos

IP

Augusto

Jos

PRG

Dory

Maria

PRG

Dory

Na tabela Turma acima, cada tupla informa que um aluno A estuda em uma disciplina D com um professor P. Para esta
relao, considere as seguintes regras:
Para cada disciplina, um aluno tem um nico professor;
Cada disciplina pode ser ensinada por mais de um professor; e
Cada professor s pode ensinar uma disciplina.
Determinantes:
(Aluno, Disciplina) Professor e Professor Disciplina
Como no h dependncia transitiva, ou seja, nenhum atributo no-chave determinado por outro atributo no-chave, a
relao est na 3FN. Porm, ela no est na FNBC, porque temos que Professor um atributo determinante e ele no faz
parte da chave primria. Isso acaba ocasionando anomalia de remoo. Por exemplo: na tabela Turma, se removermos o
registro (linha) onde o aluno Carlos est matriculado na disciplina de BD, no haveria mais o registro de que Joo
leciona a disciplina de BD. A informao seria perdida.
Ateno: Uma tabela que est na 3NF, s no est na FNBC quando existir uma dependncia X A, onde X um atributo
comum e A um atributo da chave.
Ento, para normalizar a tabela para a FBNC deve-se:
1) Deve-se verificar se h algum atributo determinante que no faz parte da chave primria e, em caso afirmativo, cria-se
uma nova tabela com os que dependem funcionalmente deste determinante, onde este ser a chave primria da nova
tabela.
Por exemplo, a tabela Turma seria decomposta nas seguintes relaes apresentadas, de acordo com os determinantes
identificados:
Aluno
Professor
Aluno
(PK)

Professor

Professor
(PK)

Disciplina

Carlos

Augusto

Augusto

IP

Carlos

Joo

Joo

BD

Jos

Augusto

Augusto

IP

Jos

Dory

Dory

PRG

Maria

Dory

Dory

PRG