sistemas de banco de dados - faculdade de computaçãoilmerio/sbd20132/sbd9anormalizacao.pdf ·...
Post on 29-Nov-2018
213 Views
Preview:
TRANSCRIPT
GBC043 – Sistemas de Banco de DadosNormalização de Relações em Projeto de BD
Ilmério Reis da Silvailmerio@facom.ufu.brwww.facom.ufu.br/~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
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)
FACOM/UFU Página:11
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
FACOM/UFU Página:12
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)
FACOM/UFU Página:13
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)
FACOM/UFU Página:15
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.
FACOM/UFU Página:16
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?
FACOM/UFU Página:17
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)
FACOM/UFU Página:18
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
FACOM/UFU Página:19
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
FACOM/UFU Página:20
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
FACOM/UFU Página:21
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?
FACOM/UFU Página:22
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:
FACOM/UFU Página:25
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
FACOM/UFU Página:26
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
FACOM/UFU Página:27
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!!!
FACOM/UFU Página:28
Dependência Multivalorada - Definição
15: as tuplas t1, t2, t3 e t4, não são necessariamente distintas.
FACOM/UFU Página:29
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
15: as tuplas t1, t2, t3 e t4, não são necessariamente distintas.
FACOM/UFU Página:30
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 )
15: as tuplas t1, t2, t3 e t4, não são necessariamente distintas.
FACOM/UFU Página:31
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).
FACOM/UFU Página:32
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
FACOM/UFU Página:33
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
FACOM/UFU Página:34
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
FACOM/UFU Página:35
Quinta forma normal - 5FN
1) ou seja, cada decomposição tem que conter uma chave
FACOM/UFU Página:36
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
FACOM/UFU Página:37
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
FACOM/UFU Página:38
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.
GBC043 – Sistemas de Banco de DadosNormalização de Relações em Projeto de BD
(Parte 3 – Agoritmos de projeto)
FACOM/UFU Página:41
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;
FACOM/UFU Página:42
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.→
FACOM/UFU Página:43
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)}→
FACOM/UFU Página:52
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.
FACOM/UFU Página:53
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.
FACOM/UFU Página:54
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
FACOM/UFU Página:62
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.
FACOM/UFU Página:64
Alg. 16.4 – Exemplo
Seja a relação universal:U(Func_cpf, Pnr, Fsal, Ftelefone, Dnr, Projnome, Projlocal)
FACOM/UFU Página:65
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.
FACOM/UFU Página:67
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.
FACOM/UFU Página:70
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.
FACOM/UFU Página:71
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).
FACOM/UFU Página:73
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
top related