Roteiro do curso Informações sobre a BVS Bases de Dados Bibliográficas Pesquisas nas Bases de Dados.
©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts Capítulo 7: Design de...
-
Upload
giovanna-bandeira-alvares -
Category
Documents
-
view
227 -
download
1
Transcript of ©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
©Silberschatz, Korth and Sudarshan (modificado)7.1.2Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.3Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.4Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.5Database System Concepts
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
CaparicaLisboaLisboa
Caparica
Amigos1(r)
nome
MariaJoãoPedroAna
telef.
1111222211123333
CPostal
2815100011002815
CPs(r)
CPostal
281510001100
localidade
CaparicaLisboaLisboa
©Silberschatz, Korth and Sudarshan (modificado)7.1.6Database System Concepts
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
CaparicaLisboaLisboa
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.7Database System Concepts
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
CaparicaLisboaLisboa
Caparica
Amigos2(r)CPostal
281510001100
localidade
CaparicaLisboaLisboa
Loc(r)
nome
MariaJoãoPedroAna
telef.
1111222211123333
CPostal
2815100011002815
localidade
CaparicaLisboaLisboa
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.8Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.9Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.10Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.11Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.12Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.13Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.14Database System Concepts
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+).
©Silberschatz, Korth and Sudarshan (modificado)7.1.15Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.16Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.17Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.18Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.19Database System Concepts
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?
©Silberschatz, Korth and Sudarshan (modificado)7.1.20Database System Concepts
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.
©Silberschatz, Korth and Sudarshan (modificado)7.1.21Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.22Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.23Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.24Database System Concepts
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.25Database System Concepts
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