Normalização em Bancos de Dados
Este artigo descreve o que é o processo de normalização em bancos de dados e quais os benefícios obtidos. Este documento também explica os conjuntos de regras chamados de “formas normais”, inerentes ao processo de normalização e ilustra como se dá o procedimento.
Normalização
Normalização é o processo de modelar o banco de dados projetando a forma como as informações serão armazenadas a fim de eliminar, ou pelo menos minimizar, a redundância no banco. Tal procedimento é feito a partir da identificação de uma anomalia em uma relação, decompondo-as em relações melhor estruturadas.
Normalmente precisamos remover uma ou mais colunas da tabela, dependendo da anomalia identificada e criar uma segunda tabela, obviamente com suas próprias chaves primárias e relacionarmos a primeira com a segunda para assim tentarmos evitar a redundância de informações.
O processo de normalização compreende o uso de um conjunto de regras, chamados de formas normais. Ao analisarmos o banco de dados e verificarmos que ele respeita as regras da primeira forma normal, então podemos dizer que o banco está na “primeira forma normal”. Caso o banco respeite as primeiras três regras, então ele está na “terceira forma normal”. Mesmo existindo mais conjuntos de regras para outros níveis de normalização, a terceira forma normal é considerada o nível mínimo necessário para grande parte das aplicações. [Microsoft 2007]
Um banco de dados dentro dos padrões de normalização reduz o trabalho de manutenção e ajuda a evitar o desperdício do espaço de armazenamento. Se tivermos cadastrado no banco um cliente e tivermos o seu telefone registrado em mais de uma tabela, havendo uma alteração no seu número de telefone, teremos que fazer essa atualização em cada tabela. A tarefa se torna muito mais eficiente se tivermos seu telefone registrado em apenas uma tabela.
Os próximos parágrafos demonstram melhor as anomalias no banco de dados e as diferentes regras de normalização, bem como a forma de aplicá-las para estruturarmos o banco de dados da melhor maneira possível.
Formas Normais
Como mencionado anteriormente, temos conjuntos de regras para determinar com qual forma normal o banco é compatível. Primeiramente, precisamos verificar se encontramos compatibilidade com a primeira forma normal. Caso esteja tudo conforme, analisamos se a segunda forma normal se encaixa e assim sucessivamente.
É importante lembrar que para uma relação atender as exigências de uma forma normal, se faz necessário que esta obedeça as regras da forma normal anterior. A primeira forma normal é exceção pois não existe uma forma normal anterior a primeira.
Primeira Forma Normal
Uma relação está na primeira forma normal quando todos os atributos contém apenas um valor correspondente, singular e não existem grupos de atributos repetidos — ou seja, não admite repetições ou campos que tenham mais que um valor.
O procedimento inicial é identificar a chave primária da tabela. Após, devemos reconhecer o grupo repetitivo e removê-lo da entidade. Em seguida, criamos uma nova tabela com a chave primária da tabela anterior e o grupo repetitivo.
Analisando o exemplo acima, podemos observar dois problemas: temos uma pessoa com dois números de telefone e um endereço com diferentes valores, a rua e o bairro. A fim de normalizar, teremos que colocar cada informação em uma coluna diferente e criar uma nova tabela relacionando a pessoa a seus números de contato.
Dessa forma, como mostrado na tabela acima, temos uma tabela na primeira forma normal evitando assim repetições e campos com múltiplos valores, conforme observamos na tabela abaixo.
Segunda Forma Normal
É dito que uma tabela está na segunda forma normal se ela atende a todos os requisitos da primeira forma normal e se os registros na tabela, que não são chaves, dependam da chave primária em sua totalidade e não apenas parte dela. A segunda forma normal trabalha com essas irregularidades e previne que haja redundância no banco de dados.
Para isso, devemos localizar os valores que dependem parcialmente da chave primária e criar tabelas separadas para conjuntos de valores que se aplicam a vários registros e relacionar estas tabelas com uma chave estrangeira.
Podemos observar que a tabela acima apresenta uma coluna responsável por armazenar o título do filme, onde este foi alugado e está associado a um número de locação. Porém, ele também está associado a um código, tornando-o então um valor que não é totalmente dependente da chave primária da tabela.
Se em algum momento tivermos que alterar o título de um filme, teríamos que procurar e alterar os valores em cada tupla (linha) da tabela. Isso demandaria um trabalho e tempo desnecessário. Porém, ao criarmos uma tabela e vincularmos elas com o recurso da chave estrangeira, tornamos o nosso banco mais organizado e ágil para as futuras consultas e manutenções que podem vir a ser necessárias.
Terceira Forma Normal
Se analisarmos uma tupla e não encontrarmos um atributo não chave dependente de outro atributo não chave, podemos dizer que a entidade em questão está na terceira forma normal - contanto que esta não vá de encontro as especificações da primeira e da segunda forma normal.
Como procedimento principal para configurar uma entidade que atenda as regras da terceira forma normal, nós identificamos os campos que não dependem da chave primária e dependem de um outro campo não chave. Após, separamos eles para criar uma outra tabela distinta, se necessário.
No exemplo acima temos uma entidade que lista os carros cadastrados, bem como o modelo, a quantidade de quilômetros rodados, o código do fabricante e o nome do fabricante. Observamos que “nome_fab” se dá em função de “cod_fab”. Para adequarmos esta tabela de acordo com os padrões da terceira forma normal, devemos remover a coluna do nome do fabricante.
A coluna que removemos deve ser colocada em uma nova tabela, relacionando corretamente o nome do fabricante com o seu código. Abaixo, podemos observar como ficaria esta nova entidade.
Quarta Forma Normal
Uma entidade está na quarta forma normal quando ela estiver na terceira forma normal e não existir dependências multivaloradas entre seus atributos, ou seja, campos que se repetem em relação a chave primária, gerando redundância nas tuplas da entidade. Devemos fragmentar essa relação com o objetivo de não termos mais essas dependências funcionais do gênero.
Em outras palavras, quando houver repetição de dois ou mais atributos não chave, gerando uma redundância desnecessária na tabela, dividimos essa tabela em dois ou mais subgrupos evitando assim o problema da redundância. [Silva 2010]
Conforme o exemplo acima, temos uma tabela relacionando música, cantor e álbum, contendo as músicas. Uma música pode ser interpretada por um artista e esta pode estar em um ou mais álbuns ou ser interpretada por outro artista. Para evitarmos a repetição de informações, devemos dividir a tabela.
Conclusão
Considerando as dificuldades de elaborar um projeto para um sistema e planejar toda a modelagem de um banco de dados robusto, ágil e seguro, as regras para normalização de dados aplicadas da forma correta contribuem consideravelmente para a criação de uma boa estrutura das bases de dados relacionais, evitando anomalias de redundância ou perda de informação.
Dessa forma, a pessoa que vai analisar a documentação de uma modelagem normalizada consegue abstrair com mais clareza, pois uma vez conhecendo os padrões, a compreensão é facilitada e agiliza todo o trabalho. Como desvantagem podemos citar o aumento do número de tabelas. Bancos devidamente construídos, ou seja, na terceira forma normal, apresentam um número maior de tabelas em comparação aos bancos não normalizados. Assim, as consultas em bancos com mais tabelas requerem uma complexidade maior na elaboração do SQL, fazendo necessário o uso dos Joins e cláusulas para elaborarmos a consulta adequadamente.
Dado o exposto, a aplicação das regras de normalização de dados é altamente recomendada, pois os ganhos são consideravelmente relevantes. Investir um pouco mais de dedicação e tempo trabalhando com um número maior de tabelas trás mais benefícios do que um banco de dados sem a devida organização.
Referências
CALÇADO, Bruno. Normalização de Banco de Dados. 2010. Disponível em: <http://wiki.sintectus.com/bin/view/SGBD/LicaoNormalizacaoDeBD#Varia_o_da_3FN_Forma_Normal_Boyc>. Acesso em: 20 jul. 2011.
CONTRIBUIDORES DA WIKIPÉDIA. Normalização de dados. Wikipédia, a enciclopédia livre. 2011. Disponível em: <http://pt.wikipedia.org/w/index.php?title=Normaliza%C3%A7%C3%A3o_de_dados&oldid=25486265>. Acesso em: 20 jul. 2011.
CONTRIBUIDORES DA WIKIPÉDIA. Banco de dados relacional. Wikipédia, a enciclopédia livre. 2011. Disponível em: <http://pt.wikipedia.org/w/index.php?title=Banco_de_dados_relacional&oldid=25887344>. Acesso em: 20 jul. 2011.
MICROSOFT. Descrição dos conceitos de normalização banco de dados básicos. 2007. Disponível em: <http://support.microsoft.com/kb/283878/pt-br>. Acesso em: 20 jul. 2011.
SILVA, Eduardo. Banco de Dados — Aula 10. Normalização de Dados. 2010. Disponível em: <http://www.conekti.com/site/index.php/apostilas/>. Acesso em: 20 jul. 2011.
SILBERSCHATZ, Abraham; Korth, Henry; Sudarshan, S. Sistema de Banco de Dados. 5. ed. Rio de Janeiro. Elsevier, 2006. 781p.
