5

1.INTRODUÇÃO

O conceito de Normalização e formas normais é sem dúvidas um dos

conceitos mais importantes do Modelo Relacional. O conceito de normalização foi

introduzido por E.F.Codd em 1970 (primeira forma normal). Esta técnica é um

processo matemático que tem seus fundamentos na teoria dos conjuntos. Através

deste processo pode-se, gradativamente, substituir um conjunto de entidades e

relacionamentos por um outro, o qual se apresenta purificado em relação às

anomalias de atualização (inclusão, alteração e exclusão) as quais podem causar

certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados,

dependências parciais em relação a uma chave concatenada, redundância

desnecessária de dados, dificuldade na representação de fatos da realidade

observada e dependências transitivas entre atributos.

6

2.OBJETIVO

O objetivo da normalização é evitar os problemas provocados por falhas no

Projeto da Base de Dados, bem como eliminar a “mistura de assuntos” e as

correspondentes repetições desnecessárias de dados. Uma Regra de Ouro que

devemos observar quando do Projeto de uma Base de Dados baseada no Modelo

Relacional de dados é a de "não Misturar assuntos em uma mesma Tabela". Por

exemplo, na Tabela Clientes devemos colocar somente campos relacionados com o

assunto Clientes. Não devemos misturar campos relacionados com outros assuntos,

tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma

tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência

dos dados. O Processo de Normalização aplica uma série de Regras sobre as

Tabelas de uma Base de Dados, para verificar se estas estão corretamente

projetadas. Embora existam cinco formas normais (ou regras de Normalização), na

prática usamos um conjunto de três Formas Normais. Normalmente após a

aplicação das Regras de Normalização, algumas tabelas acabam sendo divididas

em duas ou mais tabelas, o que no final gera um número maior de tabelas do que o

originalmente existente. Este processo causa a simplificação dos atributos de uma

tabela, colaborando significativamente para a estabilidade do modelo de dados,

reduzindo-se consideravelmente as necessidades de manutenção. Vamos entender

o Processo de Normalização na Prática, através de exemplos.

Formulário de Pedido

Num. Ped.

Cliente End. CNPJ IE Cód.Prod. Un. Qt. Descr. Val.Unit.

Tot.Prod Tot.Ped

3445 TCA R.Meira 111 2 45 L 20 alcool 5,00 100,00 1799,003445 TCA R.Meira 111 2 130 M 2 Tecido 20,00 40,00 1799,003445 TCA R.Meira 111 2 335 Kg 30 Farinha 1,00 30,00 1799,003445 TCA R.Meira 111 2 78 Kg 50 Cimento 30,00 1500,00 1799,003445 TCA R.Meira 111 2 90 L 40 Cola 3,00 120,00 1799,003445 TCA R.Meira 111 2 35 Kg 3 Chumbo 3,00 9,00 1799,002610 Lopes R. 127 1111 45 45 L 50 Álcool 5,00 100,002610 Lopes R. 127 1111 45 78 Kg 47 Cimento 30,00 375,00 2650,002610 Lopes R. 127 1111 45 21 Kg 20 Pregos 5,00 45,00 2650,002610 Lopes R. 127 1111 45 98 L 15 Tinta azul 25,00 30,00 2650,002610 Lopes R. 127 1111 45 90 L 15 Cola 3,00 20,00 2650,002610 Lopes R. 127 1111 45 43 M 10 Arame 3,00 30,00 2650,002610 Lopes R. 127 1111 45 25 F 10 Algodão 2,00 20,00 2650,002610 Lopes R. 127 1111 45 65 L 5 Querosene 8,00 40,00 2650,002610 Lopes R. 127 1111 45 51 M 20 Fio 13,00 260,00 2650,002610 Lopes R. 127 1111 45 74 M 30 Linha 10 4,00 120,00 2650,00

Figura 1 – Exemplo de Formulário de Pedido.

7

Formulário de Pedido (Atributos)

• Número do pedido • Quantidade do produto

• Descrição do produto • Prazo de entrega

• Valor unitário do produto • Valor total do produto

• Valor total do pedido • Código do vendedor

• Nome do vendedor • Cliente

• Endereço • Cidade

• UF • CNPJ

• Inscrição Estadual • Código do produto

• Unidade do produto

Caso esta entidade fosse implementada como uma tabela em um banco de dados,

as seguintes anomalias iriam aparecer:

– Anomalia de inclusão: ao ser incluído um novo cliente, o mesmo tem que estar

relacionado a uma venda;

– Anomalia de exclusão: ao ser excluído um cliente, os dados referentes as suas

compras serão perdidos;

– Anomalia de alteração: caso algum fabricante de produto altere a faixa de preço de

uma determinada classe de produtos, será preciso percorrer toda a entidade para se

realizar múltiplas alterações.

3.PRIMEIRA FORMA NORMAL(1FN)

• Em uma determinada realidade, às vezes encontramos algumas informações que

se repetem (atributos multivalorados), retratando ocorrências de um mesmo fato

dentro de uma única linha e vinculadas a sua chave primária;

• Ao observarmos a entidade PEDIDO, apresentada anteriormente, visualizamos que

um certo grupo de atributos (produtos solicitados) se repete (número de ocorrências

não definidas) ao longo do processo de entrada de dados na entidade;

• A 1FN diz que: cada ocorrência da chave primária deve corresponder a uma e

somente uma informação de cada atributo, ou seja, a entidade não deve conter

grupos repetitivos (multivalorados);

• Para se obter entidades na 1FN, é necessário decompor cada entidade não

normalizada em tantas entidades quanto for o número de conjuntos de atributos

repetitivos. Nas novas entidades criadas, a chave primária é a concatenação da

8

chave primária original mais o(s) atributo(s) do grupo repetitivo visualizado(s) como

chave primária deste grupo. Uma tabela está na Primeira Forma Normal quando

seus atributos não contém grupos de repetição. Por isso dissemos que uma tabela

que possui grupos de repetição não está na 1FN. Considere a estrutura da tabela

Indicada na próxima figura:

Figura 2 - Tabela que não está na 1FN.

Uma tabela com esta estrutura apresentaria diversos problemas. Por

exemplo, se um casal tiver mais de um filho, teremos que digitar o Nome do Pai e da

Mãe diversas vezes, tantas quantos forem os filhos. Isso forma um Grupo de

Repetição. Além do mais pode ser que por erro de digitação o Nome dos Pais não

seja digitado exatamente igual todas as vezes, o que pode acarretar problemas na

hora de fazer pesquisas ou emitir relatórios. Este problema ocorre porque

"Misturamos Assuntos" em uma mesma tabela. Colocamos as informações dos

pais e dos filhos em uma mesma tabela. A solução para este problema é simples:

Criamos uma tabela separada para a Informação dos Pais e Relacionamos a tabela

Pais com a tabela filhos através de um relacionamento do tipo um para vários, ou

seja, um casal da pais pode ter vários filhos. Observe na figura abaixo as duas

tabelas: pais e filhos, já normalizadas:

Figura 3 – Tabela Normalizada.

9

Voltando a nossa tabela Formulário de Pedido temos o seguinte:

Ao aplicarmos a 1FN sobre a entidade PEDIDO, obtemos mais uma entidade

chamada ITEM-DE-PEDIDO, que herdará os atributos repetitivos e destacados da

entidade PEDIDO; Um PEDIDO possui no mínimo 1 e no máximo N elementos em

ITEM-DEPEDIDO e um ITEM-DE-PEDIDO pertence a 1 e somente 1 PEDIDO.

PEDIDO ITEM DE PEDIDO

• Número do pedido • Número do pedido• Prazo de entrega • Código do produto• Cliente • Quantidade do produto• Endereço • Descrição do produto• Cidade • Valor unitário do produto• UF • Valor total do produto• CGC • Inscrição Estadual• Valor total do pedido• Valor total do pedido• Código do vendedor• Nome do vendedor

4.DEPENDÊNCIA FUNCIONAL

Para descrevermos as próximas formas normais, se faz necessária a

introdução do conceito de dependência funcional, sobre o qual a maior parte da

teoria de normalização foi baseada.

• Dada uma entidade qualquer, dizemos que um atributo ou conjunto de atributos A é

dependente funcional de um outro atributo B contido na mesma entidade, se a cada

valor B existir nas linhas da entidade em que aparece, um único valor de A. Em

outras palavras, A depende funcionalmente de B;

• Na entidade PEDIDO, o atributo PRAZO-DE-ENTREGA depende funcionalmente

de NUMERO-DO-PEDIDO;

• O exame das relações existentes entre os atributos de uma entidade deve ser feito

a partir do conhecimento (conceitual) que tem sobre a realidade a ser modelada.

4.1 Dependência Funcional Total e Parcial

Na ocorrência de uma chave primária concatenada, dizemos que um atributo

ou conjunto de atributos depende de forma completa ou total desta chave primária

concatenada, se e somente se, a cada valor da chave (e não parte dela), está

associado um valor para cada atributo, ou seja, um atributo não se apresenta com

10

dependência completa ou total quando só depende de parte da chave primária

concatenada e não dela como um todo;

• Dependência total – na entidade ITEM-DOPEDIDO, o atributo QUANTIDADE-

DOPRODUTO depende de forma total ou completa da chave primária concatenada

(NÚMERO-DO-PEDIDO + CÓDIGO-DOPRODUTO);

• A dependência total ou completa só ocorre quando a chave primária for composta

por vários atributos, ou seja, em uma entidade de chave primária composta de um

único atributo não ocorre este tipo de dependência.

4.2 Dependência Funcional Transitiva

Quando um atributo ou conjunto de atributos A depende de outro atributo B

que não pertence à chave primária, mas é dependente funcional desta, dizemos que

A é dependente transitivo de B.

• Dependência transitiva – na entidade PEDIDO, os atributos ENDEREÇO, CIDADE,

UF, CNPJ e INSCRIÇÃO ESTADUAL são dependentes transitivos do atributo

CLIENTE. Nesta mesma entidade, o atributo NOME-DO VENDEDOR é dependente

transitivo do atributo CÓDIGO-DO VENDEDOR;

• Com base na teoria sobre as dependências funcionais entre atributos de uma

entidade, podemos continuar com a apresentação das outras formas normais.

5. SEGUNDA FORMA NORMAL (2FN)

Devemos observar se alguma entidade possui chave primária concatenada, e

para aquelas que satisfizerem esta condição, analisar se existe algum atributo ou

conjunto de atributos com dependência parcial em relação a algum elemento da

chave primária concatenada;

Com a finalidade de tornar ainda mais estável o modelo de dados, a aplicação

da 2FN sobre as entidades em observação geram novas entidades, que herdarão a

chave parcial e todos os atributos que dependem desta chave parcial, ou seja, uma

entidade para estar na 2FN não pode ter atributos com dependência parcial em

relação à chave primária.

A entidade ITEM-DO-PEDIDO apresenta uma chave primária concatenada e

por observação, notamos que os atributos UNIDADE-DO-PRODUTO, DESCRIÇÃO-

DO-PRODUTO e VALOR-UNITÁRIO dependem de forma parcial do atributo

CÓDIGO-DO-PRODUTO, que faz parte da chave primária. Logo devemos aplicar a

2FN sobre esta entidade. Quando aplicarmos a 2FN sobre ITEM-DO-PRODUTO,

será criada a entidade PRODUTO que herdará os atributos UNIDADE-

11

DOPRODUTO, DESCRIÇÃO-DO-PRODUTO e VALORUNITÁRIO e terá como

chave primária o CÓDIGO-DOPRODUTO. Um PRODUTO participa de no mínimo 0

e no máximo N elementos de ITEM-DEPEDIDO e um ITEM-DE-PEDIDO só pode

conter 1 somente 1 PRODUTO.

6.TERCEIRA FORMA NORMAL (3FN)

Uma entidade está na 3FN se nenhum de seus atributos possui dependência

transitiva em relação a outro atributo da entidade que não participe da chave

primária, ou seja, não exista nenhum atributo intermediário entre a chave primária e

o próprio atributo observado;

• Ao retirarmos a dependência transitiva, devemos criar uma nova entidade que

contenha os atributos que dependem transitivamente de outro e a sua chave

primária é o atributo que causou esta dependência;

• Além de não conter atributos com dependência transitiva, entidades na 3FN não

devem conter atributos que sejam o resultado de algum cálculo sobre outro atributo,

que de certa forma pode ser encarada como uma dependência funcional.

Na entidade PEDIDO, podemos observar que o atributo NOME-DOVENDEDOR

depende transitivamente do atributo CÓDIGO-DOVENDEDOR que não pertence à

chave primária. Para eliminarmos esta anomalia devemos criar a entidade

VENDEDOR, com o atributo NOMEDO-VENDEDOR e tendo como chave primária o

atributo CÓDIGO-DOVENDEDOR. Encontramos ainda o conjunto de atributos

formados por ENDEREÇO,CIDADE, UF, CNPJ e INSCRIÇÃO ESTADUAL que

dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a

entidade CLIENTE que conterá os atributos ENDEREÇO, CIDADE, UF, CNPJ e

INSCRIÇÃO ESTADUAL. Para chave primária desta entidade vamos criar um

atributo chamado CÓDIGO-DO-CLIENTE que funcionará melhor como chave

primária do que NOME-DO-CLIENTE, deixando este último como simples atributo da

entidade CLIENTE. Um PEDIDO só é feito por um e somente um CLIENTE e um

CLIENTE pode fazer de 0 até N elementos de PEDIDO. Um PEDIDO só é tirado por

um e somente um VENDEDOR e VENDEDOR pode tirar de 0 a N elementos de

PEDIDO.

7. FORMA NORMAL DE BOYCE/CODD(FNBC)

12

As definições da 2FN e 3FN, desenvolvidas por Codd, não cobriam certos

casos. Esta inadequação foi apontada por Boyce em 1974. Os casos não cobertos

pelas definições de Codd somente ocorrem quando três condições aparecem juntas:

– A entidade tenha várias chaves candidatas;

– Estas chaves candidatas sejam concatenadas (mais de um atributo);

– As chaves concatenadas compartilham pelo menos um atributo comum;

Na verdade, a FNBC é uma extensão da 3FN, que não resolvia certas anomalias

presentes na informação contida em uma entidade. O problema foi observado

porque a 2FN e a 3FN só tratavam dos casos de dependência parcial e transitiva de

atributos fora de qualquer chave, porém quando o atributo observado estiver contido

em uma chave, ele não é captado pela verificação da 2FN e 3FN.

Considere a seguinte entidade FILHO:

Por hipótese, vamos assumir que um professor possa estar associado a mais de

uma escola e uma sala. Sob esta suposição, tanto a chave (candidata) concatenada

NOME-DA-ESCOLA + SALA-DA-ESCOLA bem como NOME-DA-ESCOLA + NOME-

DO-PROFESSOR podem ser determinantes. Logo esta entidade atende às três

condições relacionadas anteriormente.

– As chaves candidatas para a entidade FILHO são: NOME-DO-FILHO

ENDEREÇO-DO-FILHO, NOME-DO-FILHO + NÚMERO-DA-SALA e

NOME-DO-FILHO + NOME-DO-PROFESSOR;

– Todas as três chaves apresentam mais de um atributo (concatenados);

– Todas as três chaves compartilham um mesmo atributo: NOME-DOFILHO.

A definição da FNBC é a seguinte: uma entidade está na FNBC se e somente se

todos os determinantes forem chaves candidatas. Notem que esta definição é em

termos de chaves candidatas e não sobre chaves primárias. Neste exemplo, NOME-

DOPROFESSOR não é completamente dependente funcional do NÚMERO-DA-

Nome do Filho

Endereço do Filho

Data de Nascimento

Nome da Escola

Número da Sala

Nome do Professor

13

SALA, nem NÚMERO-DASALA é completamente dependente funcional do NOME-

DO-PROFESSOR. Neste caso, NOME-DOPROFESSOR é realmente

completamente dependente funcional da chave candidata concatenada NOME-

FILHO + NÚMERO-DASALA ou NÚMERO-DASALA é completamente dependente

funcional da chave candidata concatenada NOME-DOFILHO + NOME-

DOPROFESSOR. Ao se aplicar a FNBC, a entidade FILHO deve ser dividida em

duas entidades, uma que contém os atributos que designam um professor em uma

particular escola e número de sala.

8. QUARTA FORMA NORMAL (4FN)

Na maioria dos casos, as entidades normalizadas até a 3FN são fáceis de

entender, atualizar e de se recuperar dados. Mas às vezes podem surgir problemas

com relação a algum atributo não chave, que recebe valores múltiplos para um

mesmo valor de chave. Esta nova dependência recebe o nome de dependência

multivalorada que existe somente se a entidade contiver no mínimo três atributos;

• Uma entidade que esteja na 3FN também está na 4FN, se ela não contiver mais do

que um fato multivalorado a respeito da entidade descrita. Esta dependência não é o

mesmo que uma associação M:N entre atributos, geralmente descrita desta forma

em algumas literaturas.

• Dada a entidade hipotética a seguir:

Código do Fornecedor Código da Peça Código do Comprador

11111111111 BA3 113

11111111111 CJ10 113

11111111111 88A 435

11111111111 BA3 537

Nome do Filho

Endereço do Filho

Data de Nascimento

Nome da Escola

Número da Sala

Nome da Escola

Número da Sala

Nome do Professor

14

Como podemos observar, esta entidade tenta conter dois fatos multivalorados: as

diversas peças compradas e os diversos compradores. Com isto apresenta uma

dependência multivalorada entre CÓDIGO-FORNECEDOR e o CÓDIGO-PEÇA e

entre CÓDIGO-FORNECEDOR e o CÓDIGOCOMPRADOR. Embora esteja na 3FN,

ao conter mais de um fato multivalorado, torna a sua atualização muito difícil, bem

como a possibilidade de ocorrer problemas relativos ao espaço físico de

armazenamento, causados pela ocupação desnecessária de área de memória. Para

passarmos a entidade acima para a 4FN, é necessária a realização de uma divisão

da entidade original, em duas outras, ambas herdando a chave CÓDIGO-

FORNECEDOR e concatenado, em cada nova entidade, com os atributos CÓDIGO-

PEÇA e CÓDIGO-COMPRADOR.

9. QUINTA FORMA NORMAL(5FN)

Uma tabela está na 5FN se estiver na 4FN e um relacionamento triplo não puder ser decomposto em relacionamentos binários sem geração de informação incorreta.Caso especial: Relacionamento envolvendo Chaves primárias de 3 tabelas, que nem sempre é possível decomposição correta. Exemplo: relacionamento Agente-Companhia-Produto.

Agente Companhia ProdutoJoão Ford CarroJoão GM Caminhão

Formato necessário quando existem apenas algumas combinações entre os 3

atributos (tabela c/ tripla).

Situação: Se um agente vende um certo produto e ele representa uma companhia, então ele vende um produto fabricado por esta companhia . Todos os pares secombinam!

Agente Companhia Produto

João Ford Carro

João Ford Caminhão

Código do Fornecedor

Código do Comprador

Código do Fornecedor

Código da Peça

15

João GM Carro

João GM Caminhão

Carlos Ford Carro

Neste caso, é possível decompor uma tripla em três

relações binárias com eliminação de certas

redundâncias. As três relações abaixo estão na

5FN:

Agente CompanhiaJoão FordJoão GMCarlos Ford

Eliminação de certas redundâncias:

- Apenas uma vez está dito que Ford produz carros;

- Apenas uma vez está dito que João é agente da GM.

Apesar do aumento no número de tabelas, o número total de tuplas na forma

normalizada é menor.

Agente ProdutoJoão CarroJoão CaminhãoCarlos Carro

Companhia

Produto

Ford CarroFord Caminh

ãoGM CarroGM Caminh

ão

16

CONCLUSÃO

Projetar um banco de dados sem lançar mão das ferramentas disponíveis,

tais como as ”formas normais” pode acarretar sérios problemas posteriormente. O

estudo das formas normais é sem dúvida um dos mais importantes em Banco de

Dados. A normalização de dados é provavelmente um dos aspectos mais abordados

em modelagem de banco de dados. Antes de construirmos um modelo de dados a

ser utilizado em uma aplicação, devemos tratar alguns pontos sobre sua

normalização. Esses pontos estão relacionados a se usamos ou não as formas

normais, qual dessas formas usar em uma aplicação e quando devemos

desnormalizar o modelo. Tudo depende do projetista do banco de dados. Aqui,

tratamos brevemente do conceito de formas normais, já que seu estudo é vasto

mas, suas vantagens são excepcionalmente notórias.

17

REFERÊNCIAS BIBLIOGRÁFICAS

DATE,C.J. Introdução a Sistemas de Banco de Dados (Cap. 11 e 12). 7ª Edição.

Editora Campus, 2000.

KROENKE,David M. Banco de Dados: Fundamentos, Projeto e Implementação.

(Cap. 5). 6ª Edição. Editora LTC, 1999.

http://www.poli.usp.br/d/pmr2490/Curso%20SQL-1-PMR.pdf - Bancos de Dados

Relacionais

http://www.aprendercomastics.net/tic/materiaisapoio/Normalizacao.pdf-

Normalização