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 2 3 6 11 12 16 21 22 25 30 43 50 51 64 72 WINE Chardonnay Chardonnay Chardonnay Jo.. Riesling Jo. Riesling Jo. Riesling Fume Blanc Fume Blanc Wh. Burgundy PRODUCER Buena Vista Louis Martini Chappellet lekel Buena Vista Sattui Ch. St. Jean Robt. Mondavi Mirassou YEAR 83 81 82 84 82 82 79 78 80 80 77 77 78 77 78 BOTTLES 1 5 4 10 1 1 4 2 6 3 12 3 2 9 2 READY COMMENTS 85 84 85 86 83 83 83 82 82 82 87 85 86 86 83 Anniversary Harvest Late Harvest very dry Napa Valley Thanksgiving

Gewurztraminer Buena Vista Cab. Sauvignon Robt. Mondavi Pinot Noir Pinot Noir Zinfandel Gamay Mirassou Ch. St. Jean Mirassou Robt. Mondavi

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 Chardonnay Chardonnay Pinot Noir BIN 2 6 50 PRODUCER Buena Vista Chappellet 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). A SQL (pronunciada normalmente como "sequel") a linguagem suportada pelos produtos de banco de dados da IBM,DB2, SQL/DS e QMF, assim como por inmeros produtos de banco de dados de outros fabricantes. 2 - O QUE UM SISTEMA DE BANCO DE DADOS? O sistema de banco de dados basicamente um sistema de manuteno de registros por computador,ou seja, um sistema cujo objetivo global manter as informaes e torn-las disponveis quando solicitadas. Trata-se de qualquer informao considera-da como 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 Exemplo dos trs nveis

 O banco de dados contm, no nvel conceitual, informaes referentes ao tipo de entidade chamada EMPLOYEE. Cada EMPLOYEE tem um EMPLOYEE_NUMBER (seis caracteres), um DEPARTMENT NUMBER (quatro caracteres) e um SALARY (cinco dgitos decimais). Os funcionrios esto representados, no nvel interno, por um tipo de registro armazenado chamado STORED EMP, com dezoito bytes de comprimento. O STORED_EMP contm quatro tipos de campos armazenados: um prefixo de seis bytes (contendo, provavelmente, informaes de controle como sinalizadores ou ponteiros, e trs campos de dados 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 no-especficos de banco de dados, tais como variveis locais (temporrias), operaes computacionais, lgica if-then-else e assim por diante. Um determinado sistema pode suportar mltiplas linguagens hospedeiras e mltiplas sublinguagens de dados.

FIGURA 5 Sistema de Arquitetura detalhado Observao: Embora seja conveniente diferenciar, na arquitetura, a sublinguagem de dados e linguagem hospedeira, as duas, em relao ao usurio, podem ser indistinguveis. Se assim for, ou se s puderem ser separadas com dificuldades, dizemos que so "unidades de maneira firme". Se as linguagens so fceis e claramente separadas, dizemos que so "unidas de maneira indefinida". A maioria dos sistemas de hoje suporta apenas a unio indefinida. Um sistema firmemente unido propiciar um conjunto de recursos mais uniforme para o usurio, mas obviamente requer maior esforo por parte dos projetistas do sistema (o que poderia 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. 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. A consulta "achar os fornecedores em Londres", discutida ilustra o

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) seguindo-se o ponteiro esquerdo a partir deste n; da mesma forma, os registros com F, superiores a 50 e menores ou iguais a 82 podem ser achados seguindo-se o ponteiro do meio; os registros com F superiores a 82 so achados seguindo-se o ponteiro da direita. Os outros ns do conjunto de ndices so interpretados de forma anloga; observemos que (por exemplo), ao seguirmos o ponteiro direito a partir do primeiro n ao segundo nvel, chegamos a todos os registros com F superior a 32 e tambm inferior ou igual a 50 (em virtude do fato de j termos seguido o ponteiro esquerdo a partir do n superior).
Figura 10 Parte de uma rvore B simples

A rvore B (isto , o conjunto de ndices) da Fig. 10 um tanto fora da realidade, pelas 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 aparece na rvore mais do que uma vez. Fornecemos o algoritmo de explorao para o valor especial V na estrutura; O algoritmo para a rvore B da ordem n uma simples generalizao. set N to the root node ; repeat until N is a sequence-set node ; Let X, Y be the data values in node N l* X < Y *l ; if V < = X then set N to the left lower node of N ; if X < V < = Y then set N to the middle lo wer node of N ; if V > Y then set N to the right lower node of N ; end repeat ; if Voccurs in node Nthen exit /* found */ ; if V does not occur in node N then exit /* not found */ ; As estruturas de rvore em geral tm um problema, ou seja, tais inseres e eliminaes podem causar o desbalanceamento da rvore. Uma rvore desbalanceada quando todas as folhas de ns no se encontram no mesmo nvel - isto , se folhas diferentes de ndulos se encontram em diferentes distncias do n da raiz. Como a pesquisa da rvore envolve um acesso em disco para cada n,a pesquisa em rvore desbalanceada pode ter uma durao 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, 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