sistemas de banco de dados - faculdade de computaçãoilmerio/sbd20132/sbd9anormalizacao.pdf ·...

GBC043 – Sistemas de Banco de DadosNormalização de Relações em Projeto de BD

Ilmério Reis da [email protected]/~ilmerio/sbdUFU/FACOM

FACOM/UFU Página:2

Projeto de BD Relacionais Método 1: mapeamento do modelo conceitual para

o Modelo R

Método 2: formal com critérios de qualidade

Método 3: mapeamento seguido de aplicação do método formal

Objetivos: Preservar a informação Minimizar redundância

FACOM/UFU Página:3

Projeto de BD - Diretrizes Informais Semântica clara com esquemas fáceis de explicar Evitar informações redundantes Evitar possibilidade de valores NULL nas tuplas Evitar o surgimento de tuplas falsas: a junção de

relações deve ser feita somente com chave estrangeira

Contra exemplo: FUNC_LOCAL(fnome, plocal) FUNC_PROJ(cpf, pnum, horas, pnome, plocal) FUNC_LOCAL ⋈plocal FUNC_PROJ

junção baseada em plocal GERA tuplas falsas


(Parte 1-1FN até FNBC)

FACOM/UFU Página:5

Normalização de Relações

Def. Normalização é o processo reversível de substituição de um conjunto de relações de um banco de dados por sucessivos conjuntos onde as relações são mais simples.

O objetivo da normalização é eliminar anomaliasPor exemplo:

Seja o Esquema de BD abaixo formado por apenas um esquema de relação (relação universal)

Relação Universal de Empregados e Projetos: uemp(ecod, ename, title, sal, pno, pname, budget, resp, dur)

FACOM/UFU Página:6

Projeto de BD – Anomalias uemp(ecod, ename, title, sal, pno, pname, budget, resp, dur)

Em uemp temos as seguintes anomalias:• Anomalia de Repetição

cargo e salário são repetidos em cada projeto• Anomalia de Atualização

um aumento de salário reflete em todas as tuplas dos projetos em que o empregado trabalha

• Anomalia de Inserçãocomo inserir um empregado que ainda não foi alocado para um projeto?

• Anomalia de Exclusãocomo eliminar o único projeto em que um funcionário trabalha sem eliminar o funcionário ?

FACOM/UFU Página:7

Normalização – Como fazer

• Como normalizar? • Decomposição sem perda da relação universal em

conjuntos de relações nas formas normais (1FN, 2FN, 3FN, etc.) preservando as dependências

• Dependência é a base para as formas normais

FACOM/UFU Página:8

Dependência Funcional - DefiniçãoSejam: R(A1,A2, ... ,An) um esquema de relação definido

sobre conjunto de atributos A={A1,A2, ... , An}; r uma relação sobre R X, Y dois subconjuntos de atributos de A | X ⊂ A

e Y ⊂ A

Def. Uma expressão X → Y é chamada de Dependência Funcional sobre R. Esta dependência é satisfeita por r se para quaisquer tuplas ti e tj em r,

SE (ti[X]=tj[X]) ENTÃO (ti[Y]=tj[Y])

FACOM/UFU Página:9

Dependência Funcional - Exemplo:

uemp(ecod, ename, title, sal, pno , pname, budget, resp, dur)

pno → (pname, budget)(ecod, pno) → (ename, title, sal, resp, dur) ecod → (ename, title, sal) title → sal

FACOM/UFU Página:10

Dependência Funcional Parcial e TotalEm uma dependência funcional X → Y um

subconjunto Y’ ⊆ Y é dependente parcialmente de X se existe um subconjunto X’ ⊂ X tal que X’ → Y’, caso contrário a dependência é total.

Exemplo: uemp(ecod, ename, title, sal, pno, pname, budget, resp, dur)

Dep Parcial (ecod, pno) → (ename, title, sal) pois

ecod → (ename, title, sal)Dep Total (ecod, pno) → (resp, dur)


Primeira forma normal - 1FN

Def. Uma relação R está na primeira forma normal se todos os seus atributos são atômicos.

A 1FN não permite que o valor de um atributo seja um conjunto de valores ou uma tupla de valores ou uma combinação de ambos.

Exemplo: todas as relações apresentadas até agora


Segunda forma normal - 2FN Uma relação R está na segunda forma normal se está na 1FN e

se todo atributo não chave, também chamado atributo não principal, é totalmente dependente da chave (não há dependência parcial)

• Apenas interesse histórico, não há aplicação práticaExemplo: Na 1FN: uemp(ecod, ename, title, sal, pno, pname,

budget, resp, dur) com chave=(ecod, pno)Dep Parcial : (ecod, pno) → (ename, title, sal)

pois ecod → (ename, title, sal)

Na 2FN: emp(ecod, ename, title, sal) proj(pno, pname, budget) asg(ecod, pno, resp, dur)


Terceira forma normal - 3FN Uma relação R está na terceira forma normal se para

toda dependência funcional X → Y associada com R uma das seguintes afirmações é verdadeira: Y ⊆ X (i.e, X → Y é DF trivial);ou X é superchave de R; ou Y é um atributo principal (pertence a uma chave)

Exemplo:

Na 2FN: emp(ecod, ename, title, sal), mas title → sal

Na 3FN: emp(ecod, ename, title), pay(title, sal)


Definições gerais das 3 primeiras formas normais


Forma normal de Boyce-Codd - FNBCUma relação R está na forma normal de Boyce-Codd

se para toda dependência funcional X → Y associada com R uma das seguintes afirmações é verdadeira: Y ⊆ X (i.e, X → Y é DF trivial);ou X é superchave de R;

Exemplo:

Está na FNBC: emp(ecod, ename, title), pay(title, sal),

É raro uma relação estar na 3FN e não estar na FNBC, mas vejamos dois exemplos.


Exemplo de normalização até a FNBCSeja o esquema de lotes a venda em um Estado:lotes(propriedadeNum, cidade, loteNum, area, preco,

imposto)chaves primária: propriedadeNum; DF1: propriedadeNum é chave primáriaDF2: (cidade, loteNum) é chave candidataDF3: cidade → imposto; % imposto fixo por cidadeDF4: area → preco; % preço por área independente

% dos demais atributosDF5: area → cidade; % domínio de tamanhos

% disjuntos por cidadeEstá na 1FN? E na 2FN? E na 3FN? E na FNBC?


Exemplo lotes: 1FNlotes(propriedadeNum, cidade, loteNum, area, preco,

imposto)

Está na 1FN, mas não na 2FN, pois:

DF2: (cidade, loteNum) → propriedadeNum, area, preco, imposto

DF3: cidade → imposto

Imposto é parcialmente dependente da chave (cidade, loteNum)


Exemplo lotes1 e lotes2: 2FNlotes1(propriedadeNum, cidade, loteNum, area, preco)lotes2(cidade, imposto)

lotes2 está na 3FN;lotes1 está na 2FN, mas não na 3FN, pois:

DF4: area → preco;

- area não é superchave e preço não é atributo principal


Exemplo lotes1 e lotes2: 3FNlotes1a(propriedadeNum, cidade, loteNum, area)lotes1b(area, preco)lotes2(cidade, imposto)

Lotes1a, lotes1b e lotes2 estão na 3FN, mas lotes1a não está na FNBC, pois:

DF5: area → cidade;

Observe que lotes1a está na 3FN porque, embora area não seja supercahve, cidade é atributo principal. Entretanto isso não é relevante para a FNBC


Exemplo lotes na FNBClotes1ax(propriedadeNum, loteNum, area)

lotes1ay(area, cidade)

lotes1b(area, preco)

lotes2(cidade, imposto)

Observe que a DF2 foi perdida nesta decomposição


Outro Exemplo de 3FN x FNBCensina(aluno, disciplina, professor)DF1: {aluno, disciplina} professor; →

DF2: professor disciplina; % cada professor→

% leciona uma disciplina1FN: atributos são atômicos? Sim2FN: há dependência parcial? Não, logo está na 2FN3FN: dependências de superchaves ou apontando

para atributos principais? sim, logo está na 3FNFNBC: dependências de superchaves? Não, veja DF2

Como decompor ensina?


Alternativas de decomposição na FNBC1. (aluno, professor), (aluno, disciplina)2. (disciplina, professor), (aluno, disciplina)3. (disciplina, professor), (aluno, professor)Todas perdem DF1, mas em 3. evitamos tuplas falsas

após uma junção. Ex. de instância:


Exercício 1FN a FNBCExercício 15.19 de [EN]. Esquema de histórico dos

alunos


(Parte 2 – 4FN e 5FN)


Além das Dependências Funcionais

Motivação: alguns problemas de redundância não são detectados pelas DF

Então, outras dependências são definidas, por exemplo:

Dependências Multivaloradas Dependências de Junção Dependências de Inclusão


Dependência Multivalorada – O ProblemaSeja a relação CPL(curso, professor, livro), onde:

– O professor P pode lecionar o curso C– O livro L é recomendado para o curso C

Chave é CPL Livros e professores são

independentes Está na FNBC, mas há

redundância Sugere outra FN que nos

leve a normalização de CPL para CP e CL

CPL Curso Professor Livro

t1 Fisica Green Mecânica

t2 Fisica Brown Ótica

t3 Fisica Green Ótica

t4 Fisica Brown Mecânica

t5 Matematica Green Mecânica

t6 Matematica Green Vetores

t7 Matematica Green Geometria


Dependência Multivalorada - Intuição

Sejam r, R, X e Y conforme definido, a dependência multivalorada X → → Y é válida sobre r de R se para cada valor de X em r está associado um conjunto de valores de Y e esse conjunto é independente dos valores de Z=R - (X∪ Y)

• Intuitivamente o valor de um atributo determina um conjunto de valores de outro atributo!!!


Dependência Multivalorada - Definição

15: as tuplas t1, t2, t3 e t4, não são necessariamente distintas.


Dependência Multivalorada-Exemplo 1

CPL Curso Professor Livro

t1 Fisica Green Mecânica

t2 Fisica Brown Ótica

t3 Fisica Green Ótica

t4 Fisica Brown Mecânica

t5 Matematica Green Mecânica

t6 Matematica Green Vetores

t7 Matematica Green Geometria



Dependência Multivalorada–Exemplo 2

R X Y Z

t1 a b1 c1

t2 a b2 c2

t3 a b1 c2

t4 a b2 c1

SE (t1 ∧ t2 )

ENTÃO (t3 ∧ t4 )



Dependência Multivalorada – Definição alternativa

Se X → → Y Então

πYZ(σX=x(R))=πY(σX=x(R)) x πZ(σX=x(R)).

Garante que dado o valor de X os valores de Y e Z são independentes.

Se existe ti com (X=A e Y=B) e

existe tj com (X=A e Z=C)

Então deve existir tk com (X=A, Y=B e Z=C).


Dependência Multivalorada - Propriedades

• toda dependência funcional é dependência multivalorada mas o recíproca não é necessariamente verdadeira

• Se (X→ → Y) e (Z=R-X ∪ Y) então X → → Z• Se Y for subconjunto de X ou R=(X ∪ Y) então a MVD (X → → Y) é trivial• Se a MVD não for trivial, para garantir a MVD,

teremos que repetir valores em tuplas, gerando redundância...isto leva à 4FN


Quarta forma normal - 4FN

Exemplo: skill(ecod, pno, place) ecod → → pno, mas ¬ (ecod →→ pno)ecod → → place, mas ¬ (ecod → place)

Na 4FN

ep(ecod, pno)el(ecod, place)

17: F+ é o conjunto de todas as dependências implicadas por F


Dependência de Junção

1) o símbolo * é usado como junção natural

2) decomposição de junção não aditiva, ou decomposição de junção sem perda, é uma decomposição que mantêm a igualdade acima


Quinta forma normal - 5FN

1) ou seja, cada decomposição tem que conter uma chave


Dependência de Junção - ExemploExemplo:

Seja X = (ecod, pno) e Y=(ecod, place) então SKILL = X join Y

DJ(X, Y) é uma dependência de junção em skill.

A dependência multivalorada é um caso particular de dependência de junção


Quinta forma normal – 5FN - Exemplo

Exemplo: está na 5FNemp(ecod, ename, title)proj(pno, pname, budget)asg(ecod, pno, resp, dur)

pay(title, sal)

Obs: - uma relação na 5FN não pode ser decomposta sem perda de informação

- dependência de inclusão: define que algumas colunas estão contidas em outras. Chave estrangeira é um exemplo de dependência de inclusão


Normalização 2 – Considerações finais

A decomposição multivias para a 5FN é restrição semântica bastante peculiar e a normalização para a 5FN raramente é feita nestes termos

Uma alternativa à decomposição da relação universal é utilizar ferramentas de projeto conceitual e mapeamento para o relacional.

Por exemplo, um mapeamento do Modelo de Entidades e Relacionamentos para o Modelo Relacional gera esquemas de BD na terceira forma normal.


Normalização 2 - Exercício


(Parte 3 – Agoritmos de projeto)


Algoritmos de projeto de BD

deduzir dependências funcionais a partir de um conjunto dado;

junção sem perda e preservação de dependências funcionais;

projeto relacional por síntese;


Fecho de DF - F+

Seja F o conjunto de dependências funcionais que são especificadas no esquema de relação R, o conjunto de todas as dependências que incluem F e todas as dependências que podem ser deduzidas de F, é chamado de fechamento de F, ou fecho de F, sendo denotado por F+.

Obs.: uma DF X Y é deduzida de um conjunto de →dependências F especificado em R, SE:

Sempre que r satisfizer todas as dependências em F ENTÃO X Y também se mantém em r.→


Fecho de DF – F+ - Exemplo

F = {(Dep_nr Cpf_gerente), →

(Cpf_gerente Telefone_ger)}→

F |= (Dep_ nr Telefone_ger); % Lê-se: de F →deduzimos...

Como não há mais DF a deduzir de F, temos que:

F+ = F ∪ {(Dep_ nr Telefone_ger)}→


Regras de inferência em DF


Fecho de X sob F - X+


X+ sob F - Exemplo


Equivalência de conjuntos de DF


Equivalência de conjuntos de DF – Exemplo/Exercício calcule F+ e G+


Conjunto mínimo de DF


Cobertura mínima de F


Alg. 16.2 - Cobertura mínima de FAlg. 16.2a – Chave


Decomposição de R

O conjunto F de dependências funcionais que devem ser mantidas nos atributos de R é especificado pelos projetistas de banco de dados e se torna disponível aos algoritmos de projeto.

Ao utilizar as dependências funcionais, os algoritmos decompõem o esquema de relação universal R em um conjunto de esquemas de relação D = {R1, R2, ..., Rm}, que se tornará o esquema do banco de dados relacional; D é chamado de decomposição de R.


Preservação de atributo

D = {R1, R2, ..., Rm}, temos de garantir que cada atributo em R aparecerá em pelo menos um esquema de relação Ri na decomposição, de modo que nenhum atributo seja perdido. Formalmente, temos

Esta é chamada de condição de preservação de atributo de uma decomposição.


Preservação de dependência - Intuição

Seria útil se cada dependência funcional X→Y especificada em F aparecesse diretamente em um dos esquemas de relação Ri na decomposição D ou pudesse ser deduzida das dependências que aparecem em alguma Ri.

Informalmente, essa é a condição de preservação de dependência


Preservação de dependência - Definição


Preservação de dependência e 3FN


Junção sem perda (não aditiva)


Alg. 16.3 – Testa junção não aditiva


Decomposições sucessivas


Teste de junção não aditiva para decomposições binárias


Decomposições sucessivas


Preservação de dependência e 3FN

O Algoritmo 16.4, a seguir, cria uma decomposição de preservação de dependência D = {R1, R2, ..., Rm} de uma relação universal R com base em um conjunto de dependências funcionais F, tal que cada Ri em D está na 3FN.

Isso garante apenas a propriedade de preservação de dependência; mas não garante a propriedade de junção não aditiva.


Alg. 16.4 – Síntese para 3FN com preservação de dependência


Alg. 16.4 – Exemplo

Seja a relação universal:U(Func_cpf, Pnr, Fsal, Ftelefone, Dnr, Projnome, Projlocal)


Alg. 16.4 – Exemplo cont...

Ao aplicar o Algoritmo 16.2 de cobertura mínima, na etapa 3 vemos que: - Pnr é um atributo redundante em Func_cpf, Pnr → Fsal, Ftelefone, Dnr. - Func_cpf é redundante em Func_cpf, Pnr → Projnome, Projlocal.


Alg. 16.5


Alg. 16.4 e 16.5 - Limitações

Até aqui, no Algoritmo 16.4, mostramos como obter um projeto 3FN com o potencial para perda de informação e, no Algoritmo 16.5, mostramos como obter um projeto FNBC com a perda em potencial de certas dependências funcionais.

No momento, sabemos que não é possível ter todos os três a seguir: (1) projeto sem perdas garantido, (2) preservação de dependência garantida e (3) todas as relações na FNBC.


Alg. 16.6 – Exemplo 1


Nulos

Problemas com valores NULL

Ainda não existe uma teoria de projeto relacional totalmente satisfatória e que inclua valores NULL.

NULL para atributos que serão usados para juntar relações individuais na decomposição é um problema, conforme exemplo a seguir.


Nulos - Exemplo

Considere as duas relações, FUNCIONARIO e DEPARTAMENTO do banco de dados, mostradas na Figura 16.2(a) e a consulta (FNOME, DNOME).


Nulos – Exemplo cont...

Resultado da junção externa


Algoritmos de normalização e projetosAlternativos – Considerações Finais

Um dos problemas com os algoritmos de normalização que descrevemos é que o projetista de banco de dados precisa primeiro especificar todas as dependências funcionais relevantes entre os atributos do banco de dados. Essa não é uma tarefa simples para um banco de dados grande, com centenas de atributos.

Outro problema é que os algoritmos não são determinísticos

Nem sempre é possível encontrar uma decomposição que preserve dependências e esteja na FNBC


FIM – Normalização e Projeto

FIM – Normalização e Projeto

sistemas de banco de dados - faculdade de computaçãoilmerio/sbd20132/sbd9anormalizacao.pdf ·...

Documents