Normalização

Ao modelar um banco de dados no modelo conceitual, podem ser identificadas inúmeras entidades com inúmeros atributos, que compõem o domínio da aplicação. Diante deste cenário, é inevitável o surgimento de diversas dúvidas, como, quantas entidades, de fato, irão compor o meu modelo? Quais são os atributos que devem ser considerados? Quais relacionamentos realmente existem? Com qual cardinalidade? Para responder a estas e outras dúvidas que podem surgir, garantindo que não haverá duplicidade de informações e não terá entidades, atributos e relacionamentos perdidos, é aplicado um processo bem definido, denominado Normalização.

A normalização nos ajuda tanto no refinamento de novos projetos, como também, no refinamento de entidades, atributos, relacionamento e cardinalidade de sistemas legados, permitindo ser aplicado em processos de engenharia reversa (HEUSER, 2009).

O processo de normalização consiste em uma técnica geralmente utilizada como guia no projeto de dados relacionais. Proposto por Codd, por volta de 1970, inicialmente com apenas 3 formas normais, que posteriormente, foi estendida por outras formas normais (SILBERCHATZ, 2012).

Como definição de normalização, podemos dizer que é o processo que permite a simplificação da estrutura de um banco de dados de modo que esta se apresente em um estado ótimo, sem duplicações de informações (DAMAS, 2007).

A teoria da normalização é baseada no conceito de Formas Normais. Uma forma normal é uma regra que deve ser obedecida por uma tabela para que seja considerada bem projetada(HEUSER, 2009). As formas normais são denominadas primeira, segunda, terceira e quarta forma normal, tendo como abreviações 1FN, 2FN, 3FN, Forma normal de Boyce/Cood, 4FN e 5 FN.

Neste texto apresentarei as Formas Normais, porém, vale a pena ressaltar que para a maioria dos casos basta normalizar até a 3 FN para obter um esquema considerado como normalizado.

Passagem à Primeira Forma Normal

 

Diz-se que uma tabela está na primeira forma normal, quando ela não contém tabelas aninhadas. Portanto, a passagem à 1FN consta na eliminação das tabelas aninhadas, eventualmente existentes.

Para transformar um esquema de tabelas não normalizadas para a 1FN há duas alternativas:

·         Construir uma única tabela com redundância de dados;

·         Construir uma tabela para cada tabela aninhada.

Considere o esquema conceitual apresentado a seguir:

PROJ(codProj, Tipo, Descr, (codEmp, nome, categoria, salario, datainicial, tempoal))

No esquema apresentado, é possível notar que há duas tabelas aninhadas, a primeira que consta os dados do projeto e a segunda que consta os dados do empregado. Para passarmos este esquema para a 1FN, vamos separar em duas tabelas, ficando na tabela PROJ apenas os dados do projeto, e levando para a tabela PROJEMP os dados do empregado no projeto, conforme o esquema conceitual a seguir:

PROJ(codProj, Tipo, Descr)

PROJEMP(codProj, codEmp, nome, categoria, salario, datainicial, tempoal)

Nesta passagem, podem ser perdidas relações entre informações, entretanto, para fins práticos, vamos considerar a decomposição de tabelas.

Passagem à Segunda Forma Normal

 

Para compreendermos a passagem a segundo forma normal, vamos entender primeiro o conceito de dependência funcional.

Em uma tabela relacional, diz-se que uma coluna C₂ depende funcionalmente de uma coluna C₁ (ou que a coluna C₁ determina a coluna C₂) quando, em todas linhas da tabela, para cada valor de C₁ que aparece na tabela, aparece o mesmo valor de C₂. Para exemplificar, temos a Tabela 1, que no qual, exibe o mesmo salário para cada código, ou seja, o Código E1 sempre exibe o salário 10. A notação de dependência funcional é representa por C₁à C₂, no exemplo, Código à Salário, que podemos dizer que o atributo Código determina o atributo salário ou que o atributo salário depende funcionalmente do atributo Código.

Tabela 1 - Exemplo de Dependência Funcional

Uma tabela encontra-se na 2FN quando, além de estar na 1FN, não contém dependências (funcionais) parciais.

Um dependência (funcional) parcial ocorre quando uma coluna depende apenas de uma parte de uma chave primária composta. Entendemos como chave primária compostas, as chaves primárias que são formadas por mais um atributo.

As tabelas que já estão na 1FN e possuem apenas uma coluna como chave primária, não contém dependências parciais, o que resulta na afirmação de que ela já está na 2FN. No exemplo apresentado abaixo, a tabela PROJ já está na 2FN por não contém chave primária composta, mas a tabela PROJEMP está apenas na 1FN, pois possui dependência parcial. Identificamos as dependências parciais nos atributos nome, categoria e salário, que são determinados apenas pela chave primária codEmp, o que estabelece uma dependência parcial. Os atributos datainicial e tempoal são determinados pelo chave primária composta por codProj e codEmp.

1FN

PROJ(codProj, Tipo, Descr)

PROJEMP(codProj, codEmp, nome, categoria, salario, datainicial, tempoal)

Para a passagem para a 2FN, copiamos a tabela PROJ, pois ela já está na 2FN e na tabela PROJEMP devemos eliminar as dependências parciais, fazemos isso dividindo a tabela PROJEMP em duas tabelas, como:

2FN

 PROJ(codProj, Tipo, Descr)

EMP (codEmp, nome, categoria, salario)

PROJEMP(codProj, codEmp, datainicial, tempoal)

O exemplo citado é possível observar que a tabela PROJEMP mantém sua chave primária composta.

Passagem a 3 Forma Normal

 

Uma tabela está na 3FN quando, além de estar na 2FN, não contém dependências transitivas. Uma dependência (funcional) transitiva ocorre quando uma coluna, além de depender da chave primária, depende de outra coluna ou conjunto de colunas da tabela.

Para exemplificar, vamos considerar a tabela EMP, exposta no exemplo acima. Neste exemplo, vamos supor que o salário (coluna salário) do funcionário seja determinado pela categoria funcional (coluna categoria). Neste caso, a representação de salário, que é determinada pela categoria, está representado redundantemente na tabela, pois para todos os funcionários pertencentes a mesma categoria será repetido o valor do salário. Então, podemos identificar neste exemplo uma dependência transitiva, no qual, o atributo salario é determinado pelo atributo chave primária codEmp e pelo atributo não chave categoria.

Para eliminar essa dependência transitiva realizamos a passagem a 3FN que consiste na divisão da tabela EMP de forma a eliminar a dependência transitiva.

3FN

PROJ(codProj, Tipo, Descr)

CAT (categoria, salario)

EMP (codEmp, nome, categoria)

PROJEMP(codProj, codEmp, datainicial, tempoal)

Forma Normal de Boyce/Codd

 

Para a maioria dos esquemas, a decomposição até a 3FN é suficiente para obter o esquema de banco de dados normalizado ou, no caso da engenharia reversa, correspondente ao documento. Entretanto, na literatura são citados ainda a Forma Normal de Coyce/Codd, a 4FN e a 5FN.

A forma normal de Boyce/Codd (FNBC) refere-se a um refinamento da 3 FN, este nome foi proposto pelo fato de que já haviam a 1FN, 2FN, 3FN, 4FN E 5FN, logo, fazer a 6FN como algo parecido com a 3FN não fazia sentido (DAMAS, 2007).

Enquanto a 3FN lida com dependências entre atributos chaves e não chave, a FNBC lida com dependências entre chaves.

As situações específicas que a FNBC lida são:

·         Existem múltiplas chaves candidatas;

·         As chaves candidatas são compostas;

·         As chaves candidatas se sobrepõem.

Caso algumas das situações acima não se verificar, então a FNBC se reduz à 3FN.

Como exemplo, podemos citar as seguintes dependências funcionais:

Encarregadoà Cidade, Departamento.

                Cada empregado trabalha em uma única cidade e gerencia um único departamento.

Cidade, Departamento à Encarregado.

                Só existe um encarregado para cada Cidade e Departamento.

Encarregado, Projeto, Cidade à Departamento.

                Podem existir vários encarregados para um mesmo projeto, mas tem de existir em cidades distintas;

                Cada encarregado pode ser responsável por mais de um projeto.

                Em cada cidade um projeto está associado a um único departamento e só tem um encarregado responsável por ele.

Para resolver esta situação pode-se separar  em duas tabelas, contendo:

Encarregado à cidade, projeto

Projeto à cidade, departamento.

Para que a FNBC seja aplicável é necessário que existam pelo menos duas chaves candidatas com atributos comuns que se sobrepõem.

Passagem a 4 Forma Normal

 

Até a FNBC são tratadas no processo de normalização as dependências funcionais. Entretanto, para a verificação de consistência, é necessário basear-se também em uma variação da dependência funcional, denominada dependência multivalorada.

Uma dependência multivalorada, embora um conjunto de atributos não possa determinar outro conjunto de atributos, ainda assim consegue restringir os valores possíveis para o respectivo conjunto.

Como definição temos: Dada uma relação R, se um conjunto de atributos A pertencentes a R, restringe os valores possíveis para os atributos de outro conjunto B também pertencentes a R, diz-se então que A Multidetermina B ou que B é Multidependente de A, e é representando pela notação A àà B.

Como exemplo, podemos ver na Figura 1, o CodProj determina o conjunto de dados de CodEmpr. 

Figura 1- Exemplo de Dependência Multivalorada

Dizemos que uma tabela está na 4FN quando, além de estar na 3FN e/ou FNBC, não contém mais de uma dependência multivalorada.

A passagem para a 4 FN, assim como as anteriores, também consiste na decomposição da tabela em tabelas menores. Para exemplificar, vamos considerar a seguinte tabela:

MATRICULA(codProj, Aluno, Sala)

Neste exemplo, podem ocorrer redundâncias se, um grupo de alunos alocados a um projeto poder ocupar duas ou mais salas, como pode ser visto na Tabela 2.

Tabela 2- Exemplo - Tabela Matrícula

Projeto	Aluno	Sala
1	A	S1
P1	B	S1
P1	C	S1
1	A	S2
P1	B	S2
P1	C	S2

É notório, neste exemplo, as redundâncias ocorridas, pois os alunos aparecem tantas vezes quanto as salas alocadas, e o mesmo ocorre com salas, que aparecem tantas vezes quanto a alunos alocados. Sendo assim, para passar esta tabela para a 4FN, decompomos a tabela em duas tabelas menores, ficando:

4FN

MATRICULAPROJALU(codProj, Aluno)

MATRICULAPROJSALA(codProj, Sala) 

Passagem a 5 Forma Normal

 

Uma tabela está na 5FN quando, além de estar na 4FN, o seu conteúdo puder ser reconstruído a partir de entidades menores.

A 5FN ou Forma normal de Projeção-Junção baseia-se no conceito de dependência de junção.

Dependência de junção expressa a capacidade de um tabela, que tenha sido decomposta em duas ou mais tabelas menores, de se reconstruir novamente a partir das novas tabelas, obtendo-se a tabela original. Logo, uma tabela está na 5FN quando não é mais possível decompô-la.

Há um consenso que são raras as exceções que necessitam da passagem para a 5FN, na maioria dos casos, quando uma tabela está na 4FN também estará na 5FN.

Referências

DAMAS, L. SQL, Strutucture Query Language. Rio de Janeiro. LTC, 2007.

HEUSER, C. Projeto de Banco de Dados. São Paulo. Bookman, 2009.

SILBERCHATZ, A. Sistemas de Banco de Dados. Rio de Janeiro. Elsevier, 2012.