©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts Capítulo 7: Design de...

©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts

Capítulo 7: Design de Bases de DadosCapítulo 7: Design de Bases de Dados

Objectivos com Design de Bases de Dados Dependências funcionais 1ª Forma Normal Decomposição Forma Normal de Boyce-Codd 3ª Forma Normal Dependências multivalor 4ª Forma Normal Visão geral sobre o processo de design


Objectivos com o Design de BDs RelacionaisObjectivos com o Design de BDs Relacionais

Pretendem-se encontrar “bons” conjuntos de esquemas de relações para armazenar os dados.

Um “mau” design pode levar a: Repetição de dados. Impossibilidade de representar certos tipos de informação. Dificuldade na verificação da integridade

Objectivos do Design: Evitar dados redundantes Garantir que as relações relevantes sobre dados podem ser

representadas Facilitar a verificação de restrições de integridade.


Exemplo de mau designExemplo de mau design Considere o esquema simples:

Amigos = (nome, telefone, código_postal, localidade)

Redundância: Os valores de (código_postal, localidade) são repetidos para cada amigo com

um mesmo código postal Desperdiça-se espaço de armazenamento Dá azo a inconsistências Complica bastante a verificação da integridade dos dados

Dificuldade de representar certa informação Não se pode armazenar informação do código postal de uma localidade sem

que hajam amigos dessa localidade. Podem usar-se valores nulos, mas estes são difíceis de gerir.

nome

MariaJoãoPedroAna

telef.

1111222211123333

CPostal

2815100011002815

localidade

CaparicaLisboaLisboa

Caparica


DecomposiçãoDecomposição

Decompor o esquema Amigos em:

Amigos1 = (nome,telefone, código_postal)CPs = (código_postal, localidade) Todos os atributos do esquema original (R) devem

aparecer na decomposição em (R1, R2):

R = R1 R2

Decomposição sem perdas: Para todas as (instâncias de) relações r que “façam

sentido” sobre o esquema R:

r = R1 (r) R2 (r) Note-se que o “façam sentido” depende do problema

concreto.


Exemplo de decomposição sem perdas Exemplo de decomposição sem perdas

Decomposição de Amigos em Amigos1 e CPs:

Amigos1 (r) CPS (r) = r

r

nome

MariaJoãoPedroAna

telef.

1111222211123333

CPostal

2815100011002815

localidade


Caparica

Amigos1(r)

nome

MariaJoãoPedroAna

telef.

1111222211123333

CPostal

2815100011002815

CPs(r)

CPostal

281510001100

localidade



Exemplo de decomposição com perdas Exemplo de decomposição com perdas Decomposição de CPs em:

CP1 = (código_postal) e Locs = (localidade)

r

CPostal

281510001100

localidade


Amigos1 (r) CPS (r)

CPostal

281528151000100011001100

localidade

CaparicaLisboa

CaparicaLisboa

CaparicaLisboa

CP1(r)

CPostal

281510001100

Locs(r)

localidade

CaparicaLisboa

≠

Perdeu-se a informação de qual os CPs das localidades!!! Decompor parecia bom para evitar redundâncias. Mas decompor demais pode levar à perda de informação.


Outro exemplo com perdas Outro exemplo com perdas Decomposição de Amigos em:

Amigos2 = (nome,telefone,localidade) e Loc = (localidade,código_postal).

nome

MariaJoãoPedroAna

telef.

1111222211123333

localidade


Caparica

Amigos2(r)CPostal

281510001100

localidade


Loc(r)

nome

MariaJoãoPedroAna

telef.

1111222211123333

CPostal

2815100011002815

localidade


Caparica

rnome

MariaJoãoJoãoPedroPedroAna

telef.

111122222222111211123333

CPostal

281510001100100011002815

localidade

CaparicaLisboaLisboaLisboaLisboa

Caparica

Amigos2(r) Loc(r)

≠

Perdeu-se a informação de qual é o CP do João (e do Pedro)!!! O que torna esta decomposição diferente da primeira?

Depende do problema.


Objectivo: chegar a um conjunto da seguinte formaObjectivo: chegar a um conjunto da seguinte forma

Decidir se o esquema R já está num “bom” formato. Se não estiver, decompor R num conjunto de esquemas

{R1, R2, ..., Rn} tal que: cada um deles está num “bom” formato A decomposição é sem perdas

A teoria é baseada em Dependências funcionais Dependências multivalor


Dependências funcionaisDependências funcionais

Restrições sobre o conjunto de relações possíveis. Exige que os valores num conjunto de atributos determinem

univocamente os valores noutro conjunto de atributos. São uma generalização da noção de chave.


Dependências Funcionais (Cont.)Dependências Funcionais (Cont.) Seja R o esquema duma relação e R e R. A dependência

funcional: é verdadeira em R sse, para toda a relação possível (i.e. “que faça sentido”) r(R), sempre que dois tuplos t1 e t2 de r têm os mesmos valores em , também têm os mesmos valores em :

t1,t2 r, t1[] = t2 [] t1[ ] = t2 [ ] De forma equivalente:

a dom(), (=a(r)) tem no máximo 1 tuplo Exemplo: Seja r(A,B):

Nesta instância, A B não é verdadeira, mas B A é.

1 41 53 7

A B


Dependências Funcionais (Cont.)Dependências Funcionais (Cont.)

Casos extremos { }

Só se verifica se na relação r todos os tuplos têm o mesmo valor em (nunca deve ser permitido)

{ } Verifica-se para toda a relação r e conjunto de atributos

Diz-se que uma dependência é trivial se é satisfeita por todas as relações (quer façam sentido ou não) sobre um esquema E.g.

customer-name, loan-number customer-name customer-name customer-name

Em geral, é trivial se


Dependências Funcionais e ChavesDependências Funcionais e Chaves

K é uma superchave no esquema R sse K R K é uma chave candidata em R sse

K R, e para nenhum K, R

As dependências funcionais permitem expressar restrições que não o podem ser usando apenas os conceitos de chave. E.g:

(customer-name, loan-number, branch-name, amount).Espera-se que as seguintes dependências sejam verdadeiras:

loan-number amountloan-number branch-name

mas não se espera que a dependência abaixo seja verdadeira:

loan-number customer-name


Uso de Dependências FuncionaisUso de Dependências Funcionais

Usam-se dependências funcionais para: testar (instâncias de) relações, para verificar se “fazem sentido” de

acordo com as dependências funcionais. Se uma relação r torna verdadeiras todas as dependências dum

conjunto F, então diz-se que r satisfaz F. Especificar restrições sobre as relações

Diz-se que F é verdadeira em R se todas as relações (possíveis) sobre R satisfazem as dependências em F.

Nota: Uma instância particular duma relação pode satisfazer uma dependência funcional mesmo que a dependência não seja verdadeira no esquema. Por exemplo, uma instância particular (em que, por acaso, nenhum empréstimo tenha mais que um cliente) satisfaz: loan-number customer-name.


Fecho de um Conjunto de Fecho de um Conjunto de Dependências FuncionaisDependências Funcionais

Dado um conjunto F de dependências, há outras dependências que são logicamente implicadas por F. E.g. Se A B e B C, então, obrigatoriamente, A C

Ao conjunto de todas as dependências funcionais implicadas por F chama-se fecho de F (denotado por F+).

Podem encontrar-se todas as dependências em F+ por aplicação do Axiomas de Armstrong: Se , então (reflexividade) Se , então (aumento) Se , e , então (transitividade)

Estes regras são coerentes (só geram dependências que pertencem a F+) e completas (geram todas as dependências pertencentes a F+).


ExemploExemplo R = (A, B, C, G, H, I)

F = { A B A CCG HCG I B H}

alguns elementos de F+

A H transitividade a partir de A B e B H

AG I aumento de A C com G, obtendo-se AG CG

e depois transitividade com CG I CG HI

de CG H e CG I : “regra de união” que pode inferir-se de– definição de dependências funcionais, ou– Aumento de CG I inferindo CG CGI, aumento de

CG H inferindo CGI HI, e depois transitividade


Construção de FConstrução de F++

Para calcular o fecho de um conjunto de dependências F:

F+ = FRepetirPara cada dependência funcional f F+

aplicar reflexividade e aumento em f adicionar os resultados a F+

Para cada par de dependências f1e f2 F+

Se f1 e f2 podem combinar-se para usar transitividade Então adicionar a dependência resultado a F+

Até F+ não mudar mais

NOTA: Veremos, mais tarde, outro procedimento para este problema


Fecho de Dependências (Cont.)Fecho de Dependências (Cont.)

Podemos facilitar a construção (manual) de F+ usando mais regras coerentes: Se e , então (união) Se , então e (decomposição) Se e , então (pseudotransitividade)Todas estas regras se podem derivar dos Axiomas de Armstrong.


Fecho de um Conjunto de AtributosFecho de um Conjunto de Atributos

Dado um conjunto de atributos define-se o fecho de sobre F (denotado por +) como sendo o conjunto de atributos que dependem funcionalmente de dado F. I.e:

F+ +

Algoritmo para calcular +

result := ;Enquanto (mudança em result)

Para cada em F begin

Se result Então result := result end


Exemplo de fecho de atributosExemplo de fecho de atributos R = (A, B, C, G, H, I) F = {A B

A C CG HCG IB H}

(AG)+

1. result = AG2. result = ABCG (A C e A B)3. result = ABCGH (CG H e CG AGBC)4. result = ABCGHI (CG I e CG AGBCH)

Será que AG é chave candidata? 1. Será AG superchave?

1. AG R? 2. E algum subconjunto próprio de AG é superchave?

1. A+ R?2. G+ R?


Uso de fecho de atributosUso de fecho de atributos

O algoritmo pode ser usa para vários fins: Testar superchaves:

Para testar se é superchave, calcular +, e verificar se + contém todos os atributos de R.

Testar dependências funcionais Para ver se a dependência é verdadeira (i.e. pertence a F+),

basta ver se +. Ou seja, basta calcular +, e verificar se contém . É um teste simples e muito útil

Cálculo do fecho de F Para cada R, calcular +. Para cada S +, devolver como

resultado a dependência S.


Coberturas de Conjuntos de DFsCoberturas de Conjuntos de DFs

Um conjunto de dependências, podem conter algumas delas que são redundantes (por se inferirem das outras) Eg: A C é redundante em: {A B, B C, A C} Partes de dependências também podem ser redundantes

E.g. : {A B, B C, A CD} pode ser simplificado para {A B, B C, A D}

E.g. : {A B, B C, AC D} pode ser simplificado para {A B, B C, A D}

Um conjunto de dependências funcionais F é uma cobertura de (outro) conjunto G sse F+ = G +

Intuitivamente, uma F é uma cobertura canónica de G se é uma cobertura de G e, além disso, F é “minimal” e nenhuma das dependência em F tem partes redundantes


Atributos dispensáveisAtributos dispensáveis Considere o conjunto de dependências F e a dependência

F. O atributo A é dispensável (à esquerda) em se A

e F implica (F – { }) {( – A) }. O atributo A é dispensável (à direita) em se A

e o conjunto (F – { }) { ( – A)} implica F.

Nota: a implicação na direcção oposta é trivial em ambos os casos (uma dependência mais forte, implica sempre uma mais fraca)

Exemplo: Dado F = {A C, AB C } B é dispensável em AB C porque A C implica

AB C. Exemplo: Dado F = {A C, AB CD}

C é dispensável em AB CD pois com A C, AB CD pode ser inferido de AB D


Teste para atributos dispensáveisTeste para atributos dispensáveis

Considere o conjunto F de dependências, e a dependência F. Para testar se A é dispensável em

1. calcular ({} – A)+ usando as dependências em F

2. verificar se ({} – A)+ contém A; se contém, então A é dispensável

Para testar se A é dispensável em

1. calcular + usando as dependências em F’ = (F – { }) { ( – A)},

2. verificar se + contém A; se contém, então A é dispensável


Cobertura CanónicaCobertura Canónica

Uma cobertura canónica de F é um conjunto de dependências Fc tal que F implica todas as dependências em Fc, e

Fc implica todas as dependências em F, e

Nenhuma dependência em Fc contém atributos dispensáveis, e

O lado esquerdo de cada dependência em Fc é único.

Para calcular uma cobertura canónica de F:Repetir

Usar a regra da união para substituir as dependências em F 1 1 e 1 1 por 1 1 2 Encontrar dependência com atributo dispensável (em ou )

Quando se encontra atributo dispensável, apaga-se de Até F não mudar

Nota: A regra da união pode tornar-se aplicável depois de retirados alguns atributos dispensáveis. Por isso há que reaplicá-la


Exemplo de cálculo de cobertura canónicaExemplo de cálculo de cobertura canónica

R = (A, B, C)F = {A BC

B C A BAB C}

Combinar A BC e A B para A BC Agora o conjunto é {A BC, B C, AB C}

A é dispensável em AB C porque B C implica AB C. Agora o conjunto é {A BC, B C}

C é dispensável em A BC pois A BC é implicado por A B e B C.

A cobertura canónica é:A BB C

©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts Capítulo 7: Design de...

Documents

Transcript of ©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts Capítulo 7: Design de...