Re: [firebase-br] Normalização...

Ter Out 18 15:05:29 -03 2005

Se vc pegar o texto original de Edward Codd, dos anos 1970, verá que são 
muito mais que 5 formas normais...
De qualquer maneira, segue a explicação (fiz apenas um copiar/colar da 
internet: não sou o autor do texto!) que vc solicitou:

NORMALIZAÇÃO

A técnica de Normalização, criada pelo matemático Edward Codd nos anos 70, é 
fundamentada na teoria Relacional de Bases de Dados, sendo composta por um 
conjunto de regras denominadas Formas Normais, que tem o objetivo de 
corrigir e/ou simplificar o conteúdo de depósitos de dados gerando arquivos 
relacionais.

Como principais benefícios da Normalização temos: eliminação de redundâncias 
de dados e conseqüentes anomalias de atualização, definição de chaves 
eficientes gerando registros identificáveis inequivocamente, simplificação 
na forma de arquivamento dos dados.

Notação para a Normalização:

NOME DO DEPÓSITO DE DADOS (chave primária, atributo 1, atributo 2, atributo 
3, ...)

Exemplo: ALUNO (código do aluno, nome, endereço, telefone, data de 
nascimento, ...)

1A. FORMA NORMAL

A primeira regra da Normalização tem por objetivo corrigir registros em que, 
para a chave primária, ocorrem "grupos de repetição", ou seja , atributos 
que possam assumir múltiplos valores.

REGRA: Se um depósito de dados apresentar grupos de repetição, desmembrá-lo, 
criando depósitos menores e sem grupo de repetição.

Exemplo para aplicação da 1a. forma normal:

PEDIDOS (número do pedido, data do pedido, data da entrega, meio de 
transporte, código do cliente, nome do cliente, endereço do cliente, 
telefone do cliente, valor total do pedido, código do produto, descrição do 
produto, quantidade pedida, preço unitário)

Repare que um pedido só pode ter uma data do pedido, data da entrega, código 
do cliente, etc.

Por outro lado, um pedido pode ter vários produtos com respectiva descrição, 
quantidade pedida, preço unitário e valor total do produto, o que configura 
um caso de grupo de repetição.

Desmembrar o depósito de dados da seguinte forma:

PEDIDOS (número do pedido, data do pedido, data da entrega, meio de 
transporte, código do cliente, nome do cliente, endereço do cliente, 
telefone do cliente, valor total do pedido).

ITENS DE PEDIDOS (numero do pedido, código do produto, descrição do produto, 
quantidade pedida, preço unitário)

2A. FORMA NORMAL

A segunda regra da Normalização tem por objetivo corrigir registros de chave 
composta que tenham atributos dependentes apenas de uma parte da chave.

REGRA: Se um depósito de dados apresentar atributos dependentes apenas de 
uma parte da chave composta, desmembrá-lo, criando depósitos menores em que 
os atributos sejam dependentes de toda a chave.

Exemplo para aplicação da 2a. forma normal:

ITENS DE PEDIDOS (número do pedido, código do produto, descrição do produto, 
quantidade pedida, preço unitário).

Repare que, para obter a quantidade pedida de um produto, é necessário saber 
o numero do pedido e o código do produto, ou seja, o atributo quantidade 
pedida depende de toda a chave .

Por outro lado, para obter a descrição do produto e o seu preço unitário, 
basta saber o código do produto, ou seja, estes atributos dependem apenas de 
parte da chave.

Desmembrar o depósito da seguinte forma:

ITENS DE PEDIDOS (número do pedido, código do produto, quantidade pedida).

PRODUTOS (código do produto, descrição do produto, preço unitário)

3A. FORMA NORMAL

A terceira regra da Normalização tem por objetivo corrigir registros que 
apresentem atributos dependentes de um atributo não chave, ou seja , 
atributos que não dependam da chave primária.

REGRA: Se um depósito de dados tiver atributo dependente de um atributo não 
chave, desmembrá-lo, criando depósitos menores em que os atributos só 
dependam da chave primária.

Exemplo para aplicação da 3a. forma normal:

PEDIDOS (número do pedido, data do pedido, data da entrega, meio de 
transporte, código do cliente, nome do cliente, endereço do cliente, 
telefone do cliente, valor total do pedido)

Repare que, para obter data do pedido, data da entrega, meio de transporte, 
código do cliente e valor total do pedido, é preciso saber o numero do 
pedido.

Por outro lado, para obter nome do cliente, endereço do cliente e telefone 
do cliente, basta saber o código do cliente, o que configura um caso de 
atributos que dependem de outro atributo não chave.

Desmembrar o depósito de dados da seguinte forma:

PEDIDOS (número do pedido, data do pedido, data da entrega, meio de 
transporte, código do cliente, valor total do pedido).

CLIENTES (código do cliente, nome do cliente, endereço do cliente, telefone 
do cliente).

Após a aplicação das 3 Formas Normais, o depósito de dados PEDIDOS 
transformou-se em 4 arquivos relacionais:

CLIENTES (código do cliente, nome do cliente, endereço do cliente, telefone 
do cliente)

PEDIDOS (numero do pedido, data do pedido, data da entrega, meio de 
transporte, código do cliente, valor total do pedido)

ITENS DE PEDIDOS (numero do pedido, código do produto, quantidade pedida)

PRODUTOS (código do produto, descrição do produto, preço unitário)

4a. e 5a. FORMAS NORMAIS

A quarta e quinta formas normais lidam com dependências multivaloradas e 
chaves compostas com mais de 2 atributos.

A aplicação dessas regras é considerada opcional pela maioria dos 
Metodologistas de desenvolvimento de sistemas por não representarem 
transgressão à Estrutura Relacional de Bancos de Dados.

Na realidade, essas 2 regras da normalização tem por objetivo otimizar a 
construção de arquivos relacionais, facilitando atualizações de registros.

A quarta forma normal lida com casos onde uma chave composta pode ser 
desmembrada em chaves menores, desde que não haja dependência entre todos os 
componentes da chave.

De acordo com a quarta forma normal, um registro que tenha dois ou mais 
fatos multivalorados, independentes, pode ser desmembrado em registros 
menores, minimizando redundâncias e anomalias de atualização.

Por exemplo, considerando o caso de empregados, suas habilidades e idiomas 
praticados, em que temos dois relacionamentos do tipo muitos para muitos 
(empregados-habilidades e empregados-idiomas) e temos também a independência 
dos atributos habilidades e idiomas, pela quarta forma normal o depósito de 
dados contendo chave composta por 3 atributos, poderia ser desmembrado em 2 
registros.

Dessa forma um dos registros teria a chave empregado-habilidade e o outro 
teria a chave empregado-idioma.

A quinta forma normal trata casos em que uma informação pode ser recomposta 
a partir de quantidades menores de informação, minimizando redundâncias. As 
outras formas normais também servem a esse propósito, mas a quinta forma 
normal abrange os casos que as outras não atendem.

De acordo com a quinta forma normal, um registro que tenha dois ou mais 
fatos multivalorados, apesar de dependentes, pode ser desmembrado em 
registros menores, desde que permitam reconstruir a informação original.

Por exemplo, considerando o caso de vendedores, fabricantes de veículos e 
tipos de veiculo, em que temos 3 relacionamentos do tipo muitos para muitos 
(vendedores-fabricantes, fabricantes-tipos, e vendedores-tipos) e temos 
também dependência entre os atributos, pela quinta forma normal o depósito 
de dados contendo chave composta por 3 atributos, poderia ser desmembrado em 
3 registros.

Dessa forma um dos registros teria a chave vendedor-fabricante, outro 
registro teria a chave fabricante-tipo de veiculo e o outro teria a chave 
vendedor-tipo de veiculo.

Porém, cabe ressaltar que a reconstrução da informação original só poderá 
ocorrer com a consulta aos 3 registros resultantes do desmembramento. A 
partir dos 2 primeiros registros sabemos que um determinado vendedor 
representa um fabricante e que um fabricante produz um tipo de veiculo, mas 
só saberemos se o vendedor vende um tipo de veiculo acessando o ultimo 
registro.

A quarta e quinta formas normais lidam com combinações de fatos 
multivalorados. Uma diferença é que os fatos tratados na quinta forma normal 
são dependentes. Outra diferença é que, embora a quarta forma normal possa 
tratar com mais do que dois fatos multivalorados, ela só lida com eles aos 
pares.

CONCLUSÃO

As formas normais, definidas na teoria relacional de bancos de dados, 
representam regras de conduta na definição de registros de arquivos. A 
técnica de normalização tem as seguintes características:

- exige conhecimento prévio dos dados, portanto deve ser desenvolvida após a 
Análise Funcional.

- induz o desenvolvedor a definir com precisão os dados realmente úteis e

necessários ao sistema, com refinamentos sucessivos de registros.

- elimina redundâncias, ambigüidades, duplicações de registros e anomalias

de atualização.

Para ter certeza de que o trabalho de normalização foi concluído com 
sucesso, verifique se os registros criados atendem à seguinte condição 
genérica: arquivo normalizado é aquele em que todos os campos (atributos) do 
registro (instância) dependem da chave primaria, de toda a chave e nada mais 
do que a chave.

Um abraço,

Valdir Marcos

----- Original Message ----- 
From: "Robert Nunes" <robertcnunes em yahoo.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Tuesday, October 18, 2005 9:46 AM
Subject: [firebase-br] Normalização...

galera alguém sabe a descrição correta das 5 formas normais, pra a aplicação 
da normalização em uma base de dados....

[]'s
_________________________________________________
Robert Nunes.
Pacto & Byte's Consultoria em TI.
Analista/Programador de Sistemas de Informação.
Bandeirantes - Pr.
robert em pactoconsultoria.com.br; robertcnunes em yahoo.com.br
_________________________________________________
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço 
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa