O objetivo da normalização é evitar os problemas provocados por falhas no projeto do Banco de Dados, bem como eliminar a “mistura” de assuntos e as correspondentes redundâncias de dados. A normalização de tabelas é utilizadas para tentar detectar erros no projeto das tabelas e atributos de cada tabela e corrigir estes erros, antes da criação e utilização do banco de dados. É bem mais fácil (e barato), corrigir os erros na fase de projeto do que depois, que o banco de dados já está em uso.
Uma “Regra de Ouro” que devemos observar quando do projeto de Banco de Dados é a de “não misturar assuntos em uma mesma Tabela”, conforme já descrito anteriormente.
Por exemplo, na tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa “mistura de assuntos” em uma mesma tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência dos dados.
O processo de Normalização aplica uma série de regras sobre as tabelas de um Banco de Dados, para verificar se estas estão corretamente projetadas. Embora existam cinco Formas Normais (ou regras de Normalização), na prática usamos um conjunto de três Formas Normais.
Frequentemente, após a aplicação das regras de Normalização, algumas tabelas acabam sendo divididas em duas ou mais, o que no final gera um número maior de tabelas do que o número de tabelas originalmente projetado. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do projeto do banco de dados, reduzindo-se as necessidades de manutenção e alterações, após o banco ter sido colocado em produção.
Vamos estudar e entender o processo de Normalização através de exemplos práticos.
Primeira Forma Normal
Regra: “Uma tabela está na Primeira Forma Normal quando seus atributos não contêm Grupos de Repetição.”
Por isso dissemos que uma Tabela que possui Grupos de Repetição não está na Primeira Forma Normal. Considere a Figura 1.8:
Figura 1.8 Uma tabela que não está na Primeira Forma Normal.
Podemos notar que uma tabela com esta estrutura apresenta diversos problemas. Por exemplo, se um casal tiver mais do que um filho, teríamos que digitar o Nome do Pai e da Mãe diversas vezes, tantas quantos forem os filhos. Isso forma um Grupo de Repetição. Pode ser que, por erro de digitação, o nome dos pais não apareça exatamente igual todas as vezes, o que pode acarretar problemas na hora de fazer pesquisas ou emitir relatórios. Este problema ocorre porque misturamos assuntos em uma mesma tabela. Colocamos as informações dos Pais e dos Filhos em uma mesma tabela.
A solução para este problema é simples: criamos uma tabela separada para a Informação dos Pais e relacionamos a tabela Pais com a tabela Filhos através de um relacionamento do tipo Um para Vários, ou seja, Um casal pode ter Vários filhos. Esta solução é indicada na Figura 1.9.
Figura 1.9 As tabelas Pais e Filhos estão na Primeira Forma Normal.
As duas tabelas resultantes da aplicação da Primeira Forma Normal, Pais e Filhos, estão na Primeira Forma Normal; a tabela original, a qual misturava informações de Pais e Filhos, não está na Primeira Forma Normal.
|
Promoção: Livro Windows Server 2008 R2
Curso Completo, 1222 páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!
|
Segunda Forma Normal
Podemos aplicar a Segunda Forma Normal quando tivermos uma Chave Primária Composta. Neste caso, devemos observar se todos os campos, que não fazem parte da Chave primária composta, dependem de todos os campos que compõem a Chave Primária composta. Se algum campo depender somente de parte da Chave Primária composta, então este campo deve pertencer a outra tabela.
Observe o exemplo indicado na Figura 1.10:
Figura 1.10 Uma tabela que não está na Segunda Forma Normal.
A Chave Primária Composta é formada pela combinação dos campos NúmeroDaMatrícula e CódigoDoCurso. O campo Avaliação depende tanto do CódigoDoCurso quanto do NúmeroDaMatrícula (cada aluno – representado por sua matrícula, tem uma nota em cada disciplina – representada pelo campo CódigoDocurso), porém o campo DescriçãoDoCurso, depende apenas do CódigoDoCurso (a descrição do curso não tem relação com o NúmeroDaMatrícula). Com isso, temos um campo que não faz parte da Chave Primária composta e depende apenas de um dos campos que compõem a Chave Primária composta. Assim podemos dizer que esta tabela não está na Segunda Forma Normal.
A resolução para este problema também é simples: dividimos a tabela, que não está na Segunda Forma Normal, em duas outras tabelas, conforme indicado pela Figura 1.11, sendo que as duas tabelas resultantes estarão na Segunda Forma Normal.
Figura 1.11 Duas tabelas que estão na Segunda Forma Normal.
A distinção entre a Segunda e a Terceira Forma Normal, que veremos no próximo item, muitas vezes é confusa. A Segunda Forma Normal está ligada à ocorrência de Chaves Primárias Compostas.
Terceira Forma Normal
Na definição dos campos de uma tabela podem ocorrer casos em que um campo não seja dependente diretamente da Chave Primária, ou de parte dela, mas sim dependente de um outro atributo constante na tabela, atributo este que não seja a Chave Primária.
Quando isto ocorre, dizemos que a tabela não está na Terceira Forma Normal, conforme indicado pela Figura 1.12:
Figura 1.12 Uma tabela que não está na Terceira Forma Normal.
Observe que o campo DescriçãoDoCurso depende apenas do campo CódigoDoCurso, o qual não faz parte da Chave Primária. Por isso dizemos que esta tabela não está na Terceira Forma Normal.
A solução para este caso também é simples. Novamente basta dividir a tabela em duas outras, conforme indicado pela Figura 1.13. As duas tabelas resultantes estão na Terceira Forma Normal.
Figura 1.13 Duas tabelas que estão na Terceira Forma Normal.
Com isso podemos concluir que, como resultado do processo de Normalização, iremos obter um número maior de tabelas do que o existente antes do processo de normalização, porém sem problemas de redundância e inconsistência dos dados, ou com estes problemas minimizados. |
