Escolar Documentos
Profissional Documentos
Cultura Documentos
Banco de Dados
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
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.
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.
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
Funcionrio (1FN)
CPF
(PK)
Nome
Telefones
CPF
(PK)
Nome
Tel_1
Tel_2
Tel_3
1111
Maria
999999;
888888;
333333;
1111
Maria
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
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.
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).
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
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