Você está na página 1de 36

CAPITULO 4

Uma introduo SQL


4.1 INTRODUO
Como mencionamos no Captulo 1, a SQL a linguagem padro
para se lidar com bancos de dados relacionais, e aceita por
quase todos os produtos existentes no mercado. A SQL foi
desenvolvida originalmente na IBM Research no incio da
dcada de 1970 (consulte as referncias [4.8-4.9] e [4.28]);
ela foi implementada pela primeira vez em grande escala em um
prottipo da IBM chamado System R (consulte as referncias
[4.14.3] e [4.114.13]), e reimplementada depois disso em
numerosos produtos comerciais da IBM (ver referncia [4.20])
e de muitos outros fornecedores. Neste captulo,
apresentaremos uma introduo linguagem SQL; aspectos
adicionais, relacionados com assuntos como integridade,
segurana, etc., sero descritos em captulos subsequentes
dedicados a esses tpicos. Todas as nossas descries sero
baseadas (exceto onde for indicado algo em contrrio) na
verso atual do padro, conhecida informalmente como SQL/92,
tambm como SQL92 ou apenas SQL2 [4.224.23]; o nome oficial
International Standard Database Language SQL (1992).
Nota: devemos acrescentar imediatamente que est prximo da
concluso o trabalho na SQL3, a proposta de prosseguimento
para o padro atual; a ratificao era esperada para o final
de 1999. Ento, quando este livro for impresso, o padro
atual dever ser possivelmente a SQL/99, e no a SQL/92.
Porm, consideramos que seria muito confuso empregar a SQL3
como base de nossas discusses, pelo simples fato de que
obviamente ainda no h nenhum produto que a reconhea; por
essa razo, decidimos descrever a SQL3 separadamente em um
apndice (o Apndice B). Em todo caso, tambm devemos
assinalar que nenhum produto atual admite nem mesmo a SQL/92
em sua totalidade;* em vez disso, os produtos em geral
admitem aquilo que se poderia chamar um superconjunto de um
subconjunto da SQL/92 (isto , a maioria deles deixa de
oferecer suporte a determinados aspectos do padro e ainda de
ir alm do padro em outros aspectos). Por exemplo, o produto
DB2 da IBM no admite no momento todos os recursos de
integridade da SQL/92, mas vai alm da SQL/92 em suas regras
relativas atualizao de vises.
Aqui esto algumas observaes preliminares adicionais:
- Em sua forma original, a SQL pretendia ser especificamente
uma sublinguagem de dados. Porm, com a incorporao do
recurso de Mdulos Armazenados Persistentes (PSM Persistent
Stored Modules) ao padro no final de 1996, a SQL se tornou
completa em termos computacionais (ela agora inclui
instrues ou declaraes como CALL, RETURN, SET, CASE, IF,
LOOP, LEAVE, WHILE e REPEAT, bem como diversas
caractersticas inter-relacionadas, como variveis e
tratadores de excees). Como consequncia, j no h mais
qualquer necessidade de combinar a SQL com alguma linguagem
hospedeira distinta para se desenvolver uma aplicao
completa. No entanto, optamos por no descrever o recurso PSM
em qualquer nvel de detalhe neste livro.
*De fato, nenhum produto poderia oferecer suporte SQL/92 em
sua totalidade porque a SQL/92 especificada no momento contm
numerosos furos, equvocos e incoerncias. Consulte a
referncia [4.19] para ver uma descrio detalhada desse
assunto. 71
- No se surpreenda ao descobrir que a SQL utiliza o termo
tabela em lugar dos termos relao e varivel de relao (ver
Captulo 3). Por essa razo, para manter a coerncia com o
padro SQL e os produtos de SQL, faremos o mesmo neste
captulo (e em qualquer outro lugar neste livro, sempre que
estivermos preocupados especificamente com a SQL). Alm
disso, a SQL no usa os termos cabealho e corpo (de uma
tabela ou relao).
- A SQL uma linguagem enorme. O prprio documento padro
[4.22] tem bem mais de 600 pginas (e as especificaes da
SQL3 ocupam mais de duas vezes esse tamanho). Em
consequncia, no possvel esgotar o assunto em um livro
desta natureza; tudo o que podemos esperar fazer descrever
os aspectos mais importantes de modo razoavelmente amplo, mas
prevenimos o leitor de que nossas discusses so
necessariamente superficiais. Em particular, no hesitamos em
omitir material irrelevante ao propsito pretendido, nem em
fazer simplificaes no interesse da brevidade. Descries
mais completas (mas ainda assim tutoriais) podem ser
encontradas nas referncias [4.4], [4.19] e [4.27].
- Finalmente, deve ser dito que (conforme indicado em
diversos pontos nos Captulos de 1 a 3) a SQL est muito
longe de ser a linguagem relacional perfeita ela se
ressente de pecados de omisso e comisso. No obstante, ela
o padro, admitida por quase todos os produtos existentes
no mercado, e todo profissional de banco de dados precisa
conhecer algo sobre ela. Da a cobertura feita neste livro.
4.2 VISO GERAL
A SQL inclui operaes de definio de dados e operaes de
manipulao de dados. Consideraremos primeiro as operaes de
definio. A Figura 4.1 oferece uma definio de SQL para o
banco de dados de fornecedores e peas (compare-a com a
Figura 3.9). Como podemos observar, a definio inclui uma
instruo CREATE TABLE para cada das trs tabelas bsicas
(conforme notamos no Captulo 3, a palavra-chave TABLE em
CREATE TABLE indica especificamente uma tabela bsica). Cada
uma dessas instrues CREATE TABLE especifica o nome da
tabela bsica a ser criada, os nomes e os tipos de dados das
colunas dessa tabela, e ainda a chave primria e quaisquer
chaves estrangeiras na tabela (e, possivelmente, tambm
algumas informaes adicionais no ilustradas na Figura 4.1).
H ainda alguns detalhes sintticos a assinalar:
- Observe que fazemos uso frequente do smbolo # em (por
exemplo) nomes de colunas mas, na realidade, esse smbolo no
vlido em SQL/92.
- Usamos o ponto-e-vrgula (;) como indicador de trmino de
instruo. Na realidade, o uso desses indicadores pela SQL/92
depender do contexto. Os detalhes especficos esto alm do
escopo deste livro.
Uma diferena importante entre a Figura 4.1 e sua equivalente
(a Figura 3.9) no Captulo 3 o fato de que a Figura 4.1 no
inclui nada que corresponda s definies de tipos (isto ,
declaraes TYPE) da Figura 3.9. claro que a razo que a
SQL no permite que os usurios definam seus prprios tipos;*
assim, as colunas devem ser definidas somente em termos de
tipos embutidos ou internos (definidos pelo sistema). A SQL
admite os seguintes tipos embutidos, mais ou menos auto-
explicativos:
CHARACTER [ VARYING ] (n) INTEGER DATE
BIT E VARYING ] (n) SMALLINT TIME
NUMERIC (p,q) FLOAT (p) TIMESTAMP
DECIMAL (p,q) INTERVAL
Ela permite que os usurios definam aquilo que se chama
domnios, mas esses domnios no so na realidade domnios
isto , tipos no sentido relacional (ver Captulo 5).
Nota: porm, os tipos definidos pelo usurio so admitidos na
SQL3 (ver Apndice B).
CREATE TABLE F
( F# CHAR(5),
FNOME CHAR(20),
STATUS NUMERIC(S),
CIDADE CHAR(15),
PRIMARY KEY ( F# ) ) ;
CREATE TABLE P
( P# CHAR(6),
PNOME CHAR(20),
COR CHAR(6),
PESO NUMERIC(5.1),
CIDADE CHAR(15),
PRIMARY KEY ( P# ) ) ;
CREATE TABLE FP
( F# CHAR(5),
P# CHAR(6),
QDE NUMERIC(9),
PRIMARY KEY ( F#, P# ),
FOREIGN KEY ( F# ) REFERENCES F,
FOREIGN KEY ( P# ) REFERENCES P ;
FIGURA 4.1 O banco de dados de fornecedores e peas
(definio de SQL)
Uma srie de padres, abreviaes e grafias alternativas
por exemplo, CHAR em lugar de CHARACTER tambm tm suporte;
omitimos os detalhes aqui. Alm disso, os colchetes [ e ]
em CHARACTER e BIT so usados para indicar que o material que
eles incluem opcional (como normal na notao BNF,
claro). Observe finalmente que a SQL exige que certos
comprimentos ou precises sejam declarados para determinados
tipos (por exemplo, CHAR), o que no foi feito em nossa
sintaxe hipottica do Captulo 3. De fato, a SQL
aparentemente considera esses comprimentos e essas precises
como partes dos tipos (implicando, por exemplo, que CHAR(3) e
CHAR(4) so tipos diferentes); acreditamos que melhor
consider-los restries de integridade (e assim o fizemos
consulte o Captulo 8, em especial o Exerccio 8.4).
Tendo definido o banco de dados, podemos agora comear a
operar sobre ele por meio das operaes de manipulao de SQL
SELECT, INSERT, UPDATE e DELETE. Em particular, podemos
executar operaes relacionais de restrio, projeo e
juno sobre os dados, utilizando em cada caso a instruo de
manipulao de dados SELECT de SQL. A Figura 4.2 mostra como
certas operaes de restrio, projeo e juno podem ser
formuladas em SQL. Nota: o exemplo de juno na figura
ilustra o fato de que nomes qualificados (por exemplo, F.F#,
FP.F#) so s vezes necessrios em SQL para tirar a
ambiguidade de referncias a colunas. A regra geral a de
que esses nomes qualificados so sempre aceitveis, mas nomes
no qualificados tambm so aceitveis, desde que no causem
nenhuma ambiguidade.
Observamos que a SQL tambm admite uma forma abreviada da
clusula SELECT, como ilustra o exemplo seguinte:
SELECT * ou SELECT F.*' (isto , o * pode ser qualificado)
FROM F ;
O resultado uma cpia da tabela F inteira; o asterisco a
abreviao para uma lista separada por vrgulas de todos
nomes de colunas na(s) tabela(s) referenciada(s) na clusula
FROM, na ordem da esquerda para a direita em que essa(s)
coluna(s) (so) definida(s) dentro da(s) tabela(s). A
propsito, note o comentrio nesse exemplo (introduzido com
um hfen duplo e encerrado com um caractere de nova linha).
Nota: a expresso SELECT * FROM T, onde T um nome de
tabela, pode ser abreviada ainda mais, tornando-se apenas
TABLE T.
A instruo SELECT discutida em extenso muito maior no
Captulo 7 (Seo 7.7).
FIGURA 4.2 Exemplos de restrio, projeo e juno em SQL
Vamos examinar agora as operaes de atualizao: j foram
dados exemplos de instrues de SQL INSERT, UPDATE e DELETE
no Captulo 1, mas esses exemplos envolviam deliberadamente
apenas operaes de uma nica linha. Contudo, como SELECT, as
operaes INSERT, UPDATE e DELETE em geral so todas
operaes em nvel de conjunto (e alguns dos exerccios e
respostas no Captulo 1 de fato ilustravam esse detalhe).
Aqui esto alguns exemplos de operaes de atualizao de
alto nvel para o banco de dados de fornecedores e peas:
INSERT
INTO TEMP ( P#, PESO
SELECT P#, PESO
FROM P
WHERE COR = `Vermelha'
Esse exemplo pressupe que j criamos outra tabela TEMP com
duas colunas, P# e PESO. A instruo INSERT insere nessa
tabela nmeros de peas e pesos correspondentes a todas as
peas vermelhas.
UPDATE F
SET STATUS = STATUS * 2
WHERE CIDADE = `Paris'
Restrio: Resultado:
SELECT F#, P#, QDE
FROM FP
WHERE QDE < 150 F# # QDE
Fi Fi P5 100
P6 100
Projeo: Resultado:
SELECT F#, CIDADE
FROM F ; CIDADE
F1
F2
F3
F4
F5 Londres
Paris
Paris
Londres
Atenas
Juno:
SELECT F.F#, FNOME, STATUS CIDADE, P#, QDE
FROM F, FP
WHERE F.F# = FP.F#
Resultado: F# FNOME STATUS CIDADE r p# QDE
F1 Smith 20 Londres P1 300
F1 Smith 20 Londres P2 200
F1 Smith 20 Londres P3 400
F4 Clark 20 Londres P5 400
A instruo UPDATE duplica o status para todos os
fornecedores em Paris.
DELETE
FROM FP
WHERE P# = `2'
A instruo DELETE elimina todas as remessas correspondentes
pea P2.
Nota: a SQL no inclui uma analogia direta da operao de
atribuio relacional. Porm, podemos simular essa operao
eliminando primeiro todas as linhas da tabela de destino, e
depois executando uma operao INSERT ... SELECT ... (como no
primeiro exemplo anterior) nessa tabela.
4.3 O CATLOGO
O padro SQL inclui especificaes para um catlogo padro
chamado Information Schema (esquema de informaes). De fato,
os termos convencionais catlogo e esquema so ambos
usados em SQL, mas com significados altamente especficos de
SQL; em termos informais, um catlogo de SQL consiste nos
descritores para um banco de dados individual,* e um esquema
de SQL, nos descritores para a parte desse banco de dados que
pertence a algum usurio individual. Em outras palavras, pode
haver um nmero qualquer de catlogos (um por banco de
dados), cada qual dividido em um nmero qualquer de esquemas.
Entretanto, cada catlogo deve incluir exatamente um esquema
chamado INFORMATIONSCHEMA e, da perspectiva do usurio,
esse esquema (como j mencionamos) que executa a funo
normal de catlogo.
Desse modo, o Information Schema consiste em um conjunto de
tabelas SQL cujo contedo reproduz efetivamente, de uma forma
definida com preciso, todas as definies de todos os outros
esquemas no catlogo em questo. De um modo mais exato, o
Information Schema definido para conter um conjunto de
vises de um hipottico Definition Schema (esquema de
definies). A implementao no tem a obrigatoriedade de
fornecer suporte ao Definition Schema como tal, mas deve (a)
dar suporte a algum tipo de Definition Schema e (b) dar
suporte a vises desse Definition Schema semelhantes a
vises do Information Schema. Surgem alguns pontos
importantes:
1. As razes para se enunciar a exigncia em termos de dois
itens separados (a) e (b) como acabamos de descrever que,
em primeiro lugar, os produtos existentes certamente oferecem
suporte para algo semelhante ao Definition Schema. No
entanto, esses Definition Schemas variam amplamente de um
produto para outro (at mesmo quando os produtos em questo
vm do mesmo fabricante). Da, faz sentido a idia de exigir
apenas que a implementao admita certas vises predefinidas
de seu Definition Schema.
2. Na realidade, devemos dizer um (e no o) Information
Schema pois, como vimos, existe um esquema desse tipo em cada
catlogo. Desse modo, em geral a totalidade de dados
disponveis para um determinado usurio no ser descrita por
um nico Information Schema. Porm, por questo de
simplicidade, continuaremos a falar como se existisse apenas
um.
No vale a pena entrarmos em muitos detalhes sobre o contedo
do Information Schema; em vez disso, simplesmente vamos
relacionar algumas vises mais importantes do Information
Schema, na esperana de que apenas seus nomes sejam
suficientes para dar alguma idia do contedo dessas vises.
Entretanto, devemos dizer que a viso TABLE contm
informaes sobre todas as tabelas nomeadas, tanto vises
quanto tabelas bsicas, enquanto a viso VIEWS contm
informaes apenas sobre vises.
* Mais precisamente, devemos mencionar que realmente no
existe nada semelhante a um banco de dados no padro SQL! O
modo exato como chamada a coleo de dados descrita por um
catlogo definido pela implementao. Porm, no sem
razo que ela considerada um banco de dados. 75
SCHEMATA REFERENTIALCONSTRAINTS A (
DOMAINSCHECKCONSTRAINTS
TABLES KEYCOLUMNUSAGE DEL
VIEWS ASSERTIONS FRC
COLUMNS VIEWTABLEUSAGE WHE
TABLEPRIVILEGES VI EWCOLUMNUSAGE AN[
COLUMNPRIVILEGES CONSTRAINTTABLEUSAGE
USAGE PRIVILEGES CONSTRAINTCOLUMNUSAGE
DOMAINCONSTRAINTS CONSTRAINTDOMAINUSAGE 4.
TABLECONSTRAINTS
A referncia [4.19] oferece mais detalhes; em particular,
mostra como formular consultas sobre o Information Schema (o
processo no to direto quanto se poderia esperar).
4.4 VISES
Aqui est um exemplo de uma definio de viso em SQL:
CREATE VIEW BOM_FORNECEDOR
AS SELECT F#, STATUS, CIDADE
FROM F
WHERE STATUS > 15
E aqui est um exemplo de uma consulta de SQL sobre essa
viso:
SELECT F#, STATUS
FROM BOM FORNECEDOR
WHERE CIDADE = Londres
Substituindo a referncia ao nome da viso pela definio da
viso, obtemos uma expresso semelhant a esta (observe a
subconsulta aninhada na clusula FROM):
SELECT BOM_FORNECEDOR. F#, BOM_FORNECEDOR. STATUS
FROM ( SELECT F#, STATUS, CIDADE
FROM F
WHERE STATUS > 15 ) AS BOM_FORNECEDOR
WHERE BOM FORNECEDOR.CIDADE = Londres'
E essa expresso pode ento ser simplificada, resultando em
algo como isto:
SELECT F#, STATUS
FROM F
WHERE STATUS > 15
AND CIDADE = `Londres
Essa ltima a consulta realmente executada.
Como outro exemplo, considere a operao DELETE a seguir:
DELETE
FROM BOM_FORNECEDOR
WHERE CIDADE = Londres'
76
A operao DELETE realmente executada semelhante a esta:
DELETE
FROM F
WHERE STATUS > 15
AND CIDADE = Londres'
4.5 TRANSAES
Os anlogos em SQL s nossas instrues COMMIT e ROLLBACK so
chamados COMMIT WORK e ROLLBACK WORK, respectivamente (a
palavra-chave WORK opcional em ambos os casos). Entretanto,
a SQL no inclui nenhuma instruo BEGIN TRANSACTION
explcita. Em vez disso, uma transao iniciada de forma
implcita, sempre que o programa executa uma instruo de
inicializao de transao e ainda no h uma transao em
andamento. Os detalhes exatos sobre as instrues de SQL que
inicializam transaes estariam fora de lugar aqui;
suficiente dizer que todas as instrues descritas neste
captulo so de inicializao de transaes (com exceo,
claro, das prprias COMMIT e ROLLBACK).
4.6 SQL EMBUTIDA
A maioria dos produtos de SQL permite que as instrues SQL
sejam executadas diretamente (ou seja, interativamente a
partir de um terminal on-line) e como parte de um programa
aplicativo (isto , as instrues de SQL podem estar
embutidas, significando que elas podem estar entremeadas com
as instrues da linguagem de programao de um tal
programa). Alm disso, no caso das instrues embutidas, o
programa aplicativo em geral pode ser escrito em uma
variedade de linguagens hospedeiras, como COBOL, Java, PL/I
etc.* Nesta seo, consideraremos especificamente o caso das
instrues embutidas.
O princpio fundamental subjacente SQL embutida, ao qual
nos referimos como o princpio da dualidade, que qualquer
instruo de SQL que pode ser usada interativamente tambm
pode ser empregada em um programa aplicativo. claro que
existem vrias diferenas de detalhes entre uma determinada
instruo SQL interativa e sua equivalente embutida, e
operaes de busca em particular exigem um tratamento
significativamente estendido em um ambiente de programa
hospedeiro (ver mais adiante nesta seo) mas, apesar disso,
o princpio amplamente verdadeiro. (A propsito, o inverso
no verdadeiro vrias instrues de SQL embutidas no
podem ser usadas de modo interativo, conforme veremos.)
Antes de podermos descrever as instrues reais da SQL
embutida, necessrio abordar uma srie de detalhes
preliminares. A maioria desses detalhes ilustrada pelo
fragmento de programa mostrado na Figura 4.3. (Para fixarmos
nossas idias, supomos que a linguagem hospedeira PL/I. A
maior parte das idias se traduz em outras linguagens
hospedeiras, com pequenas alteraes.) Vrios pontos se
destacam:
1. As instrues de SQL embutida tm o prefixo EXEC SQL, a
fim de distingui-las de instrues da linguagem hospedeira, e
so encerradas por um smbolo terminador especial (um ponto-
e-vrgula, no caso da linguagem PL/I).
2. Uma instruo SQL executvel (no restante desta seo,
deixaremos de lado o qualificador embutido) poder surgir
sempre que uma instruo executvel da hospedeira tambm
puder aparecer. A propsito, note esse executvel:
diferente da SQL interativa, a SQL embutida inclui algumas
instrues que so puramente declarativas e no
executveis.** Por exemplo, DECLARE CURSOR no uma
instruo executvel (consulte a subseo Operaes que
envolvem cursores, mais adiante neste captulo), nem as
instrues BEGIN e END DECLARE SECTION (consulte o pargrafo
5 mais adiante), e nem a instruo WHENEVER (consulte o
pargrafo mais adiante).
* O padro SQL [4.22] admite atualmente Ada, C, COBOL,
Fortran, M (anteriormente chamada MUMPS), Pascal e PL/I. O
suporte ao Java no estava includo no momento em que este
livro era escrito, mas ele deve ser acrescentado em breve
(consulte a
referncia [4.6] e tambm o Apndice B), e alguns produtos j
o reconhecem.
**Exatamente por esse motivo, essas instrues especficas
tambm podem ser chamadas declaraes. (N.T.) 77
EXEC SQL BEGIN DECLARE SECTION
DCL SQLSTATE CHAR(5)
DCL P1 CHAR(6)
DCL PESO FIXED DECIMAL(5,1);
EXEC SQL END DECLARE SECTION
= `P2 ; /* por exemplo */
EXEC SQL SELECT P.PESO
INTO :PESO
FROM P
WHERE P.P# = :P#
IF SQLSTATE = `00000
THEN ... /* PESO = valor obtido pela busca /
ELSE ... ; /* ocorreu alguma exceo */
FIGURA 4.3 Fragmento de um programa PL/I com SQL embutida
3. As instrues de SQL podem incluir referncias a variveis
hospedeiras; essas referncias devem incluir um prefixo de
dois-pontos para distingui-las dos nomes de colunas de SQL.
As variveis hospedeiras podem aparecer em SQL embutida onde
quer que um literal possa surgir em SQL interativa. Elas
tambm podem surgir em uma clusula INTO em uma instruo
SELECT (ver pargrafo 4 a seguir) ou FETCH (consulte
novamente a subseo Operaes que envolvem cursores mais
adiante) para designar destinos de operaes de busca.
4. Note a clusula INTO na instruo SELECT da Figura 4.3. A
finalidade dessa clusula (como acabamos de mencionar)
especificar as variveis de destino nas quais os valores
devem ser atribudos; a i-sima varivel de destino
mencionada na clusula TNTO corresponde ao i-simo valor a
ser retornado, como especifica a clusula SELECT.
5. Todas as variveis hospedeiras referenciadas em instrues
SQL devem ser declaradas (DCL em PL/I) dentro de uma seo de
declarao de SQL embutida, delimitada pelas instrues BEGIN
e
END DECLARE SECTION.
6. Todo programa que contm instrues SQL embutidas deve
incluir uma varivel hospedeira chamada SQLSTATE. Aps a
execuo de qualquer instruo de SQL, um cdigo de status
retornado ao programa nessa varivel; em particular, o cdigo
de status 00000 significa que a instruo foi executada com
sucesso, e o valor 02000 significa que a instruo foi
executada, mas que no foram encontrados dados que
satisfizessem o pedido. Por essa razo, em princpio, toda
instruo SQL no programa deve ser seguida por um teste em
SQLSTATE, e devem ser executadas aes apropriadas se o valor
no for o esperado. Contudo, na prtica, esses testes podem
com frequncia ser implcitos (consulte o pargrafo 9 a
seguir).
7. Variveis hospedeiras devem ter um tipo de dado apropriado
para os usos a que elas se destinam. Em particular, uma
varivel hospedeira que tenha de ser usada como destino (por
exemplo, em SELECT) deve ter um tipo de dados compatvel com
o da expresso que fornece o valor a ser atribudo a esse
destino; da mesma forma, uma varivel hospedeira que tenha de
ser usada como origem (por exemplo, em INSERT) deve ter um
tipo de dados compatvel com o da coluna de SQL qual os
valores dessa origem devem ser atribudos. Comentrios
semelhantes se aplicam a uma varivel hospedeira que deva ser
usada em uma comparao ou, na verdade, em qualquer tipo de
operao. Para obter detalhes sobre o significado exato da
compatibilidade dos tipos de dados no sentido anterior,
consulte a referncia [4.22].
78
8. Variveis hospedeiras e colunas de SQL podem ter o mesmo
nome.
9. Como j mencionamos, toda instruo SQL deve, em
princpio, ser seguida por um teste do valor retornado em
SQLSTATE. A instruo WHENEVER fornecida para simplificar
esse processo. A instruo WHENEVER assume a forma:
EXEC SQL WHENEVER <condio> <ao>
Aqui, <condio> SQLERROR ou NOT FOUND, e <ao> uma
instruo CONTINUE ou GO TO. A instruo WHENEVER no uma
instruo executvel, mas sim uma diretiva para o compilador
de SQL. A expresso WHENEVER <condio> GO TO <rtulo> faz
o compilador inserir uma instruo da forma IF <condio> GO
TO <rtulo> END IF aps cada instruo de SQL executvel que
encontrar; j WHENEVER <condio> CONTINUE faz com que no
seja inserida nenhuma dessas instrues; nesse caso, a
implicao que o programador far a insero manual de tais
instrues. Os dois argumentos <condio> so definidos da
seguinte maneira:
NOT FOUND significa no foram encontrados dados
SQLSTATE = 02000 (normalmente)
SQLERROR significa ocorreu um erro
ver referncia [4.22] sobre SQLSTATE
Cada instruo WHENEVER que o compilador de SQL encontra em
sua busca sequencial pelo texto do programa (para uma
determinada condio) anula a anterior que ele encontrou
(para essa condio).
10. Por fim, observe que para usar a terminologia do
Captulo 2 a SQL embutida constitui um acoplamento fraco
entre a SQL e a linguagem hospedeira.
Aqui terminam os conceitos preliminares. No restante desta
seo, iremos concentrar nossa ateno especificamente em
operaes de manipulao de dados. Conforme j indicamos, a
maioria dessas operaes pode ser tratada de forma bastante
direta (isto , com apenas algumas alteraes em sua
sintaxe). No entanto, as operaes de busca exigem um
tratamento especial. O problema que essas operaes
retornam muitas linhas (em geral), no apenas uma, e as
linguagens hospedeiras normalmente no esto equipadas para
manipular mais de uma linha de cada vez. Por esse motivo,
necessrio fornecer alguma espcie de ponte entre o
processamento orientado a conjuntos da SQL e o processamento
orientado a tuplas (ou linhas) da linguagem hospedeira, e os
cursores fornecem tal ponte. Um cursor um tipo especial de
objeto da SQL que s se aplica SQL embutida (porque a SQL
interativa no precisa dele). Em essncia, ele consiste em
uma espcie de ponteiro (lgico) que pode ser usado para
examinar uma coleo de linhas, apontando para cada uma das
linhas de cada vez e fornecendo assim a possibilidade de
enderear essas linhas uma a uma. Porm, adiaremos a
descrio detalhada dos cursores para uma seo posterior, e
consideraremos primeiro as instrues que no necessitam
deles.
Operaes que no envolvem cursores
As instrues de manipulao de dados que no necessitam de
cursores so:
- SELECT unitria.
- INSERT.
- UPDATE (exceto na forma CURRENT ver mais adiante).
- DELETE (novamente, exceto na forma CURRENT ver mais
adiante).
Daremos exemplos de cada dessas instrues, uma por vez.
79
SELECT unitria: obter o status e a cidade para o fornecedor
cujo nmero de fornecedor dado pela varivel hospedeira
DADOF#.
EXEC SQL SELECT STATUS, CIDADE
INTO :GRAU, :CIDADE
FROM F
WHERE F# : DADOF#
Usamos o termo SELECT unitria para indicar uma expresso
SELECT que avaliada como uma tabela contendo no mximo uma
linha. No exemplo, se houver exatamente uma linha na tabela F
que satisfaa condio da clusula WHERE, ento os valores
de STATUS e CIDADE dessa linha sero atribudos s variveis
hospedeira GRAU e CIDADE como solicitado, e SQLSTATE ser
definida como 00000. Se nenhuma linha de F satisfazer
condio de WHERE, SQLSTATE ser definida como 02000. Alm
disso, se mais de uma linha satisfazer condio, o programa
tem erro e SQLSTATE ser definida como um cdigo de erro.
INSERT: inserir uma nova pea (nmero de pea, nome e peso
dados pelas variveis hospedeiras P#, PNOME e PPS,
respectivamente; cor e cidade desconhecidos) na tabela P.
EXEC SQL INSERT
INTO P ( P#, PNOME, PESO
VALUES ( :P#, :PNOME, :PPS ) ;
Os valores de COR e CIDADE para a nova pea sero definidos
como os valores default aplicveis. Consulte o Captulo 5,
Seo 5.5, para ver uma descrio dos valores default da SQL.
UPDATE: aumentar o status de todos os fornecedores de Londres
de acordo com a proporo dada pela varivel hospedeira
AUMENTO.
EXEC SQL UPDATE F
SET STATUS = STATUS + :AUMENTO
WHERE CIDADE = `Londres
Se nenhuma linha de fornecedor satisfizer condio WHERE,
SQLSTATE ser definida como 02000.
DELETE: eliminar todas as remessas correspondentes a
fornecedores cuja cidade dada pela varivel hospedeira
CIDADE.
EXEC SQL DELETE
FROM FP
WHERE :CIDADE =
SELECT CIDADE
FROM F
WHERE F.F# = FP.F# ) ;
Novamente, SQLSTATE ser definida como 02000 se nenhuma linha
de FP satisfizer condio WHERE. Mais uma vez, observe a
subconsulta aninhada (dessa vez na clusula WHERE).
Operaes que envolvem cursores
Agora vamos examinar a questo da busca em nvel de conjunto
isto , o retorno de um conjunto con80 tendo um nmero
arbitrrio de linhas, em vez de no mximo uma linha, como no
caso da SELECT unitria. Como explicamos antes, o que
necessrio aqui um mecanismo para obter acesso s linhas do
conjunto uma a uma, e os cursores oferecem esse mecanismo. O
processo ilustrado de forma geral pelo exemplo da Figura
4.4 (a seguir), o qual pretende buscar detalhes de
fornecedores (F#, FNOME e STATUS) para todos os fornecedores
na cidade dada pela varivel hospedeira Y.
Explicao: a instruo DECLARE X CURSOR... define um
cursor chamado X, com uma expresso de tabela associada (ou
seja, uma expresso avaliada como uma tabela), especificada
pela instruo SELECT que forma parte dessa DECLARE. Essa
expresso de tabela no avaliada nesse momento; DECLARE
CURSOR uma instruo puramente declarativa. A expresso
avaliada quando o cursor aberto (OPEN X). A instruo
FETCH X INTO... usada ento para recuperar as linhas uma
de cada vez no conjunto resultante, atribuindo os valores
retornados a variveis hospedeiras de acordo com as
especificaes da clusula INTO nessa instruo. (Por
simplicidade, demos s variveis hospedeiras os mesmos nomes
das colunas correspondentes do banco de dados. Note que a
instruo SELECT na declarao do cursor no tem uma clusula
INTO prpria.) Tendo em vista que haver muitas linhas no
conjunto de resultados, a instruo FETCH aparecer
normalmente dentro de um loop; o loop ser repetido desde que
ainda existam outras linhas a serem includas no conjunto de
resultados. Na sada do loop, o cursor X fechado (CLOSE
X).
EXEC SQL DECLARE X CURSOR FOR /* define o cursor /
SELECT F.F#, F.FNOME, F.STATUS
FROM F
WHERE F.CIDADE =
ORDER BY F# ASC ;
EXEC SQL OPEN X ; /* executa a consulta /
DO /*para todas as linhas de F acessveis via X*/
EXEC SQL FETCH X INTO :F#, :FNOME, :STATUS ;
/*vai buscar prximo fornecedor /
END ;
EXEC SQL CLOSE X ; /* desativa o cursor X */
FIGURA 4.4 Exemplo de busca retornando vrias linhas
Agora vamos considerar os cursores e as operaes de cursores
com mais detalhes. Em primeiro lugar, um cursor declarado
por meio de uma instruo DECLARE CURSOR, que assume o
formato geral:
EXEC SQL DECLARE <nome do cursor> CURSOR
FOR <expresso de tabela> { <ordenao>
(estamos ignorando algumas especificaes opcionais no
interesse da brevidade). Para ver uma explicao completa de
<expresso de tabela>, consulte o Apndice A. O parmetro
opcional <ordenao> toma a forma:
ORDER BY <lista_com_vrgulas de itens de ordenao>
onde (a) a lista com vrgulas de <itens de ordenao> no
deve estar vazia ver o pargrafo imediatamente seguinte e
(b) cada <item de ordenao> individual consiste em um nome
de coluna (no qualificado, devemos observar), seguido
opcionalmente por ASC (ascendente ou crescente) ou DESC
(descendente ou decrescente); ASC o default.
Nota: definimos o termo lista_com_vrgulas como a seguir.
Considere que <xyz> denote uma categoria sinttica arbitrria
(isto , qualquer coisa que aparea no lado esquerdo de
alguma regra de produo 81
da BNF). Ento, a expresso <lista_com_vrgulas de xyz>
denota uma sequncia de zero ou mais <xyz>s, na qual cada par
de <xyz>.s adjacentes est separado por uma vrgula (e
possivelmente por um ou mais espaos em branco). Observe que
faremos uso extensivo do recurso da lista de vrgulas em
regras de sintaxe futuras (na verdade, em todas as regras de
sintaxe, no apenas nas de SQL).
Conforme afirmamos anteriormente, a instruo DECLARE CURSOR
declarativa, e no-executvel; ela declara um cursor com o
nome especificado e que tem a expresso de tabela e a
ordenao especificadas associadas permanentemente a ele. A
expresso de tabela pode incluir referncias a variveis
hospedeiras. Um programa pode incluir qualquer nmero de
instrues DECLARE CURSOR, cada uma das quais deve ( claro)
servir a um cursor diferente.
Trs instrues executveis so fornecidas para operao
sobre cursores: OPEN, FETCH e
CLOSE.
A instruo:
EXEC SQL OPEN <nome de cursor>
abre ou ativa o cursor especificado (que no deve estar
aberto no momento). Na verdade, a expresso de tabela
associada com o cursor avaliada (usando-se os valores
atuais de quaisquer variveis hospedeiras referenciadas
dentro dessa expresso); um conjunto de linhas portanto
identificado e se torna o conjunto ativo corrente para o
cursor. O cursor tambm identifica uma posio dentro desse
conjunto ativo, ou seja, a posio imediatamente antes da
primeira linha. (Conjuntos ativos sempre so considerados
como tendo uma ordenao; desse modo, o conceito de posio
tem significado.* A ordenao a definida pela clusula
ORDER BY ou uma ordenao determinada pelo sistema, na
ausncia de tal clusula.)
A instruo:
EXEC SQL FETCH <nome de cursor>
INTO <lista_comvrgulas de referncias a variveis
hospedeiras>
avana o cursor especificado (que deve estar aberto) para a
prxima linha no conjunto ativo, e depois atribui o i-simo
valor dessa linha i-sima varivel hospedeira referenciada
na clusula INTO. Se no houver uma prxima linha quando
FETCH for executada, SQLSTATE ser definida como 02000 e
nenhum dado ser retornado.
A instruo:
EXEC SQL CLOSE <nome de cursor>
fecha ou desativa o cursor especificado (que deve estar
aberto no momento). Agora, o cursor no tem nenhum conjunto
ativo atual. Porm, ele pode ser novamente aberto em seguida;
nesse caso, ele ir obter outro conjunto ativo talvez no
exatamente o mesmo conjunto de antes, em especial se os
valores de quaisquer variveis hospedeiras referenciadas na
declarao do cursor tiverem sido alteradas nesse meio tempo.
Observe que a alterao dos valores dessas variveis
hospedeiras enquanto o cursor est aberto no tem nenhum
efeito sobre o conjunto ativo atual.
Duas instrues adicionais podem incluir referncias a
cursores, isto , as formas CURRENT de UPDATE e DELETE. Se um
cursor, digamos X, estiver posicionado no momento sobre uma
determinada linha, possvel a operao UPDATE (de alterar)
ou DELETE (de excluir) o valor atual de X, ou seja, a linha
na qual X est posicionado. Por exemplo:
EXEC SQL UPDATE F
SET STATUS = STATUS + :AUMENTO
WHERE CURRENT OF X ;
* claro que conjuntos propriamente ditos no tm uma
ordenao (ver Captulo 5); assim, um conjunto ativo na
realidade no de modo algum um conjunto em si. Seria melhor
consider-lo uma lista ordenada ou um array (de linhas).
Nota: as formas CURRENT de UPDATE e DELETE no sero
permitidas se a expresso de tabela na declarao do cursor
definir uma viso no atualizvel, caso ela faa parte de uma
instruo CREATE VIEW (consulte o Captulo 9, Seo 9.6).
SQL dinmica
A SQL dinmica consiste em um conjunto de recursos embutidos
de SQL que se destinam a oferecer suporte construo de
aplicaes generalizadas, on-line e possivelmente
interativas. (Lembramos que, no Captulo 1, uma aplicao on-
line foi definida como uma aplicao capaz de fornecer
suporte para o acesso ao banco de dados a partir de um
terminal on-line.) Considere o que uma tpica aplicao on-
line tem de fazer. Em linhas gerais, os passos que ela deve
percorrer so:
1. Aceitar um comando do terminal.
2. Analisar esse comando.
3. Executar instrues SQL apropriadas sobre o banco de
dados.
4. Retornar uma mensagem e/ou resultados ao terminal.
Se o conjunto de comandos que o programa pode aceitar no
Passo 1 for razoavelmente pequeno, como no caso de (talvez)
um programa que lida com reservas de passagens areas, ento
o conjunto de instrues SQL passveis de serem executadas
provavelmente tambm ser pequeno e poder ser embutido no
cdigo do programa. Nesse caso, os Passos 2 e 3 anteriores
consistiro apenas na lgica para examinar o comando de
entrada, e depois no desvio para a parte do programa que
emite a(s) instruo(es) SQL predefinida(s). Por outro lado,
se houver possibilidade de grandes variaes na entrada,
ento poder no ser prtico predefinir e embutir no cdigo
instrues SQL para cada comando possvel. Em vez disso,
talvez seja muito mais conveniente construir as instrues
SQL necessrias de forma dinmica e, em seguida, compilar e
executar essas instrues. Os recursos de SQL dinmica so
fornecidos para auxili-lo nesse processo.
As duas principais instrues dinmicas so PREPARE e
EXECUTE. Seu uso est ilustrado no seguinte exemplo
(irrealista e simples, porm preciso).
DCL SQLSOURCE CHAR VARYING (65000)
SQLSOURCE = `DELETE FROM FP WHERE QDE < 300
EXEC SQL PREPARE SQLPREPPED FROM :SQLSOURCE
EXEC SQL EXECUTE SQLPREPPED
Explicao:
1. O nome SQLSOURCE identifica uma varivel de string de
caracteres de comprimento varivel em PL/I, na qual o
programa construir de algum modo o formato fonte (isto , a
representao do string de caracteres) de alguma instruo
SQL uma instruo DELETE em nosso exemplo especfico.
2. Em contraste, o nome SQLPREPPED identifica uma varivel
SQL, no uma varivel PL/I, que ser usada (conceitualmente)
para guardar a forma compilada da instruo SQL cujo fonte
dado em SQLSOURCE. (Os nomes SQLSOURCE e SQLPREPPED so
naturalmente arbitrrios.)
3. A instruo de atribuio em PL/I SQLSOURCE = ...;
atribui a SQLSOURCE a forma fonte de uma instruo DELETE da
SQL. claro que, na prtica, o processo de construo de uma
instruo fonte como essa provavelmente ser muito mais
complexo envolvendo talvez a entrada e a anlise de alguma
solicitao do usurio final, expressa em linguagem natural
ou de algum outro modo mais amistoso para o usurio que a
SQL.
83
4. A instruo PREPARE recebe ento essa instruo fonte e a
prepara (isto , compila) para produzir uma verso
executvel, a qual armazenada em SQLPREPPED.
5. Finalmente, a instruo EXECUTE executa essa verso de
SQLPREPPED e, desse modo, realiza a operao DELETE de fato.
As informaes de SQLSTATE da instruo DELETE so retornadas
como se DELETE tivesse sido executada diretamente da maneira
normal.
Observe que, pelo fato de denotar uma varivel SQL e no uma
varivel PL/I, o nome SQLPREPPED no tem o prefixo de dois-
pontos quando referenciado nas instrues PREPARE e
EXECUTE. Observe tambm que essas variveis SQL no precisam
ser declaradas de modo explcito.
A propsito, o processo que acabamos de descrever
exatamente o que acontece quando as prprias instrues SQL
so introduzidas de modo interativo. A maioria dos sistemas
oferece alguma espcie de processador de consultas de SQL
interativa. Na verdade, esse processador de consultas
apenas um tipo particular de aplicao on-line generalizada;
ele est preparado para aceitar uma variedade extremamente
ampla de formas de entrada, ou seja, qualquer instruo SQL
vlida (ou no-vlida!). Ele utiliza os recursos da SQL
dinmica para construir instrues SQL convenientes que
correspondem sua entrada, para compilar e executar essas
declaraes construdas, e ainda para retornar mensagens e
resultados ao terminal.
Conclumos esta subseo (e esta seo) com uma breve meno
a um acrscimo mais recente (de 1995) ao padro, conhecido
como SQL Call-Level Interface (SQL/CLI, sendo CLI a
abreviatura da expresso em ingls correspondente a interface
de nvel de chamada). A CLI se baseia fortemente na interface
Open Database Connectivity (ODBC) da Microsoft. A CLI permite
que uma aplicao escrita em uma das linguagens hospedeiras
usuais emita solicitaes invocando certas rotinas da CLI
fornecidas pelo fabricante. Essas rotinas, que devem ter sido
vinculadas aplicao em questo, utilizam ento a SQL
dinmica para executar as operaes de banco de dados
solicitadas em favor da aplicao. (Em outras palavras, do
ponto de vista do SGBD, as rotinas da CLI podem ser
consideradas apenas como outra aplicao.)
Como podemos ver, a SQL/CLI (e tambm a ODBC, bom frisar)
procura resolver o mesmo problema geral que a SQL dinmica:
ambas permitem que sejam escritas aplicaes para as quais as
instrues SQL exatas a serem executadas no so conhecidas
at o momento da execuo. Entretanto, na realidade elas
representam uma abordagem melhor que a SQL dinmica para o
problema. H duas razes principais para isso:
- Em primeiro lugar, a SQL dinmica um padro de cdigo-
fonte. Assim, qualquer aplicao que usa a SQL dinmica exige
os servios de algum tipo de compilador de SQL para processar
as operaes PREPARE, EXECUTE, etc. prescritas por esse
padro. Em contraste, a CLI simplesmente padroniza os
detalhes de certas invocaes de rotina (isto , basicamente
chamadas de sub-rotinas); no necessrio nenhum servio
especial do compilador, apenas os servios normais do
compilador padro da linguagem hospedeira. Como resultado, as
aplicaes podem ser distribudas (talvez por fornecedores de
software independentes) sob a forma de cdigo-objeto
empacotado.
- Segundo, essas aplicaes podem ser independentes do SGBD;
ou seja, a CLI inclui recursos que permitem a criao
(novamente, talvez por fornecedores de software
independentes) de aplicaes genricas que podem ser usadas
com vrios SGBDs diferentes, em vez de terem de ser
especficas para algum SGBD em particular.
Interfaces como CLI, ODBC e JDBC (uma variante em Java da
ODBC) esto se tornando cada vez mais importantes na prtica,
por razes que sero discutidas (em parte) no Captulo 20.
4.7 A SQL NO PERFEITA
Como afirmamos na introduo a este captulo, a SQL est
muito longe de ser a linguagem relacional perfeita ela
sofre de numerosos pecados de omisso e comisso. Sero
oferecidas crticas especficas em pontos apropriados de
84
captulos subsequentes, mas a questo fundamental
simplesmente a de que a SQL apresenta falhas em um nmero
muito grande de aspectos para fornecer suporte apropriado ao
modelo relacional. Em consequncia disso, no est claro de
modo algum que os produtos SQL de hoje realmente devam
merecer o rtulo de relacionais! De fato, pelo menos at
onde o autor tem conhecimento, no existe nenhum produto no
mercado atual que oferea suporte a todos os detalhes do
modelo relacional. Isso no quer dizer que algumas partes do
modelo no tenham importncia; pelo contrrio, todo detalhe
do modelo importante e, mais ainda, importante por razes
genuinamente prticas. importante frisar que, na realidade,
o propsito da teoria relacional no apenas terico; em vez
disso, a finalidade dessa teoria fornecer uma base sobre a
qual sero elaborados sistemas 100% prticos. Porm, o triste
fato que os fornecedores no tm ainda a exata noo do
desafio de implementar a teoria em sua totalidade. Em
consequncia disso, todos os produtos relacionais de hoje
apresentam falhas, de um modo ou de outro, quando se trata de
fornecer todos os benefcios da tecnologia relacional.
4.8 RESUMO
Isso conclui nossa introduo a alguns dos principais
recursos do padro SQL (SQL/92). Enfatizamos o fato de que
a SQL muito importante do ponto de vista comercial, embora
infelizmente ela seja um pouco deficiente sob a tica
relacional pura.
A SQL inclui um componente de linguagem de definio de dados
(DDL data definition language) e um componente de linguagem
de manipulao de dados (DML data manipulation language). A
DML de SQL pode operar tanto no nvel externo (sobre vises)
quanto no nvel conceitual (sobre tabelas bsicas). Do mesmo
modo, a DDL de SQL pode ser usada para definir objetos no
nvel externo (vises), no nvel conceitual (tabelas
bsicas), e mesmo na maioria dos sistemas comerciais,
embora no no padro em si no nvel interno (isto , em
ndices e outras estruturas fsicas de armazenamento). Alm
disso, a SQL tambm oferece certos recursos de controle de
dados ou seja, recursos que na realidade no podem ser
classificados como pertencentes DDL ou DML. Um exemplo
desses recursos a instruo GRANT, que permite aos usurios
concederem privilgios de acesso uns aos outros (consulte o
Captulo 16).
Mostramos como a SQL pode ser usada para criar tabelas
bsicas, com a utilizao da instruo CREATE TABLE. Em
seguida, apresentamos alguns exemplos de instrues SELECT,
INSERT, UPDATE e DELETE, mostrando em particular como SELECT
pode ser usada para expressar as operaes relacionais de
restrio, projeo e juno. Tambm descrevemos brevemente o
Information Schema, que consiste em um conjunto de vises
prescritas a partir de um hipottico Definition Schema.
Alm disso, examinamos os recursos da SQL para lidar com
vises e transaes.
Uma parte bem grande do captulo tratou da SQL embutida. A
idia bsica que rege a SQL embutida o princpio da
dualidade, isto , o princpio segundo o qual (na medida do
possvel) qualquer instruo SQL que possa ser utilizada
interativamente tambm possa ser usada em um programa
aplicativo. A principal exceo a esse princpio surge em
conexo com operaes de busca com retorno de vrias linhas,
que exigem o uso de um cursor para servir de ponte sobre o
abismo entre o processamento orientado a conjuntos da SQL e o
processamento orientado a tuplas ou linhas das linguagens
hospedeiras, como PL/I.
Depois de um certo nmero de temas preliminares necessrios
(embora relacionados principalmente com a sintaxe)
incluindo em particular uma breve explicao de SQLSTATE
consideramos as operaes, como SELECT unitria, INSERT,
UPDATE e DELETE, que no precisam de cursores. Depois
voltamos nossa ateno para as operaes que precisam de
cursores, e discutimos DECLARE CURSOR, OPEN, FETCH, CLOSE e
as formas CURRENT (atuais) de UPDATE e DELETE. (O padro se
refere s formas CURRENT desses operadores como UPDATE e
DELETE posicionados e usa o termo UPDATE e DELETE pesquisados
para as formas no CURRENT ou cadas do cu.) Finalmente,
fornecemos uma introduo muito breve do conceito de SQL
dinmica, descrevendo em especial as instrues PREPARE e
EXECUTE, e mencionamos tambm a CLI, ou Call-Level Interface
(Interface de nvel de chamada) de SQL. 85
EXERCICIOS
4.1 A Figura 4.5 (a seguir) mostra alguns valores de dados de
amostra para uma forma estendida do banco de dados de
fornecedores e peas que chamamos banco de dados de
fornecedores, projetos e peas. Fornecedores (F), peas (P) e
projetos (J) so identificados de forma exclusiva por nmero
de fornecedor (F#), nmero de pea (P#) e nmero de projeto
(J#), respectivamente. O significado de uma linha de FPJ
(remessa) que o fornecedor especificado fornece a pea
especificada para o projeto especificado na quantidade
especificada (e a combinao F#-P#-J# identifica de modo
exclusivo tal linha). Escreva um conjunto apropriado de
definies SQL para esse banco de dados. Nota: esse banco de
dados ser usado como base para numerosos exerccios em
captulos subsequentes.
4.2 Na Seo 4.2, descrevemos a instruo CREATE TABLE
conforme ela definida pela SQL padro [4.11. Muitos
produtos comerciais de SQL oferecem suporte para opes
adicionais sobre essa instruo; porm, em geral elas esto
relacionadas com ndices, alocao de espao de disco e
outras questes de implementao (prejudicando com isso os
objetivos de independncia fsica de dados e compatibilidade
entre sistemas). Examine qualquer produto SQL que possa estar
disponvel para voc. As crticas precedentes se aplicam a
esse produto? Especificamente, quais opes adicionais de
CREATE TABLE o produto admite?
4.3 Mais uma vez, investigue qualquer produto de SQL que
possa estar disponvel para voc. Esse produto oferece
suporte para o Information Schema? Se no, que aspecto tem o
seu suporte de catlogo?
4.4 Apresente formulaes de SQL para os seguintes problemas
de atualizao do banco de dados de fornecedores-peas-
projetos:
a. Inserir um novo fornecedor FiO na tabela F. O nome e a
cidade so Smith e Nova York, respectivamente; o status ainda
no conhecido.
b. Mudar a cor de todas as peas vermelhas para alaranjado.
c. Eliminar (excluir) todos os projetos para os quais no h
remessas.
FIGURA 4.5 O banco de dados de fornecedores, peas e projetos
(amostras de valores)
FPJ
F
P
J
86
F# ENOME STATUS CIDADE
F1 Smith 20 Londres
F2 Jones 10 Paris
F3 Blake 30 Paris
F4 Clark 20 Londres
F5 Adams 30 Atenas
P# PNOME COR PESO CIDADE
P1 Porca Vermelho 12.0 Londres
P2 Pino Verde 17.0 Paris
P3 Parafuso Azul 17.0 Roma
P4 Parafuso Vermelho 14.0 Londres
P5 Came Azul 12.0 Paris
P6 Tubo Vermelho 19.0 Londres
J# JNOME CIDADE
Ji Classificador Paris
J2 Monitor Roma
J3 OCR Atenas
34 Console Atenas
35 RAID Londres
J6 EDS Oslo
J7 Fita Londres
F# P# J# QDE
Fi P1 Ji 200
Fi P1 J4 700
F2 P3 Ji 400
F2 P3 J2 200
F2 P3 33 200
F2 P3 J4 500
F2 P3 J5 600
F2 P3 J6 400
F2 P3 37 800
F2 P5 32 100
F3 P3 Ji 200
F3 P4 32 500
F4 P6 J3 300
F4 P6 37 300
F5 P2 J2 200
F5 P2 J4 100
F5 P5 35 500
F5 P5 J7 100
F5 P6 J2 200
F5 P1 J4 100
F5 P3 34 200
F5 P4 J4 800
F5 P5 34 400
F5 P6 34 500
4.5 Usando o banco de dados fornecedores-peas-projetos,
escreva um programa com instrues de SQL embutida para
listar todas as linhas de fornecedores, em ordem de nmero de
fornecedor. Cada linha de fornecedor deve ser seguida
imediatamente na listagem por todas as linhas de projetos
fornecidos por esse fornecedor, em ordem de nmero de
projeto.
4.6 Considere as tabelas PEA e ESTRUTURA_PEA definidas como
a seguir:
CREATE TABLE PEA
DESCRIO
PRIMARY KEY ( P# ) ) ;
CREATE TABLE ESTRUTURA_PEA
( PRINCP# ... , SECP# ... , QDE
PRIMARY KEY ( PRINCP#, SECP# ),
FOREIGN KEY ( PRINCP# ) REFERENCES PEA,
FOREIGN KEY ( SEC P# ) REFERENCES PEA
A tabela ESTRUTURA_PEA mostra quais peas (PRINC_P#) contm
quais outras peas (SEC_P#) como componentes de primeiro
nvel. Escreva um programa SQL para listar todas as peas
componentes de uma dada pea, para todos os nveis (o
problema conhecido como part explosion). Nota: os dados de
amostra apresentados na Figura 4.6 podero ajud-lo a
visualizar esse problema. Observamos que a tabela
ESTRUTURA_PEA mostra como os dados da lista de materiais
(bili-o [-materiais) consulte o Captulo 1, Seo 1.3,
subseo Entidades e relacionamentos so representados
tipicamente em um sistema relacional.
FIGURA 4.6 A tabela ESTRUTURA_PEA (amostra de valores)
REFERNCIAS E BIBLIOGRAFIA
4.1 M. M. Astrahan e R. A. Lorie: SEQUEL-XRM: A Relational
System, Proc. ACM Pacific Regional Conf., San Francisco,
Calif. (abril de 1975).
Descreve a implementao do primeiro prottipo de SEQUEL, a
verso original de SQL [4.8]. Ver tambm as referncias [4.2
e 4.3], que realizam funo anloga para o System R.
4.2 M. M. Astrahan et ai.: System R: Relational Approach to
Database Management, ACM TODS 1, Nmero
2 (junho de 1976).
O System R era a implementao de prottipo principal da
linguagem SEQUEL/2 (mais tarde chamada SQL) [4.8]. Esse
artigo descreve a arquitetura do System R, como ela foi
originalmente planejada. Ver tambm a referncia [4.3].
4.3 M. W. Blasgen et ai.: System R: An Architectural
Overview, IBM Sys. J. 20, Nmero 1 (fevereiro de
1981).
Descreve a arquitetura do System R, como ela se tornou quando
o sistema foi completamente implemen tad (compare com a
referncia [4.2]). 87
ESTRUTURA_PEA PRINCP# SEC_P# QDE
P1 P2 2
P1 P3 4
P2 P3 1
P2 P4 3
P3 P5 9
P4 P5 8
P5 P6 3
4.4 Stephen Cannan e Gerard Otten: SQL The Standard
Handbook. Maidenhead, Reino Unido: McGraw-Hill International
(1993).
[Nosso] objetivo ... fornecer uma obra de referncia
explicando e descrevendo [a SQL/92 em sua definio original]
de um modo muito menos formal e muito mais legvel que o
prprio padro (da introduo do livro).
4.5 Joe Celko: SQL for Smarties: Advanced SQL Programming.
San Francisco, Calif.: Morgan Kaufmann (1995).
Esse o primeiro livro avanado de SQL disponvel que
oferece uma apresentao completa das tcnicas necessrias
para dar suporte a seu progresso de usurio casual de SQL at
se tornar um programador especialista (da prpria capa do
livro).
4.6 Andrew Eisenberg e Jim Melton: SQLJ Part 0, Now Known as
SQL/OLB (Object Language Bindings), ACM SIGMOD Record 27,
Nmero 4 (dezembro de 1998). Ver tambm Gray Clossman et ai.:
Java and Relational Databases: SQLJ, Proc. 1998 ACM SIGMOD
Int. Conf. on Management of Data, Seattle, Wash. (junho de
1998).
4.7 Don Chamberlin: Using the New DB2. San Francisco. Calif.:
Morgan Kaufmann (1996).
Uma descrio legvel e completa de um produto comercial de
SQL de ltima gerao, feita por um dos dois principais
projetistas da linguagem SQL original [4.8].
Nota: o livro tambm descreve algumas decises
controvertidas tomadas no projeto de SQL principalmente
(a) a deciso de oferecer suporte a nulos e (b) a deciso de
permitir a duplicao de linhas. Meu [isto , o de
Chamberlin] propsito... histrico, em vez de persuasivo
reconheo que nulos e duplicatas so questes religiosas...
Em sua maioria, os projetistas [de SQL] eram pessoas
prticas, e no tericas, e essa orientao se refletiu em
muitas decises [de projeto]. Essa posio muito diferente
da que mantida por este autor! Nulos e duplicatas so
questes cientficas, no religiosas; elas so discutidas
cientificamente neste livro nos Captulos 18 e 5,
respectivamente. No caso de prticas... e no [tericas],
rejeitamos categoricamente a sugesto de que a teoria no
prtica; j afirmamos (na Seo 4.5) nossa posio de que
pelo menos a teoria relacional , de fato, muito prtica.
4.8 Donald D. Chamberlin e Raymond F. Boyce: SEQUEL: A
Structured English Query Language, Proc.
1974 ACM SIGMOD Workshop on Data Description, Access, and
Control, Ann Arbor, Mich. (maio de
1974).
O artigo que primeiro introduziu a linguagem SQL (ou SEQUEL,
como ela foi chamada originalmente; o nome foi modificado
mais tarde por razes legais).
4.9 Donald D. Chamberlin et ai.: SEQUEL/2: SEQUEL/2: A
Unified Approach to Data Definition, Manipulation, and
Control. IBMJ. R&D. 20, Nmero 6 (novembro 1976). Ver tambm
a errata em IBMJ. R&D. 21, Nmero 1 (janeiro 1977).
A experincia da implementao do prottipo original de
SEQUEL discutida na referncia [4.1] e os resultados dos
testes de facilidade de uso relatados na referncia [4.28]
levaram ao projeto de uma verso revisada da linguagem,
chamada SEQUEL/2. A linguagem admitida pelo System R [4.2 e
4.3] era basicamente SEQUEL/2 (com a ausncia notvel dos
recursos chamados assertion e trigger ver Captulo 18)
alm de certas extenses sugeridas pela experincia dos
primeiros usurios [4.10].
4.10 Donald D. Chamberlin: A Summary of User Experience with
the SQL Data Sublanguage, Proc. Int. Conf. on Databases,
Aberdeen, Esccia (julho de 1980). Tambm disponvel como IBM
Research Report RJ2767 (abril de 1980).
Descreve a experincia dos primeiros usurios com o System R
e prope algumas extenses para a linguagem SQL luz dessa
experincia. Algumas dessas extenses EXISTS, LIKE, PREPARE
e EXECUTE
foram de fato implementadas na verso final do System R.
Nota: consulte o Captulo 7 e o Apndice A para ver uma
descrio de EXISTS e LIKE, respectivamente.
4.11 Donald D. Chamberlin et ai.: Support for Repetitive
Transactions and Ad Hoc Queries in System R, ACM TODS 6,
Nmero 1 (maro de 1981).
Apresenta algumas medidas de desempenho do System R, tanto
nos ambientes de consulta ad hoc quanto de transao
condensada (canned transaction). (Uma transao condensada
uma aplicao simples
88 que tem acesso apenas a uma pequena parte do banco de
dados e compilada antes do momento da exe
cuo. Ela corresponde ao que chamamos requisio planejada
no Captulo 2, Seo 2.8.) As medies foram feitas em um IBM
System 370 Model 158, executando o System R sob o sistema
operacional VM. Elas so descritas como preliminares;
porm, com essa advertncia, o artigo mostra entre outras
coisas que (a) a compilao quase sempre superior
interpretao, mesmo no caso de consultas ad hoc, e (b) um
sistema como o System R capaz de processar diversas
transaes condensadas por segundo, desde que existam ndices
apropriados no banco de dados.
O artigo notvel porque foi um dos primeiros a negar a
reivindicao, ouvida frequentemente na poca, de que os
sistemas relacionais nunca tero bom desempenho. E claro
que, desde que esse trabalho foi publicado pela primeira vez,
produtos relacionais comerciais alcanaram taxas de
transaes na casa de centenas e at milhares de transaes
por segundo.
4.12 Donald D. Chamberlin eta!.: A History and Evaluation of
System R, CACM 24, Nmero 10 (outubro de
1981).
Descreve as trs principais fases do projeto do System R
(prottipo preliminar, prottipo multiusurio, avaliao) com
nfase nas tecnologias de compilao e otimizao nas quais o
System R foi o pioneiro. H alguma superposio entre esse
artigo e a referncia [4.131.
4.13 Donald D. Chamberlin, Arthur M. Gilbert e Robert A.
Yost: A History of System R and SQL/Data System, Proc. 7th
Int. Conf. on Very Large Data Bases, Cannes, Frana (setembro
de 1981).
Discute as lies aprendidas a partir do prottipo do System
R e descreve a evoluo desse prottipo at chegar ao
primeiro produto da famlia de produtos DB2 da IBM, o SQL/DS
(mais tarde renomeado DB2 para VM e VSE).
4.14 C. J. Date: A Critique of the SQL Database Language,
ACM SIGMOD Record 14, Nmero 3 (novembro de 1984).
Republicado em Relational Database: Selected Writings.
Reading, Mass.: Addison-Wesley (1986).
Como observamos no corpo do captulo, a SQL no perfeita.
Esse artigo apresenta uma anlise crtica de um bom nmero
das principais deficincias da linguagem (principalmente sob
o ponto de vista das linguagens formais de computador em
geral, em vez de linguagens de bancos de dados
especificamente). Nota: certas crticas desse artigo no se
aplicam SQL/92.
4.15 C. J. Date: What's Wrong with SQL?, em Relationa!
Database Writings 1985 1989. Reading, Mass.:
Addison-Wesley (1990).
Descreve algumas deficincias adicionais da SQL, alm
daquelas identificadas na referncia [4.14], sob os ttulos
What's Wrong with SQL per se, What's Wrong with the SQL
Standard e Application Portability. Nota: novamente,
certas crticas desse artigo no se aplicam SQL/92.
4.16 C. J. Date: SQL Dos and Don'ts, em Relational Database
Writings 1985 1989. Reading, Mass.: Addison-Wesley (1990).
Esse artigo oferece alguns conselhos prticos sobre como usar
a SQL de modo a (a) evitar algumas armadilhas potenciais que
surgem dos problemas discutidos nas referncias [4.14-4.15] e
[4.181 e (b) obter os maiores benefcios possveis em termos
de produtividade, portabilidade, conectividade e assim por
diante.
4.17 C. J. Date: How We Missed the Relational Boat, em
RelationalDatabase Writings 1991 1994. Reading, Mass.:
Addison-Wesley (1995).
Um resumo sucinto das deficincias da SQL relacionadas com
seu suporte (ou com a falta dele) para os aspectos
estruturais, de integridade e manipulativos do modelo
relaciona!.
4.18 C. J. Date: Grievous Bodily Harm (em duas partes),
DBP&D 11, NmeroS (maio de 1998) e 11, Nmero
6 (junho de 1998); Fifty Ways to Quote Your Query, no Web
site DBP&D, em www.dbpd.com (julho de
1998).
A SQL uma linguagem extremamente redundante, no sentido de
que tudo, exceto as consultas mais triviais, pode ser
expresso de muitas maneiras diferentes. Esses artigos
ilustram esse ponto e discutem algumas de suas implicaes.
Em particular, eles mostram que a clusula GROUP BY, a
clusula HAVING e as variveis de intervalos, poderiam ser
todas descartadas da linguagem sem nenhuma perda efetiva de
funcionalidade (e o mesmo tambm verdadeiro no caso da
construo IN subconsulta). Nota: todas essas construes
de SQL so explicadas no Captulo 7 (Seo 7.7) e/ou no
Apndice A.
89
4.19 C. J. Date e Hugh Darwen: A Guide to the SQL Standard (4
edio). Reading, Mass.: Addison-Wesley (1997).
Um tutorial completo sobre SQL/92, incluindo CLI e PSM. Em
particular, o livro contm um apndice, o Apndice D, que
documenta muitos aspectos do padro que parecem estar
definidos de modo inadequado, ou mesmo incorretamente, neste
momento. Nota: as referncias [4.4J e [4.271 tambm so
tutoriais de SQL/92.
4.20 C. J. Date e Colin J. White: A Guide to DB2 (4 edio).
Reading, Mass.: Addison-Wesley (1993).
Fornece uma viso extensa e completa do produto DB2 original
da IBM (como ele era em 1993) e alguns de seus produtos
complementares. O DB2, como o SQLIDS [4.131, se baseava no
System R.
4.21 Neal Fishman: SQL du Jour, DBP&D 10, Nmero 10
(outubro 1997).
Uma pesquisa desanimadora de algumas incompatibilidades
encontradas entre produtos de SQL reconhecidos por todos como
tendo suporte para o padro SQL.
4.22 International Organization for Standardization (ISO):
Database Language SQL, documento ISO/IEC
9075:1992. Tambm disponvel como o documento ANSI (American
National Standards Institute) ANSI X3. 135-1992.
A definio da SQL/92 original do ISO/ANSI (conhecida como
ISO/IEC 9075, ou s vezes apenas ISO 9075). O documento
original de uma nica parte foi desde ento expandido em uma
srie de partes separadas, sob o ttulo geral Information
Technology Database Languages SQL. Na poca em que este
livro era escrito, as seguintes partes haviam sido definidas
(embora certamente no estejam concludas):
Parte 1: Arcabouo geral (SQL/Framework).
Parte 2: Fundamentos (SQL/Foundation).
Parte 3: Interface de nvel de chamada (SQL/CLI).
Parte 4: Mdulos armazenados persistentes (SQL/PSM).
Parte 5: Acoplamentos da linguagem hospedeira (SQL/Bindings).
Parte 6: Especializao em XA (SQL/Transaction).
Parte 7: Temporal (SQL/Temporal).
Parte 8: No existe nenhuma Parte 8.
Parte 9: Gerncia de dados externos (SQL/MED).
Parte 10: Acoplamentos de linguagem objeto (SQL/OLB).
As propostas da SQL3 que esperamos que sejam ratificadas em
1999 pertencem logicamente s Partes 1, 2, 4 e 5. Esboos de
trabalho que descrevem essas propostas podem ser encontrados
na Internet em ftp://jeriy. ece. umassd.
edu/isowg3/dbl/BASEdocs/public.
Nota: vale a pena mencionar que, embora a SQL seja amplamente
reconhecida como o padro internacional de bancos de dados
relacionais, o documento padro no se descreve como tal;
na verdade, ele jamais utiliza o termo relao! (A
propsito, conforme mencionamos em uma nota de rodap antiga,
o documento tambm no menciona em momento algum a expresso
banco de dados.)
4.23 International Organization for Standardization (ISO):
Information Technology Database Languages SQL Technical
Corrigendum 2. Documento ISO/IEC 9075: 1992/Cor.2: 1996(E).
Contm um grande nmero de revises e correes para a verso
original da referncia [4.22]. Infelizmente, essas revises e
correes no corrigem quase nenhum dos problemas
identificados na referncia [4.19].
4.24 Raymond A. Lorie e Jean-Jacques Daudenarde: SQL and Its
Applications. Englewood Cliffs, N.J.: Prentice-HaIl (1991).
Um livro prtico de SQL (quase metade do livro consiste em
uma srie detalhada de estudos de casos envolvendo aplicaes
realistas).
4.25 Raymond A. Lorie e J. F. Nilsson: An Access
Specification Language for a Relational Data Base System,
90 IBMJ. R&D. 23, Nmero 3 (maio de 1979).
Oferece mais detalhes sobre um determinado aspecto do
mecanismo de compilao do Sistema R [4.11, 4.254.26]. Para
qualquer instruo de SQL dada, o otimizador do Sistema R
gera um programa em uma linguagem interna chamada ASL (Access
Specification Language). Essa linguagem serve como interface
entre o otimizador e o gerador de cdigo. (O gerador de
cdigo, como seu nome sugere, converte um programa ASL em
cdigo de mquina.) A ASL consiste em operadores como scan
e insert sobre objetos como ndices e arquivos armazenados.
O propsito da ASL era tornar o processo de traduo global
mais gerencivel, decompondo-o em uma srie de subprocessos
bem definidos.
4.26 Raymond A. Lorie e Bradford W. Wade: The Compilation of
a High-Level Data Language, IBM Research Report RJ2598
(agosto de 1979).
O Sistema R foi o pioneiro em um esquema para compilar
consultas antes do momento da execuo, e
depois recompilar automaticamente essas consultas se a
estrutura fsica do banco de dados tivesse sofrido
alteraes significativas nesse nterim. Esse ensaio descreve
com certos detalhes o mecanismo de compilao e recompilao
do Sistema R, sem contudo entrar em questes relacionadas com
a otimizao (ver
a referncia [17.34] para obter informaes sobre esse ltimo
tpico).
4.27 Jim Melton e Alan R. Simon: Understanding the New SQL: A
Complete Guide. San Mateo, Calif.: Morgan Kaufmann (1993).
Um tutorial sobre a SQL/92 (como foi originalmente definida).
Melton foi o editor da especificao original da SQL/92
[4.22].
4.28 Phyllis Reisner, Raymond F. Boyce e Donald D.
Chamberlin: Human Factors Evaluation of Two Data Base Query
Languages: SQUARE and SEQUEL, Proc. NCC 44. Anaheim, Calif.
Montvale, N.J.: AFIPS Press (maio de 1975).
A predecessora da SQL, chamada SEQUEL [4.8], se baseava em
uma linguagem anterior, denominada SQUARE. Na verdade, as
duas linguagens eram fundamentalmente idnticas, mas SQUARE
usava uma sintaxe bastante matemtica, enquanto SEQUEL se
baseava em palavras-chave em ingls, como SELECT, FROM, WHERE
etc. Esse ensaio relata uma srie de experimentos sobre a
facilidade de uso das duas linguagens, com o emprego de
alunos da escola superior como participantes. Diversas
revises foram feitas em SEQUEL como resultado desse trabalho
[4.9].
4.29 David Rozenshtein, Anatoly Abramovich e Eugene Birger:
Optimizing Transact-SQL: Advanced Programming Techniques.
Fremont. Calif.: SQL Forum Press (1995).
A Transact-SQL o dialeto de SQL admitido pelos produtos
Sybase e SQL Server. Esse livro apresenta uma srie de
tcnicas de programao para Transact-SQL, baseadas no uso de
funes caractersticas (definidas pelos autores como
dispositivos que permitem aos programadores codificarem a
lgica condicional como.., expresses dentro de clusulas
SELECT, WHERE, GROUP BY e SET). Embora expressas
especificamente em termos de Transact-SQL, as idias tm na
realidade uma aplicao mais ampla. Nota: talvez devamos
acrescentar que a otimizao mencionada no ttulo do livro
se refere no ao componente otimizador do SGBD, mas sim
otimizao que pode ser feita manualmente pelos prprios
usurios.
RESPOSTAS A EXERCICIOS SELECIONADOS
4.1 CREATE TABLE F
( F# CHAR(5),
FNOME CHAR(20),
STATUS NUMERIC(5),
CIDADE CHAR(15),
PRIMARY KEY ( F# ) )
CREATE TABLE P
( P# CHAR(6),
PNOME CHAR(20),
COR CHAR(6),
PESO NUMERIC(5,1),
CIDADE CHAR(15),
PRIMARY KEY ( P# ) ) ; 91
CREATE TABLE J
( J# CHAR(4),
JNOME CHAR(20),
CIDADE CI-IAR(15),
PRIMARY KEY ( J# ) ) ;
CREATE TABLE FPJ
( F# CHAR(5),
P# CHAR(6),
J# CHAR(4),
QDE NUMERIC(9),
PRIMARY KEY ( F#, P#, J# ),
FOREIGN KEY ( F# ) REFERENCES F,
FOREIGN KEY ( P# ) REFERENCES P,
FOREIGN KEY ( J# ) REFERENCES J ) ;
4.4 a. INSERT INTO F ( F#, FNOME, CIDADE
VALUES ( `FiO', `Smith', `Nova York'
Aqui STATUS definido como o valor default aplicvel.
b. UPDATE P
SET COR = `Alaranjado'
WHERE COR = `Vermelho'
c. DELETE
FROM J
WHERE J# NOT IN
( SELECT J#
FROM FPJ )
Observe a subconsulta aninhada e o operador IN (na realidade,
o operador IN negado) na soluo da parte c., nesse caso.
Consulte o Captulo 7 para ver uma explicao adicional.
4.5 Observe que poderiam existir alguns fornecedores que no
fornecessem absolutamente nenhum projeto; a soluo a seguir
lida de modo satisfatrio com esses fornecedores (exatamente
de que modo?). Primeiro, definimos dois cursores, CF e CJ, da
seguinte forma:
EXEC SQL DECLARE CF CURSOR FOR
SELECT F.F#, F.FNOME, F.STATUS, F.CIDADE
FROM F
ORDER BY F#
EXEC SQL DECLARE CJ CURSOR FOR
SELECT J.J#, J.JNOME, J.CIDADE
FROM J
WHERE J.J# IN
( SELECT FPJ.J#
FROM FPJ
WHERE FPJ.F# = :CFF# )
ORDER BY J#
(Note uma vez mais a subconsulta aninhada e o operador IN.)
Quando o cursor CJ for aberto, a varivel hospedeira CF_F#
conter um valor de nmero de fornecedor, obtido por meio do
cursor CF. A lgica procedural essencialmente a seguinte:
EXEC SQL OPEN CF
DO para todas as linhas F acessveis via CF
EXEC SQL FETCH CF INTO :CFF#, :CF_FN, :CFFT, :CF_FC ;
imprimir CFF#, CFFN. CFFT, CF_FC
92 EXEC SQL OPEN CJ ;
DO para todas as linhas J acessveis via CJ
EXEC SQL FETCH CJ INTO :CJJ#, :CJJN, :CJJC ;
imprimir CJJ#, CJJN, CJJC
END DO ;
EXEC SQL CLOSE CJ ;
END DO ;
EXEC SQL CLOSE CF ;
4.6 Esse um bom exemplo de um problema com o qual a SQL em
sua forma corrente no lida muito bem. A dificuldade bsica
a seguinte: precisamos explodir a pea dada at n nveis,
onde o valor de n desconhecido no momento em que se escreve
o programa. Um modo comparativamente direto de executar tal
exploso de nvel n se ele fosse possvel seria atravs
de um programa recursivo, no qual cada chamada recursiva
criaria um novo cursor, como este:
CALL RECURSO ( DADOP# )
RECURSO: PROC ( SUPER_P# ) RECURSIVE ;
DCL SUPERP#
DCL INFERP# ...
EXEC SQL DECLARE C reabrvel CURSOR FOR
SELECT SECP#
FROM ESTRUTURA_PEA
WHERE PRINCP# = :SUPER_P# ;
imprimir SUPERP#
EXEC SQL OPEN C ;
DO para todas as linhas de ESTRUTURA_PEA acessveis via C
EXEC SQL FETCH C INTO :INFERP# ;
CALL RECURSO ( INFERP# )
END DO
EXEC SQL CLOSE C
END PROC ;
Nesse caso, fizemos a suposio de que a especificao
(fictcia) reabrvel sobre DECLARE CURSOR significa que
vlido OPEN (abrir) esse cursor mesmo que ele j esteja
aberto, e que o efeito de tal operao OPEN o de criar uma
nova instncia do cursor para a expresso de tabela
especificada (usando-se os valores atuais de quaisquer
variveis hospedeira referenciadas nessa expresso). Fizemos
ainda a suposio de que as referncias a tal cursor em FETCH
(etc.) so referncias instncia atual, e que CLOSE
(fechar) destri essa instncia e restabelece a instncia
anterior como atual. Em outras palavras, supusemos que um
cursor reabrvel forma uma pilha, com OPEN e CLOSE servindo
como operadores de insero push e obteno pop para essa
pilha.
Infelizmente, essas suposies so hoje puramente
hipotticas. No h nada semelhante a um cursor reabrvel
em SQL atualmente (na verdade, uma tentativa de usar OPEN
para abrir um cursor j aberto ir falhar). O cdigo anterior
invlido. Porm, o exemplo torna claro que cursores
reabrveis seriam uma extenso muito desejvel da SQL atual.
Como o procedimento anterior no funciona, damos aqui um
esboo de uma abordagem possvel (embora muito ineficiente)
que funciona.
CALL RECURSO ( DADOP# ) ;
RECURSO: PROC ( SUPER_P# ) RECURSIVE
DCL SUPERP#
DCL INFERP# .. . ; INITIAL ( ) ;
EXEC SQL DECLARE C CURSOR FOR
SELECT SECP#
FROM ESTRUTURA_PEA
WHERE PRINCP# = :SUPERP#
AND SECP# > :INFERP#
ORDER BY SECP# ;
93
imprimir SIJPERP#
DO para sempre
EXEC SQL OPEN C
EXEC SQL FETCH C INTO :INFERP#
EXEC SQL CLOSE C
IF nenhum P# inferior recuperado THEN RETURN ; END IF
IF P# inferior' recuperado THEN
CALL RECURSO ( INFERP# ) ; END IF
END DO
END PROC ;
Observe nessa soluo que o mesmo cursor usado em cada
chamada de RECURSO. (Em contraste, novas instncias de
SUPER_P# e INFER_P# so criadas dinamicamente cada vez que
RECURSAO
invocada; essas instncias so destrudas ao se concluir essa
chamada.) Devido a esse fato, temos de usar
um artificio
AND SEC P# > :INFERP# ORDER BY SECP#
de modo que, a cada invocao de RECURSO, possamos ignorar
todos os componentes imediatos (INFERP#s) do SUPER P# atual
que j tenham sido processados.
Consulte (a) as referncias [4.5J e [4.71 para ver uma
descrio de algumas abordagens alternativas no estilo de SQL
para esse problema, (b) o Captulo 6 (final da Seo 6.7)
para ver uma descrio de um operador relacional pertinente
chamado fecho transitivo, e (c) Apndice B para ter uma viso
geral de alguns recursos relevantes de SQL3.
94