Escolar Documentos
Profissional Documentos
Cultura Documentos
Banco de Dados Relacionais
Banco de Dados Relacionais
- 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 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.
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.
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 sub-
conjunto do banco de dados, as vises do mesmo podem diferir consideravelmente a nvel
dos detalhes.
Hardware
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:
fbricas;
bancos;
hospitais;
universidades;
departamentos governamentais.
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:
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).
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 siste-
mas 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.
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.
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.
A arquitetura divide-se em trs nveis gerais: interno, conceitual e externo (Figura 3). Em
termos amplos:
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.
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:
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.
6 - O NVEL EXTERNO
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 supor-
tar mltiplas linguagens hospedeiras e mltiplas sublinguagens de dados.
FIGURA 5 Sistema de Arquitetura detalhado
9 - O NVEL CONCEITUAL
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 defi-
nio 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
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.
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 corresponden-
te existiro no s na forma-fonte como na forma objeto.
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).
1. O usurio emite uma solicitao de acesso, usando uma sublinguagem especfica de dados
(por exemplo, SQL).
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.
15.2 - rvores B
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'.
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 exten-
svel 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.
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.
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.)