Normalização é um processo aplicado a tabelas de banco de dados para evitar redundâncias e inconsistências. Ele envolve seguir regras para colocar as tabelas na Primeira, Segunda e Terceira Forma Normal. Isso garantirá um banco de dados mais íntegro sem dados duplicados ou derivados. O documento explica essas formas normais e dá exemplos de como normalizar tabelas.
BD I - Aula 06 B - Parte 2 - Teorico Formas Normais
Normalização de Dados: Formas Normais e Exemplos
1. Trabalho Normalização de Dados
Normalização é um processo a partir do qual se aplicam regras a todas as
tabelas do banco de dados com o objetivo de evitar falhas no projeto, como
redundância de dados e mistura de diferentes assuntos numa mesma tabela.
Ao projetar um banco de dados, se temos um modelo de entidades e
relacionamentos e a partir dele construirmos o modelo relacional seguindo as regras
de transformação corretamente, o modelo relacional resultante estará, provavelmente,
normalizado. Mas, nem sempre os modelos que nos deparamos são implementados
dessa forma e, quando isso acontece, o suporte ao banco de dados é dificultado.
Em ambos os casos, é necessário aplicar as técnicas de normalização, ou para
normalizar (segundo caso citado), ou apenas para validar o esquema criado (primeiro
caso citado). Aplicando as regras descritas a seguir, é possível garantir um banco de
dados mais íntegro, sem redundâncias e inconsistências.
CONCEITOS BÁSICOS
1. Dependência Funcional Completa
Quando um atributo não identificador depende do(s) atributo(s)
identificador(es).
2. Dependência Funcional Parcial
Quando um atributo não identificador depende de parte dos atributos
identificadores.
3. Dependência Funcional Transitiva
Quando um atributo não identificador depende de outro atributo também não
identificador. A normalização permite eliminar atributos:
• Com mais de um valor
• Duplicados ou repetidos
• Que contém dados derivados de outros atributos
PRIMEIRA FORMA NORMAL
• Todos os atributos de uma tabela devem ser atômicos, ou seja, a tabela não deve
conter grupos repetidos e nem atributos com mais de um valor. Para deixar nesta
forma normal, é preciso identificar a chave primária da tabela, identificar a(s) coluna(s)
que contenha(m) dados repetidos e removê-la(s), criar uma nova tabela com a chave
primária para armazenar o dado repetido e, por fim, criar uma relação entre a tabela
principal e a tabela secundária. Por exemplo, considere a tabela Pessoas a seguir.
2. PESSOAS = {ID+ NOME + ENDERECO + TELEFONES}
Ela contém a chave primária ID e o atributo TELEFONES é um atributo multivalorado
e, portanto, a tabela não está na 1FN. Para deixá-la na 1FN, vamos criar uma nova
tabela chamada TELEFONES que conterá PESSOA_ID como chave estrangeira de
PESSOAS e TELEFONE como o valor multivalorado que será armazenado.
PESSOAS = { ID + NOME + ENDERECO }
TELEFONES = { PESSOA_ID + TELEFONE }.
SEGUNDA FORMA NORMAL
• Inicialmente, para estar na 2FN é preciso estar na 1FN. Além disso, todos os
atributos não chaves da tabela devem depender unicamente da chave primária (não
podendo depender apenas de parte dela). Para deixar na segunda forma normal, é
preciso identificar as colunas que não são funcionalmente dependentes da chave
primária da tabela e, em seguida, remover essa coluna da tabela principal e criar uma
nova tabela com esses dados. Por exemplo, considere a tabela ALUNOS_CURSOS a
seguir.
ALUNOS_CURSOS = { ID_ALUNO + ID_CURSO + NOTA + DESCRICAO_CURSO }
Nessa tabela, o atributo DESCRICAO_CURSO depende apenas da chave primária
ID_CURSO. Dessa forma, a tabela não está na 2FN. Para tanto, cria-se uma nova
tabela chamada CURSOS que tem como chave primária ID_CURSO e atributo
DESCRICAO retirando, assim, o atributo DESCRICAO_CURSO da tabela
ALUNOS_CURSOS.
ALUNOS_CURSOS = {ID_ALUNO + ID_CURSO + NOTA}
CURSOS = {ID_CURSO + DESCRICAO}.
TERCEIRA FORMA NORMAL
• Para estar na 3FN, é preciso estar na 2FN. Além disso, os atributos não chave de
uma tabela devem ser mutuamente independentes e dependentes unicamente e
exclusivamente da chave primária (um atributo B é funcionalmente dependente de A
se, e somente se, para cada valor de A só existe um valor de B). Para atingir essa
forma normal, é preciso identificar as colunas que são funcionalmente dependentes
das outras colunas não chave e extraí-las para outra tabela. Considere, como
exemplo, a tabela FUNCIONARIOS a seguir.
FUNCIONARIOS = { ID + NOME + ID_CARGO + DESCRICAO_CARGO }
O atributo DESCRICAO_CARGO depende exclusivamente de ID_CARGO (atributo
não chave) e, portanto, deve-se criar uma nova tabela com esses atributos. Dessa
forma, ficamos com as seguintes tabelas:
FUNCIONARIOS = { ID + NOME + ID_CARGO }
CARGOS = { ID_CARGO + DESCRICAO }.
Abaixo serão mostrados alguns exemplos de normalização.
• Um modelo de ER normalizado é convertido facilmente para um Banco de
Dados relacional em tempo de projeto.
3. • A terceira forma normal geralmente é aceita como boa para projeto de Banco
de Dados sem redundância.
• Existem formas normais de nível maior, mas que geralmente não são usadas.
Verificação da Primeira Forma Normal.
• Verificar se cada atributo tem um único valor para cada instância da entidade.
• Nenhum atributo pode ter valores repetidos.
Exemplo 1:
Verificar se a entidade Cliente abaixo está na 1FN.
Se não estiver, convertê-la para a 1FN.
4. O Atributo data de contato pode ter múltiplos valores, portanto a entidade
CLIENTE não está na 1FN.
Para transformá-la para a 1FN vamos criar uma entidade adicional CONTATO
e relacioná-la com um relacionamento 1:M no sentido CLIENTE - CONTATO.
Verificação da Segunda Forma Normal
• Verificar se cada atributo é dependente apenas do identificador da entidade.
• Verificar se existe algum atributo dependente apenas de parte do identificador
da entidade.
Exemplo 2:
Verificar se entidade CURSO está normalizada.
Cada código determina um valor específico para nome, duração e preço, todos
eles são dependentes exclusivamente do identificador, e nenhum dos atributos
é derivado um do outro. Portanto a entidade está normalizada.
Exemplo 3:
Verificar se as entidades abaixo estão normalizadas.
5. Cada instância de CLIENTE e PEDIDO determina valores específicos de
quantidade e preço do item. O atributo data do pedido está perdido na entidade
CLIENTE, porque ele não é dependente do identificador da entidade. Ele deve
ser um atributo de PEDIDO.
Exemplo 4:
Normalizar a entidade abaixo:
Como a entidade não tem nenhum atributo com valores repetidos ela está na
1FN. Entretanto os atributos data do pedido, número do pedido, quantidade
pedida e valor unitário não são dependentes do identificador da entidade,
portanto ela não está na 2FN.
Para normalizá-la devemos criar uma entidade auxiliar com os atributos não
dependentes do identificador.
Verificação da Terceira Forma Normal
6. • Verificar se existe algum atributo não identificador dependente de outro
atributo não identificador.
• Retirar os atributos não identificadores dependentes para uma entidade
auxiliar.
Exemplo 5:
Verificar se a entidade abaixo está na terceira forma normal.
Não existe nenhum atributo com valores repetidos logo a entidade está na 1FN.
Os atributos número do cliente, nome do cliente e limite de crédito não são
dependentes do identificador da entidade, portanto ela não está na 2FN. Logo
a entidade não está na 3FN.
Para passá-la para a 2FN devemos criar uma entidade auxiliar com os atributos
não dependentes do identificador.
Exemplo 6:
Verificar se a entidade abaixo está na 3FN.
7. Não existe nenhum atributo com valores repetidos, logo a entidade está na
1FN. Todos os atributos não identificadores são dependentes do identificador
da entidade, logo ela está na 2FN. O atributo total do item é dependente da
quantidade pedida e do valor unitário, portanto a entidade não está na 3FN.
Para passá-la para a 3FN basta eliminar o atributo total do item que é
desnecessário na entidade.
Bibliografia.
Curso: Ciências da Computação – UCG
Rumbaugh, James e outros.
Modelagem e Projetos Baseados em Objetos.
Rio de Janeiro: Campus, 1988.
Pompilho, S. Análise Essencial. Rio de Janeiro: Infobook, 1995.
http://www.dsc.ufcg.edu.br/~pet/jornal/maio2011/materias/recapitulando.html
Korth, Henry e Silberschatz, Abraham – (Livro Texto Básico)
“Sistemas de Bancos de Dados”, Makron Books do Brasil Editora Ltda, RJ, 1994, 2ª
Edição.