Download - Capítulo 7: Design de Bases de Dados
©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
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
©Silberschatz, Korth and Sudarshan (modificado)7.1.2Database System Concepts
1ª Forma Normal1ª Forma Normal
Um esquema R diz-se na 1ª forma normal se os domínios de todos os seus atributos são atómicos.
Uma domínio é atomico se os seus elementos forem unidades indivisíveis. Exemplo de domínios não atómicos:
Conjuntos (e.g. de nomes), atributos compostos (e.g. com nome de rua, nº de porta, código postal e localidade)
Identificações com partes distintas (e.g. nº de carta de condução E-111222-5, nº de BI com último dígito)
Os valores não atómicos complicam o armazenamento e encorajam repetições desnecessárias de dados.
Daqui para a frente, assumiremos que todas os esquemas de relações estão já na 1ª Forma Normal.
©Silberschatz, Korth and Sudarshan (modificado)7.1.3Database 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.4Database System Concepts
ExemploExemplo
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.5Database 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.6Database 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.7Database 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.8Database 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
r
nome
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.9Database 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.10Database 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.11Database 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.12Database 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.13Database System Concepts
Dependências Funcionais (Cont.)Dependências Funcionais (Cont.)
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.14Database 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.15Database 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.16Database 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 deCG H inferindo CGI HI, e depois transitividade
©Silberschatz, Korth and Sudarshan (modificado)7.1.17Database System Concepts
Construção de FConstrução de F++
Para calcular o fecho de um conjunto de dependências F:
F+ = Frepeat
for each dependência funcional f F+
aplicar reflexividade e aumento em f adicionar os resultados a F+
for each par de dependências f1e f2 F+
if f1 e f2 podem combinar-se para usar transitividade
then adicionar a dependência resultado a F+
until F+ não mudar mais
NOTA: Veremos, mais tarde, outro procedimento para esta problema
©Silberschatz, Korth and Sudarshan (modificado)7.1.18Database 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.19Database 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 := ;while (mudança em result) do
for each in F dobegin
if result then result := result end
©Silberschatz, Korth and Sudarshan (modificado)7.1.20Database 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 = 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?
©Silberschatz, Korth and Sudarshan (modificado)7.1.21Database 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.22Database System Concepts
Cobertura CanónicaCobertura Canónica
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}
Intuitivamente, uma cobertura canónica de F é um conjunto “minimal” de dependências, equivalente a F, e em que nenhuma dependência tem partes redundantes
©Silberschatz, Korth and Sudarshan (modificado)7.1.23Database 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.24Database 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.25Database 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:repeat
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 until F não muda
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.26Database 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