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

Apresentação em tema: "©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts Capítulo 7: Design de Bases de Dados Objectivos com Design de Bases de Dados."— Transcrição da apresentação:

1 ©Silberschatz, Korth and Sudarshan (modificado)7.1.1Database System Concepts Capí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

2 ©Silberschatz, Korth and Sudarshan (modificado)7.1.2Database System Concepts Objectivos 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.

3 ©Silberschatz, Korth and Sudarshan (modificado)7.1.3Database System Concepts Exemplo 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 Maria João Pedro Ana telef. 1111 2222 1112 3333 CPostal 2815 1000 1100 2815 localidade Caparica Lisboa Caparica

4 ©Silberschatz, Korth and Sudarshan (modificado)7.1.4Database System ConceptsDecomposiçã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 (R 1, R 2 ): R = R 1  R 2 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.

5 ©Silberschatz, Korth and Sudarshan (modificado)7.1.5Database System Concepts Exemplo de decomposição sem perdas Decomposição de Amigos em Amigos1 e CPs:  Amigos1 ( r )  CPS ( r ) = r r nome Maria João Pedro Ana telef. 1111 2222 1112 3333 CPostal 2815 1000 1100 2815 localidade Caparica Lisboa Caparica  Amigos1 (r) nome Maria João Pedro Ana telef. 1111 2222 1112 3333 CPostal 2815 1000 1100 2815  CPs (r) CPostal 2815 1000 1100 localidade Caparica Lisboa

6 ©Silberschatz, Korth and Sudarshan (modificado)7.1.6Database System Concepts Exemplo de decomposição com perdas Decomposição de CPs em:  CP1 = (código_postal) e Locs = (localidade) r CPostal 2815 1000 1100 localidade Caparica Lisboa  Amigos1 ( r )  CPS ( r ) CPostal 2815 1000 1100 localidade Caparica Lisboa Caparica Lisboa Caparica Lisboa  CP1 (r) CPostal 2815 1000 1100  Locs (r) localidade Caparica Lisboa ≠ 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.

7 ©Silberschatz, Korth and Sudarshan (modificado)7.1.7Database System Concepts Outro exemplo com perdas Decomposição de Amigos em:  Amigos2 = (nome,telefone,localidade) e Loc = (localidade,código_postal). nome Maria João Pedro Ana telef. 1111 2222 1112 3333 localidade Caparica Lisboa Caparica  Amigos2 (r) CPostal 2815 1000 1100 localidade Caparica Lisboa  Loc (r) nome Maria João Pedro Ana telef. 1111 2222 1112 3333 CPostal 2815 1000 1100 2815 localidade Caparica Lisboa Caparica r nome Maria João Pedro Ana telef. 1111 2222 1112 3333 CPostal 2815 1000 1100 1000 1100 2815 localidade Caparica Lisboa 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.

8 ©Silberschatz, Korth and Sudarshan (modificado)7.1.8Database System Concepts Objectivo: 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 {R 1, R 2,..., R n } tal que:  cada um deles está num “bom” formato  A decomposição é sem perdas A teoria é baseada em  Dependências funcionais  Dependências multivalor

9 ©Silberschatz, Korth and Sudarshan (modificado)7.1.9Database System Concepts Dependê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.

10 ©Silberschatz, Korth and Sudarshan (modificado)7.1.10Database System Concepts 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 t 1 e t 2 de r têm os mesmos valores em , também têm os mesmos valores em  :  t 1,t 2  r, t 1 [  ] = t 2 [  ]  t 1 [  ] = t 2 [  ] 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 é. 14 1 5 37 A B

11 ©Silberschatz, Korth and Sudarshan (modificado)7.1.11Database System Concepts 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   

12 ©Silberschatz, Korth and Sudarshan (modificado)7.1.12Database System Concepts Dependê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  amount loan-number  branch-name mas não se espera que a dependência abaixo seja verdadeira: loan-number  customer-name

13 ©Silberschatz, Korth and Sudarshan (modificado)7.1.13Database System Concepts Uso 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.

14 ©Silberschatz, Korth and Sudarshan (modificado)7.1.14Database System Concepts Fecho de um Conjunto de Dependê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 + ).

15 ©Silberschatz, Korth and Sudarshan (modificado)7.1.15Database System ConceptsExemplo R = (A, B, C, G, H, I) F = { A  B A  C CG  H CG  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

16 ©Silberschatz, Korth and Sudarshan (modificado)7.1.16Database System Concepts Construção de F + Para calcular o fecho de um conjunto de dependências F: F + = F Repetir Para cada dependência funcional f  F + aplicar reflexividade e aumento em f adicionar os resultados a F + Para cada par de dependências f 1 e f 2  F + Se f 1 e f 2 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

17 ©Silberschatz, Korth and Sudarshan (modificado)7.1.17Database System Concepts 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.

18 ©Silberschatz, Korth and Sudarshan (modificado)7.1.18Database System Concepts Fecho 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

19 ©Silberschatz, Korth and Sudarshan (modificado)7.1.19Database System Concepts Exemplo de fecho de atributos R = (A, B, C, G, H, I) F = {A  B A  C CG  H CG  I B  H} (AG) + 1.result = AG 2.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?

20 ©Silberschatz, Korth and Sudarshan (modificado)7.1.20Database System Concepts Uso 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.

21 ©Silberschatz, Korth and Sudarshan (modificado)7.1.21Database System Concepts Coberturas 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

22 ©Silberschatz, Korth and Sudarshan (modificado)7.1.22Database System Concepts Atributos 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

23 ©Silberschatz, Korth and Sudarshan (modificado)7.1.23Database System Concepts Teste 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

24 ©Silberschatz, Korth and Sudarshan (modificado)7.1.24Database System Concepts Cobertura Canónica Uma cobertura canónica de F é um conjunto de dependências F c tal que  F implica todas as dependências em F c, e  F c implica todas as dependências em F, e  Nenhuma dependência em F c contém atributos dispensáveis, e  O lado esquerdo de cada dependência em F c é ú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

25 ©Silberschatz, Korth and Sudarshan (modificado)7.1.25Database System Concepts Exemplo de cálculo de cobertura canónica R = (A, B, C) F = {A  BC B  C A  B AB  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  B B  C