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 arquivo 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
arquivos existentes;
- A recuperao de dados dos arquivos existentes; A atualizao de dados nos arquivos
existentes; 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

Chardonnay

Buena Vista

83

85

Chardonnay

Louis Martini

81

84

Chardonnay

Chappellet

82

85

Thanksgiving

11

Jo.. Riesling

lekel

12

Jo. Riesling

Buena Vista

82

83

Late Harvest

16

Jo. Riesling

Sattui

82

83

very dry

21

Fume Blanc

Ch. St. Jean

79

83

Napa Valley

22

Fume Blanc

Robt. Mondavi

78

82

Mirassou

80

82

25 Wh. Burgundy

YEAR

84

BOTTLES

10

READY COMMENTS

86

30

Gewurztraminer Buena Vista

80

82

43

Cab. Sauvignon Robt. Mondavi

77

12

87

50

Pinot Noir

Mirassou

77

85

51

Pinot Noir

Ch. St. Jean

78

86

64

Zinfandel

Mirassou

77

72

Gamay

Robt. Mondavi

78

86

Harvest
Anniversary

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
recuperao.
Resultado (impresso ou na tela):
WINE

BIN

PRODUCER

Chardonnay

Buena Vista

Chardonnay

Chappellet

Pinot Noir

50

Mirassou

Alguns outros exemplos de operaes no arquivo CELLAR que, na sua maioria, so autoexplicativas. 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
registro . 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).

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
significativa ao indivduo ou organizao servida pelo sistema - em outras palavras, que
seja necessria 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
componentes 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
proporcionados 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
particular, 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 individual 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 sistema 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,
representam 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 pequenos, 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 unificao 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 incluir esta informao, redundante, nos registros de
INSCRIO, uma vez que ela ser encontrada 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 subconjunto 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
entrada/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),
insero 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 comandos 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 consulta de banco de dados.
Observao: Muitos sistemas tambm proporcionam interfaces
embutidas adicionais, nas quais os usurios no precisam emitir expressamente os comandos,
como SELECT; operam (por exemplo) escolhendo itens do menu ou preenchendo-os em
formulrios. Tais interfaces acionadas 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 programa 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 interfaces.

A terceira

classe de usurios o administrador 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
sistemas 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
indivduo (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.
Exemplos 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
empresas 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
puramente 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
transitrias.
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
informaes 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
interligando-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 funcionrio 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
representadas no banco de dados. Consideremos mais frente as diversas maneiras de fazlo.
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
necessariamente 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 equivalente 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
explicitamente, se conhecemos b), c) e d), podemos deduzir que Smith fornece chavesinglesas 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 relacionamento " 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
depende, 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
arquivamento. 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 particulares - 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
aplicao de registros de educao podem ter, ambas, um arquivo contendo informaes do
departamento 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.
Algumas 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 atualizaes" (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 inconsistente capaz de fornecer informaes incorretas ao usurio.
Se o fato mencionado estiver representado por uma nica entrada (isto , se a
redundncia

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
compartilhar os dados do banco de dados, mas tambm que novas aplicaes podem ser
desenvolvidas para operar sobre os mesmos dados armazenados. Em outras palavras, as
necessidades 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
empreendido 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 atualizao. (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
particulares", 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
representao 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
conceito 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
precisamente 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
nveis

Exemplo dos trs

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 correspondendo 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 #
(novamente) 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
armazenado 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
determinada 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
certamente 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
convencional 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 noespecficos 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 explicar o que temos hoje). Entretanto, parece haver um movimento que,
gradualmente, nos levar 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
possibilita 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 aspectos de PL/I utilizados para a comunicao com o DBMS. A parte DDL
consiste nas construes 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 especiais 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
determinado 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
fornecedores e peas vistas pelos usurios do Departamento de Compras). Portanto, uma
viso externa 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 "registro lgico" refere-se a um registro externo.
Cada viso externa definida por meio de um esquema externo, que consiste,
basicamente, 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
funcionrio, por exemp]o, pode ser definido como um campo de seis caracteres, nmero do

funcionrio, 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
fornecedores 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
linguagem 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 registros 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
distante 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
endereamento 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 integridade (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 linguagem 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
arquitetura, 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
representados 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
conceitual/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
seguinte:

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
informao 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 solicitaes 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
disponibilidade 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

considerados parte do esquema conceitual. A DDL conceitual incluir os recursos para a
especificao 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 descarregamento peridico do banco de dados na memria auxiliar de armazenamento
e procedimentos 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,
evidentemente, 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
armazenamento 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 exemplo, 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
mencionadas). 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 dicionrio 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, recuperar 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,
desempenho 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
proporciona 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
solicitaes 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 efetuadas 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,
costumamos consider-los parceiros de mesmo nvel no exerccio denominado banco de
dados/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 cidades (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 ponteiro 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
fornecedores; 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
explicitamente 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 eficiente baseada no valor do campo em questo ou a perda em atualizao, em
funo da recuperao 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 exemplo 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
fornecedores 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, digamos - 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 denominado, 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,
combinando 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 feito, 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 explorar atravs das pginas do armazenamento principal, embora a
quantidade de entradas/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
armazenados em cada pgina e 2) seqncia de pginas dentro do conjunto de pginas.
Suponhamos 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 entrada 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
utilizando 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 indexada 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
desvantagem, 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
principal 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 armazenado/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 pesquisadores; 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 (relacionais 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 entradas 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 proporciona 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) seguindose 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

seguintes 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 apa rece 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
imprevisvel. 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
"rvore 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
extenso 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
desempenha 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
indexados, 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 fornecedores. 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 aumente 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 S100S500), 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
fornecedor, 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,
conseqentemente, 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
extensvel, 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 profundidade 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
diretrio (o ponteiro 000) aponte para a pgina onde a profundidade local p seja dois. A
profundidade 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 iniciam 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,
Figura 12
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
correspondentes para ndice. Assim, a estrutura, provavelmente, deve ocupar menos
armazenamento 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
determinada 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
determinado 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 seguir-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
incomum 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 registrofilho para o pai correspondente); isto reduziria quantidade de passagens na cadeia que so
necessrias para se responder consulta "Achar a cidade para determinado fornecedor"
(observemos, 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
determinado arquivo armazenado, tambm possvel ter quaisquer quantidades de cadeias de
ponteiros em determinado arquivo armazenado. (Ambos tambm so possveis, embora
incomuns 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