NORMALIZAÇÃO

 

A normalização tem seus conceitos fundamentados na teoria de conjuntos da matemática, assim como a dependência funcional.

 

Embora existam cinco formas normais no total, na prática só são utilizadas três.

 

Normalização é uma técnica de análise de dados e tabelas, que, passo a passo (formas normais), analisa e substitui um conjunto de atributos de uma entidade por outros. Nesse processo nenhum atributo deve ser perdido.

 

Normalizar uma tabela (relação) é decompô-la, com a finalidade de eliminar redundâncias e inconsistências, deixando-a sem as anomalias de atualização (inclusão, alteração e exclusão), como por exemplo:

 
  • Quando se eliminar um dado não excluí-lo de todo o banco de dados ou quando incluí-lo não ter que incluir no banco de dados inteiro;
    •  
  • Atributos multivalorados (repetidos);
    •  
  • Dependência parcial (um atributo que não é chave primária depende de parte dela) em relação à chave concatenada;
    •  
  • Perdas acidentais de informações;
    •  
  • Dependência transitiva (campo que não é chave primária e depende de outro que também não é) entre atributos etc.
    •  
  • Reduzir o espaço necessário para armazenar o banco de dados
    •  

    Mas por que normalizar?

     
     

    É importante normalizar para se obter uma estrutura mais simples para o modelo de dados, de modo que atualizações de dados sejam mais fáceis e econômicas. Além disso, a normalização serve também para eliminar as falhas, e principalmente a "mistura" de assuntos e repetições do projeto conceitual do banco de dados.

     

    A Normalização também permite ao projetista controlar o quanto de CONSISTÊNCIA SERÁ GARANTIDA pela maneira de construção do sistema (estrutura), e quanto deve ser de responsabilidade dos aplicativos e/ou do SGBD. Porém, se deve analisar até que ponto a Normalização deve chegar, pois Normalizar DEMAIS pode diminuir a eficiência dos aplicativos que utilizam a base de dados (BD). Por outro lado, Normalizar de MENOS facilita as possibilidades das inconsistências na BD.

     

    No projeto conceitual de um banco de dados não se pode "misturar" os assuntos em uma mesma tabela! Cada assunto deve ficar em sua própria tabela.

     

    Normalmente, após a aplicação das regras de normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que, no final, gera um número maior de tabelas do que havia inicialmente. Estas tabelas deverão conter os mesmos dados da tabela original.

     

    1ª Forma Normal

     

    Um modelo está na 1ª forma normal se possui apenas atributos atômicos (simples e indiviséveis). Desse forma, a primeira forma normal tem como objetivo eliminar atributos multivalorados e atributos compostos das tuplas na construção de uma tabela.

     

    Transformando para a 1ª FN:

     

    Para se normalizar uma relação para a 1ª FN as “regras” seguintes devem ser seguidas.

     
  • Cada um dos atributos compostos (ou não atômicos) devem ser “divididos” em seus componentes;
    •  
  • Para os atributos multivalorados tem-se duas alternativas:
    •  

    1- Pequena quantidade de valores possíveis, substitui-se o atributo multivalorado por um conjunto de atributos de mesmo domínio, cada um mono valorado representando uma ocorrência do valor;


    2- Quantidade de possíveis valores desconhecida, grande ou muito variada, retira-se da relação o atributo multivalorado e cria-se uma nova relação que tem o mesmo conjunto de atributos chave, mais o atributo multivalorado também como chave, mas tomado como mono valorado.

    Exemplo:

     

    Estrutura não normalizada:

     

    Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Cod. do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente, Relação das mercadorias vendidas (onde para cada mercadoria temos: Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria) e Total Geral da Nota)

     

    Analisando a estrutura acima, observamos que existem várias mercadorias em uma única Nota Fiscal, sendo portanto elementos repetitivos que deverão ser retirados.

     

    Como resultado desta etapa ocorre um desdobramento dos dados em duas estruturas:

     

    Arquivo de Notas Fiscais


    (Num. NF, Série, Data emissão, Código do Cliente, Nome Cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

     

    Arquivo de Vendas


    (Num. NF, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

     

    Obs. Os campos sublinhados identificam as chaves das estruturas.

     

    Entendendo melhor:

     
  • Primeira estrutura (Arquivo de Notas Fiscais): Dados que compõem a estrutura original, excluindo os elementos repetitivos.
    •  
  • Segundo estrutura (Arquivo de Vendas): Dados que compõem os elementos repetitivos da estrutura original, tendo como chave o campo chave da estrutura original (Num. NF) e o campo chave da estrutura de repetição (Código da Mercadoria).
    •  

    A 1 FN é uma das maneiras de controlar a consistência por meio da própria estrutura do sistema, sendo também fundamental para a conceituação do sistema. Com isso, tem-se a ideia de atomicidade, ou seja, que os atributos sejam atômicos, indivisíveis, sendo importante para evitar anomalias na parte de duplicação de dados. Logo, para evitar tal problema, é necessário avaliar a entidade trabalhada, identificando sua chave primária e os dados repetidos e removê-los, criando uma nova entidade com os dados removidos e criando um relacionamento entre a entidade normalizada e a nova entidade.

     

    Exemplo prático:

     
    Com intuito de apoiar o aprendizado em Banco de Dados, sugere-se assistir a videoaula para o aperfeiçoamento no conhecimento deste conteúdo.

    2ª Forma Normal

     

    Um modelo está na 2ª forma normal se:

     
  • Estiver na 1ª Forma Normal;
    •  
  • Cada uma das colunas não pertencentes à chave primária dependem totalmente da chave (e não de um subconjunto de chave).
    •  
  • Dependência funcional Total (completa - chaves concatenadas), Parcial e Transitiva.
    •  

    Transformando para a 2ª FN:

     

    Para se normalizar uma relação para a 2ª FN as “regras” seguintes devem ser seguidas.

     
  • Remoção das dependências parciais de parte da chave primária;
    •  
  • Identificar as colunas que não participam da chave primária da tabela.
    •  
  • Para cada coluna, analisar se seu valor é dependente em parte ou na totalidade da chave.
    •  
  • Para colunas dependentes parcialmente, criar novas tabelas e excluir as dependências parciais.
    •  
  • Decompôr a relação em duas ou mais relações.
    •  

    Continuando ainda com a estrutura do exemplo anterior, sua 2ª Forma Normal será:

     

    Arquivo de Notas Fiscais


    (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

     

    Arquivo de Vendas


    (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

     

    Arquivo de Mercadorias


    (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)

     

    Ou seja, como resultado desta etapa, houve um desdobramento do arquivo de Vendas em duas estruturas:

     
  • Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código da Mercadoria.
    •  
  • Segundo estrutura (Arquivo de Mercadorias): Contém os elementos que são identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrição e o preço de venda serão constantes.
    •  

    Logo, de forma resumida, o objetivo da aplicação da segunda forma normal é realizar as aplicações propostas na primeira forma normal e sempre atentar-se para que todos os atributos de determinada tabela dependam unicamente da chave primária. Caso contrário, o procedimento de separação desses atributos através da criação de uma nova tabela é necessária para que respeite a segunda forma normal. Esta normalização evita a inconsistência devido a duplicidade de informaçõoes, além da perda de dados em operaçães de remoção ou de alterações na relação (anomalias).

    OBS: Note que a normalização de relações é realizada, na grande maioria das vezes, decompondo-se uma relação em duas ou mais relações.

     

    Exemplo:

     
     
    Com intuito de apoiar o aprendizado em Banco de Dados, sugere-se assistir a videoaula para o aperfeiçoamento no conhecimento deste conteúdo.

    3ª Forma Normal

     

    Um modelo está na 3ª forma normal se:

     
  • Estiver na 2ª Forma Normal;
    •  
  • Qualquer atributo não chave não seja dependente funcional de outro atributo não chave.
    •  

    Transformando para a 3ª FN:

     

    Para se normalizar uma relação para a 3ª FN as "regras" seguintes devem ser seguidas.

     
  • Remoção das dependências transitivas;
    •  
  • Identificar as colunas que não participam da chave primária da tabela;
    •  
  • Para cada coluna, analisar se seu valor é dependente de alguma coluna que não seja chave.
    •  
  • Para colunas dependentes transitivamente, criar novas tabelas e excluir as dependências transitivas
    •  

    Ainda com o exemplo anterior, sua 3ª Forma normal ficará:

     

    Arquivo de Notas Fiscais


    (Num. NF, Série, Data emissão, Código do Cliente e Total Geral da Nota)

     

    Arquivo de Vendas


    (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

     

    Arquivo de Mercadorias


    (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)

     

    Arquivo de Clientes

    (Código do Cliente, Nome do cliente, Endereço do cliente e CGC do cliente)

     

    Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o único que possuía campos que não eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endereço e CGC do cliente são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos e economizar espaço por eliminar o armazenamento frequente destes dados. A cada nota fiscal comprada pelo cliente, haverá o armazenamento destes dados e poderá ocorrer divergência entre eles.

     

    As estruturas alteradas foram:

     
  • Primeira estrutura (Arquivo de Notas Fiscais): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código do Cliente (informações referentes ao cliente).
    •  
  • Segunda estrutura (Arquivo de Clientes): Contém os elementos que são identificados apenas pelo Código do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereço e CGC dos clientes serão constantes.
    •  

    A partir desses exemplos, em suma, a terceira forma normal engloba todo o procedimento da primeira e da segunda, acrescentando o detalhe de não haver uma dependência entre os atributos, tendo uma mútua independência deles a fim de que sejam dependentes unicamente e exclusivamente da chave primária. Para isso, o foco é essencialmente identificar as colunas que são funcionalmente dependentes de outras que não sejam a chave, extraindo-as para outra tabela.

     
    Com intuito de apoiar o aprendizado em Banco de Dados, sugere-se assistir a videoaula para o aperfeiçoamento no conhecimento deste conteúdo.

    Atividade de Fixação

     

    No intuito de fixar a aprendizagem iniciada por meio deste módulo e verificar como está sua compreensão sobre o mesmo, são sugeridos alguns exercícios de fixação para serem resolvidos. Clique no link de exercícios ao lado, pois será por meio dele iniciada a lista de exercícios sobre os conteúdos estudados até este momento. Boa revisão sobre os mesmos!!