Normalização: eliminando redundâncias em modelo de banco de dados relacional

Quer projetar bancos de dados relacionais, reduzindo anomalias, redundâncias e que mantenham sua integridade apesar do crescimento das operações? Então, leia este artigo até o fim que vamos apresentar como fazer isso.

Normalização, uma das etapas do projeto de um banco de dados relacional, é a chave para a criação de tabelas e das relações entre elas sem redundâncias e dependências inconsistentes. E é sobre normalização o assunto que trataremos neste texto.

O que você vai aprender

Inicialmente, será tratado o conceito de dependência funcional, chave para o entendimento de normalização, abordado na sequência. Após isso, será apresentado o conceito de formas normais. Na sequência serão explicados os passos necessários a fim de que as formas normais sejam entendidas, utilizando exemplos práticos. 

Dependência funcional

Dependência funcional (DF) é um relacionamento entre dois atributos, normalmente entre a chave primária (PK) e outros atributos não-chave dentro de uma tabela. Para qualquer relação R, o atributo Y é funcionalmente dependente do atributo X (geralmente a PK), se para cada instância válida de X, esse valor de X determina exclusivamente o valor de Y. Por exemplo, na tabela Empregados:

O ID 1 determina unicamente o empregado João da Silva, e o ID 2 determina unicamente Maria Sousa. Ou seja, o atributo Nome é funcionalmente dependente de ID. Nas próximas seções veremos como esse conceito é pertinente para entendermos normalização.

O que é normalização

Nos anos 70, Edgar Frank Codd apresentou os conceitos do modelo relacional, uma maneira de representar os dados. Complementar ao modelo, ele propôs as bases para tratar problemas de redundância e de consistência - a normalização.

Podemos dizer que normalização é o processo de determinar quanta redundância existe numa relação ou tabela. Assim, as metas da normalização são:

• Ser capaz de caracterizar o nível de redundância em um esquema relacional
• Prover mecanismos para transformar os esquemas de modo a remover redundâncias

A teoria da normalização se baseia fortemente nas dependências funcionais, e prevê seis formas normais (FN).

Formas Normais

Formais normais são as etapas do processo de normalização, que vão garantir um banco de dados bem estruturado. Como vimos, estão previstas seis FN, onde cada uma delas descreve propriedades que a relação deve satisfazer de modo a assegurar a ausência de anomalias.

A despeito dessas seis FN, a literatura e a própria prática leva em conta apenas as três primeiras para considerar que um esquema está devidamente normalizado. São elas:

• Primeira Forma Normal
• Segunda Forma Normal
• Terceira Forma Normal

Vamos ver o processo na prática, a partir de um esquema não normalizado.

Primeira Forma Normal (1FN)

A Primeira Forma Normal objetiva eliminar atributos que sejam compostos e atributos multivalorados.

Os atributos compostos são aqueles que podem ser subdivididos em vários outros atributos, tais como Endereço nesta relação:

A fim de resolver esse problema criam-se tantos atributos quantos forem necessários. Neste caso vamos criar Endereço, Cidade e Estado em substituição ao atributo único Endereço, resultando nesta tabela:

Por sua vez, os atributos multivalorados são aqueles que podem ter mais de um valor para uma mesma linha, ou registro, tais como o atributo Telefone na tabela:

Atributos multivalorados devem ser removidos para formar uma nova relação onde os campos são a chave primária da relação original e o atributo que tem múltiplos valores, mais um atributo que será a chave primária da tabela:

Note que cada número de telefone foi inserido em uma linha, juntamente com o Codigo Ciente correspondente. O atributo ID foi definido como chave primária desta nova relação. E o campo Telefone foi removido da tabela original:

Desse modo, nossa relação está na Primeira Forma Normal.

Segunda Forma Normal (2FN)

Uma tabela está na Segunda Forma Normal se ela está na 1FN e todos os seus atributos não chave são dependentes totalmente da chave primária, e não apenas de parte dela - denominada dependência parcial. Os passos para essa normalização são:

• Verificar se a relação possui chave primária composta (constituída de mais de um atributo)
• Identificar os atributos com dependência parcial
• Remover esses atributos para formar uma nova relação
• A chave primária da nova tabela é o atributo do qual os atributos removidos são dependentes

Vamos analisar a seguinte relação:

Aqui notamos a ocorrência de chave composta (Nota Fiscal e Codigo Produto) e dependência parcial em Nome Produto, o qual depende apenas de Codigo Produto. Seguindo, portanto, os passos descritos, vamos remover a atributo Nome Produto da tabela original e criar uma nova relação. Assim, ficaremos com uma nova versão da tabela original e a nova tabela, mostradas a seguir, respectivamente:

Agora, nossa relação está na Segunda Forma Normal.

Terceira Forma Normal (3FN)

Uma tabela está na 3FN se ela está na 2FN e não possua atributo não chave dependendo de outro atributo não chave - chamada dependência transitiva. Os passos para essa normalização são:

• Identificar os atributos com dependência transitiva
• Remover esses atributos para formar uma nova tabela. Se forem campos calculados basta retirá-los da relação
• A chave primária da nova tabela será a coluna da qual os atributos dependem

Analisando a seguinte tabela:

Notamos que Salário depende de Categoria, e não da chave Codigo Empregado. Dessa maneira, seguindo os passos, vamos remover da tabela original o atributo Salário, o qual possui dependência transitiva e formar uma nova tabela, resultando nas seguintes relações:

Pronto, nossa relação está normalizada.

Considerações Finais

Durante o processo de normalização sempre verifique se as novas tabelas criadas atendem às formas normais, a fim de evitar que as modificações adicionem novas anomalias ao banco de dados.

Por outro lado, o processo de normalização deve ser conciliado com o desempenho das consultas. Por vezes um projeto perfeitamente estruturado apresenta desempenho ruim e algumas dessas regras precisa ser quebrada. Só a prática e a experiência vai aprimorar sua sensibilidade para analisar esses casos.

Referências

Booth, J.D. (2022). Database Design Succinctly. Syncfusion. Acesso: https://www.dbooks.org/database-design-succinctly-1642002232/.

Watt, A. and N. Eng. (2014). Database Design – 2nd Edition. Victoria, B.C.: BCcampus. Acesso: https://opentextbc.ca/dbdesign01/.