Você está na página 1de 45

CAPITULO 9

Vises
9.1 INTRODUO
Como explicamos no Captulo 3, uma viso essencialmente uma
expresso nomeada da lgebra relaciona! (ou algo equivalente
lgebra relacional). Por exemplo:
VAR BOM_FORNECEDOR VIEW
F WHERE STATUS > 15 ) { F#, STATUS, CIDADE
Quando essa instruo executada, a expresso da lgebra
relacional (isto , a expresso de definio de viso) no
avaliada, mas apenas lembrada pelo sistema na verdade,
gravando-a no catlogo sob o nome especificado
BOM_FORNECEDOR. Porm, para o usurio como se realmente
houvesse uma varivel de relao chamada BOM_FORNECEDOR no
banco de dados, com tuplas e atributos como mostram as partes
no sombreadas da Figura 9.1 ( claro que estamos supondo os
valores usuais da nossa amostra de dados). Em outras
palavras, o nome BOM_FORNECEDOR denota uma varivel de
relao derivada (e virtual), cujo valor em qualquer instante
a relao que resultaria se a expresso de definio da
viso fosse de fato avaliada nesse instante.
Tambm explicamos no Captulo 3 que uma viso como
BOM_FORNECEDOR na verdade apenas uma janela aberta para os
dados subjacentes: quaisquer mudanas nesse dados sero
automtica e instantaneamente visveis atravs da janela
(desde que, claro, essas mudanas estejam dentro do escopo
da viso); da mesma forma, atualizaes na viso sero
aplicadas automtica e instantaneamente aos dados subjacentes
e, portanto, estaro visveis atravs da janela.
FIGURA 9.1 BOM FORNECEDOR como uma viso da varivel de
relao bsica F (partes no sombreadas)
Dependendo das circunstncias, o usurio pode ou no perceber
que BOM_FORNECEDOR realmente uma viso; alguns usurios
poderiam ter conscincia disso e entender que h uma varivel
de re BOM_FORNECEDOR
FNOME STATUS CIDADE
Fi Smith 20 Londres
F2 Jones 10 Paris
F3 B1ak 30 Paris
F4 Clark 20 Londres
F5 Adains 30 Atenas
254
lao real F nos bastidores, outros poderiam acreditar
mesmo que BOM_FORNECEDOR uma varivel de relao real em
si. Em qualquer caso, isso faz pouca diferena: o importante
que os usurios possam operar sobre BOM_FORNECEDOR como se
ela fosse uma varivel de relao real. Por exemplo, uma
consulta sobre BOM_FORNECEDOR poderia ser:
BOM FORNECEDOR WHERE CIDADE Londres
Considerando-se a amostra de dados da Figura 9.1, o resultado
:
F# STATUS CIDADE
F3 30 Paris
F5 30 Atenas
A consulta certamente semelhante a uma consulta normal
sobre uma varivel de relao regular real e, como vimos no
Captulo 3, o sistema trata essa consulta convertendo-a em
uma consulta equivalente sobre a varivel de relao bsica
subjacente (ou variveis de relaes bsicas, no plural). Ela
faz isso substituindo efetivamente cada apario dentro da
consulta do nome da viso pela expresso que define a viso.
No exemplo, esse procedimento de substituio fornece:
F WHERE STATUS > 15 ) { F#, STATUS, CIDADE
WHERE CIDADE Londres'
que se percebe facilmente ser equivalente forma mais
simples:
F WHERE STATUS > 15 AND CIDADE `Londres
F#, STATUS, CIDADE
E essa consulta fornece o resultado mostrado antes.
A propsito, vale a pena observar que esse processo de
substituio isto , o processo de substituir o nome da viso
pela expresso que a define funciona exatamente devido
propriedade relacional de fechamento. O fechamento implica
(entre muitas outras coisas) que sempre que um nome R de
varivel de relao simples puder aparecer dentro de uma
expresso, uma expresso relacional de complexidade
arbitrria pode aparecer em seu lugar (desde que, claro,
essa expresso seja avaliada como uma relao do mesmo tipo
que R). Em outras palavras, as vises funcionam exatamente
devido ao fato de que relaes so fechadas sob a lgebra
relacional ainda outra ilustrao da importncia fundamental
da propriedade de fechamento.
As operaes de atualizao so tratadas de modo semelhante.
Por exemplo, a operao:
UPDATE BOM_FORNECEDOR WHERE CIDADE = Paris'
STATUS : STATUS + 10
efetivamente convertida em:
UPDATE F WHERE STATUS > 15 AND CIDADE = `Paris'
STATUS : STATUS + 10
As operaes INSERT e DELETE so tratadas de maneira anloga.
Exemplos adicionais
Nesta subseo, apresentaremos vrios outros exemplos, para
fins de referncia subsequente.
1. VAR PEA_VERMELHA VIEW
P WHERE COR = COR ( `Vermelho ) ) { ALL BUT COR )
RENAME PESO AS PS ; 255
A viso PEA_VERMELHA tem atributos P#, PNOME, PESO e CIDADE,
e contm tuplas somente para peas vermelhas.
2. VAR PQ VIEW
SUMMARIZE FP PER P { P# } ADD SUM ( QDE ) AS QDETOTAL
Diferente de BOM_FORNECEDOR e PEA_VERMELHA, a viso PQ no
apenas um subconjunto simplesisto , uma restrio e/ou
projeo de alguma varivel de relao bsica subjacente.
Ela pode ser considerada em vez disso uma espcie de resumo
estatstico ou compresso dessa varivel de relao
subjacente.
3. VAR CIDADE_PAR VIEW
F RENAME CIDADE AS FCIDADE ) JOIN FP JOIN
P RENAME CIDADE AS PCIDADE ) ) { FCIDADE, PCIDADE
Informalmente, um par de nomes de cidades (x,y) aparece na
viso CIDADE_PAR se e somente se um fornecedor localizado na
cidade x fornece uma pea armazenada na cidade y. Por
exemplo, o fornecedor F1 fornece a pea P1; o fornecedor Fi
est localizado em Londres e a pea P1 est armazenada em
Londres; assim, o par (Londres,Londres) aparece na viso.
4. VAR PEA_VERMELHA_PESADA VIEW
PEA_VERMELHA WHERE PS > PESO ( 12,0
Esse exemplo mostra uma viso definida em termos de outra.
Como definir e descartar vises
Aqui est ento a sintaxe para definir uma viso:
VAR <nome de varivel de relao> VIEW <expresso relacional>
<lista_com_vrgulas de chaves candidatas>
A <lista de definio de chaves candidatas> pode ser vazia,
porque o sistema deve ser capaz de inferir chaves candidatas
para vises [10.6]. Por exemplo, no caso de BOM_FORNECEDOR, o
sistema deve estar ciente de que a nica chave candidata
{F#}, herdada da varivel de relao bsica subjacente F.
Observamos que para usar a terminologia ANSI/SPARC do
Captulo 2 as definies de vises combinam (a) a funo de
esquema externo e (b) a funo de mapeamento
externo/conceitual, porque especificam (a) qual a aparncia
do objeto externo (isto , a viso) e (b) o modo como esse
objeto mapeado para o nvel conceitual ou seja, para a(s)
varivel(is) de relao(es) bsica(s) subjacente(s). Nota:
algumas definies de vises especificam no o mapeamento
externo/conceitual, mas sim um mapeamento externo/externo. A
viso PEA_VERMELHA_PESADA da subseo anterior um desses
casos.
A sintaxe para descartar uma viso :
DROP VAR <nome de varivel de relao>
onde, claro, o <nome de varivel de relao> se refere
especificamente a uma viso. Ora, no Captulo 5, supomos que
uma tentativa de descartar uma varivel de relao bsica
falharia se qualquer definio de viso referenciasse no
momento essa varivel de relao bsica. De modo anlogo,
supomos que uma tentativa de descartar uma viso tambm
falhar se alguma outra definio de viso se referir no
momento a essa viso. Uma alternativa (por analogia com
restries referenciais) seria considerarmos a possibilidade
de estender a declarao de definio de viso para incluir
algum tipo de opo RESTRICT versus CASCADE; RESTRICT (o
default) significaria que uma tentativa de descartar qualquer
varivel de relao referenciada na definio de viso deve
falhar; CASCADE significaria que uma tentativa desse tipo
deve ser bem-sucedida e deve se propagar at descartar
tambm a viso referente. Nota: a SQL admite essa opo, mas
a coloca na instruo DROP, e no na definio da viso. No
existe nenhum default a
256 opo exigida deve ser enunciada de forma explcita
(consulte a Seo 9.6).
9.2 PARA QUE SERVEM AS VISES
O suporte de vises desejvel por muitas razes. Aqui esto
algumas delas:
- As vises fornecem segurana automtica para dados ocultos
A expresso dados ocultos se refere aos dados no visveis
atravs de uma determinada viso (por exemplo, nomes de
fornecedores, no caso da viso BOM_FORNECEDOR). Esses dados
esto claramente seguros quanto ao acesso (pelo menos o
acesso para busca) atravs dessa viso particular. Assim,
forar usurios a acessar o banco de dados atravs de vises
um mecanismo simples mas eficiente de segurana. Falaremos
mais sobre esse uso especfico das vises no Captulo 16.
- As vises fornecem um recurso de abreviao ou de macro
Considere a consulta Obter cidades que armazenem peas que
estejam disponveis de algum fornecedor em Londres. Dada a
viso CIDADE_PAR da subseo Exemplos adicionais da seo
anterior, suficiente a formulao a seguir:
CIDADE_PAR WHERE FCIDADE = `Londres' ) { PCIDADE
Em contraste, sem a viso, a consulta muito mais complexa:
F RENAME CIDADE AS FCIDADE
JOIN FP
JOIN ( P RENAME CIDADE AS PCIDADE
WHERE FCIDADE = `Londres' ) { PCIDADE
Embora o usurio pudesse usar diretamente essa segunda
formulao se as restries de segurana a permitissem,
claro a primeira evidentemente mais simples. (E lgico que
a primeira na verdade apenas uma abreviao da segunda; o
mecanismo de processamento de vises do sistema efetivamente
expandir a primeira formulao na segunda, antes que esta
seja executada.)
Existe aqui uma forte analogia com macros em um sistema de
linguagem de programao. Em princpio, um usurio de um
sistema de linguagem de programao poderia escrever a forma
expandida de uma certa macro diretamente em seu cdigo-fonte
porm, muito mais conveniente (por uma variedade de razes
bem compreendidas) no faz-lo, mas sim usar a abreviao de
macro e deixar que o processador de macros do sistema faa a
expanso em favor do usurio. Observaes anlogas se aplicam
a vises. Assim, as vises em um sistema de banco de dados
desempenham papel anlogo ao de macros em um sistema de
linguagem de programao, e as bem conhecidas vantagens e os
benefcios das macros tambm se aplicam diretamente a vises,
mutatis mutandis. Em particular, observe que (como ocorre com
as macros) nenhum desperdcio de desempenho durante a
execuo est associado ao uso de vises ocorre apenas um
pequeno aumento do tempo de processamento da viso (anlogo
ao tempo de expanso da macro).
- As vises permitem que os mesmos dados sejam vistos por
usurios diferentes de modos diferentes ao mesmo tempo
As vises permitem efetivamente que os usurios se concentrem
apenas em e talvez reestruturem logicamente uma parte do
banco de dados que lhes interessa e ignorem o restante. Essa
considerao obviamente importante quando h muitos
usurios diferentes, com muitas exigncias diferentes, todos
interagindo ao mesmo tempo com um nico banco dc dados
integrado.
- As vises podem fornecer independncia de dados lgica
Esse um dos aspectos mais importantes. Veja a subseo
imediatamente a seguir.
257
Independncia de dados lgica
Lembramos que a independncia de dados lgica pode ser
definida como a imunidade de usurios e programas de usurios
a mudanas na estrutura lgica do banco de dados (onde
estrutura lgica se refere ao nvel conceitual ou da
comunidade lgica consulte o Captulo 2). Ento, claro
que as vises so o meio pelo qual a independncia de dados
lgica alcanada em um sistema relacional. H dois aspectos
da independncia de dados lgica, ou seja, o crescimento e a
reestruturao. Nota: discutimos o crescimento aqui mais por
completeza; embora seja importante, ele tem pouca relao com
as vises.
- Crescimento
medida que o banco de dados cresce para incurporar novas
espcies de informaes, a definio do banco dc dados tambm
deve crescer. Existem dois tipos possveis de crescimento que
podem ocorrer.
1. A expanso de uma varivel de relao bsica existente
para incluir um novo atributo, correspondendo adio de
novas informaes relativas a algum tipo de objeto existente
por exemplo, a adio de um atributo DESCONTO varivel de
relao bsica de fornecedores.
2. A incluso de uma nova varivel de relao bsica,
correspondendo adio de um novo tipo de objeto por
exemplo, a adio de informaes de projetos ao banco de
dados de fornecedores e peas.
Nenhuma dessas mudanas deve ter qualquer efeito sobre
usurios ou programas de usurios existentes, pelo menos em
princpio (mas veja o Exemplo 7.7.1 no Captulo 7 para
examinar uma advertncia relacionada especificamente SQL.
- Reestruturao
Ocasionalmente, pode se tornar necessrio reestruturar o
banco de dados de algum modo tal que, embora o contedo geral
de informaes permanea o mesmo, o posicionamento lgico de
informaes muda isto , a alocao de atributos a
variveis de relaes bsicas alterada de algum modo. Aqui,
consideramos apenas um exemplo simples. Suponha que por
alguma razo (a razo exata no importante para os nossos
fins) desejssemos substituir a varivel de relao bsica F
pelas duas variveis de relaes bsicas a seguir:
VAR FNC BASE RELATION { F# F#, FNOME NOME, CIDADE CHAR
PRIMARY KEY { F# } ;
VAR FT BASE RELATION { F# F#, STATUS INTEGER
PRIMARY KEY { F# } ;
O ponto crucial a observar que a varivel de relao antiga
F a juno das duas novas variveis de relaes FNC e FT (e
FNC e FT so ambas projees dessa antiga varivel de relao
F). Assim, criamos uma viso que exatamente essa juno e
lhe damos o nome F:
VAR F VIEW
FNC JOIN FT ;
Qualquer programa de aplicao ou operao interativa que
antes se referisse varivel de relao bsica F agora far
referncia viso F. Portanto desde que o sistema admita
corretamente operaes de manipulao de dados sobre vises
usurios e programas de usurios sero de fato logicamente
imunes a essa reestruturao do banco de dados em particular.
*
Em princpio! triste perceber que, em sua maioria, os
produtos de SQL de hoje (e o padro de SQL) no admitem
operaes de manipulao de dados sobre vises de forma
apropriada. Portanto, eles no oferecem o grau desejado de
imunidade a mudanas como o do exemplo. Para sermos mais
especficos, alguns produtos (no todos) aceitam corretamente
buscas sobre de vises, mas nenhum produto pelo menos de
que o autor tenha conhecimento admite atualizaes de
vises de modo 100% correto. Assim, alguns produtos fornecem
independncia de dados lgica total para operaes de busc2,
mas nenhum deles o faz
258 atualmente para operaes de atualizao.
Como um comentrio adicional, devemos mencionar que a
substituio da varivel de relao original de fornecedores
F por suas duas projees FNC e FT no totalmente trivial.
Em particular, observe que algo deve ser feito quanto
varivel de relao de remessas FP, pois essa varivel de
relao inclui uma chave estrangeira que referencia a
varivel de relao original de fornecedores. Veja o
Exerccio 9.13 no final do captulo.
Voltando ao fio principal da discusso: note que do exemplo
FNC-FT no se conclui que a independncia de dados lgica
pode ser alcanada para todas as reestruturaes possveis. A
questo crtica se existe um mapeamento sem ambiguidade da
verso reestruturada do banco de dados de volta verso
anterior (isto , se a reestruturao reversvel) ou, em
outras pala- vras, se as duas verses tm informaes
equivalentes. Caso contrrio, a independncia de dados lgica
claramente no alcanada.
Dois princpios importantes
A discusso anterior sobre a independncia de dados lgica
levanta outra questo. O fato que as vises servem na
realidade a dois propsitos bastante diferentes:
- Um usurio que realmente define uma viso V est,
obviamente, consciente da expresso X de definio de viso
correspondente; esse usurio pode empregar o nome V sempre
que a expresso X for mencionada, mas (como j vimos) esses
casos so basicamente apenas abreviaes.
- Por outro lado, um usurio que foi apenas informado de que
a viso V existe e est disponvel para uso em geral no est
consciente da expresso de definio de viso X; para esse
usurio, a viso V deve de fato parecer e se comportar
exatamente como uma varivel de relao bsica.
Seguindo o que foi dito, vamos enfatizar o fato de que a
dvida sobre quais variveis de relaes so bsicas e quais
so derivadas (isto , vises) em grande parte arbitrria!
Vamos examinar o caso das variveis de relaes F, FNC e FT
da discusso sobre reestruturao na subseo anterior.
Deve ficar claro que poderamos (a) definir F como uma
varivel de relao bsica, e FNC e FT como vises de
projeo dessa varivel de relao bsica, ou (b) definir FNC
e FT como variveis de relaes bsicas e F como uma viso de
juno dessas duas variveis de relaes bsicas. *
Conclumos que no deve existir nenhuma distino arbitrria
e desnecessria entre variveis de relaes bsicas e
derivadas. Mencionamos esse fato como O Princpio da
Permutabilidade (de variveis de relaes bsicas e
derivadas). Observe em particular que esse princpio implica
que devemos ser capazes de atualizar vises a possibilidade
de atualizao do banco de dados no deve depender da deciso
essencialmente arbitrria pela qual determinamos quais
variveis de relaes devem ser bsicas e quais devem ser
vises. Consulte a Seo 9.4 para ver uma discusso
adicional.
Vamos concordar por enquanto em nos referirmos ao conjunto de
todas as variveis de relaes bsicas como o banco de dados
real. Porm, um usurio tpico interage (em geral) no com
o banco de dados real em si, mas com o que se poderia chamar
um banco de dados expressvel, consistindo (de novo, em
geral) em alguma mistura de variveis de relaes bsicas e
vises. Agora, podemos supor que nenhuma das variveis de
relaes nesse banco de dados expressvel pode ser derivada
das restantes (porque essa varivel de relao poderia ser
descartada sem perda de informaes).** Ento, do ponto de
vista do usurio, essas variveis de relaes so todas
variveis de relaes bsicas, por definio! por certo
todas elas so independentes umas das outras (isto , so
todas autnomas, para usarmos a terminologia do Captulo 3).
O mesmo acontece no caso do prprio banco de dados ou seja,
a escolha de qual banco de dados o banco de dados real
arbitrria, pois as opes tm todas informaes
equivalentes. Vamos nos referir a esse fato como O Princpio
da Relatividade de Bancos de Dados.
*Veja a discusso sobre decomposio sem perdas no Captulo
11, Seo 11.2.
**Ignoramos aqui quaisquer vises definidas pelo usurio em
questo, pois j vimos que elas so na realidade simples
abrevia es 259
9.3 BUSCA EM VISES
J explicamos em linhas gerais como uma operao de busca em
uma viso convertida em uma opera- o equivalente sobre
a(s) varivel(is) de relao(es) bsica(s) subjacente(s).
Agora, vamos tornar nossa explicao um pouco mais formal,
como veremos adiante.
Primeiro, observe que qualquer expresso relacional dada pode
ser considerada uma funo com valor de relao: sendo dados
valores para as diversas variveis de relaes mencionadas na
expresso (representando os argumentos para essa invocao da
funo especfica), a expresso produz outra relao. Agora,
seja D um banco de dados (que, para nossos propsitos atuais,
vamos considerar apenas como um conjunto de variveis de
relaes bsicas) e seja Vuma viso sobre D, isto , uma
viso cuja expresso de definio X alguma funo em
V=X (O)
Seja R uma operao de busca sobre V: claro que R outra
funo com valor de relao, e o resultado da busca :
R ( v) =R (x (O))
Assim, o resultado da busca definido como igual ao
resultado da aplicao de X a D ou seja, a materializao
de uma cpia da relao que o valor atual da viso V e
depois da aplicao de R a essa varivel materializada.
Porm, na prtica quase certamente mais eficiente usar em
vez disso o procedimento de substituio, discutido na Seo
9.1 (e agora podemos ver que esse procedimento equivalente
a formar a funo C, que a composio R (X) das funes X e
R, nessa ordem, e depois aplicar C diretamente a D). Apesar
disso, conveniente, pelo menos em termos conceituais
definir a semntica da busca em vises em funo da
materializao, em vez da substituio; em outras palavras, a
substituio vlida desde que oferea a garantia de
produzir o mesmo resultado que seria produzido se a
materializao fosse usada em seu lugar (e claro que isso
garantido).
Agora, voc j deve estar familiarizado com a explicao dada
em nossas discusses anteriores. Vamos torn-la explcita
aqui pelas seguintes razes:
- Primeiro, ela constitui a base para uma discusso
semelhante (embora mais profunda) das operaes de
atualizao na Seo 9.4.
- Segundo, ela torna claro que a materializao uma tcnica
de implementao perfeitamente legtima de implementao de
vises (embora provavelmente um tanto ineficiente) pelo
menos
para operaes de busca. Porm, claro que ela no pode ser
usada para operaes de atualizao, porque toda a questo de
atualizar uma viso exatamente a de aplicar as atualizaes
s variveis de relaes bsicas subjacentes, no apenas a
alguma cpia temporariamente materializada dos dados. Mais
uma vez, consulte a Seo 9.4 a seguir.
- Terceiro, embora o procedimento de substituio seja
bastante direto e funcione perfeitamente bem na teoria em
100% dos casos, o fato triste que (no momento em que
escrevemos), existem
alguns produtos de SQL para os quais ele no funciona na
prtica! ou seja, h alguns produtos de SQL nos quais
algumas buscas sobre algumas vises falharo de forma
surpreendente. Ele tambm no funciona na prtica para
verses do padro SQL anteriores SQL/92. E a razo para as
falhas exatamente que os produtos em questo, e as verses
anteriores do padro SQL, no tm suporte completo para a
propriedade de fechamento relaciona!. Veja o Exerccio 9.14,
parte a. no final do captulo.
9.4 ATUALIZAES DE VISES
O problema de atualizao de vises pode ser informalmente
enunciado desta forma: dada uma atualiza260 o particular
sobre uma determinada viso, que atualizaes precisam ser
aplicadas a quais variveis de
relaes bsicas subjacentes para implementar a atualizao
da viso original? Mais precisamente, seja D um banco de
dados, seja Vuma viso sobre D, isto , uma viso cuja
definioX uma funo sobre D:
v=x (D)
( como na Seo 9.3). Agora, seja U uma operao de
atualizao sobre V; U pode ser considerada uma operao que
tem o efeito de alterar seu argumento, produzindo:
u( V) =u(x(D) )
o problema de atualizao de vises ento o problema de
encontrar uma operao dc atualizao LY sobre D tal que:
U(X) (D) ) =x(u' (O))
porque, naturalmente, D a nica coisa que realmente
existe (as vises so virtuais) e assim as atualiza- es
no podem ser implementadas diretamente em termos de vises
em si.
Antes de continuarmos, devemos enfatizar que o problema da
atualizao de vises foi tema de considervel pesquisa
durante muitos anos, e firam propostas muitas abordagens
diferentes para sua soluo (pelo autor deste livro, entre
outros); por exemplo, consulte as referncias [9.71, [9.10 a
9.131, [9.15] e, em particular, as propostas de Codd para o
RM/V2 [5.21. Neste captulo, descrevemos uma abordagem
relativamente nova [9.9], que menos ad hoc que algumas
propostas anteriores, mas tem a virtude de apresentar
compatibilidade ascendente com os melhores aspectos dessas
propostas. Ela tambm tem a virtude de tratar como
atualizvel uma classe muito mais ampla de vises que
abordagens anteriores; na verdade, ela trata todas as vises
como potencialmente atualizveis, impedindo violaes s
restries de integridade.
Revendo a Regra urea
Vamos relembrar A Regra urea do captulo anterior:
Nenhuma operao de atualizao deve ser permitida se puder
deixar qualquer varivel de relao em um estado que viole
seu prprio predicado.
Quando introduzimos pela primeira vez essa regra, enfatizamos
o fato de que ela se aplica a todas as variveis de relaes,
derivadas e bsicas. Em outras palavras, as variveis de
relaes derivadas tambm tm predicados como de fato
deveriam ter, em virtude do Princpio da Permutabilidade e
o sistema precisa saber quais desses predicados esto em
ordem para executar corretamente atualizaes de vises.
Ento, qual a aparncia de um predicado para uma viso? E
claro que precisamos de um conjunto de regras de inferncia
de predicados tais que, se soubermos o(s) predicado(s) para
a(s) entrada(s) de qualquer operao relacional, possamos
inferir o predicado correspondente sada dessa operao.
Sendo dado um tal conjunto de regras, seremos capazes de
inferir o predicado para uma viso do(s) predicado(s) da(s)
varivel (is) de relao(es) bsica(s) em cujos termos essa
viso direta ou indiretamente definida. (E claro que os
predicados para essas variveis de relaes bsicas j so
conhecidos: eles decorrem da operao lgica AND de quaisquer
restries de variveis de relaes por exemplo, restries
de chaves candidatas que tenham sido declaradas para a
varivel de relao bsica em questo.)
Na verdade, muito fcil encontrar um desses conjuntos de
regras eles resultam imediatamente das definies dos
operadores relacionais. Por exemplo, se A e B so duas
variveis de relaes quaisquer do mesmo tipo e seus
predicados respectivos so PA e PB e, se a viso C definida
como A INTERSECT B, ento o predicado PC para essa viso
obviamente (PA) AND (PB); ou seja, uma determinada tupla
aparecer em C se e somente se tornar PA e PB ambos
verdadeiros. Consideraremos os outros operadores relacionais
mais adiante nesta seo.
26)
predicado de varivel de relao, enquanto a operao UPDATE
geral no o faz. Por exemplo, suponha que a varivel de
relao R contm exatamente 10 tuplas, e considere o efeito
de UPDATE tupla t sobre R se o predicado de varivel de
relao de R afirma que R deve conter pelo menos 10 tuplas.
. Da mesma forma, procedimentos triggers nunca so executados
no meio de qualquer atualiza- o dada (na verdade, eles
so executados no final, pouco antes da verificao do
predicado da varivel de relao).
. A abreviao exige algum refinamento no caso de vises de
projeo (ver adiante nesta seo).
6. Todas as operaes de atualizao sobre vises devem ser
implementadas pelo mesmo tipo de operao de atualizao
sobre as variveis de relaes subjacentes. Isto , INSERTs
so mapeadas como INSERTs e DELETEs como DELETEs (podemos
ignorar UPDATEs, graas ao ponto anterior). Ao contrrio,
suponha que exista alguma espcie de viso digamos uma
viso de unio para a qual (digamos) INSERTs sejam mapeadas
como DELETEs. Ento, devemos concluir que INSERTs sobre uma
varivel de relao bsica tambm devem s vezes ser mapeadas
como DELETEs! Essa concluso decorre (como j observamos no
item 2 anterior) de ser a varivel de relao bsica B
semanticamente idntica viso de unio V = B UNION B. Um
argumento anlogo tambm se aplica a todos os outros tipos de
vises (restrio, projeo, interseo etc.). A idia de que
uma operao INSERT sobre uma varivel de relao bsica
possa na verdade ser uma operao DELETE parece ser
evidentemente absurda; da nossa posio de que (repetindo)
INSERTs so mapeadas como INSERTs e DELETEs como DELETEs.
7. De modo geral, as regras de atualizao, quando aplicadas
a uma determinada viso V especificaro as operaes que
devem ser aplicadas s variveis de relaes em cujos termos
V definida. Alm disso, essas regras devem funcionar
corretamente, mesmo quando essas variveis de relaes
subjacentes sejam elas prprias vises. Em outras palavras,
as regras devem poder ter aplica do recursiva. E claro que,
se uma tentativa de atualizar uma varivel de relao
subjacente falhar por alguma razo, a atualizao original
tambm falhar; ou seja, atualizaes sobre vises so tudo
ou nada, exatamente como atualizaes sobre variveis de
relaes bsicas.
8. As regras no podem pressupor que o banco de dados foi bem
projetado (por exemplo, completamente normalizado consulte
os Captulos 11 e 12). Porm, elas podem ocasionalmente
produzir um resultado um pouco surpreendente se o banco de
dados no tiver sido bem projetado um fato que pode ser
visto em si mesmo como um argumento adicional para apoiar um
bom projeto. Daremos um exemplo de um resultado um pouco
surpreendente na prxima subseo.
9. No deve haver nenhuma razo prima facie para permitir
algumas atualizaes e no outras (por exemplo, DELETEs mas
no INSERTs) sobre uma determinada viso.
10. Tanto quanto possvel, INSERT e DELETE deveriam ser
inversas uma da outra.
Lembramos ao leitor um outro principio importante: como foi
explicado no Captulo 5, as operaes relacionais
atualizaes relacionais em particular so sempre
realizadas em nvel de conjunto; um conjunto contendo uma
nica tupla apenas um caso especial. Mais ainda,
atualizaes de vrias tuplas so s vezes uma exigncia
(isto , algumas atualizaes no podem ser simuladas por uma
srie de operaes tupla a tupla). Essa observao
verdadeira tanto para variveis de relaes bsicas quanto
para vises, em geral. Para simplificar, estaremos
apresentando nossas regras de atualizao de vises em termos
de operaes tupla a tupla, mas voc no deve perder de vista
o fato de que considerar operaes tupla a tupla apenas uma
simplificao e, na verdade, uma simplificao excessiva em
certos casos.
Consideramos agora um a um os operadores da lgebra
relacional, comeando com unio, interseo e diferena.
Nota: em particular, nesses trs primeiros casos, vamos supor
que estamos lidando com uma viso cuja expresso de definio
tem a forma A UNION B ou A INTERSECT B ou A MINUS B (como
convier), onde A e B so por sua vez expresses relacionais
(isto , no so necessariamente variveis de relaes
bsicas). As relaes denotadas por A e B devem ser do mesmo
tipo de relao. Os predicados de variveis de relaes
correspondentes so PA e PB, respectivamente. 263
Unio
Aqui est ento a regra de INSERT para A UNION B:
. INSERT: a nova tupla deve satisfazer a PA ou a PB ou a
ambos. Se satisfizer a PA, ela ser inserida emA; note que
essa INSERT poderia ter o efeito colateral de inserir a tupla
tambm emB.* Se satisfizer a PB, ela ser inserida em B, a
menos que j tenha sido inserida em B como efeito colateral
de ter sido inserida em A.
Nota: o modo procedural especfico como essa regra foi
declarada (insira em A, depois insira em B) deve ser
entendido apenas como expediente pedaggico; ele no
significa que o SGBD deve realmente executar as operaes
INSERT em sequncia, conforme foi enunciado. De fato, o
princpio de simetria o Princpio Nmero 3 na subseo
imediatamente anterior implica isso, porque nem A nem B tem
prioridade uma sobre a outra. Observaes anlogas se aplicam
a muitas das regras que discutiremos a seguir.
Explicao: a nova tupla deve satisfazer pelo menos a um
predicado entre PA e PB, porque do contrrio no se
qualificaria para incluso em A UNION B isto , no iria
satisfazer ao predicado da varivel de relao, ou seja, (PA)
OR (PB), para A UNION B. (Supomos tambm, embora na verdade
essa suposio no seja estritamente necessria, que a nova
tupla no deve aparecer atualmente em A ou B pois, caso
contrrio, estaramos tentando inserir uma tupla que j
existe.) Considerando-se que as exigncias enunciadas sejam
satisfeitas, a nova tupla ser inserida em A ou em B, seja
qual for a varivel de relao a que ela logicamente pertena
(possivelmente em ambas).
Exemplos: seja a viso UV definida como:
VAR UV VIEW
F WHERE STATUS > 25 ) UNION ( F WHERE CIDADE = Paris
A Figura 9.2 mostra um valor possvel para essa viso,
correspondendo aos valores de dados de nossa amostra usual.
- Seja (F6,Smith,5O,Roma) a tupla a ser inserida.** Essa
tupla satisfaz ao predicado para F WHERE STATUS > 25, mas no
ao predicado para F WHERE CIDADE = `Paris'. Portanto, eia
inserida em F WHERE STATUS > 25. Devido s regras
relacionadas com INSERT em uma restrio (as quais so
bastante bvias veja mais adiante nesta seo), o efeito
o de inserir a nova tupla na varivel de relao bsica de
fornecedores, e ento fazer a tupla aparecer na viso como
desejado.
Varias regras e exemplos discutidos no texto a seguir se
referem possibilidade de efeitos colaterais. Ora, sabemos
muito bem que os efeitos colaterais so quase sempre
indesejveis; contudo, o que importa que os efeitos
colaterais podem ser inevitveis se A e B representam
subconjuntos sobrepostos da mesma variveis de relao
subjacente, como ocorrer com frequncia no caso de vises de
unio, interseo e diferena. Alm disso, os efeitos
colaterais em questo so (pelo menos dessa vez) desejveis,
e no-indesejveis.
264 ** Adotaremos essa notao simplificada para tuplas em
toda esta seo, por razes de legibilidade.
F 1 G U R A 9.2 A viso UV (amostras de valores)
. Agora seja (F7,Jones,5O,Paris) a tupla a ser inserida. Essa
tupla satisfaz ao predicado para F WHERE STATUS > 25 e ao
predicado para F WHERE CIDADE = `Paris'. Portanto, ela
logicamente inserida em ambas as restries. Contudo, inseri-
la em qualquer uma das duas restries tem o efeito colateral
de inseri-la na outra, de qualquer forma, de modo que no h
necessidade de executar explicitamente a segunda operao
INSERT.
Suponha agora que FA e FB so duas variveis de relaes
bsicas distintas, FA representando for- necedores com status
> 25 e FB representando fornecedores em Paris (ver Figura
9.3); suponha que a vi- so UV seja definida como FA UNION
FB, e considere novamente os dois exemplos de INSERT discuti-
dos antes. Inserir a tupla (F6,Smith,50,Roma) na viso UV
far com essa tupla seja inserida na varivel de relao
bsica FA, presumivelmente como se desejava. Porm, inserir a
tupla (F7,Jones,5O,Paris) na viso Uv far que essa tupla
seja inserida em ambas as variveis de relaes bsicas!
FA FB
F# FNOME STATUS CIDADE FNOME STATUS CIDADE
F3 Bi ake 30 Pari s F2 Jones 10 Paris
F5 Adams 30 Atenas F3 Blake 30 Paris
F 1 G U R A 9 . 3 Variveis de relaes bsicas FA e FB
(amostras de valores)
Esse resultado logicamente correto, embora se possa dizer
que ele no intuitivo ( um exemplo do que chamamos de
resultado um pouco surpreendente na subseo anterior).
Nossa posio que tais surpresas s podem ocorrer se o
banco de dados for mal projetado. Em particular, nossa
posio que um projeto que permite que a mesma tupla aparea
em isto , satisfaa ao predicado para duas variveis de
relaes bsicas distintas , por definio, um mau projeto.
Essa posio (talvez controvertida) elaborada no Captulo
12, Seo 12.6.
Agora vamos cuidar da regra DELETE para A UNION B:
- DELETE: se a tupla a ser removida aparecer em A, ela ser
removida de A (note que essa operao DELETE poderia ter o
efeito colateral de remover a tupla tambm de B). Se ela
(ainda) aparecer em B, ser eliminada de B.
Exemplos para ilustrar essa regra ficam como exerccio.
Observe que remover uma tupla de A ou B poderia causar uma
operao DELETE em cascata ou a execuo de algum outro
procedimento trigger.
Finalmente, a regra de UPDATE:
- UPDATE: a tupla a ser atualizada deve ser tal que a verso
atualizada satisfaa a PA ou a PB ou a ambos. Se a tupla a
ser atualizada aparecer emA, ela ser removida deA sem que
sejam executados quaisquer procedimentos triggers (DELETE em
cascata etc.) que essa operao DELETE normalmente causaria
e, do mesmo modo, sem verificar o predicado de varivel de
relao para A. Note que essa operao DELETE poderia ter o
efeito colateral de remover a tupla tambm de B. Se a tupla
(ainda) aparecer em B, ela ser removida de B (de novo sem a
execuo de quaisquer procedimentos triggers ou verificao
de predicados de variveis de relaes). Em seguida, se a
verso atualizada da tupla satisfizer a PA, ela ser inserida
em A (note que INSERT poderia ter o efeito colateral de
inserir a tupla tambm em B). Finalmente, se a verso
atualizada satisfizer a PB, ela ser inserida em B, a menos
que j tenha sido inserida em B como efeito colateral de
inseri-la em A.
Essa regra de UPDATE formada essencialmente pela regra de
DELETE seguida da regra de INSERT. Contudo (como j
indicamos) nenhum procedimento trigger ou verificao de
predicado executado depois de DELETE (quaisquer
procedimentos triggers associados com UPDATE so
conceitualmente executados, depois de todas as remoes e
inseres terem sido feitas, pouco antes das verifi cae de
predicados). 265
1
Vale a pena observar que uma importante consequncia de
tratar UPDATE dessa forma que uma determinada UPDATE pode
fazer uma tupla migrar de uma varivel de relao para outra,
em termos informais. Por exemplo, considerando-se o banco de
dados da Figura 9.3, a atualizao da tupla
(F5,Adams,30,Atenas), dentro da viso UV para
(F5,Adams,15,Paris), eliminar a tupla antiga para F5 de FA e
ir inserir a nova tupla para FS em FB.
Interseo
Agora, as regras para atualizar A 1NTERSECT B. Dessa vez,
damos as regras simplesmente, sem mais discusso (elas seguem
o mesmo padro geral que as regras para unio), exceto pela
observao de que o predicado para A INTERSECT B (PA) AND
(PB). Exemplos para ilustrar os vrios casos ficam como
exerccio.
. INSERT: a nova tupla deve satisfazer tanto a PA quanto a
PB. Se no aparecer atualmente em A, ela ser inserida emA
(note que essa INSERT poderia ter o efeito colateral de
inserir a tupla tambm em B). Se (ainda) no aparecer em B,
ela ser inserida em B.
. DELETE: a tupla a ser eliminada eliminada deA (note que
essa DELETE poderia ter o efeito de eliminar a tupla tambm
de B). Se (ainda) aparecer em B, ela ser eliminada de B.
- UPDATE: a tupla a ser atualizada deve ser tal que a verso
atualizada satisfaa tanto a PA quanto a PB. A tupla ser
eliminada de A, sem a execuo de qualquer procedimento
trigger ou verificao de predicado (note que essa DELETE
poderia ter o efeito colateral de eliminar a tupla de B); se
(ainda) aparecer em B, ela ser eliminada de B, de novo sem a
execuo de quaisquer procedimentos triggers ou verificaes
de predicados. Em seguida, se a verso atualizada da tupla
no aparecer no momento em A, ela ser inserida em A (note
que essa INSERT poderia ter o efeito colateral de inserir a
tupla tambm em B). Se (ainda) no aparecer em B, ela ser
inserida em B.
Diferena
Essas so as regras para atualizar A MINUS B (o predicado de
varivel de relao (PA) AND NOT (PB), claro):
- INSERT: a nova tupla deve satisfazer a PA e no a PB. Ela
inserida em A.
- DELETE: a tupla a ser eliminada ser removida de A.
- UPDATE: a tupla a ser atualizada deve ser tal que a verso
atualizada satisfaa a PA e no a PB. A tupla ser eliminada
de A sem a execuo de quaisquer procedimentos triggers ou
verificaes de predicados de variveis de relaes; a verso
atualizada ser ento inserida em A.
Restrio
Seja A WHERE p a expresso de definio para a viso V, e
seja PA o predicado de A. Ento, o predicado para V (PA)
AND (p). Por exemplo, o predicado para a restrio F WHERE
CIDADE = `Londres' (PF) AND (CIDADE = `Londres'), onde PF
o predicado para fornecedores. Ento, aqui esto as regras
para atualizao de A WHERE :
- INSERT: a nova tupla deve satisfazer tanto a PA quanto a p.
Ela ser inserida em A.
- DELETE: a tupla a ser eliminada ser eliminada de A.
- UPDATE: a tupla ser atualizada deve ser tal que a verso
atualizada satisfaa tanto a PA quanto p. A tupla ser
eliminada de A sem a execuo de quaisquer procedimentos
triggers ou verificaes de predicados. A verso atualizada
ser ento inserida em A.
Exemplos: seja a viso LF definida como:
VAR LF VIEW
F WHERE CIDADE = `Londres
A Figura 9.4 exibe uma amostra de valores para essa viso.
266
L9i .J p oe3ipi p 1AVIJEA Up o3uijp ru (, iuvuu
`o snivis) rinvia Ju3!jpds sotuiipod `oTduix d <i1nvJp>
<oinqzw p auiou> rw.io; w <nvJp op3v7zJz'
-acjs> pU: puo `sowvip `(<j;nvJap opviJiads ap
sv1nFfu4o3vsq>) `DTsq o5epi p pATflA p o5iui;p eu tjnsnp
IAOU EUJfl p vuuo iVWO eiipod rpnbpt a IcTJon1 p xuuTs sijsq
s3rpi p STACUEA p sonquie
tud jnp SIOIA JED!JDdS PJU0dS!P OiUT UJfl 1SIX (ibs w ouioD)
nb opuodns somus `sei; ss rDTIdwJ owo
-J!ns I rbA ILVUdQ P OS3 OU uiqmi wrDijd s so1
-u sg5AJsq pi Du!x `- OSS!p 1ZJ id DT9j OZJ 1UJflqUU q ou
`opnuo .v p c1dn wn uuex puodsJJoD {x}v p pTAOUTJ is i 1dni
nb opow op p pIpuED AUD Wfl SOUUJ opd npuTXnb pASp is
uuimiou `DuJd u :vzo
.v p srpu!w!p
oJs {x}V P pu!w!p Js Ejdrn nb x JOjIA omsu o uio v p stjdni
s spo :jjj3u -
-sJ:aIsNI viuuuid ou w uo3rqns o3p.i p {ALA tp SpipUD SA
-fl{D S srpoi 1PU! ou nb o5Iod ewn `rnunbsuoD w (gj ondj o
jnsuo) jnjp iii
-nquu oJ Ou `iduis uu oqtu `uuiuuuou srnp!puD SA1D p sonqu
:VON
-v w pTJsu! (v
1zUJs!s nb) (i('x) 1dn y (sopnTwJd ou sqnjp ,, JA! S ` OSi
`njp IOJA III
-nquu 1flS!X OU S Ofl um ) p incjp 1O1A O iC s rpusui is jdn
t (x) bs - :{X}V WZTjfl EJd sr os TnbV
o3eji p pATJeA e eied opeDTpld oe zeJsies (`u'J) ejdn e nb
jei 1 snes p JOjA mn asTx nb o5Ioid essu uiede nb (`u'J)
eldrn epoj vui ]NONI `j iqos j o3ep.i P PAA
ep oe5Ioid e JpIsuoD `o1dwx 10d Vc1 e ze;sues {1C:'x:X} e1dn
e nb sT1 p SIOjA p O!UJWOp op iC JOjA mnje 1uweDiSeq o3oid
essa eied ope3!pd o nb oep ies `o.iu oe5[oid
essp ejdn ewn {x:X} {x}v `x iqos v p o3Ioid e JpTsuoD `um epe
osodmoz oinque oiui wn ouio Jpisuo souIeTp `soiun[sTp sodn
sTop m sopeuo!DuJed (v opeDTpJd o moD) v oe5ejj p ep soinque
so mebs ueApi opeDTpJd o .iepisuo od SOme3uiOD UUJAON
o3fo
ose epe tu `iuujeiex `nb od) eJeqe; no
eed e1dn emsm essa ezqerne p eueu em epipDns-wJq
eis eed e1dn e ezqene p eAueua eui -
fl 0STA ep epeuiuJJ{ iuueup mquiei `oueod ` j o3epi P PA!1eA
ep epeu!uJip is e1dn v epTpDns-u.iq is j' p (sipuo'o'qw.us'j)
e1dn e .Jeuuuip p eAi1e1u1 ew .
SJpUO, = IUVUID
o5iusi e ejo!A nbiod eqjej j'j w (seu v'oz'uJo'9I) ejdn e
iusui p eAUeIUai em -
{#i} elepipueD e eied pepTDiun p o3uis e e{oiA ep `
(mqwe j- eied oiueiod ) j o5epi p PA!Je e eied o5epi p PA!
Je1 p opeDTpJd o ejo nbiod ieqe; j' m (sJpuo'J'oz'uJ9'TJ)
ejdrn e usui p eAi1eua1 eui -
OSTA eu epLIJSU! uueAuJ is mquie `oueiod ` o3epi p piie eu
ep!JSU! is e1dn eAou v epipDns-mq is j ui (sJpuo'oz'uJo'9)
ejdn e iusui p eATeu1 eui -
(sa.so1va ap srnisou4v) [7 os!a v f7 6 V 1 fl J 1 1
sapuoi o td
SAPUO1 O Lfl.IUIS IJ
OVOID SflIVIS ]NONd #J
-11
- UPDATE: seja (x) a tupla a ser atualizada e seja (x') a
verso atualizada. Seja a uma tupla de A com o mesmo valor x
de X, e seja y o valor de Y em a. Todas essas tuplas a sero
eliminadas de A sem a execuo de quaisquer procedimentos
triggers ou verificaes de predicados de variveis de
relaes. Ento, para cada valor y, a tupla (x',y) (que deve
satisfazer a PA) ser inserida em A.
Nota: aqui que se mostra o ligeiro refinamento a respeito
da projeo mencionado no Princpio Nmero 5 na subseo Na
direo de um mecanismo de atualizao de vises.
Especificamente, observe que o passo INSERT final na regra
de UPDATE restaura o valor de Y anterior em cada tupla
inserida ele no o substitui pelo valor default aplicvel,
como faria uma operao INSERT isolada.
Exemplos: seja a viso FC definida como:
FC { F#, CIDADE
A Figura 9.5 apresenta uma amostra de valores para essa
viso.
FIGURA 9.5 A viso FC (amostras de valores)
- Uma tentativa de inserir a tupla (F6,Atenas) em FC ser
bem-sucedida e ter o efeito de inserir a tupla
(F6,n,t,Londres) na varivel de relao F, onde n e t so os
valores default para os atributos FNOME e STATUS,
respectivamente.
- Uma tentativa de inserir a tupla (F 1 ,Atenas) em FC
falhar porque viola o predicado de varivel de relao para
a varivel de relao F (e, portanto, tambm para FC)
especificamente, ela viola a restrio de unicidade para
chave candidata {F#}.
- Uma tentativa de eliminar a tupla (F1,Londres) de FC ser
bem-sucedida. A tupla para Fi ser removida da varivel de
relao F.
- Uma tentativa de atualizar a tupla FC (F1,Londres) para
(F1,Atenas) ser bem-sucedida; o efeito ser o de substituir
a tupla (F1,Smith,20,Londres) na varivel de relao F pela
tupla (F1,Smith,20,Atenas) e no pela tupla
(F1,n,t,Atenas), onde n e t so os default aplicveis.
- Uma tentativa de atualizar a mesma tupla FC (F1,Londres)
para (F2,Londres) falhar (por que exatamente?).
Deixamos como exerccio a considerao do caso em que a
projeo no inclui uma chave candidata da varivel de
relao subjacente por exemplo, a projeo da varivel de
relao F sobre STATUS e
CIDADE.
Extenso
Seja a expresso de definio para a viso V
EXTEND A ADD exp AS X
(onde, como sempre, o predicado para A PA). Ento, o
predicado PE para V :
268PA (a ) AND e.X = exp (a )
FC
F# CIDADE
Fi Londres
F2 Paris
F3 Paris
F4 Londres
F5 Atenas
Aqui, e uma tupla de V e a a tupla que permanece quando o
componente X de e removido (isto , a a projeo de e
sobre todos os atributos de A, falando-se em termos
informais). Em linguagem natural (e formal):
Toda tupla e na extenso tal que (1) a tupla a que
derivada de e por projeo do componente X satisfaz a PA, e
(2) esse componente X tem o valor igual ao resultado da
aplicao da expresso exp a essa tupla a. Ento, aqui esto
as regras de atualizao:
- INSERT: seja e a tupla a ser inserida: e deve satisfazer a
PE. A tupla a que derivada de e por projeo do componente
X inserida em A.
- DELETE: seja e a tupla a ser eliminada. A tupla a que
derivada de e por projeo do componente X eliminada de A.
- UPDATE: seja e a tupla a ser atualizada e seja e' a verso
atualizada; e' deve satisfazer a PE. A tupla a que derivada
de e por projeo do componente X eliminada de A sem a
execuo de quaisquer procedimentos triggers ou verificao
de predicados de variveis de relaes. A tupla a' que
derivada de e' por projeo do componente X inserida em A.
Exemplos: seja a viso VPX definida como:
EXTEND P ADD ( PESO * 454 ) AS PESOGM
A Figura 9.6 ilustra uma amostra de valores para dessa viso.
FIGURA 9.6 A viso VPX (amostras de valores)
- Uma tentativa de inserir a tupla
(P7,Tubo,Vermelho,12,Paris,5448) ser bem-sucedida e ter o
efeito de inserir a tupla (P7,Tubo,Vermelho,12,Paris) na
varivel de relao P.
- Uma tentativa de inserir a tupla
(P7,Tubo,Vermelho,Paris,5449) falhar (por qu?).
- Uma tentativa de inserir a tupla
(P1,Tubo,Vermelho,12,Paris,5448) falhar (por qu?).
- Uma tentativa de eliminar a tupla para P1 ser bem-sucedida
e ter o efeito de eliminar da varivel de relao P a tupla
para P1.
- Uma tentativa de atualizar a tupla correspondente a P1 para
(P1,Porca,Vermelho,1O,Paris,4540) ser bem-sucedida; o efeito
ser o de atualizar a tupla (P1,Porca,Vermelho,12,Londres) na
varivel de relao P para (P1,Porca,Vermelho,1O,Paris).
- Uma tentativa de atualizar a mesma tupla para uma tupla
correspondente a P2 (com todos os outros valores inalterados)
ou para uma tupla na qual o valor de PESOGM no seja igual a
454 vezes o valor de PESO falhar (em cada caso, por qu?).
269
VPX p PNOME COR PESO CIDADE PESOGM
P1
P2
P3
P4
P5
P6
Porca
Pino
Parafuso
Parafuso
Came
Tubo
Vermelho
Verde
Azul
Vermelho
Azul
Vermelho
12,0
17,0
17,0
14,0
12,0
Londres
Paris
Roma
Londres
Paris
Londres
5448,0
7718,0
7718,0
6536,0
5448,0
8626,0
19,0
Juno
Q uase todos os tratamentos anteriores do problema de
atualizao de vises - inclusive nas cinco edies
anteriores deste livro e em outros livros deste autor
arguiram que a possibilidade de atualizao ou no de uma
determinada juno depende, pelo menos em parte, de a juno
ser de um para um, um para mui- tos ou muitos para muitos. Em
contraste com esses tratamentos anteriores, afirmamos agora
que junes so sempre atualizveis. Alm disso, as regras
so idnticas nos trs casos e so em essncia bastante
diretas. O que torna a tese plausvel por mais
surpreendente que ela possa parecer primeira vista a
nova perspectiva sobre o problema proporcionada pela adoo
da Regra Aurea, como explicaremos agora.
Gencricamente, o objetivo do suporte de vises sempre foi o
dc tornar as vises semelhantes s variveis de relaes
bsicas tanto quanto possvel, e esse objetivo certamente
ainda louvvel. Porm:
. Em geral, supe-se (de forma implcita) que seja sempre
possvel atualizar uma tupla individual de uma varivel de
relao bsica, independentemente de todas as outras tuplas
dessa varivel de relao bsica.
. Ao mesmo tempo, percebe-se (de forma explcita) que com
certeza no sempre possvel atualizar uma tupla individual
em uma viso, independentemente de todas as outras tuplas
nessa viso.
Por exemplo, Codd mostra, na referncia [11.2], que no
possvel remover apenas uma tupla de uma certa juno, porque
o efeito seria o de deixar uma relao que no a juno de
duas relaes quais- quer (o que significa que o resultado
no poderia de jeito algum satisfazer ao predicado de
varivel de relao para a viso). Alm disso, historicamente
a abordagem para essas atualizaes de vises tem sido
rejeit-las por completo, com base na impossibilidade de
torn-las completamente semelhantes s atualizaes de
variveis de relaes bsicas.
Nossa abordagem um tanto diferente. Para sermos
especficos, reconhecemos que mesmo com uma varivel de
relao bsica, nem sempre possvel atualizar tuplas
individuais independentemente de todo o restante. Ento, em
geral, aceitamos as atualizaes de vises que historicamente
tm sido rejeita- das, interpretando-as de um modo bvio e
logicamente correto, como aplicveis a variveis de relaes
subjacentes; acima de tudo, ns a aceitamos, reconhecendo por
completo o fato de que a atualizao dessas variveis de
relaes subjacentes poderia ter efeitos colaterais sobre a
viso efeitos colaterais que so, todavia, necessrios para
evitar a possibilidade de que a viso venha a violar seu
prprio predicado.
Feito esse prembulo, vamos aos detalhes. No texto seguinte,
primeiro definiremos nossos termos. Depois, apresentaremos as
regras para atualizao de vises de juno. Em seguida,
consideraremos as implicaes dessas regras para cada um dos
trs casos (um para um, um para muitos, muitos para muitos)
por vez.
Considere ajunoJ = AJOTNB, onde (como no Captulo 6, Seo
6.4) as variveis de relaesA, B eJ tm cabealhos {X,Y},
{Y,Z} e {X,Y,Z}, respectivamente. Sejam PA e PB os predicados
para A e B, respectivamente. Ento, o predicado de varivel
de relao PJ para]
P11 ( a ) AND P8 ( b
onde, para uma dada tupla j da juno, a a poro A dej
(isto , a tupla que derivada dej pela projeo do
componente Z) e b a poro B dej (isto , a tupla que
derivada dei pela projeo do componente X). Em outras
palavras:
Toda tupla na juno tal que a poro A satisfaz a PA e a
poro B satisfaz a PB.
Por exemplo, o predicado para a juno das variveis de
relaes F e FP sobre F :
Toda tupla (s,n,t,c,p,q) na juno tal que a tupla
(s,n,t,c) satisfaz ao predicado para F e a tupla (s,p,q)
satisfaz ao predicado para FP.
Ento, aqui esto as regras de atualizao:
270
. INSERT: a nova tupla j deve satisfazer a PJ. Se a poro A
de j no aparecer em A, ela ser inserida em A. Se a poro B
de j no aparecer em B, ela ser inserida em B.
. DELETE: a poroA da tupla a ser eliminada ser eliminada
deA e a poro B ser eliminada de B.
. UPDATE: a tupla a ser atualizada deve ser tal que a verso
atualizada satisfaa a PJ. A poro A ser eliminada de A,
sem a execuo de procedimentos triggers e verificao de
predicados de variveis de relaes. Ento, se a poro A da
verso atualizada da tupla no aparecer em A ela ser
inserida em A; se a poro B no aparecer em B, ela ser
inserida em B.
Vamos examinar agora as implicaes dessas regras para os
trs casos diferentes.
Caso 1 (um para um): primeiro, observe que um para um aqui
seria mais precisamente (zero ou um) para (zero ou um). Em
outras palavras, existe uma restrio de integridade que
garante que, para cada tupla de A existe no mximo uma tupla
correspondente em B e vice-versa implicando que o conjunto
de atributos Y sobre o qual a juno executada tem de ser
uma superchave tanto para A quanto para B. ( Consulte o
Captulo 8, Seo 8.8 se precisar relembrar o assunto de
superchaves.)
Exemplos:
. Como primeiro exemplo, voc deve considerar o efeito das
regras precedentes sobre a juno da varivel de relao dc
fornecedores F com ela mesma sobre nmeros de fornecedores
(somente).
. Como segundo exemplo, suponha que temos outra varivel de
relao bsica FR com atributos F# e REST, onde F# identifica
um fornecedor r REST identifica o restaurante favorito desse
fornecedor. Vamos supor que nem todos os fornecedores de F
aparecem em FREQUENTE- MENTE. Considere o efeito das regras
de atualizao da juno sobre F JOIN FR. Qual seria a
diferena se algum fornecedor pudesse aparecer em FR e no em
F?
Caso 2 (um para muitos): o termo um para muitos aqui seria
mais exatamente (zero ou um) para ( zero ou mais). Em
outras palavras, existe uma restrio de integridade em
efeito que garante que, para cada tupla de B existe no mximo
uma tupla correspondente em A. Em geral, isso significa que o
conjunto de atributos Y sobre o qual a juno executada
deve incluir um conjunto K, digamos, tal que K seja uma chave
candidata paraA e uma chave estrangeira associada paraB.
Nota: se esse for realmente o caso, poderemos substituir a
expresso zero ou um por exatamente um.
Exemplo: seja a viso FFP definida como:
F JOIN FP
( essa uma juno de chave estrangeira para chave candidata
associada, claro). Amostras de valores so apresentadas na
Figura 9.7.
. Uma tentativa de inserir a tupla
(F4,Clark,20,Londres,P6,100) em FFP ser bem-sucedida e ter
o efeito de inserir a tupla (F4,P6,100) na varivel de
relao FP (acrescentando assim uma tupla viso).
- Uma tentativa de inserir a tupla
(F5,Adams,30,Atenas,P6,100) em FFP ser bem-sucedida e ter o
efeito de inserir a tupla (F5,P6,100) na varivel de relao
FP (acrescentando assim uma tupla viso).
- Uma tentativa de inserir a tupla
(F6,Green,20,Londres,P6,100) em FFP ser bem-sucedida e ter
o efeito de inserir a tupla (F5,Green,20,Londres) na varivel
de relao F e a tupla (F6,P6,100) na varivel de relao FP
(acrescentando assim uma tupla viso).
Nota: vamos supor por um momento que possvel existirem
tuplas de FP sem uma tupla de F correspondente. Vamos supor
ainda que a varivel de relao FP j inclui algumas tuplas
com nmero de fornecedor P6, mas no uma com nmero dc
fornecedor F6 e nmero de pea
Note que essa INSERT poderia ter o efeito colateral de
inserir a poro B tambm em B, como no caso das vises de
unio, interseo e diferena que discutimos antes.
Comentrios anlogos tambm se aplicam s regras DELETE e
UPDATE; para
abreviar, no nos preocuparemos em mostrar essa possibilidade
em detalhes para cada caso. 271
P1. Ento, a operao INSERT no exemplo discutido ter o
efeito de inserir algumas tuplas adicionais na viso ou
seja, a juno da tupla (F6,Green,20,Londres) com as tuplas
de FP que existiam antes para o fornecedor F6.
SSP
FIGURA 9 . 7 A viso FFP (amostras de valores)
. Uma tentativa de inserir a tupla
(F4,Clark,20,Atenas,P6,100) em FFP falhar (por qu?).
. Uma tentativa de inserir a tupla
(F1,Smith,20,Londres,P1,400) em FFP falhar (por qu?).
. Uma tentativa de eliminar a tupla
(F3,Blake,30,Paris,P2,200) de FFP ser bem-sucedida e ter o
efeito de eliminar a tupla (F3,Blake,30,Paris) da varivel de
relao F e a tupla (F3,P2,200) da varivel de relao FP.
. Uma tentativa de eliminar a tupla
(F1,Smith,20,Londres,P1,300) de FFP ser bem-sucedida
veja a nota a seguir e ter o efeito de eliminar a tupla
(F1,Smith,20,Londres) da varivel de relao F e a tupla
(F1,P1,300) da varivel de relao FP.
Nota: na verdade, o efeito geral dessa tentativa de DELETE
depender da regra DELETE da chave estrangeira de remessas
para fornecedores. Se a regra especificar RESTRICT, a opera-
o geral falhar. Se especificar CASCADE, ela ter o efeito
colateral de eliminar todas as outras tuplas de FP (e,
portanto, tuplas de FFP) tambm para o fornecedor Fi.
. Uma tentativa de atualizar a tupla de FFP
(F1,Smith,20,Londres,P1,300) para (F1,Smith,
20,Londres,P1,400) ser bem-sucedida e ter o efeito de
atualizar a tupla de FP (F1,P1,300) para (F1,P1,400).
. Um tentativa de atualizar a tupla de FFP
(F1,Smith,20,Londres,P1,300) para (F1,Smith,20,Ate-
nas,P1,400) ser bem-sucedida e ter o efeito de atualizar a
tupla de F (F1,Smith,20,Londres) para (F1,Smith,20,Atenas) e
a tupla de FP (F1,P1,300) para (F1,P1,400).
. Uma tentativa de atualizar a tupla de FFP
(F1,Smith,20,Londres,P1,300) para (F6,Smith,
20,Londres,P1,300) ser bem-sucedida veja a nota a seguir
e ter o efeito de atualizar a tu- pia de F
(F1,Smith,20,Londres) para (F6,Smith,20,Londres) e a tupla de
FP (F1,P1,300) para (F6,P1,300).
Nota: na reaiidade, o efeito geral dessa tentativa de
atualizao depender da regra UPDATE da chave estrangeira de
remessas para fornecedores. Os detalhes ficam como exerccio.
Caso 3 (muitos para muitos): o termo muitos para muitos
aqui seria mais precisamente (zero ou mais)
para (zero ou mais). Em outras palavras, no existe nenhuma
restrio de integridade em efeito que garanta que realmente
que estamos realmente lidando com uma situao do Caso 1 ou
do Caso 2.
272
F# FNOME STATUS CIDADE P# QDE
F1 Smith 20 Londres P1 300
Fi Smith 20 Londres P2 200
Fi Smith 20 Londres P3 400
Fi Smith 20 Londres P4 200
Fi Smith 20 Londres P5 100
F1 Smith 20 Londres P6 100
F2 Jones 10 Paris P1 300
F2 Jones 10 Paris P2 400
F3 Blake 30 Paris P2 200
F4 Clark 20 Londres P2 200
F4 Clark 20 Londres P4 300
F4 Clark 20 Londres P5 400
Exemplos: vamos supor que temos uma viso definida como:
F JOIN P
( juno de F e P sobre CIDADE uma juno muitos para
muitos). Amostras de valores esto representa- das na Figura
9.8.
- Inserir a tupla (F7,Bruce,15,Oslo,P8,Roda,Branco,25) ser
bem-sucedida e ter o efeito de inserir a tupla
(F7,Bruce,15,Oslo) na varivel de relao F e a tupla
(P8,Roda,Branco,25,Oslo) na varivel de relao P
(adicionando assim a tupla especificada viso).
FIGURA 9.8 AjunoFePsobre CIDADE
. Inserir a tupla
(F1,Smith,Londres,P7,Arruela,Vermelha,4,Londres) ser bem-
sucedida e ter o efeito de inserir a tupla
(P7,Arruela,Vermelha,S,Londres) na varivel de relao P
(acrescentando assim duas tuplas viso a tupla
(F1,Smith,20,Londres,P7,Arruela,Vermelha,5) como
especificado, e tambm a tupla
(F4,Clark,20,Londres,P7,Arruela,Vermelha,S)).
. Inserir a tupla (F6,Green,20,Londres,P7,Arruela,Vermelha,5)
ser bem-sucedida e ter o efeito de inserir a tupla
(F6,Green,20,Londres) na varivel de relao F e a tupla
(P7,Arruela,Verme- lha,5,Londres) na varivel de relao P
(acrescentando assim seis tuplas viso).
. A eliminao da tupla
(F1,Smith,20,Londres,P1,Porca,Vermelha,12) ser bem-sucedida
e ter o efeito de eliminar a tupla (F1,Smith,20,Londres) da
varivel de relao F e a tupla (P1,Por-
ca,Vermelha,12,Londres) da varivel de relao P (eliminando
assim quatro tuplas da viso).
Outros exemplos ficam como exerccio.
Outros operadores
Por fim, vamos considerar rapidamente os operadores restantes
da lgebra. Primeiro, notamos que juno , semijuno,
semidiferena e diviso no so primitivas; assim, as regras
para esses operadores podem ser derivadas das regras para os
operadores em cujos termos eles so definidos. Quanto aos
outros:
. Renomeao: trivial.
. Produto cartesiano: como observamos no final da Seo 6.4
do Captulo 6, o produto cartesiano um caso particular da
juno natural (A JOIN B degenera em A TIMES B se A e B no
tm atributos em comum). Em consequncia disso, as regras
paraA TIMES B so apenas um caso especial das regras para A
JOIN B (como tambm as regras para A INTERSECT B,
naturalmente).
273
F# FNOME STATUS CIDADE P# PNOME COR PESO
F1 Srnith 20 Londres P1 Porca Vermelho 12,0
F1 Smith 20 Londres P4 Parafuso Vermelho 14,0
F1 Smith 20 Londres P6 Tubo Vermelho 19,0
F2 Jones 10 Paris P2 Pino Verde 17,0
F2 Jones 10 Paris P5 Carne Azul 12,0
F3 Blake 30 Paris P2 Pino Verde 17,0
F3 Blake 30 Paris P5 Carne Azul 12,0
F4 Clark 20 Londres P1 Porca Vermelho 12,0
F4 Clark 20 Londres P4 Parafuso Vermelho 14,0
F4 Clark 20 Londres P6 Tubo Vermelho 19,0
. Totalizao: a totalizao tambm no primitiva ela
definida em termos de extenso e, as- sim, as regras de
atualizao podem ser derivadas daquelas existentes para a
extenso. Nota: verdade que a maioria das atualizaes
sobre a maioria das vises de SUMMARIZE falhar na prtica.
Porm, as falhas ocorrem no porque essas vises so
inerentemente no atualizveis, mas sim porque tentativas de
atualiz-las em geral violaro alguma restrio de
integridade. Por exemplo, seja a expresso de definio de
viso:
SUMMARIZE FP PER FP { F# ) ADD SUM ( QDE ) AS QDETOTAL
Ento, uma tentativa de eliminar, digamos, a tupla para o
fornecedor Fi ser bem-sucedida. No entanto, uma tentativa de
inserir, digamos, a tupla (F5,500) falhar, porque viola a
restrio de que o valor de QDETOTAL deve ser igual soma de
todos os valores de QDE individuais aplicveis. Uma tentativa
de inserir a tupla (F5,O) tambm falhar, mas por uma razo
diferente (exatamente, por qu?).
. Agrupamento e desagrupamento: nesse caso tambm se aplicam
comentrios anlogos aos que foram feitos sobre o operador de
totalizao.
. Tclose: mais uma vez, aplicam-se comentrios de certa forma
anlogos aos anteriores.
9.5 SNAPSHOTS (UMA DIGRESSO)
Nesta seo, faremos uma breve digresso para discutir
snapshots (ou fotografias) [9.2]. Os snapshots tm alguns
pontos em comum com as vises,* mas no so a mesma coisa.
Como as vises, os snapshots so variveis de relaes
derivadas; porm, diferentes das vises, eles so reais
isto , so representados no apenas por sua definio em
termos de outras variveis de relaes, mas tambm (pelo
menos conceitualmente) por sua prpria cpia dos dados
materializada separadamente. Aqui est um exemplo:
VAR P2SC SNAPSHOT
( ( F JOIN FP ) WHERE P# = P# ( P2' ) ) { F#, CIDADE
REFRESH EVERY DAY
A definio de um snapshot muito semelhante execuo de
uma consulta, exceto pelo fato de que:
a. O resultado da consulta mantido no banco de dados sob o
nome especificado (P2FC, no exemplo) como uma varivel de
relao somente de leitura (ou seja, somente de leitura fora
da renovao peridica veja o item b.).
b. Periodicamente (no exemplo EVERY DAY) o snapshot
renovado isto , seu valor atual descartado, a consulta
executada outra vez, e o resultado dessa nova execuo passa
a ser o novo valor do snapshot.
Assim, o snapshot P2FC representa os dados relevantes como
eram no mximo 24 horas antes (ento, qual o predicado?).
O importante na idia de snapshots que muitas aplicaes
talvez at mesmo a maioria delas podem tolerar, ou at
exigir, dados como eram em algum instante determinado. Por
exemplo, as aplica- es de relatrios e de contabilidade so
casos importantes; em geral, essas aplicaes exigem que os
da- dos sejam congelados em um momento apropriado (por
exemplo, no final de um perodo contbil), e os snapshots
permitem que esse congelamento ocorra sem impedir que outras
transaes executem atualizaes nos dados em questo (ou
seja, nos dados reais). De modo semelhante, poderia ser
desejvel congelar grandes quantidades de dados para uma
consulta complexa ou uma aplicao somente de leitu *N
verdade, eles so s vezes chamados vises materializadas
(veja, por exemplo, as referncias [9.1], [9.3], [9.6],
[9.14] e [9.16]). Porm essa terminologia infeliz e de fato
desaconselhada, pois o fato de vises serem materializadas ou
no uma questo de implementao, e no do modelo; no que
se refere ao modelo, as vises realmente no so
materializadas, e uma vi274 so materializada uma
contradio.
ra, de novo sem impedir atualizaes. Nota: essa idia se
torna ainda mais atraente em um ambiente de banco de dados
distribudo ou de apoio deciso consulte os Captulos 20
e 21, respectivamente. Observamos que os snapshots
representam um caso especial de redundncia controlada
(consulte o Cap- tulo 1) e um snapshot refresh o
processo de propagao de atualizao correspondente (mais
uma vez, consulte o Captulo 1).
Ento, em geral, uma definio de snapshot ser semelhante a
esta:
VAR <nome de varivel de relao> SNAPSHOT <expresso
relacional>
<lista de definio de chaves candidatas>
REFRESH EVERY <perodo de renovao>
onde <perodo de renovao> , por exemplo, MS ou SEMANA ou
DIA ou HORA ou n MINUTOS ou SEGUNDA, ou DIA UTIL . .. (etc.).
(Em particular, uma especificao da forma REFRESH [ON] EVERY
UPDATE poderia ser usada para manter o snapshot
permanentemente sincronizado com as variveis de relaes das
quais ele derivasse.) E aqui est a sintaxe da operao DROP
correspondente:
DROP VAR <nome de varivel de relao>
onde, claro, <nome de varivel de relao> se refere
especificamente ao snapshot. Nota: supomos que uma tentativa
de descartar um snapshot falhar se alguma outra definio de
varivel de relao se referir atualmente a ele. Como outra
opo, poderamos considerar estender a definio do snapshot
para incluir novamente alguma espcie de opo RESTRICT
versus CASCADE. No consideraremos com maior profundidade
aqui essa ltima possibilidade.
9.6 RECURSOS DE SQL
Nesta seo, vamos resumir o suporte de SQL para vises
(somente para elas a SQL no admite snapshots, pelo menos
no momento em que escrevemos). Primeiro, a sintaxe de CREATE
VIEW :
CREATE VIEW <nome de viso> AS <expresso de tabela>
[ WITH [ <qualificador> ] CHECK OPTION 1 ;
onde o <qualificador> CASCADED ou LOCAL, e CASCADED o
default (e de fato a nica opo sensata, como se explica em
detalhes na referncia [4.19]; por essa razo, omitimos aqui
a discusso mais profunda sobre LOCAL). Explicao:
1. A <expresso de tabela> a expresso de definio de
viso. Consulte o Apndice A para ver uma explicao
detalhada das expresses de tabelas SQL.
2. WITH CHECK OPTION, se especificada, significa que
operaes INSERT e UPDATE sobre a vi- so sero rejeitadas se
violarem qualquer restrio de integridade implcita na
expresso de defini- o de viso. Portanto, observe que tais
operaes s falharo se WITH CHECK OPTION for especificada
isto , por default, elas no falharo. Voc deve lembrar da
Seo 9.4, onde consideramos esse comportamento como
logicamente incorreto; assim, recomendaramos com veemncia
que WITH CHECK OPTION sempre seja sempre especificada na
prtica* (consulte a referncia [9.8]).
Exemplos:
1. CREATE VIEW BOM_FORNECEDOR
AS SELECT F.F#, F.STATUS, F.CIDADE
FROM F
WHERE F.STATUS > 15
WITH CHECK OPTION ;
* Isto , se a viso for atualizvel. Como veremos mais
adiante, as vises em SQL muitas vezes no so atualizveis,
e WITH
CHECK OPTION no vlida se a viso no atualizvel de
acordo com a SQL. 275
2. CREATE VIEW PEA_VERMELHA
AS SELECT P.P#, P.PNOME, P.PESO AS PS, P.CIDADE
FROM P
WHERE P.COR = Vermelho'
WITH CHECK OPTION ;
3. CREATE VIEW PQ
AS SELECT FP.P#, SUM ( FP.QDE ) AS QDETOTAL
FROM FP
GROUP BY FP.P# ;
Diferente de sua contraparte na Seo 9.1 (subseo Exemplos
adicionais), essa viso no incluir linhas correspondentes
a peas no fornecidas por um fornecedor qualquer. Consulte a
discusso do exemplo 7.7.8 no Captulo 7.
4. CREATE VIEW CIDADE_PAR
AS SELECT DISTINCT F.CIDADE AS FCIDADE, P.CIDADE AS PCIDADE
FROM F, FP, P
WHERE F.F# = FP.F#
AND FP.P# = P.P#
5. CREATE VIEW PEA_VERMELHA_PESADA
AS SELECT RP.P#, RP.PNOME, RP.PS, RP.CIDADE
FROM PEA_VERMELHA AS RP
WHERE RP.PS > 12,0
WITH CHECK OPTION ;
Uma viso existente pode ser descartada por meio da sintaxe
de DROP VIEW:
DROP VIEW <nome da viso> <opo>
onde (como ocorre com DROP TABLE e DROP DOMAIN) <opo>
RESTRICT ou CASCADE. Se RESTRICT for especificada e a viso
for referenciada em qualquer outra definio de viso ou em
uma restrio de integridade, DROP falhar; se CASCADE for
especificada, DROP ser bem-sucedida e quaisquer definies
de vises referentes e restries de integridade tambm sero
descartadas.
Busca em vises
Como se indicou na Seo 9.3, todas as buscas sobre todas as
vises tm a garantia de funcionar corretamente na verso
atual do padro de SQL (SQL/92). Infelizmente, o mesmo no
verdade para certos produtos atuais, nem para verses
anteriores do padro. Veja o Exerccio 9.14, parte a. no
final deste captulo.
Atualizao de vises
O suporte de SQL/92 para atualizao de vises muito
limitado. Basicamente, as nicas vises consideradas
atualizveis so as vises derivadas de uma nica tabela
bsica por meio de alguma combinao de operaes de
restrio e projeo. Alm disso, mesmo esse caso simples
tratado de modo incorreto, devido falta de compreenso por
parte da SQL de predicados de variveis de relaes e, em
particular, ao fato de que as tabelas de SQL permitem linhas
duplicadas.
Aqui est um enunciado mais preciso das regras de
possibilidade de atualizao de vises da SQL/92 (essa lista
foi tirada da referncia [4.19], mas est um pouco
simplificada aqui). Em SQL, uma viso atualizvel se todas
as condies a seguir se aplicarem:
1. A expresso de tabela que define o escopo da viso uma
expresso de seleo; isto , ela no contm imediatamente
qualquer das palavras-chave JOIN, UNION, INTERSECT ou EXCEPT.
276
2. A clusula SELECT dessa expresso de seleo no contm
diretamente a palavra-chave
DISTINCT.
3. Todo item de seleo nessa clusula SELECT (depois de
qualquer expanso necessria de itens de seleo no estilo
de asterisco) consiste em um nome de coluna possivelmente
qualificado (e opcionalmente acompanhado de uma clusula AS),
representando uma referncia simples a uma coluna da tabela
subjacente (ver pargrafo 5 a seguir).
4. A clusula FROM dessa expresso de seleo contm
exatamente uma referncia a tabela.
5. Essa referncia a tabela identifica uma tabela bsica ou
uma viso atualizvel. Nota: a tabela identificada por essa
referncia a tabela a (nica) tabela subjacente para a
viso atualizvel em questo (ver pargrafo 3 anterior).
6. Essa expresso de seleo no contm uma clusula WHERE
que inclua uma subconsulta que inclua uma clusula FROM que
inclua uma referncia mesma tabela referenciada na clusula
FROM mencionada no pargrafo 4 anterior.
7. Essa expresso de seleo no inclui uma clusula GROUP
BY.
8. Essa expresso de seleo no inclui uma clusula HAVING.
Surgem dois pontos importantes:
1. A possibilidade de atualizao em SQL tudo ou nada, no
sentido de que ou todas as trs operaes, INSERT, UPDATE ou
DELETE podem ser aplicadas a uma dada viso, ou ento nenhuma
delas pode no possvel (por exemplo) DELETE ser
aplicvel mas INSERT no (embora alguns produtos comerciais
admitam essa capacidade).
2. Em SQL, a operao UPDATE pode ou no pode ser aplicada a
uma dada viso no possvel haver algumas colunas
atualizveis e outras no dentro da mesma viso (embora, mais
uma vez, alguns produtos comerciais avancem alm do padro
nesse aspecto).
9.7 RESUMO
Uma viso essencialmente uma expresso relaciona! nomeada;
ela pode ser considerada uma varivel de relao derivada
virtual. Operaes sobre uma viso so normalmente
implementadas por um processo de substituio; isto ,
referncias ao nome da viso so substitudas pela expresso
que define a viso
e esse processo de substituio funciona precisamente
devido ao fechamento. Para operaes de busca, o processo de
substituio funciona 100% do tempo (pelo menos em teoria,
embora no necessariamente em produtos atuais). Para
operaes de atualizao, ele tambm funciona 100% do tempo*
(mais uma vez, em teoria, embora definitivamente no em
produtos atuais); porm, no caso de algumas vises (por
exemplo, vises definidas em termos de totalizao), as
atualizaes geralmente falhem, em virtude de violaes de
restries de integridade. Tambm apresentamos um extenso
conjunto de princpios a que o esquema de atualizao deve
satisfazer e mostramos em detalhes como o esquema de
atualizao funcionava para vises definidas em termos dos
operadores de unio, interseo, diferena, restrio,
projeo, juno e extenso. Para cada um desses operadores,
descrevemos as regras de inferncia de predicados (de
variveis de relaes) correspondentes.
Tambm examinamos a questo de vises e independncia de
dados lgica. Existem dois aspectos dessa independncia, o
crescimento e a reestruturao. Outros benefcios das vises
incluem: (a) sua capacidade de ocultar dados e com isso
fornecer uma certa medida de segurana, e (b) sua capacidade
de atuar como uma abreviao e assim facilitar a vida do
usurio. Continuamos a explicar dois princpios importantes,
O Princpio da Permutabilidade (que implica entre outras
coisas que devemos ser capazes de atualizar vises) e O
Princpio da Relatividade de Bancos de Dados.
Tambm fizemos uma digresso por um momento para dar uma
breve descrio de snapshots. Finalmente, descrevemos os
aspectos relevantes da SQL. (em linhas gerais).
Isto porque consideramos vises, variveis; e estas so, por
definio, sempre atualizadas. 277
EXERCICIOS
9.1 D anlogos, baseados no clculo, das definies
algbricas de vises da Seo 9.1, subseo Exemplos
adicionais.
9.2 Defina uma viso consistindo em nmeros de fornecedores e
nmeros de peas para fornecedores e peas que no so
colocados.
9.3 Defina uma viso para fornecedores de Londres.
9.4 Defina a varivel de relao FP do banco de dados de
fornecedores e peas como uma viso da varivel de relao
FPJ do banco de dados de fornecedores, peas e projetos.
9.5 Defina uma viso sobre o banco de dados de fornecedores,
peas e projetos consistindo em todos os projetos (somente
atributos nmero de projeto e cidade) que so supridos pelo
fornecedor Fi e utilizam a pea P1.
9.6 Dada a definio de viso:
VAR PESOPESADO VIEW
P RENAME PESO AS PS, COR AS COL
WHERE PS > PESO ( 14,0 ) ) { P#, PS, COL
mostre a forma convertida aps a procedimento de
substituio ter sido aplicado para cada uma das instrues a
seguir:
a. RA := PESOPESADO WHERE COL = COR ( `Verde
b. RB : ( EXTEND PESOPESADO ADD PS + PESO ( 5,3) AS PSP P#,
PSP
c. UPDATE PESOPESADO WHERE PS = PESO ( 18,0 ) COL := `Branco'
d. DELETE PESOPESADO WHERE P5 < PESO ( 10,0
e. INSERT INTO PESOPESADO
RELATION { TUPLE { P# P# ( `P99' ),
PS PESO ( 12,0 ),
COL COR ( `Prpura' )
9.7 Suponha que a definio da viso PESOPESADO do Exerccio
9.6 seja revista como a seguir:
VAR PESOPESADO VIEW
EXTEND P ADD PESO * 454 AS PS ) RENAME COR AS COL
WHERE PS > PESO ( 14,0 ) ) { P#, P5, COL
(isto , o atributo PS agora denota peso em gramas, e no em
libras). Em seguida, repetida o Exerccio 9.6.
9.8 No Captulo 8, sugerimos que s vezes poderia ser
desejvel ter a possibilidade de declarar chaves candidatas
ou possivelmente uma chave primria para uma viso. Por que
tal recurso seria desejvel?
9.9 Quais extenses do catlogo do sistema descrito nos
Captulos 3 e 5 so necessrias para dar suporte s vises? E
no caso dos snapshots?
9.10 Suponha que uma determinada varivel de relao bsica R
seja substituda por duas restries A e B, tais que A UNION
B seja sempre igual aR eA INTERSECT B seja sempre vazia. E
possvel alcanar a independncia de dados lgica?
9.11
a. A interseo A INTERSECT B equivalente juno A JOIN B
(essa juno de um para um, mas no estritamente, porque
poderiam existir tuplas em A sem equivalentes em B e vice-
versa). As regras de possibilidade de atualizao dadas na
Seo 9.4 para vises de interseo e juno so consistentes
como essa equivalncia?
b. A INTERSECT B tambm equivalente aA MINUS (A MINUS B) e
a B MINUS (B MINUS A). As regras de possibilidade de
atualizao dadas na Seo 9.4 para vises de interseo e
diferena so consistentes com essas equivalncias?
9.12 Um dos princpios que enunciamos na Seo 9.4 foi que
INSERT e DELETE deveriam ser inversas uma da outra, tanto
quanto possvel. As regras dadas nessa seo para atualizar
vises de unio, interseo e diferen 27 a obedecem a esse
princpio?
snapshots podem ser mantidos de forma incrementa!, e essa
manuteno incremental desejvel por razes de desempenho.
Contudo, a manuteno incremental pode levar a problemas se
os snapshots forem derivados de vrios bancos de dados
distintos que estejam sendo todos atualizados ao mesmo tempo.
Esse artigo oferece uma soluo para tal problema.
9.4 H. W. Buff: Why Codd's Rule No. 6 Must Be Reformulated,
ACM SIGMOD Record 17, Nmero 4 (dezembro de 1988).
Em 1985, Codd publicou um conjunto de doze regras a serem
usadas como parte de um teste para determinar se um produto
do qual se diz que completamente relacional na realidade o
[9.5]. Sua Regra Nmero 6 exigia que todas as vises que
teoricamente fossem atualizveis tambm fossem atualizveis
pelo sistema. Nessa breve nota, Buff afirma que o problema
gera! da possibilidade de atualizao de vises indecidvel
isto , no existe algoritmo gera! para determinar a
possibilidade de atualizao (no sentido de Codd) ou no de
uma viso arbitrria. Porm, observe que a definio de
possibilidade de atualizao de vises adotada neste capitulo
um pouco diferente da de Codd, pelo fato de dedicar ateno
explicitamente aos predicados de variveis de relaes
aplicveis.
9.5 E. F. Codd: Is Your DBMS Really Relational? e Does
Your DBMS Run by the Rules?, Com puterworld (14 e 21 de
outubro de 1985).
9.6 Latha S. Colby et ai.: Supporting Multiple View
Maintenance Policies, Proc. 1997 ACM SIGMOD Int. Conf. on
Management of Data, Tucson, Arizona (maio de 1997).
As vises do ttulo desse artigo no so vises, mas sim
snapshots. Existem trs abordagens gerais para manuteno de
snapshots:
1. Imediata: toda atualizao a qualquer varivel de relao
subjacente ativa de imediato uma atualizao correspondente
no snapshot.
2. Postergada: o snapshot s renovado quando consultado.
3. Peridica: o snapshot renovada a intervalos
especificados (por exemplo, todos os dias).
A finalidade dos snapshots em geral melhorar o desempenho
de consultas s expensas do desempenho de atualizaes, e as
trs normas de manuteno representam um espectro de
compromissos entre os dois. Esse artigo investiga questes
relacionadas ao suporte de diferentes normais em diferentes
snapshots no mesmo sistema e ao mesmo tempo.
9.7 Donald D. Chamberlin, James N. Gray e Irving L. Traiger:
Views, Authorization, and Locking in a Relational Data Base
System, Proc. NCC 44, Anaheim, Calif. Montvale, N.J.: AFIPS
Press (maio de 1975).
Inclui uma breve justificativa do enfoque adotado para a
atualizao de vises no prottipo do System R (e, portanto,
em SQLIDS, em DB2 e no padro de SQL etc.). Consulte tambm a
referncia [9.13], que faz o mesmo para o prottipo
University Ingres.
9.8 Hugh Darwen: Without Check Option, em C. J. Date and
Hugh Darwen, Relational Database Writings
19891991. Reading, Mass.: Addison-Wesley (1992).
9.9 C. J. Date e David McGoveran: Updating Union,
Intersection, and Difference Views e Updating Joins and
Other Views, em C. J. Date, Relationai Database Writings
19911994. Reading, Mass.: Addison-Wesley (1995). Nota: Uma
verso formal desses artigos est sendo preparada no momento
em que escrevemos.
9.10 Umeshwar Dayal e Philip A. Bernstein: On the Correct
Translation of Update Operations on Relational Views, ACM
TODS 7, Nmero 3 (setembro de 1982).
O primeiro tratamento realmente formal das regras de
atualizao de vises (apenas para vises de restrio,
projeo e juno). No entanto, no so considerados os
predicados de variveis de relaes.
9.11 Antonio L. Furtado e Marco A. Casanova: Updating
Relational Views, na referncia [17.1].
H duas amplas abordagens para o problema de atualizao de
vises. Uma delas (a nica discutida em detalhes neste livro)
tenta fornecer um mecanismo geral que funcione qualquer que
seja o banco de dados especfico envolvido; ela conduzida
unicamente pelas definies das vises em causa. A outra
abordagem, menos ambiciosa, exige que o DBA especifique, para
cada viso, exatamente quais atualizaes so permitidas e
quais so suas semnticas, escrevendo (de fato) o cdigo
procedural para implementar
280 essas atualizaes em termos das variveis de relaes
bsicas subjacentes. Esse artigo descreve trabalhos
sobre cada uma das abordagens (at 1985). Um extenso conjunto
de referncias a trabalhos anteriores est includo no
artigo.
9.12 Nathan Goodman: View Update Is Practical, InfoDB 5.
Nmero 2 (vero de 1990).
Uma discusso muito informal do problema da atualizao de
vises. Aqui est um trecho ligeiramente parafraseado da
introduo: Dayal e Bernstein [9.10] provaram que, em
essncia, nenhuma viso interessante pode ser atualizada;
Buff [9.2] provou que no existe algoritmo que possa decidir
se uma viso arbitrria pode ser atualizada. Parece haver
pouca razo para esperana. [Contudo,] nada poderia estar
mais longe da verdade. O fato que a atualizao de vises
tanto possvel quanto prtica. O artigo prossegue at
apresentar uma variedade de tcnicas de atualizao de vises
ad hoc. Porm, a noo crucial dos predicados de variveis de
relaes no mencionada.
9.13 Arthur M. Keller: Algorithms for Translating View
Updates to Database Updates for Views Involving Selections,
Projections, and Joins, Proc. 4th ACM SIGACT-SIGMOD
Symposium on Principies of Database Systems, Portland, Ore.
(maro de 1985).
Prope um conjunto de cinco critrios que deveriam ser
satisfeitos por algoritmos de atualizao de vises nada de
efeitos colaterais. somente mudanas em uma etapa, nada de
mudanas desnecessrias, substituto mais simples impossvel,
nenhum par DELETE-INSERT em vez de UPDATE e apresenta
aIgoritmos que satisfazem a esses critrios. Entre outras
coisas, os algoritmos permitem a implementao de uma espcie
de atualizao por meio de outra: por exemplo, uma operao
DELETE sobre uma viso poderia ser traduzida por uma operao
UPDATE sobre a varivel de relao bsica subjacente (por
exemplo, um fornecedor poderia ser eliminado da viso
fornecedores de Londres mudando-se o valor de CIDADE para
Paris). Como outro exemplo (para alm do escopo do artigo de
Keller, porm), uma operao DELETE sobre V (onde V
definida como a diferena A MINUS B) poderia ser implementada
por meio de uma operao INSERT sobre B em vez de uma
operao DELETE sobre A. Note que rejeitamos tais
possibilidades neste captulo, em virtude de nosso Princpio
Nmero 6.
9.14 DalIan Quass e Jennifer Widom: On-Line Warehouse View
Maintenance, Proc. 1997 ACM SIGMOD Int. Conf. on Management
of Data, Tucson, Arizona (maio de 1997).
As vises do ttulo desse artigo no so vises, mas sim
snapshots. O documento apresenta um algoritmo para manuteno
de snapshots que permite que transaes de manuteno sejam
executadas ao mesmo tempo que consultas sobre os snapshots.
9.15 M. R. Stonebraker: Implementation of Views and
Integrity Constraints by Query Modification, Proc. ACM SIGMOD
Int. Conf. on Management of Data, San Jose, Calif. (maio de
1975).
Ver anotao referncia [9.7].
9.16 Yue Zhuge, Hector Garcia-Molina, Joachim Hammer e
Jennifer Widom: View Maintenance in a Warehousing
Environment, Proc. 1995 ACM SIGMOD Int. Conf. on Management
of Data, San Jose, Calif. (maio de 1995).
As vises do ttulo desse artigo no so vises, mas sim
snapshots. Quando informada sobre uma atualizao a alguns
dados subjacentes, a instalao do depsito de dados pode
precisar emitir uma consulta para a instalao dos dados
bsicos, antes de poder conduzir a manuteno de snapshots
necessria, e o retardo de tempo entre tal consulta e a
atualizao dos dados bsicos originais pode levar a
anomalias. Esse artigo apresenta um algoritmo para se lidar
com tais anomalias.
RESPOSTAS A EXERCICIOS SELECIONADOS
9.1 As solues seguintes esto numeradas como 9.1 n, onde n
o nmero do exemplo original na Seo 9.1. Faremos nossas
suposies habituais a respeito de variveis de intervalos.
9.1.1 VAR PEA VERMELHA VIEW
( PX.P#, PX.PNOME, PX.PESO AS PS, PX.CIDADE )
WHERE PX.COR = COR ( Vermelha'
9.1.2 VAR PQ VIEW
( Px.P#,
SUM C FPX WHERE FPX.P# = PX.P#, QDE ) AS QDETOTAL )
281
9.1.3 VAR CIDADE_PAR VIEW
( FX.CIDADE AS FCIDADE, PX.CIDADE AS PCIDADE
WHERE EXISTS FPX ( FPX.F# FX.F# AND
FPX.P# PX.P# )
9.1.4 VAR PEA_VERMELHA_PESADA VIEW
RPX WHERE RPX.PS > PESO ( 12,0
No caso, RPX uma varivel de intervalo que varia sobre
PEA_VERMELHA.
9.2 VAR NO_COLOCADO VIEW
( F TIMES P ) { F#, P# } MINLJS
(FJOINP) {F#,P#};
9.3 VAR FORNECEDOR_LONDRES VIEW
F WHERE CIDADE = `Londres' ) { ALL BUT CIDADE
Nota: omitimos o atributo CIDADE nesse caso, pois sabemos que
seu valor deve ser Londres para todo fornecedor na viso.
Porm, observe que essa omisso significa que qualquer INSERT
sobre a viso falhar necessariamente (a menos que o valor
default para o atributo CIDADE na varivel de relao de
fornecedores subjacente seja Londres). Em outras palavras,
uma viso como essa provavelmente no poder admitir de modo
algum operaes INSERT. (Como outra opo, poderamos
considerar a possibilidade de definir o valor default de
CIDADE para tu pias inseridas por meio dessa viso como
Londres. Essa idia de defaults especficos de vises exige
mais estudo.)
9.4 O problema aqui : como o atributo QDE deve ser definido
na viso FP? A resposta sensata parece ser que, para um dado
par F#-P#, ele deve ser a soma de todos os valores FPJ.QDE,
tomados sobre todos os valores J# para esse par F#-P#:
VAR FP VIEW
SLJMMARIZE FPJ PER FPJ { F#, P# }
ADD SUM ( QDE ) AS QDE
9.5 VAR JC VIEW
( ( FPJ WHERE F# = F# (`Fi') ) { J# } JOIN
FPJ WHERE P# = P# (`P1') ) { J# } ) JOIN
J { J#, CIDADE
9.6 No mostramos as formas convertidas. Porm, observamos
que e. falhar, porque a tupla apresentada para insero no
satisfaz ao predicado para a viso.
9.7 Novamente, e. falhar, embora por uma razo ligeiramente
diferente dessa vez. Primeiro, o SGBD fornecer um valor
default de PESO, digamos w, pois o usurio no forneceu um
valor real de PESO (e no pode faz-lo, claro). Em
segundo lugar, extremamente provvel que, qualquer valor de
PS fornecido pelo usurio seja igual a w * 454 mesmo que
(como no o caso na operao INSERT mostrada) esse valor de
PS em particular, seja maior que 14,0. Assim, a tupla
apresentada para insero novamente no ir satisfazer ao
predicado para a viso.
Nota: seria possvel argumentar que o valor de PESO na nova
tupla deve ser definido de forma apropriada como o valor de
PS especificado dividido por 454. Essa possibilidade requer
mais estudo.
9.8 A lista de razes a seguir foi tirada da referncia
[5.71:
- Se usurios vo interagir com vises em vez de variveis de
relaes bsicas, ento claro que essas vises devem
parecer ao usurio to semelhantes a variveis de relaes
bsicas quanto possvel. De fato, no caso ideal, o usurio
no deve nem mesmo ter de saber que elas so vises, mas deve
ser capaz de trat-las como se realmente fossem variveis de
relaes bsicas, de acordo com O Princpio da Relatividade
de Bancos de Dados. Alm disso, da mesma forma que o usurio
de uma varivel de relao bsica precisa saber quais chaves
candidatas essa varivel de relao bsica tem (em geral), o
usurio de uma viso tambm precisa saber quais chaves
candidatas essa viso tem (mais uma vez, em geral). A
declarao explcita dessas chaves o modo bvio de tornar
essa informao disponvel.
- O SGBD pode no ser capaz de deduzir sozinho chaves
candidatas (isso certamente ocorre com todo SGBD no mercado
atual). Declaraes explcitas so, portanto, provavelmente o
nico meio disponvel
282 (para o DBA, lgico) de informar ao SGBD assim como
ao usurio sobre a existncia de tais chaves.
- Mesmo que o SGBD fosse capaz de deduzir chaves candidatas
sozinho, as declaraes explcitas pelo menos permitiriam que
o sistema verificasse que suas dedues e as especificaes
explcitas do DBA no so inconsistentes.
- O DBA pode ter algum conhecimento que SGBD no tem, e assim
poderia ser capaz de aperfeioar as dedues do SGBD. A
referncia [5.7] oferece um exemplo dessa possibilidade.
Alm disso, a referncia [11.3] apresenta outra razo,
essencialmente a de que tal recurso proporcionaria um modo
simples e conveniente de enunciar certas restries de
integridade importantes que, de outra forma, s poderiam ser
apresentadas com circunlquios.
9.9 obviamente impossvel fornecer uma resposta definitiva
a essa pergunta. Oferecemos as seguintes observaes:
- Cada viso e cada snapshot ter uma entrada na varivel de
relao do catlogo VARREL, com um valor de TIPOVARREL igual
a Viso ou Snapshot, conforme o caso.
- Cada viso tambm ter uma entrada em uma nova entrada de
varivel de relao de catlogo, que tambm poderamos chamar
VISAO. Essa entrada deve incluir a expresso de definio de
viso relevante.
- De modo semelhante, cada snapshot ter tambm uma entrada
em uma nova varivel de relao de catlogo (SNAPSHOT). Essa
entrada deve incluir a expresso de definio relevante. Ela
tambm deve conter informaes a respeito do intervalo de
renovao do snapshot.
- Outra varivel de relao de catlogo mostrar quais vises
e quais snapshots so definidos em termos de que outras
variveis de relaes. Observe que a estrutura dessa varivel
de relao de certa forma semelhante da varivel de
relao ESTRUTURA PEA (ver Figura 4.6 no Captulo 4): assim
como peas podem conter outras peas, vises e snapshots
tambm podem ser definidos em termos de outras vises e
outros snapshots. Portanto, observe que os pontos discutidos
na resposta ao Exerccio 7.7 do Captulo 7 so relevantes
aqui.
9.10 Sim! mas observe o seguinte. Vamos supor que
substitussemos a varivel de relao de fornecedores F por
duas restries, digamos FA e FB, onde FA representa os
fornecedores de Londres e FB os fornecedores que no so de
Londres. Podemos agora definir a unio de FA e FB como uma
viso chamada F. Se tentarmos agora (atravs dessa viso)
usar UPDATE para atualizar a cidade de um fornecedor de
Londres para algo diferente de Londres, ou ento a cidade de
um fornecedor no de Londres para Londres, a implementao
deve mapear essa operao UPDATE como uma operao DELETE
sobre uma das duas restries e uma INSERT sobre a outra.
Agora, as regras dadas na Seo 9.4 tratam esse caso
corretamente de fato, (deliberadamente) definimos UPDATE
como DELETE seguida por INSERT; porm, havia uma suposio
tcita de que a implementao realmente utilizaria uma
operao UPDATE, por razes de eficincia. Esse exemplo
mostra que s vezes o mapeamento de uma UPDATE para uma
UPDATE no funciona; na verdade, a determinao dos casos em
que ela funciona pode ser considerada uma otimizao.
9.11 a. Sim! b. Sim!
9.12 INSERT e DELETE sero sempre inversas uma da outra,
desde que (a) o banco de dados seja projetado de acordo com O
Princpio do Projeto Ortogonal (consulte a Seo 12.6 no
Captulo 12) e (b) o SGBD admita predicados de variveis de
relaes adequadamente. Porm, se essas condies no forem
satisfeitas, ento possvel que as operaes no possam ser
inversas uma da outra de modo algum. Por exemplo, se A e B
so variveis de relaes bsicas distintas, a insero da
tupla t em V = A INTERSECT B pode fazer t ser inserida
somente em A (porque ela j est presente em B); a eliminao
subsequentemente de t de V far agora t ser eliminada de A e
de B. (Por outro lado, a eliminao de t e depois sua
reinsero sempre preservar o status quo.) Contudo, observe
que tal assimetria s poder surgir se t satisfizer ao
predicado para A e ainda no estiver presente em A.
9.13 Oferecemos alguns comentrios. Primeiro, o prprio
processo de substituio envolve vrias etapas, que poderiam
ser resumidas com a seguir. (Essa sequncia de operaes ser
aprimorada em breve.)
/ define as novas variveis de relaes bsicas*/
VAR FNC BASE RELATION
F# F#, FNOME NOME, CIDADE CHAR
PRIMARY KEY { F# } ;
VAR FT BASE RELATION
F# F#, STATUS INTEGER } 283
PRIMARY KEY { F#
/ copia os dados nas novas variveis de relaes bsicas */
INSERT INTO FNC F { F#, FNOME, CIDADE
INSERT INTO FT F { F#, STATUS
/* descarta a varivel de relao antiga */
DROP VAR F
Agora podemos criar a viso desejada:
VAR F VIEW
FNC JOIN FT
Observamos agora que cada um dos dois atributos F# (em FNC e
em FT) constitui uma chave estrangeira que faz referncia
outra. Na verdade, h um relacionamento um para um estrito
entre as variveis de relaes FNC e FT, e ento incorremos
em uma variedade de dificuldades de um para um que foram
discutidas com certo detalhe pelo autor em outro trabalho
[13.7].
Observe tambm que devemos fazer algo em relao chave
estrangeira na varivel de relao FP que faz referncia
antiga varivel de relao bsica F. Seria timo se essa
chave estrangeira pudesse agora ser tomada como referncia
viso F; se isso no fosse possvel (como realmente no
costuma ser nos produtos atuais), seria melhor acrescentar
uma terceira projeo da varivel de relao bsica F para o
banco de dados, assim:
VAR FF BASE RELATION
{ F# F# } PRIMARY KEY { F# }
INSERT INTO FF F { F# 1
(Na verdade, esse projeto de todo modo recomendado na
referncia [8.101 por outras razes.) Agora, alteramos a
definio da viso F:
VAR F VIEW F
FF JOIN FNC JOIN FT
Acrescentamos tambm a seguinte especificao de chave
estrangeira definio das variveis de relaes FNC e FT:
FOREIGN KEY { F# } REFERENCES FF
ON DELETE CASCADE
ON UPDATE CASCADE
Finalmente, devemos mudar a especificao da chave
estrangeira {F#} na varivel de relao FP de modo que ela
referencie a varivel de relao FF em vez de F.
Nota: a idia de permitir que uma chave estrangeira
referencie uma viso em vez de uma varivel de relao bsica
exige mais estudo.
9.14 A respeito da parte a. deste exerccio aqui est um
exemplo de busca em viso, que certamente falha em certos
produtos de SQL na poca em que escrevemos. Considere a
seguinte definio de viso de SQL (Exemplo 3 da Seo 9.6):
CREATE VIEW PQ AS
SELECT FP.P#, SUM ( FP.QDE ) AS QDETOTAL
FROM FP
GROUP BY FP.P#
Considere tambm a seguinte tentativa de consulta:
SELECT AVG ( PQ.QDETOTAL ) AS PT
FROM PQ
284
Se seguirmos o simples processo de substituio explicado no
texto do captulo (isto , se tentarmos substituir as
referncias ao nome da viso pela expresso que define a
viso), obteremos algo como:
SELECT AVG ( SUM ( FP.QDE ) ) AS PT
FROM FP
GROUP BY FP.P#
E essa no uma instruo SELECT vlida, porque (como
observamos na discusso seguinte do exemplo 7.7.7 no Captulo
7) a SQL no permite que operadores de agregados sejam
aninhados dessa forma.
Aqui est outro exemplo de consulta sobre a mesma viso PQ
que tambm falha em certos produtos, em grande parte pela
mesma razo:
SELECT PQ.P#
FROM PQ
WHERE PQ.QDETOTAL > 500
A propsito, exatamente em virtude do problema ilustrado por
esses exemplos, certos produtos o DB2 da IBM um exemplo
s vezes materializam fisicamente a viso (em vez de
aplicarem o procedimento de substituio mais usual) e depois
executam a consulta sobre a verso materializada. Essa
tcnica sempre funcionar, claro, mas pode incorrer em
prejuzo no desempenho. Alm disso, no caso do DB2 em
particular, ainda possvel que algumas buscas sobre algumas
vises no funcionem; isto , o DB2 nem sempre utiliza a
materializao se a substituio no funciona, nem fcil
caracterizar exatamente em que casos ela funciona e em quais
no funciona. Ento, o segundo dos dois exemplos dados antes
ainda falha em DB2 no momento em que escrevemos. Consulte a
referncia [4.20j para ver mais discusso adicional.
9.15 Primeiro, aqui est uma definio do projeto b. em
termos do projeto a.:
VAR FFP VIEW
F JOIN FP
VAR XFF VIEW
F MINUS ( F JOIN FP ) { F#, FNOME, STATUS, CIDADE
E aqui temos uma definio do projeto a. em do projeto b.:
VAR F VIEW
XFF UNION FFP { F#, FNOME, STATUS, CIDADE
VAR FP VIEW
FFP { F#, P#, QDE
As restries de bancos de dados aplicveis para os dois
projetos podem ser enunciadas desta forma:
CONSTRAINT DESIGNA
ISEMPTY ( FP { F# } MINUS F { F# } )
CONSTRAINT DESIGNB
ISEMPTY ( FFP { F# } INTERSECT XFF { F# } )
(Observe que a restrio DESIGN_A nesse caso um exemplo de
outro modo de formular uma restrio referencial.)
O projeto a. claramente superior, pelas razes discutidas
em detalhes no Captulo 11.
9.16 Numeramos as solues seguintes como 9.16.n, onde n o
nmero do exerccio original.
9.16.2 CREATE VIEW NO_COLOCADO
AS SELECT F.F#, P.P#
FROM F, P
WHERE F.CIDADE <> P.CIDADE
9.16.3 CREATE VIEW FORNECEDOR_LONDRES
AS SELECT F.F#, F.FNOME, F.STATUS
FROM F
WHERE F.CIDADE = `Londres
285
9.16.4 CREATE VIEW FP
AS SELECT FPJ.F#, FPJ.P#, SUM ( FPJ.QDE ) AS QDE FROM FPJ
GROUP BY FPJ.F#, FPJ.P# ;
9.16.5 CREATE VIEW JC
AS SELECT J.J#, J.CIDADE
FROM J
WHERE J.J# IN ( SELECT FPJ.J#
FROM FPJ
WHERE FPJ.F# = Fi'
AND J.J# IN ( SELECT FPJ.J#
FROM FPJ
WHERE FPJ.P# = `P1' )
286