Normalizao de Tabelas

O conceito de Normalizao e formas normais sem dvidas um dos conceitos mais importantes do Modelo Relacional. Ou seja, um Processo que consiste em estruturar as tabelas e atributos por forma a eliminar redundncias e evitar problemas com a insero, eliminao e atualizao dos dados.

Objetivo
O objetivo da normalizao evitar os problemas provocados por falhas no Projeto da Base de Dados, bem como eliminar a "mistura de assuntos e as correspondentes repeties desnecessrias 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 no Misturar assuntos em uma mesma Tabela". Por exemplo, na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. No devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetio desnecessria dos dados bem como inconsistncia dos dados. O Processo de Normalizao aplica uma srie de Regras sobre as Tabelas de uma Base de Dados, para verificar se estas esto corretamente projetadas. Embora existam 5 formas normais (ou regras de Normalizao), na prtica usamos um conjunto de 3 Formas Normais. Normalmente aps a aplicao das Regras de Normalizao, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um nmero maior de tabelas do que o originalmente existente. Este processo causa a simplificao dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manuteno. Vamos entender o Processo de Normalizao na Prtica, atravs de exemplos.

Primeira Forma Normal

"Uma Tabela est na Primeira Forma Normal quando seus atributos no contm grupos de Repetio". Por isso dissemos que uma Tabela que possui Grupos de Repetio no est na Primeira Forma Normal. Considere a estrutura da Tabela Indicada na Prxima Figura:

Tabela que no est na Primeira Forma Normal.

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 Me diversas vezes, tantas quantos

forem os filhos. Isso forma um Grupo de Repetio. Alm do mais pode ser que por erro de digitao o Nome dos Pais no seja digitado exatamente igual todas s vezes, o que pode acarretar problemas na hora de fazer pesquisas ou emitir relatrios. Este problema ocorre porque "Misturamos Assuntos" em uma mesma tabela. Colocamos as informaes dos Pais e dos Filhos em uma mesma tabela. A soluo para este problema simples: Criamos uma tabela, separada para a Informao dos Pais e Relacionamos a tabela Pais com a Tabela Filhos atravs de um relacionamento do tipo Um para Vrios, ou seja, um casal da tabela Pais pode ter Vrios Filhos. Observem na figura abaixo as duas tabelas: Pais e Filhos, j normalizados.

Informaes sobre Pais e Filhos em Tabelas Separadas.

As duas tabelas Resultantes da Aplicao da Primeira Forma Normal: Pais e Filhos esto na Primeira Forma Normal, as Tabelas Originais, a qual misturava informaes de Pais e Filhos, no estava na Primeira forma Normal.

Segunda Forma Normal

Ocorre quando a chave Primria composta por mais de um campo. Neste caso, devemos observar se todos os campos que no fazem parte da chave dependem de todos os campos que compem a chave. Se algum campo depender somente de parte da chave composta, ento este campo deve pertencer outra tabela. Observe o Exemplo Indicado na Tabela da Figura abaixo:

Tabela com uma Chave Primria Composta. No est Na Segunda Forma Normal.

A Chave Primria Composta formada pela combinao dos Campos "NmeroDaMatrcula" e "CdigoDoCurso". O Campo Avaliao depende tanto do CdigoDoCurso quanto do NmeroDaMatrcula, porm o campo DescrioDoCurso, depende apenas do CdigoDoCurso, ou seja, dado o cdigo do curso possvel localizar a respectiva descrio, independentemente do NmeroDaMatrcula. Com isso temos um campo que no faz parte da Chave Primria e depende apenas de um dos campos que compem a chave Primria Composta, por isso que dizemos que esta tabela no est na Segunda Forma Normal. A Resoluo para este problema tambm simples: Dividimos a Tabela que no est na Segunda Forma Normal em duas outras tabelas, conforme indicado pela figura abaixo, sendo que as duas tabelas resultantes esto na Segunda Forma Normal.

Informaes sobre Avaliaes e Cursos em Tabelas Separadas.

OBS: A Distino entre a Segunda e a Terceira forma normal, que veremos logo em seguida, muitas vezes confusa. A Segunda Forma normal est ligada a ocorrncia de Chaves Primrias compostas.

Terceira Forma Normal

Na definio dos campos de uma entidade podem ocorrer casos em que um campo no seja dependente diretamente da chave primria ou de parte dela, mas sim dependente de outro campo da tabela, campo este que no a Chave Primria. Quando isto ocorre, dizemos que a tabela no est na Terceira Forma Normal, conforme. indicado pela tabela da figura abaixo:

Tabela com um Campo dependente de Outro campo que no a Chave Primria. No est na Terceira Forma Normal.

Observe que o Campo DescrioDoCargo depende apenas do Campo CdigoDoCargo, o qual no faz parte da Chave Primria. Por isso dizemos que esta tabela no est na terceira forma normal. A Soluo deste problema tambm simples. Novamente basta dividir a tabela em duas outras, conforme indicado pela figura a seguir. As duas tabelas resultantes esto na Terceira Forma Normal.

Tabelas Resultantes que esto na Terceira Forma Normal.

Com isso podemos concluir que como resultado do Processo de Normalizao, iremos obter um nmero maior de tabelas, porm sem problemas de redundncia e inconsistncia dos dados.

Exemplo prtico de normalizao de banco de dados

A normalizao de tabelas um passo fundamental no design de um banco de dados e da arquitetura de um sistema.

Voc ir precisar normalizar os dados em duas situaes principais: quando um campo do banco ser varivel como um vetor, ou quando julgar necessrio manter informaes devidamente separadas. Exemplo 1. Vendas e nota fiscal. Considere a seguinte tabela que armazena as vendas de uma papelaria. tabelaVendas - desnormalizada idVenda idCliente itens 1 1 3 cadernos, 5 lpis, 1 mochila 2 3 10 lpis, 2 borrachas, 300 folhas de sulfite 3 7 2 mochilas, 4 borrachas Como podemos ver, o campo itens armazena uma quantidade varivel de informao. Vamos aplicar a normalizao a na primeira forma normal, ou 1NF. tabelaVendas - quase 1NF idVenda idCliente item 1 Qtd 1 item 2 Qtd 2 item 3 Qtd 3 1 1 caderno 3 lpis 5 mochila 1 2 3 lpis 10 borracha 2 sulfite 300 3 7 mochila 2 borracha 4

OK, separamos as colunas para ter um e apenas um tipo de dado, mas ainda assim podemos ver que o design dessa tabela ainda bem falho. E se um consumidor quiser comprar mais de 4 itens na mesma compra? mesmo que vc crie 200 campos, certamente haver um ou outro caso onde esse limite ser um problema, sem contar nas desvantagens bvias de tamanho da tabela, espao ocupado (com informaes

nulas), e no trabalho para criar queries e relatrios em cima de uma tabela assim. Mas esta ainda no a verso terminada da 1NF. Podemos fazer um design um pouco melhor para obter isso. tabelaVendas - 1NF idVenda idCliente linhaDaVenda Item Qtd 1 1 1 caderno 3 1 1 2 lpis 5 1 1 3 mochila 1 2 3 1 lpis 10 2 3 2 borracha 2 2 3 3 sulfite 300 3 7 1 mochila 2 3 7 2 borracha 4 Pronto, chegamos assim primeira forma normal. Sem valores multiplos dentro de um campos, e sem multiplos campos para a mesma funo. Os mais atentos devem ter percebido um pequeno "problema" na tabela acima. No h nenhum campo que funcione bem como chave-primria. A chave-primria para se obter uma linha a combinao das colunas idVenda e linhaDaVenda. Para resolver isso aplicamos a segunda forma normal, 2NF, que diz que cada linha tem uma chaveprimria representada por um e apenas um campo. Considere a tabela anterior com um pouco mais de detalhes: tabelaVendas2 - 1NF idVenda idCliente Data linhaDaVenda Qtd idProduto descProduto 1 1 12/7/2010 1 3 1 caderno 1 1 12/7/2010 2 5 2 lpis 1 1 12/7/2010 3 1 3 mochila 2 3 13/7/2010 1 10 2 lpis 2 3 13/7/2010 2 2 4 borracha 2 3 13/7/2010 3 300 5 sulfite 3 7 15/7/2010 1 2 3 mochila 3 7 15/7/2010 2 4 4 borracha Vamos separar o que pertence a cada venda, do que pertence aos items de cada venda em duas tabelas. tabelaVendas2 - 2NF idVenda idCliente Data 1 1 12/7/2010 1 1 12/7/2010 1 1 12/7/2010 2 3 13/7/2010 2 3 13/7/2010 2 3 13/7/2010 3 7 15/7/2010 3 7 15/7/2010

tabelaDetalheVenda - 2NF idVenda linhaDaVenda Qtd idProduto descProduto 1 1 3 1 caderno 1 2 5 2 lpis 1 3 1 3 mochila 2 1 10 2 lpis 2 2 2 4 borracha 2 3 300 5 sulfite 3 1 2 3 mochila 3 2 4 4 borracha Note que as duas tabelas esto agora relacionadas pelo campo idVenda, que chave-primria da primeira tabela e chave-estrangeira na segunda. Estamos agora a um passo da terminar a normalizao destas entidades (geralmente se aplica a normalizao at sua terceira forma normal. Dificilmente formas de normalizao superiores se fazem necessrias). Vamos separar os dados dos produtos da tabela de detalhes de venda (Note que a tabela de vendas j est completamente normalizada). tabelaDetalheVenda - 3NF idVenda linhaDaVenda Qtd idProduto 1 1 3 1 1 2 5 2 1 3 1 3 2 1 10 2 2 2 2 4 2 3 300 5 3 1 2 3 3 2 4 4 tabelaProdutos - 3NF idProduto descricaoProduto 1 caderno 2 lpis 3 mochila 4 borracha 5 sulfite

Pronto. Normalizado.