Download Acetatos - centria

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
Database System Concepts
7.3.1
©Silberschatz, Korth and Sudarshan (modificado)
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.
Database System Concepts
7.3.2
©Silberschatz, Korth and Sudarshan (modificado)
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.
Database System Concepts
7.3.3
©Silberschatz, Korth and Sudarshan (modificado)
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
Database System Concepts
7.3.4
©Silberschatz, Korth and Sudarshan (modificado)
3NF (Cont.)
 Exemplo
 R = (J, K, L)
F = {JK  L, L  K}
 Duas chaves candidatas: JK e JL
 R está na 3NF
JK  L
LK
JK é superchave
K 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
Redundante
Database System Concepts
7.3.5
J
L
K
1
a
x
2
a
x
3
a
x
4
b
y
©Silberschatz, Korth and Sudarshan (modificado)
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
Database System Concepts
7.3.6
©Silberschatz, Korth and Sudarshan (modificado)
Algoritmo de Decomposição para 3NF
Seja Fc uma cobertura canónica de F;
i := 0;
for each     Fc do
if nenhum dos esquemas Rj, 1  j  i contém  
then begin
i := i + 1;
Ri :=  
end
if nenhum dos esquemas Rj, 1  j  i contém uma chave
candidata de R
then begin
i := i + 1;
Ri := uma (qualquer) chave candidata de R;
end
return (R1, R2, ..., Ri)
Database System Concepts
7.3.7
©Silberschatz, Korth and Sudarshan (modificado)
Exemplo
 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.
Database System Concepts
7.3.8
©Silberschatz, Korth and Sudarshan (modificado)
Propriedade do algoritmo de Decomposição
 O algoritmo descrito garante que:
 Todo o esquema Ri está na 3NF
 A decomposição preserva as dependências e é sem perdas
Database System Concepts
7.3.9
©Silberschatz, Korth and Sudarshan (modificado)
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!!
Database System Concepts
7.3.10
©Silberschatz, Korth and Sudarshan (modificado)
BCNF versus 3NF (Cont.)
 Exemplo de problemas causados pela redundância na 3NF
 R = (J, K, L)
F = {JK  L, L  K}
J
L
K
j1
l1
k1
j2
l1
k1
j3
l1
k1
null
l2
k2
R, que está na 3NF mas não na BCNF, tem problemas de:
 Repetição de informação (e.g., relação l1, k1)
 Necessita usar valores null (e.g., para representar a relação
entre l2, k2 sem que haja valores correspondente em J).
Database System Concepts
7.3.11
©Silberschatz, Korth and Sudarshan (modificado)
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ão cliente gestor
Dados redundantes
Database System Concepts
Lx
Cp
Lx
Lx
Cp
Maria
Maria
Pedro
José
null
7.3.12
Ana
João
Ana
Ana
Mario
Necessidade de null
para associar gestores
(ainda) sem clientes, a
balcões
©Silberschatz, Korth and Sudarshan (modificado)
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.
Database System Concepts
7.3.13
©Silberschatz, Korth and Sudarshan (modificado)
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
   Fc 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
Database System Concepts
7.3.14
©Silberschatz, Korth and Sudarshan (modificado)