Normalizar ou não normalizar: eis a questão! Parte 1

No início da vida acadêmica com bancos de dados, somos logo apresentados a algo que nos acompanhará o resto de nossas carreiras: a normalização. Pra quem não lembra, basicamente são 3 formas normais (e mais uma extra) que devem/podem ser aplicadas no banco de dados a fim de garantir maior integridade e consistência  nas informações. Como exemplos são melhores que texto, vamos discutir esse tema através de uma aplicação prática.

Imagine um banco de dados de pedidos (de vendas),  no qual temos as funcionalidades mais básicas: clientes, produtos e pedidos. Uma modelagem inicial poderia ser:

TB_ClienteTB_ProdutoTB_Pedido
NomeDescriçãoNome_Cliente
EndereçoAtivoNome_Produto
AtivoData
Entregue
Telefone
Fidelidade

Para fins deste estudo, não vamos controlar estoques, senão o exemplo cresceria demais e fugiria ao objetivo deste estudo. Considere que a loja tem muito de todos os itens. Vamos entender e preencher com alguns dados:

TB_Cliente
NomeEndereco
LeviRua dos Encantos Nº 6, Salvador, Bahia
SallieTravessa da Imaginação, bloco A, São Paulo,São Paulo
ArthurLadeira dos Poetas, SN, Goiânia, Goiás
Este campo chamado “Ativo” permite a exclusão lógica do registro
TB_Produto
Descricao
Mel
Cravos
Incensos

A tabela TB_Pedido tem a ideia de saber quem pediu o que. Vamos a ela:

TB_Pedido
Nome_ClienteProdutosDataEntregueTelefoneFidelidade
SallieCravos
Mel
01/01/2020Não3232-3232Sim
ArthurIncensos01/02/2020Sim7777-6666Não
LevyMel01/03/2020Não1212-9090Não
Neste caso, temos o nome do cliente que comprou o item, os itens comprados, a data do pedido, se foi entregue ou não e na loja temos um programa de fidelidade, alguns clientes participantes recebem sempre um desconto na compra.

Discutindo problemáticas

Antes de discutirmos de fato as formas normais, alguns adiantados já perceberam que o banco não tem chaves primárias. Pra quem não lembra, as chaves primárias são identificadores únicos das tabelas, são aqueles “Cod” ou “ID” que servem para garantir a atomicidade dos dados (discutiremos atomicidade em um próximo post). Parece que nosso banco de dados já apresenta uma inconsistência. Reparem na tabela TB_Pedido, a linha 3, a atendente no momento do cadastro escreveu o nome do cliente errado, era Levi e ela escreveu Levy. O que acontece quando eu pesquisar todas as compras onde o cliente for “Levi”? Exato, não teremos resultados e esse pedido e o mesmo ficará no limbo do banco de dados. Para evitar esta situação – e dezenas de outras – devemos adicionar as chaves primárias no nosso banco para garantir que o Levi cliente é o mesmo Levi que fez o pedido. O mesmo para a tabela TB_Produto. Vamos lá:

TB_ClienteTB_ProdutoTB_Pedido
ID_ClienteID_ProdutoNome_Cliente
NomeDescriçãoNome_Produto
EndereçoData
Entregue
Telefone
Fidelidade
Adicionamos na tabela TB_Cliente e na tabela TB_Produto suas respectivas chaves primárias. Considere o tipo do dado como número inteiro.

Pronto! Vamos ver agora os dados como ficaram:

TB_Cliente
ID_ClienteNomeEndereço
1LeviRua dos Encantos Nº 6, Salvador, Bahia
2SallieTravessa da Imaginação, bloco A, São Paulo, São Paulo
3ArthurLadeira dos Poetas, SN, Goiânia, Goiás
Este campo chamado “Ativo” permite a exclusão lógica do registro
TB_Produto
ID_ProdutoDescrição
1Mel
2Cravos
3Incensos

Agora que já arrumamos as tabelas de cliente e de produtos, vamos organizar a tabela de pedidos. Para isto, vamos lembrar do conceito de chaves estrangeiras, que são identificadores utilizados para referenciar uma linha (tupla) em outra tabela (relação) em um banco de dados relacional. Na prática, vamos trocar os nomes dos clientes na tabela TB_Pedido por seus respectivos IDs e vamos trocar também os nomes dos produtos por seus IDs. A ideia fundamental é que através do uso das chaves estrangeiras o próprio SGBD possa garantir a integridade, ou seja, quando a atendente digitar o ID_Cliente “1”, será o Levi e caso essa mesma atendente tente digitar um ID inexistente, como 4 ou 5, o SGBD não permitirá.

Nota: Alguns podem estar se perguntando porque os nomes não poderiam ser usados como chaves primária e estrangeira, uma vez que o banco de dados garantiria a integridade. Há varias razões para termos trocado por números, uma delas seria, por exemplo, a velocidade nas transações, já que um número inteiro ocupa 4 bytes (no MySQL) enquanto uma string com o nome ocuparia bem mais do que isso. Um char ocupa um byte, mas os nomes tem vários caracteres. Outro ponto seria o uso do AUTOINCREMENT, que ajuda bastante na inserção dos registros.

Vamos ver como ficou a tabela Tb_Pedido:

TB_Pedido
ID_ClienteID_ProdutosDataEntregueTelefoneFidelidade
22
1
01/01/2020Não3232-3232Sim
3301/02/2020Sim7777-6666Não
1101/03/2020Não1212-9090Não
Trocamos as strings dos nomes dos clientes e produtos por seus respectivos IDs, conforme constam nas tabelas TB_Cliente e TB_Produto.

Feito isto, as tabelas estão ajustadas e agora podemos – de fato – começar a nossa discussão sobre formas normais.

Publicado por

Murilo Freire

Formado em Análise de Sistemas, MBA em Gestão de Projetos, Mestrado em Biotecnologia e Doutorado - em curso - em Biotecnologia. Programei do Delphi ao PHP passando pelo Unity 3D, sempre fascinado por programação mas também por cultura pop, jogos (eletrônicos e de tabuleiro), aleatoriedades, Cabala, Tarô e bruxaria.

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.