Login:

iMasters | Por uma internet mais criativa e dinâmica

Feeds

Banco de Dados

Feed da seção Banco de Dados

Newsletter de Banco de Dados


Segunda-feira, 24/09/2007 - 09:05 - Por Mauri Gonçalves
Seções relacionadas:

Modelagem de Dados - Final (Normalização)

Caros leitores. Estou de volta com a última parte desta série, onde falarei sobre Normalização.

Normalização é um processo baseado nas chamadas formais normais. Uma forma normal é uma regra de deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem projetadas. Segundo autores, existem 4 formas normais. Neste artigo vou falar sobre as 3 primeiras, sendo as principais.

Com o banco de dados construído, devem-se aplicar as 3 formas normais em cada tabela, ou grupo de tabelas relacionadas. As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.

Então, vamos às normas:

1 Forma Normal: Verificação de Tabelas Aninhadas.

Para uma tabela estar na primeira forma normal ela não deve conter tabelas aninhadas. Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta: Este campo depende de qual?.

Vamos exemplificar, com a tabela Venda. Este é o esquema relacional da tabela:

Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

O raciocínio é o seguinte: A tabela Venda, deve armazenar informações da venda. Pois bem, verificando o campo Cliente, sabemos que ele depende de CodVenda, afinal para cada Venda há um cliente. Vendo o campo Endereço, podemos concluir que ele não depende de Codvenda, e sim de Cliente, pois é uma informação referente particularmente ao cliente. Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda. Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não á venda.

Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

A solução é extrair estes campos para uma nova tabela, adicionar uma chave-primária à nova tabela e relaciona-la com a tabela Venda criando uma chave-estrangeira.

Ficaria desta forma:

Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).

Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal).

Agora aplicamos novamente á primeira forma normal as 2 tabelas geradas. Uma situação comum em tabelas de cadastro é o caso Cidade-Estado. Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade. No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina. Isso é o que chamamos de Dependência funcional: é onde aparentemente, uma informação depende da outra. No caso Cidade-Estado a solução é simples:

Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida, o mesmo processo feito anteriormente: adicionar uma chave-primária à nova tabela e relaciona-la criando uma chave-estrangeira na antiga tabela.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).

Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal).

Seguindo com o exemplo, a tabela Cliente encontra-se na 1 forma normal, pois não há mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela aninhada. Os campos entre colchetes são referente á mesma coisa: Produto de Venda

Venda (Codvenda, Codcliente, Codcidade, [Produto Quantidade, [Valorunitario, Valorfinal).

Na maioria das situações, produtos têm um valor previamente especificado. O Valorunitário depende de Produto. Já a Quantidade (campo entre Produto e Valorunitario) não depende do produto e sim da Venda.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).

Produto (Codproduto, Nome, Valorunitario).

Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas. Vamos á próxima forma

2 Forma Normal: Verificação de Dependências Parciais

Para uma tabela estar na segunda formal, além de estar na primeira forma ela não deve conter dependências parciais. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se não, temos uma dependência parcial..

Vimos antes o caso Cidade-Estado que gerava uma dependência funcional. É preciso entender este conceito para que você entenda o que é Dependência Parcial.

Após a normalização da tabela Venda, acabamos com uma chave composta de 4 campos:

Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

A questão agora é verificar se cada campo não-chave depende destas 4 chaves. O raciocínio seria assim:

  1. O primeiro campo não-chave é Quantidade.
  2. Quantidade depende de Codvenda, pois para cada venda há uma quantidade específica de itens.
  3. Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser feitas várias vendas, com quantidades diferentes.
  4. Quantidade não depende de Cidade. Quem depende de Cidade é Cliente. Aqui está uma dependência parcial.
  5. Quantidade depende de Codproduto, pois para cada produto da Venda á uma quantidade certa.

Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda. Quem sobrou nessa história foi Codcidade. A tabela Cidade já está ligada com Cliente, que já está ligado com Venda. A chave Codcidade em Venda é redundante, portanto podemos eliminá-la.

Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal).

O próximo campo não-chave é Valorfinal. Verificando Valorfinal, da mesma forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos á próxima norma.

3 Forma Normal: Verificação de Dependências Transitivas

Para uma tabela estar na segunda formal, além de estar na segunda forma ela não deve conter dependências transitivas. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que não seja a chave? Se Sim, temos uma dependência transitiva..

No exemplo de Venda, temos um caso de dependência transitiva:

Na tabela Venda, temos Valorfinal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um valor final existir ele DEPENDE de valor unitário e quantidade. O Valorunitário está na tabela Produto, relacionada à Venda e Quantidade está na própria Venda. Valorfinal depende destes 2 campos e eles não são campos-chave, o que nos leva a pensar: Se temos valor unitário e quantidade, porque teremos valor final? O valor final nada mais é que o resultado de um cálculo de dados que já está estão no banco, o que o torna um campo redundante.

Quando for necessário ao sistema obter o valor final, basta selecionar o valor unitário e multiplicar pela quantidade. Não há porque guardar o valor final em outro campo. Aqui a solução é eliminar o campo Valorfinal.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone).

Produto (Codproduto, Nome, Valorunitario).

Venda (Codvenda, Codcliente, Codproduto, Quantidade).

Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do campo Estado na tabela Cidade, mas eu deixarei para uma outra ocasião, pois o objetivo aqui é mostrar conceitualmente o processo de normalização do banco de dados.

É muito comum, no processo de normalização enxergamos todas as formas normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, já conseguimos ver as dependências transitivas e logo mais encontramos uma dependência parcial, tudo assim, ao mesmo tempo. Isso é normal. Só tome cuidado, para não deixar nada passar batido.

Reforçando o recado do artigo anterior: tem muito mais a ser visto sobre as etapas que eu mostrei nessa série. Aqui foi só uma demonstração do que se deve levar em conta ao modelar e construir um banco de dados íntegro, correto e que aproveita os dados da forma mais eficiente possível.

Um abraço à todos e até o próximo artigo!

Todos os artigos de Mauri Gonçalves

5 comentários publicados

  • 1. Modelagem de dados

    Sexta-feira, 28/09/2007, por sidneida de sá

    Texto simples, claro e objetivo. É disso que precisamos. Que continue assim.

    Responder comentário

  • 2. modelagem de dados

    Segunda-feira, 29/10/2007, por Luiz Otavio Campos Pereira

    Material bem didático. Excelente para quem está começando e, até mesmo, para aqueles que conhecem um pouco mais do assunto.

    Responder comentário

  • 3. 1Fn: Tabelas aninhadas

    Quarta-feira, 12/03/2008, por Fernanda Rigamont

    Não concordei com a primeira Forma Normal: verificação de tabelas aninhadas.
    A tabela venda não precisa da chave estrangeira Codcidade, uma vez que a tabela cliente sabe qual é a sua cidade e consequentemente a venda sabe qual a cidade

    Responder comentário

  • 4. Modelagem de Dados - Final (Normalização) - Cont...

    Terça-feira, 06/05/2008, por Hilder Nunes

    Muito bom seu material, bem claro.Eu sem saber dessas formalidades uso-as constantemente, acho, por isso ficou tudo tão fácil de entender na sua matéria. Porém não utilizo chaves estrangueiras... Mas, desde já,espero anciosamente pelo caso "Cidade / Estado". valew!

    Responder comentário

  • 5. Valor Final Imdispensavel

    Sábado, 21/06/2008, por Cleidson Dias do Nascimento

    Bem...
    So discordo quando o quesito do Valor final que voce dispensou em seu banco de dados, por experiencia propia sei que nao pode desperezar o valor final, uma vez que o usuario pode mudar o valor unitario, e se ficar a criterio do computador executar a multiplicação ("Quantidade * ValorInicial"), Toda vez que for fazer uma pesquisa a Venda retornara o Valor atualizado, o que não e o caso, sendo que cada venda tambem acumula o valor historico da mesma

    Responder comentário

Poste um comentário


Os textos publicados neste espaço são de responsabilidade única de seus autores (colunistas e leitores) e podem não expressar necessariamente a opinião do iMasters.

Sobre o autor

Mauri Gonçalves é formando em Análise de Sistemas pela Faculdade de Ciências Sociais Aplicadas de Cascavel (PR). Já atuou como designer gráfico, webdesigner e hoje trabalha com projeto e desenvolvimento de sistemas small business pela MG Sistemas como home-officer.


Indique para um amigo

captcha

TI SHOP Produtos iMasters

  • Lançamento: CD-ROM Treinamento Aplicado de SQL - Lançamento! Treinamento Aplicado de SQL - Aprenda a trabalhar com SQL com bancos de dados Oracle e SQL Server. São mais de 100 tópicos explicados por Mauro Pichilliani, um articulistas mais lidos do iMasters. Aproveite! Apenas R$ 69,90 no TI SHOP.
  • Lançamento: Livro iMasters "O Encontro de 2 Mundos"- Este livro conta com 56 crônicas de profissionais mais admirados e influentes do mercado brasileiro de Internet. Aproveite o preço especial para leitores do iMasters. Apenas R$ 40,00 e envio imediato!
  • DVD Curso Completo de Photoshop - Do conceito à finalização Lançamento! Curso Completo de Photoshop, em DVD, com mais de 230 aulas dividas em 4 módulos: conceito, básico, avançado e finalização. Apenas R$ 69,50 no TI SHOP - Frete com 50% de desconto
  • DVD Javascript Starter - Curso Completo Com mais de 9 horas de vídeo-aulas, é um curso completo sobre Javascript. Ideal para quem deseja aprender a linguagem. Apenas R$ 64,90 no TI SHOP - Frete com 50% de desconto!

2001 - iMasters FFPA Informática Ltda - Todos os direitos reservados.