Você está na página 1de 36

CAPTULO 3

Introduo aos bancos de dados relacionais

3.1 INTRODUO

Conforme explicamos no Captulo 1, grande parte da nfase


deste livro recai sobre a abordagem relacional. Em
particular, a Parte II cobre os fundamentos tericos desses
sistemas (o modelo relacional) com uma profundidade
considervel. O objetivo deste captulo apenas o de fazer
uma apresentao preliminar, intuitiva e muito informal do
material a ser examinado na Parte II (e at certo ponto,
tambm em partes subseqentes), a fim de pavimentar o caminho
para uma compreenso melhor das partes finais do livro. A
maioria dos tpicos mencionados ser discutida novamente de
modo mais formal, e com muito mais detalhes, nesses captulos
posteriores.

3.2 UMA VISO INFORMAL DO MODELO RELACIONAL

J dissemos vrias vezes que os sistemas relacionais so


baseados em uma fundamentao formal, ou teoria, chamada
modelo relacional de dados. Intuitivamente, o que essa
expresso significa (entre outras coisas) que, em um
sistema desse tipo:
1. Aspecto estrutural: os dados no banco de dados so
percebidos pelo usurio como tabelas, e nada alm de tabelas.

2. Aspecto de integridade: essas tabelas satisfazem a certas


restries de integridade (a serem discutidas no final desta
seo).
3. Aspecto manipulativo: os operadores disponveis para que o
usurio possa manipular essas tabelas
por exemplo, para propsitos de busca de dados so
operadores que derivam tabelas de outras tabelas. Desses
operadores, trs particularmente importantes so os
operadores de restrio, projeo e juno.
Um banco de dados relacional simples, o banco de dados de
departamentos e empregados, mostrado na Figura 3.1. Como
voc pode ver, esse banco de dados de fato percebido como
tabelas (e os significados dessas tabelas pretendem ser
auto-explicativos).
49

FIGURA 3.1 O banco de dados de departamentos e empregados


(amostra de valores)
A Figura 3.2 apresenta uma amostra de operaes de restrio,
projeo e juno sobre o banco de dados da Figura 3.1. Aqui
esto definies (muito informais!) dessas operaes:
A operao de restrio (tambm conhecida como seleo)
extrai linhas especficas de uma tabela.
A operao de projeo extrai colunas especficas de uma
tabela.
A operao de juno une duas tabelas com base em valores
comuns em uma coluna comum.

FIGURA 3.2 Restrio, projeo e juno (exemplos)


Dos trs exemplos, o nico que parece necessitar de mais
alguma explicao o ltimo, o exemplo de juno. Primeiro,
observe que as duas tabelas DEPTO e EMP tm de fato uma
coluna em comum (ou seja, DEPTO#), de modo que podem ser
unidas com base nos valores comuns dessa coluna. Uma

50

determinada linha da tabela DEPTO se juntar a uma dada linha


na tabela EMP (para produzir uma linha da

DEPTO
EMP

DEPTONOMEDEPTO ORAMENTO

D1 Marketing 10M

D2 Desenvolvimento 12M

D3 Pesquisa 5M
EMP# NOMEEMP DEPTO# SALRIO

E1 Lopez D1 40K
E2 Cheng D1 42K
E3 Finzi D2 30K
E4 Saito D2 35K

Restrio: Resultado: DEPTO# NOMEDEPTO ORAMENTO


DEPTOs nos quais ORAMENTO > 8M D1 Marketing 1OM
D2 Desenvolvimento l2M

Projeo: Resultado: DEPTO#


DEPTOs sobre DEPTO#, ORAMENTO D1
ORAMENTO
D2
D3

10M
12M 5M

Juno:
DEPTOs e EMP5 sobre DEPTO#
Resultado: DEPTO# NOMEDEPTO ORAMENTO EMP# NOMEEMP SALRIO

D1 Marketing 1OM E1 Lopez 40K


D1 Marketing 1OM E2 Cheng 42K
D2 Desenvolvimento 12M E3 Finzi 30K
D2 Desenvolvimento 12M E4 Saito 35K
tabela de resultados) se e somente se as duas linhas em
questo tiverem o mesmo valor em DEPTO#. Por exemplo, as
linhas de DEPTO e EMP

(com os nomes de colunas mostrados para manter a clareza)


podem ser unidas para produzir a linha de resultado
DEPTO# NOMEDEPTO ORAMENTO EMP# NOMEEMP SALRIO
D1 Marketing 10M E1 Lopez 40K
porque tm o mesmo valor D1 na coluna comum. Observe que o
valor comum aparece apenas uma vez, e no duas vezes, na
linha resultante. O resultado global da juno contm todas
as linhas possveis que podem ser obtidas dessa maneira (e
nenhuma outra linha). Observe em particular que, como nenhuma
linha de EMP tem o valor D3 em DEPTO# (isto , nenhum
empregado est designado no momento para esse departamento),
no aparece nenhuma linha correspondente a D3 no resultado,
embora exista uma linha correspondente a D3 na tabela DEPTO.
Um ponto que a Figura 3.2 ilustra claramente que o
resultado de cada uma das trs operaes outra tabela (em
outras palavras, os operadores so de fato operadores que
derivam tabelas de outras tabelas, como mencionamos antes).
Essa a propriedade de fechamento de sistemas relacionais, e
muito importante. Basicamente, pelo fato de que a sada de
qualquer operao do mesmo tipo de objeto que a entrada
ambas so tabelas e assim, a sada de uma operao pode se
tornar a entrada de outra. Desse modo, possvel (por
exemplo) obter uma projeo de uma juno, ou uma juno de
duas restries, ou uma restrio de uma projeo etc. etc.
Em outras palavras, possvel escrever expresses aninhadas
isto , expresses em que os prprios operandos so
representados por expresses gerais, em vez de simples nomes
de tabelas. Esse fato tem numerosas conseqncias
importantes, como veremos mais adiante (tanto neste captulo
quanto em muitos outros subseqentes).
A propsito, quando dizemos que a sada de cada operao
outra tabela, importante entender que estamos falando de um
ponto de vista conceitual. No queremos necessariamente dizer
que o sistema tenha na realidade de materializar o resultado
completo de cada operao individual. Por exemplo, vamos
supor que estamos tentando calcular uma restrio de uma
juno. Ento, assim que for formada uma determinada linha da
juno, o sistema poder testar imediatamente essa linha em
relao condio de restrio especificada, a fim de
verificar se ela pertence ao resultado final, e descart-la
de imediato se no pertencer. Em outras palavras, o resultado
intermedirio que a sada da juno poder jamais existir
sob a forma de uma tabela totalmente materializada. De fato,
como regra geral, o sistema sempre tenta no materializar
resultados intermedirios completos, por razes de desempenho
evidentes. Nota:
se os resultados intermedirios forem totalmente
materializados, a estratgia global de avaliao da expresso
ser chamada (de modo no surpreendente) avaliao
materializada; se os resultados intermedirios forem
repassados sob a forma de fragmentos a operaes
subseqentes, ela ser chamada avaliao em pipeline.
Outro ponto que a Figura 3.2 tambm ilustra com clareza que
as operaes so todas realizadas sobre um conjunto (de
linhas) a cada vez, e no sobre uma linha a cada vez; ou
seja, os operandos e os resultados so tabelas completas, no
apenas linhas individuais, e as tabelas contm conjuntos de
linhas. ( claro que uma tabela contendo um conjunto de
apenas uma linha vlida, bem como uma tabela vazia, isto ,
uma tabela que no contm nenhuma linha.) Por exemplo, a
juno na Figura 3.2 opera sobre duas tabelas de trs e
quatro linhas respectivamente, e retorna uma tabela
resultante de quatro linhas. Em contraste, as operaes sobre
sistemas no-relacionais em geral ocorrem no nvel de linha,
ou registro, a cada

51

DEPTO# NOMEDEPTO ORAMENTO

D1 Marketing 1OM

EMP# NOMEEMP DEPTO SALRIO

E1 Lopez D1 40K

vez; portanto, essa capacidade de processar conjuntos uma


caracterstica importante que distingue os sistemas
relacionais (veja mais detalhes sobre o assunto na Seo
3.5).
Voltemos por um momento Figura 3.1. Existem alguns pontos
adicionais a serem elaborados em conexo com o exemplo de
banco de dados dessa figura:
Primeiro, note que os sistemas relacionais s exigem que o
banco de dados seja percebido pelo usurio como tabelas. As
tabelas so a estrutura lgica em um sistema relacional, no
a estrutura fsica. No nvel fsico, de fato, o sistema
livre para armazenar os dados do modo que preferir usando
arquivos seqenciais, indexao, hashing, cadeias de
ponteiros, compactao etc. desde que somente ele possa
mapear essa representao armazenada como tabelas no nvel
lgico. Outra maneira de dizer a mesma coisa afirmar que as
tabelas representam uma abstrao do modo como os dados esto
armazenados fisicamente uma abstrao na qual numerosos
detalhes do nvel de armazenamento, como posicionamento de
registros armazenados, seqncia de registros armazenados,
representaes de valores de dados armazenados, prefixos de
registros armazenados, estruturas de acesso armazenadas como
ndices, e assim por diante, esto todos ocultos do usurio.
A propsito, o termo estrutura lgica no pargrafo anterior
pretende englobar os nveis conceitual e externo em termos
ANSI/SPARC. O detalhe importante que conforme explicamos
no Captulo 2 os nveis conceitual e externo em um sistema
relacional sero ambos relacionais, mas o nvel interno ou
fsico no. Na verdade, a teoria relacional como tal no tem
absolutamente nada a dizer sobre o nvel interno; ela se
preocupa, vale a pena repetir, com a aparncia do banco de
dados para o usurio.* A nica exigncia que, voltamos a
insistir, qualquer estrutura fsica escolhida deve
implementar totalmente a estrutura lgica.
Em segundo lugar, os bancos de dados relacionais satisfazem
a um princpio muito interessante, chamado Princpio da
Informao: todo o contedo de informao do banco de dados
representado de um e somente um modo, ou seja, como valores
explcitos em posies de colunas em linhas de tabelas. Esse
mtodo de representao o nico mtodo disponvel ( claro,
no nvel lgico) em um sistema relacional. Em particular, no
h nenhum ponteiro conectando uma tabela a outra. Por
exemplo, na Figura 3.1 h uma conexo entre a linha D1 da
tabela DEPTO e a linha E1 da tabela EMP, porque o empregado
E1 trabalha no departamento D1; porm, essa conexo
representada no por um ponteiro, mas pelo aparecimento do
valor D1 na posio DEPTO# da linha EMP correspondente a E1.
Em contraste, nos sistemas no-relacionais (por exemplo, IMS
ou IDMS) tais informaes so representadas tipicamente
como mencionamos no Captulo 1 por algum tipo de ponteiro
visvel de modo explcito para o usurio.
Nota: quando dizemos que no h nenhum ponteiro em um banco
de dados relacional, no queremos dizer que no possam
existir ponteiros no nvel fsico pelo contrrio, eles
certamente podem existir e, de fato, quase com certeza
existiro. Entretanto, como j foi explicado, todos esses
detalhes de armazenamento fsico so ocultados do usurio em
um sistema relacional.
Conclumos o estudo dos aspectos estrutural e manipulativo do
modelo relacional; agora, vamos examinar o aspecto da
integridade. Considere mais uma vez o banco de dados de
departamentos e empregados (funcionrios) da Figura 3.1. Na
prtica, esse banco de dados poderia estar sujeito a qualquer
nmero de restries de integridade por exemplo, os
salrios de empregados poderiam ter de estar no intervalo de
25K a 95K, os oramentos de departamentos deveriam estar no
intervalo de 1M a 15M, e assim por diante**. Porm, algumas
dessas restries so de tal importncia no sentido
pragmtico que desfrutam de uma nomenclatura especial. Para
sermos especficos:
uma infelicidade que a maioria dos produtos de SQL de hoje
no oferea suporte apropriado para esse aspecto da teoria.
Para ser mais especfico, esses produtos em geral admitem
apenas mapeamentos conceituais/internos bastante restritivos
(muitas vezes, eles mapeiam uma nica tabela lgica
diretamente em um nico arquivo armazenado). Em conseqncia,
eles no proporcionam quase nenhuma independncia de dados
fsica em comparao com aquilo que a tecnologia relacional
teoricamente capaz de fornecer.
** Neste e em muitos outros exemplos de valores monetrios
apresentados no livro, K representa mil unidades e M
representa 52 um milho de unidades monetrias dlares ou
reais. (N.T.)

1. Cada linha na tabela DEPTO deve incluir um nico valor


DEPTO#; do mesmo modo, cada linha na tabela EMP deve incluir
um nico valor EMP#. Dizemos informalmente que as colunas
DEPTO# na tabela DEPTO e EMP# na tabela EMP so as chaves
primrias de suas respectivas tabelas. (Voc deve lembrar
que, no Captulo 1, indicamos chaves primrias em nossos
exemplos por um duplo sublinhado.)
2. Cada valor DEPTO# na tabela EMP deve existir como um valor
DEPTO# na tabela DEPTO, a fim de refletir o fato de que cada
empregado deve ser designado para um departamento existente.
Dizemos informalmente que a coluna DEPTO# na tabela EMP uma
chave estrangeira que faz referncia chave primria da
tabela DEPTO.
Fechamos esta seo com uma definio do modelo relacional,
para fins de referncia subseqente (a despeito do fato de
que a definio bastante abstrata e no ser muito
compreensvel neste estgio). Em termos simples, o modelo
relacional consiste nos cinco componentes seguintes:
1. Uma coleo ilimitada de tipos escalares (incluindo em
particular o tipo booleano ou valor verdade).
2. Um gerador de tipo de relao e uma interpretao
pretendida para esses tipos de relaes gerados.
3. Recursos para definio de variveis de relaes desses
tipos de relaes gerados.
4. Um operador de atribuio relacional para atribuio de
valores de relaes a essas variveis de relaes.
5. Uma coleo ilimitada de operadores relacionais genricos
para derivar valores de relaes de outros valores de
relaes.
Como podemos ver, o modelo relacional muito mais que apenas
tabelas e mais restries, projees e junes, embora
muitas vezes seja caracterizado informalmente dessa maneira.
Nota: talvez voc se surpreenda ao ver que no h nenhuma
meno explcita a restries de integridade na definio
precedente. Porm, o fato que tais restries representam
apenas uma aplicao (embora uma aplicao muito importante)
dos operadores relacionais; ou seja, essas restries so
formuladas conceitualmente, de qualquer modo em termos
desses operadores, conforme veremos no Captulo 8.
3.3 RELAES E VARIVEIS DE RELAES
Se verdade que um banco de dados relacional simplesmente
um banco de dados no qual os dados so percebidos como
tabelas - e claro que verdade ento uma boa pergunta :
o que exatamente chamamos de banco de dados relacional? A
resposta simples (de fato, ns a mencionamos no Captulo
1): relao apenas um termo matemtico para uma tabela
para sermos precisos, uma tabela de um certo tipo especfico
(veremos os detalhes no Captulo 5). Assim, por exemplo,
podemos dizer que o banco de dados de departamentos e
empregados da Figura 3.1 contm duas relaes.
Agora, em contextos informais, usual tratar os termos
relao e tabela como sinnimos; na verdade,
informalmente, o termo tabela usado com muito maior
freqncia que o termo relao. Porm, vale a pena dedicar
um momento a entender por que o termo relao foi
introduzido em primeiro lugar. Em poucas palavras, a
explicao a seguinte:
Como j vimos, os sistemas relacionais se baseiam no modelo
relacional. Por sua vez, o modelo relacional uma teoria
abstrata de dados que se baseia em certos aspectos da
matemtica (principalmente na teoria dos conjuntos e na
lgica de predicados).
Os princpios do modelo relacional foram enunciados
originalmente em 1969-70 por E. F. Codd, nessa poca um
pesquisador da IBM. No final de 1968, Codd um matemtico
por formao percebeu pela primeira vez que a disciplina da
matemtica podia ser usada para injetar
53

alguns princpios slidos e algum rigor em uma rea a do


gerenciamento de bancos de dados que, at ento, era
deficiente demais em tais qualidades. As idias iniciais de
Codd foram amplamente disseminadas em um artigo agora
clssico, A Relational Model of Data for Large Shared Data
Banks (consulte a referncia [5.11 no Captulo 5).
Desde ento, essas idias agora aceitas quase
universalmente tiveram uma ampla influncia em quase todos
os aspectos da tecnologia de bancos de dados e, na verdade,
tambm em outras reas, como a inteligncia artificial, o
processamento da linguagem natural e o projeto de sistemas de
hardware.
O modelo relacional formulado originalmente por Codd fez uso
de modo muito deliberado de certos termos, como o prprio
termo relao, que no eram familiares nos crculos de
tecnologia da informao da poca (embora os conceitos fossem
familiares em alguns casos). O problema era que muitos dos
termos mais familiares eram bastante vagos eles careciam da
preciso necessria a uma teoria formal do tipo que Codd
estava propondo. Por exemplo, considere o termo registro.
Em diferentes momentos e em diferentes contextos, esse nico
termo pode significar uma ocorrncia de um registro ou um
tipo de registro; um registro lgico ou um registro fsico;
um registro armazenado ou um registro virtual; e talvez
tambm tenha outros significados. Por essa razo, o modelo
relacional no usa de forma alguma o termo registro; em vez
disso, ele utiliza o termo tupla (para rimar com dupla),
que pode ter uma definio muito precisa. No daremos essa
definio agora; para nossos propsitos atuais, suficiente
dizer que o termo tupla corresponde aproximadamente noo
de linha (assim como o termo relao corresponde
aproximadamente noo de tabela). Quando passarmos ao
estudo dos aspectos mais formais dos sistemas relacionais na
Parte II, faremos uso da terminologia formal; porm, neste
captulo, no estamos tentando ser to formais (na verdade,
nem um pouco formais), e na maioria das vezes ficaremos com
termos como linha e coluna que so razoavelmente
familiares. Contudo, um termo formal que utilizaremos
bastante a partir de agora o prprio termo relao.
Vamos voltar mais uma vez ao banco de dados de departamentos
e empregados da Figura 3.1 a fim de destacarmos outro ponto
importante. O fato que DEPTO e EMP nesse banco de dados so
na realidade variveis de relaes variveis cujos valores
so valores de relaes (diferentes valores de relaes em
momentos diferentes). Por exemplo, suponha que EMP tenha
atualmente o valor na verdade, o valor de relao
mostrado na Figura 3.1, e suponha tambm que a linha
correspondente a Saito (o empregado nmero E4) seja excluda:

DELETE EMP WHERE EMP# = E4 ;


O resultado est ilustrado na Figura 3.3.
EMP EMP# NOMEEMP DEPTO# SALRIO
E1 Lopez D1 40K
E2 Cheng D1 42K
E3 Finzi D2 30K
FIGURA 3.3 A varivel de relao EMP aps a excluso da linha
E4
Conceitualmente, o que aconteceu nesse caso foi que o antigo
valor de relao de EMP foi substitudo em bloco por um valor
de relao inteiramente novo. claro que o valor antigo (com
quatro linhas) e o novo (com trs linhas) so muito
semelhantes, mas, em termos conceituais, eles so valores
diferentes. De fato, a operao de excluso em questo
basicamente apenas uma abreviao para uma certa operao de
atribuio relacional que poderia ser semelhante a esta:
54

EMP : EMP MINUS ( EMP WHERE EMP# = E4 )

(Nota: tanto a instruo DELETE original quanto a instruo


de atribuio equivalente so expressas em uma linguagem
chamada Tutorial D [3.3]. MINUS a palavra-chave de Tutorial
D correspondente operao de diferena relacional ver
Captulo 6.) Como em todas as atribuies, o que est
acontecendo aqui em termos conceituais que (a) a expresso
no lado direito avaliada e, em seguida, (b) o resultado
dessa avaliao atribudo varivel do lado esquerdo (
claro que, por definio, esse lado esquerdo deve identificar
especificamente uma varivel). Como j mencionamos, o efeito
lquido , portanto, a substituio do antigo valor de EMP
por um novo valor.
bvio que, de modo anlogo, as operaes relacionais INSERT
e UPDATE tambm so basicamente abreviaes para certas
atribuies relacionais.
Agora, um fato infeliz que grande parte da literatura
utilize o termo relao quando o que ele realmente indica
uma varivel de relao (como tambm quando ele significa uma
relao em si isto , um valor de relao). Porm,
historicamente, essa prtica com certeza levou a uma certa
confuso. Por essa razo, em todo este livro faremos uma
distino muito cuidadosa entre variveis de relaes e
relaes propriamente ditas; de fato, seguindo a referncia
[3.3], empregaremos a expresso varivel de relao e
procuraremos expressar nossos comentrios em termos de
variveis de relaes, e no de relaes, quando for isso o
que realmente desejarmos dizer.
Nota: devemos adverti-lo de que a expresso varivel de
relao no de uso comum mas deveria ser! Na realidade,
consideramos importante deixar clara a distino entre
relaes propriamente ditas (ou seja, valores de relaes) e
variveis de relaes, ainda que edies anteriores deste
livro tenham deixado de faz-lo e que a maior parte da
literatura atual sobre bancos de dados ainda seja falha nesse
aspecto.
3.4 O QUE SIGNIFICAM AS RELAES
No Captulo 1, mencionamos o fato de que as colunas nas
relaes tm tipos de dados associados a elas.* No final da
Seo 3.2, dissemos que o modelo relacional inclui um
conjunto ilimitado de tipos [de dados]. Isso significa
(dentre outras coisas) que os usurios podero definir seus
prprios tipos (alm de serem capazes de usar tipos definidos
pelo sistema ou tipos embutidos, claro). Por exemplo,
poderamos definir tipos da seguinte maneira (mais uma vez, a
sintaxe de Tutorial D; as reticncias ... significam
pores das definies que no tm importncia na discusso
atual):
TYPE EMP# ... ;
TYPE NOME
TYPE DEPTO# ... ;
TYPE DINHEIRO
Por exemplo, o tipo EMP#, pode ser considerado (dentre outras
coisas) o conjunto de todos os nmeros de empregados
possveis; o tipo NOME como o conjunto de todos os nomes
possveis; e assim por diante.
Agora considere a Figura 3.4, que basicamente a poro de
EMP da Figura 3.1, expandida para mostrar os tipos de dados
de colunas. Como a figura indica, toda relao para ser
mais preciso, todo valor de relao tem duas partes, um
conjunto de pares nome de coluna:nome de tipo (o cabealho),
acompanhado por um conjunto de linhas em conformidade com
esse cabealho (o corpo). Nota: na prtica, muitas vezes
ignoramos os componentes de nome de tipo do cabealho, como
de fato fizemos em todos os nossos exemplos anteriores a este
ponto, mas voc deve entender que, conceitualmente, eles
esto sempre l.
Ento, existe um modo muito importante (embora talvez pouco
usual) de pensar sobre relaes; aqui est ele:
*O termo relacional mais usual para representar tipos de
dados domnios, como veremos no Captulo 5.

55

EMP

FIGURA 3 .4 Exemplo de valor de relao de EMP, mostrando-se


os tipos de colunas
Primeiro, dada uma relao r, o cabealho de r denota um
certo predicado ou funo de valor verdade.
Segundo, como mencionamos rapidamente no Captulo 1, cada
linha no corpo de r denota uma certa proposio verdadeira,
obtida a partir do predicado pela substituio dos
placeholders ou parmetros desse predicado por certos valores
de argumentos do tipo apropriado (instanciao do
predicado).
Por exemplo, no caso da Figura 3.4, o predicado semelhante
a este:
O empregado EMP# chama-se NOMEEMP, trabalha no departamento
DEPTO# e recebe um salrio de valor SALARIO
(Os parmetros so EMP#, NOMEEMP, DEPTO# e SALRIO,
correspondendo, claro, s quatro colunas de EMP.) As
proposies verdadeiras correspondentes so:
O empregado E1 chama-se Lopez, trabalha no departamento D1 e
recebe um salrio de valor 40K
(Essa proposio foi obtida substituindo-se EMP# pelo valor
E1, NOME pelo valor Lopez, DEPTO# pelo valor D1 e DINHEIRO
pelo valor 40K para os parmetros apropriados.)
O empregado E2 chama-se Cheng, trabalha no departamento D1 e
recebe um salrio de valor 42K
(Essa proposio foi obtida substituindo-se EMP# pelo valor
E2, NOME pelo valor Cheng, DEPTO# pelo valor D1 e DINHEIRO
pelo valor 42K para os parmetros apropriados), e assim por
diante. Em resumo, temos:
Tipos so (conjuntos de) coisas sobre as quais podemos
falar.
Relaes so (conjuntos de) coisas que dizemos a respeito
das coisas sobre as quais podemos falar.
(Existe uma analogia interessante nesse caso que poderia
ajudar voc a apreciar e memorizar estes pontos importantes:
tipos esto para relaes assm como substantivos esto para
frases.) Desse modo, no exemplo, as coisas sobre as quais
podemos falar so nmeros de empregados, nomes, nmeros de
departamentos e valores monetrios, e as coisas que dizemos
so declaraes verdadeiras da forma o empregado com o
nmero de empregado especificado tem o nome especificado,
trabalha no departamento especificado e recebe o salrio
especificado.
De tudo o que foi dito, segue-se que:
Primeiro, tipos e relaes so ambos necessrios (sem
tipos, no temos nada a falar sobre; sem relaes, no
podemos dizer nada).
Segundo, tipos e relaes so suficientes, alm de
necessrios isto , no precisamos de nada mais, em termos
lgicos.
Nota: tambm se depreende que tipos e relaes no so a
mesma coisa. um fato infeliz que certos produtos comerciais
produtos que no so relacionais, por definio! sejam
confusos exatamente nesse ponto. Examinaremos essa confuso
no Captulo 25 (Seo 25.2).
A propsito, importante entender que toda relao tem um
predicado associado, inclusive relaes que so derivadas de
outras por meio de operadores relacionais como o de juno.
Por exemplo, a
56

relao DEPTO da Figura 3.1 e as trs relaes resultantes da


Figura 3.2 tm predicados como estes:

EMP# EMP# NOMEEMP NOME DEPTO# DEPTO# SALRIO DINHEIRO

E1 Lopez D1 40K
E2 Cheng D1 42K
E3 Finzi D2 30K
E4 Salto D2 35K

DEPTO: o departamento DEPTO# chamado NOMEDEPTO e tem o


oramento ORAMENTO.
Restrio de DEPTO onde ORAMENTO > 8M: o departamento
DEPTO# chamado NOMEDEPTO e tem o oramento ORAMENTO, o
qual maior que oito milhes.
Projeo de DEPTO sobre DEPTO# e ORAMENTO: o departamento
DEPTO# tem algum nome e tem o oramento ORAMENTO.
Juno de DEPTO e EMP sobre DEPTO#: o departamento DEPTO#
chamado NOMEDEPTO e tem o oramento ORAMENTO, e o
empregado EMP# chamado NOMEEMP, trabalha no departamento
DEPTO# e recebe o salrio SALARIO. Observe que esse
predicado tem seis parmetros, e no sete as duas
referncias a DEPTO# denotam o mesmo parmetro.
3.5 OTIMIZAO
Conforme explicamos na Seo 3.2, operaes relacionais como
restrio, projeo e juno so todas operaes em nvel de
conjuntos. Em conseqncia disso, as linguagens relacionais
so ditas com freqncia no-procedurais (ou no-
procedimentais), tendo em vista que os usurios especificam o
que, e no como isto , eles dizem o que desejam, sem
especificar um procedimento para obt-lo. O processo de
navegao em torno dos dados armazenados para satisfazer a
solicitao do usurio feito automaticamente pelo sistema,
e no manualmente pelo usurio. Por essa razo, dizemos s
vezes que os sistemas relacionais executam a navegao
automtica. Ao contrrio, em sistemas no-relacionais, a
navegao geralmente de responsabilidade do usurio. Uma
ilustrao notvel dos benefcios da navegao automtica
mostrada na Figura 3.5, que compara uma certa instruo
INSERT de SQL com o cdigo de navegao manual que o
usurio poderia ter de escrever para obter um efeito
equivalente em um sistema no-relacional (na realidade, um
sistema em rede CODASYL; o exemplo foi tirado do captulo
sobre bancos de dados em rede na referncia [1.5]). Nota: o
banco de dados o conhecido exemplo de banco de dados de
fornecedores e peas. Consulte a Seo 3.9 para obter
explicaes adicionais.
Apesar das observaes do pargrafo anterior, devemos dizer
que no-procedural no um termo muito satisfatrio, embora
seja comum, porque proceduralidade e no-proceduralidade
no so termos absolutos. O melhor que se pode dizer que
alguma linguagem A mais ou menos procedural do que alguma
outra linguagem B. Talvez um modo melhor de expressar essas
idias fosse dizer que linguagens como a SQL esto em um
nvel de abstrao mais elevado que linguagens como C+ + e
COBOL (ou sublinguagens de dados como as que so tipicamente
encontradas em SGBDs no-relacionais, como mostra a Figura
3.5). Fundamentalmente, esse maior nvel de abstrao o
responsvel pelo aumento de produtividade que os sistemas
relacionais podem oferecer.
Decidir exatamente como executar a navegao automtica
mencionada antes responsabilidade de um componente muito
importante do SGBD chamado otimizador (mencionamos
rapidamente esse componente no Captulo 2). Em outras
palavras, para cada consulta relacional do usurio, cabe ao
otimizador escolher um modo eficiente de implementar a
consulta. A ttulo de exemplo, vamos supor que o usurio
emita a solicitao a seguir (mais uma vez, usando Tutorial
D):
RESULTADO := ( EMP WHERE EMP# = E4 ) { SALRIO }
Explicao: a expresso entre parnteses (EMP WHERE...)
denota uma restrio do valor atual da varivel de relao
EMP para apenas a linha em que EMP# E4. O nome da coluna
entre chaves (SALARIO, faz ento o resultado dessa
restrio ser projetado sobre a coluna SALARIO. Finalmente o
sinal de atribuio (: =) faz o resultado dessa projeo
ser atribudo varivel de relao
SOLICITADO. Aps essa atribuio, RESULTADO contm uma
relao de uma nica coluna e uma nica linha que contm o
salrio do empregado E4. (A propsito, observe que
implicitamente estamos fazendo uso da propriedade relacional
de fechamento nesse exemplo escrevemos uma expresso
relacional aninhada no lado direito, na qual a entrada da
operao de projeo a sada da operao de
57

INSERT INTO FP ( F#, P#, QOE )


VALUES ( F4, P3, 1000
MOVE F4 TO F# IN F
FIND CALC F
ACCEPT F-FP-ENDER FROM F-FP CURRENCY
FIND LAST FP WITHIN F-FP
while FP found PERFORM
ACCEPT F-FP-ENOER FROM F-FP CURRENCY
FIND OWNER WITHIN P-FP
GET P
IF P# IN P < P3
leave loop
END-IF
FIND PRIOR FP WITHIN F-FP
END- PERFORM
MOVE P3 TO P# IN P
FIND CALC P
ACCEPT P-FP-ENDER FROM P-FP CURRENCY
FIND LAST FP WITHIN P-FP
while FP found PERFORM
ACCEPT P-FP-ENDER FROM P-FP CURRENCY
FIND OWNER WITHIN F-FP
GET F
IF F# IN F < F4
leave loop
END-IF
FIND PRIOR FP WITHIN P-FP
END-PERFORM
MOVE 1000 TO QOE IN FP
FIND OB-KEY IS F-FP-ENOER
FIND DB-KEY IS P-FP-ENOER
STORE FP
CONNECT FP TO F-FP
CONNECT FP TO P-FP
FIGURA 3.5 Navegao automtica versus navegao manual
Agora, mesmo nesse exemplo muito simples, existem
provavelmente pelo menos dois modos de executar o necessrio
acesso aos dados:
1. Fazendo uma busca seqencial fsica da (verso armazenada
da) varivel de relao EMP at encontrar os dados exigidos.
2. Se houver um ndice sobre a (verso armazenada da) coluna
EMP# que na prtica provavelmente haver, porque os valores
de EMP# devem ser nicos e muitos sistemas de fato exigem um
ndice para forar a unicidade , usando esse ndice e indo
assim diretamente para os dados exigidos.
O otimizador escolher qual dessas duas estratgias deve ser
adotada. De maneira mais genrica, dada qualquer solicitao
em particular, o otimizador far essa escolha de estratgia
para implementao dessa solicitao com base em
consideraes como as seguintes:
Quais variveis de relaes so referenciadas na
solicitao.
Qual o tamanho atual dessas variveis de relaes.
Quais ndices existem.
58

O quanto esses ndices so seletivos.


Como os dados esto agrupados* fisicamente no disco.
Que operaes relacionais esto envolvidas.
E assim por diante. Portanto, repetimos: os usurios
especificam somente os dados que desejam, no como obter
esses dados; a estratgia de acesso para se chegar aos dados
escolhida pelo otimizador (navegao automtica).
Usurios e programas de usurios so assim independentes
dessas estratgias de acesso, o que naturalmente essencial
se deve ser alcanada a independncia de dados fsica.
Teremos muito mais a dizer sobre o otimizador no Captulo 17.

3.6 O CATLOGO
Conforme explicamos no Captulo 2, todo SGBD deve fornecer
uma funo de catlogo ou dicionrio. O catlogo o lugar em
que dentre outras coisas todos os vrios esquemas
(externo, conceitual, interno) e todos os mapeamentos
correspondentes (externo/conceitual, conceitual/interno) so
mantidos. Em outras palavras, o catlogo contm informaes
detalhadas (algumas vezes chamadas informaes do descritor
ou metadados) referentes aos diversos objetos que so de
interesse do prprio sistema. So exemplos desses objetos
variveis de relaes, ndices, usurios, restries de
integridade, restries de segurana, e assim por diante. As
informaes do descritor so essenciais para que o sistema
faa seu trabalho de forma apropriada. Por exemplo, o
otimizador utiliza informaes do catlogo sobre ndices e
outras estruturas fsicas de armazenamento, alm de muitas
outras informaes, para ajud-lo a decidir como implementar
requisies do usurio. Da mesma forma, o subsistema de
segurana utiliza informaes do catlogo sobre usurios e
restries de segurana (ver Captulo 16) para conceder ou
negar tais requisies.
Uma das caractersticas interessantes dos sistemas
relacionais o fato de que, em um sistema desse tipo, o
prprio catlogo consiste em variveis de relaes (mais
precisamente, variveis de relaes do sistema, assim
chamadas para distingui-las de variveis de relaes comuns
do usurio). Como resultado, os usurios podem interrogar o
catlogo exatamente da mesma forma que interrogam seus
prprios dados. Por exemplo, em geral o catlogo incluir
duas variveis de relaes do sistema, chamadas TABELA e
COLUNA, cuja finalidade descrever as tabelas (isto ,
variveis de relaes) no banco de dados e as colunas nessas
tabelas. (Dizemos em geral porque o catlogo no o mesmo
em todos os sistemas; as diferenas surgem porque o catlogo
para um determinado sistema contm necessariamente uma grande
quantidade de informaes especficas para esse sistema.) No
caso do banco de dados de departamentos e empregados da
Figura 3.1, as variveis de relaes TABELA e COLUNA devem
ter uma aparncia semelhante em estrutura da Figura
3.6.**
Nota: conforme mencionamos no Captulo 2, o catlogo deve
normalmente ser autodescrito ou seja, ele deve incluir
entradas (itens) descrevendo as prprias variveis de
relaes do catlogo. Contudo, nenhuma dessas entradas
mostrada na Figura 3.6. Veja o Exerccio 3.3 no final do
captulo.
Suponha agora que algum usurio do banco de dados de
departamentos e empregados queira saber exatamente quais
colunas a varivel de relao DEPTO contm (obviamente,
estamos considerando que, por alguma razo, o usurio ainda
no tem essa informao). Ento, a expresso
(COLUNA WHERE NOMETAB = DEPTO ) { NOMECOL}
fornece exatamente o que se deseja. Nota: se quisssemos
guardar o resultado dessa consulta de alguma forma mais
permanente, poderamos ter atribudo o valor da expresso a
alguma outra varivel de relao, como no exemplo da seo
anterior. Porm, omitiremos esse passo final de atribuio na
maioria dos nossos exemplos restantes (tanto neste quanto em
captulos posteriores).

* comum usar o termo clusterizado em vez de agrupado.


(N.R.T.)
**Observe que a presena de uma coluna CONTALINHAS na figura
sugere que operaes INSERT e DELETE sobre o banco de
dados causaro uma atualizao do catlogo como efeito
colateral. Na prtica, CONTALINHAS deveria ser atualizada
apenas a pedido (por exemplo, quando algum utilitrio fosse
executado), significando que os valores nem sempre estariam
atualizados.

59

NOMETAB CONTACOLS CONTALINHAS 1

DEPTO DEPTO#NOM
DEPTO EDEPTO
DEPTO ORAMENTO
EMP EMP#
EMP NOMEEMP
EMP DEPTO#
EMP SALRIO
FIGURA 3.6 Catlogo para o banco de dados de departamentos e
empregados
(esboo da estrutura)
Aqui est outro exemplo: Quais variveis de relaes incluem
uma coluna chamada EMP#?
COLUNA WHERE NOMECOL = EMP# ) { NOMETAB}
Exerccio: qual a finalidade do trecho a seguir?
TABELA JOIN COLUNA
WHERE CONTACOLS < 5 ) { NOMETAB, NOMECOL }
3.7 VARIVEIS DE RELAES BSICAS E VISES
Vimos que, partindo-se de um conjunto de variveis de
relaes como DEPTO e EMP, juntamente com um conjunto de
valores de relaes referentes a essas variveis de relaes,
as expresses relacionais nos permitem obter valores de
relaes adicionais a partir dos que foram dados por
exemplo, unindo-se duas das variveis de relaes dadas.
hora de apresentarmos um pouco mais de terminologia. As
variveis de relaes originais (dadas) so chamadas
variveis de relaes bsicas, e seus valores de relaes so
chamados relaes bsicas; uma relao que ou pode ser
obtida a partir dessas relaes bsicas por meio de alguma
expresso relacional chamada relao derivada ou derivvel.
Nota: variveis de relaes bsicas so chamadas variveis de
relaes reais na referncia [3.3].
Obviamente, os sistemas relacionais tm de fornecer um meio
para se criar em primeiro lugar as variveis de relaes
bsicas. Por exemplo, em SQL, essa tarefa executada pela
instruo CREATE TABLE (onde TABLE significa, de modo muito
especfico, uma varivel de relao bsica). Alm disso,
evidente que as variveis de relaes bsicas tm de receber
um nome (elas devem ser nomeadas) por exemplo:
CREATE TABLE EMP
Porm, em geral os sistemas relacionais tambm admitem outra
espcie de varivel de relao nomeada, chamada viso, cujo
valor em um instante determinado uma relao derivada (e,
portanto, uma viso pode ser imaginada informalmente como uma
varivel de relao derivada). O valor de uma dada viso em
um dado instante o que resulta da avaliao de uma certa
expresso relacional nesse instante; a expresso
60

relacional em questo especificada no instante em que a


viso criada. Por exemplo, a instruo

TABELA
COLUNA

DEPTO 3 3
EMP 4 4

NOMETAB CONTACOLS

CREATE VIEW EMPSUP AS


EMP WHERE SALRIO > 33K ) { EMP#, NOMEEMP, SALARIO}
poderia ser usada para definir uma viso chamada EMPSUP.
Nota: por razes que no tm importncia neste momento, o
exemplo foi expresso em uma mistura de SQL e Tutorial D.
Quando essa instruo executada, a expresso relacional que
segue AS a expresso de definio da viso no
avaliada, mas simplesmente memorizada de algum modo pelo
sistema (na realidade, pela gravao da expresso no
catlogo, sob o nome EMPSUP especificado). Porm, para o
usurio, agora como se de fato existisse uma varivel de
relao no banco de dados chamada EMPSUP, com um valor atual
indicado nas partes no sombreadas (somente) da Figura 3.7 a
seguir. O usurio tambm deve ser capaz de operar sobre essa
viso, exatamente como se ela fosse uma varivel de relao
bsica. Nota:
se (como sugerimos antes) DEPTO e EMP so consideradas
variveis de relaes reais, ento EMPSUP poderia ser
considerada uma varivel de relao virtual isto , uma
varivel de relao que aparentemente existe por si prpria,
mas que no existe de fato (seu valor em qualquer instante
dado depende do(s) valor(es) de certa(s) outra(s)
varivel(is) de relao(es)).

FIGURA 3.7 EMPSUP como uma viso de EMP (pores no


sombreadas)

Contudo, observe cuidadosamente que, embora digamos que o


valor de EMPSUP a relao que resultaria se a expresso de
definio da viso fosse avaliada, no pretendemos sugerir
que temos agora uma cpia separada dos dados; isto , no
queremos sugerir que a expresso de definio da viso
efetivamente avaliada. Pelo contrrio, a viso na realidade
apenas uma janela na varivel de relao bsica subjacente
EMP. Em conseqncia disso, quaisquer alteraes feitas nessa
varivel de relao subjacente estaro automtica e
instantaneamente visveis atravs dessa janela (supondo-se,
naturalmente, que elas residam dentro da poro no
sombreada). Da mesma forma, mudanas em EMPSUP sero
aplicadas de forma automtica e instantnea varivel de
relao EMP e, portanto, estaro visveis atravs da janela
(veja um exemplo mais adiante).
Aqui est um exemplo de operao de recuperao sobre a viso
EMPSUP:
EMPSUP WHERE SALRIO < 42K ) { EMP#, SALRIO}
Considerando-se a amostra de dados da Figura 3.7, o resultado
ser semelhante a este:

Conceitualmente, operaes sobre uma viso como a operao de


busca que acabamos de mostrar so manipuladas pela
substituio de referncias ao nome da viso pela expresso
de definio da viso (ou seja, a expresso que foi gravada
no catlogo). Assim, no exemplo, a expresso original
EMPSUP WHERE SALRIO < 42K ) { EMP#, SALRIO }
modificada pelo sistema, tornando-se

DEPTO# SALRIO
EMPSUP EMP# NOMEEMP
40K

E1 Lopez

E2 Cheng D1 42K
E3 inzi 02 30K
E4 Salto 02 I 35K

EMP# SALRIO

E1 40K

E4 35K

( EMP WHERE SALRIO > 33K ) { EMP#, NOMEEMP, SALRIO } )


WHERE SALRIO < 42K ) { EMP#, SALRIO}
(colocamos o nome da viso em itlico na expresso original e
o texto substituto na verso modificada). A expresso
modificada pode ento ser simplificada para
EMP WHERE SALRIO > 33K AND SALRIO < 42K ) { EMP#, SALRIO }
(ver Captulo 17) que, quando avaliada, forma o resultado
mostrado anteriormente. Em outras palavras, a operao
original sobre a viso efetivamente convertida em uma
operao equivalente sobre a varivel de relao bsica
subjacente, e essa operao equivalente ento executada da
maneira normal (ou, de forma mais precisa, otimizada e
executada da maneira normal).
Para vermos outro exemplo, considere a seguinte operao
DELETE:
DELETE EMPSUP WHERE SALRIO < 42K
A operao DELETE que realmente executada semelhante a
esta:
DELETE EMP WHERE SALRIO > 33K AND SALRIO < 42K
A viso EMPSUP muito simples, consistindo apenas em um
subconjunto de linhas e colunas de uma nica varivel de
relao bsica subjacente (em termos informais). Porm, em
princpio, uma definio de viso, por ser essencialmente
apenas uma expresso relacional com nome, pode ter uma
complexidade arbitrria (e pode at mesmo fazer referncia a
outras vises). Por exemplo, aqui est uma viso cuja
definio inclui uma juno de duas variveis de relaes
bsicas subjacentes:
CREATE VIEW EXEMPJOIN AS
EMP JOIN DEPTO ) WHERE ORAMENTO > 7M ) { EMP#, DEPTO# }
Voltaremos a tratar de toda a questo de definio de vises
e processamento de vises no Captulo 9.
A propsito, podemos agora explicar o comentrio do Captulo
2, prximo ao fim da Seo 2.2, no qual afirmamos que o termo
viso tem um significado bastante especfico em contextos
relacionais que no idntico ao significado atribudo a ele
na arquitetura ANSI/SPARC. No nvel externo dessa
arquitetura, o banco de dados percebido como uma viso
externa, definida por um esquema externo (e diferentes
usurios podem ter diferentes vises externas). Ao contrrio,
em sistemas relacionais, uma viso (como explicamos antes) ,
especificamente, uma varivel de relao com nome, derivada e
virtual. Portanto, o anlogo relacional de uma viso
externa ANSI/SPARC (em geral) uma coleo de diversas
variveis de relaes, cada uma das quais uma viso no
sentido relacional, e o esquema externo consiste em
definies dessas vises. (Segue-se que as vises no sentido
relacional so o modo pelo qual o modelo relacional
proporciona independncia de dados lgica, embora uma vez
mais deva ser dito que os produtos comerciais de hoje so
seriamente deficientes nesse aspecto. Consulte o Captulo 9.)

A arquitetura ANSI/SPARC bastante genrica e permite uma


variabilidade arbitrria entre os nveis externo e
conceitual. Em princpio, mesmo os tipos de estruturas de
dados admitidos nos dois nveis poderiam ser diferentes por
exemplo, o nvel conceitual poderia ser relacional, enquanto
um determinado usurio poderia ter uma viso externa que
fosse hierrquica. Porm, na prtica, a maioria dos sistemas
utiliza o mesmo tipo de estrutura como base para ambos os
nveis, e os produtos relacionais no so excees a essa
regra vises ainda so variveis de relaes, exatamente
como as variveis de relaes bsicas. Alm disso, como o
mesmo tipo de objeto admitido em ambos os nveis, a mesma
sublinguagem de dados (em geral a SQL) se aplica aos dois
nveis. Na realidade, o fato de uma viso ser uma varivel de
relao precisamente um dos pontos fortes dos sistemas
relacionais; ele importante do mesmo modo que tambm
importante em matemtica o fato de um subconjunto ser um
conjunto. Nota: porm, os
62

produtos de SQL e o padro SQL (ver Captulo 4) muitas vezes


parecem ignorar esse ponto, pois se referem repetidamente a
tabelas e vises (com a implicao de que uma viso no
uma tabela). O leitor aconselhado a no cair nessa
armadilha comum de considerar tabelas (ou variveis de
relaes) com o significado especfico de tabelas bsicas
(ou variveis de relaes) apenas.
H um ltimo ponto que deve ser mencionado sobre o assunto de
variveis de relaes bsicas versus vises, e vamos mostr-
lo agora. A distino entre varivel de relao bsica e
viso caracterizada com freqncia desta forma:
Variveis de relaes bsicas existem realmente, no
sentido de que representam dados que esto de fato
armazenados no banco de dados.
Em contraste, as vises no existem realmente, mas apenas
oferecem diferentes modos de visualizao dos dados reais.
No entanto, embora talvez til em um sentido informal, essa
caracterizao no reflete com preciso a situao real.
verdade que os usurios podem pensar em variveis de relaes
bsicas como se elas estivessem fisicamente armazenadas; de
certo modo, na verdade, a finalidade dos sistemas relacionais
permitir aos usurios imaginarem variveis de relaes
bsicas como fisicamente existentes, embora eles no tenham
de se preocupar com o modo como essas variveis de relaes
esto realmente representadas no meio de armazenamento. Porm
e esse um grande porm! esse modo de pensar no deve
ser interpretado com o significado de que uma varivel de
relao bsica est fisicamente armazenada em qualquer modo
direto (por exemplo, como um nico arquivo armazenado).*
Conforme explicamos na Seo 3.2, as variveis de relaes
bsicas devem ser imaginadas como uma abstrao de alguma
coleo de dados armazenados uma abstrao na qual todos os
detalhes no nvel de armazenamento so ocultados. Em
princpio, pode existir um grau arbitrrio de diferenciao
entre uma varivel de relao bsica e sua contrapartida
armazenada.
Um exemplo simples poderia ajudar a esclarecer esse ponto.
Considere uma vez mais o banco de dados de departamentos e
empregados. A maior parte dos sistemas relacionais de hoje
provavelmente implementaria esse banco de dados com dois
arquivos armazenados, um para cada uma das duas variveis de
relaes bsicas. Contudo, no h absolutamente nenhuma razo
lgica pela qual no deva existir apenas um arquivo
armazenado de registros armazenados hierrquicos, cada qual
consistindo em (a) nmero de departamento, nome e oramento
para algum departamento determinado, juntamente com (b)
nmero de empregado, nome e salrio para cada empregado que
esteja nesse departamento. Em outras palavras, os dados podem
estar fisicamente armazenados de qualquer modo que parea
apropriado, mas sempre tero a mesma aparncia no nvel
lgico.
3.8 TRANSAES
Nota: o tpico desta seo no peculiar a sistemas
relacionais. Apesar disso, ns o abordamos aqui, porque
necessria uma compreenso da idia bsica para se apreciar
certos aspectos do material que vir na Parte II. Contudo,
nossa cobertura neste ponto deliberadamente no ser muito
profunda.
No Captulo 1, dissemos que uma transao uma unidade
lgica de trabalho, em geral envolvendo diversas operaes de
bancos de dados. Tambm indicamos que o usurio precisa ser
capaz de informar ao sistema quando operaes distintas fazem
parte da mesma transao. As operaes BEGIN TRANSACTION,
COMMIT e ROLLBACK so fornecidas com essa finalidade.
Basicamente, uma transao comea quando uma operao BEGIN
TRANSACTION executada, e termina
quando uma operao COMMIT ou ROLLBACK correspondente
executada. Por exemplo (em pseudocdigo):

*A citao a seguir, extrada de um livro recente, exibe


vrias confuses das que estamos discutindo aqui, alm de
outras examinadas na Seo 3.3 anterior: [] importante
fazer uma distino entre relaes armazenadas, que so
tabelas, e relaes virtuais, que so vises... Usaremos o
termo relao somente onde puder ser usada uma tabela ou uma
viso. Quando quisermos enfatizar que uma relao
armazenada, em vez de uma viso, s vezes empregaremos o
termo relao bsica ou tabela bsica. A citao,
lamentavelmente, no de modo algum atpica.

63

BEGIN TRANSACTION ; /* move $$$ da conta A para a conta B */


UPDATE conta A ; /* retirada */
UPDATE conta B ; /* depsito */
IF tudo funcionou bem
THEN COMMIT ; /* fim normal */
ELSE ROLLBACK ; /* fim anormal */
END IF ;
So pontos importantes:
1. As transaes tm a garantia de serem atmicas isto ,
elas tm a garantia (de um ponto de vista lgico) de serem
executadas em sua totalidade ou de no serem executadas ao
todo, mesmo que (digamos) o sistema falhe no decorrer do
processo.
2. As transaes tambm tm a garantia de serem durveis (ou
persistentes) no sentido de que, uma vez que uma transao
execute uma operao COMMIT com sucesso, suas atualizaes
tero a garantia de serem aplicadas ao banco de dados, mesmo
que ocorra alguma falha subseqente do sistema em algum
instante. Nota: fundamentalmente, essa propriedade de
durabilidade das transaes que torna persistentes os dados
no banco de dados, no sentido do Captulo 1.
3. As transaes tambm tm a garantia de estarem isoladas
uma das outras, no sentido de que atualizaes feitas no
banco de dados por uma dada transao T1 no se tornaro
visveis para qualquer transao T2 distinta, at e a menos
que T1 execute com sucesso uma operao COMMIT. A operao
COMMIT faz as atualizaes efetuadas pela transao se
tornarem visveis para outras transaes; dizemos que essas
atualizaes fizeram o commit* e tm a garantia de nunca
serem canceladas. Por outro lado, se a transao executar a
operao ROLLBACK, todas as atualizaes feitas pela
transao sero canceladas (ou desfeitas). Nesse ltimo caso,
o efeito ser como se a transao nunca tivesse sido
executada.
4. A execuo intercalada de um conjunto de transaes
concorrentes tem (em geral) a garantia de ser serializvel,
no sentido de que ela produz o mesmo resultado que a execuo
dessas mesmas transaes uma de cada vez em alguma ordem
consecutiva no especificada.
Consulte os Captulos 14 e 15, que contm uma discusso
ampliada de todos os pontos descritos e de muitos outros
assuntos.
3.9 O BANCO DE DADOS DE FORNECEDORES E PEAS
Nosso exemplo prtico em grande parte deste livro o
conhecido banco de dados de fornecedores e peas (mantido,
como vimos no Captulo 1, por uma empresa fictcia chamada
KnowWare mc.). O propsito desta seo explicar esse banco
de dados, a fim de servir como ponto de referncia para
captulos posteriores. A Figura 3.8 apresenta um conjunto de
amostras de valores de dados; os exemplos subseqentes de
fato utilizaro esses valores especficos, onde fizer alguma
diferena. A Figura 3.9 mostra a definio do banco de dados,
expressa uma vez mais em (uma ligeira variao de) Tutorial
D. Observe em particular as especificaes da chave primria
e da chave estrangeira. Observe tambm que (a) diversas
colunas tm tipos de dados do mesmo nome que a coluna em
questo; (b) a coluna STATUS e as duas colunas CIDADE so
definidas em termos de tipos embutidos (ou internos)
INTEGER (inteiros) e CHAR (strings de caracteres de
comprimento arbitrrio) em vez de tipos definidos pelo
usurio. Observe finalmente que h um ponto importante a ser
considerado em relao aos valores de colunas mostrados na
Figura 3.8, mas ainda no estamos em condies de fazer essa
considerao; voltaremos ao assunto no Captulo 5, Seo 5.2,
na subseo intitulada Representaes possveis.
64 *Tambm comum utilizar-se em linguagem falada o
anglicismo transaes commitadas. (N.R.T.)

FIGURA 3.8 O banco de dados de fornecedores e peas (amostras


de valores)
TYPEF#... ;
TYPE NOME
TYPEP#...;
TYPE COR . . .
TYPE PESO
TYPE QDE ...
VAR F BASE RELATION
{ F# F#,
FNOME NOME,
STATUS INTEGER,
CIDADE CHAR
PRIMARY KEY { F# }
VAR P BASE RELATION
{ P# P#,
PNOME NOME,
COR COR,
PESO PESO,
CIDADE CHAR
PRIMARY KEY { P# }
VAR FP BASE RELATION
{ F#
P#
QDE QDE }
PRIMARY KEY { F#, P# }
FOREIGN KEY { F# } REFERENCES F
FOREIGN KEY { P# ) REFERENCES P ;

F
FNOME STATUS CIDADE FP

FIGURA 3.9 O banco de dados de fornecedores e peas


(definio de dados)

65

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


F# P# QDE

F1 P1 300

F1 P2 200

F1 P3 400

F1 P4 200

F1 P5 100

F1 P6 100

F2 P1 300

F2 P2 400

F3 P2 200

F4 P2 200

F4 P4 300

F4 P5 400

O banco de dados foi elaborado para ser entendido da seguinte


maneira:
A varivel de relao F representa fornecedores. Cada
fornecedor tem um nmero de fornecedor (F#), exclusivo para
esse fornecedor, um nome de fornecedor (FNOME), no
necessariamente exclusivo (embora os valores de FNOME sejam
exclusivos na Figura 3.8), um valor de classificao ou
status (STATUS) e um local (CIDADE). Partimos do princpio de
que cada fornecedor est localizado em exatamente uma cidade.

A varivel de relao P representa peas (mais


precisamente, tipos de peas). Cada tipo de pea tem um
nmero de pea (P#) exclusivo, um nome de pea (PNOME), uma
cor (COR), um peso (PESO) e um local em que peas desse tipo
so armazenadas (CIDADE). Supomos onde faz alguma diferena
que os pesos de peas so dados em quilogramas. Tambm
supomos que cada tipo de pea tem exatamente uma cor e
armazenado em um depsito de exatamente uma cidade.
A varivel de relao FP representa remessas. Em certo
sentido, ela serve para unir as outras duas variveis de
relaes, falando-se em termos lgicos. Por exemplo, a
primeira linha de FP mostrada na Figura 3.8 vincula um
fornecedor especfico de F (ou seja, o fornecedor F1) a uma
pea especfica de P (ou seja, a pea P1) em outras
palavras, ela representa uma remessa de peas do tipo P1 pelo
fornecedor chamado F1 (e a quantidade da remessa 300).
Assim, cada remessa tem um nmero de fornecedor (F#), um
nmero de pea (P#) e uma quantidade (QDE). Presumimos que
possa haver no mximo uma remessa em qualquer instante dado
correspondente a um determinado fornecedor e uma dada pea;
para uma remessa determinada, portanto, a combinao do valor
de F# e do valor P# exclusiva com
relao ao conjunto de remessas que aparecem no momento em
FP. Nota: deliberadamente, as amostras de valores da Figura
3.8 incluem um fornecedor, o fornecedor F5, que no tem
nenhuma remessa correspondente a ele.
Observamos que (como j foi comentado no Captulo 1, Seo
1.3) fornecedores e peas podem ser considerados entidades, e
que uma remessa pode ser considerada um relacionamento entre
um determinado fornecedor e uma pea especfica. Porm,
tambm mencionamos naquela seo que melhor considerar um
relacionamento apenas como um caso especial de entidade. Uma
vantagem dos bancos de dados relacionais exatamente o fato
de que todas as entidades, ainda que elas sejam de fato
relacionamentos, so representadas do mesmo modo uniforme
especificamente, por meio de linhas em relaes, conforme
indica o exemplo.
Aqui esto dois comentrios finais:
Primeiro, o banco de dados de fornecedores e peas
naturalmente muito simples, bem mais simples que qualquer
banco de dados real tem probabilidade de ser; a maioria dos
bancos de dados reais incluir um nmero muito maior de
entidades e relacionamentos (e uma quantidade muito maior de
tipos de entidades e relacionamentos) que esse. No entanto,
ele no mnimo adequado para ilustrar a maioria dos pontos
que precisaremos considerar no restante do livro e (conforme
j foi mencionado) ns o empregaremos como base para a
maioria dos nossos exemplos seno para todos nos prximos
captulos.
Em segundo lugar, no h nada de errado ( claro) no uso de
nomes mais descritivos, como FORNECEDORES, PEAS e REMESSAS
em lugar dos nomes bastante abreviados F, P e FP que
empregamos; de fato, na prtica em geral recomendvel o uso
de nomes descritivos. Contudo, no caso especfico de
fornecedores e peas, as variveis de relaes so
referenciadas com tanta freqncia nos captulos seguintes
que nos pareceu desejvel usar nomes curtos. Nomes longos
tendem a se tornar irritantes com a repetio demasiada.
66

3.10 RESUMO
Chegamos ao fim da nossa breve viso geral da tecnologia
relacional. evidente que apenas arranhamos a superfcie do
que se tornou agora um tema bastante extenso, mas o propsito
do captulo foi o de servir como uma introduo agradvel s
discusses muito mais amplas que viro. Ainda assim,
conseguimos avanar bastante. Aqui est um resumo dos
principais tpicos que discutimos.
Um banco de dados relacional um banco de dados percebido
por seus usurios como uma coleo de variveis de relaes
ou, de modo mais informal, tabelas. Um sistema relacional
um sistema que admite bancos de dados relacionais e operaes
sobre esses bancos de dados, incluindo em particular as
operaes de restrio, projeo e juno. Essas operaes, e
outras semelhantes a elas, so todas operaes em nvel de
conjunto. A propriedade de fechamento dos sistemas
relacionais significa que a sada de toda operao do mesmo
tipo de objeto que a entrada (so todas relaes); isso
significa que podemos escrever expresses relacionais
aninhadas. As variveis de relaes podem ser atualizadas por
meio da operao de atribuio relacional; as conhecidas
operaes de atualizao INSERT, UPDATE e DELETE podem ser
consideradas atalhos para certas atribuies relacionais
comuns.
A teoria formal subjacente aos sistemas relacionais chamada
modelo relacional de dados. O modelo relacional trata apenas
de questes lgicas, no de questes fsicas. Ele est
relacionado com trs aspectos principais dos dados a
estrutura de dados, a integridade de dados e a manipulao de
dados. O aspecto estrutural trata das relaes propriamente
ditas; o aspecto de integridade est relacionado com (entre
outras coisas) chaves primrias e chaves estrangeiras; e o
aspecto manipulativo se relaciona com os operadores (de
restrio, projeo, juno etc.). O princpio da informao
estabelece que todo o contedo de informao de um banco de
dados relacional representado de um e somente um modo,
especificamente sob a forma de valores explcitos em posies
de colunas em linhas de relaes.
Toda relao tem um cabealho e um corpo; o cabealho um
conjunto de pares nome de coluna:nome de tipo, e o corpo um
conjunto de linhas em conformidade com o cabealho. O
cabealho de uma dada relao pode ser considerado um
predicado, e cada linha no corpo denota uma certa proposio
verdadeira, obtida pela substituio dos placeholders ou
parmetros do predicado por certos valores de argumentos do
tipo apropriado. Em outras palavras, os tipos so (conjuntos
de) coisas sobre as quais podemos falar, e as relaes so
(conjuntos de) coisas que dizemos a respeito das coisas sobre
as quais podemos falar. Juntos, os tipos e as relaes so
necessrios e suficientes para representar quaisquer dados
que desejarmos (isto , no nvel lgico).
O otimizador o componente do sistema que determina como
implementar solicitaes do usurio (que se relacionam com o
que, e no com como). Portanto, tendo em vista que os
sistemas relacionais pressupem a responsabilidade pela
navegao no banco de dados armazenado para localizar os
dados desejados, eles so descritos s vezes como sistemas de
navegao automtica. A otimizao e a navegao automtica
so pr-requisitos para a independncia de dados fsica.
O catlogo um conjunto de variveis de relaes do sistema
que contm descritores para os diversos itens que so de
interesse do sistema (variveis de relaes bsicas, vises,
ndices, usurios etc.). Os usurios podem consultar o
catlogo exatamente do mesmo modo que consultam seus prprios
dados.
As variveis de relaes originais em um determinado banco de
dados so chamadas variveis de relaes bsicas, e seus
valores so chamados relaes bsicas; uma relao obtida a
partir dessas relaes bsicas por meio de alguma expresso
relacional chamada uma relao derivada (coletivamente, as
relaes bsicas e derivadas so s vezes referenciadas como
relaes expressveis). Uma viso uma varivel de relao
cujo valor em qualquer instante determinado uma relao
derivada (informalmente, ela pode ser imaginada como uma
varivel de relao derivada); o valor de uma tal varivel de
relao em qualquer instante determinado o resultado da
avaliao da expresso de definio da viso associada. Por
essa razo, observamos que as variveis de relaes bsicas
tm existncia independente, mas no as vises elas
dependem das variveis de relaes bsicas aplicveis. (Outro
modo de dizer a mesma coisa afirmar que as variveis de
relaes bsicas so autnomas, mas as vises no so
autnomas.) Os usurios podem operar sobre as vises
exatamente do mesmo modo que operam sobre variveis de
relaes bsicas (pelo menos em teoria). O sistema implementa
operaes sobre vises substituindo referncias 67

ao nome da viso pela expresso de definio da viso,


convertendo assim a operao em uma operao equivalente
sobre a(s) varivel(is) de relao(es) bsica(s)
subjacente(s).
Uma transao uma unidade lgica de trabalho, normalmente
envolvendo diversas operaes sobre bancos de dados. Uma
transao comea quando a instruo BEGIN TRANSACTION
executada e termina quando se executa a instruo COMMIT
(trmino normal) ou ROLLBACK (trmino anormal). As transaes
so atmicas, durveis e isoladas umas das outras. A execuo
intercalada de uma srie de transaes concorrentes tem (em
geral) a garantia de ser serializvel.
Por fim, o exemplo bsico usado na maior parte do livro o
banco de dados de fornecedores e peas. Vale a pena dedicar
algum tempo para se familiarizar com esse exemplo agora, se
voc ainda no o fez; ou seja, voc deve pelo menos saber
quais variveis de relaes tm quais colunas, e ainda qual
a chave primria e quais so as chaves estrangeiras (no
to importante saber exatamente quais so os valores da
amostra de dados!).
EXERCCIOS
3.1 Defina os seguintes termos:
banco de dados relacional operao em nvel de conjuntos
catlogo otimizao
chave estrangeira predicado
chave primria projeo
desfazer (rollback) proposio
fazer o commit restrio
fechamento SGBD relacional
juno varivel de relao bsica
modelo relacional varivel de relao derivada
navegao automtica viso
3.2 Esboce o contedo das variveis de relaes TABELA e
COLUNA do catlogo do banco de dados de fornecedores e peas.

3.3 Como explicamos na Seo 3.6. o catlogo autodescrito


isto , ele inclui entradas para as prprias variveis de
relaes do catlogo. Amplie a Figura 3.6 para incluir as
entradas necessrias s prprias variveis de relaes TABELA
e COLUNA.
3.4 Aqui est uma consulta sobre o banco de dados de
fornecedores e peas. Qual sua finalidade?
RESULTADO := ( ( F JOIN FP ) WHERE P# = P2 ) { F#, CIDADE
Nota: na realidade, h um ligeiro problema com essa consulta,
relacionado com o tipo de dados da coluna P#. Voltaremos a
esse assunto no Captulo 5, Seo 5.2 (na subseo intitulada
Converses de tipos). Comentrios anlogos tambm se
aplicam ao prximo exerccio.
3.5 Suponha que a expresso no lado direito da atribuio do
Exerccio 3.4 seja usada na definio de uma viso:
CREATE VIEW V AS
F JOIN FP ) WHERE P# = P2 ) { F# CIDADE
Agora, considere a consulta
RESULTADO := ( V WHERE CIDADE = Londres ) { F#
Qual o objetivo dessa consulta? Mostre o que est envolvido
na parte do SGBD ao se processar essa consulta.
3.6 O que voc entende pelos termos atomicidade,
durabilidade, isolao e serializao (de uma transao)?
REFERNCIAS E BIBLIOGRAFIA
3.1 E. F. Codd: Relational Database: A Practical Foundation
for Productivity. CACM 25, Nmero 2 (fevereiro de 1982).
Reeditado em Robert L. Ashenhurst (editor), ACM TuringAward
Lectures: The First Twenty Years 1966-1985. Reading, Mass.:
Addison-Wesley (ACM Press Anthology Series, 1987).

Esse o artigo que Codd apresentou na ocasio do recebimento


do ACM Turing Award de 1981 por seu trabalho sobre o modelo
relacional. Ele discute o conhecido problema de application
backlog. Para citar o autor: A demanda por aplicaes de
computador cresce com rapidez com tanta rapidez que os
departamentos de sistemas de informaes (cuja
responsabilidade fornecer essas aplicaes) esto ficando
cada vez mais atrasados em sua capacidade de atender
demanda. Existem duas maneiras complementares de atacar esse
problema:
1. Fornecer novas ferramentas aos profissionais de tecnologia
de informao, a fim de aumentar sua produtividade.
2. Permitir a interao direta entre os usurios finais e o
banco de dados, ignorando assim por completo o profissional
de tecnologia de informao.
Ambas as abordagens so necessrias e, nesse documento, Codd
oferece evidncias para sugerir que a base necessria para as
duas proporcionada pela tecnologia relacional.
3.2 C. J. Date: Why Relational?, em Relational Database
Writings 1985-1989. Reading, Mass.: Addison-Wesley (1990).
Uma tentativa de fornecer um resumo sucinto, ainda que
razoavelmente completo, das principais vantagens dos sistemas
relacionais. A observao a seguir, extrada do documento,
merece ser repetida aqui:
entre todas as numerosas vantagens da abordagem relacional,
h uma em particular que deve ser enfatizada, e essa a
existncia de uma base terica slida. Para citar o autor:
... [o sistemal relacional realmente diferente.
diferente porque no ad hoc. Em contraste, sistemas mais
antigos eram ad hoc; eles podem ter fornecido solues para
certos problemas importantes de sua poca, mas no tinham
nenhuma base terica slida. Ao contrrio, os sistemas
relacionais se apoiam nessa base terica.., o que significa
que [eles) so slidos como rochas.
Graas a essa slida fundamentao, os sistemas relacionais
se comportam de modo bem definido e (possivelmente sem
perceber o fato) os usurios tm um modelo simples desse
comportamento em suas mentes, um modelo que lhes permite
prever com confiana o que o sistema far em qualquer
situao determinada. No h (nem deve haver) surpresas. Essa
previsibilidade significa que as interfaces do usurio so
fceis de entender, documentar, ensinar, aprender, usar e
lembrar.
3.3 C. J. Date e Hugh Darwen: Foundation for
Object/Relational Databases: The Third Manifesto. Reading,
Mass.: Addison-Wesley (1998). Ver tambm o documento genrico
introdutrio The Third Manifesto:
Foundation for Object/Relational Databases, em C. J. Date,
Hugh Darwen e David McGoveran, Relational
Database Writings 19941997. Reading, Mass.: Addison-Wesley
(1998).
The Third Manifesto uma proposta detalhada, formal e
rigorosa para a orientao futura dos bancos de dados e
SGBDs. Ele pode ser visto como uma planta baixa abstrata para
o projeto de um SGBD e a inter- face de linguagem para esse
SGBD. Ele se baseia nos conceitos centrais clssicos de tipo,
valor, varivel e operador. Por exemplo, poderamos ter um
tipo INTEGER; o inteiro 3 poderia ser um valor desse tipo;
N poderia ser uma varivel desse tipo, cujo valor em qualquer
instante determinado seria algum valor inteiro (isto , algum
valor desse tipo) e + poderia ser um operador que se
aplicasse a valores inteiros (isto , a valores desse tipo).
RESPOSTAS A EXERCCIOS SELECIONADOS
3.3 A Figura 3.10 a seguir mostra as entradas correspondentes
s variveis de relaes TABELA e COLUNA (somente as
entradas para as variveis de relaes do prprio usurio
foram omitidas). Evidentemente, no possvel dar valores
precisos de CONTACOLS e CONTALINHAS.
3.4 A consulta busca o nmero do fornecedor e a cidade para
fornecedores da pea P2.
3.5 O significado da consulta : Obter nmeros do
fornecedores correspondentes a fornecedores de Londres que
fornecem a pea P2. O primeiro passo no processamento da
consulta substituir o nome V pela expresso que define V, o
que d:
F JOIN FP ) WHERE P# = P2 ) { F#, CIDADE 1
WHERE CIDADE = Londres ) { F#
69

Isso, em sua forma simplificada, equivale a:

F WHERE CIDADE = Londres ) JOIN


( FP WHERE P# = P2 ) ) { F# }

Para ver uma descrio e uma explicao adicional, consulte


os Captulos 9 e 17.

TABELA
TABELA
TABELA
COLUNA
COLUNA

CONTACOLS

NOMETAB
CONTACOLS
CONTALINHAS
NOMETAB
NOME CO L

TABELA

NOMETAB CONTACOLS CONTALINHAS

TABELA COLUNA

(>3)
(>2)

COLUNA

(>2)
(>5)

NOMETAB

FIGURA 3.10 Entradas de catlogo para as prprias tabelas


TABELA e COLUNA (esboo da estrutura)
70

Você também pode gostar