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

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

1 ©Silberschatz, Korth and Sudarshan (modificado)7.3.1Database System Concepts Capítulo 7: Design de Bases de Dados 1ª Forma Normal Objectivos com Design de Bases de Dados Dependências funcionais 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.3.2Database System Concepts Motivação para a 3ª Forma Normal Há situações em que:  a BCNF não preserva as dependências, e  a eficiência na verificação de integridade aquando de alterações é importante Solução: definir uma forma normal mais fraca – 3ª Forma Normal:  Admite alguma redundância (o que pode trazer problemas, como veremos à frente)  Mas as dependências podem ser verificadas sem recorrer a junções.  É sempre possível fazer uma decomposição sem perdas para a 3NF, que preserva as dependências.

3 ©Silberschatz, Korth and Sudarshan (modificado)7.3.3Database System Concepts Exemplo Motivador O esquema Gestores = (balcão, cliente, gestor-conta), com as dependências: 1. gestor-conta  balcão 2. cliente, balcão  gestor-conta não estava na BCNF por causa da primeira dependência. A única chave canditada de Gestores é {cliente, balcão}. Mas:  Ao decompor Gestores com base na 1ª dependência, balcão vai ficar numa relação diferente daquela onde fica cliente.  Logo deixa de ser possível verificar a chave candidata de Gestores numa só relação! Solução:  Para se continuar a poder verificar a chave candidata da relação original, não decompor um esquema com base numa dependência que à direita contenha apenas alguns dos atributos duma chave candidata.

4 ©Silberschatz, Korth and Sudarshan (modificado)7.3.4Database System Concepts 3ª Forma Normal Um esquema R está na 3ª Forma Normal (3NF) sse para toda:     F + pelo menos uma das condições é verdadeira:     é trivial (i.e.,    )   é superchave de R (i.e.,   R)  Todo atributo A  (  –  ) está contido numa chave candidata de R. (NOTE: cada um dos atributos pode pertencer a uma chave candidata distinta) Se R está na BCNF então está também na 3NF A 3ª condição relaxa a BCNF para garantir a preservação de dependências

5 ©Silberschatz, Korth and Sudarshan (modificado)7.3.5Database System Concepts 3NF (Cont.) Exemplo  R = (J, K, L) F = {JK  L, L  K}  Duas chaves candidatas: JK e JL  R está na 3NF JK  LJK é superchave L  KK está contido numa chave candidata Decomposição BCNF dá (JL) e (LK) Testar JK  L obriga a uma junção Pode haver redundância em R J 12341234 L aaabaaab K xxxyxxxy Redundante

6 ©Silberschatz, Korth and Sudarshan (modificado)7.3.6Database System Concepts Teste para 3NF Optimização: Basta verificar para uma cobertura canónica de F (não é necessário verificar para toda a dependência em F + ) Usar fecho de atributos para verificar, em toda a dependência   , se  é superchave. Se  não for superchave, há que verificar se todo a atributo em  pertence a alguma chave candidata de R  Este teste é bastante ineficiente, pois envolve o cálculo de chaves candidatas  Pode demonstrar-se que verificar se um conjunto de esquemas está na 3NF tem complexidade NP-hard  No entanto, a decomposição para a 3NF (descrita à frente) pode ser feita em tempo polinomial

7 ©Silberschatz, Korth and Sudarshan (modificado)7.3.7Database System Concepts Algoritmo de Decomposição para 3NF Seja F c uma cobertura canónica de F; i := 0; for each     F c do if nenhum dos esquemas R j, 1  j  i contém   then begin i := i + 1; R i :=   end if nenhum dos esquemas R j, 1  j  i contém uma chave candidata de R then begin i := i + 1; R i := uma (qualquer) chave candidata de R; end return (R 1, R 2,..., R i )

8 ©Silberschatz, Korth and Sudarshan (modificado)7.3.8Database System ConceptsExemplo Considere o esquema: Info-Gestores = (balcão, cliente, gestor-conta, gabinete) As dependências definidas sobre este esquema são: gestor-conta  balcão, gabinete cliente, balcão  gestor-conta A chave candidata é: {cliente, balcão} O ciclo for do algoritmo, leva à introdução dos seguintes esquemas na decomposição: Gestores-gab = (gestor-conta, balcão, gabinete) Gestores = (cliente, balcão, gestor-conta) Como Gestores contém uma chave candidata de Info-Gestores, o processo de decomposição termina.

9 ©Silberschatz, Korth and Sudarshan (modificado)7.3.9Database System Concepts Propriedade do algoritmo de Decomposição O algoritmo descrito garante que:  Todo o esquema R i está na 3NF  A decomposição preserva as dependências e é sem perdas

10 ©Silberschatz, Korth and Sudarshan (modificado)7.3.10Database System Concepts BCNF versus 3NF É sempre possível decompor um esquema, num conjunto de esquemas na 3NF em que:  a decomposição é sem perdas  as dependências são preservadas  Mas pode haver alguma redundância!! É sempre possível decompor um esquema, num conjunto de esquemas na BCNF em que  a decomposição é sem perdas  não há redundância  Mas nem sempre se podem preservar as dependências!!

11 ©Silberschatz, Korth and Sudarshan (modificado)7.3.11Database System Concepts BCNF versus 3NF (Cont.) J j 1 j 2 j 3 null L l1l1l1l2l1l1l1l2 K k1k1k1k2k1k1k1k2 R, que está na 3NF mas não na BCNF, tem problemas de: Repetição de informação (e.g., relação l 1, k 1 ) Necessita usar valores null (e.g., para representar a relação entre l 2, k 2 sem que haja valores correspondente em J). Exemplo de problemas causados pela redundância na 3NF  R = (J, K, L) F = {JK  L, L  K}

12 ©Silberschatz, Korth and Sudarshan (modificado)7.3.12Database System Concepts BCNF versus 3NF (exemplo) Considere o esquema Gestores = (balcão, cliente, gestor), com as dependências: 1. gestor  balcão 2. cliente, balcão  gestor Está na 3NF  {cliente, balcão} é chave de Gestores  {balcão} – {gestor} = {balcão}  na chave candidata de Gestores (que é {cliente, balcão}) balcãoclientegestor Lx Cp Lx Cp Maria Pedro José null Ana João Ana Mario Dados redundantesNecessidade de null para associar gestores (ainda) sem clientes, a balcões

13 ©Silberschatz, Korth and Sudarshan (modificado)7.3.13Database System Concepts BCNF ou 3NF? Objectivos do design, numa primeira fase:  BCNF.  Decomposição sem perdas.  Preservação de dependências. Se tal não for possível, então há que optar por uma de  Não preservação de dependências  Alguma redundância (devido ao uso da 3NF) O SQL não fornece nenhuma forma directa de impor dependências que não sejam superchaves. Pode fazer-se usando assertion mas isso é muito ineficiente.  Mesmo quando a decomposição preserva as dependências, com o SQL não é possível testar de forma eficiente dependências cujo lado esquerdo não seja chave.

14 ©Silberschatz, Korth and Sudarshan (modificado)7.3.14Database System Concepts Teste de Dependências em várias Relações Se a decomposição não preserva as dependências, podemos criar uma materialized view para cada uma das dependências    F c que não é preservada  O Oracle permite criar este tipo de views com o comando create materialized view A materialized view deve ser definida para a projecção em   da junção das relações decompostas. A dependência funcional deve ser imposta como chave candidata da materialized view. Isto implica um overhead de  espaço: há que guardar as views.  tempo: há que manter as views actualizadas