Banco de Dados I

Normalizao Frederico D. Bortoloti freddb@ltc.ufes.br

Qualidade de Esquemas Relacionais: Normalizao

A normalizao a explicao formal para coisas que so bvias ao se projetar um BD
A intuio do projetista o leva a dividir um esquema de BD em vrias tabelas, mas a normalizao explica porque as coisas so assim

As restries impostas pela normalizao geralmente so alcanadas de outra forma que no o procedimento de normalizao
Normalmente esquemas surgem de cima para baixo

Qualidade de Esquemas Relacionais: Normalizao

Um bom projeto de um esquema de entidades, e sua conseqente converso para um esquema relacional, segundo as regras vistas, praticamente deixa o esquema relacional normalizado Assim, utiliza-se a normalizao somente para validar um projeto relacional A normalizao necessria (embora no suficiente) a um bom projeto relacional

Qualidade de Esquemas Relacionais: Normalizao

[Date, 95]
A idia geral de normalizao que o projetista do banco de dados deveria almejar ter relaes em forma normal ltima (5FN). Porm, esta recomendao no deve ser tomada como lei. Ocasionalmente podem existir boas razes para desafiar os princpios de normalizao. A nica exigncia firme que as relaes estejam pelo menos na primeira forma normal.

Qualidade de Esquemas Relacionais: Normalizao

Principais formas normais existentes
1FN 2FN 3FN Forma normal de Boyce/Codd (FNBC) ou Nova 3FN 4FN 5FN

Estudaremos neste curso apenas at a 3FN Segue um exemplo de motivao

Qualidade de Esquemas Relacionais: Normalizao

HABILIDADES-ESPORTIVAS Identidade Nome 8795835 dson Arantes 8795835 dson Arantes 8795835 dson Arantes 8795835 dson Arantes 8795835 dson Arantes Endereo Ponta da Praia Ponta da Praia Ponta da Praia Ponta da Praia Ponta da Praia Habilidade Futebol Voleibol Basquete Atletismo Tnis

Esta tabela est mal projetada! 1. Se Pel mudar de endereo? (anomalia de atualizao) 2. Um novo esporte para Pel? (anomalia de incluso) 3. Retirar Pel do Banco de Dados (anomalia de remoo)

Qualidade de Esquemas Relacionais: Normalizao

HABILIDADES-ESPORTIVAS Identidade Nome 8795835 dson Arantes Endereo Habilidade Ponta da {Futebol, Praia Voleibol, Basquete, Atletismo, Tnis}

Isto no uma tabela, pois possui atributos com valores no atmicos. O que possvel fazer, dentro do modelo relacional?

Qualidade de Esquemas Relacionais: Normalizao

ESPORTISTAS Identidade Nome Endereo 8795835 dson Arantes Ponta da Praia ... ... ... HABILIDADES Identidade Esporte 8795835 Futebol 8795835 Voleibol 8795835 Basquetebol 8795835 Atletismo 8795835 Tnis

A repetio da coluna identidade uma redundncia necessria

Normalizao
Primeira Forma Normal (1FN)
Toda tabela deve ser minimamente normalizada (1FN) Tabela em 1FN: O valor de uma coluna de uma tabela indivisvel

Normalizao 1FN
Ex.: Empregado
Matr cula 120 120 121 121 121 270 270 273 274 279 279 279 301 306 Nome Joo Joo Hlio Hlio Hlio Gabriel Gabriel Silva Abrao Carla Carla Carla Ana Manoel Cod Cargo 1 1 1 1 1 2 2 3 2 1 1 1 1 3 NomeCargo Programador Programador Programador Programador Programador Analista Analista Projetista Analista Programador Programador Programador Programador Projetista CodProj 01 08 01 08 12 08 12 01 12 01 08 12 12 17 DataFim 17/07/95 12/01/96 17/07/95 12/01/96 21/03/96 12/01/96 21/03/96 17/07/95 21/03/96 17/07/96 12/01/96 21/03/96 21/03/96 21/03/96 Horas 37 12 45 21 107 10 38 22 31 27 20 51 16 67

Normalizao 1FN
A chave primria para a tabela empregados (Matrcula,CodProj) Um dos objetivos da normalizao reduzir a redundncia de dados, porm com a tabela anterior aumentamos a redundncia Precisamos realizar outros passos de normalizao para termos um bom projeto A tabela apenas na 1FN possui caractersticas indesejveis

Normalizao 1FN
Anomalias da 1FN
Insero: no podemos inserir um empregado sem que este esteja alocado num projeto, nem um projeto sem que haja um empregado trabalhando nele (integridade de entidade) Remoo: se precisarmos remover um projeto, as informaes de empregados que estiverem lotados apenas naquele projeto sero perdidas

Normalizao 1FN
Anomalias da 1FN
Atualizao: se um empregado for promovido de cargo teremos que atualizar os atributos CodCargo e NomeCargo em todas as tuplas nas quais aquele empregado est presente

Normalizao 1FN
Concluso
Uma tabela em 1FN no evita, porm, anomalias de incluso, atualizao e remoo preciso uma normalizao mais fina , ou outras formas formas normais
Segunda Forma Normal (2FN) Terceira Forma Normal (3FN)

Esta normalizao fina utiliza o conceito de dependncia funcional

Dependncias Funcionais
Dependncias funcionais so restries ao conjunto de relaes vlidas A B, l - se:
A funcionalmente determina B B dependente funcional de A B funo de A

Sendo duas tuplas t1 e t2 na relao R, se t1[A] = t2[A], ento obrigatoriamente t1[B] = t2[B]
Ou seja, para cada valor de A s existe um valor de B

Dependncias Funcionais
A B, negao de A B A ou B podem ser um conjunto de atributos Para o exemplo da tabela esportista:
Identidade Identidade Identidade Nome Endereo Habilidade Identidade Nome Endereo Habilidade Identidade Identidade Identidade Nome, Endereo

Dependncias Funcionais
A B A D Uma coluna pode depender funcionalmente de uma combinao de colunas (A,B) C

Dependncias Funcionais
Idia de normalizao fina: agrupar numa tabela somente dois conjuntos de atributos X e Y, com X Y X ento a chave da tabela, e Y complemento da chave

Normalizao 2FN
Uma tabela est na Segunda Forma Normal (2FN) se ela 1FN e todo atributo do complemento de uma chave candidata totalmente funcionalmente dependente daquela chave A, B, C => D (D totalmente funcionalmente dependente de {A, B, C}) se para todo valor de {A, B, C} s existe um valor de D, e se D no funcionalmente dependente de A, ou B, ou C

Normalizao 2FN
Exemplo 1: ESPORTISTA (Identidade, Nome, Endereo, Esporte)
Chaves Candidatas Complementos da Chave Identidade Nome, Endereo, Esporte {Nome, Endereo} Identidade, Esporte

Normalizao 2FN
Identidade Nome Identidade Endereo Identidade Esporte {Nome, Endereo} => Identidade {Nome, Endereo} => Esporte

Normalizao 2FN
Concluso: O atributo Esporte deve ser retirado da relao ESPORTISTA ESPORTISTA (Identidade, Nome, Endereo) PRATICA-ESPORTE (Identidade, Esporte)
Atualizar o endereo de Pel: sem anomalia Incluir uma nova habilidade de Pel: sem anomalia

Normalizao 2FN
Exemplo 2:
ESTUDANTE-DISCIPLINA E # Enome Sexo Idade E 1 Joo M 25 E 1 Joo M 25 E 1 Joo M 25 E 2 Maria F 22 E 2 Maria F 22 E 2 Maria F 22 E 3 Joo M 27 E 3 Joo M 27
Chaves Candidatas {E#, D#} {E#, Dnome}}

D# D1 D2 D3 D2 D3 D4 D2 D3

Dnome Opinio Mat Boa Quim M Fis Boa Quim Satisf. Fis Satisf. Est M Quim Boa Fis Boa

Complementos da Chave Enome, Sexo, Idade, Dnome, Opinio Enome, Sexo, Idade, D#, Opin

Normalizao 2FN
{E#, D# }:
{E#, D#} => Enome {E#, D#} => Sexo {E#, D#} => Idade {E#, D#} => Dnome {E#, D#} => Opinio (E# Enome) (E# Sexo) (E# Idade) Dnome)

(D#

Normalizao 2FN
{E# , Dnome):
{E#, Dnome} {E#, Dnome} {E#, Dnome} {E#, Dnome} {E#, Dnome} => Enome => Sexo => Idade => D# => Opinio (E# Enome) (E# Sexo) (E# Idade) (Dnome D# )

Concluso: Enome, Sexo, Idade e Dnome devem ser

retirados de ESTUDANTE-DISCIPLINA

Normalizao 2FN
ESTUDANTE

E# E1 E2 E3

Enome Joo Maria Joo

Sexo M F M

Idade 25 22 27
ESTUDANTE-DISCIPLINA E # D # Opinio E1 D1 Boa E1 D2 Pobre E1 D3 Boa E2 D2 Satisfatria E2 D3 Satisfatria E2 D4 Pobre E3 D2 Boa E3 D3 Boa

DISCIPLINA D # Dnome D1 Mat D2 Quim D3 Fis D4 Est

Normalizao 2FN
Ex3:A tabela Empregado anterior aps passarmos para 2FN resultaria em trs tabelas
Empregado Matrcula Nome Joo 120 Hlio 121 Gabriel 270 Silva 273 Abrao 274 Carla 279 Ana 301 Manuel 306 CodCargo 1 1 2 3 2 1 1 3 NomeCargo Programador Programador Analista Projetista Analista Programador Programador Projetista

Normalizao 2FN
Ex3:A tabela Empregado anterior aps passarmos para 2FN resultaria em trs tabelas
Alocao
Matrcula 120 120 121 121 121 270 270 273 274 279 279 279 301 301 306

Projeto
CodProj 01 08 12 DataFim 17/07/95 12/01/96 21/03/96

CodProj 01 08 01 08 12 08 12 01 12 01 08 12 01 12 12

Horas 37 12 45 21 107 10 78 22 31 27 20 51 16 85 67

Normalizao 2FN
Anomalias da 2FN:
Insero: S podemos criar cargos se houver empregados designados para ele Remoo: Se removermos um empregado que ocupa unicamente um cargo na empresa, perderemos a informao deste cargo Atualizao: Se um cargo muda de nome precisaremos mudar todas as tabelas em que este cargo aparece

Normalizao 3FN
Terceira Forma Normal
Envolve o conceito de dependncia transitiva

Suponha que tenhamos uma tabela com colunas A, B e C

Se a coluna C funcionalmente dependente de B e B funcionalmente dependente de A, ento C funcionalmente dependente de A

Normalizao 3FN
Definio: Uma relao est em 3FN se, e somente se, estiver em 2FN e todos os atributos no-chave forem dependentes no-transitivos da chave primria
Ex.: Ao analisarmos a nova tabela empregado que est em 2FN temos:
Matrcula CodCargo NomeCargo

Normalizao 3FN
NomeCargo dependente transitivo de Matrcula Removendo esta dependncia transitiva, obteremos, alm das tabelas Projeto e Alocao, as seguintes tabelas:
Empregado
Matrcula 120 121 270 273 274 279 301 306 Nome Joo Hlio Gabriel Silva Abrao Carla Ana Manuel CodCargo 1 1 2 3 2 1 1 3

Cargo
CodCargo 1 2 3 Nome Programador Analista Projetista

Normalizao 3FN
Uma relao est em 3FN se todas as colunas da tabela so funcionalmente dependentes da chave inteira e nada alm da chave A 3FN elimina as caractersticas mais potencialmente indesejveis dos dados que esto em 2FN ou 1FN Existem outros casos especiais que requerem mais nveis de normalizao: Boyce-Codd, 4FN e 5FN

Uma Metodologia de Normalizao

Passo 1: Tome projees de tabelas 1FN para eliminar todas as dependncias funcionais no-totais. O resultado uma coleo de tabelas 2FN Passo 2: Tome projees das tabelas obtidas no passo 1 para eliminar todas as dependncias transitivas. O resultado uma coleo de relaes 3FN