Casal 10

Normalização em Banco de Dados
11 novembro 2009, por Edson, às 15:00

Introdução

Nos dias de hoje é praticamente impossível pensar num sistema grande sem pensar em banco de dados. Banco de Dados é o lugar onde se efetua a persistência das informações de modo a serem salvas e resgatadas quando necessário.
Porém você pode realizar isto de uma forma boa ou ruim e para isto foram criados definições de quão bem modelado está seu banco de dados. Lembrando apenas que, bem modelado não necessariamente vai ter uma boa performance.

Objetivo:

Sempre achei muito complicado a abordagem dos livros sobre banco de dados, abaixo tentarei abordar o tema com linguajar menos técnico e com exemplos práticos. Como tive que estudar normalização recentemente, vou explicar como você pode identificar e normalizar seu BD para pelo menos obedecer a 3ª Forma Normal, que geralmente é a que já tem um custo benefício bem proveitoso, a partir de uma tabela totalmente “zuada” incorreta até uma estrutura aceitável.

Não normalizado

Se falamos que vamos normalizar uma tabela, podemos começar por uma “tabela” não normalizada. E acreditem, todo profissional de TI vai encontrar situações como abaixo ao menos algumas vezes na vida.

Imagine um sistema onde os dados são guardados no formato texto da seguinte forma:

Como podem ver o nome da tabela não significa nada, o campo também não e dentro do campo todos os valores necessários estão na forma de texto.
Para piorar
Uma tabela assim (se é que pode se chamar de tabela), por vários motivos não está normalizada nem na forma normal 1.

1ª Forma Normal

O primeiro passo para colocar na forma normal, é criar uma tabela de verdade, com colunas e linhas. Veja abaixo:

Porém para estar na, 1ª Forma Normal, ainda é necessário não ter campos multi-valorados, ou seja, não pode ter um campo com vários valores (como ocorre com o campo notas). Para resolver isto deve-ser feito assim:

2ª Forma Normal

Para você ter uma tabela na 2ª FN obviamente ela precia estar pelo menos na 1ª FN. A partir daí você deve ter reparado que a tabela não tem apenas um assunto (entidade) mas dois (ou três), ela mistura tanto notas quanto alunos.
Para resolver isto precisamos criar uma segunda tabela e modificar a primeria. Veja abaixo:

Reparem que você ainda tem todos os dados, pois para saber de que aluno a nota pertence você percorre a outra tabela pelo código dele. De modo que a apesar de termos reduzido a chance de causar uma falha de integridade; e também termos reduzido drásticamente a quantidade de informação armazenada, todas as informações ainda foram preservadas.

3ª Forma Normal

Agora podemos ver que a estrutura já está bem melhor do que no início, mas ainda falta coisa a se fazer:
Para você ter uma tabela na 3ª FN você antes de mais nada tem que estar na 2ª forma normal. Além disto não pode ter campos que possam ser formado a partir dos demais cmapos já existentes (ou seja, campos calculados)pois a regra é de que campos calculados não sejam armazenados, pois se você alterar um campo estará comprometendo a integridade do 2o. Para tanto o campo Média deve ser excluído e a tabela de alunos deve então ficar da seguinte forma:

3ª Forma Normal Boiyce Code (BCNF)

Existe uma proposta de uma extensão da 3ªFN que é chamada de BCNF. Como se trata de uma extensão, para estar em BCNF precisa estar na 3ªFN (o oposto não é verdadeiro).
Imagine a situação que você tem a seguinte tabela (fora as que já usamos):

O primeiro campo é o código do aluno, o segundo é a versão da carteirinha (uma vez que o aluno pode gerar mais de uma carteirinha quando perde a anterior) e o terceiro campo é o código de acesso da catraca.

Se reparar os campos CodAluno e Acesso poderiam facilmente serem juntos a chave primária. Porém existe uma regra de negócio que, nunca terá duas versões de carteirinha para o mesmo aluno, pois ele sempre considera a última carteirinha como válida. Então temos uma situação de que um dos campos (versão da carteirinha) é dependente do código do aluno (uma das chaves) mas não de AcessoCatraca.

Sempre que um campo depende de uma das chaves mas não das demais ele falha na 3a FN BCNF. Para resolver esse problema podemos passar para a BCNF da seguinte maneira:

Reparem que o campo de versão da carteirinha passou para a tabela de aluno. Caso existissem outras informações sobre a carteirinha como data de expeidição, ela poderia então até ocupar uma tabela própria.

Conclusão:

Futuramente ainda falarei de outras FN, mas estas são as principais.
Como puderam ver quanto mais normalizado estiver seu database:
*menor será a chance dele ser comprometido por uma informação incorreta
*Mais otimizado para consultas e alterações ele será (ao menos até a 3ª FN esta afirmação é verdadeira)
*Além de economizar HD (ao menos até a 3ª FN esta afirmação é verdadeira).

A partir da 4ª FN começa a depender de quão otimizado é sua engine de banco de dados, e o ganho em Integridade Vs Trabalho começa a decair exponencialmente mas pretendo abordar futuramente todas as demais formas normais já identificadas.

1 Bla bla bla sobre “Normalização em Banco de Dados”

1. Teusma — quinta-feira, novembro 12, 2009 @ 9:37
   

   Cara, então eu não sou o único a achar os livros de DB chatos? IUPIIIIIII heueheuheue Sério, são muito chatos mesmo. Parabéns pelo artigo, tem uma abordagem excelente sobre o que deve e não fazer em um DB.

Dê o seu pitaco aqui

Nome

E-mail (não será publicado)

Siteb