CAPTULO 8

Integridade

8.1 INTRODUO
O termo integridade se refere preciso ou correo de dados
no banco de dados. Como observamos no Captulo 3, um
determinado banco de dados pode estar sujeito a um nmero
muito grande de restries de integridade de complexidade (em
geral) arbitrria. Por exemplo, no caso de fornecedores e
peas, nmeros de fornecedores poderiam ter a forma Fnnnn
(onde nnnn quer dizer at quatro dgitos decimais) e ser
exclusivos; valores de status poderiam estar no intervalo de
1 a 100; fornecedores de Londres poderiam ter o status 20;
quantidades de remessas poderiam ser mltiplos de 50; peas
vermelhas poderiam estar armazenadas em Londres etc. Assim,
em geral, o SGBD precisa ser informado dessas restries e,
claro, precisa impor as restries de algum modo
(basicamente, rejeitando qualquer atualizao que possa
viol-las). Por exemplo (mais uma vez em Tutorial D):
CONSTRAINT FC3
ISEMPTY ( F WHERE STATUS < 1 OR STATUS > 100
(valores de status devem estar no intervalo de 1 a 100).
Observe o nome de restrio FC3 (restrio de fornecedores
trs); a restrio ser registrada no catlogo do sistema
sob esse nome e ele aparecer em qualquer mensagem de
diagnstico produzida pelo sistema em resposta a uma
tentativa de violar a restrio. A prpria restrio de
integridade especificada como uma expresso booleana que
no deve ter valor falso.
Nota: supomos a verso algbrica de Tutorial D como
definitiva; em conseqncia, a expresso booleana ser com
freqncia embora nem sempre da forma IS EMPTY (...),
significando que no existem dados no banco de dados que
violem a restrio (consulte o Captulo 6, Seo 6.9). Um
anlogo do clculo para o exemplo mostrado seria semelhante a
este:*
CONSTRAINT FC3
FORALL FX ( FX.STATUS 1 AND FX.STATUS 100
(onde, claro, FX uma varivel de intervalo que varia
sobre fornecedores).
A propsito, observamos que a expresso booleana em uma
restrio de clculo tem de ser uma FBF fechada (consulte o
Captulo 7, Seo 7.2) e com freqncia embora nem sempre
ela ter forma FORALL.x (...). Assim, note que o exemplo
especifica que todos os valores de status de fornecedores
devem estar no intervalo indicado. claro que, na prtica,
basta que o sistema verifique o fornecedor recm-inserido ou
atualizado, e no todos os fornecedores.
* Na prtica, muitas vezes parece mais fcil formular
restries (especialmente as complicadas) em termos de
clculo do que em termos de lgebra. Nosso foco sobre a
lgebra neste captulo feito por consistncia com nossas
discusses em outras partes do
livro, mas voc talvez prefira experimentar o exerccio de
converter alguns dos exemplos seguintes para a forma de
clculo. 219

Quando uma nova restrio declarada, o sistema deve

primeiro ter certeza de que o banco de dados a satisfaz. Se
no, a nova restrio rejeitada; do contrrio, ela aceita
(isto , gravada no catlogo) e imposta a partir desse
instante. No exemplo, a imposio exige que o SGBD monitore
todas as operaes que fariam a insero de um novo
fornecedor ou a alterao do status de um fornecedor
existente.
claro que tambm precisamos de um modo para eliminar
restries existentes:
DROP CONSTRAINT <nome da restrio>
Por exemplo:
DROP CONSTRAINT FC3
Nota: como vimos, nossa preocupao especificamente com o
suporte de integridade declarativa. Infelizmente, poucos
produtos atuais oferecem de modo adequado tal suporte. Embora
a situao esteja melhorando lentamente nesse aspecto, ainda
se pode afirmar que alguns produtos (em especial os no
relacionais) enfatizam de modo muito especfico a abordagem
oposta isto , o suporte procedural, usando procedimentos
armazenados ou triggers.* Porm, foi sugerido que, se o SGBD
fornecesse de fato suporte declarativo, ento mais de 90% da
definio de um banco de dados tpico consistiriam em
restries; assim, um sistema que fornecesse tal suporte
aliviaria os programadores de aplicaes de um trabalho
considervel e os tornaria bem mais produtivos. O suporte de
integridade declarativa importante.
Antes de seguirmos adiante, devemos dizer que a parte de
integridade do modelo relacional talvez seja a parte que mais
mudou ao longo dos anos (talvez seja mais bem dizer a que
mais evoluiu em vez de mudou). Como mencionamos no Captulo
3, a nfase original era especificamente sobre chaves
primrias e estrangeiras (chaves, para abreviar). Porm,
gradualmente a importncia na verdade, a importncia
crucial! de restries de integridade em geral comeou a
ser mais bem entendida e mais apreciada; ao mesmo tempo,
certas questes complicadas relativas a chaves em particular
comearam a surgir. A estrutura deste captulo reflete essa
mudana de nfase, pois ele trata de restries de
integridade em geral (at certo ponto), e depois discute as
chaves o que continua a ter maior importncia pragmtica
em seguida.
Um esquema de classificao de restries
Seguindo a referncia [3.3], classificamos as restries de
integridade em geral em quatro categorias amplas: de tipo
(domnio), de atributo, de varivel de relao e de banco de
dados. Basicamente:
Uma restrio de tipo especifica os valores vlidos de um
dado tipo. Nota: em todo este captulo, usaremos tipo com o
significado especfico de tipo escalar. Os tipos de relaes
tambm esto sujeitos a restries de tipo, mas essas
restries so apenas uma conseqncia lgica das restries
de tipo que se aplicam aos tipos escalares em termos dos
quais esses tipos de relaes so definidos (em ltima
anlise).
Uma restrio de atributo especifica os valores vlidos
para um dado atributo.
Uma restrio de varivel de relao especifica os valores
vlidos para uma dada varivel de relao.
Uma restrio de banco de dados especifica os valores
vlidos para um determinado banco de dados. Os quatro casos
sero discutidos em detalhes das Sees 8.2 a 8.5.
* Procedimentos armazenados e triggers so procedimentos pr-
compilados que podem ser invocados a partir de programas de
aplicao. Os exemplos poderiam incluir os operadores
definidos pelo usurio ABS, DIST, REFLECT etc. discutidos na
Seo 5.2 (subseo Definio de operadores). Esses
procedimentos podem ser considerados logicamente uma extenso
ao SGBD (em um sistema cliente/servidor, eles sero com
freqncia mantidos e executados no site servidor).
Voltaremos a esses procedimentos na Seo 8.8, na anotao a
220

algumas referncias do final do captulo, e tambm no

Captulo 20.
8.2 RESTRIES DE TIPO
Em essncia, uma restrio de tipo (ou logicamente
equivalente a) apenas uma enumerao dos valores vlidos do
tipo. Aqui est um exemplo simples, a restrio de tipo para
o tipo PESO:
TYPE PESO POSSREP ( RATIONAL );
CONSTRAINT THE PESO (PESO ) > 0.0
Adotamos uma conveno bvia pela qual uma restrio de tipo
pode fazer uso do nome de tipo aplicvel para denotar um
valor arbitrrio do tipo em questo; assim, esse exemplo
restringir os pesos de tal modo que eles possam ser
representados por um nmero racional maior que zero. Qualquer
expresso que deva ser avaliada como um peso mas que no
produza de fato um valor que satisfaa a essa restrio ir
falhar. Nota: consulte o Captulo 5 se precisar rever as
especificaes de POSSREP e operadores THE_.
Deve ficar claro que, em ltima anlise, o nico modo pelo
qual qualquer expresso pode produzir um valor do tipo PESO
atravs de alguma invocao de seletor PESO. Assim, o nico
modo pelo qual essa expresso pode violar a restrio de tipo
PESO se a invocao de seletor em questo o fizer. Desse
modo, essas restries de tipo sempre podem ser vistas, pelo
menos conceitualmente, como verificadas durante a execuo de
alguma invocao de seletor. Em conseqncia, podemos dizer
que as restries de tipo so verificadas imediatamente e,
ento, que nenhuma varivel de relao poder adquirir um
valor para qualquer atributo de qualquer tupla que no seja
do tipo apropriado ( claro, em um sistema que admita
restries de tipo de forma apropriada!).
Aqui est outro exemplo de restrio de tipo:
TYPE PONTO POSSREP CARTESIAN ( X RATIONAL, Y RATIONAL );
CONSTRAINT ABS ( THE_X ( PONTO ) ) 100.0 AND
ABS ( THEY ( PONTO ) ) 100.0
Aqui, a verificao de tipo feita conceitualmente durante a
execuo de invocaes do seletor CARTESIANO. Observe o uso
do operador definido pelo usurio ABS (consulte o CaptuloS,
Seo 5.2).
Aqui est um terceiro exemplo:
TYPE ELIPSE POSSREP ( A COMPRIMENTO, B COMPRIMENTO, CTR PONTO
);
CONSTRAINT THE_A ( ELIPSE ) THE_B ( ELIPSE);
Agora, os componentes da representao possvel,
especificamente A, B e CTR, representam respectivamente o
comprimento do semi-eixo maior a, o comprimento de semi-eixo
menor b e o centro ctr da elipse. Suponha que a varivel
escalar E seja declarada como do tipo ELIPSE, e que seu valor
atual tenha o comprimento do semi-eixo maior igual a cinco e
do semi-eixo menor igual a quatro. Agora, considere a
atribuio:
THE_B ( E ) : COMPRIMENTO ( 6.0 );
Nota: baseamos esse exemplo em uma varivel escalar e em uma
atribuio escalar apenas por razes de simplicidade, mas
poderamos ter usado como base uma varivel de relao e uma
atribuio relacional.
claro que a atribuio mostrada falhar, mas no a
atribuio em si que est errada. Em vez disso, o erro ocorre
de novo dentro de uma invocao de seletor (embora nenhuma
invocao esteja visvel diretamente na atribuio), porque a
atribuio mostrada de fato a abreviao para:*
*Em outras palavras e apesar do fato de no termos
mencionado esse detalhe de modo explcito no Captulo 5 as
pseudovariveis THE_ so logicamente desnecessrias! Ou seja,
qualquer atribuio a uma pseudovarivel THE_ sempre
logicamente equivalente (e de fato definida como uma
abreviao para) atribuio do resultado de uma certa
invocao de seletor a uma
varivel comum. 221

E := ELIPSE ( THE_A ( E ), COMPRIMENTO ( 6,0 ), THE_CTR ( E

a invocao de seletor no lado direito que falha
8.3 RESTRIES DE ATRIBUTOS
Uma restrio de atributo apenas uma declarao para o
efeito de que um atributo especificado seja de um tipo
especificado. Por exemplo, considere mais uma vez a definio
da varivel de relao de fornecedores:
VAR F BASE RELATION
F# F#,
SNOME NOME,
STATUS INTEGER,
CIDADE CHAR
Nessa varivel de relao, os valores dos atributos F#,
FNOME, STATUS e CIDADE esto limitados aos tipos F#, NOME,
INTEGER e CHAR, respectivamente. Em outras palavras, as
restries de atributos fazem parte da definio do atributo
em questo e podem ser identificadas por meio do nome do
atributo correspondente. Segue-se que uma restrio de
atributo s pode ser descartada se descartarmos o prprio
atributo (o que na prtica significar normalmente descartar
a varivel de relao que a contm).
Nota: em princpio, qualquer tentativa de introduzir um valor
de atributo no banco de dados que no seja um valor do tipo
relevante ser simplesmente rejeitado. Porm, na prtica, tal
situao nunca deve ocorrer, pois o sistema impe de fato as
restries de tipo descritas na seo anterior.
8.4 RESTRIES DE VARIVEIS DE RELAES
Uma restrio de varivel de relao uma restrio sobre
uma varivel de relao individual (expressa somente em
termos da varivel de relao em questo, embora possa ser
arbitrariamente complexa em outros aspectos). Aqui esto
alguns exemplos:
CONSTRAINT FC5
ISEMPTY ( F WHERE CIDADE = Londres AND STATUS 20
(fornecedores de Londres devem ter o status 20).
CONSTRAINT PC4
ISEMPTY ( P WHERE COR = COR ( Vermelho
AND CIDADE Londres
(peas vermelhas devem estar armazenadas em Londres).
CONSTRAINT FCK
COUNT(F)COUNT(F{F#})
(nmeros de fornecedores so exclusivos ou, de modo mais
formal, {F#} uma chave candidata para fornecedores
consulte a Seo 8.8).
CONSTRAINT PC7
IF NOT ( IS_EMPTY ( P ) ) THEN
COUNT ( P WHERE COR = COR ( Vermelho ) ) > O
END IF ;
222

(se existem peas, pelo menos uma delas deve ser vermelha).
A propsito, observe que esse exemplo difere de todos os
outros que vimos pois operaes DELETE tambm tm o potencial
de violar a restrio.
As restries de variveis de relaes so sempre verificadas
imediatamente (na verdade, como parte da execuo de qualquer
instruo que possa fazer com que elas sejam violadas).
Portanto, qualquer instruo que tente atribuir um valor a
uma dada varivel de relao que viole qualquer restrio
para essa varivel de relao efetivamente ser rejeitada.
8.5 RESTRIES DE BANCOS DE DADOS
Uma restrio de banco de dados uma restrio que relaciona
entre si duas ou mais variveis de relaes distintas. Aqui
esto alguns exemplos:
CONSTRAINT DBC1
ISEMPTY ( ( F JOIN FP )
WHERE STATUS < 20 AND QDE > QDE ( 500
(nenhum fornecedor com status menor que 20 pode fornecer
qualquer pea em uma quantidade maior que 500). Exerccio:
que operaes de atualizao o SGBD tem de monitorar para
impor a restrio
DBC1?
CONSTRAINT DBC2 FP { F# } F { F# } ;
(todo nmero de fornecedor na varivel de relao de remessa
tambm existe na varivel de relao de fornecedores;
lembre-se de que, no Captulo 6, usamos para indica
subconjunto de). Como o atributo F# na varivel de relao
F constitui uma chave candidata para fornecedores, essa
restrio basicamente a restrio referencial necessria de
remessas para fornecedores (isto , {F#} na varivel de
relao FP uma chave estrangeira para remessas que se
refere a fornecedores). Consulte a Seo 8.8 para ver uma
descrio adicional.
CONSTRAINT DBC3 FP { P# } P { P# } ;
(toda pea deve ter pelo menos uma remessa). Nota: claro
que tambm verdade que toda remessa deve ter exatamente uma
pea, em virtude do fato de que {P#} na varivel de relao P
uma chave candidata para peas e existe uma restrio
referencial de remessas para peas; no nos preocupamos em
mostrar aqui essa ltima restrio. De novo, consulte a Seo
8.8.
Esses dois ltimos exemplos servem para ilustrar o ponto de
que (em geral) a verificao de uma restrio de banco de
dados no pode ser feita de imediato, mas deve ser adiada at
o final da transao isto , at o instante de COMMIT
(consulte o Captulo 3 se precisar rever COMMIT). Vamos
supor, ao contrrio, que a verificao fosse imediata e que
no existisse nenhuma pea ou remessa no momento. Ento, a
insero de uma pea falhar porque ela viola a restrio
DBC3; da mesma forma, a insero de uma remessa falhar,
porque ela viola a restrio DBC2.*
Se uma restrio de banco de dados for violada no momento de
COMMIT, feito um ROLLBACK da transao.
8.6 A REGRA UREA
Nota: o material desta seo de importncia fundamental.
Porm, infelizmente, ele no tem aceitao muito ampla na
prtica, nem sequer bem compreendido, embora em princpio
seja bastante simples. Pedimos desculpas ao leitor.
*Na realidade, a referncia [3.3] prope uma forma mltipla
de atribuio que permitiria a insero de peas e remessas
em uma nica operao. Se tais atribuies fossem aceitas, as
restries de bancos de dados poderiam ser verificadas
imediatamente. 223

No Captulo 3, Seo 3.4, explicamos como qualquer relao

dada tinha um predicado associado e como tuplas dessa relao
denotavam proposies verdadeiras derivadas desse predicado.
No Captulo 5, Seo 5.3, mencionamos a Hiptese do Mundo
Fechado, que diz na realidade que, se uma certa tupla no
aparece em uma certa relao, somos obrigados a supor que a
proposio correspondente falsa.
Embora no tenhamos enfatizado esse detalhe antes, deve ficar
claro que uma varivel de relao tambm tem um predicado; ou
seja, o predicado comum a todas as relaes possveis que so
valores vudos da varivel de relao em questo. Por
exemplo, considere a varivel de relao F de fornecedores. O
predicado para essa varivel de relao seria semelhante a:
O fornecedor com o nmero de fornecedor especificado (F#) tem
o nome (FNOME) especificado e o valor de status especificado
(STATUS), e est localizado na cidade especificada (CIDADE);
alm disso, no h dois fornecedores com o mesmo nmero de
fornecedor ao mesmo tempo.
Essa declarao no exata nem completa, mas servir para os
propsitos atuais.
Tambm deve ficar claro que, fundamentalmente, o predicado
para uma dada varivel de relao serve como critrio para
aceitao de atualizaes na varivel de relao ele
determina se uma certa operao TNSERT, UPDATE ou DELETE
sobre essa varivel de relao deve ter sucesso. Por exemplo,
uma tentativa de inserir um novo fornecedor com nmero de
fornecedor igual ao de algum fornecedor existente seguramente
ser rejeitado.
Assim, no caso ideal, o SGBD conheceria e entenderia o
predicado de toda varivel de relao de modo que ele pudesse
lidar corretamente com toda as tentativas possveis de
atualizar o banco de dados. Porm, claro que essa meta
inalcanvel. Por exemplo, no h nenhum meio pelo qual o
SGBD possa saber o que significa um certo fornecedor estar
em uma certa cidade. E no h nenhum meio pelo qual o SGBD
possa saber a priori que o predicado para fornecedores tal
que (por exemplo) a tupla
{ F# F# ( Fi )
FNOME NOME ( Smith
STATUS 20
CIDADE : Londres
o satisfaz, enquanto a tupla
{ F# : F# ( F6 )
FNOME NOME ( Smith
STATUS : 50
CIDADE Roma
no o satisfaz. Na verdade, se o usurio final apresentar
essa ltima tupla para insero, o sistema s poder
verificar se ela no viola alguma restrio de integridade
conhecida. Supondo-se que no, o sistema tentar aceitar a
tupla para insero e a tratar como uma proposio
verdadeira desse momento em diante.
Ento, repetimos: o sistema no sabe (e no pode saber) nem
entende 100% o predicado de fornecedores. Porm, ele conhece
uma boa aproximao para esse predicado; para sermos
especficos, ele conhece as restries de integridade que se
aplicam a fornecedores. Assim, definimos o predicado de
varivel de relao para a varivel de relao de
fornecedores (ou, de modo mais geral, para qualquer varivel
de relao como a operao AND lgica entre todas as
restries da variveis de relaes que se aplicam a essa
varivel de relao. Por exemplo, o predicado de varivel de
relao para a varivel de relao F semelhante a este:
ISEMPTY ( F WHERE STATUS < 1 OR STATUS > 100 ) ) AND
ISEMPTY ( F WHERE CIDADE = Londres AND STATUS 20 ) ) AND
( COUNT (F) = COIJNT ( F { F# 1 ) )
( claro que, alm disso, o sistema sabe que os atributos F#,
FNOME, STATUS e CIDADE so do tipo F#, NOME, INTEGER e CHAR,
respectivamente.)
224

Ento, observe que h efetivamente dois predicados associados

com qualquer varivel de relao dada: o predicado informal
ou externo, entendido pelos usurios mas no pelo sistema, e
o predicado formal ou interno, entendido pelos usurios e
peio sistema. Alm disso, claro que o predicado interno o
que indicamos pela expresso predicado de varivel de
relao e o predicado interno que o sistema verificar
sempre que houver uma tentativa de atualizao da varivel de
relao em questo. Na verdade, de agora em diante usaremos o
termo predicado (quando em conexo com alguma varivel de
relao) para indicar especificamente o predicado interno
dessa varivel de relao, impedindo declaraes explcitas
em contrrio.
Dadas as definies anteriores, podemos agora enunciar A
Regra Aurea (pelo menos, a primeira verso dessa regra):
No deve ser permitida nenhuma operao de atualizao que
deixe qualquer varivel de relao em
um estado que viole seu prprio predicado.
Tambm devemos enfatizar que varivel de relao no
significa necessariamente uma varivel de relao bsica A
Regra Aurea se aplica a todas as variveis de relaes,
derivadas ou bsicas. Voltaremos a esse ponto no prximo
captulo.
Fechamos esta seo destacando que, assim como toda varivel
de relao tem um predicado, todo banco de dados tambm tem
um predicado associado o predicado de banco de dados para
esse banco de dados, que definimos como a operao AND lgica
de todas as restries de bancos de dados e variveis de
relaes que se aplicam a esse banco de dados. Assim, podemos
agora estender A Regra Aurea: *
No deve ser permitida nenhuma operao de atualizao que
deixe qualquer varivel de relao em um estado que viole seu
prprio predicado. Da mesma forma, no deve ser permitida
nenhuma transao de atualizao que deixe o banco de dados
em um estado que viole seu prprio predicado.
8.7 RESTRIES DE ESTADO E RESTRIES DE TRANSIO
Todas as restries discutidas neste captulo at agora foram
restries de estado: elas estavam relacionadas com estados
corretos do banco de dados. Porm, s vezes necessrio
considerar tambm as restries de transio isto ,
restries sobre transies vlidas de um estado correto para
outro. Por exempio, em um banco de dados de pessoas, haveria
uma srie de restries de transio relacionadas com
mudanas no estado civil. Seriam vlidas todas as transies
a seguir:
Solteiro para casado.
Casado para vivo.
Casado para divorciado.
Vivo para casado.
(etc.), enquanto estas no so:
Solteiro para vivo.
Solteiro para divorciado.
Vivo para divorciado.
Divorciado para vivo.
(etc.). Voltando ao banco de dados de fornecedores e peas,
aqui est outro exemplo (nenhum status de fornecedor deve
jamais diminuir):
CONSTRAINT TRC1 ISEMPTY
F { F#, STATUS } RENAME STATUS AS STATUS
JOIN F { F#, STATUS
WHERE STATUS > STATUS
*Se forem admitidas vrias atribuies (uma possibilidade
mencionada em uma nota de rodap anterior), talvez pudssemos
dei xa A Regra Aurea em sua forma original e mais simples.
225

Explicao: introduzimos a conveno de que um nome de

varivel de relao com apstrofo, como F no exemplo, se
refere a uma varivel de relao como ela era antes da
atualizao sob considerao. A restrio do exemplo pode
ento ser entendida como: se (a) fizermos a juno (sobre
nmeros de fornecedores) da relao que o valor da varivel
de relao F antes da atualizao com a relao que seu
valor posterior, e se (b) escolhermos nessa juno as tuplas
para as quais o valor de status antigo maior que o novo,
ento (c) o resultado final dever ser vazio. (Como a juno
sobre nmeros de fornecedores, qualquer tupla no resultado
da juno para a qual o valor de status antigo fosse maior
que o do novo representaria um fornecedor cujo status
diminuiu.)
Nota: a restrio TRC1 uma restrio de transio de
varivel de relao (ela se aplica apenas a uma nica
varivel de relao, ou seja, fornecedores) e, portanto, a
verificao imediata. Em contraste, aqui est um exemplo de
uma restrio de transio de banco de dados (a quantidade
total de qualquer pea dada, considerada sobre todos os
fornecedores, nunca pode diminuir):
CONSTRAINT TRC2 ISEMPTY
( ( ( SUMMARIZE FP PER F { F# } ADD SUM ( QDE ) AS FQ )
JOIN
( SUMMARIZE FP PER F { F# } ADD SUM ( QDE ) AS FQ )
WHERE FQ > FQ ) ;
A restrio TRC2 uma restrio de transio de banco de
dados (ela envolve duas variveis de relaes distintas,
fornecedores e remessas); portanto, a verificao adiada
at o momento de COMMIT, e os nomes de variveis de relaes
F e FP significam variveis de relaes F e FP como elas
eram em
BEGIN TRANSACTION.
O conceito de restries de estado e restries de transio
no tem significado para restries de tipo ou de atributo.
8.8 CHAVES
O modelo relaciona! sempre enfatizou o conceito de chaves,
embora tenhamos visto que elas so na realidade apenas um
caso especial apesar de importante de um fenmeno mais
geral. Nesta seo, vamos voltar nossa ateno
especificamente para as chaves.
Nota: embora as idias bsicas sejam bastante simples nesse
caso, infelizmente existe um fator complicador significativo:
os nulos. A possibilidade de que (por exemplo) uma dada chave
estrangeira possa permitir nulos complica o quadro de forma
considervel. No entanto, os nulos formam por si prprios um
tpico extenso e poderia ser inadequado discuti-lo em
detalhes neste momento. Portanto, considerando razes
pedaggicas, vamos ignorar quase totalmente os nulos nesta
seo; voltaremos a discutir o impacto dos nulos sobre chaves
quando discutirmos os nulos em geral, no Captulo 18. (Na
verdade, nossa opinio que os nulos so um equvoco e nunca
deveriam ter sido introduzidos, mas seria errado ignor-los
por completo em um livro desta natureza.)
Chaves candidatas
Seja R uma varivel de relao. Por definio, o conjunto de
todos os atributos de R tem a propriedade de unicidade
significando que, em qualquer instante, no h duas tuplas no
valor de R nesse instante que sejam duplicatas uma da outra.
Na prtica, ocorre com freqncia que algum subconjunto
prprio do conjunto de todos os atributos de R tambm tenha a
propriedade de unicidade; por exemplo, no caso da varivel de
relao de fornecedores F, o subconjunto que contm apenas o
atributo F# tem essa propriedade. Esses fatos constituem a
intuio que rege a definio de chave candidata:
Seja K um conjunto de atributos da varivel de relao R.
Ento, K uma chave candidata paraR se e somente se ela
possui ambas as propriedades a seguir:
Observe que a definio se aplica especificamente a variveis
de relaes. possvel definir uma noo anloga tambm para
226 valores de relaes [3.3] mas as variveis de relaes
so o caso importante.

a. Unicidade: nenhum valor vlido deR contm duas tuplas

diferentes com o mesmo valor para K.
b. Irredutibilidade: nenhum subconjunto prprio de K tem a
propriedade de unicidade. Note que toda varivel de relao
tem pelo menos uma chave candidata. A propriedade de
unicidade de tais chaves auto-explicativa. Quanto
propriedade de irredutibilidade, o ponto que, se fssemos
especificar uma chave candidata que no fosse irredutvel,
o sistema no ficaria a par do real estado de coisas, e assim
no seria capaz de impor adequadamente a restrio de
integridade associada. Por exemplo, suponha que fssemos
definir a combinao {F#,CIDADE} em vez de {F#} apenas
como chave candidata para fornecedores. Ento, o sistema no
imporia a restrio de que nmeros de fornecedores so
globalmente nicos; em vez disso, imporia somente a
condio mais fraca de serem os nmeros de fornecedores
localmente nicos dentro da cidade. Por essa razo, entre
outras, exigimos que chaves candidatas no incluam atributos
que sejam irrelevantes para fins de identificao nica. *
A propsito, a irredutibilidade no sentido mencionado antes
dita minimalidade na maior parte da literatura (inclusive em
edies anteriores deste livro). Porm minimalidade no
realmente o mais correto, porque dizer que uma chave
candidata K1 mnima no significa que no se possa achar
uma outra chave candidata K2 com menos componentes;
inteiramente possvel que (por exemplo) K1 tenha quatro
componentes e K2 apenas dois. Ficaremos com o termo
irredutvel.
Em Tutorial D, usaremos a sintaxe:
KEY { <lista_com_vrgulas de nomes de atributos>
dentro de uma definio de varivel de relao, a fim de
especificar uma chave candidata para a varivel de relao.
Aqui esto alguns exemplos:
VAR F BASE RELATION
{ F# F#,
SNOME NOME,
STATUS INTEGER,
CIDADE CHAR
KEY { F# } ;
Nota: em captulos anteriores, mostramos essa definio com
uma clusula PRIMARY KEY, e no com uma clusula KEY.
Consulte a subseo Chaves primrias e chaves alternativas
mais adiante nesta seo, para ver uma discusso e uma
explicao adicional.
VAR FP BASE RELATION
{ F# F#,
P# P#,
QDE QDE }
KEY { F#, P# 1 . . . ;
Esse exemplo mostra uma varivel de relao com uma chave
candidata composta (isto , uma chave candidata envolvendo
mais de um atributo). Uma chave candidata simples aquela
que no composta.
VAR ELEMENTO BASE RELATION { NOME NOME,
SMBOLO CHAR,
ATMICO# INTEGER }
KEY { NOME
KEY { SMBOLO
KEY { ATMICO# } ;
Esse exemplo mostra uma varivel de relao com diversas
chaves candidatas (simples) distintas.
* Outra boa razo para se exigir que chaves candidatas sejam
irredutveis tem a ver com chaves estrangeiras
correspondentes. Qualquer chave estrangeira que referenciasse
uma chave candidata redutvel (se isso fosse possvel)
seria tambm redutvel e a varivel
de relao que a contm estaria ento quase certamente
violando os princpios de normalizao avanada (consulte o
Captulo 11). 227

VAR CASAMENTO BASE RELATION { MARIDO NOME,

ESPOSA NOME,
DATA /* do casamento / DATE
/* supondo-se que no h poliandria nem poliginia, e
/ que nenhum marido e nenhuma esposa se casam um com /
/ o outro mais de uma vez ... *1
KEY { MARIDO, DATA
KEY { DATA, ESPOSA
KEY { ESPOSA, MARIDO
Esse exemplo mostra uma varivel de relao com diversas
chaves candidatas compostas (e sobrepostas) distintas.
claro que, como destacamos na Seo 8.4, uma definio de
chave candidata na realidade apenas uma abreviao para uma
certa restrio de varivel de relao. A abreviao til
porque o conceito de chave candidata muito importante de um
ponto de vista pragmtico. Para sermos especficos, as chaves
candidatas fornecem o mecanismo bsico de endereamento no
nvel de tupla no modelo relacional isso significa que o
nico modo garantido pelo sistema de se apontar com preciso
alguma tupla especfica pelo valor de alguma chave
candidata. Por exemplo, a expresso:
F WHERE F# = F# ( F3 )
oferece a garantia de fornecer no mximo uma tupla (mais
precisamente, ela produz uma relao que contm no mximo uma
tupla). Ao contrrio, a expresso
F WHERE CIDADE = Paris
fornecer um nmero imprevisvel de tuplas, em geral. Segue-
se que chaves candidatas so to fundamentais para a operao
bem-sucedida de um sistema relacional quanto os endereos da
memria principal para a operao bem-sucedida da mquina
subjacente. Em conseqncia:
1. Variveis de relaes que no tenham uma chave candidata
isto , variveis de relaes que permitam tuplas
duplicadas certamente exibiro um comportamento estranho e
anmalo em algumas circunstncias.
2. Um sistema que no tenha conhecimento de chaves candidatas
certamente exibir em algumas ocasies um comportamento que
no verdadeiramente relacional, mesmo se as variveis de
relaes com que ele lida sejam de fato variveis de relaes
verdadeiras e no permitem tuplas duplicadas.
O comportamento mencionado antes como estranho e anmalo e
no verdadeiramente relaciona 1 tem a ver com questes como
atualizao de vises e otimizao. Consulte os Captulos 9 e
17, respectivamente.
Alguns pontos finais para fecharmos esta subseo:
Um superconjunto de chave candidata uma superchave. Por
exemplo, o conjunto de atributos {F#,CIDADE} uma superchave
para a varivel de relao F. Uma superchave tem a
propriedade de unicidade, mas no necessariamente a
propriedade de irredutibilidade ( claro que uma chave
candidata um caso especial de uma superchave).
Se FK uma superchave para a varivel de relao R e A
um atributo de R, ento a dependncia funcional FK > A
necessariamente verdadeira em R (esse conceito importante
ser discutido em profundidade no Captulo 10). De fato,
podemos definir uma superchave como um subconjunto FK dos
atributos de R, tal que a dependncia funcional FK A
verdadeira para todos os atributos A de R.
228

Por fim, observe que a noo lgica de chave candidata no

deve ser confundida com a noo fsica de um ndice
exclusivo (embora essa ltima seja usada com muita
freqncia para implementar a primeira). Em outras palavras,
no h nenhuma implicao que tenha de existir um ndice (ou,
de fato, qualquer outro caminho de acesso fsico especial) em
uma chave candidata. Na prtica, provavelmente haver algum
caminho de acesso especial, mas o fato dele existir ou no
est alm do escopo do modelo relaciona!.
Chaves primrias e chaves alternativas
Como vimos, possvel que uma dada varivel de relao tenha
mais de uma chave candidata. Em tal caso, o modelo relacional
historicamente tem exigido pelo menos no caso de variveis
de relaes bsicas que exatamente uma dessas chaves
candidatas seja escolhida como a chave primria, e as outras
sejam ento chamadas chaves alternativas. Por exemplo, em
ELEMENTOS, poderamos escolher o {SIMBOLO} como chave
primria; {NOME} e {ATOMICO#} seriam ento chaves
alternativas. E, no caso em que s existe uma chave
candidata, o modelo relaciona! (mais uma vez) historicamente
tem exigido que essa chave candidata seja designada como a
chave primria para a varivel de relao em questo.
Portanto, toda varivel de relao bsica sempre tem uma
chave primria.
Ora, escolher uma chave candidata (nos casos em que existe
uma escolha) como chave primria poderia ser um boa idia em
muitos casos at mesmo na maioria dos casos mas no pode
ser justificada em todos os casos, inequivocamente.
Argumentos detalhados em apoio a essa posio so dados na
referncia [8.13]; aqui vamos apenas observar um caso em que
a escolha de qual chave candidata ser primria
essencialmente arbitrria (para citar Codd [8.8], a base
norma! para fazer a escolha] a simplicidade, mas esse
aspecto est fora do escopo do modelo relacional). Em nossos
prprios exemplos, definiremos s vezes uma chave primria e
em outras vezes no ( claro que sempre definiremos pelo
menos uma chave candidata).
Chaves estrangeiras
Informalmente, uma chave estrangeira um conjunto de
atributos de uma varivel de relao R2 cujos valores devem
obrigatoriamente corresponder a valores de alguma chave
candidata de alguma varivel de relao Ri. Por exemplo,
considere o conjunto de atributos {F#} da varivel de relao
FP (um conjunto que contm apenas um atributo, claro). Deve
ficar claro que um dado valor para {F#} deve poder aparecer
na varivel de relao FP somente se esse mesmo valor tambm
aparecer como um valor da nica chave candidata {F#} para a
varivel de relao F (no podemos ter uma remessa para um
fornecedor que no existe). Da mesma forma, um dado valor
para o conjunto de atributos {P#} deve poder aparecer na
varivel de relao FP somente se o mesmo valor tambm
aparecer como valor da nica chave candidata {P#} para a
varivel de relao P (tambm no podemos ter uma remessa de
uma pea que no existe). Esses exemplos servem como
motivao desta definio:
Seja R2 uma varivel de relao. Ento, uma chave
estrangeira em R2 um conjunto de atributos de R2, digamos
FK, tal que:
a. Existe uma varivel de relao Ri (Ri e R2 no
necessariamente distintas) com uma chave candidata CK, e
b. Para sempre, cada valor de FK no valor atua! de R2
idntico ao valor de CK em alguma tupla no valor atual de RI.

Surgem alguns pontos importantes:

1. A definio exige que todo valor de uma dada chave
estrangeira tem de aparecer como valor de uma chave candidata
correspondente (a qual em geral, mas nem sempre,
especificamente uma chave primria). Porm, observe que a
recproca no um exigncia; isto , a chave candidata
correspondente a uma dada chave estrangeira poderia conter um
valor que no aparece no momento como
um valor dessa chave estrangeira. No caso de fornecedores e
peas, por exemplo (amostras de valo- 229

res como na Figura 3.8), o fornecedor nmero F5 aparece na

varivel de relao F, mas no na varivel de relao FP,
porque o fornecedor F5 no est fornecendo peas no momento.
2. Uma chave estrangeira simples ou composta, conforme a
chave candidata que corresponde a ela seja simples ou
composta.
3. Cada atributo de uma dada chave estrangeira deve ter o
mesmo nome e tipo que o componente correspondente da chave
candidata associada.
4. Terminologia: um valor de chave estrangeira representa uma
referncia tupla que contm o valor da chave candidata
associada (a tupla referenciada). O problema de garantir que
o banco de dados no inclui quaisquer valores invlidos de
chave estrangeira ento conhecido como o problema de
integridade referencial. A restrio de que valores de uma
dada chave estrangeira devem se ajustar a valores da chave
candidata correspondente chama-se restrio referencial.
Dizemos que a varivel de relao que contm a chave
estrangeira a varivel de relao referente e que a
varivel de relao que contm a chave candidata
correspondente a varivel de relao referida.
5. Diagramas referenciais: considere mais uma vez
fornecedores e peas. Podemos representar as restries
referenciais que existem nesse banco de dados por meio do
seguinte diagrama referencial:
F FP * P
Cada seta significa que h uma chave estrangeira na varivel
de relao da qual a seta emerge, que se refere
especificamente a alguma chave candidata na varivel de
relao para a qual a seta aponta. Nota: por simplicidade e
clareza, s vezes uma boa idia identificar cada seta em um
diagrama referencial com o(s) nome(s) do(s) atributo(s) que
constitui(em) a chave estrangeira relevante.* Por exemplo:
F# P#
F FP * P
Porm, neste livro mostraremos essas etiquetas (labels)
apenas quando omiti-las puder levar a confuso ou
ambigidade.
6. claro que uma dada varivel de relao pode ser uma
relao referida e referente, como acontece com a relao R2
no diagrama a seguir:
R3 * R2 * Ri
E conveniente introduzir a expresso caminho referencial.
Sejam as relaes Rn, R(n-i), ... R2, Ri tais que exista uma
restrio referencial de Rn para R(n-i), uma restrio
referencial de R(n-i) para R(n-2), ... e um restrio
referencial de R2 para Ri:
Rn * R(n-1) * R(n-2) *... *R2 *Ri
Ento, a cadeia de setas de Rn at Ri representa um caminho
referencial de Rn a Ri.
7. Observe que as variveis de relaes Ri e R2 na definio
de chaves estrangeiras no so necessa ria- mente distintas.
Isto , uma varivel de relao poderia incluir uma chave
estrangeira cujos valores devem combinar com os valores de
alguma chave candidata na mesma varivel de relao. Por
exemplo, considere a definio de varivel de relao a
seguir (explicaremos a sintaxe em breve mas, de qualquer
modo, ela deve ser auto-explicativa):
VAR EMP BASE RELATION
EMP# EMP#, . . ., GER EMP# EMP#, . .
PRIMARY KEY { EMP# }
FOREIGN KEY { RENAME GER EMP# AS EMP# } REFERENCES EMP
De forma alternativa (e talvez de preferncia), poderamos
nomear as chaves estrangeiras, e depois usar esses nomes para
iden230 tificar as setas.

Aqui, o atributo GER_EMP# representa o nmero de empregado do

gerente do empregado identificado por EMP#. Por exemplo, a
tupla para o empregado E4 pode incluir um valor GER_EMP#
igual a E3, que representa uma referncia tupla de EMP para
o empregado E3. (Observe a necessidade de renomear um
atributo de chave estrangeira nesse exemplo, a fim de
obedecer s exigncias do pargrafo 3 anterior.) Tal varivel
de relao s vezes dita auto-referente. Exerccio: crie
algumas amostras de dados para esse exemplo.
8. Variveis de relaes auto-referentes como EMP na verdade
representam um caso particular de uma situao mais geral
ou seja, podem existir ciclos referenciais. As variveis de
relaes Rn, R(n-i), R(n-2), ..., R2, Ri formam um ciclo
referencial se Rn incluir uma chave estrangeira fazendo
referncia a R(n-1), R(n-1) incluir uma chave estrangeira
fazendo referncia a R(n-2), ... e assim por diante, e
finalmente Ri incluir uma chave estrangeira fazendo
referncia de novo a Rn. De modo mais sucinto, existe um
ciclo referencial se existe um caminho referencial de alguma
varivel de relao Rn para ela mesma:
Rn R(n-1) * R(n-2) +... *R2 * Ri * Rn
9. Associaes de chaves estrangeiras para chaves candidatas
so ditas s vezes serem a cola que mantm unido o banco de
dados. Outro modo de dizer isso que essas combinaes
representam certos relacionamentos entre tuplas. Porm,
observe com cuidado que nem todos esses relacionamentos so
representados por chaves desse modo. Por exemplo, existe um
relacionamento (co-localizao) entre fornecedores e peas,
representado pelos atributos CIDADE das relaes F e P; um
dado fornecedor e uma certa pea so co-localizados se esto
localizados na mesma cidade. Contudo, esse relacionamento no
representado por chaves.
10. Historicamente, o conceito de chave estrangeira tem sido
definido apenas para variveis de relaes bsicas, um fato
que por si s levanta algumas questes (veja a discusso do
Princpio da permutabilidade no Captulo 9, Seo 9.2). No
impomos tal restrio aqui; no entanto, vamos limitar nossas
discusses somente s variveis de relaes bsicas (onde
fizer diferena), por razes de simplicidade.
11. Originalmente, o modelo relacional exigia que as chaves
estrangeiras referenciassem, de forma muito especfica,
chaves primrias, no apenas chaves candidatas (por exemplo,
veja de novo a referncia [8.8]). Rejeitamos essa limitao
como desnecessria e indesejvel em geral, embora ela possa
com freqncia constituir boa disciplina na prtica [8.131.
Normalmente, seguiremos essa disciplina em nossos prprios
exemplos.
12. Juntamente com o conceito de chave estrangeira, o modelo
relacional inclui as seguinte regra (a regra de integridade
referencial):
Integridade referencial: o banco de dados no deve conter
quaisquer valores de chaves estrangeiras no-associados.
Aqui, a expresso valor de chave estrangeira no
correspondente significa apenas um valor de chave
estrangeira em alguma varivel de relao referente para a
qual no existe um valor associado da chave candidata
relevante na varivel de relao referenciada relevante. Em
outras palavras, a restrio diz apenas: se B faz referncia
a A, ento A tem de existir.
Ento, aqui est a sintaxe para a definio de uma chave
estrangeira:
FOREIGN KEY { <lista com vrgulas de itens > } REFERENCES
<nome de varivel de relao>
*A regra de integridade referencial pode ser considerada uma
metarrestrio: ela irriplica que qualquer banco de dados
deve estar sujeito a certas restries dc integridade
especficas ao banco de dados em questo que, juntas,
garantem que a regra no ser violada por esse banco de
dados. Observamos de passagem que o modelo relacional
considerado como incluindo outra metarrestrio, a regra de
integridade de entidades; essa ltima regra est relacionada
com nulos e, portanto, adiaremos sua dis cuss para o
Captulo 18. 231

Essa clusula aparece dentro de uma definio de varivel de

relao referente. Observe que:
Cada <item> um <nome de atributo> da varivel de relao
referente ou uma expresso da forma:
RENAME <nome de atributo> AS <nome de atributo>
(veja a varivel de relao auto-referente EMP anterior como
exemplo do caso de RENAME).
O <nome de varivel de relao> identifica a varivel de
relao referenciada.
J foram dados exemplos em muitos pontos anteriores no livro
(por exemplo, veja a Figura 3.9 no Captulo 3). Nota: claro
que, como mencionamos na Seo 8.5, uma definio de chave
estrangeira na realidade apenas uma abreviao para uma
certa restrio de banco de dados (ou uma certa restrio de
varivel de relao, no caso de uma varivel de relao auto-
referente) a menos que a definio da chave estrangeira
seja estendida para incluir certas aes referenciais, e
nesse caso ela se torna mais que apenas uma restrio de
integridade. Veja as duas subsees imediatamente a seguir.
Aes referenciais
Considere a seguinte instruo:
DELETE F WHERE F# = F# ( Fi ) ;
Suponha que essa operao DELETE faz exatamente o que seu
nome diz isto , elimina a tupla de fornecedor
correspondente ao fornecedor Fi, nem mais nem menos. Suponha
tambm que (a) o banco de dados inclui algumas remessas para
o fornecedor Fi, como na Figura 3.8, e (b) a aplicao no
continua a eliminar essas remessas. Ento, quando o sistema
verificar a restrio referencial de remessas para
fornecedores, encontrar uma violao e ocorrer um erro.
Nota: como a restrio referencial no caso uma restrio de
banco de dados, a verificao ser feita no momento de COMMIT
pelo menos conceitualmente (o sistema pode verificar de
fato a restrio logo que DELETE for executada, mas uma
violao nesse momento no ser necessariamente um erro;
significar apenas que o sistema ter de fazer a verificao
de novo no momento de COMMIT).
Contudo, existe uma abordagem alternativa, uma que pode ser
prefervel em alguns casos e que faz
o sistema executar uma ao de compensao apropriada que ir
garantir que o resultado geral ainda
atender restrio. No exemplo, a ao de compensao bvia
seria o sistema eliminar as remessas para
o fornecedor Fi de forma automtica. Podemos conseguir esse
efeito estendendo a definio de chave
estrangeira, assim:
VAR FP BASE RELATION {
FOREIGN KEY { F# } REFERENCES F
ON DELETE CASCADE
A especificao ON DELETE CASCADE define uma regra DELETE
para essa chave estrangeira em particular, e a especificao
CASCADE a ao referencial para essa regra DELETE. O
significa dessas especificaes que uma operao DELETE
sobre a varivel de relao de fornecedores deve propagar a
eliminao at as tuplas correspondentes na varivel de
relao de remessas.
Outra ao referencial comum RESTRICT (no relacionada com
o operador de restrio da lgebra relacional). No caso,
RESTRICT significaria que operaes DELETE so restritas ao
caso em que no h nenhuma remessa correspondente (elas so
rejeitadas caso contrrio). Omitir uma ao referencial para
uma determinada chave estrangeira equivalente a especificar
a ao NO ACTION, que significa exatamente o que seu nome
diz a operao DELETE executada exatamente como foi
solicitada, nem mais nem menos. (E claro que se NO ACTION for
especificada no caso e um fornecedor que tenha remessas
correspondentes for eliminado, teremos em seguida uma
violao de integrida232 de referencial.) Surgem pontos
importantes:

1. DELETE no a nica operao para a qual as aes

referenciais fazem sentido. Por exemplo, o que aconteceria se
tentssemos atualizar o nmero de fornecedor correspondente a
um fornecedor para o qual existisse pelo menos uma remessa
associada? E claro que precisaramos tambm de uma regra
UPDATE, alm de uma regra DELETE. Em geral, h as mesmas
possibilidades para UPDATE que existem para DELETE:
CASCADE UPDATE atua em cascata para atualizar a chave
estrangeira tambm nessas remessas associadas.
RESTRICT a operao UPDATE restrita ao caso em que no
h nenhuma remessa associada (do contrrio, ela rejeitada).

NO ACTION UPDATE executada exatamente como foi

solicitada.
2. claro que CASCADE, RESTRICT e NO ACTION no so as
nicas aes referenciais possveis so apenas as que se
exigem normalmente na prtica. Porm, em princpio, poderia
haver um nmero arbitrrio de respostas possveis a, por
exemplo, uma tentativa de eliminar um determinado fornecedor.
Vejamos:
As informaes poderiam ser gravadas em algum banco de
dados de arquivo morto.
As remessas para o fornecedor em questo poderiam ser
transferidas para algum outro fornecedor, e assim por diante.
Nunca ser vivel fornecer a sintaxe declarativa para todas
as respostas imaginveis. Assim, em geral, deve ser possvel
especificar uma ao referencial da forma CALL proc (...),
onde proc um procedimento definido pelo usurio.
Nota: a execuo desse procedimento deve ser considerada
parte da execuo da transao que provocou a verificao de
integridade. Alm disso, essa verificao de integridade deve
ser executada novamente aps esse procedimento ser executado
(o procedimento no deve obviamente deixar o banco de dados
em um estado que viole a restrio).
3. Sejam R2 e Ri, respectivamente uma varivel de relao
referente e a varivel de relao referida correspondente:
R2 * Ri
Suponha que a regra DELETE aplicvel especifica CASCADE.
ento, uma operao DELETE sobre uma dada tupla de Ri
implicar uma DELETE em certas tuplas da varivel de relao
R2 (em geral). Agora, suponha que a varivel de relao R2
seja por sua vez referenciada por alguma outra varivel de
relao R3:
R3 * R2 * Ri
Ento, o efeito da operao DELETE implcita sobre as tuplas
de R2 definido exatamente como se fosse feita uma tentativa
de eliminar essas tuplas de forma direta; isto , ele depende
da regra DELETE especificada para a restrio referencial de
R3 para R2. Se essa DELETE implcita falhar (devido regra
DELETE de R3 para R2 ou por qualquer outra razo), ento a
operao inteira falhar, e o banco de dados permanecer
inalterado. E assim por diante, recursivamente, at qualquer
nmero de nveis.
Aplicam-se comentrios anlogos tambm regra CAS CADE
UPDATE, mutatis mutandis, se a chave estrangeira na varivel
de relao R2 tiver quaisquer atributos em comum com a chave
candidata da varivel de relao referenciada pela chave
estrangeira em R3.
4. Conclumos do que foi dito que, de um ponto de vista
lgico, as atualizaes de bancos de dados so sempre
atmicas (tudo ou nada), mesmo se nos bastidores elas
envolvem diversas atualizaes sobre diversas variveis de
relaes, em virtude de, por exemplo, uma ao referencial
CASCADE.
233

Procedimentos triggers
Como voc j deve ter percebido (e como de fato o comentrio
da subseo anterior a respeito de procedimentos definidos
pelo usurio deve ter sugerido), todo o conceito de aes
referenciais nos leva at alm das restries de integridade,
em direo aos procedimentos triggers. Um procedimento
trigger (normalmente chamado apenas trigger na literatura)
um procedimento invocado automaticamente na ocorrncia de
algum evento especificado ou de uma condio de trigger. A
condio de trigger em geral a execuo de alguma operao
de atualizao do banco de dados, mas poderia ser por exemplo
a ocorrncia de uma exceo especificada (em particular, a
violao de uma determinao restrio de integridade) ou a
passagem de um certo intervalo de tempo. As aes
referenciais CASCADE fornecem um exemplo simples de
procedimento trigger (especificado de forma declarativa, como
podemos observar!).
Em geral, procedimentos triggers se aplicam a uma variedade
muito mais ampla de problemas que apenas a questo da
integridade que o tpico deste captulo (uma boa lista
dessas aplicaes pode ser encontrada na referncia [8.1]).
Porm, eles representam sozinhos um assunto extenso, um
tpico que est alm do escopo deste captulo (consulte a
referncia [8.22] para ver uma discusso mais completa).
Gostaramos de dizer que, embora os procedimentos triggers
certamente sejam teis para muitos fins, eles normalmente no
so uma boa abordagem para o problema especfico de
integridade de bancos de dados, por razes bvias (abordagens
declarativas, se forem possveis, sempre sero preferveis).
Nota:
essas observaes no significam a sugesto de que as aes
referenciais so uma idia ruim. Embora seja verdade que as
aes referenciais provocam a chamada de certos
procedimentos, pelo menos elas so (como j observamos)
especificadas de forma declarativa.
8.9 RECURSOS DE SQL
O esquema de classificao de restries de integridade da
SQL muito diferente daqueles descritos nas Sees 8.1 a
8.5. Antes de tudo, ele classifica as restries em trs
amplas categorias, assim:
Restries de domnios
Restries de tabelas bsicas
Restries gerais (assertivas)
Entretanto, as restries de domnios no so iguais s
nossas restries de tipo, restries de tabelas bsicas
no so iguais s nossas restries de variveis de relaes,
e assertivas no so iguais s nossas restries de bancos
de dados. Na verdade:
A SQL no admite realmente restries de tipo de forma
alguma (porque, claro, ela na realidade no admite tipos de
forma alguma, exceto alguns tipos embutidos).
As restries de domnios de SQL so uma forma
generalizada indesejvel de nossas restries de atributos
(lembre-se de que os domnios no estilo de SQL no so na
realidade domnios de modo algum no sentido relaciona!).
As restries de tabelas bsicas e assertivas de SQL (que
so na verdade intercambiveis) dificilmente seriam
equivalentes ao conjunto de nossas restries de variveis de
relaes e de bancos de dados.
Observamos tambm que a SQL no fornece nenhum suporte para
restries de transio, nem admite no momento procedimentos
triggers, embora uma parte desse suporte esteja includa na
SQL3 (consulte o Apndice B).
Restries de domnios
Uma restrio de domnio no estilo de SQL uma restrio que
se aplica a cada coluna definida no domf234 nio em questo.
Aqui est um exemplo:

CREATE DOMAIN COR CHAR(6) DEFAULT ???

CONSTRAINT VALIDCOLORS
CHECK ( VALUE IN
Vermelho, Amarelo, Azul , Verde, ???
Suponha que CREATE TABLE para a tabela bsica P seja
semelhante a:
CREATE TABLE P ( ... , COR COR,
Ento, como default, se o usurio inserir uma linha de pea e
no fornecer um valor de COR para essa linha, o valor ???
ser inserido nessa posio. Como alternativa, se o usurio
fornecer um valor de COR, mas ele no fizer parte do conjunto
vlido, a operao falhar e o sistema produzir um
diagnstico apropriado que mencionar a restrio
VALID_COLORS pelo nome.
Vimos na Seo 8.2 que uma restrio de domnio ou
melhor, deve ser conceitualmente nada alm de uma
enumerao dos valores que formam esse domnio, e o exemplo
de VALID COLORS de fato sustenta essa definio. Porm, em
geral, a SQL permite que uma restrio de domnio envolva uma
expresso booleana de complexidade arbitrria; portanto, por
exemplo, os valores vlidos para algum domnio D podem
depender dos valores presentes no momento em alguma tabela T.
Voc deve meditar sobre algumas implicaes dessa
permissividade no justificada.
Restries de tabelas bsicas
Uma restrio de tabela bsica de SQL qualquer das
seguintes:
Uma definio de chave candidata
Uma definio de chave estrangeira
Uma definio de restrio de verificao
Discutiremos cada caso em detalhes a seguir. Nota: qualquer
dessas definies pode ser precedida opcionalmente pela
sentena CONSTRAINT <nome da restrio>, fornecendo assim
um nome para a nova restrio (o mesmo vale para restries
de domnios, como vimos antes no exemplo de VALID_COLORS).
Para abreviar, vamos ignorar essa opo.
Chaves candidatas: uma definio de chave candidata tem a
forma:
UNIQUE ( <lista com vrgulas de nomes de colunas>
ou a forma:
PRIMARY KEY ( <lista com vrgulas de nomes de colunas>
Uma <lista_com_vrgulas de nomes de colunas> no deve ser
vazia em nenhum dos casos. Uma determinada tabela bsica pode
ter no mximo uma especificao de PRIMARY KEY, mas qualquer
nmero de especificaes UNIQUE. No caso de PRIMARY KEY, cada
coluna especificada , alm disso, considerada NOT NULL,
mesmo que NOT NULL no seja especificada de forma explcita
(veja a discusso sobre restries de verificao a seguir).
Chaves estrangeiras: uma definio de chave estrangeira obtm
a forma:
FOREIGN KEY ( <lista com vrgulas de nomes de colunas>
REFERENCES <nome de tabela bsica> [ ( <lista_com_vrgulas de
nomes de colunas> ) 1
[ ON DELETE <ao referencial> ]
ON UPDATE <ao referencial> 1
235

onde <ao referencial> NO ACTION (o default) ou CASCADE ou

SET DEFAULT ou SET NULL. Adiaremos a discusso de SET DEFAULT
e SET NULL para o Captulo 18. A segunda <lista_com_vrgulas
de nomes de colunas> necessria se a chave estrangeira faz
referncia a uma chave candidata que no uma chave
primria. Nota: a correspondncia de chave estrangeira para
chave candidata feita com base no nos nomes de colunas,
mas na posio de colunas (da esquerda para a direita) dentro
das listas_com_vrgulas.
Restries de verificao: uma definio de restrio de
verificao toma a forma:
CHECK ( <expresso condicional>
Uma tentativa de criar uma linha r dentro da tabela bsica T
considerada uma violao a uma restrio de verificao
para T se a expresso condicional especificada dentro dessa
restrio tiver o valor falso para r. Nota: as expresses
condicionais so o anlogo em SQL daquilo que chamamos em
outros lugares expresses booleanas. Elas sero explicadas em
detalhes no Apndice A. Observe em particular que (nesse
contexto), a expresso condicional pode ser arbitrariamente
complexa ela no est limitada explicitamente a uma
condio que se refira apenas a T, mas pode se referir a
qualquer outro item no banco de dados. Mais uma vez, procure
meditar sobre algumas implicaes dessa permissividade no
justificada.
Ento, aqui est um exemplo de CREATE TABLE envolvendo
restries de tabelas bsicas dos trs tipos:
CREATE TABLE FP
( F# F# NOT NULL, P# P# NOT NULL, QDE QDE NOT NULL,
PRIMARY KEY ( F#, P# ),
FOREIGN KEY ( F# ) REFERENCES F
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY ( P# ) REFERENCES 1
ON DELETE CASCADE
ON UPDATE CASCADE.
CHECK ( QDE > O AND QDE < 5001
Estamos supondo aqui que (a) os domnios F#, P# e QDE j
foram definidos e que (b) F# e P# foram definidos de modo
explcito como chaves primrias para as tabelas F e P,
respectivamente. Alm disso, tambm fazemos uso deliberado da
abreviao pela qual uma restrio de verificao da forma:
CHECK ( <nome de coluna> IS NOT NULL
pode ser substituda por uma simples especificao NOT NULL
na definio da coluna em questo. No exemplo, substitumos
assim trs restries de verificao um pouco incmodas por
trs especificaes simples de NOT NULL.
Fechamos esta subseo com um comentrio sobre um ponto de
certa forma estranho, ou seja: uma restrio de tabela bsica
de SQL sempre considerada satisfeita se a tabela bsica
est vazia mesmo que a restrio seja da forma esta tabela
no deve estar vazia!
Assertivas
No restante desta seo, vamos concentrar nossa ateno no
terceiro caso, as restries gerais ou assertivas. As
restries gerais so definidas por meio da sintaxe de CREATE
ASSERTION:
CREATE ASSERTION <nome de restrio>
CHECK ( <expresso condicional> )

236

E aqui est a sintaxe de DROP ASSERTION:

DROP ASSERTION <nome de restrio>
Observe que, diferente de todas as outras formas do operador
DROP de SQL discutidas neste livro (DROP DOMAIN, DROP TABLE,
DROP VIEW), DROP ASSERTION no oferece uma opo RESTRICT
versus CASCADE.
Aqui esto alguns exemplos de CREATE ASSERTION:
1. Todo fornecedor tem status pelo menos cinco:
CREATE ASSERTION 1C13 CHECK
( ( SELECT MIN ( F.STATiJS ) FROM F ) > 4 )
2. Toda pea tem um peso positivo:
CREATE ASSERTION 1C18 CHECK
( NOT EXISTS ( SELECT * FROM P
WHERE NOT ( P.PESO > 0.0 ) ) )
3. Todas as peas vermelhas devem estar armazenadas em
Londres:
CREATE ASSERTION 1C99 CHECK
( NOT EXISTS ( SELECT * FROM P
WHERE P.COR = Vermelho
AND P.CIDADE <> Londres
4. Nenhuma remessa tem um peso total (peso da pea vezes
quantidade da remessa) maior que
20.000:
CREATE ASSERTION 1C46 CHECK
( NOT EXISTS ( SELECT * FROM P, FP
WHERE P.P# FP.P#
AND ( P.PESO * FP.QDE ) > 20000.0
5. Nenhum fornecedor com status menor que 20 pode fornecer
qualquer pea em quantidade maior
que 500:
CREATE ASSERTION 1C95 CHECK
( NOT EXISTS ( SELECT * FROM F, FP
WHERE F.STATUS < 20
AND F.F# = FP.F#
AND FP.QDE > 500
Verificao postergada
O esquema de classificao de restries de integridade de
SQL tambm difere do nosso quanto questo de quando a
verificao feita. Em nosso esquema, as restries de
bancos de dados so verificadas no instante de COMMIT, outras
so verificadas imediatamente. Em contraste, em SQL, as
restries podem ser definidas como DEFERRABLE ou NOT
DEFERRABLE; se uma dada restrio DEFERRABLE, ela pode
ainda ser definida como INITIALLY DEFERRED ou INITIALLY
IMMEDIATE, o que define seu estado no incio de cada
transao. As restries NOT DEFERRABLE so sempre
verificadas imediatamente, mas as restries DEFERRABLE podem
ser ativadas e desativadas dinamicamente por meio da
instruo:
SET CONSTRAINTS <lista com vrgulas de nomes de restries>
<opo>
onde <opo> IMMEDIATE ou DEFERRED. Aqui est um exemplo:
SET CONSTRAINTS 1C46, 1C95 DEFERRED ;
237

As restries DEFERRABLE so verificadas apenas quando se

encontram no estado IMMEDIATE. A definio de uma restrio
DEFERRABLE no estado IMMEDIATE faz essa restrio ser
verificada de imediato, claro; se a verificao falhar, SET
IMMEDIATE falhar. O COMMTT fora uma SET IMMEDIATE para
todas as restries DEFERRABLE; se qualquer verificao de
integridade falhar, ento a transao ser retomada.
RESUMO
Neste captulo, discutimos o conceito crucial de integridade.
O problema da integridade o de garantir que os dados no
banco de dados so precisos ou corretos (e, claro, estamos
interessados em solues declarativas para esse problema). Na
verdade, como voc deve ter percebido, nesse contexto
integridade significa semntica: so as restries de
integridade (em particular, os predicados de variveis de
relaes e bancos de dados ver a seguir) que representam o
significado dos dados. E esse o motivo por que, como
afirmamos na Seo 8.6, a integridade tem importncia
crucial.
Dividimos as restries de integridade em quatro categorias:
Uma restrio de tipo especifica os valores vlidos para um
determinado tipo (ou domnio), e verificada durante
invocaes do seletor correspondente.
Uma restrio de atributo especifica os valores vlidos
para um determinado atributo, e nunca deve ser violada.
Uma restrio de varivel de relao especifica os valores
vlidos para uma determinada varivel de relao, e
verificada quando essa varivel de relao atualizada.
Uma restrio de banco de dados especifica os valores
vlidos para um determinado banco de dados, e verificada no
instante de COMMIT.
A operao lgica AND de todas as restries de variveis de
relaes para uma determinada varivel de relao o
predicado de varivel de relao (interno) para essa varivel
de relao. O predicado de varivel de relao o
significado da varivel de relao entendido pelo sistema e
o critrio para aceitao de atualizaes sobre essa varivel
de relao. A Regra Aurea estabelece que nenhuma operao de
atualizao ter jamais permisso para deixar qualquer
varivel de relao em um estado que viole seu prprio
predicado. Por sua vez, o banco de dados global assunto
para um predicado de banco de dados e nenhuma transao ter
permisso para deixar o banco de dados em um estado que viole
esse predicado.
Em seguida, esboamos rapidamente a idia bsica de
restries de transio (as outras restries so restries
de estado). Ento, passamos a discutir os casos especiais
pragmaticamente importantes de chaves candidatas, primrias,
alternativas e estrangeiras. As chaves candidatas satisfazem
s propriedades de uni- cidade e irredutibilidade, e toda
varivel de relao tem pelo menos uma (sem excees!). A
restrio de que os valores de uma determinada chave
estrangeira devem corresponder aos valores da chave candidata
correspondente uma restrio referencial; exploramos
diversas implicaes da idia de integridade referencial,
inclusive em particular a noo de aes referenciais
(especialmente CASCADE). Essa ltima discusso nos levou a
uma breve incurso pelo objetivo dos procedimentos triggers.
Conclumos nossas discusses com um exame dos aspectos
relevantes de SQL. A SQL admite restries de domnios,
restries de tabelas bsicas e assertivas (restries
gerais), e seu suporte para restries de tabelas bsicas
inclui o caso especial do suporte para chaves.
EXERCCIOS
8.1 Usando a sintaxe introduzida nas Sees 8.2 a 8.5,
escrever restries de integridade para o banco de dados de
fornecedores, peas e projetos como a seguir:
a. As nicas cidades vlidas so Londres, Paris, Roma,
Atenas, Oslo, Estocolmo, Madri e Amsterd.
238

h. Os nicos nmeros de fornecedores vlidos so aqueles que

podem ser representados por um string de caracteres de pelo
menos dois caracteres, dos quais o primeiro uma letra F e
os restantes denotam um inteiro decimal no intervalo de 0 a
9999.
c. Todas as peas vermelhas devem pesar menos de 50 libras.
d. Dois projetos no podem estar localizados na mesma cidade.

e. No mximo um fornecedor pode estar localizado em Atenas em

qualquer instante.
f. Nenhuma remessa pode ter uma quantidade maior que o dobro
da mdia de todas as quantidades de remessas.
g. O fornecedor de status mais alto no deve estar localizado
na mesma cidade que o fornecedor de status mais baixo.
h. Todo projeto deve estar localizado em uma cidade na qual
exista pelo menos um fornecedor.
i. Todo projeto deve estar localizado em uma cidade na qual
exista pelo menos um fornecedor desse projeto.
j. Deve existir pelo menos uma pea vermelha.
k. O status de fornecedor mdio deve ser maior que 18.
1. Todo fornecedor de Londres deve fornecer a pea P2.
m. Pelo menos uma pea vermelha deve pesar menos que 50
libras.
n. Fornecedores em Londres devem fornecer mais tipos
diferentes de peas que tornecedores em Paris.
o. Fornecedores em Londres devem fornecer mais peas no total
que fornecedores em Paris.
p. Nenhuma quantidade de remessa pode ser reduzida (em uma
nica atualizao) a menos de metade de seu valor atual.
q. Fornecedores em Atenas s podem mudar para Londres ou
Paris, e fornecedores em Londres s podem mudar para Paris.
8.2 Para cada uma de suas respostas ao Exerccio 8.1,
estabelea se a restrio uma restrio de varivel de
relao ou de banco de dados.
8.3 Para cada uma de suas respostas ao Exerccio 8.1,
estabelea as operaes que poderiam fazer a restrio
aplicvel ser violada.
8.4 Sejam CHAR(5) e CHAR(3) strings de caracteres de
comprimento cinco e trs caracteres, respectivamente. Quantos
tipos existem aqui um ou dois?
8.5 Sejam A e B duas variveis de relaes. Declare a(s)
chave(s) candidata(s) para cada um dos itens a seguir:
a. A WHERE
b. A {...}
c. A TIMES 8
d. A UNION 8
e. A INTERSECT B
f. A MINUS 8
g. A JOIN 8
h. EA XTEND A ADD exp AS Z
i. 5 UMMARIZE A PER 8 ADD exp AS Z
j. A SEMIJOIN B
k. A SEMIMINUS B
Em cada caso, suponha que A e B atendem s exigncias para a
operao em questo (por exemplo, elas so do mesmo tipo, no
caso de UNION).
8.6 Seja R uma varivel de relao de grau n. Qual o nmero
mximo de chaves candidatas que R pode
possuir? 239

8.7 Seja R uma varivel de relao cujos nicos valores

vlidos so as relaes especiais (e muito importantes) de
grau O DEE e DUM. Quais chaves candidatas R possui?
8.8 O texto do captulo discutiu as regras de chaves
estrangeiras DELETE e UPDATE, mas no mencionou nenhuma
regra INSERT de chave estrangeira. Por que no?
8.9 Usando os valores de dados de fornecedores, peas e
projetos da Figura 4.5, diga qual ser o efeito de cada uma
das seguintes operaes:
a. UPDATE projeto J7, definindo CIDADE como Nova York.
b. UPDATE pea P5, definindo P# como P4.
c. UPDATE fornecedor F5, definindo F# como F8, se a ao
referencial aplicvel for RESTRICT.
d. DELETE fornecedor F3, se a ao referencial aplicvel for
CASCADE.
e. DELETE pea P2, se ao referencial aplicvel for
RESTRICT.
f. DELETE projeto J4, se ao referencial aplicvel for
CASCADE.
g. UPDATE remessa Fi-Pi-Ji, definindo F# como F2.
h. UPDATE remessa F5-P5-J5, definindo J# como J7.
i. UPDATE remessa F5-P5-J5, definindo J# como J8.
j. INSERT remessa F5-P6-J7.
k. INSERT remessa F4-P7-J6.
1. INSERT remessa F1-P2-jjj (onde jjj representa um nmero de
projeto padro).
810 Um banco de dados de ensino contm informaes sobre um
esquema de treinamento educacional interno de uma empresa.
Para cada curso de treinamento, o banco de dados contm
detalhes de todos os cursos que so pr-requisitos para esse
curso e todas as ofertas desse curso; e para cada oferta
contm detalhes de todos os professores e todos as matrculas
de alunos para essa oferta, O banco de dados tambm contm
informaes sobre empregados. As variveis de relaes so as
seguintes, em um esboo:
CURSO { CURSO#, TTULO
PREREQ { SUPCURSO#, SUB CURSO# }
OFERTA { CURSO#, OFER#, DATAOFER, LOCAL
PROFESSOR { CURSO#, OFER#, EMP#
MATRCULA { CURSO#, OFER#, EMP#, GRADE
EMPREGADO { EMP#, ENOME, CARGO
O significado da varivel de relao PREREQ que o curso
superior (SUI_CURSO#) tem o curso subordinado (SUB_CURSO#)
como pr-requisito imediato; as outras variveis de relaes
devem ser auto-explicativas. Trace um diagrama referencial
adequado para esse banco de dados. Fornea tambm a definio
do banco de dados correspondente (isto , escreva um conjunto
apropriado de definies de tipos e variveis de relaes).
8.11 As duas variveis de relaes a seguir representam um
banco de dados contendo informaes sobre departamentos e
empregados:
DEPTO { DEPTO# ,.., GEREMP#, ... }
EMP { EMP#,..., DEPTO#, ... }
Cada departamento tem um gerente (GER_EMP#); cada empregado
tem um departamento (DEPTO#). Novamente, trace um diagrama
referencial e escreva uma definio de banco de dados
adequada para esse banco de dados.
8.12 As duas variveis de relaes a seguir representam um
banco de dados contendo informaes sobre empregados e
programadores:
EMP ( EMP#, ... CARGO, ... }
PGMR { EMP#, ..., LING, ... }
Todo programador um empregado, mas a recproca no
verdadeira. Mais uma vez, trace um diagrama
240 referencial e escreva uma definio de banco de dados
adequada.
8.13 Uma questo que no discutimos no texto do captulo foi
a questo do que deve acontecer se o usurio tentar descartar
alguma varivel de relao ou algum tipo, e alguma restrio
existente fizer referncia a essa varivel de relao ou a
esse tipo. O que deve acontecer em tal situao?
8.14 Fornea solues em SQL para o Exerccio 8.1.
8.15 Compare o suporte para integridade de SQL com o
mecanismo de integridade descrito no texto deste captulo.
REFERNCIAS E BIBLIOGRAFIA
8.1 Alexander Aiken, Joseph M. Hellerstein e Jennifer Widom:
Static Analysis Techniques for Predicting the Behavior of
Active Database Rules, ACM TODS 20, Nmero 1 (maro de
1995).
Esse artigo continua o trabalho das referncias [8.2] e [8.5]
sobre sistemas de bancos de dados especialistas (chamados
aqui de sistemas de bancos de dados ativos). Em particular,
descreve o sistema de regras do prottipo Starburst da IBM
(consulte as referncias [17.50], [25.14], [25.17] e [25.21 e
25.22], e tambm a referncia [8.22].
8.2 Elena Baralis e Jennifer Widom: An Algebraic Approach to
Rule Analysis in Expert Database Systema, Proc. ZOth Int.
Conf. on Very Large Data Bases, Santiago, Chile (setembro de
1994).
De acordo com esse artigo, um sistema de banco de dados
especialista um sistema de banco de dados que admite
regras de condio/ao (em nossa terminologia, a condio
desse acaso uma condio trigger, e a ao o procedimento
trigger correspondente). Um problema com tais sistemas que
seu comportamento inerentemente difcil de prever ou
entender. Esse artigo apresenta mtodos para determinar antes
do tempo de execuo se um certo conjunto de regras possui as
propriedades de terminao e confluncia. A terminao
significa que o processamento de regras tem a garantia de no
continuar para sempre. Confluncia significa que o estado
final do banco de dados independente da ordem em que as
regras so executadas.
8.3 Philip A. Bernstein, Barbara T. Blaustein e Edmund M.
Clarke: Fast Maintenance of Semantic Integrity Assertions
Using Redundant Aggregate Data, Proc. 6th Int. Conf. on Very
Large Data Bases, Montreal, Canad (outubro de 1980).
Apresenta um mtodo eficiente para impor restries de
integridade de um certo tipo especial. Um exemplo todo
valor no conjunto A deve ser menor que todo valor no conjunto
B. A tcnica de imposio baseada na observao de que
(por exemplo) a restrio dada logicamente equivalente
restrio o valor mximo emA deve ser menor que o valor
mnimo em B. Reconhecendo essa classe de restrio e
mantendo de forma automtica os valores mximo e mnimo
relevantes em variveis ocultas, o sistema pode reduzir o
nmero de comparaes envolvidas na imposio da restrio
sobre uma atualizao de algo na ordem da cardinalidade de A
ou B (dependendo do conjunto ao qual a atualizao se aplica)
a um claro, ao custo de ser obrigado a manter as
variveis ocultas.
8.4 0. Peter Buneman e Erik K. Clemons: Efficiently
Monitoring Relational Databases, ACM TODS 4, Nmero 3
(setembro de 1979).
Esse artigo se preocupa com a implementao eficiente de
procedimentos armazenados (aqui chamados triggers) em
particular, com o problema de decidir quando a condio de
trigger ser satisfeita, sem necessariamente avaliar essa
condio. Ele apresenta um mtodo (um algoritmo de anulao)
para detectar atualizaes que talvez no possam satisfazer a
uma determinada condio de trigger; ele tambm discute uma
tcnica para reduzir a sobrecarga de processamento no caso em
que o algoritmo de anulao falha, avaliando a condio de
trigger para algum subconjunto pequeno (um filtro) do
conjunto total de tuplas relevantes.
8.5 Stefano Ceri e Jennifer Widom: Deriving Production Rules
for Constraint Maintenance, Proc. l6th Int. Conf. on Very
Large Data Bases, Brisbane, Austrlia (agosto de 1990).
Descreve uma linguagem baseada em SQL para definir restries
e oferece um algoritmo para identificar todas as operaes
que poderiam violar uma dada restrio. (Um esboo preliminar
desse algoritmo foi apresentado antes na referncia [8.11]. A
existncia desse algoritmo significa que no h necessidade
de informar explicitamente ao SGBD quando uma restrio
precisa ser verificada e, claro, o esquema descrito no
texto deste captulo no oferece nenhum meio para que o
usurio possa faz-lo.) O artigo tam b examina questes de
otimizao e correo. 241

8.6 Stefano Ceri, Piero Fraternali, Stefano Paraboschi e

Letizia Tanca: Automatic Generation of Production Rules for
Integrity Maintenance, ACM TODS 19, 3 (setembro de 1994).
Esse artigo, que se baseia no trabalho da referncia [8.5],
introduz a possibilidade de reparao automtica dos danos
feitos por uma violao de restrio. AS restries so
compiladas em regras de produo com os seguintes
componentes:
1. Uma lista de operaes que podem violar a restrio.
2. Uma expresso booleana que ter o valor verdadeiro se a
restrio for violada (basicamente apenas a negao da
restrio original).
3. Um procedimento de reparao em SQL
O artigo tambm inclui uma boa pesquisa sobre trabalhos
relacionados.
8.7 Roberta Cochrane, Hamid Pirahesh e Nelson Mattos:
Integrating Triggers and Declarative Constraints in SQL
Database Systems, Proc. 22nd Int. Conf. on Very Large Data
Bases, Mumbai (Bombaim), India (setembro de 1996).
Citando o artigo: A semntica da interao de triggers e
restries declarativas deve ser definida com cuidado para
evitar a execuo inconsistente e fornecer aos usurios um
modelo amplo para compreenso dessas interaes. Este artigo
define tal modelo. O modelo em questo foi implementado em
DB2 e aceito como o modelo para o padro emergente de SQL
(SQL3) (consulte o Apndice B).
8.8 E. F. Codd: Domains, Keys and Referential Integrity in
Relational Databases, InfoDB 3, Nmero 1 (primavera de
1988).
Uma discusso dos conceitos de domnio, chave primria e
chave estrangeira. O artigo evidentemente tem autoridade,
pois Codd foi o inventor de todos esses conceitos; porm, na
opinio deste autor, ele ainda deixa muitas questes no
resolvidas ou no explicadas. A propsito, o artigo oferece o
seguinte argumento em favor da disciplina de exigir que uma
nica chave candidata seja escolhida como chave primria:
deixar de apoiar essa disciplina algo como tentar usar um
computador com o esquema de endereamento ... que altere o
radical sempre que uma espcie particular de evento ocorrer
(por exemplo, encontrar um endereo que seja um nmero
primo). Contudo, se aceitarmos esse argumento, por que no
lev-lo sua concluso lgica e usar em esquema de
endereamento idntico para tudo? No muito estranho ter de
enderear fornecedores por nmeros de fornecedores e peas
por nmeros de peas? sem mencionar as remessas, que
envolvem endereos que so compostos. (Na verdade, h muito
que dizer em favor dessa idia de um esquema de endereamento
globalmente uniforme. Consulte a discusso sobre substitutos
na anotao referncia [13.16] no Captulo 13.)
8.9 C. J. Date: Referential Integrity, Proc. 7th Int. Conf.
on Very Large Data Bases, Cannes, Frana (setembro de 1981).
Republicado em forma revisada em Relational Database:
Selected Writings. Reading, Mass.: Addison-Wesley (1986).
O artigo que introduziu as aes referenciais (principalmente
CASCADE e RESTRICT), discutidas na Seo 8.8 deste captulo.
A principal diferena entre a verso original do artigo (VLDB
1981) e a verso revista que a verso original, seguindo a
referncia [13.6], permitia que uma determinada chave
estrangeira fizesse referncia a qualquer nmero de variveis
de relaes, enquanto por razes explicadas em detalhes na
referncia [8.10] a verso revista recuava dessa posio
excessivamente geral.
8.10 C. J. Date: Referential Integrity and Foreign Keys (em
duas partes), em Relational Database Writings
19851989. Reading, Mass.: Addison-Wesley (1990).
A Parte 1 desse artigo discute a histria do conceito de
integridade referencial e oferece um conjunto preferido de
definies bsicas (com justificativa). A Parte II fornece
mais argumentos em favor dessas definies preferidas e d
algumas recomendaes prticas especficas; em particular,
discute problemas causados por (a) superposio de chaves
estrangeiras (b) valores compostos de chaves estrangeiras que
so parcialmente nulos, e (c) caminhos referenciais contguos
(isto , diferentes caminhos referenciais que tm o mesmo
ponto de partida e o mesmo ponto final). Nota: certas
posies nesse artigo so ligeiramente (mas no muito
seriamente) minadas pelos argumentos da referncia [8.13].
8.11 C. J. Date: A Contribution to the Study of Database
Integrity, em Relational Database Writings
242 19851989. Reading, Mass.: Addison-Wesley (1990).

Para citar do resumo: Esse artigo tenta impor alguma

estrutura sobre o problema [da integridade] (a) propondo um
esquema de classificao para restries de integridade, (b)
usando esse esquema para esclarecer os principais conceitos
bsicos da integridade de dados, (c) esboando uma abordagem
para uma linguagem concreta de formulao de restries de
integridade e (d) identificando algumas reas especficas
para pesquisa adicional. Partes deste captulo se baseiam
nesse artigo anterior, mas o esquema de classificao
propriamente dito deve ser considerado como superado pela
verso revisada descrita nas Sees de 8.2 a 8.5 deste
captulo.
8.12 C. J. Date: Integrity, Captulo 11 de C. J. Date e
Colin J. White, A Guide to DB2 (4 edio) [4.20]. Reading,
Mass.: Addison-Wesley (1993).
O produto DB2 da IBM fornece suporte declarativo para chave
primria e chave estrangeira (na verdade, foi um dos
primeiros produtos a faz-lo, seno o primeiro). Porm, como
explica esta referncia, esse suporte sofre de certas
restries de implementao, cujo objetivo geral garantir
um comportamento previsvel. Damos aqui um exemplo simples.
Suponha que a varivel de relao R contenha somente duas
tupIas, com valores de chave primria 1 e 2 respectivamente,
e considere a solicitao de atualizao Duplicar todo valor
de chave primria em R. O resultado correto que as tuplas
devem agora ter os valores de chave primria 2 e 4,
respectivamente. Se o sistema atualizar o 2 primeiro
(substituindo-o por 4) e depois atualizar o 1
(substituindo-o por 2) a solicitao ter sucesso. Se, por
outro lado, o sistema atualizar ou melhor, tentar atualizar
o 1 primeiro (substituindo-o por 2), incorrer em uma
violao da unicidade, e a solicitao falhar (o banco de
dados permanecer inalterado). Em outras palavras, o
resultado da solicitao ser imprevisvel. Para evitar essa
imprevisibilidade, o DB2 simplesmente impede situaes nas
quais ela poderia ocorrer. Porm, infelizmente, algumas das
restries resultantes so bastante severas [8.17].
Observe que, como sugere o exemplo anterior, o DB2 em geral
efetua uma verificao durante a execuo isto , aplica
verificaes de integridade a cada tupla individual quando
atualiza essa tupla. Essa verificao durante a execuo
logicamente incorreta (veja a discusso sobre operaes de
atualizao no final da Seo 5.4, no Captulo 5); ela
feita por razes de desempenho.
8.13 C. J. Date: The Primacy of Primary Keys: An
Investigation, em Relational Database Writings 19911994.
Reading, Mass.: Addison-Wesley (1995).
Apresenta argumentos para apoiar a posio de que s vezes
no boa idia tornar uma chave candidata mais igual que
outras.
8.14 M. M. Hammer e S. K. Sarin: Efficient Monitoring of
Database Assertions, Proc. 1978 ACM SIGMOD lnt. Conf. on
Management of Data, Austin, Texas (maio/junho de 1978).
esboado um algoritmo para gerar procedimentos de
verificao de integridade mais eficiente que o mtodo bvio
da fora bruta de simplesmente avaliar restries aps ter
sido executada uma atualizao. As verificaes so
incorporadas ao cdigo objeto da aplicao em tempo de
compilao. Em alguns casos, possvel detectar que nenhuma
verificao necessria durante a execuo. Mesmo quando
elas so necessrias, com freqncia possvel reduzir de
modo significativo o nmero de acessos ao banco de dados de
diversas maneiras.
8.15 Bruce M. Horowitz: A Run-Time Execution Model for
Referential Integrity Maintenance, Proc. 8th IEEE Int. Conf.
on Data Engineering, Phoenix, Arizona (fevereiro de 1992).
E bem sabido que certas combinaes de
1. Estruturas referenciais (isto , colees de varivel de
relaes relacionadas entre si por meio de restries
rcferenciais)
2. Regras DELETE e UPDATE de chaves estrangeiras
3. Valores de dados reais no banco de dados
podem juntos levar a certas situaes de conflito e
potencialmente podem causar comportamento imprevisvel por
parte da implementao (por exemplo, consulte a referncia
[8.101 para uma explicao adicional). Existem trs
abordagens amplas para se lidar com esse problema:
a. Deix-lo para o usurio.
b. Fazer o sistema detectar e rejeitar tentativas de definir
estruturas que possam levar potencialmente a conflitos em
tempo de execuo.
c. Fazer o sistema detectar e rejeitar conflitos reais
durante a execuo. 243

A opo a. no vem ao caso e a opo b. tende a ser

excessivamente cautelosa [8.12, 8.17]; portanto, Horowitz
prope a opo c. O artigo oferece um conjunto de regras para
essas aes em tempo de execuo e demonstra sua correo.
Porm, observe que a questo da sobrecarga de desempenho
dessa verificao durante a execuo no considerada.
Horowitz foi membro ativo do comit que definiu a SQL/92, e
as pores sobre integridade referencial desse padro
implicam efetivamente que as propostas desse artigo devem ser
suportadas.
8.16 Victor M. Markowitz: Referential Integrity Revisited:
An Object-Oriented Perspective, Proc. l6th Int. Conf. on
Very Large Data Bases, Brisbane, Austrlia (agosto de 1990).
A perspectiva orientada a objetos do ttulo desse artigo
reflete a declarao da posio inicial do autor de que a
integridade referencial a base da representao relaciona!
de estruturas orientadas a objetos. Porm, o artigo no
trata na realidade de orientao a objetos. Em vez disso, ele
apresenta um algoritmo que, partindo de uma diagrama de
entidades/relacionamento (consulte o Captulo 13) ir gerar
uma definio de banco de dados relaciona! na qual certas
situaes problemticas identificadas na referncia [8.10]
(por exemplo, superposio de chaves) tem a garantia de no
ocorrer.
O artigo tambm discute trs produtos comerciais (DB2, SYBASE
e Ingres, como eram em 1990) sob o ponto de vista da
integridade referencial. O DB2, que oferece suporte
declarativo, se mostra bastante restritivo; o Sybase e o
Ingres, que oferecem suporte procedural (por meio de
gatilhos e regras, respectivamente) so apresentados como
menos restritivos que o DB2, mas incmodos e difceis de usar
(embora o suporte do Ingres seja considerado tecnicamente
superior ao do Sybase).
8.17 Victor M. Markowitz: Safe Referential Integrity
Structures in Relational Databases, Proc. l7th Int. Conf. on
Very Large Data Bases, Barcelona, Espanha (setembro de 1991).

Prope duas condies de segurana que garantem que certas

situaes problemticas discutidas (por exemplo) nas
referncias [8.10] e [8.15] no podem ocorrer. O artigo
tambm considera o que est envolvido para satisfazer essas
condies em DB2, SYBASE e Ingres (novamente, como eles eram
em 1990). Quanto ao DB2, mostrado que algumas restries de
implementao impostas no interesse da segurana [8.12] so
logicamente desnecessrias, enquanto outras so inadequadas
(isto , o DB2 ainda assim permite que ocorram certas
situaes inseguras). Quanto a SYBASE e Ingres, afirma-se que
o suporte procedural encontrado nesses produtos no fornece
meios para a deteco de especificaes referenciais
inseguras ou mesmo incorretas!
8.18 Ronald G. Ross: The Business Ride Book: Classi[ying,
Defining, and Modeling Rules (verso 3.0). Boston, Mass.:
Database Research Group (1994).
Consulte a anotao referncia [8.19].
8.19 Ronald G. Ross: Business Ride Concepts. Houston, Texas:
Business Rule Solutions mc. (1998).
Uma grande quantidade de suporte para regras de negcio vem
sacudindo o mundo comercial nos ltimos anos; alguns
especialistas da indstria comearam a sugerir que elas
poderiam ser uma base melhor para projeto e elaborao de
bancos de dados e de aplicaes de bancos de dados (melhor,
vale dizer, que tcnicas mais estabelecidas como a modelagem
de entidades/relacionamentos, modelagem de objetos,
modelagem semntica e outras). E ns concordamos com isso,
porque as regras de negcio no so essencialmente nada
alm de um modo mais amistoso (isto , menos acadmico e
menos formal) de se falar sobre predicados, proposies e
todos os outros aspectos da integridade discutidos neste
captulo. Ross um dos primeiros defensores da abordagem de
regras de negcio e seus livros so recomendados ao
estudioso. A referncia [8.18] exaustiva, enquanto a
referncia [8.19] um breve tutorial.
8.20 M. R. Stonebraker e E. Wong: Access Control in a
Relational Data Base Management System by Query
Modification, Proc. ACM National Conf. (1974).
O prottipo University Ingres [7.11] foi o pioneiro em uma
interessante abordagem para restries de integridade (e
tambm restries de segurana consulte o Captulo 16),
baseada em modificao de solicitao. As restries de
integridade foram definidas por meio da instruo DEFINE
INTEGRITY aqui est a sintaxe:
DEFINE INTEGRITY ON <nome de varivel de relao> IS
<expresso booleana>
Por exemplo:
244 DEFINE INTEGRITY ON F IS F.STATIJS > O

Suponha que o usurio U tente a seguinte operao REPLACE de

QUEL:

REPLACE F ( STATUS = F.STATUS - 10

WHERE F.CIDADE = Londres
Ento, o Ingres modifica automaticamente a REPLACE para:
REPLACE F ( STATUS = F.STATUS - 10
WHERE F.CIDADE = Londres
AND ( F.STATUS 10 ) > O
E, claro, essa operao modificada no ter a possibilidade
de violar a restrio de integridade.
Uma desvantagem dessa abordagem que nem todas as restries
podem ser impostas dessa maneira simples; na verdade, QUEL.
s admitia restries nas quais a expresso booleana era uma
condio de restrio simples. Porm, mesmo esse suporte
limitado representava mais do que aquilo que se encontrava na
maioria dos sistemas da poca.
8.21 A. Walker e S. C. Salveter: Automatic Modification of
Transactions to Preserve Data Base Integrity Without Undoing
Updates, Universidade Estadual de Nova York, Stony Brook,
N.Y.: Technical Report 8 1/026 (junho de 1981).
Descreve uma tcnica para modificao automtica de qualquer
template de transao (isto , cdigo-fonte de transao)
em um template correspondente seguro, no sentido de que
nenhuma instncia de transao que obedea a esse template
modificado ter possibilidade de violar qualquer restrio de
integridade declarada. O mtodo funciona acrescentando
consultas e testes ao template original para assegurar antes
de qualquer atualizao ser feita que nenhuma restrio ser
violada. Durante a execuo, se qualquer desses testes
falhar, a transao ser rejeitada e uma mensagem de erro
ser gerada.
8.22 Jennifer Widom e Stef ano Ceri (editores): Active
Database Systems: Triggers and Rules forAdvanced Data- base
Processing. San Francisco, Calif.: Morgan Kaufmann (1996).
Um compndio til de artigos de pesquisa e tutoriais sobre
sistemas de bancos de dados ativos (isto , sistemas de
bancos de dados que executam automaticamente aes
especificadas em resposta a determinados eventos em outras
palavras, sistemas de bancos de dados com procedimentos
triggers). So includas descries de vrios sistemas
prottipos, inclusive o Starburst da IBM Research (veja as
referncias [17.50] [25.14], [25.17] e [25.21 e 25.22]) e o
Postgres, da Universidade da Califrnia em Berkeley (veja as
referncias [25.26], [25.30] e [25.32]). O livro tambm
resume os aspectos relevantes de SQ14192, de (uma primeira
verso de) SQL3 e de certos produtos comerciais (Oracle,
Informix e Ingres entre eles). Est includa tambm uma
extensa bibliografia.
RESPOSTAS A EXERCCIOS SELECIONADOS
8.1
a.
TYPE CIDADE POSSREP ( CHAR
CONSTRAINT THE CIDADE ( CIDADE ) = Londres
OR THE CIDADE ( CIDADE ) = Paris
OR THE CIDADE ( CIDADE ) = Roma
OR THE CIDADE ( CIDADE ) Atenas
OR TRE CIDADE ( CIDADE ) = Oslo
OR THE CIDADE ( CIDADE ) = Estocolmo
OR THE CIDADE ( CIDADE ) = Madri
OR THE CIDADE ( CIDADE ) = Amsterd
Uma abreviao bvia seria:
a. TYPE CIDADE POSSREP ( CI-IAR
CONSTRAINT THE CIDADE ( CIDADE ) IN { Londres , Paris
Roma , Atenas
Oslo , Estocolmo
Madri , Amsterd } ;

245

b. TYPE F# POSSREP ( CHAR ) CONSTRAINT

SUBSTR ( THE_F# ( F# 1, 1) = F AND
CASTAS INTEGER ( SUBSTR ( THEF# ( F# ), 2 ) O AND
CASTAS INTEGER ( SUBSTR ( THEF# ( F# ), 2 ) 9999
Supomos aqui que o operador de substring SUBSTR e o operador
de converso explcita CAST_AS INTEGER esto ambos
disponveis.
c. CONSTRAINT C ISEMPTY ( P WHERE PESO PESO ( 50.0
d. CONSTRAINT D COUNT ( J ) = COUNT ( J { CIDADE
e. CONSTRAINT E COUNT ( F WHERE CIDADE = Atenas ) 1
f. CONSTRAINT F
ISEMPTY ( ( EXTEND FPJ ADD 2 * AVO ( FPJ, QDE )
AS X ) WHERE QDE > X ) ;
g. CONSTRAINT G
ISEMPTY ( ( F WHERE STATUS = MIN ( F { STATUS } ) ) JOIN
F WHERE STATUS = MAX ( F { STATUS } )
Na realidade, os termos fornecedor de status mais alto e
fornecedor de status mais baixo no esto bem definidos,
pois os valores de status no so nicos. Interpretamos a
exigncia como se Fx e Fy fossem fornecedores quaisquer com
status mais alto e status mais baixo, respectivamente;
ento, Fx e Fy teriam de ser no co-localizados. Observe que
a restrio ser necessariamente violada se os valores de
status mais alto e mais baixo forem iguais! em
particular, ela ser violada se existir apenas um fornecedor.

h. CONSTRAINT H ISEMPTY ( J { CIDADE } MINUS F { CIDADE

i. CONSTRAINT 1 ISEMPTY ( J WHERE NOT ( TUPLE { CIDADE CIDADE
} IN
J { J# } JOIN FPJ JOIN F ) { CIDADE }
j. CONSTRAINT J NOT ( IS_EMPTY
P WHERE COR = COR ( Vermelho )
Essa restrio ser violada se no existir absolutamente
nenhuma pea. Uma formulao melhor seria:
CONSTRAINT J ISEMPTY ( P ) OR NOT ( ISEMPTY
P WHERE COR = COR ( Vermelho )
k. CONSTRAINT K IF NOT ( ISEMPTY ( F )
THEN AVO ( F, STATUS ) > 18
END IF
O teste IF para evitar o erro que ocorreria em caso
contrrio se o sistema tentasse verificar a restrio quando
no existisse nenhum fornecedor.
1. CONSTRAINT L ISEMPTY
F WHERE CIDADE Londres ) { F# } MINUS
FPJ WHERE P# = P# (P2) ) { F#}
m. CONSTRAINT M ISEMPTY ( P ) OR NOT
ISEMPTY ( P WHERE PESO < PESO ( 50.0 )
n. CONSTRAINT N
COUNT ( ( ( F WHERE CIDADE = Londres ) JOIN FPJ ) { P# ) )
>
COUNT ( ( ( F WHERE CIDADE = Paris ) JOIN FPJ ) { P# }
o. CONSTRAINT O
SUM ( ( ( F WHERE CIDADE = Londres) JOIN FPJ ), QDE ) >
SUM ( ( ( F WHERE CIDADE = Paris ) JOIN FPJ ), QDE )
p. CONSTRAINT P ISEMPTY
( ( FPJ JOIN ( FPJ RENAME QDE AS QDE ) )
WHERE QDE > 0,5 * QDE ) ;

246

q. CONSTRAINT Q ISEMPTY (
F JOIN ( F WHERE CIDADE = Atenas ) ) WHERE
CIDADE Atenas AND CIDADE Londres AND CIDADE =Paris
AND ISEMPTY (
F JOIN ( F WHERE CIDADE Londres ) ) WHERE
CIDADE Londres AND CIDADE =Paris
Como um exerccio complementar, voc poderia tentar formular
as restries anteriores em um estilo de clculo no lugar do
estilo algbrico.
8.2 As duas primeiras so restries de tipo, claro. Das
outras, as restries C, D, R, F, G, J, K, M, P e Q so
restries de variveis de relaes; as restantes so
restries de bancos de dados.
8.3
a. Invocao do seletor CIDADE.
b. Invocao do seletor F#.
c. INSERT sobre P, UPDATE sobre PESO de pea.
d. INSERT sobre J, UPDATE sobre CIDADE de projeto.
e. INSERT sobre F, UPDATE sobre CIDADE de fornecedor.
f. INSERT ou DELETE sobre FPJ, UPDATE sobre QDE de remessa.
g. INSERT ou DELETE sobre F, UPDATE sobre STATUS de
fornecedor.
h. INSERT sobre J, DELETE sobre F, UPDATE sobre CIDADE de
fornecedor ou projeto.
i. INSERT sobre J, DELETE sobre FPJ, UPDATE sobre fornecedor
ou projeto.
j. INSERT ou DELETE sobre P, UPDATE sobre CIDADE de pea.
k. INSERT ou DELETE sobre F, UPDATE sobre STATUS de
fornecedor.
1. INSERT sobre F, DELETE sobre FPJ, UPDATE sobre CIDADE de
fornecedor ou sobre F# ou P# de remessa.
m. INSERT ou DELETE sobre P, UPDATE sobre PESO de pea.
n. INSERT ou DELETE sobre F ou FPJ, UPDATE sobre CIDADE de
fornecedor ou sobre F# ou P# de remessa.
o. INSERT ou DELETE sobre F ou FPJ, UPDATE sobre CIDADE de
fornecedor ou sobre F# ou P# ou QDE de remessa.
p. UPDATE sobre QDE de remessa.
q. UPDATE sobre CIDADE de fornecedor.
8.4 Um. As especificaes (5) e (3) devem ser vistas
melhor como restries de integridade. Como observamos na
referncia [3.31, uma conseqncia desejvel desse enfoque
que, se as variveis X eY so definidas como, digamos,
CHAR(5) e CHAR(3), respectivamente, ento as comparaes
entre X e Y so vlidas isto , elas no violam a exigncia
de que os comparandos devem ser do mesmo tipo.
8.5 Oferecemos a lista a seguir como um primeiro esboo do
conjunto de respostas (mas observe a nota ao final).
a. Qualquer restrio de A herda todas as chaves candidatas
de A.
b. Se a projeo incluir qualquer chave candidata K de A,
ento K ser uma chave candidata para a projeo. Do
contrrio, a nica chave candidata ser a combinao de todos
os atributos da projeo (em geral).
c. toda combinao K de uma chave candidata KA de A e uma
chave candidata KB de B uma chave candidata para o produto
A TIMES B.
d. A nica chave candidata para a unio A UNION B a
combinao de todos os atributos (em geral).
e. Fica como exerccio (a interseo no uma primitiva).
f. Toda chave candidata de A uma chave candidata para a
diferena A MINUS B.
247

g. Deixamos o caso geral como exerccio (a juno natural no

uma primitiva. Porm, observamos que no caso especial em
que o atributo de juno em A uma chave candidata de A,
toda chave candidata de B uma chave candidata para a
juno.
h. As chaves candidatas para uma extenso arbitrria de A so
iguais s chaves candidatas de A.
i. As chaves candidatas para uma totalizao arbitrria de A
por B so as chaves candidatas de B.
j. Toda chave candidata de A uma chave candidata para a
semijuno A SEMIJOIN B.
k. Toda chave candidata de A uma chave candidata para a
semidiferena A SEMIMINUS B.
Entretanto, muitas dadas declaraes anteriores podem ser um
pouco aprimoradas em certas situaes. Por exemplo:
A combinao {F#,P#,J#} no uma chave candidata para a
restrio FPJ WHERE F# = F#(F1) em vez disso, a
combinao {P#,J#} uma chave candidata.
Se A tem o cabealho {X,Y,Z} e a nica chave candidata X, e
tambm satisfaz dependncia funcional Y Z (consulte o
Captulo 10), ento, Y uma chave candidata para a projeo
de A sobre Y e Z.
Se A e B so ambas restries de C, ento toda chave
candidata de C uma chave candidata de A UNION B.
E assim por diante. Toda essa questo de inferncia de chaves
candidatas discutida com algum detalhe na referncia
[10.6].
8.6 Seja m o maior inteiro maior que ou igual a n/2. R ter o
maior nmero possvel de chaves candidatas se (a) cada
conjunto distinto de m atributos uma chave candidata, ou
(b) n impar e cada conjunto distinto de m-1 atributos uma
chave candidata. Em qualquer caso, segue-se que o nmero
mximo de chaves candidatas em R n! / (m! * (n-m)! ). Nota:
as variveis de relaes ELEMENTO e CASAMENTO na Seo 8.8
so dois exemplos de variveis de relaes com o nmero
mximo possvel de chaves candidatas.
8.7 R tem exatamente uma chave candidata, ou seja, o conjunto
vazio de atributos {} (algumas vezes denotado por ). Nota: o
conceito de chave candidata vazia (ou nulria) merece uma
ligeira elaborao. Uma varivel de relao como R, cujos
nicos valores vlidos so DEE e DUM no deve ter
necessariamente nenhum atributo, e assim bvio que sua
nica chave candidata tambm no tem nenhum atributo. Porm,
no so apenas as variveis de relaes sem atributos que
podem ter tal chave candidata. Entretanto, se uma chave
candidata para alguma varivel de relao R, ento:
Ela deve ser a nica chave candidata para R, porque
qualquer Outro conjunto de atributos de R seria um
superconjunto prprio de 4, violando assim a exigncia de
irredutibilidade para chaves candidatas. (Portanto, ela de
fato a chave primria, se for preciso escolher uma.)
R est restrita a conter no mximo uma tupla, porque toda
tupla tem o mesmo valor para o conjunto vazio de atributos
(ou seja, a tupla 0).
Observe que nossa sintaxe certamente permite a declarao
dessa varivel de relao por exemplo:
VAR R BASE RELATION {
PRIMARY KEY { } ;
Ela tambm permite a declarao de uma varivel de relao
sem atributo algum isto , uma varivel de relao cujos
nicos valores possveis so DEE e DUM:
VAR R BASE RELATION
PRIMARY KEY { } ;
Voltando questo de chaves candidatas vazias: claro que,
se uma chave candidata pode ser vazia, ento uma chave
estrangeira associada tambm pode ser vazia. A referncia
[5.51 discute com certo detalhe essa possibilidade.
8.8 No h nenhuma regra INSERT explcita para chave
estrangeira, porque as operaes INSERT sobre a varivel de
relao referente (e tambm operaes UPDATE sobre a chave
estrangeira na varivel de relao referente) so governadas
pela prpria regra bsica de integridade referencial, isto ,
a exigncia de no haver valores de chave estrangeira no
associados. Em outras palavras, tomando fornecedores e peas
como exemplo concreto:
Uma tentativa de INSERT uma tupla de remessa (FP) s ter
sucesso se (a) o nmero de fornecedor na tupla existir como
um nmero de fornecedor em F, e (b) o nmero de pea nessa
tupla existir como um n 24 mero de pea em P.

Uma tentativa de UPDATE uma tupla de remessa (FP) s ter

sucesso se (a) o nmero de fornecedor na tupla atualizada
existir como um nmero de fornecedor em F, e (b) o nmero de
pea na tupla atualizada existir como um nmero de pea em P.
Observe tambm com ateno que as observaes anteriores se
aplicam varivel de relao referente, enquanto as regras
(explcitas) DELETE e UPDATE se aplicam varivel de relao
referida. Portanto, falar sobre uma regra INSERT como se
essa regra fosse algo semelhante s regras DELETE e UPDATE
existentes realmente algo bastante confuso. Esse fato
fornece justificativa adicional para no incluirmos qualquer
suporte de regra INSERT explcita na sintaxe concreta.
8.9
a. Aceita.
b. Rejeitada (violao de unicidade de chave candidata).
c. Rejeitada (viola a especificao RESTRICT).
d. Aceita (o fornecedor F3 e todas as remessas para o
fornecedor F3 so eliminadas).
e. Rejeitada (viola a especificao RESTRICT).
f. Aceita (o projeto J4 e todas as remessas para o projeto J4
so eliminados).
g. Aceita.
h. Rejeitada (violao de unicidade de chave candidata).
i. Rejeitada (violao de integridade referencial).
j. Aceita.
k. Rejeitada (violao de integridade referencial).
1. Rejeitada (violao de integridade referencial o nmero
de projeto padro jjj no existe na varivel de relao J).
8.10 O diagrama referencial mostrado na Figura 8.1. Segue-
se uma definio de banco de dados possvel. Para
simplificar, no nos preocupamos em definir nenhuma restrio
de tipo exceto, claro, pelo fato de que a especificao
de POSSREP em uma determinada definio de tipo serve como
uma restrio a priori do tipo.
TYPE CURSO# POSSREP C CHAR ) ;
TYPE TTULO POSSREP ( CHAR
TYPE OFER# POSSREP C CHAR ) ;
TYPE DATAOFER POSSREP ( DATE )
TYPE CIDADE POSSREP ( CHAR
TYPE EMP# POSSREP ( CHAR ) ;
TYPE NOME POSSREF ( NOME
TYPE CARGO POSSREP ( CHAR
TYPE GRADE POSSREP ( CHAR
VAR CURSO BASE RELATION
{ CURSO# CURSO#,
TTULO TTULO
PRIMARY KEY ( CURSO# } ;
VAR PREREQ BASE RELATION
{ SUPCURSO# CURSO#,
SUB CURSO# CURSO# }
PRIMARY KEY { SUP CURSO#, SUB CURSO# }
FOREIGN KEY { RENAME SUP CURSO# AS CURSO# }
REFERENCES CURSO
ON DELETE CASCADE
ON UPDATE CASCADE
FOREIGN KEY { RENAME SUB CURSO# AS CURSO# }
REFERENCES CURSO
ON DELETE CASCADE
ON UPDATE CASCADE ;
249

LOCAL PRIMARY FOREIGN

ENOME
CARGO PRIMARY

VAR PROFESSOR { CURSO#

OFER#
EMP#

VAR MATRCULA { CURSO#

OFER#
EMP#

GRADE PRIMARY FOREIGN

CIDADE
KEY { CURSO#, OFER# }
KEY { CURSO# } REFERENCES CURSO ON DELETE CASCADE
ON UPDATE CASCADE ;

NOME,
CARGO
KEY { EMP# } ;

BASE RELATION
CURSO#,
OFER#,
EMP# }

OFER#, EMP# }
OFER# } REFERENCES OFERTA ON DELETE CASCADE
ON UPDATE CASCADE
EMP# } REFERENCES EMPREGADO ON DELETE CASCADE
ON UPDATE CASCADE ;

BASE RELATION MATRCULA

CURSO#,
OFER#
EMP#,

CURSO#, OFER#, EMP# } CURSO#. OFER# } REFERENCES OFERTA

ON DELETE CASCADE

ON UPDATE CASCADE
REFERENCES EMPREGADO
ON DELETE CASCADE
ON UPDATE CASCADE ;

VAR OFERTA BASE RELATION

{ CURSO# CURSO#,
OFER# OFER#,
DATAOFER DATAOFER,

VAR EMPREGADO BASE RELATION { EMP# EMP#,

PRIMARY KEY { CURSO#, FOREIGN KEY { CURSO#,

FOREIGN KEY {

GRADE KEY { KEY {

FOREIGN KEY { EMP# }

SUPCURSO# SUB CURSO#

ECURSO
CURSO#
CURSO#, OFER# CURSO#, OFER#
- OFERTA

EMP#

EMPREGADO

EMP#

250 FIGURA 8.1 Diagrama referencial para o banco de dados de

ensino

Surgem pontos importantes:

1. Os conjuntos de atributos (unitrios) {CURSO#} em
PROFESSOR e {CURSO#} em MATRCULA tambm poderiam ser
considerados chaves estrangeiras, ambos fazendo referncia a
CURSO. Porm, se as restries referenciais de PROFESSOR para
OFERTA, MATRICULA para OFERTA e OFERTA para CURSO forem todas
adequadamente mantidas, as restries referenciais de
PROFESSOR para CURSO e MATRICULA para CURSO sero mantidas
automaticamente. Consulte a referncia [8.101 para ver uma
discusso adicional.
2. OFERTA um exemplo de varivel de relao que
simultaneamente referida e referente: existe uma restrio
referencial para OFERTA de MATRICULA (de fato, tambm de
PROFESSOR) e uma restrio referencial de OFERTA para CURSO:
MATRICULA * OFERTA > CURSO
3. Note que existem dois caminhos referenciais distintos de
MATRCULA para CURSO um direto (chave estrangeira {CURSO#}
em MATRICULA) e outro indireto, atravs de OFERTA (chaves
estrangeiras {CURSO#, OFER#} em MATRICUL& e {CURSO#} em
OFERTA):
MATRCULA * OFERTA * CURSO
Porm, os dois caminhos no so verdadeiramente independentes
um do outro (o caminho superior est implcito na combinao
dos dois inferiores). Para ver uma discusso adicional desse
ponto, consulte novamente a referncia [8.10].
4. Tambm existem dois caminhos referenciais distintos de
PREREQ para CURSO, mas dessa vez os dois caminhos so
verdadeiramente independentes (eles tm significados
totalmente distintos), consulte mais uma vez a referncia
[8.10].
8.11 O diagrama referencial mostrado na Figura 8.2. Observe
que o banco de dados envolve um ciclo referencial (h um
caminho referencial de cada uma das duas variveis de
relaes para ela mesma). Alm dessa considerao, a
definio do banco de dados essencialmente simples.
Omitimos os detalhes.

FIGURA 8.2 Diagrama referencial envolvendo um ciclo

8.12 Mostramos apenas as definies de variveis de relaes
(e essas apenas em esboo):
VAR EMP BASE RELATION
{ EMP# . . .
CARGO
PRIMARY KEY { EMP# }
VAR PGMR BASE RELATION
{ EMP# ...
LING ... }
PRIMARY KEY { EMP# }
FOREIGN KEY { EMP# } REFERENCES EMP
ON DELETE CASCADE
ON UPDATE CASCADE ;
GEREMP# 1
DEPTO______j
[EMP
1 DEPTO#

Alguns pontos importantes:

1. Esse exemplo ilustra o fato de que uma chave estrangeira
tambm pode ser uma chave candidata da varivel de relao
que a contm. A varivel de relao EMP contm todos os
empregados, e a varivel de relao PGMR contm apenas os
empregados que so programadores; assim, todo nmero de
empregado que aparece em PGMR tambm deve aparecer em EMP
(mas a recproca no verdadeira). A chave primria de PGMR
tambm uma chave estrangeira, referenciando a chave
primria de EMP.
2. Observe que h outra restrio que precisa ser mantida
nesse exemplo ou seja, a restrio que um dado empregado
aparecer em PGMR se e somente se o valor de CARGO para esse
empregado for Programador. E claro que essa restrio no
uma restrio referencial.
8.14 Observe que as solues a. e b. a seguir so apenas
aproximaes para as solues correspondentes mostradas na
resposta ao Exerccio 8.1.
a. CREATE DOMAIN CIDADE CHAR(15) VARYING
CONSTRAINT CIDADES VLIDAS
CHECK ( VALUE IN ( Londres, Paris, Roma,
Atenas, Oslo, Estocolmo,
Madri , Amsterd ) ) ;
b. CREATE DOMAIN F# CHAR(5) VARYING
CONSTRAINT VALID F# CHECK
SLJBSTRING ( VALUE FROM 1 FOR 1 ) = E AND
CAST ( SUBSTRING ( VALUE FROM 2 ) AS INTEGER ) >= O AND
CAST ( SUBSTRINO ( VALUE FROM 2 ) AS INTEGER ) < 9999
c. CREATE ASSERTION SQL_C CHECK
P.COR <> Vermelho OR P.PESO < 50.0
d. CREATE ASSERTION SQLD CHECK
( NOT EXISTS ( SELECT * FROM J JX WHERE
EXISTS ( SELECT * FROM J JY WHERE
( JX.J# <> JY.J# AND
JX.CIDADE = JY.CIDADE ) ) ) )
e. CREATE ASSERTION SQLE CHECK
( ( SELECT COUNT(*) FROM F
WHERE F.CIDADE = Atenas ) < 2
f. CREATE ASSERTION SQL_F CHECK
( NOT EXISTS ( SELECT *
FROM FPJ FPJX
WHERE FPJX.QDE > 2 *
( SELECT AVG ( FPJY.QDE
FROM FPJ FPJY ) ) )
g. CREATE ASSERTION SQL_G CHECK
( NOT EXISTS ( SELECT * FROM F EX WHERE
EXISTS ( SELECT * FROM F FY WHERE
SX.STATUS = ( SELECT MAX ( F.STATUS )
FROM F ) AND
SY.STATUS = ( SELECT MIN ( F.STATUS
FROM F ) AND
FX.STATUS <> FY.STATUS AND
FX.CIDADE = FY.CIDADE ) ) )
h. CREATE ASSERTION SQL_H CHECK
( NOT EXISTS ( SELECT * FROM F WHERE
NOT EXISTS ( SELECT * FROM F WHERE
F.CIDADE = J.CIDADE ) ) ) ;

252

CREATE ASSERTION SQLI CHECK

( NOT EXISTS ( SELECT * FROM J WHERE
NOT EXISTS ( SELECT * FROM F WHERE
F.CIDADE = J.CIDADE AND
EXISTS ( SELECT * FROM FPJ
WHERE FPJ.F# = F.F#
AND FPJ.J# = J.J# ) ) ) )
j. CREATE ASSERTION SQL_J CHECK
( NOT EXISTS ( SELECT * FROM P
OR EXISTS ( SELECT * FROM P
WHERE P.COR = Vermelho
k. CREATE ASSERTION SQL_K CHECK
( SELECT AVG ( F.STATUS ) FROM F ) > 10 )
Se a tabela de fornecedores estiver vazia, o operador AVG de
SQL retornar (incorretarnente!) um nulo, a expresso
condicional ser avaliada como desconhecida, e a restrio
no ser considerada violada. Consulte o Captulo 18, que
contm explicaes adicionais.
CREATE ASSERTION SQL_L CHECK
( NOT EXISTS ( SELECT * FROM F
WHERE F.CIDADE = Londres
AND NOT EXISTS
( SELECT * FROM FPJ
WHERE FPJ.F# = F.F#
AND FPJ.P# = P2 )
m. CREATE ASSERTION SQLM CHECK
( NOT EXISTS ( SELECT * FROM P
WHERE P.COR = Vermelho1
OR EXISTS ( SELECT * FROM P
WHERE P.C0R = Vermelho
AND P.PESO < 50.0
n. CREATE ASSERTION SQLN CHECK
( ( SELECT COUNT(*) FROM P
WHERE EXISTS ( SELECT * FROM FPJ WHERE
EXISTS ( SELECT * FROM F WHERE
( P.P# = FPJ.P# AND
FPJ.F# = FF# AND
F.CIDADE = Londres ) ) ) ) >
( SELECT COUNT(*) FROM P
WHERE EXISTS ( SELECT * FROM FPJ WHERE
EXISTS ( SELECT * FROM F WHERE
( P.P# = FPJ.P# AND
FPJ.F# F.F# AND
F.CIDADE = Paris ) ) )
o. CREATE ASSERTION SQL_0 CHECK
( ( SELECT SUM ( FPJ.QDE ) FROM FPJ
WHERE ( SELECT F.CIDADE FROM F
WHERE F.F# FPJ.F# ) = Londres ) >
( SELECT SUM ( FPJ.QDE ) FROM FPJ
WHERE ( SELECT F.CIDADE FROM F
WHERE F.F# FPJ.F# ) = Paris )
p. No pode ser feito.
q. No pode ser feito.

253