Normalização de dados

A normalização de dados é uma série de passos que se segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes.

No entanto, muitas SGBDs relacionais não têm separação suficiente entre o projeto lógico da base de dados e a implementação física do banco de dados, e isso tem como conseqüência que as consultas feitas a um banco de dados totalmente normalizado têm um mau desempenho. Nestes casos, usa-se por vezes a desnormalização para melhorar o desempenho, com o custo de menores garantias de consistência.

Panorâmica informal

Diz-se que uma tabela num banco de dados relacional está numa certa forma normal se satisfaz certas condições. O trabalho original de Edgar F. Codd definiu três dessas formas, mas existem hoje outras formas normais geralmente aceitas. Damos aqui uma curta panorâmica informal das mais comuns. Cada forma normal listada abaixo representa uma condição mais forte que a que a precede na lista. Para a maioria dos efeitos práticos, considera-se que as bases de dados estão normalizadas se aderirem à terceira forma normal.

Primeira Forma Normal (ou 1FN) requer que todos os valores de colunas em uma tabela, sejam atômicos (ex., um número é um átomo, enquanto uma lista ou um conjunto não o são). Por exemplo, a normalização elimina grupos repetidos pondo-os cada um em uma tabela separada, conectando-os com uma chave primária ou estrangeira.

Segunda Forma Normal (ou 2FN) requer que não haja dependência funcional não-trivial de um atributo que não seja a chave, em parte da chave candidata.

Terceira Forma Normal (ou 3FN) requer não haver dependências funcionais não-triviais de atributos que não sejam chave, em qualquer coisa exceto um superconjunto de uma chave candidata.

Forma Normal de Boyce-Codd (ou BCNF) requer que não exista nenhuma dependência funcional não-trivial de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estágio, todos os atributos são dependentes de uma chave, de uma chave inteira e de nada mais que uma chave (excluindo dependências triviais, como A->A).

Quarta Forma Normal (ou 4NF) requer que não exista nenhuma dependência multi-valorada não-trivial de conjuntos de atributo em algo mais de que um superconjunto de uma chave candidata.

Quinta Forma Normal (ou 5NF ou PJ/NF) requer que não exista dependências de joins não triviais que não venham de restrições chave.

Domain-Key Normal Form (ou DK/NF) requer que todas as restrições sigam os domínios e restrições chave.

Visão Formal

Antes de falar sobre normalização, é necessário utilizar alguns termos a partir do modelo relacional e defini-los na teoria de conjuntos. Estas definições muitas vezes serão simplificações de seus significados originais, uma vez que somente alguns aspectos do modelo relacional são levados em consideração na normalização.

As Notações Básicas utilizadas no modelo relacional são nomes de relacionamentos e nomes de atributos. Representaremos estas cadeias de caracteres tais como Pessoas e Nomes e geralmente usaremos variáveis como r, s, t, ... e a, b, c para o conjunto dados definido sobre eles. Outra notação básica é o conjunto de valores atômicos que contém valores tais como números e cadeias de caracteres.

Nossa primeira definição que nos interessa é a noção de tupla a qual formaliza a noção de linha ou registro em uma tabela:

Def. Uma tupla é uma função parcial de nomes de atributos para valores atômicos.

Def. Um cabeçalho é um conjunto finito de nomes de atributos.

Def. A projeção de uma tupla t em um conjunto finito de atributos A é t[A] = { (a, v) : (a, v) ∈ t, a ∈ A }.

A próxima definição é a de relação na qual formaliza-se o teor de uma tabela como ele é definido no modelo relacional.

Def. Uma relação é uma tupla (H, B) sendo H, o cabeçalho, um cabeçalho e B, o corpo, um conjunto de tuplas em que possuem todas o domínio H.

Como uma relação corresponde definitivamente com aquela que é usualmente chamada de extensão de um predicado em lógica de primeira ordem exceto que aqui nós identificamos os locais no predicado com nomes de atributos. Geralmente no modelo relacional um esquema de banco de dados é dito consistir-se de um conjunto de nomes relação, os cabeçalhos que são associados com esses nomes e as restrições que devem manter toda instância do esquema de banco de dados. Para normalização nós nos concentraremos nas restrições que indicam relações individuais, isto é, as restrições relacionais. O propósito destas restrições é descrever o universo relacional, ou seja, o conjunto de todas as relações que são permitidas para serem associadas com certos nomes de relação.

Def. Um universo relacional U sobre um cabeçalho H é um conjunto não vazio de relações com o cabeçalho H.

Def. Um esquema relacional (H, C) consiste de um cabeçalho H e um predicado C(R) que é definido por todas as relações R com o cabeçalho H.

Def. Uma relação satisfaz o esquema relacional (H, C) se possuir o cabeçalho H e satisfizer C.

Restrições Chave e Dependências Funcionais

A restrição relacional mais importante é a restrição de Chave. Ela relaciona cada registro (tupla) a um (ou mais) valor índice.

Def. Uma Chave é um atributo que identifica um registro(tupla).

Exemplos

Tabela normalizada

Atributos não atômicos ou contém tabelas aninhadas

Exemplo: Tabela de alocação de funcionários a projetos

Código do Projeto: 1

Tipo: Desenvolvimento

Descrição: Vagas

CodEmp	Nome	Categ	Salário	DataInício	TempoAloc
1	João	1	700	1 de novembro de 1995	6
2	Carlos	2	1000	23 de novembro de 1995	9

Código do Projeto: 2

Tipo: Administrativo

Descrição: Marketing

CodEmp	Nome	Categ	Salário	DataInício	TempoAloc
2	Carlos	2	1000	23 de novembro de 1995	9
4	Maria	1	700	15 de novembro de 1995	12

A seguinte tabela descreveria os dados acima apresentados: Projetos(codp, tipo, descrição, empregados(code, nome, categ, salário,data_início, tempo_aloc)).

Tabela não normalizada empregados é um atributo não atômico.

Primeira Forma Normal

Definição (note que relacionamentos como são definidos acima são necessariamente na 1NF)

  "Uma tabela está na 1FN, se e somente se, não possuir atributos multivalor."

Definir relações NFNF

• como transformar relações NFNF (também chamadas relações UNF) em relações 1NF
  • como transformar as restrições chave de relações aninhadas
  • como transformar as dependências funcionais de relações aninhadas

Passagem à 1FN:

• Gerar uma única tabela com colunas simples
• Chave primária : id de cada tabela aninhada

Exemplo: Projetos(codp, tipo, descrição, code, nome, categ, salário, data_início, tempo_aloc)

Problemas:

• Redundância
• Anomalias de Atualização

Segunda Forma Normal

Definição:

   Uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não-chave for dependente
 da chave primária inteira, isto é, cada atributo não-chave não poderá ser dependente de apenas
 parte da chave.

No caso de tabelas com chave primária composta. Se um atributo depende apenas de uma parte da chave primária, então esse atributo deve ser colocado em outra tabela.

Passagem à 2FN:

• Geração de novas tabelas com DFs completas
• Análise de DFs:

  * tipo e descrição - DF de codp
  * nome, categ e salário - DF de code
  * data_início e  tempo_aloc - DF de toda a chave

Resultado:

• Projetos(codp, tipo, descrição)
• Empregados(code, nome, categ, salário)
• ProjEmp(codp, code, data_início, tempo_aloc)

Conclusões:

• Maior independência de dados (não há mais repetição de empregados por projeto, por exemplo)
• Redundâncias + Anomalias - DF indiretas

Terceira Forma Normal

• definição

“ Uma relação R está na 3NF, se ela estiver na 2NF e cada atributo não chave de R
 não possui dependência transitiva, para cada chave candidata de R.”

Passagem à 3FN:

• Geração de novas tabelas com DF diretas

• Análise de DFs entre atributos não chave:

  - salário - DF de categ

Resultado:

• Projetos(codp, tipo, descrição)

• Empregados(code, nome, categ)

• Categorias(categ, salário)

• ProjEmp(codp, code, data_início, tempo_aloc)

Conclusões:

• Maior independência de dados

• 3FN gera representações lógicas finais na maioria das vezes

• Redundâncias + Anomalias - DF multivaloradas

teste heheh

Terceira Forma Normal - Boyce-Codd

• definição

“Uma tabela está na BCNF, se e somente se, estiver na 3FN e todo atributo não chave depende
 funcionalmente diretamente da  chave primária, ou seja, não há dependências entre atributos
 não chave”

• exemplo
• Como transformar da 3NF para BCNF
• Nem sempre pode ser alcançada preservando a dependência.

Multi-valued and Join Dependencies

• def multi-value dependencies
• exemplo
  • trivial multi-value dependency (X->>Y is trivial if X+Y contains all attributes or Y is a subset of X)
• reasoning rules for MVDs

• def join dependency
• example
• reasoning rules for JDs
• when is join dependency implied by key constraints?
• relacionamento entre JDs e MVDs

Quarta Forma Normal

Definição

   “Uma tabela está na 4FN, se e somente se, estiver na 3FN e não existirem dependências multivaloradas”.

Exemplo: Dados sobre livros

Relação não normalizada: Livros(nrol, (autor), título, (assunto), editora, cid_edit, ano_public)

1FN: Livros(nrol, autor, assunto, título, editora, cid_edit, ano_public)

2FN: Livros(nrol,título, editora, cid-edit, ano_public)
     AutAssLiv(nrol, autor, assunto)

3FN: Livros(nrol, título, editora, ano_public)
     Editoras(editora, cid-edit)
     AutAssLiv(nrol, autor, assunto)

• Redundância para representar todas as informações
• Evitar todas as combinações: representação não-uniforme (repete alguns elementos ou posições nulas)

Passagem à 4FN:

• Geração de novas tabelas, eliminando Dependências Multivaloradas
• Análise de Dependências Multivaloradas entre atributos:
• autor, assunto -> Dependência multivalorada de nrol

Resultado:

4FN: Livros(nrol, título, editora, ano_public)
     Editoras(editora, cid-edit)
     AutLiv(nrol, autor)
     AssLiv(nrol, assunto)

Quinta Forma Normal

• definição da 5NF

Está ligada a noção de dependência de junção.

• Se uma relação é decomposta em várias relações e a reconstrução não é possível pela junção das

outras relações, dizemos que existe uma dependência de junção.

• Existem tabelas na 4FN que não podem ser divididas em duas relações sem que se altere os dados originais.
• Exemplo:

Seja as relações R1(CodEmp, CodPrj) e R2(CodEmp, Papel) a decomposição da relação ProjetoRecuro(CodEmp, CodPrj, Papel).

• exemplo
• Da 4FN para a 5NF
• Explanação de que a última forma norma pode ser alcançada com projeções

Forma Normal Chave-Domínio

• def de FNCD
• ultimate normal form
• degride normal form

Outras dependencias

• dependências encapsuladas
• dependencias como blocos em lógica de primeira ordem

---

This article was originally based on material from the Free On-line Dictionary of Computing, used with permission. Update as needed.