1- INTRODUO

Um sistema de banco de dados no nada mais do que um sistema de manuteno de registros

por computador. O prprio banco de dados pode ser considerado uma espcie de sala de ar-
quivo eletrnica - ou seja, um depsito de um conjunto de arquivos de dados computadorizados
que oferece diversos recursos ao usurio, possibilitando-Ihe a realizao de vrias operaes,
incluindo, entre outras, as seguintes:

- A adio de novos (vazios) arquivos ao banco de dados; A insero de novos dados nos ar-
quivos existentes;
- A recuperao de dados dos arquivos existentes; A atualizao de dados nos arquivos exis-
tentes; A eliminao de dados nos arquivos xistentes;
- A renovao permanente de arquivos existentes (vazios ou outros) do banco de dados.

Demonstramos um banco de dados bastante simples, que contm um nico arquivo, o arquivo
CELLAR que rene informaes referentes ao contedo de uma adega de vinhos.
O Arquivo CELLAR:
BIN WINE PRODUCER YEAR BOTTLES READY COMMENTS
2 Chardonnay Buena Vista 83 1 85
3 Chardonnay Louis Martini 81 5 84
6 Chardonnay Chappellet 82 4 85 Thanksgiving
11 Jo.. Riesling lekel 84 10 86
12 Jo. Riesling Buena Vista 82 1 83 Late Harvest
16 Jo. Riesling Sattui 82 1 83 very dry
21 Fume Blanc Ch. St. Jean 79 4 83 Napa Valley
22 Fume Blanc Robt. Mondavi 78 2 82
25 Wh. Burgundy Mirassou 80 6 82
30 Gewurztraminer Buena Vista 80 3 82
43 Cab. Sauvignon Robt. Mondavi 77 12 87
50 Pinot Noir Mirassou 77 3 85 Harvest
51 Pinot Noir Ch. St. Jean 78 2 86
64 Zinfandel Mirassou 77 9 86 Anniversary
72 Gamay Robt. Mondavi 78 2 83

Demonstramos abaixo um banco de dados bastante simples, que contm um nico arquivo, o
arquivo CELLAR que rene informaes referentes ao contedo de uma adega de vinhos.
SELECT WINE, BIN, PRODUCER FROM CELLAR
WHERE READY = 85 ;

Abaixo demonstrao de um exemplo de uma operao de recuperao neste banco de dados,

assim como os dados (mais corretamente, os resultados) devolvidos atravs daquela recu-
perao.

Resultado (impresso ou na tela):

WINE BIN PRODUCER

Chardonnay 2 Buena Vista
Chardonnay 6 Chappellet
Pinot Noir 50 Mirassou

Alguns outros exemplos de operaes no arquivo CELLAR que, na sua maioria, so

auto-explicativas. Os exemplos referentes adio ou remoo de arquivos do banco de dados.

Insero de novos dados:

INSERT INTO CELLAR
VALUES (53, 'Pinot Noir', 'Franciscan', 79, 1, 86, 'for Joan ) ;

Atualizao de dados existentes:

UPDATE CELLAR
SET BOTTLES = 4 WHERE BIN = 3 ;

Eliminao de dados existentes:

DELETE FROM CELLAR WHERE BIN = 2 ;

Primeiro, por motivos bvios, os arquivos computadorizados como o CELLAR do

exemplo so chamados mais de tabelas do que de arquivos.
Segundo, as linhas de tais tabelas podem ser consideradas registros do arquivo (s
vezes chamadas explicitamente de registros lgicos, para distingui-los de outros tipos de reg-
istro . As colunas, da mesma maneira, podem ser consideradas campos destes registros lgicos.
 Terceiro, as operaes SELECT, INSERT, UPDATE e DELETE demonstradas acima
so, de fato, exemplos de instrues de uma linguagem de banco de dados conhecida como
SQL ("Structured Query Language" - Linguagem de Consulta Estruturada). A SQL
(pronunciada normalmente como "sequel") a linguagem suportada pelos produtos de banco
de dados da IBM,DB2, SQL/DS e QMF, assim como por inmeros produtos de banco de dados
de outros fabricantes.

2 - O QUE UM SISTEMA DE BANCO DE DADOS?

O sistema de banco de dados basicamente um sistema de manuteno de registros por

computador,ou seja, um sistema cujo objetivo global manter as informaes e torn-las
disponveis quando solicitadas. Trata-se de qualquer informao considera-da como signifi-
cativa ao indivduo ou organizao servida pelo sistema - em outras palavras, que seja ne-
cessria ao processo de tomada de deciso daquele indivduo/organizao. A figura a seguir (1)
abaixo mostra uma viso bastante simplificada de um sistema de banco de dados.
Esta figura pretende demonstrar que um sistema de banco de da-dos envolve quatro compo-
nentes principais: dados, hardware, software e usurios.

Dados
Os sistemas de banco de dados agora esto disponveis em mquinas que abrangem
desde os pequenos micros at os maiores computadores de grande porte. Os recursos propor-
cionados por um determinado sistema so, at certo ponto, definidos pelo tamanho e pela
potncia da mquina bsica. Os sistemas de grandes mquinas ("grandes sistemas), em par-
ticular, tendem a ter usurios mltiplos e os das mquinas pequenas ("pequenos sistemas") a ter
usurio nico. Um sistema de usurio nico aquele no qual somente um nico usurio pode
operar num certo momento; o sistema de usurios mltiplos aquele em que diversos usurios
podem operar simultaneamente. Na realidade, a distino irrelevante: Um dos objetivos da
maioria dos sistemas de usurios mltiplos precisamente possibilitar a cada usurio indi-
vidual comportar-se como se estivesse trabalhando com um sistema de usurio nico. Os
problemas especiais dos sistemas de usurios mltiplos so essencialmente internos do sistema,
no visveis ao usurio.
FIGURA 1 Representao simplificada de um sistema de banco de dados

Uma outra observao preliminar: Normalmente, convm assumir, para simplificar,

que a totalidade dos dados armazenados no sistema mantida num nico banco de dados;
estaremos adotando esta suposio simplificada, pois no invalida substancialmente quaisquer
das discusses subseqentes. Na prtica, entretanto, pode haver boas razes, mesmo num sis-
tema pequeno, para que os dados sejam divididos em diversos bancos de dados distintos.
Abordaremos algumas destas razes mais frente.
Geralmente, pois, os dados no banco de dados - pelo menos num sistema grande - sero no s
integrados como compartilhados. Estes dois aspectos, integrao e compartilhamento, repre-
sentam a maior vantagem dos sistemas de banco de dados de ambientes "grandes", e pelo
menos a integrao tambm pode ser significa- tiva em ambientes "pequenos" . Certamente h
muitas outras vantagens (que sero discutidas mais tarde), mesmo nos ambientes ditos pe-
quenos, mas primeiro explicaremos o que significam os termos "integrado" e "compartilhado"
Por "integrado" queremos dizer que o banco de dados pode ser imaginado como a unifi-
cao de diversos arquivos de dados que,de outra forma, seriam distintos, eliminando-se total
ou parcialmente qualquer redundncia entre os mesmos. Por exemplo, um certo banco de dados
poderia conter tanto registros de FUNCIO NRIOS, com nome, endereo, departamento,
salrio etc., como registro de INSCRIO, representando a inscrio de funcionrios em
cursos de treinamento. Suponhamos que, para o processo de administrao de cursos, seja
necessrio conhecer o departamento de cada aluno inscrito. Claramente no seria preciso in-
cluir esta informao, redundante, nos registros de INSCRIO, uma vez que ela ser en-
contrada nos registros correspondentes aos FUNCIONRIOS.
 Por "compartilhado" quer dizer que parcelas isoladas de dados podem ser compartilhadas
por diversos usurios num banco de dados, no sentido de que todos os usurios podem ter
acesso mesma parcela de dados (e podem us-los com finalidades diferentes). Como j
mencionado, diferentes usurios podem, inclusive,ter acesso s mesmas partes de dados no
mesmo momento ("acesso concorrente"). Tal compartilhamento (concorrente ou outro) , em
parte, conseqncia do fato de que o banco de dados integrado. No exemplo
FUNCIONRIO/INSCRIO acima, a informao sobre departamento nos registros
FUNCIONRIO seria compartilhada por usurios do Departamento do Pessoal e usurios do
Departamento de Educao e, como sugerido anteriormente, os dois departamentos, estariam
utilizando as informaes para propsitos diferentes.
Outra conseqncia do mesmo fato (de que o banco de dados integrado) que qualquer
usurio, em geral, s estar interessado em um subconjunto do banco de dados total; ademais,
os subconjuntos de diferentes usurios iro sobrepor-se de muitas maneiras diferentes. Em
outras palavras, um determinado banco de dados ser percebido por usurios diferentes de
vrias formas distintas. De fato, mesmo quando dois usurios compartilham o mesmo sub-
conjunto do banco de dados, as vises do mesmo podem diferir consideravelmente a nvel dos
detalhes.

Hardware
O Hardware compe-se dos volumes de memria secundria discos de cabea mvel
nos quais reside o banco de dados, juntamente com os dispositivos associados de en-
trada/sada (unidades de disco, nos casos de discos de cabea mvel), dispositivos de controle,
canais de entrada/sada, e assim por diante. Este livro no se detm muito nos aspectos de
hardware do sistema, pelas seguintes razes: primeiramente, esses aspectos formam, por si
mesmos, um tpico maior; segundo, os problemas encontrados nesta rea no so peculiares
aos sistemas de bancos de dados; terceiro, estes problemas esto extensamente investigados e
documentados.

Software
Entre o banco de dados fsico (isto , os dados armazenados) e os usurios do sistema
encontra-se o software, o gerenciador do banco de dados (o gerenciador DB) ou, mais
comumente, sistema gerenciador de banco de dados (DBMS - [conforme iniciais em ingls -
N.T.]). Todas as solicitaes dos usurios de acesso ao banco de dados so manipuladas pelo
DBMS; os recursos esboados na Seo I.1 referentes criao de arquivos (ou tabelas), in-
sero de dados, recuperao de dados etc. so todos proporcionados pelo DBMS. Outra
funo do DBMS , pois, isolar os usurios do banco de dados dos detalhes a nvel de hardware
(como os sistemas de linguagens de programao protegem os programadores de aplicao dos
detalhes a nvel de hardware). Em outras palavras, o DBMS faz com que os usurios tenham
uma viso do banco de dados acima do nvel do hardware, e suporta as operaes do usurio
(como as operaes em SQL) que so expressas em termos daquela viso a nvel mais elevado.
Discutiremos esta e outras funes do DBMS posteriormente.

Usurios
Consideramos trs grandes classes de usurios. Primeiramente, trs grandes classes de usurios,
Primeiramente temos o programador de aplicaes, responsvel pela definio dos programas
de aplicao que utilizam o banco de dados, caracteristicamente em linguagem como COBOL
ou PL/I ou outra linguagem mais moderna; como APL ou Pascal. Estes programas operam com
os dados de todas as formas usuais: recuperao de informaes, criao de novas informaes,
anulao ou alterao de informaes existentes. Todas estas funes so executadas pela
emisso de solicitaes apropriadas ac DBMS. Os programas em si podem ser de aplicaes
convencionais en lotes ou (cada vez mais) aplicaes on-line, cuja funo suportar un usurio
final (vide abaixo) que se comunica com o banco de dados a partir de um terminal on-line. A
segunda classe de usurios, ento, o usurio-final, que inteta ge com o sistema a partir de um
terminal on-line. Um certo usurio final pode ter acesso ao banco de dados por meio de uma
das aplicaeson-line, definidas para o mesmo e mencionadas no pargrafo anterior, ou usar a
interface fornecida como parte integrante do sistema. Tais interfaces tambm so fornecidas
atravs de aplicaes on-line, mas essas aplicaes so embutidas e no definidas para o
usurio. A maioria dos sistemas fornece pelo menos uma aplicao embutida, a saber, um
processador de linguagem de consulta interativo, pelo qual o usurio capaz de emitir co-
mandos ou instrues de alto nvel (como SELECT, INSERT etc.) ao DBMS. A linguagem
SQL, j mencionada diversas vezes, considerada um exemplo tpico de linguagem de con-
sulta de banco de dados. Observa-
o: Muitos sistemas tambm proporcionam interfaces embutidas adicionais, nas quais os
usurios no precisam emitir expressamente os comandos, como SELECT; operam (por ex-
emplo) escolhendo itens do menu ou preenchendo-os em formulrios. Tais interfaces aciona-
das por menus ou formulrios so normalmente mais fceis para as pessoas sem treinamento
formal em processamento de dados. As interfaces acionadas por comando (i.e., linguagens de
consulta), ao contrrio, necessitam de uma certa experincia em processamento de dados,
embora no muito grande (obviamente no tanto quanto seria necessrio para definir um pro-
grama de aplicao em COBOL ou PL/I). Tambm neste caso, as interfaces acionadas por
comando so provavelmente mais flexveis do que as de menu ou formulrios, posto que as
linguagens de consulta proporcionam certas funes que no so suportadas por outras inter-
faces. A terceira classe de usurios o ad-
ministrador do banco de dados ou DBA.Assim, completamos nossa descrio preliminar dos
principais aspectos de um sistema de banco de dados. Passaremos agora a discuti-los de forma
mais detalhada.

3 DADOS OPERACIONAIS

Um dos primeiros textos didticos sobre o assunto, de Engles [1.10], refere-se aos dados de
banco de dados como "dados operacionais", distinguindo-os de dados de entrada, dados de
sada e de outros tipos de dados. Damos abaixo uma verso modificada da definio original de
Engles acerca de banco de dados:

Um banco de dados uma coleo de dados operacionais armazenados, usados pelos siste-
mas de aplicaes de uma empresa especfica.
Esta definio requer uma explicao. Primeiramente, "empresa" apenas um termo
genrico e conveniente para designar uma organizao comercial, cientfica, tcnica ou de
outra natureza que seja razoavelmente independente. Uma empresa pode ser um nico in-
divduo (com um pequeno banco de dados particular), ou uma organizao de grande porte ou
similar (com um grande banco de dados compartilhado), ou algo entre esses extremos. Ex-
emplos de empresas:

fbricas;
bancos;
hospitais;
universidades;
departamentos governamentais.

Qualquer empresa deve, necessariamente, manter uma certa quantidade de dados

acerca de suas operaes. So estes os "dados operacionais". Os dados operacionais das em-
presas acima provavelmente incluiriam o seguinte:
dados sobre os produtos;
dados contbeis;
dados sobre os pacientes;
 dados sobre os estudantes;
dados de planejamento.

Os "dados operacionais", como mencionado, no incluem os dados de entrada e sada,

seqncia de trabalhos a realizar, resultados temporrios ou, ainda, qualquer informao pu-
ramente transitria. Os "dados de entrada" representam informaes que entram no sistema
pela primeira vez (a partir do teclado do terminal, leitor de cartes ou dispositivo similar); tais
informaes podem provocar a necessidade de uma alterao nos dados operacionais (para que
possam tornar-se parte dos dados operacionais) mas, inicialmente, no fazem parte do banco de
dados em si. Da mesma forma, os "dados de sada" so mensagens e resultados que procedem
do sistema (impressas ou projetadas de outra maneira numa tela de terminal); novamente,
podem derivar dos dados operacionais, sem que sejam consideradas, em si, como parte do
banco de dados. Observaes anlogas aplicam-se a outras espcies de informaes tran-
sitrias.
A ttulo de ilustrao do conceito de dados operacionais, vamos considerar o caso de uma
fbrica. A empresa desejar guardar informaes sobre os seus projetos; as peas usadas nos
mesmos; os fornecedores dessas peas; os depsitos onde so estocadas; os funcionrios que
trabalham nos projetos; e assim por diante. So estas as entidades bsicas relativas s infor-
maes a registrar (o termo "entidade" amplamente usado nos meios de bancos de dados para
denominar qualquer objeto distinto a ser representado no banco de dados).Veja a Figura 2.

FIGURA 2 Exemplo de dados operacionais

importante notar que, alm das entidades bsicas em si, existiro relacionamentos interli-
gando-as. So demonstrados pelas setas de ligao. H, por exemplo, um relacionamento entre
os fornecedores e as peas: cada fornecedor fornece certas peas e, de modo inverso, cada pea
suprida por certos fornecedores (ou melhor, cada fornecedor fornece certos tipos de peas,
cada tipo de pea suprido por certos fornecedores). Do mesmo modo, as peas so usadas em
projetos, e inversamente, os projetos utilizam peas; as peas so armazenadas em depsitos e
os depsitos estocam as peas, e assim sucessivamente. Observa-se que estes relacionamentos
so bidirecionais - isto , podem ocorrer em ambas as direes. O relacionamento entre fun-
cionrio e departamentos, por exemplo, pode ser utilizado para responder s duas questes
seguintes:

l. Dado um funcionrio, encontre o departamento correspondente;

2. Dado um departamento, encontre os funcionrios correspondentes.
O ponto importante dos relacionamentos como ilustrados acima na figura 2 que so tanto uma
parte dos dados operacionais como entidades bsicas. Conseqentemente, devem estar repre-
sentadas no banco de dados. Consideremos mais frente as diversas maneiras de faz-lo.
A Figura 2 tambm ilustra outros itens.
1. Embora a maioria dos relacionamentos do diagrama envolva dois tipos de entidade - isto ,
sejam relacionamentos binrios -, isto no significa que todos os relacionamentos sejam ne-
cessariamente binrios neste sentido. Temos no exemplo um relacionamento que envolve trs
tipos de entidade (fornecedores, peas e projetos) - um relacionamento ternrio, interpretado de
forma que certos fornecedores forneam certas peas para certos projetos. Observe-se que este
relacionamento ternrio "fornecedores fornecem peas para projetos" no , em geral, o equi-
valente combinao dos trs relacionamentos binrios, "fornecedores fornecem peas",
"peas so usadas nos projetos" e "projetos so fornecidos por fornecedores". A informao,
por exemplo, que
a) Smith fornece chaves-inglesas para o projeto Manhattan nos diz mais do que a combinao
b) Smith fornece chaves-inglesas,
c) chaves-inglesas so utilizadas no projeto Manhattan, e
d) o projeto Manhattan abastecido por Smith

No podemos (incontestavelmente!) deduzir: a) se conhecemos somente b), c) e d). Mais ex-

plicitamente, se conhecemos b), c) e d), podemos deduzir que Smith fornece chaves-inglesas
para algum projeto (digamos, projeto Jz), que algum fornecedor (digamos, fornecedor Sx)
fornece chaves-inglesas para o projeto Manhattan e, que Smith fornece alguma pea (digamos,
pea Px) para o projeto Manhattan -, mas no podemos realmente concluir que Sx Smith ou
que Py sejam chaves-inglesas nem que Jz seja o projeto Manhattan. Concluses errneas como
esta ilustram o que chamamos de armadilha de conexo.
2. O diagrama mostra tambm uma seta que envolve apenas um tipo de entidades (peas). O
relacionamento indica, neste caso, que certas peas incluem outras peas como componentes
imediatos (o chamado relacionamento "lista de materiais que compem um produto ) - por
exemplo, um parafuso componente de uma dobradia, que tambm considerada uma pea e
que, por sua vez, pode ser um componente de uma pea maior, como uma tampa. Observemos
que ainda se trata de um relacionamento binrio; como dois tipos de entidades que se ligam
entre si (ou seja, peas e peas) so uma s e a mesma.
3. Em geral, um dado conjunto de tipos de entidades pode enlaarse em qualquer nmero de
relacionamentos. No diagrama, projetos e empregados so ligados por duas setas, uma poderia
representar o relacionamento "trabalha no" (o funcionrio trabalha no projeto), e outra o rela-
cionamento " o gerente de" (o funcionrio o gerente do projeto).
Um relacionamento tambm pode ser considerado uma entidade. Se tomarmos nossa definio
de entidade "qualquer objeto do qual desejamos registrar informaes", ento relacionamento
certamente se encaixa na definio. Por exemplo, "a pea P4 est estocada no depsito W8"
uma entidade sobre a qual gostaramos de registrar informaes - por exemplo, a quantidade
correspondente. Neste livro, pois, estaremos considerando os relacionamentos simplesmente
como um tipo especial de entidade.

4 - POR QUE BANCO DE DADOS?

Por que usar um sistema de banco de dados? Quais so as vantagens? A resposta de-
pende, at certo ponto, do sistema, se este servir a um usurio nico ou mltiplos - ou, para ser
mais exato, h inmeras vantagens adicionais no caso de usurios mltiplos. Consideramos,
primeiramente, o caso do usurio nico. Referimo-nos novamente ao exemplo da adega de
vinhos, o qual julga-se caracterstico de um banco de dados de usurio nico. Este banco de
dados especfico to pequeno e simples que as vantagens podem no ser bvias de imediato.
Imaginemos, porm, um banco de dados similar para um grande restaurante, com um estoque
de talvez milhares de garrafas e com freqentesalteraes; ou uma loja de bebidas alcolicas,
com um estoque imenso e muita rotatividade. (Embora se trate de um banco de dados maior,
ainda um sistema de usurio nico.).
As vantagens do sistema de banco de dados em relao aos mtodos tradicionais,
baseads em papis e arquivos ficaro mais evidentes nos seguintes exemplos:

compacto: No h necessidade de arquivos de papis volumosos.

rpido: A mquina pode recuperar e modificar os dados muito mais rapidamente do que o
ser humano. Em especial, as consultas incidentais, repentinas (como, p. ex., "Temos mais
Zinfandel do que Pinot Noir?") so rapidamente respondidas, sem consultas a manuais ou
pesquisas visuais, que consomem muito tempo.
 Importa em menos trabalho braal: elimina a maior parte do tedioso trabalho manual de ar-
quivamento. As mquinas sempre executam as tarefas mecnicas melhor do que ns.
Tem fluxo corrente: disponibilidade de informaes certas e atualizadas a qualquer momento,
basta pedir.
As vantagens acima so mais significativas em ambientes de usurios mltiplos onde o
banco de dados maior e mais complexo do que o de usurio nico. H, neste caso, outra
vantagem dominante, a saber: O sistema do banco de dados proporciona empresa o controle
centralizado de seus dados operacionais ( uma de suas propriedades mais teis). Tal situao
contrasta nitidamente com a que vemos na empresa sem sistema de banco de dados, onde cada
aplicao dispe de seus prprios arquivos - muitas vezes tambm suas fitas e discos particu-
lares - de tal forma que os dados operacionais so muito dispersos, diiicultando o controle
sistemtico.
Vamos aprofundar o conceito de controle centralizado: implica que (numa empresa
com um sistema de banco de dados) exista uma pessoa identificvel detendo a responsabilidade
central sobre os dados operacionais. Esta pessoa o administrador do banco de dados (DBA);
por enquanto; suficiente sabermos que o cargo requer a) um alto grau de capacitao tcnica,
e b) a capacidade de entender e interpretar as necessidades da empresa a nvel de gerncia
executiva. Na prtica, a funo do DBA pode ser desempenhada por um grupo de pessoas,
gerentes e tcnicos, ao invs de apenas um indivduo. Contudo, para simplificar, partiremos do
princpio que o DBA seja na verdade uma nica pessoa. importante percebermos que a
posio do DBA dentro da empresa (ou deveria ser) de alto nvel gerencial.
Descrevemos a seguir algumas das vantagens que resultam da noes de controle
centralizado:

Pode reduzir a redundncia.

Nos sistemas sem banco de dados, cada aplicao possui seus prprios arquivos. Este fato
costuma provocar uma redundncia considervel nos dados armazenados, com o desperdcio
de espao de armazenamento resultante. Por exemplo, uma aplicao de pessoal e uma apli-
cao de registros de educao podem ter, ambas, um arquivo contendo informaes do de-
partamento relativo aos funcionrios. Como sugerido na Seo 1.2., estes dois arquivos podem
ser integrados, e a redundncia eliminada, se o DBA estiver a par das necessidades de dados de
ambas as aplicaes - isto , se o DBA possuir o necessrio controle global.
No pretendemos sugerir que toda a redundncia deva necessariamente ser eliminada. Algu-
mas vezes, existem fortes razes, tcnicas ou comerciais, para se manter cpias mltiplas do
mesmo dado. Entretanto sugerimos que a redundncia seja cuidadosamente controlada - isto ,
o DBMS deve ter conhecimento da mesma, e assumir a responsabilidade de "propagar as atu-
alizaes" (vide o item abaixo).

A inconsistncia pode ser evitada (at certo ponto).

Conseqncia natural do item anterior. Suponhamos que um certo fato do mundo real -
digamos, o fato de que o funcionrio E3 trabalha no departamento D8 - representado por duas
entradas distintas no banco de dados, e qu o DBMS no tenha conhecimento desta duplicidade
(i.e., a redundncia no controlada). Haver, ento, ocasies em que as duas entradas no
sero concordes - ou seja, quando apenas uma das duas entradas for atualizada. Diz-se, ento,
que o banco de dados inconsistente. bvio que um banco de dados considerado inconsis-
tente capaz de fornecer informaes incorretas ao usurio.
Se o fato mencionado estiver representado por uma nica entrada (isto , se a re-
dundncia for removida), obviamente tal inconsistncia no poder ocorrer. Alternativamente,
se a redundncia no for removida, mas controlada (tornando-se conhecida do DBMS); ento
ele poder garantir que o banco de dados nunca estar inconsistente, como visto pelo usurio,
assegurando que qualquer alterao feita em uma das entradas seja automaticamente aplicada
na outra. Conhece-se este processo como propagao de atualizao - onde (como ocorre em
geral) se utiliza o termo "atualizao" para cobrir todas as operaes de insero, anulao e
modificao. Observemos, entretanto, que poucos sistemas comercialmente disponveis hoje
so capazes de propagar automaticamente as atualizaes; isto , a maioria dos produtos atuais
no suporta a redundncia controlada, exceto em poucos casos especiais.

Pode compartilhar os dados.

O compartilhamento no significa apenas que as aplicaes existentes podem com-

partilhar os dados do banco de dados, mas tambm que novas aplicaes podem ser desen-
volvidas para operar sobre os mesmos dados armazenados. Em outras palavras, as necessi-
dades de dados das novas aplicaes podem ser satisfeitas sem a criao de quaisquer dados
adicionais armazenados.

Pode reforar os padres.

O DBA, pelo controle central do banco de dados, pode assegurar que todos os padres
aplicveis sero observados na representao dos dados. Os padres aplicveis podem incluir
um ou todos, mencionados a seguir: padres a nvel de instalaes, departamentos, indstrias,
padres nacionais ou internacionais. Uma padronizao dos formatos dos dados armazenados
especialmente interessante para facilitar o intercmbio de dados ou a migrao entre sistemas.
Da mesma forma seria desejvel a denominao dos dados e a padronizao da documentao
para facilitar o compartilhamento e a compreenso dos dados.

Pode aplicar restries de segurana.

O DBA, detendo toda a autoridade sobre os dados operacionais, pode assegurar a) que
os nicos meios de acesso ao banco de dados sejam realizados atravs de certos canais e,
conseqentemente, b) pode definir os controles de segurana a adotar, sempre que for em-
preendido o acesso a determinados dados especiais. Pode estabelecer diferentes controles para
cada tipo de acesso (recuperao, modificao, anulao etc.) e para cada parte da informao
no banco de dados. Observemos, porm, que os dados, sem tais controles de segurana, podem
incorrer num risco maior do que em sistema tradicional de arquivo (disperso); isto , a natureza
centralizadora do sistema de banco de dados requer, tambm, um bom sistema de segurana.

Pode manter a integridade.

O problema da integridade assegurar que os dados do banco de dados sejam corretos.

A inconsistncia entre duas entradas que pretendem representar o mesmo "fato" um exemplo
de falta de integridade (vide discusso no item acima); este problema, certamente, s pode
ocorrer se houver redundncia nos dados armazenados. Entretanto, mesmo que ela no exista,
o banco de dados ainda pode conter uma informao incorreta. Por exemplo, estaria registrado
que um funcionrio trabalhou 400 horas na semana, em vez de 40 horas, ou que o mesmo
pertence a um departamento inexistente. O controle centralizado do banco de dados ajuda a
evitar tais problemas - medida que possam ser evitados -, pois permite que o DBA defina
controles de integridade a realizar sempre que for empreendida qualquer operao de atuali-
zao. (Utilizamos novamente o termo "atualizao" em termos genricos, a fim de abranger
todas as operaes de modificao, insero e anulao).
Chama-se a ateno para o fato de a integridade de dados ser ainda mais importante em
sistemas de banco de dados de usurios mltiplos do que nos ambientes de "arquivos particu-
lares", precisamente porque o banco de dados compartilhado. Sem controles apropriados, um
usurio poderia atualizar o banco de dados incorretamente, gerando dados errados e, assim
"infectando" outros usurios. A mencionar, ainda, que a maioria dos produtos atuais de banco
de dados so um tanto fracos no suporte de controles de integridade.
 Pode equilibrar as necessidades conflitantes.

O DBA, tendo conhecimento das necessidades globais da empresa - em oposio s

necessidades de um usurio individual - pode estruturar o sistema, a fim de proporcionar um
servio geraI que seja "o melhor para a empresa". Por exemplo, pode-se escolher uma repre-
sentao para os dados na memria, dando rpido acesso s aplicaes mais importantes, em
detrimento do desempenho mais fraco de determinadas aplicaes.
A maioria das vantagens mencionadas acima provavelmente bastante bvia. Entretanto h
necessidade de adicionarmos um outro item lista, que no to bvio - muito embora tenha
relao com diversos itens anteriores - ou seja, a independncia de dados. (Na verdade, mais
um objetivo dos sstemas de banco de dados do que necessariamente uma vantagem.) O con-
ceito da independncia de dados to importante que dedicaremos uma seo exclusivamente
ao mesmo.

5 ARQUITETURA DE UM BANCO DE DADOS

OS TRS NVEIS DA ARQUITETURA

A arquitetura divide-se em trs nveis gerais: interno, conceitual e externo (Figura 3). Em
termos amplos:

1. o nvel interno o mais prximo ao armazenamento fsico - i.e. relaciona-se forma

como so realmente armazenados os dados;
2. o nvel externo o mais prximo aos usurios - i.e., forma como os dados so vistos
pelos usurios 7individuais; e
3. o nvel conceitual o "nvel de simulao", entre os dois outros. Se o nvel externo diz
respeito s vises do usurio individual, o nvel conceitual pode ser considerado a viso
do grupo de usurios.

Se o nvel externo diz respeito s vises do usurio individual, o nvel conceitual pode ser
considerado a viso do grupo de usurios.
Em outras palavras, haver muitas "vises externas" distintas, cada uma consstindo em uma
representao mais ou menos abstrata de determinada parte do banco de dados e haver pre-
cisamente uma "viso conceitual", que corresponde representao abstrata do banco de dados
em sua totalidade.' (Lembremo-nos que a maioria dos usurios no estar interessada em todo o
banco de dados, mas somente numa parte restrita do mesmo.) Da mesma forma, haver
exatamente uma "viso interna", representando todo o banco de dados como armazenado de
fato.

FIGURA 3 Os trs nveis da arquitetura

Um exemplo tornar estas idias mais claras. A figura 4 mostra a viso conceitual de um
simples banco de dados sobre funcionrios, a viso interna correspondente e as duas vises
externas correspondentes, uma para um usurio de PL/I e outra para o usurio de COBOL. O
exemplo, na certa, totalmente hipottico - no pretende simular qualquer sistema real - e
muitos detalhes irrelevantes foram deliberadamente omitidos.
Interpretamos a Figura 4 como segue:

FIGURA 4 Exemplo dos trs nveis

O banco de dados contm, no nvel conceitual, informaes referentes ao tipo de entidade

chamada EMPLOYEE. Cada EMPLOYEE tem um EMPLOYEE_NUMBER (seis caracteres),
um DEPARTMENT NUMBER (quatro caracteres) e um SALARY (cinco dgitos decimais).
Os funcionrios esto representados, no nvel interno, por um tipo de registro armazenado
chamado STORED EMP, com dezoito bytes de comprimento. O STORED_EMP contm
quatro tipos de campos armazenados: um prefixo de seis bytes (contendo, provavelmente,
informaes de controle como sinalizadores ou ponteiros, e trs campos de dados correspon-
dendo s trs propriedades dos funcionrios, Os registros STORED_EMP so, adicionalmente,
indexados no campo CAMPO EMP por um ndice chamado EMPX.

O usurio de PL/I tem uma viso externa do banco de dados, na qual cada fnncionrio
representado por um registro PL/I, contendo dois campos (os nmeros de departamento no
so do interesse deste usurio, e por isto foram omitidos da viso). O tipo de registro definido
por uma declarao comum de estrutura PL/I, de acordo com as regras normais de PL/I.

Do mesmo modo, o usurio de COBOL tem uma viso externa, na qual cada funcionrio
representado por um registro COBOL, contendo, novamente, dois campos (desta vez foi
omitido o de salrio). O tipo de registro definido por um registro cornum COBOL, de acordo
com as regras normais do COBOL.

Observemos que objetos correspondentes podem ter nomes diferentes em cada nvel. O
nmero do funcionrio, por exemplo, chamado de EMP # na viso da PL/I, e de EMPNO na
viso COBOL, como EMPLOYEE_NUMBER na viso conceitual e como EMP # (no-
vamente) na viso interna. O sistema certamente deve estar a par das correspondncias. Deve
ser informado, por exemplo, que o campo COBOL EMPNO deriva do objeto conceitual
EMPLOYEE_NUMBER que, por sua vez, representado no nvel interno pelo campo ar-
mazenado EMP # . Tais concordncias, ou mapeamentos, no so mostradas na Figura 4.

Primeiro, o nvel conceitual em tal sistema ser definitivamente relacional, no sentido

de que os objetos visveis neste nvel sero tabelas relacionais (os operadores tambm sero
operadores relacionais, i.e., operadores que trabalham com tais tabelas). Segundo, uma de-
terminada viso externa ser igualmente relacional ou algo bem prximo; por exemplo, os
registros PL/I e COBOL podem ser considerados, respectivamente, como as representaes
PL/I e COBOL de (uma linha dentro de) uma tabela relacional. Terceiro, o nvel interno cer-
tamente no ser sempre "relacional", desde que os objetos desse nvel no sero exatamente
tabelas relacionais (armazenadas) - ao contrrio, sero a mesma espcie de objetos encontrados
no nvel interno de outros tipos de sistema (a saber, registros armazenados, ponteiros, ndices,
acessos hash etc.). De fato, a teoria relacional como tal no tem nada a dizer sobre o nvel
interno (repetimos, sobre como o banco de dados aparece para o usurio.
Examinaremos agora mais detalhadamente os trs nveis da arquitetura, iniciando com o nvel
externo.

6 - O NVEL EXTERNO

O nvel externo o nvel do usurio individual. Um determinado usurio tanto pode ser
um programador de aplicaes como um usurio de terminal on-line - i.e., um usurio final - de
qualquer grau de sofisticao. O DBA um caso especial importante. (Ao contrrio dos
usurios comuns, o DBA ter de se interessar pelos nveis conceitual e interno tambm.
Cada usurio tem uma linguagem sua disposio:

Esta linguagem, para o programador de aplicao, pode ser uma linguagem conven-
cional de programao, como COBOL ou PL/I, ou uma linguagem de programao apropriada,
especfica do sistema em questo (sistemas NOMAD, Rdv/VMS ou dBase II).

Para o usurio final, pode ser uma linguagem de consulta ou uma linguagem de
propsitos especiais, talvez baseada em formulrios ou menu, modelada s necessidades do
usurio e suportada por um programa de aplicao on-line.

Para nossos propsitos, o que importa sabermos que todas essas linguagens incluiro
uma sublinguagem de dados - ou seja, um subconjunto de toda a linguagem, voltado para os
objetivos e operaes do banco de dados. A sublinguagem de dados (DSL) embutida na
linguagem hospedeira correspondente, a qual proporciona os diversos recursos no-especficos
de banco de dados, tais como variveis locais (temporrias), operaes computacionais, lgica
if-then-else e assim por diante. Um determinado sistema pode suportar mltiplas linguagens
hospedeiras e mltiplas sublinguagens de dados.
FIGURA 5 Sistema de Arquitetura detalhado

Observao: Embora seja conveniente diferenciar, na arquitetura, a sublinguagem de

dados e linguagem hospedeira, as duas, em relao ao usurio, podem ser indistinguveis. Se
assim for, ou se s puderem ser separadas com dificuldades, dizemos que so "unidades de
maneira firme". Se as linguagens so fceis e claramente separadas, dizemos que so "unidas
de maneira indefinida". A maioria dos sistemas de hoje suporta apenas a unio indefinida. Um
sistema firmemente unido propiciar um conjunto de recursos mais uniforme para o usurio,
mas obviamente requer maior esforo por parte dos projetistas do sistema (o que poderia ex-
plicar o que temos hoje). Entretanto, parece haver um movimento que, gradualmente, nos le-
var a dispor, nos prximos anos, de sistemas com unio mais firme.
Em princpio, qualquer sublinguagem de dados rea]mente uma combinao de pelo
menos duas linguagens subordinadas: a linguagem de definio de dados (DDL), que possi-
bilita a definio ou descrio dos objetos do banco de dados, e a Iinguagem de manipulao de
dados (DML), que suporta a manipu]ao ou processamento desses objetos. Considerando-se o
usurio de PL/I da figura 4, a sublinguagem de dados para aquele usurio compe-se dos as-
pectos de PL/I utilizados para a comunicao com o DBMS. A parte DDL consiste nas cons-
trues declarativas do PL/I necessrias para declarar os objetos do banco de dados: a prpria
instruo DECLARE (DCL), certos tipos de dados PL/I, e possivelmente as extenses espe-
ciais para PL/I, para suportar novos objetos que no so tratados pelo PL/I existente. A parte
DML compe-se das instrues executveis do PL/I que transferem as informaes de e para o
banco de dados - podendo, novamente, incluir novas instrues especiais. (Observao: Os
PL/I atuais de fato no incluem aspectos especficos de banco de dados. As instrues "DML",
por isto, so apenas "CHAMADAS" para o DBMS. Eis por que sistemas PL/I, como muitos
sistemas atuais, s proporcionam uma unio muito indefinida entre a sublinguagem de dados e
a hospedeira.)
Voltando arquitetura: J mencionamos que o usurio individual, por via de regra, s
vai interessar-se por determinada parte do banco de dados; alm disso, a viso que o usurio
ter daquela parcela , em geral, algo abstrato, em comprao forma como os dados so
fisicamente armazenados. Em termos ANSI/SPARC, a viso de determinado usurio uma
viso externa. A viso externa , portanto, o contedo do banco de dados como visto por de-
terminado usurio (ou seja, para aquele usurio, a viso externa o banco de dados). Um
usurio do Departamento de Pessoal, por exemplo, pode ver o banco de dados como uma
co]eo de eventos de registros do departamento, e uma coleo de eventos de registros de
empregados (Podendo estar totalmente desinformado das ocorrncias de registros de forne-
cedores e peas vistas pelos usurios do Departamento de Compras). Portanto, uma viso ex-
terna consiste, em geral, em ocorrncias mltiplas, de mltiplos tipos de registro externo3. Um
registro externo no necessariamente o mesmo que um registro armazenado. A sublinguagem
de dados do usurio definida em termos de registros externos; por exemplo, uma operao de
"recuperao de registro" da DML ir recuperar um evento de registro externo, e no uma
ocorrncia de registro armazenado. Percebemos agora, conseqentemente, que o termo "re-
gistro lgico" refere-se a um registro externo.
Cada viso externa definida por meio de um esquema externo, que consiste, basi-
camente, em definies para cada um dos vrios tipos de registro externo naquela viso externa.
O esquema externo descrito usando-se a parte DDL da sublinguagem de dados do usurio.
(Denomina-se, assim, a DDL, s vezes, de DDL externa.) O tipo de registro externo fun-
cionrio, por exemp]o, pode ser definido como um campo de seis caracteres, nmero do fun-
cionrio, mals um campo de cinco dgitos decimals, `salrio', e assim por diante. Alm disso,
deve haver uma definio do mapeamento entre o esquema externo e o esquema conceitual
fundamental

9 - O NVEL CONCEITUAL

A viso conceitual a representao de todo o contedo de informaes do banco de

dados, tambm (como a viso externa) um tanto abstrata quando comparada forma como os
dados so fisicamente armazenados, que tambm pode ser bem diferente da maneira como os
dados so vistos por qualquer usurio em particular. A grosso modo, podemos dizer que a viso
conceitual a viso dos dados "como realmente so", e no como os usurios so forados a
v-los devido s restries (por exemplo) da linguagem ou do hardware utilizados pelos
mesmos.
A viso conceitual consiste em ocorrncias mltiplas de tipos mltiplos de registros
conceituais. A mesma pode consistir, por exemplo, em uma srie de ocorrncias de registros de
departamentos, mais um conjunto de ocorrncias de registros de funcionrios, ou de fornecedo-
res de peas ... De um lado, um registro conceitual no necessariamente o mesmo do que um
registro externo e, de outro, nem o mesmo que um registro armazenado.
A viso conceitual definida pelo esquema conceitual que inclui definies de todos os
diversos tipos de registros conceitual. O esquema conceitual escrito atravs de outra lin-
guagem de definio de dados, a DDL conceitual. Para que se possa alcanar a independncia
de dados, essas definies da DDL conceitual no podem conter quaisquer consideraes sobre
a estrutura de armazenamento ou a estratgia de acesso - devem ser apenas definies das
informaes. Assim, no pode haver referncia ao esquema conceitual para as representaes
do campo armazenado, seqncia de registro armazenado, indexao, acesso hash, ponteiros
ou quaisquer outros detalhes de armazenamento/acesso. Se o esquema conceitual for realmente
independente de dados, ento os esquemas externos, que so definidos em termos do esquema
conceitual, tambm sero necessariamente independentes de dados.
A viso conceitual, ento, a viso do contedo total do banco de dados, e o esquema
conceitual uma definio desta viso. Seria errado, porm, dizer-se que o esquema conceitual
no nada mais do que um conjunto de definies parecidas com simples definies de reg-
istros como encontrados, por exemplo, num programa COBOL. As definies no esquema
conceitual devem incluir uma grande quantidade de aspectos, como controles de segurana e
de integridade. Algumas autoridades na matria ainda vo mais alm, e sugerem que o objetivo
final do esquema concetual descrever toda a empresa - no somente os dados operacionais,
mas tambm como so usados: como transcorre o fluxo em cada ponto da empresa, como
usado em cada ponto, como se aplicam a auditoria ou outros controles em cada ponto, e assim
por diante. Enfatizamos, no entanto, que hoje em dia nenhum sistema realrnente suporta um
nvel conceitual que se aproxime deste grau de abrangncia; na maioria dos sistemas existentes,
o "esquema conceitual" realmente pouco mais que uma simples unio de todos os esquemas
externos e indviduais, com a provvel ado de alguns controles de segurana e integridade.
Mas tudo indica que os sistemas, no futuro, sero eventualmente mais sofisticados quanto ao
suporte do nvel conceitual. Discutiremos este tpico com mais profundidade no final desse
Ivro (vde CaptuIo 25).
10 - O NVEL INTERNO

O terceiro nvel da arquitetura o nvel interno. A viso interna uma pequena representao
de todo o banco de dados; consiste em ocorrncias mltiplas de tipos mltiplos de registros
internos. O "registro interno" termo ANSI/SPARC para a estrutura que temos denominado de
registro armazenado (termo que continuaremos a empregar). A viso interna um tanto dis-
tante do nvel fsico, uma vez que no trabalha em termos de registros fsicos (tambm
chamados pginas ou blocos), nem de consideraes de dispositivos especficos tais como
cilindro ou comprimento de trilha. (A viso interna assume basicamente um espao de en-
dereamento linear e infinifo. Os detalhes de como este espao de endereamento mapeado
at o armazenamento fsico so altamente especficos a cada sistema, e deliberadamente
omitidos de arquitetura.)
A viso interna descrita por meio do esquema interno, que no s define os vrios
tipos de registros armazenados como tambm especifica os ndices que existem, como os
campos armazenados so representados, a seqncia fsica dos registros armazenados, e assim
por diante. O esquema interno preparado atravs de uma outra linguagem de definio de
dados - a DDL interna.
Observamos, parte, que, em certas situaes excepcionais, os programas de aplicao - em
particular, as aplicaes de natureza "utilitria" podem operar diretamente no nvel interno, ao
invs do nvel externo. No necessrio dizer que esta prtica no recomendvel; representa
um risco de segurana (posto que o controle de segurana no observado) e um risco de in-
tegridade (uma vez que os controles de integridade tambm no so observados), e o programa,
alm disso, torna-se dependente de dados, em algumas ocasies, porm esta poder ser a nica
forma de se obter a funo ou a performance nocasria - assim como o usurio de uma lin-
guagem de programao de alto nvel pode, ocasionalmente, precisar utilizar a linguagem de
montagem (assembler) para satisfazer certos objetivos funcionais ou de desempenho.

11- MAPEAMENTOS

Referindo-nos novamente Figura 5, observa-se dois nveis de mapeamento na ar-

quitetura, um entre os nveis externo e conceitual do sistema e um entre os nveis conceitual e
interno. O mapeaniento conceituallinterno define a correspondncia entre a viso conceitual e
o banco de dados armazenado; especifica como os registros e campos conceituais so repre-
sentados no nvel interno. Se a estrutura do anco de dados armazenado for modificada - i.e., se
for executada uma mudana na definio da estrutura armazenada -, o mapeamento concei-
tual/interno tambm dever ser modificado de acordo, de forma que o esquema conceitual
permanea invarivel. (O controle destas mudanas da responsabilidade do DBA.) Em outras
palavras, os efeitos dessas modificaes devem ser isolados abaixo do nvel conceitual, de
maneira a preservar a independncia de dados.
Um mapeamento externo/conceitual define a correspondncia entre uma determinada
viso externa e a viso conceitual. As diferenas que podem existir entre estes dois nveis so
similares aquelas que podem existir entre a viso conceitual e o banco de dados armazenado.
Como exemplo, os campos podem ter tipos de dados diferentes, as denominaes de campo e
registro podem ser modificadas, campos conceituais mltiplos podem ser combinados num
nico campo externo (virtual) etc. Pode haver qualquer nmero de vis~es externas ao mesmo
tempo; qualquer quantidade de usurios pode compartilhar de uma determinada viso externa;
diferentes vises externas podem sobrepor-se. Alguns sistemas possibilitam que a definio de
uma viso externa seja expressa em termos de outra (de fato, va mapeamento externo/externo),
ao invs de exigirem sempre uma definio explcita do mapeamento a nvel conceitual - um
aspecto muito til, quando diversas vises externas se relacionam entre si.

12 - O ADMINISTRADOR DO BANCO DE DADOS

O administrador do banco de dados (DBA), j rnencionado a pessoa (ou grupo de

pessoas) responsvel pelo controle do sistema. As responsabilidades do DBA incluem o se-
guinte:

Decidir o contedo de informaes do banco de dados

Faz parte do trabalho do DBA decidir exatamente que informao manter no banco de
dados - em outras palavras, deve identificar as entidades do interesse da empresa e a infor-
mao a registrar em relao a estas entidades. Uma vez feito isto, o DBA deve ento definir o
contedo do banco de dados, descrevendo o esquema conceitual (usando 0 DDL cnceitual). A
forma objeto (compilado) daquele esquema utilizada pelo DBMS para responder s solici-
taes de acesso. A forma (no compilada) atua como documento de referncia para os
usurios do sistema.

Decidir a estrutura de armazenamento e a estratgia de acesso

 O DBA tambm deve decidir como os dados sero representados no banco de dadosb, e
definir esta representao escrevendo a definio da estrutura de armazenament (usando a
DDL interna). Alm disso, deve definir o mapeamento associado entre os nveis interno e
conceitual. Na prtica, tanto a DDL conceitual quanto a DDL interna - mais provavelmente a
primeira - provavelmente incluiro os meios de definio desse mapeamento, mas as duas
funes (a definio do esquema, a definio do mapeamento) devem ser claramente separadas.
Tal como o esquema conceitual, o esquema interno e o mapeamento correspondente existiro
no s na forma-fonte como na forma objeto.

Servir de elo de ligao com usurios

funo do DBA servir de elo de ligao com os usurios, a fim de garantir a dis-
ponibilidade dos dados de que estes necessitam, e prepar~ - ou auxili-los na preparao dos
necessrios esquemas externos, utilizando a DDL externa apropriada (como j mencionamos,
um determinado sistema pode suportar diversas DDLs externas e distintas). E, ainda, tambm
deve ser definido o mapeamento entre qualquer esquema externo e o esquema conceitual. Na
prtica, a DDL externa provavelmente incluir os meios de especificao do mapeamento, mas
o esquema e o mapeamento devem ser claramente separados. Cada esquema externo e o
mapeamento correspondente existiro tanto na formafonte como na forma objeto.

Definir os controles de segurana e integridade

Os controles de segurana e de integridade, como j mencionado, podem ser consid-

erados parte do esquema conceitual. A DDL conceitual incluir os recursos para a especifi-
cao de tais controles.

Definir a estratgia de reserva e recuperao

A partir do momento em que a empresa comea efetivamente a basear-se em banco de

dados, torna-se dependente do bom funcionamento deste sistema. Na eventualidade de danos
parte do banco de dados - causados, digamos, por erro humano, ou por falha no hardware, ou
n sistema operacional de suporte -, de suma importncia fazer retornar os dados envolvidos
com um mnimo de demora e com as menores conseqncias ao restante do sistema. Por
exemplo, os dados que no sofreram danos no devero ser afetados.' O DBA deve definir e
implementar uma estratgia de recuperao apropriada envolvendo, por exemplo, o descar-
regamento peridico do banco de dados na memria auxiliar de armazenamento e procedi-
mentos para recarreg-lo, quando necessrio.

Monitorar o desempenho e atender as necessidades de modificaes.

O DBA deve organizar o sistema de tal maneira que obtenha "o melhor desempenho
para a empresa"; e efetuar os ajustes adequados quanto s necessidades de modificaes. Como
j mencionamos, quaisquer mudanas nos detalhes de armazenamento e acesso devem ser
acompanhadas de mudanas correspondentes na definio do mapeamento, a partir do nvel
conceitual, de forma que o esquema conceitual possa permanecer constante.O DBA, evi-
dentemente, ir precisar de diversos programas utilitrios como auxlio s tarefas precedentes.
Estes so uma parte essencial de um sistema de banco de dados prtico, embora no sejam
mostrados na Figura 5 da arquitetura. Listamos abaixo alguns exemplos dos programas
utilitrios necessrios.

Rotinas de carga (para criar uma verso inicial do banco de dados a partir de um ou mais
arquivos).

Rotinas de despejo na memria e recuperao (despejar o banco de dados, auxiliar de ar-

mazenamento de dados, e recarregar o banco de dados a partir dessa cpia de segurana).
Observao: As rotinas de carga mencionadas acima consistiro, na prtica, no aspecto de
"recuperao" das rotinas de despejo/recuperao na memria. Rotinas de reorganizao (para
rearrumar os dados no banco de dados, em vista de diversas razes de desempenho - por exem-
plo, agrupar os dados de certa maneira ou regenerar espao ocupado por dados que se tornaram
obsoletos).

Rotinas estatsticas (para computar diversos desempenhos estatsticos, tamanhos de arquivos

e distribuio de valores de dados). Rotinas analticas (para analisar as estatsticas menciona-
das). Uma das ferramentas mais importantes do DBA - de muitas maneiras e, de fato, o corao
de todo o sistema, embora no mostrado na Figura 5 - o dicionrio de dados (conhecido
tambm como catlogo do sistema). O dicionrio de dados pode ser considerado um banco de
dados (mas um banco de dados de sistema, e no propriamente um banco de dados de usurio).
O contedo do dicionrio pode ser considerado "dados sobre dados" (s vezes denominado
"metadados") - ou seja, descries de outros objetos no sistema, ao invs de simples "dados em
bruto". Os diversos esquemas e mapeamentos (externo, conceitual etc.), especialmente, sero
fisicamente armazenados, ambos na forma-fonte e na forma objeto, no dicionrio. Um di-
cionrio abrangente tambm incluir referncias cruzadas das informaes, mostrando, por
exemplo, que programas utilizam tal parte do banco de dados, que departamentos necessitam
de tais relatrios, que terminais esto conectados ao sistema, e assim por diante. O dicionrio
tambm pode (e deveria) estar integrado ao banco de dados que descreve, incluindo, portanto, a
sua prpria descrio. Deveria ser possvel consultar-se o dicionrio, tal como qualquer outro
banco de dados, de maneira que fosse possvel indicar os programas e/ou usurios que seriam
afetados por eventual mudana no sistema.

13- O SISTEMA DE GERENCIAMENTO DO BANCO DE DADOS.

O sistema de gerenciamento do banco de dados (DBMS) o software que manipula

todos os acessos ao banco de dados. De forma conceitual, acontece o seguinte:

1. O usurio emite uma solicitao de acesso, usando uma sublinguagem especfica de dados
(por exemplo, SQL).

2. O DBMS intercepta a solicitao e analisa-a.

3. O DBMS, por sua vez, inspeciona os esquemas externos para aquele usurio, o mapeamento
externo/conceitual correspondente, o esquema conceitual, o mapeamento conceitual/interno e
a definio da estrutura de armazenamento.

4. O DBMS executa as operaes necessrias no banco de dados armazenado.

Consideramos, por exemplo, o que envolve a recuperao de uma ocorrncia especfica

de registro externo. Em geral, diversas ocorrncias de registro conceitual vo solicitar campos.
Cada ocorrncia de registro conceitual, por sua vez, pode solicitar os campos de diversas
ocorrncias de registro armazenado. O DBMS, finalmente, precisa, em primeiro lugar, recu-
perar todas as ocorrncias de registro armazenado solicitadas, depois construir as ocorrncias
de registro conceitual solicitadas, e ento construir a ocorrncia de registro externo solicitada.
Em cada estgio, so necessrios tipos de dados ou outras converses.
Consideremos, entretanto, que a descrio acima est muito simplificada. A mesma
sugere, especialmente, que todo o processo interpretativo, o que implica, em geral, desem-
penho fraco (improdutividade do tempo de execuo). As solicitaes de acesso, na prtica,
talvez possam ser compiladas antes do tempo de execuo.
 Podemos caracterizar, de outra maneira, a funo do DBMS, ou seja, o mesmo pro-
porciona a interface de usurio ao sistema de banco de dados. A interface do usurio pode ser
definida como um limite no sistema abaixo do qual tudo invisvel ao usurio. Por definio, a
interface do usurio est no nvel externo, h certas situaes em que a viso externa difere de
maneira muito significativa da viso conceitual fundamental (a parte relevante de).

14- COMUNICAES DE DADOS

Conclumos este captulo com uma breve meno comunicao de dados. As solici-
taes ao banco de dados a partir de um usurio final so normalmente transmitidas (a partir do
terminal do usurio ~- que pode estar fisicamente longe do sistema - para alguma aplicao
on-line, embutida ou outra, e dali para o DBMS) na forma de mensagens de comunicao. As
respostas ao usurio (do DBMS e da aplicao on-line de volta ao terminal do usurio) tambm
so transmitidas sob a forma de mensagens. Todas essas transmisses de mensagens so efe-
tuadas sob a direo de um outro sistema de software, o gerenciador comunicao dos dados
(gerenciador DC).
O gerenciador DC no um componente do DBMS, mas sim um sistema autnomo em
si. Entretanto, posto que gerenciador DC e o DBMS devem trabalhar harmoniosamente, cos-
tumamos consider-los parceiros de mesmo nvel no exerccio denominado banco de da-
dos/sistema de comunicao de dados (sistema DB/DC); o DBMS procura o banco de dados e
o gerenciador DC manipula todas as mensagens para e
As diversas tcnicas no devem ser consideradas passveis de se exclurem mutuamente. Por
exemplo, perfeitamente possvel ter um arquivo armazenado (digamos) tanto com acesso
indexado como com acesso hash ao arquivo baseado no .mesmo campo armazenado, ou com
acesso hash em um campo e um acesso de cadeia de ponteiro em outro.

15 - INDEXAO
Consideremos a tabela de fornecedores na Figura 6, mais uma vez. Suponhamos a
consulta: "Achar todos os fornecedores da cidade C" (onde C seja um parmetro). Esta consulta
importante - i.e., ser executada com freqncia e, por isso, deve ser bem resolvida. Assim, o
DBA talvez escolha a representao armazenada mostrada na Fig. 3.10, onde existem dois
arquivos armazenados, um arquivo de fornecedores, e um arquivo de cidades (provavelmente
em diferentes conjuntos de pginas); o arquivo de cidades, armazenado na seqncia de ci-
dades (porque CITY uma chave primria, inclui ponteiros (RIDs) ao arquivo de fornecedores.
Para que o DBMS possa achar todos os fornecedores de Londres (digamos), existem duas
estratgias possveis:
1. Buscar em todo o arquivo de fornecedores, procurando todos os registros cujo valor de ci
dade seja igual a Londres.

FIGURA 6 Indexao de arquivos de fornecedores em CITY

2. Buscar as entradas de Londres no arquivo de cidades e, para cada uma, acompanhar o pon-
teiro ao registro correspondente no arquivo de fornecedores. Se a proporo de fornecedores de
Londres em relao aos outros for pequena, provavelmente a segunda estratgia seria mais
eficaz do que a primeira, porque 1) o DBMS est a par do seqenciamento fsico do arquivo de
cidade (pode parar a busca naquele arquivo, assim que o mesmo achar uma cidade que suceda
Londres na ordem alfabtica), e 2) mesmo que tenha de empreender uma busca em todo o
arquivo de cidades, a mesma ainda necessitaria de menos entradas/sadas, pois o arquivo de
cidades fisicamente menor do que o de fornecedores (pois os registros so menores).
O arquivo de cidades neste exemplo tido como um ndice para o arquivo de forne-
cedores; o arquivo de fornecedores, da mesma forma, tido como indexado pelo arquivo de
cidades. Um ndice uma espcie especial de arquivo armazenado. Para ser mais especfico,
um arquivo no qual cada entrada (i.e., registro) compe-se precisamente de dois valores, um
valor de dados e um ponteiro (RID);
o valor de dados um valor para determinado campo do arquivo indexado, e o ponteiro
identifica um registro daquele arquivo que tenha o valor daquele campo.
A partir deste ponto, passaremos a nos referir ao arquivo de cidades da Figura 6 mais explici-
tamente como "o ndice CITY". Um ponto da terminologia: Um ndice de um campo de chave
primria - por exemplo, um ndice no campo S # do arquivo de fornecedores - chamado de
ndice primrio. Um ndice de qualquer outro campo - por exemplo, o ndice CITY do exemplo
- denominado ndice secundrio. Como So Usados os ndices.
A vantagem fundamental do ndice que acelera a recuperao. Entretanto h tambm
uma desvantagem - reduz a velocidade das atualizaes. (Como em muitas outras situaes, h
uma compensao.) Por xemplo, cada vez que se adiciona um novo registro armazenado ao
arquivo indexado, uma nova entrada ter de ser acrescentada ao ndice. Consideremos, como
exemplo mais expecfico, o que o DBMS deve fatter no ndice CITY da Fig. 6 para mudar o
fornecedor S2 de Paris para Londres. A questo que deve ser respondida quando um campo
considerado como candidato indexao : O que seria mais importante, a recuperao efi-
ciente baseada no valor do campo em questo ou a perda em atualizao, em funo da recu-
perao eficiente?
No restante desta seo, passaremos a concentrar-nos especificamente nas operaes de
recuperao.
Os ndices podem ser utilizados, essencialmente, de duas maneiras diferentes. Primeiro, podem
ser utilizados para o acesso seqencial ao rquivo indexado - onde "seqencial" significa "na
seqncia definida pelos valores do campo indexado". Por exemplo, o ndice CITY no exem-
plo acima permite que os registros no arquivo de fornecedores sejam processados na seqncia
de cidades. Segundo, os ndices tambm podem ser utilizados para acesso direto aos registros
individuais no arquivo indexado baseado num determinado valor do campo indexado. A
consulta "achar os fornecedores em Londres", discutida ilustra o segundo caso.
Os dois meios bsicos de utilizar um ndice podem ser delineados, simplesmente como:

l. Seqencial: O ndice tambm pode ser til nas consultas de limites - por exemplo, "Achar os
fornecedores cuja cidade se encontre em determinado limite do alfabeto" (isto , inicie-se com
a letra no limite L-R).

2. Direto: O ndice tambm pode ser til nas consultas de lista - por exemplo, "Achar os
fornecedores cuja cidade se encontre em certa lista especfica" (isto , a lista da cidade de
Londres, Paris e Nova York).
H, ainda, certas consultas - basicamente, testes de existncia - que podem ser respondidas
apenas pelo ndice, sem qualquer acesso ao arquivo indexado. Considere como exemplo a
consulta: "H fornecedores em Atenas?".
A resposta claramente "sim" se, e apenas se, existir uma entrada para Atenas no ndice
CITY.
Um determinado arquivo armazenado pode ter qualquer quantidade de ndices. Por exemplo, o
arquivo armazenado de fornecedores pode ter um ndice CITY e um ndice STATUS (Figura 7).
Estes ndices poderiam ento ser utilizados para proporcionarem acesso eficiente aos registros
de fornecedores na base de determinados valores para cada ou ambos os ndices CITY e
STATUS. Como um exemplo do caso "ambos", consideremos a consulta: "Achar os forne-
cedores em Paris com status 30". O ndice CITY fornece os RIDs - r2 e r3, digamos - para os
fornecedores de Paris; da mesma maneira, o ndice STATUS fornece os RIDs - r3 e r5, di-
gamos - para os fornecedores de status 30. Deduzimos desses dois conjuntos de RIDs que o
nico fornecedor que satisfaz a consulta original o fornecedor com RID igual a r3 (ou seja, o
fornecedor S3). Somente, ento, o DBMS acessa o arquivo de fornecedores em si, a fim de
recuperar o registro desejado.
FIGURA 7 Indexao de arquivo de fornecedores tanto em CITY como em STATUS

Mais terminologia: Denominam-se os ndices, eventualmente, de listas invertidas, pela

seguinte razo: Primeiro um arquivo normal o arquivo de fornecedores das figuras 6 e 7
considerado como o tpico arquivo normal lista, para cada registro, os valores de campo
naquele registro. Por outro lado, o ndice lista, para cada valor de campo indexado, os registros
que contm aquele valor. Mais um termo: Um arquivo com um ndice em cada campo de-
nominado, eventualmente, de completamente invertido.
Indexao de Combinaes de Campos
Tambm possvel construir um ndice baseado nos valores de dois ou mais campos
combinados. Por exemplo, a Fig. 7 mostra um ndice para o arquivo de fornecedores, combi-
nando os campos CITY e STATUS (nesta ordem). O DBMS, com tal ndice, pode responder
consulta discutida acima - "Achar os fornecedores de Paris com status 30" - numa simples
explorao de ndice nico. Se o ndice combinado for recolocado por dois ndices separados, a
consulta, ento, envolver duas exploraes separadas de ndice (como descrito). Ademais,
nesse caso talvez seja difcil decidir quais das duas exploraes deve ser efetuada em primeiro
lugar, uma vez que as duas seqncias possveis podem ter caractersticas muito diferentes em
desempenho, cuja escolha seria bastante significativa.
FIGURA 8 Indexao do arquivo de fornecedores na combinao de campo
CITY/STATUS

Observemos que o ndice combinado CITY/STATUS tambm pode servir como ndice
para o campo de CITY apenas, desde que todas as entradas para uma determinada cidade sejam
consecutivas dentro do ndice combinado. (Entretanto, um outro ndice separado dever ser fei-
to, caso seja necessria a indexao de STATUS.) Em geral, um ndice para a combinao de
campos FI, F2, F3 ..., Fn (nesta ordem) tambm servir como ndice de FI apenas, como ndice
das combinaes FlF2 (ou F2F1), como ndice da combinao FIF2F3 (em qualquer ordem), e
assim por diante. A quantidade total de ndices necessrios para a indexao, deste modo, no
to grande como pode parecer primeira vista.

15.1 INDEXAO DENSA VERSUS INDEXAO NO DENSA

Como mencionado em diversas ocasies, o propsito fundamental do ndice acelerar

a recuperao dos dados - mais especificamente, reduzir o nmero de entradas/sadas em disco
necessrias para a recuperao de determinado registro armazenado. Atinge-se, basicamente,
este propsito por meio de ponteiros; e a partir de agora assumimos que todos os ponteiros so
ponteiros de registro (ou seja, RID's). De fato seria suficiente para este propsito que estes
fossem simples ponteiros de pginas (isto , nmeros de pgina). Realmente, o sistema teria
um trabalho adicional para achar um registro numa determinada pgina, pois precisaria ex-
plorar atravs das pginas do armazenamento principal, embora a quantidade de en-
tradas/sadas permanecessem as mesmas.
Levemos a idia adiante. Lembremo-nos de que qualquer arquivo armazenado tem uma
nica seqncia "fsica", representada pela combinao de 1) seqncia de registros ar-
mazenados em cada pgina e 2) seqncia de pginas dentro do conjunto de pginas. Supon-
hamos que o arquivo de fornecedores seja armazenado tal como a seqncia fsica corresponde
seqncia lgica, como definido pelos valores de determinado campo, digamos o campo de
nmero de fornecedores; em outras palavras, o arquivo de fornecedores (Figura 9) agrupado
naquele campo. Suponhamos, tambm, que seja necessrio um ndice naquele campo. No h
necessidade de que aquele ndice inclua uma entrada para cada registro armazenado no arquivo
indexado (isto , o arquivo de fornecedores, no exemplo). 'Ido o que necessrio uma en-
trada para cada pgina, determinando o nmero mais alto de fornecedor na pgina e o nmero
correspondente da pgina.
Consideremes, como exemplo, o que necessrio para recuperar o fornecedor S3 uti-
lizando este ndice. O sistema primeiramente precisa explorar o ndice, procurando a primeira
entrada com o nmero de fornecedores superior ou igual a S3. O sistema acha a entrada in-
dexada para o fornecerdor S4, que aponta a pgina p (digamos), recupera-a e explora-a no
armazenamento principal, cata do desejado registro armazenado (que neste exemplo ser
encontrado rapidamente).
Um ndice, como o da Fig. 9, denominado no-denso, pois no contm uma entrada
para todo registro armazenado no arquivo indexado. (Todos os ndices at ento discutidos,
pelo contrrio, eram ndices densos.) Uma das vantagens do ndice no-denso que ocupar
menos armazenamento que o ndice denso correspondente, pela bvia razo de que contm
menos entradas. Em conseqncia, a explorao provavelmente ser mais rpida. Como des-
vantagem, no possibilitar o desempenho de testes de existncia com base no ndice apenas.

Figura 9 Exemplo de um ndice no-denso

 Observemos que um determinado arquivo armazenado no pode ter mais do que um
ndice no-denso, pois o mesmo baseia-se na (nica) seqncia fsica do arquivo em questo.
Todos os outros ndices, necessariamente, devem ser densos.

15.2 - rvores B

Um tipo de ndice particularmente comum e importante a rvore B. Embora seja

verdade (como j observado) de que no existe uma nica estrutura de armazenamento tima
para todas as aplicaes, no h dvidas de que, se necessrio escolher uma nica estrutura,
ento a rvore B, de uma variedade ou outra, ser escolhida. As rvores B parecem ter o melhor
desempenho. Assim, a maioria dos sistemas relacionais suportam as rvores B como a prin-
cipal forma de estrutura de armazenamento, e outros no suportam absolutamente nada, a no
ser estas. Antes que possamos explicar o que uma rvore B, precisamos discutir uma noo
preliminar, a saber, o ndice multinvel (ou estruturado em forma de rvore).
Providenciamos um ndice em primeiro lugar para remover a necessidade de explorao fsica
seqencial do arquivo indexado. Entretanto a explorao fsica seqencial ainda necessria
no ndice. Se o arquivo indexado for muito grande, ento o ndice tambm ter um tamanho
equivalente, e a explorao seqencial do ndice poder tomar muito tempo. A soluo para
este problema a mesma: ou seja, tratamos o ndice simplesmente como um arquivo ar-
mazenado/regular e construmos um ndice para o mesmo (um ndice para o ndice). Esta idia
pode ser colocada em prtica em tantos nveis quanto necessrio (em geral, trs nveis na
prtica); um arquivo teria de ser muito grande para necessitar de mais do que trs nveis de
indexao). Cada nvel de ndice atua como um ndice no-denso para o nvel inferior (deve ser
o no-denso, certamente, pois, de outra maneira, no se realizaria nada - o nvel n conteria o
mesmo nmero de entradas como o nvel n + 1, e o tempo de explorao permaneceria o
mesmo).
Agora podemos discutir a rvore B. A rvore B um tipo especial de ndice estruturado
na forma de rvore, como descrito num texto de Bayer e McCreight, em 1972 [3.10]. Desde
ento, diversas variaes foram propostas em relao idia bsica, por Bayer e outros pes-
quisadores; como mencionado, as rvores B, de um ou outro modo, so agora provavelmente a
estrutura de armazenamento mais utilizada nos sistemas modernos de banco de dados (rela-
cionais ou no). Descrevemos a variao realizada por Knuth [3.1]. Mencionamos que a
estrutura de ndice do "Mtodo de Acesso Virtual ao Armazenamento" VSAM da IBM [3.12]
muito similar estrutura de Knuth. Contudo a verso VSAM inclui caractersticas prprias,
como a utilizao de tcnicas (vide Seo 3.7). Na realidade, o precursor da estrutura VSAM j
fora descrito por Chang em 1969 [3.13].
Na variao Knuth, o ndice compe-se de duas partes, o conjunto de seqncias e o conjunto
de ndices (terminologia VSAM).
1. O conjunto de seqncias consiste em um ndice de nvel nico aos dados reais; em
geral, denso, mas pode ser no-denso, se o arquivo indexado for agrupado ao campo indexado.
As entradas no ndice so (certamente) agrupadas em pginas, e as pginas so (certamente)
encadeadas, de forma que a ordem lgica representada pelo ndice seja obtida atravs das en-
tradas em ordem fsica na primeira pgina da cadeia, seguida das entradas na ordem fsica na
segunda pgina da cadeia, e assim por diante. Desta maneira, o conjunto de seqncia pro-
porciona um rpido acesso seqencial aos dados indexados.

2. O conjunto de ndices, por sua vez, proporciona um rpido acesso direto ao conjunto
de seqncias (e, conseqentemente, aos dados). O conjunto de ndice , na realidade, um
ndice estruturado em forma de rvore B para o conjunto de seqncias; o conjunto de ndices
representa a rvore B. A combinao do conjunto de ndices e do conjunto de seqncias
denominado eventualmente, de "rvore B-plus" (rvore B+). O nvel superior do conjunto de
ndices consiste em um nico n (isto , uma nica pgina, mas contendo entradas mltiplas de

ndice, como todos os outros ns). O n superior denominado raiz. A Fig. 10 mostra um
exemplo simples. A Fig. 10 se exemplifica da seguinte forma: Os valores 6, 8, 12 ..., 97, 99 so
o campo indexado, digamos, F. Consideremos o n superior, que consiste em dois valores F
(50 e 82) trs ponteiros (nmeros de pgina). Os registros de dados com F menor ou igual a
50 podem ser achados (eventualmente) seguindo-se o ponteiro esquerdo a partir deste n; da
mesma forma, os registros com F, superiores a 50 e menores ou iguais a 82 podem ser achados
seguindo-se o ponteiro do meio; os registros com F superiores a 82 so achados seguindo-se o
ponteiro da direita. Os outros ns do conjunto de ndices so interpretados de forma anloga;
observemos que (por exemplo), ao seguirmos o ponteiro direito a partir do primeiro n ao
segundo nvel, chegamos a todos os registros com F superior a 32 e tambm inferior ou igual a
50 (em virtude do fato de j termos seguido o ponteiro esquerdo a partir do n superior).
Figura 10 Parte de uma rvore B simples

A rvore B (isto , o conjunto de ndices) da Fig. 10 um tanto fora da realidade, pelas se-
guintes razes:

1. Primeiro, nem todos os ns de uma rvore B contm o mesmo nmero de dados;

2. Segundo, os mesmos normalmente contm um certo espao livre. Em geral, uma rvore B da
ordem n tem ao menos n mas no mais do que 2n de valores de dados em qualquer n (e se o
mesmo tiver valores k, tambm tem k + 1 ponteiro). Nenhum valor de dados aparece na rvore
mais do que uma vez. Fornecemos o algoritmo de explorao para o valor especial V na
estrutura;

O algoritmo para a rvore B da ordem n uma simples generalizao.

set N to the root node ;

repeat until N is a sequence-set node ;
Let X, Y be the data values in node N l* X < Y *l ;
if V < = X then set N to the left lower node of N ; if X < V < = Y then set N to the middle lo wer
node of N ;
if V > Y then set N to the right lower node of N ; end repeat ;
if Voccurs in node Nthen exit /* found */ ;
if V does not occur in node N then exit /* not found */ ;

As estruturas de rvore em geral tm um problema, ou seja, tais inseres e eliminaes

podem causar o desbalanceamento da rvore. Uma rvore desbalanceada quando todas as
folhas de ns no se encontram no mesmo nvel - isto , se folhas diferentes de ndulos se
encontram em diferentes distncias do n da raiz. Como a pesquisa da rvore envolve um
acesso em disco para cada n,a pesquisa em rvore desbalanceada pode ter uma durao im-
previsvel. A grande vantagem as rvores B que o algoritmo de insero/eliminao da
mesma garante que a rvore estar sempre balanceada. (Diz-se que o "B" na designao "r-
vore B" significa balanceada por esta razo.) Vamos considerar brevemente a insero de
um novo valor, digamos V, na rvore de ordem n. O algoritmo como descrito suprime apenas o
conjunto de ndices, posto que, como explicado anteriormente, o conjunto de ndices a
prpria rvore B; para trabalhar com o conjunto de seqncias tambm necessria uma ex-
tenso simples.
 Primeiramente, o algoritmo de pesquisa foi executado para localizar no o n do conjunto de
seqncias, mas sim aquele n (digamos N) no nvel mais inferior do conjunto de ndices, ao
qual V pertence logicamente. Se N contiver espao livre, V ser inserido em N, e o processo se
encerra.

Caso contrrio, o n N (que dever conter valores 2n) ser fracionado em dois ns, N1 e N2.
S constitui o conjunto ordenado composto de valores originais 2n, mais o novo valor V, em
seqncia lgica.
Os valores n mais baixos do conjunto S sero colocados no n esquerdo N1, os valores
n mais elevados daquele conjunto sero colocados no n direito N2, e o valor mdio, digamos
W, ser deslocado para o n-fonte de N, digamos P, a fim de servir como valor separador dos
ns N1 e N2. As futuras buscas de valor V', ao alcanarem o n P, sero direcionadas ao n N1,
se V' < = W, e para o n N2, se W < V'.

Tenta-se, agora, inserir W em P, e o processo se repete.

No pior dos casos, ocorrer um fracionamento at o topo da rvore; ser citado um novo
n raiz (fonte da antiga raiz que agora estar fracionada em duas; e a rvore crescer mais um
nvel de altura (mas, mesmo assim, continuar balanceada).
O algoritmo de eliminao essencialmente o inverso do algoritmo de insero acima descrito.
A modificao de um valor tratada pela eliminao do antigo valor e pela insero do novo
valor.

15.3- ACESSO HASH

O acesso hash (tambm denominado endereamento-hash) a tcnica que proporciona

um rpido acesso direto ao registro armazenado, baseado num determinado valor de um certo
campo. O campo em questo , em geral, mas no necessariamente, a chave primria. Esta
tcnica funciona como segue:

Cada registro armazenado colocado no banco de dados em uma localizao, cujo

endereo (RID, ou talvez apenas um nmero de pgina) computado como funo (a funo
hash) de algum campo daquele registro (o campo hash). O endereo computado denominado
endereo hash.
 Para armazenar o registro, inicialmente o DBMS computa o endereo hash para o
novo registro e instrui o gerenciador de arquvo no sentido de colocar o regstro naquela
poso.
Para recuperar o registro posteriormente, dado o valor do campo hash, o DBMS de-
sempenha a mesma computao anterior, e instrui o gerenciador de arquivo no sentido de
buscar o registro na posio computada.
Suponhamos, a ttulo de ilustrao, que 1) os valores dos nmeros de fornecedores
sejam 5100, S200, S300, S400, S500 (ao invs de Sl, S2, S3, S4 e SS) e, 2) cada registro de
fornecedor armazenado necessite de uma pgina inteira, e consideremos a funo hash:
endereamento hash (i.e. nmero de pgina) =restante da diviso da parte numrica do valor S
# por 13
- exemplo simples de um tipo muito comum da funo hash, denominado "diviso/restante".
(Por motivos que fogem ao escopo deste manual, escolhe-se um nmero primo como divisor de
uma diviso/restante hash, usualmente, como em nosso exemplo). Os nmeros de pginas para
os cinco fornecedores so, ento, 9, 5, 1, 10, 6, respectivamente, dando-nos a representao na
figura 11.
Deve ter ficado claro, pela descrio anterior, que o acesso hash difere da indexao,
uma vez que um determinado arquivo armazenado pode ter qualquer quantidade de ndices,
mas s pode ter uma estrutura hash.
Dizendo de outra forma: Um arquivo pode ter qualquer quantidade de campos in-
dexados, mas somente um campo hash.
Alm de mostrar como trabalha o acesso hash, o exemplo tambm demonstra porque a
funo hash necessria. Teoricamente seria possvel usar uma funo hash "identidade". Isto
, usar o valor (numrico) da chave primria para qualquer registro armazenado, diretamente
como o endereo hash. Contudo tal tcnica normalmente ser inadequada na prtica, porque a
margem de valores de chave primria possveis ser, em geral, mais ampla do que a margem de
endereos disponveis. Suponhamos, por exemplo, que os nmeros de fornecedores tenham, de
fato, trs dgitos a mais, como no exemplo acima. Haveria ento 1000 possibilidades de
nmeros distintos de fornecedores, enquanto, de fato, existiriam apenas cerca de 10 fornece-
dores. Assim, para evitar uma perda considervel de espao de armazenamento, o ideal seria
descobrir uma funo hash que reduza qualquer valor da faixa de 000-999 para a faixa 0-9
(digamos). Para permitir um pouco de espao para o crescimento futuro, normal que se au-
mente a margem em cerca de 20 por cento; foi por isto que escolhemos uma funo que gera
valores na faixa de 0-12, e no 0-9, como no exemplo acima.
O exemplo tambm ilustra uma das desvantagens do acesso hash: A "seqncia fsica"
de registros no arquivo armazenado no ser certamente a seqncia da chave primria, nem
qualquer outra que tenha qualquer interpretao lgica sensvel. (Ademais, pode haver espaos
vazios de tamanhos arbitrrios entre os registros consecutivos.) De fato, em geral a seqncia
fsica de um arquivo armazenado com estrutura hash (no invariavelmente) tida como
no-representativa de seqncia lgica especfica,b assim, via de regra, arquivo de acesso hash
no tem nenhum agrupamento intra-arquivo - o que de se lamentar, j que o agrupamento
fsico, como mencionado neste captulo, quase sempre seria do maior interesse.

Figura 11 Exemplo de uma estrutura Hash

Uma outra desvantagem do acesso hash a possibilidade de colises - isto , de achar dois
registros distintos que indiquem o mesmo endereo. Suponhamos, por exemplo, que o arquivo
de fornecedores (com os fornecedores S100, S200 etc.) tambm inclua um fornecedorcom
nmero de fornecedor S1400. Dada a funo hash "dividir por 13" discutida acima, aquele
fornecedor colidiria (no endereo hash 9) com o fornecedor S 100.
A funo hash, como o exemplo demonstra, inadequada; el deve ser aprofundada na
sentido de lidar com o problema de coliso.
Em nosso exemplo original, uma possibilidade seria tratar o restante da diviso por 13,
no como um endereo hash em si, mais como ponto de partida para uma busca seqencial.
Para inserir o fornecedor S1400 (supondo que j existam os fornecedores S100-S500), vamos
pgina 9 e buscamos frente, a partir desta posio, a primeira pgina livre.
O novo fornecedor ser armazenado na pgina 11. Para depois recuperar este forne-
cedor, usaremos um processo similar. Este mtodo de busca linear ser adequado se (como em
geral ocorre na prtica) os registros mltiplos estiverem armazenados em todas as pginas.
Suponhamos que cada pgina possa conter n registros armazenados. Ento, as primeiras
colises n em dado endereo hash p sero armazenadas na pgina p e uma busca linear atravs
dessas colises estar totalmente contida nesta pgina. Entretanto a prxima coliso - isto , a
de nmero (n + 1) - dever ser armazenada em pgina extra, e ser necessria outra E/S.
Uma outra abordagem ao problema da coliso, talvez mais encontrada na prtica, seria
de tratar o resultado a partir da funo hash, digamos a, como endereo de armazenamento, no
do registro de dados, mas do "ponto ncora". O ponto ncora no endereo de armazenamento a
ento considerado a cabea de uma cadeia de ponteiros (uma cadeia de colises), unindo
todos os registros - ou todas as pginas de registros - que colidem em a. As colises dentro de
uma determinada cadeia de colises sero mantidas em uma seqncia de campo hash, a fim de
simplificarem as buscas subseqentes.

Acesso Hash Extensvel

Uma outra desvantagem, alm daquela descrita acima, a seguinte: como o tamanho do
arquivo de acesso hash cresce, o nmero de colises tambm tende a crescer e, conseqente-
mente, o tempo de acesso mdio aumenta de modo correspondente (porque se gasta cada vez
mais tempo na busca atravs dos conjuntos de colises). O acesso hash extensvel uma
variao interessante da tcnica bsica, qu minoriza este problema. O acesso hash extensvel,
de fato, garante que a quantidade necessria de acessos em disco para localizar um registro
especfico (isto , o registro com o valor especfico da chave primria) nunca ser maior do que
duas e, normalmente, de apenas uma.
Obs.: Os valores do campo hash devem ser nicos no esquema de acesso hash exten-
svel, onde se encontraro naturalmente, se aquele campo for, de fato, a chave primria, como
sugerido no incio desta seo.
O esquema funciona como segue.

1. A funo hash bsica h, e o valor da chave primria de um registro especfico r k. O

acesso hash a k - isto , avaliando-se h(k).
- produz um valor k', denominado de pseudochave de r. As pseudochaves no so interpretadas
diretamente como endereos; ao contrrio, elas conduzem aos locais de armazenamento de um
modo indireto, como descrito abaixo.

2. O arquivo armazenado tem um diretrio associado ao mesmo, tambm, armazenado no disco.

O diretrio consiste em um cabealho, que contm um valor d, denominado profundidade do
diretrio, em conjunto com 2 ponteiros, que so ponteiros para as pginas de dados, que
contm os registros armazenados reais (registros mltiplos por pgina). Um diretrio de pro-
fundidade d, portanto, pode manejar um tamanho mximo de arquivo de 2d de pginas de
dados distintas.

3. Se consideramos os bits-guia d de uma pseudochave como um inteiro binrio sem sinal

algbrico b, ento o ponteiro de nmero i no diretrio (1 < = i < = 2~ indica a pgina que
contm todos os registros para os quais b toma o valor i - 1. Em outras palavras, o primeiro
ponteiro indica a pgina que contm todos os registros para os quais b apenas zero, o segundo
ponteiro indica a pgina onde b 0 ... Ol, e assim por diante. (Esses 2d ponteiros so todos
distintos, ou seja, existiro menos do que 2d pginas de dados distintos. Vide Fig. 12.) Deste
modo, para que possamos achar o registro que tenha o valor k da chave primria, achamos k via
acesso hash para descobrir a pseudochave K' e tirar os primeiros bits d da pseudochave; se
esses bits tiverem o valor numrico i - 1, vamos at o ponteiro de n i no diretrio (primeiro
acesso em disco) e o seguimos at a pgina que contm o registro desejado (segundo acesso em
disco).
Obs.: O diretrio ser, na prtica, pequeno o suficiente para ser mantido no armazenamento
principal durante a maior parte de tempo, de modo que os "dois" acessos em disco sero
normalmente reduzidos a um s na prtica.

4. Cada pgina de dados tambm tem um cabealho, indicando a profundidade do local p da

mesma (p < = d). Suponhamos, por exemplo, que d seja trs e que o primeiro ponteiro no di-
retrio (o ponteiro 000) aponte para a pgina onde a profundidade local p seja dois. A profun-
didade local dois significa, neste caso, que esta pgina no s contm todos os registros com
pseudochaves iniciando em 000, mas que a mesma tambm contm todos os registros com
pseudochaves iniciando em 00 (i.e., aqueles que iniciam com 000 e tambm aqueles que ini-
ciam com 001). Em outras palavras, o ponteiro do diretrio 001 tambm aponta para est
pgina. Vide, novamente, a Fig. 12

5. Suponhamos, em continuao ao exemplo em (3), que a pgina de dados 000 est cheia, e
que desejamos inserir um novo registro com uma pseudochave que se inicia em 000 (ou 001).
Neste ponto, a pgina ser fracionada em duas; ou seja, adquire-se uma pgina nova e vazia, e
todos os registros 001 so removidos da pgina antiga para a nova. O ponteiro 001 no diretrio
ser modificado para apontar a nova pgina (o ponteiro 000 continua para a pgina antiga). A
profundidade local p para cada uma das duas pginas ser agora trs, e no mais dois.

6. Continuando o nosso exemplo, suponhamos que a pgina de dados 000 esteja novamente
cheia e tenha que ser fracionada. O diretrio existente no pode manipular tal fracionamento,
porque a profundidade local da pgina a ser fracionada j igual profundidade do diretrio.
Assim, "dobramos o diretrio"; ou seja, aumentamos d por um e substtumos cada pontero por
um par de ponteiros adjacentes idntcos. A pgna de dados agora pode ser fracionada; os
regstros 0000 continuam na pgina anterior, e os registros 0001 vo para a nova pgina; o
primeiro ponteiro no diretrio permanece inalterado (i.e., continua a apontar para a pgina
anterior), o segundo ponteiro modificado, a fim de apontar para a nova pgina. Observemos
que a duplicao do diretrio uma operao barata, pois no necessita de acesso s pginas de
dados.

15.4 CADEIAS DE PONTEIROS

Suponhamos, novamente, que a consulta "Achar todos os fornecedores na Cidade C"

seja importante. Uma outra representao armazenada que pode tratar razoavelmente bem esta
consulta - possivelmente melhor do que um ndice, embora de forma marginal - utiliza cadeias
de ponteiros. Esta representao ilustrada na Fig. 3.17. Como se pode ver, a mesma envolve
dois arquivos armazenados, um arquivo de fornecedores e um arquivo de cidades, quase igual
representao do ndice na Fig. 13 (desta vez ambos os arquivos encontram-se, provavelmente,
no mesmo conjunto de pginas. Na representao de cadeias de ponteiros da Fig. 13, o arquivo
de cidades, contudo, no um ndice, mas sim um arquivo-"pai" (ou fonte), como o mesmo
denominado. O arquivo de fornecedores denominado conseqen
temente de arquivo-"filho", e a estrutura em si um exemplo de uma "organizao pai/filho".
A estrutura pai/filho, no exemplo, baseia-se em valores de cidades de fornecedor. O
arquivo-pai (cidade) contm um registro armazenado para cada cidade de fornecedor distinta,
indicando o valor de cidade e atuando como o cabea da cadeia ou anel de ponteiros que liga
todos os registros-filho (fornecedores) aos fornecedores naquela cidade. Observemos que o
campo cidade como tal foi removido do arquivo de fornecedores. O DBMS, para achar todos
os fornecedores em Londres (digamos), pode pesquisar o arquivo de cidades pela entrada de
Londres e, ento, seguir a correspondente cadeia de ponteiros.

FIGURA 13 Exemplo de uma estrutura pai/filho

A principal vantagem da estrutura pai/filho (cadeia de ponteiros) que os algoritmos

inserir/anular so mais simples, e podemos ver que mais eficientes do que os algoritmos cor-
respondentes para ndice. Assim, a estrutura, provavelmente, deve ocupar menos armazena-
mento do que a estrutura de ndices correspondente, porque cada valor da cidade aparece
exatamente uma vez, e no de forma mltipla. As principais desvantagens so as seguintes:
A nica maneira de acessar o fornecedor de nmero n de uma determinada cidade seguir a
cadeia e acessar o I, 2, ..., (n - 1) fornecedor tambm. Se os registros de fornecedor no forem
agrupados de forma adequada, cada acesso envolvendo uma operao de pesquisa, o tempo que
se gasta para acessar o fornecedor de nmero n pode ser bastante considervel.

Embora a estrutura possa ser adequada para a consulta "Achar os fornecedores de uma de-
terminada cidade", a mesma no de nenhum auxlio - de fato, um obstculo - quanto se trata
da consulta oposta "Achar a cidade de determinado fornecedor" (onde o fornecedor determi-
nado identificado por um nmero de fornecedor determinado). Para a ltima consulta, nem o
acesso hash, nem um ndice no arquivo de fornecedores bastar; observemos que uma estrutura
pai/filho, com base nos nmeros dos fonecedores no faria muito sentido (por que no?). E
mesmo se o registro do dado fornecedor fosse localizado, ainda assim seria necessrio se-
guir-se a cadeia at o registro-pai para descobrir a cidade desejada (a necessidade deste passo
adicional a nossa justificativa para reivindicar que a estrutura pai/filho um obstculo para
esta classe de consultas).
Observemos, ainda, que o arquivo-pai (cidade) necessitar tambm de um acesso hash ou um
ndice, se o mesmo for de um tamanho expressivo. Conseqentemente, as cadeias de ponteiros
sozinhas no so, na realidade, uma base adequada para uma estrutura de armazenamento -
outros mecanismos, tais como ndices, tambm sero necessrios.
Criar uma estrutura pai/filho para um conjunto existente de registros uma tarefa in-
comum porque as cadeias de ponteiros passam atravs dos registros armazenados (isto , os
prefixos dos registros incluem fisicamente os ponteiros relevantes) e, tambm, porque os
valores do campo relevante so decompostos para fora dos registros-filho e colocados, ao
contrrio, nos registros-pai. De fato, tal operao necessitar de uma organizao do banco de
dados,pelo menos para a parte relevante do mesmo.
 A criao de um novo ndice para um conjunto existente de registros, ao contrrio, seria
um quesito mais direto. (A criao de um novo acesso hash tambm implicar reorganizao.)

A estrutura pai-filho bsica possibilita diversas variveis. Por exemplo:

Os ponteiros podem ser feitos em sentido duplo. A vantagem que tal varivel simplifica o
ajuste de ponteiro necessrio para a operao de anulao de um registro-filho.
Uma outra ampliao seria a incluso de um ponteiro (um "ponteiro-pai" de cada regis-
tro-filho para o pai correspondente); isto reduziria quantidade de passagens na cadeia que so
necessrias para se responder consulta "Achar a cidade para determinado fornecedor" (ob-
servemos, entretanto, que esta ampliao no afeta a necessidade de um acesso hash ou ndice
para auxiliar na resposta consulta).
Uma outra varivel seria no remover o campo do arquivo de fornecedores, mas repetir o
campo nos registros de fornecedores; certas possibilidades de recuperao (por exemplo,
"Achar a cidade do fornecedor S4") torna-se-iam mais eficientes. Observemos, porm, que o
aumento da eficincia no tem nada a ver com a estrutura da cadeia de ponteiros em si - e que
ainda ser provavelmente necessrio um acesso hash ou ndice nos nmeros de fornecedores.
Finalmente, assim como possvel ter quaisquer quantidades de ndices em um de-
terminado arquivo armazenado, tambm possvel ter quaisquer quantidades de cadeias de
ponteiros em determinado arquivo armazenado. (Ambos tambm so possveis, embora in-
comuns na prtica.) A Fig. 14 mostra uma representao de um arquivo de fornecedores que
envolve duas cadeias de ponteiros distintas e, assim, duas estruturas-pai/filho distintas, uma
com o arquivo de cidade como pai (como na Fig. 13) e uma com o arquivo de status como pai.
O arquivo de fornecedores o arquivo-filho para ambas as estruturas.
FIGURA 14 Exemplo de uma organizao pai/filho

Texto gentilmente cedido por Marcos Mina Kamada (kamada@rio.com.br)

www.sti.com.br