CAPTULO 2Arquitetura de sistemas de bancos de dados 2.1 INTRODUO Agora temos condies de apresentar uma arquitetura para um sistema de bancos de dados. Nosso objetivo ao apresentar essa arquitetura fornecer um arcabouo sobre o qual possamos desenvolver os captulos subseqentes. Esse arcabouo til para descrever conceitos gerais de bancos de dados e explicar a estrutura de sistemas de bancos de dados especficos mas no afirmamos que todo sistema pode se enquadrar bem nesse arcabouo em particular, nem queremos sugerir que essa arquitetura prev o nico arcabouo possvel. Em especial, provvel que sistemas pequenos (ver Captulo 1) no ofeream suporte para todos os aspectos da arquitetura. Porm, a arquitetura em questo de fato parece se ajustar razoavelmente bem maior parte dos sistemas; alm disso, ela basicamente idntica arquitetura proposta pelo ANSI/SPARC Study Group on Data Base Management Systems (a chamada arquitetura ANSI/SPARC consulte as referncias [2.1-2.2]). Contudo, optamos por no seguir a terminologia ANSI/SPARC em todos os detalhes. Nota: este captulo lembra o Captulo 1 no sentido de que, embora a compreenso do material que ele contm seja essencial para uma apreciao completa da estrutura e dos recursos dos sistemas de bancos de dados modernos, ele mais uma vez um tanto abstrato e enxuto. Por esse motivo, como ocorre com o Captulo 1, talvez voc prefira por enquanto fazer apenas uma rpida leitura no material e voltar a ele mais tarde, medida que se tornar mais diretamente relevante para os tpicos em estudo. 2.2 OS TRS NVEIS DA ARQUITETURA A arquitetura ANSI/SPARC se divide em trs nveis, conhecidos como nvel interno, nvel conceitual e nvel externo, respectivamente (ver Figura 2.1). De modo geral: O nvel interno (tambm conhecido como nvel fsico) o mais prximo do meio de armazenamento fsico ou seja, aquele que se ocupa do modo como os dados so fisicamente armazenados. O nvel externo (tambm conhecido como nvel lgico do usurio) o mais prximo dos usurios ou seja, aquele que se ocupa do modo como os dados so vistos por usurios individuais. O nvel conceitual (tambm conhecido como nvel lgico comunitrio, ou s vezes apenas nvel indireto, sem qualificao) um nvel de simulao entre os outros dois. Observe que o nvel externo se preocupa com as percepes dos usurios individuais, enquanto o nvel conceitual est preocupado com uma percepo da comunidade de usurios. Em outras palavras, haver muitas vises externas distintas, cada qual consistindo em uma representao mais ou menos 28

abstrata de alguma parte do banco de dados completo, e haver exatamente uma viso conceitual,

consistindo em uma representao analogamente abstrata do banco de dados em sua totalidade.* (Lembre-se de que a maioria dos usurios no estar interessada em todo o banco de dados, mas somente em alguma poro restrita do banco de dados.) Do mesmo modo, haver precisamente uma viso interna, representando o modo como o banco de dados est fisicamente armazenado. Nvel externo (vises de usurios individuais) Nvel conceitual (viso da comunidade de usurios) Nvel externo (viso do meio de armazenamento) FIGURA 2. 1 Os trs nveis da arquitetura Um exemplo ajudar a esclarecer essas idias. A Figura 2.2 mostra a viso conceitual, a viso interna correspondente e duas vises externas correspondentes (uma para um usurio PL/I e outra para um usurio COBOL), todas para um simples banco de dados de pessoal. claro que o exemplo inteiramente hipottico ele no pretende se assemelhar a qualquer sistema real e muitos detalhes irrelevantes foram deliberadamente omitidos. Explicao: No nvel conceitual, o banco de dados contm informaes relativas a um tipo de entidade chamada EMPREGADO. Cada empregado individual tem um NUMERO_EMPREGADO (seis caracteres), um NUMERO_DEPARTAMENTO (quatro caracteres) e um SALARIO (cinco dgitos decimais). No nvel interno, os empregados so representados por um tipo de registro armazenado, denominado EMP_ARMAZENADO, com vinte bytes de comprimento. EMP_ARMAZENADO contm quatro campos armazenados: um prefixo de seis bytes (presumivelmente contendo informaes de controle, tais como flags ou ponteiros) e trs campos de dados correspondentes s trs propriedades de empregados. Alm disso, os registros EMP_ARMAZENADO so indexados sobre o campo EMP# por um ndice chamado EMPX, cuja definio no mostrada. O usurio PL/I tem uma viso externa do banco de dados na qual cada empregado representado por um registro PL/I que contm dois campos (nmeros de departamentos no so de interesse para esse usurio, e por isso foram omitidos da viso). O tipo de registro definido por uma declarao de estrutura PL/I comum, de acordo com as regras normais de PL/I. De modo semelhante, o usurio COBOL tem uma viso externa em que cada empregado representado por um registro COBOL contendo, mais uma vez, dois campos (agora, foram omitidos os salrios). O tipo de registro definido por uma descrio comum de registro COBOL, de acordo com as regras normais do COBOL. Observe que itens de dados correspondentes podem ter nomes diferentes em pontos diferentes. Por exemplo, a referncia ao nmero do empregado chamada EMP# na viso externa de PL/I, EMPNO na viso externa COBOL, NUMERO EMPREGADO na viso conceitual e novamente EMP# na viso interna. claro que o sistema deve estar ciente das correspondncias; por exemplo, ele tem de ser informado de que o campo EMPNO do COBOL derivado do campo conceitual Por abstrata, queremos dizer nesse caso apenas que a representao em questo envolve construes como registros e campos, mais orientadas para o usurio, em oposio a construes como bits e bytes, mais orientadas para a mquina.

29

NMERO_EMPREGADO que, por sua vez, deriva do campo armazenado EMP# no nvel interno. Tais correspondncias, ou mapeamentos, no so mostradas de forma explcita na Figura 2.2; consulte a Seo 2.6 para ver uma descrio adicional. Externo (PL/I) Externo (COBOL) DEL 1 EMPP, 01 EMPC 2 EMP# CHAR(6), 02 EMPNO PIC X(6). 2 SAL FIXED BIN(31); 02 DEPTNO PIC X(4). Conceitual EM PREGADO NMERO EMPREGADO CHARACTER (6) NMERO_DEPARTAMENTO CHARACTER (4) SALRIO NUMERIC (5) Interno EMP ARMAZENADO BYTES=20 PREFIXO TYPE=BYTE(6) ,OFFSET=0 EMP# TYPE=BYTE(6) ,OFFSET=6, INDEX=EMPX DEPTO# TYPE=BYTE(4) ,OFFSET=12 PAGTO TYPE=FULLWORD,OFFSET=16 FIGURA 2.2 Um exemplo dos trs nveis Observe que faz pouca diferena para as finalidades deste captulo saber se o sistema que est sendo considerado relacional ou no. Contudo, pode ser til indicar de forma resumida como os trs nveis da arquitetura so em

geral percebidos especificamente em um sistema relacional: Primeiro, o nvel conceitual em tal sistema ser definitivamente relacional, no sentido de que os objetos visveis nesse nvel sero tabelas relacionais, e os operadores sero operadores relacionais (incluindo, em especial, os operadores de restrio e projeo examinados de forma abreviada no Captulo 1). Em segundo lugar, uma determinada viso externa tambm ser tipicamente relacional, ou algo muito prximo disso; por exemplo, as declaraes de registros PL/I ou COBOL da Figura 2.2 podem ser consideradas de maneira informal, respectivamente, os equivalentes PL/I ou COBOL da declarao de uma tabela relacional em um sistema relacional. Nota: devemos mencionar de passagem que o termo viso externa (em geral abreviado apenas como viso) infelizmente tem um significado bastante especfico em contextos relacionais que no idntico ao significado atribudo ao termo neste captulo. Consulte os Captulos 3 e 9 para ver uma explicao e uma descrio do significado relacional. Terceiro, o nvel interno no ser relacional, porque os objetos nesse nvel no sero apenas tabelas relacionais (armazenadas) em vez disso, eles sero os mesmos tipos de objetos encontrados no nvel interno de qualquer outra espcie de sistema (registros armazenados, ponteiros, ndices, hashing etc.). De fato, o modelo relacional em si no tem absolutamente nenhuma relao com o nvel interno; ele se preocupa, como vimos no Captulo 1, com o modo como o banco de dados visto pelo usurio. 30 Agora vamos prosseguir com o exame dos trs nveis da arquitetura com um nvel muito maior de detalhes, comeando pelo nvel externo. Em toda a nossa descrio, faremos repetidas referncias Figura 2.3, que mostra os principais componentes da arquitetura e seus inter-relacionamentos.

pelo administrador de banco de dados (DBA) 1

Usurio Usurio Usurio Usurio Usurio Ai A2 Bi B2 B3 Linguagem Linguagem Linguagem Linguagem Linguagem host host host host host + DSL + DSL + DSL + DSL + DSL Esquema Viso externa A externo Viso externa B

2.3 O NVEL EXTERNO

O nvel externo o nvel do usurio individual. Como foi explicado no Captulo 1, um determinado usurio pode ser ou programador de aplicaes ou um usurio final com qualquer grau de sofisticao. (O DBA um caso especial importante; porm, diferentemente de outros usurios, o DBA tambm precisar estar interessado nos nveis conceitual e interno. Consulte as duas sees seguintes.) Cada usurio tem uma linguagem sua disposio: Para o programador de aplicaes, essa linguagem ser uma linguagem de programao convencional (como PL/I, C+ +, Java) ou uma linguagem proprietria especfica para o sistema em questo. Essas linguagens proprietrias so freqentemente chamadas de linguagens de quarta gerao (L4Gs), pelo fato (muito difuso!) de que (a) o cdigo de mquina, a linguagem assembler e a linguagem PL/I podem ser consideradas como trs geraes mais antigas de linguagens e (b) as linguagens proprietrias representam o mesmo tipo de aperfeioamento em relao s linguagens de terceira gerao (L3Gs) que essas linguagens representavam em relao linguagem assembler e esta ltima, por sua vez, representava em relao ao cdigo de mquina. Para o usurio final, a linguagem ser uma linguagem de consulta ou alguma linguagem de uso especial, talvez dirigida por formulrios ou menus, adaptada aos requisitos desse usurio e com suporte de algum programa aplicativo on-line (conforme explicamos no Captulo 1).

Esquema externo A*

Esquemas e mapeamentos construdos e mantidos

Mapeamento externo! Mapeamento externo! conceitual A conceitual B

7 Sistema fgerenciamento Esquema 1 Viso conceitual 4 de bancos conceitual de dados Mapeamento conceitual! interno

Definio da estrutura de armazenamento (esquema interno)

Banco de dados armazenado (viso interna) II II II II II II II *lnterface do usurio FIGURA 2.3 Arquitetura do sistema em detalhes 31 Para nossos propsitos, o ponto importante sobre todas essas linguagens que elas incluiro uma sublinguagem de dados isto , um subconjunto da linguagem completa relacionado de modo especfico aos objetos e s operaes do banco de dados. A sublinguagem de dados (abreviada como DSL data sublanguage na Figura 2.3) dita embutida na linguagem hospedeira correspondente. A linguagem hospedeira responsvel pelo fornecimento de diversos recursos no relacionados com bancos de dados, como variveis locais, operaes de clculo, lgica de desvios condicionais (if-then-else), e assim por diante. Um dado sistema poderia admitir qualquer nmero de linguagens hospedeira e qualquer nmero de sublinguagens de dados; porm, uma determinada sublinguagem de dados reconhecida por quase todos os sistemas atuais a linguagem SQL, discutida brevemente no Captulo 1. A maioria desses sistemas permite que a SQL seja usada tanto de modo interativo como uma linguagem de consulta autnoma, quanto incorporada a outras linguagens como PL/I ou Java (consulte o Captulo 4 para ver detalhes adicionais). Observe que, embora seja conveniente para propsitos arquiteturais distinguir entre a sublinguagem de dados e a linguagem hospedeira que a contm, as duas podem de fato no ser distintas para o usurio; na verdade, talvez seja prefervel sob a perspectiva do usurio que elas no sejam distintas. Se elas no forem distintas, ou se s puderem ser distinguidas com dificuldade, diremos que elas esto fortemente acopladas. Se forem clara e facilmente distinguveis, dizemos que elas esto fracamente acopladas. Apesar de alguns sistemas comerciais (em especial sistemas de objetos ver Captulo 24) admitirem o acoplamento forte, a maioria no o aceita. Em particular, os sistemas SQL costumam oferecer suporte apenas para o acoplamento fraco. (O acoplamento forte oferece um conjunto de recursos mais uniforme para o usurio, mas sem dvida envolve maior esforo por parte dos desenvolvedores de sistemas, um fato que presumivelmente contribui para o status quo.) Em princpio, qualquer sublinguagem de dados determinada , na realidade, uma combinao de pelo menos duas linguagens subordinadas uma linguagem de definio de dados (DDL Data Definition Language), que d suporte definio ou declarao de objetos dos bancos de dados, e uma linguagem de manipulao de dados (DML Data Manipulation Language), que admite a manipulao ou o processamento desses objetos. Por exemplo, considere o usurio PL/I da Figura 2.2, na Seo 2.2. A sublinguagem de dados para esse usurio consiste nos recursos de PL/I utilizados para a comunicao com o SGBD: A parte de DDL consiste nas construes declarativas de PL/I necessrias para se declararem objetos do banco de dados a prpria instruo DECLARE(DEL), certos tipos de dados de PL/I, possivelmente extenses especiais de PL/I para oferecer suporte a novos objetos no manipulados pela PL/I existente. A parte da DML consiste nas instrues executveis de PL/I que transferem informaes de e para o banco de dados mais uma vez incluindo, possivelmente, novas instrues especiais. Nota: mas precisamente, devemos dizer que a PL/I no inclui na realidade nenhum recurso especfico de bancos de dados na poca em que este livro foi escrito. Em particular, as instrues de DML costumam ser apenas instrues CALL de PL/I que invocam o SGBD (embora essas chamadas possam estar sintaticamente disfaradas de algum modo, a fim de torn-las um pouco mais amistosas para o usurio consulte a discusso sobre a SQL embutida no Captulo 4). Voltando arquitetura: j indicamos que um usurio individual geralmente s estar interessado em alguma parte do banco de dados como um todo; alm disso, a viso que esse usurio tem dessa parte ser em geral um tanto abstrata quando comparada com o modo como os dados esto fisicamente armazenados. O termo ANSI/SPARC para a viso de um usurio individual viso externa. Uma viso externa , portanto, o contedo do banco de dados visto por algum usurio determinado (ou seja, para esse usurio a viso externa o banco de dados). Por exemplo, um usurio do Departamento de Pessoal poderia considerar o banco de dados uma coleo de ocorrncias de registros de departamentos e empregados, e ele poderia no ter nenhum conhecimento das ocorrncias de registros de fornecedores e peas vistas pelos usurios do Departamento de Compras. 32

(corrigir falta a pgina 33)cluir muitos recursos adicionais, como as restries de segurana e integridade mencionadas no Captulo 1. Algumas autoridades no assunto chegariam at a sugerir que o objetivo final do esquema conceitual descrever a empresa inteira no apenas seus dados, mas tambm o modo como esses dados so usados, como eles fluem de um ponto para outro dentro da empresa, para que eles so usados em cada ponto, quais controles de auditoria ou outros controles devem ser aplicados em cada ponto, e assim por diante [2.3]. No entanto, devemos enfatizar que nenhum sistema atual admite realmente um esquema conceitual que sequer se aproxime desse grau de abrangncia; na maior parte dos sistemas existentes, o esquema conceitual na verdade pouco mais que uma simples reunio de todos os esquemas externos individuais, somados a certas restries de segurana e integridade. Porm, sem dvida, possvel que sistemas futuros eventualmente sejam muito mais sofisticados em seu suporte do nvel conceitual. 2.5 O NVEL INTERNO O terceiro nvel da arquitetura o nvel interno. A viso interna uma representao de baixo nvel do banco de dados por inteiro; ela consiste em muitas ocorrncias de cada um dos vrios tipos de registros internos. Registro interno o termo ANSI/SPARC que representa a construo que temos chamado de registro armazenado (e continuaremos a usar essa ltima forma). Assim, a viso interna ainda est muito afastada do nvel fsico, pois ela no lida com registros fsicos tambm chamados blocos ou pginas nem com quaisquer consideraes especficas de dispositivos, como tamanhos de cilindros ou trilhas. Em outras palavras, a viso interna pressupe efetivamente um espao de endereos linear infinito; os detalhes de como esse espao de endereos mapeado no meio de armazenamento fsico so bastante especficos para cada sistema e foram deliberadamente omitidos da arquitetura geral. Nota: o bloco, ou a pgina, a unidade de entrada e sada (E/S) isto , ele representa a quantidade de dados transferidos entre o meio de armazenamento secundrio e a memria principal em uma nica operao de E/S. Os tamanhos de pginas tpicos so 1 K, 2 K ou 4 K bytes (K = 1.024). A viso interna descrita por meio do esquema interno, que no somente define os diversos tipos de registros armazenados mas tambm especifica quais ndices existem, como os campos armazenados esto representados, em que seqncia fsica esto os registros armazenados, e assim por diante (mais uma vez, veja na Figura 2.2 um exemplo simples). O esquema interno escrito usando-se ainda outra linguagem de definio de dados a DDL interna. Nota: neste livro, usaremos normalmente os termos mais intuitivos estrutura de armazenamento ou banco de dados armazenado em vez de viso interna, e ainda definio de estrutura de armazenamento em lugar de esquema interno. Para encerrar lembramos que, em certas situaes excepcionais, os programas aplicativos em particular as aplicaes de natureza utilitria (ver Seo 2.11) podem ter permisso para operar diretamente no nvel interno, e no no nvel externo. No preciso dizer que essa prtica no recomendvel; ela representa um risco de segurana (pois as restries de segurana so ignoradas) e um risco de integridade (pois tambm as restries de integridade so ignoradas), e o programa ter uma inicializao dependente dos dados; porm, s vezes essa poder ser a nica maneira de obter a funcionalidade ou o desempenho exigido do mesmo modo o usurio em uma linguagem de programao de alto nvel poderia ter a necessidade ocasional de descer at a linguagem assembler para satisfazer certos objetivos de funcionalidade ou desempenho. 2.6 MAPEAMENTOS Alm dos trs nveis bsicos, a arquitetura da Figura 2.3 envolve, em geral, certos mapeamentos um mapeamento conceitual interno e vrios mapeamentos externos/conceituais: O mapeamento conceitual interno define a correspondncia entre a viso conceitual e o banco de dados armazenado; ele especifica o modo como os registros e campos conceituais so representados no nvel interno. Se a estrutura do banco de dados armazenado for alterada isto , se 34

(corrigir falta a pgina 35) Definir o esquema interno O DBA tambm deve decidir como sero representados os dados no banco de dados armazenado. Em geral, esse processo chamado projeto de banco de dados fsico.* Tendo elaborado o projeto fsico, o DBA deve ento criar a definio da estrutura de armazenamento correspondente (isto , o esquema interno), usando a DDL interna. Alm disso, ele tambm deve definir o mapeamento conceitual/interno associado. Na prtica, a DDL conceitual ou a DDL interna mais provavelmente a primeira dever incluir os meios para definir esse mapeamento, mas as duas funes (criao do esquema, definio do mapeamento) devem ser claramente distinguveis. Como no caso do esquema conceitual, o esquema interno e o mapeamento correspondente existiro tanto na forma de fonte quanto de objeto. Ligao com usurios tarefa do DBA fazer a ligao com os usurios, a fim de garantir que os dados de que eles necessitam estaro disponveis, e escrever (ou ajudar os usurios a escreverem) os esquemas externos necessrios, usando a DDL externa aplicvel. (Como j foi dito, um dado sistema pode admitir vrias DDLs externas distintas.) Alm disso, os mapeamentos externos/conceituais correspondentes tambm devem ser definidos. Na prtica, a DDL externa provavelmente incluir os meios para especificar esses mapeamentos, mas, de novo, os esquemas e os mapeamentos devem ser claramente distinguveis. Cada esquema externo e o mapeamento correspondente devero existir tanto na forma de fonte quanto de objeto. Outros aspectos da funo de ligao com o usurio incluem a consultoria em projeto de aplicaes, o fornecimento de instruo tcnica, a assistncia para determinao e resoluo de problemas e servios profissionais semelhantes. Definir restries de segurana e integridade Como j vimos, as restries de segurana e integridade podem ser consideradas uma parte do esquema conceitual. A DDL conceitual deve incluir recursos para a especificao de tais restries. Definir normas de descarga e recarga Uma vez que uma empresa esteja comprometida com um sistema de banco de dados, ela se torna dependente de modo crtico do sucesso desse sistema. Em caso de danos a qualquer parte do banco de dados provocados por erro humano, digamos, ou por uma falha de hardware ou do sistema operacional essencial ser capaz de reparar os dados em questo com um mnimo de demora e com o menor efeito possvel sobre o restante do sistema. Por exemplo, em condies ideais, a disponibilidade dos dados que no tenham sido danificados no deve ser afetada. O DBA tem de definir e implementar um esquema apropriado de controle de danos, em geral envolvendo (a) descarga peridica ou dumping do banco de dados para o meio de armazenamento de backup e (b) recarregamento do banco de dados quando necessrio, a partir do dump mais recente. A propsito, a discusso anterior fornece uma razo pela qual seria uma boa idia espalhar a coleo total de dados por vrios bancos de dados, em vez de manter tudo em um nico lugar; o banco de dados individual poderia muito bem formar a unidade para finalidades de descarga e recarregamento. Nessa linha, observe que j existem sistemas terabyte** isto , instalaes de bancos de dados comerciais que armazenam bem mais de um trilho de bytes de dados, em termos informais e que os sistemas do futuro devero ser muito maiores. desnecessrio dizer que tais sistemas VLDB (banco de dados muito grande very large database) exigem administrao muito cuidadosa e sofisticada, em especial se houver um requisito de disponibilidade contnua (que normalmente existe). No obstante, por simplicidade, continuaremos a falar como se de fato houvesse um nico banco de dados. * Observe a seqncia: primeiro, defina que dados voc deseja; depois, decida como represent-los no meio de armazenamento. O projeto fsico sempre deve ser feito depois do projeto lgico. **1.o24 bytes = um kilobyte (KB); 1.024 KB = um megabyte (MB); 1.024 MB = um gigabyte (GB); 1.024 GB um terabyte (TB); 1.024 TB = um petabyte (PB); 1.024 PB = um exabyte (EB). Observe que, informalmente, um gigabyte equivale a um

36

bilho de bytes (a abreviatura BB empregada s vezes em lugar de GB).

Monitorar o desempenho e responder a requisitos de mudanas Como foi indicado na Seo 1.4, o DBA responsvel pela organizao do sistema de modo a obter o desempenho que seja o melhor para a empresa, e por fazer os ajustes apropriados isto , a sintonia fina (tuning) conforme os requisitos se alterarem. Por exemplo, poderia ser necessrio reorganizar o banco de dados armazenado de tempos em tempos para assegurar que os nveis de desempenho permanecero aceitveis. Como j mencionamos, qualquer mudana no nvel de armazenamento fsico (interno) do sistema deve ser acompanhada por uma mudana correspondente na definio do mapeamento de nvel conceitual/interno, de modo que o esquema conceitual possa permanecer constante. claro que a lista anterior no esgota o assunto ela pretende apenas dar uma idia da extenso e da natureza das responsabilidades do DBA. 2.8 O SISTEMA DE GERENCIAMENTO DE BANCOS DE DADOS O sistema de gerenciamento de bancos de dados (SGBD) o software que trata de todo o acesso ao banco de dados. Conceitualmente, o que ocorre o seguinte (observe mais uma vez a Figura 2.3): 1. Um usurio faz um pedido de acesso usando uma determinada sublinguagem de dados (em geral, SQL). 2. O SGBD intercepta o pedido e o analisa. 3. O SGBD inspeciona, por sua vez, o esquema externo (ou as verses objeto desse esquema) para esse usurio, o mapeamento externo/conceitual correspondente, o esquema conceitual, o mapeamento conceitual/interno e a definio da estrutura de armazenamento. 4. O SGBD executa as operaes necessrias sobre o banco de dados armazenado. Como exemplo, considere as aes relacionadas com a busca de uma determinada ocorrncia de registro externo. Em geral, sero necessrios campos de vrias ocorrncias de registros conceituais e, por sua vez, cada ocorrncia de registro conceitual exigir campos de vrias ocorrncias de registros armazenados. Ento, conceitualmente, o SGBD deve primeiro buscar todas as ocorrncias necessrias de registros armazenados, depois construir as ocorrncias de registros conceituais exigidas e, em seguida, construir a ocorrncia de registro externo. Em cada estgio, podem ser necessrias converses de tipos de dados ou outras converses. Naturalmente, a descrio anterior muito simplificada; em particular, ela implica que todo o processo interpretativo, medida que sugere que os processos de anlise do pedido, inspeo dos diversos esquemas etc., so todos realizados durante a execuo. A interpretao, por sua vez, em geral implica um desempenho sofrvel devido sobrecarga em tempo de execuo. Porm, na prtica talvez seja possvel fazer os pedidos de acesso serem compilados antes do momento da execuo (em particular, diversos produtos atuais de SQL fazem isso consulte as anotaes relativas s referncias [4.12] e [4.26] do Captulo 4). Vamos examinar agora as funes do SGBD com um pouco mais de detalhes. Essas funes incluiro o suporte a pelo menos todos os itens a seguir (observe a Figura 2.4): Definio de dados O SGBD deve ser capaz de aceitar definies de dados (esquemas externos, o esquema conceitual, o esquema interno e todos os mapeamentos associados) em forma fonte e convert-los para a forma objeto apropriada. Em outras palavras, o SGBD deve incluir componentes de processador de DDL ou compilador de DDL para cada uma das diversas linguagens de definio de dados (DDLs). O SGBD tambm deve entender as definies da DDL, no sentido de que, por exemplo, ele entende que os registros externos EMPREGADO incluem um campo SALARIO; ele deve ento ser capaz de usar esse conhecimento para analisar e responder a pedidos de manipulao de dados (por exemplo, obtenha todos os empregados com salrio < R$ 50.000,00). 37 Manipulao de dados O SGBD deve ser capaz de lidar com solicitaes do usurio para buscar, atualizar ou excluir dados existentes no banco de dados, ou para acrescentar novos dados ao banco de dados. Em outras palavras, o SGBD deve incluir um componente processador de DML ou compilador de DML para lidar com a linguagem de manipulao de dados (DML data manipulation language). Em geral, as solicitaes de DML podem ser planejadas ou no-planejadas: a. Uma solicitao planejada aquela para a qual a necessidade foi prevista com bastante antecedncia em relao ao momento em que a solicitao executada. O DBA provavelmente ter ajustado o projeto de banco de dados fsico de modo a garantir um bom desempenho para solicitaes planejadas. b. Em contraste, uma solicitao no-planejada uma consulta ad hoc, isto , uma solicitao cuja necessidade no foi prevista com antecedncia mas, em vez disso, surgiu no ltimo instante. O projeto de banco de dados fsico pode estar ou no adaptado de forma ideal para a solicitao especfica sendo considerada. Para usar a terminologia introduzida no Captulo 1 (Seo 1.3), as solicitaes planejadas so caractersticas de aplicaes operacionais ou de produo, ao passo que as solicitaes no-planejadas so caractersticas de aplicaes para apoio deciso. Alm disso, as solicitaes planejadas em geral sero emitidas a partir de programas aplicativos escritos previamente, enquanto as solicitaes no-planejadas sero, por definio, emitidas de modo interativo por meio de algum processador de linguagem de consulta. Nota: como vimos no Captulo 1, o processador de linguagem de consulta na realidade uma aplicao on-line embutida, no uma parte do SGBD per se; ele foi includo na Figura 2.4 por completitude. Otimizao e execuo As requisies de DML, planejadas ou no-planejadas, devem ser processadas pelo componente otimizador, cujo propsito determinar um modo eficiente de implementar a requisio. A otimizao discutida em detalhes no Captulo 17. As requisies otimizadas so ento executadas sob o controle do gerenciador em tempo de execuo (run time). Nota: na prtica, o gerenciador em tempo de execuo provavelmente invocar algum tipo de gerenciador de arquivos para obter acesso aos dados armazenados. Os gerenciadores de arquivos so descritos resumidamente no final desta seo. Segurana e integridade de dados O SGBD deve monitorar requisies de usurios e rejeitar toda tentativa de violar as restries de segurana e integridade definidas pelo DBA (consulte a seo anterior). Essas tarefas podem ser executadas em tempo de compilao ou em tempo de execuo, ou ainda em alguma mistura dos dois. Recuperao e concorrncia de dados O SGBD ou, mais provavelmente, algum outro componente de software relacionado, em geral chamado gerenciador de transaes ou monitor de processamento de transaes (monitor TP) deve impor certos controles de recuperao e concorrncia. Os detalhes desses aspectos do sistema esto alm do escopo deste captulo; consulte a Parte IV deste livro, que contm uma descrio em profundidade do assunto. Nota: o gerenciador de transaes no mostrado na Figura 2.4 porque, em geral, ele no faz parte do SGBD propriamente dito. a Dicionrio de dados O SGBD deve fornecer uma funo de dicionrio de dados. O dicionrio de dados pode ser considerado um banco de dados em si (mas um banco de dados do sistema, no um banco de dados 38 do usurio), O dicionrio contm dados sobre os dados (s vezes chamados metadados ou descritores) ou seja, definies de outros objetos do sistema, em vez de dados brutos somente. Em particular, todos os vrios esquemas e mapeamentos (externos, conceituais etc.) e todas as diversas restries de segurana e integridade estaro armazenados, tanto na forma de fonte quanto de objeto, no dicionrio. Um dicionrio completo tambm incluir muitas informaes adicionais mostrando, por exemplo, os programas que utilizam determinadas partes do banco de dados, os usurios que exigem certos relatrios, os terminais conectados ao sistema, e assim por diante. O dicionrio poderia at estar na verdade, provavelmente deve estar integrado ao banco de dados que define e, portanto, incluir sua prpria definio. Por certo, deve haver a opo de consultar o dicionrio como qualquer outro banco de dados para que, por exemplo, seja possvel saber que programas e/ou usurios tero maior probabilidade de serem afetados por alguma alterao proposta no sistema. Consulte o Captulo 3 para ver uma discusso adicional sobre o assunto. Nota: estamos entrando agora em uma rea sobre a qual existe muita confuso de terminologia. Algumas pessoas fariam referncia ao que estamos chamando de dicionrio como um diretrio ou catlogo, o que implica que diretrios ou catlogos so de algum modo inferiores a um verdadeiro dicionrio e reservariam o termo dicionrio para designar uma variedade especfica (importante) de ferramenta para desenvolvimento de aplicaes. Outros termos que tambm so algumas vezes empregados para designar essa ltima variedade de objetos so repositrio de dados (ver Captulo 13) e enciclopdia de dados. 39 Desempenho desnecessrio dizer que o SGBD deve realizar todas as funes identificadas anteriormente de forma to eficiente quanto possvel. Podemos resumir tudo o que foi mencionado antes afirmando que a funo geral do SGBD fornecer a interface do usurio para o sistema de banco de dados. A interface do usurio pode ser definida como a fronteira no sistema abaixo da qual tudo invisvel para o usurio. Por definio, portanto, a interface do usurio est no nvel externo. Contudo, como veremos no Captulo 9, h algumas situaes em que improvvel que a viso externa seja significativamente diferente da poro relevante da viso conceitual subjacente, pelo menos nos produtos SQL comerciais de hoje. Conclumos esta seo com uma breve comparao entre os sistemas de gerenciamento de bancos de dados discutidos anteriormente e os sistemas de gerenciamento de arquivos (gerenciadores de arquivos ou servidores de arquivos). Em linhas gerais, o gerenciador de arquivos o componente do sistema operacional bsico que administra arquivos armazenados; portanto, em termos informais, ele est mais prximo ao disco que o SGBD. (Na verdade, o SGBD costuma ser montado sobre algum tipo de gerenciador de arquivos.) Desse modo, o usurio de um sistema de gerenciamento de arquivos ser capaz de criar e destruir arquivos armazenados e de executar operaes simples de busca e atualizao sobre registros armazenados em tais arquivos. No entanto, em contraste com o SGBD: Os gerenciadores de arquivos no tm conhecimento da estrutura interna dos registros armazenados e, por isso, no podem lidar com requisies que dependam de um conhecimento dessa estrutura. Em geral, eles fornecem pouco ou nenhum suporte para restries de segurana e integridade. Em geral, eles fornecem pouco ou nenhum suporte para controles de recuperao e concorrncia. No h verdadeiramente um conceito de dicionrio de dados no nvel do gerenciador de arquivos. Eles proporcionam muito menos independncia de dados que o SGBD. Em geral, os arquivos no esto integrados ou compartilhados no mesmo sentido que o banco de dados (normalmente, eles so privativos de algum usurio ou alguma aplicao em particular). 2.9 O GERENCIADOR DE COMUNICAES DE DADOS Nesta seo, consideraremos resumidamente o tpico de comunicaes de dados. As requisies a bancos de dados de um usurio final so, na verdade, transmitidas da estao de trabalho do usurio que pode estar fisicamente afastada do prprio sistema de banco de dados para alguma aplicao on-line (embutida ou no), e da at o SGBD, sob a forma de mensagens de comunicao. De modo semelhante, as respostas do SGBD e da aplicao on-line para a estao de trabalho do usurio tambm so transmitidas sob a forma de mensagens. Todas essas transmisses de mensagens tm lugar sob o controle de outro componente de software, o gerenciador de comunicaes de dados (gerenciador DE data communications). O gerenciador DE no faz parte do SGBD, mas um sistema autnomo. Porm, como o gerenciador DE e o SGBD so claramente obrigados a trabalhar em harmonia, s vezes os dois so considerados parceiros de igual nvel em um empreendimento cooperativo de nvel mais alto, denominado sistema de banco de dados/comunicaes de dados (sistema DB/DE), no qual o SGBD toma conta do banco de dados e o gerenciador DE manipula todas as mensagens de e para o SGBD ou, mais precisamente, de e para aplicaes que utilizam o SGBD. Porm, neste livro, teremos pouco a dizer sobre o manejo de mensagens como essas (o que, por si s, um assunto extenso). A Seo 2.12 descreve resumidamente a questo das comunicaes entre sistemas distintos (ou seja, entre mquinas diferentes em uma rede de comunicaes, como a Internet), mas esse , na realidade, um tpico parte. 40 2.10 ARQUITETURA CLIENTE/SERVIDOR Descrevemos at agora neste captulo os sistemas de bancos de dados sob o ponto de vista da chamada arquitetura ANSI/SPARC. Em particular, a Figura 2.3 forneceu uma representao simplificada dessa arquitetura. Nesta seo, examinaremos os sistemas de bancos de dados sob uma perspectiva um pouco diferente. Naturalmente, o objetivo geral desses sistemas fornecer suporte ao desenvolvimento e execuo de aplicaes de bancos de dados. Portanto, sob um ponto de vista de mais alto nvel, um sistema de banco de dados pode ser considerado como tendo uma estrutura muito simples em duas partes, consistindo em um servidor (tambm chamado back end) e um conjunto de clientes (tambm chamados front ends). Consulte a Figura 2.5. Explicao: O servidor o prprio SGBD. Ele admite todas as funes bsicas de SGBDs discutidas na Seo 2.8 definio de dados, manipulao de dados, segurana e integridade de dados, e assim por diante. Em particular, ele oferece todo o suporte de nvel externo, conceitual e interno que examinamos nas Sees 2.3 a 2.6. Assim, o termo servidor neste contexto to-somente um outro nome para o SGBD. Os clientes so as diversas aplicaes executadas sobre o SGBD tanto aplicaes escritas por usurios quanto aplicaes internas, ou seja, aplicaes fornecidas pelo fabricante do SGBD ou por produtores independentes. No que se refere ao servidor, claro que no existe nenhuma diferena entre aplicaes escritas pelo usurio e aplicaes internas todas elas empregam a mesma interface para o servidor, especificamente a interface de nvel externo discutida na Seo 2.3. Usurios finais Clientes Servidor FIGURA 2.5 Arquitetura cliente/servidor Nota: certas aplicaes especiais chamadas utilitrios poderiam constituir uma exceo ao que vimos antes, pois s vezes elas podem precisar operar diretamente no nvel interno do sistema (conforme mencionamos na Seo 2.5). Esses utilitrios devem ser considerados componentes integrais do SGBD, em vez de aplicaes no sentido usual. Os utilitrios sero discutidos com mais detalhes na prxima seo. Vamos aprofundar o exame da questo de aplicaes escritas pelo usurio versus aplicaes fornecidas pelo fabricante: Aplicaes escritas pelo usurio so basicamente programas aplicativos comuns, escritos (em geral) em uma linguagem de programao convencional de terceira gerao (L3G), como C ou COBOL, ou ento em alguma linguagem proprietria de quarta gerao (L4G) embora em ambos os casos a linguagem precise ser de algum modo acoplada a uma sublinguagem de dados apropriada, conforme explicamos na Seo 2.3.

Banco de dados

41

Aplicaes fornecidas por fabricante (chamadas freqentemente de ferramentas tools) so aplicaes cuja finalidade bsica auxiliar na criao e execuo de outras aplicaes! As aplicaes criadas so aplicaes adaptadas a alguma tarefa especfica (elas podem no ser muito semelhantes s aplicaes no sentido convencional; de fato, a finalidade das ferramentas permitir aos usurios, em especial aos usurios finais, criar aplicaes sem ter de escrever programas em uma linguagem de programao convencional). Por exemplo, uma das ferramentas fornecidas pelo fabricante ser um gerador de relatrios, cuja finalidade permitir que os usurios finais obtenham relatrios formatados a partir do sistema sob solicitao. Qualquer solicitao de relatrio pode ser considerada um pequeno programa aplicativo, escrito em uma linguagem de gerao de relatrios de nvel muito alto (e finalidade especial). As ferramentas fornecidas pelo fabricante podem ser divididas em diversas classes mais ou menos distintas: a. Processadores de linguagem de consulta. b. Geradores de relatrios. c. Subsistemas grficos de negcios. d. Planilhas eletrnicas. e. Processadores de linguagem natural. f. Pacotes estatsticos. g. Ferramentas para gerenciamento de cpias ou extrao de dados. h. Geradores de aplicaes (inclusive processadores L4G). i. Outras ferramentas para desenvolvimento de aplicaes, inclusive produtos de engenharia de software auxiliada pelo computador (CASE computer-aided software engineering). Os detalhes dessas ferramentas e de vrias outras esto alm do escopo deste livro; entretanto, observamos que, tendo em vista que (como foi dito antes) toda a importncia de um sistema de banco de dados est em dar suporte criao e execuo de aplicaes, a qualidade das ferramentas disponveis , ou deve ser, um fator preponderante na deciso sobre o banco de dados (isto , o processo de escolha do produto de banco de dados apropriado). Em outras palavras, o SGBD em si no o nico fator que precisa ser levado em considerao, nem mesmo necessariamente o fator mais significativo. Encerramos esta seo com uma referncia para o que se segue. Como o sistema por completo pode estar to claramente dividido em duas partes, servidores e clientes, surge a possibilidade de executar os dois em mquinas diferentes. Em outras palavras, existe o potencial para o processamento distribudo. O processamento distribudo significa que mquinas diferentes podem estar conectadas entre si para formar algum tipo de rede de comunicaes, de tal modo que uma nica tarefa de processamento de dados possa ser dividida entre vrias mquinas na rede. Na verdade, essa possibilidade to atraente por uma variedade de razes, principalmente de ordem econmica que o termo cliente/servidor passou a se aplicar a quase exclusivamente ao caso em que o cliente e o servidor esto de fato localizados em mquinas diferentes. Examinaremos o processamento distribudo com mais detalhes na Seo 2.12. 2.11 UTILITRIOS Utilitrios so programas projetados para auxiliar o DBA com diversas tarefas administrativas. Como mencionamos na seo anterior, alguns programas utilitrios operam no nvel externo do sistema e, portanto, so na verdade apenas aplicaes de uso especial; alguns podem nem mesmo ser fornecidos pelo fabricante do SGBD, mas sim por algum fabricante independente. Porm, outros utilitrios operam diretamente no nvel interno (em outras palavras, eles realmente fazem parte do servidor) e, desse modo, devem ser oferecidos pelo fornecedor do SGBD. 42 Aqui esto alguns exemplos dos tipos de utilitrios que costumam ser necessrios na prtica: Rotinas de carga, a fim de criar a verso inicial do banco de dados a partir de um ou mais arquivos do sistema operacional. Rotinas de descarregamento/recarregamento, a fim de descarregar o banco de dados, ou partes dele, para o meio de armazenamento de backup e recarregar dados dessas cpias de backup ( claro que o utilitrio de recarregamento basicamente idntico ao utilitrio de carga que acabamos de mencionar). Rotinas de reorganizao, a fim de rearranjar os dados no banco de dados armazenado por vrias razes (em geral, relacionadas com o desempenho) por exemplo, para agrupar dados de algum modo particular no disco, ou para reaver o espao ocupado por dados que se tornaram obsoletos. Rotinas estatsticas, a fim de calcular diversas estatsticas de desempenho, tais como tamanhos de arquivos e distribuio de valores de dados ou contagens de E/S etc. Rotinas de anlise, a fim de analisar as estatsticas mencionadas antes. A lista precedente representa apenas uma pequena amostra das funes em geral oferecidas pelos utilitrios; existe uma srie de outras possibilidades. 2.12 PROCESSAMENTO DISTRIBUDO Repetindo o que mencionamos na Seo 2.10, a expresso processamento distribudo significa que mquinas diferentes podem estar conectadas entre si em uma rede de comunicaes como a Internet, de tal modo que uma nica tarefa de processamento de dados possa se estender a vrias mquinas na rede. (A expresso processamento paralelo tambm utilizada algumas vezes com significado quase idntico, exceto pelo fato de que as diferentes mquinas tendem a manter uma certa proximidade fsica em um sistema paralelo e no precisam estar to prximas em um sistema distribudo por exemplo, elas poderiam estar geograficamente dispersas no ltimo caso.) A comunicao entre as vrias mquinas efetuada por algum tipo de software de gerenciamento de rede possivelmente uma extenso do gerenciador DE discutido na Seo 2.9 ou, com maior probabilidade, um componente de software separado. So possveis muitos nveis ou variedades de processamento distribudo. Conforme mencionamos na Seo 2.10, um caso simples envolve a execuo do back end do SGBD (o servidor) em uma das mquinas e dos front ends da aplicao (os clientes) em outra. Ver Figura 2.6. Como vimos no final da Seo 2.10, o termo cliente/servidor, embora seja estritamente uma expresso relacionada com a arquitetura, passou a ser quase um sinnimo da disposio ilustrada na Figura 2.6, na qual o cliente e o servidor funcionam em mquinas diferentes. De fato, h muitos argumentos em favor de um esquema desse tipo: O primeiro basicamente o argumento usual sobre o processamento paralelo: especificamente, muitas unidades de processamento esto sendo agora aplicadas na tarefa global, enquanto o processamento do servidor (o banco de dados) e o processamento do cliente (a aplicao) esto sendo feitos em paralelo. O tempo de resposta e a vazo (throughput) devem assim ser melhorados. Alm disso, a mquina servidora pode ser uma mquina feita por encomenda para se ajustar funo de SGBD (uma mquina de banco de dados) e pode assim fornecer melhor desempenho de SGBD. Do mesmo modo, a mquina cliente poderia ser uma estao de trabalho pessoal, adaptada s necessidades do usurio final e, portanto, capaz de oferecer interfaces melhores, alta disponibilidade, respostas mais rpidas e, de modo geral, maior facilidade de utilizao para o usurio. 43 Mquina servidora FIGURA 2.6 Cliente(s) e servidor funcionando em mquinas diferentes Vrias mquinas clientes distintas poderiam ser capazes (na verdade, normalmente sero capazes) de obter acesso mesma mquina servidora. Assim, um nico banco de dados poderia ser compartilhado entre vrios sistemas clientes distintos (ver Figura 2.7). Alm dos argumentos anteriores, existe tambm o fato de que a execuo do(s) cliente(s) e do servidor em mquinas diferentes combina com a maneira como as empresas operam na realidade. bastante comum que uma nica empresa um banco, por exemplo opere muitos computadores, de tal modo que os dados correspondentes a uma parte da empresa sejam armazenados em um computador e os dados de outra parte sejam armazenados em outro computador. Prosseguindo com o exemplo do banco, muito provvel que os usurios de uma agncia precisem ocasionalmente obter acesso a dados armazenados em outra agncia. Portanto, observe que as mquinas clientes poderiam ter seus prprios dados armazenados,

Mquinas clientes

Mquina cliente

. . . .

Mquina servidora

44 FIGURA 2.7 Um equipamento servidor, vrios equipamentos

e a mquina servidora poderia ter suas prprias aplicaes. Dessa forma, em geral cada mquina atuar como um servidor para alguns usurios e como cliente para outros (ver Figura 2.8); em outras palavras, cada mquina admitir um sistema de banco de dados por inteiro, no sentido estudado em sees anteriores deste captulo. O ltimo ponto a mencionar que uma nica mquina cliente poderia ser capaz de obter acesso a vrias mquinas servidoras diferentes (a recproca do caso ilustrado na Figura 2.7). Esse recurso desejvel porque, como mencionamos antes, as empresas em geral operam de tal maneira que a totalidade de seus dados no fica armazenada em uma nica mquina, mas se espalha por muitas mquinas diferentes, e as aplicaes s vezes precisaro ter a capacidade de conseguir acesso a dados de mais de uma mquina. Basicamente, esse acesso pode ser fornecido de dois modos distintos: Um dado cliente pode ser capaz de obter acesso a qualquer nmero de servidores, mas somente um de cada vez (ou seja, cada requisio individual ao banco de dados tem de ser direcionada para apenas um servidor). Em um sistema desse tipo no possvel, dentro de uma nica requisio, combinar dados de dois ou mais servidores diferentes. Alm disso, o usurio de tal sistema tem de saber qual mquina em particular contm cada um dos fragmentos de dados. O cliente pode ser capaz de obter acesso a muitos servidores simultaneamente (isto , uma nica solicitao ao banco de dados poderia ter a possibilidade de combinar dados de vrios servidores). Nesse caso, os servidores aparentam para o cliente de um ponto de vista lgico ser realmente um nico servidor, e o usurio no precisa saber qual mquina contm cada um dos itens de dados.

FIGURA 2.8 Cada mquina pode rodar tanto o(s) cliente(s) como o servidor 45 Esse ltimo caso constitui um exemplo daquilo que se costuma chamar sistema de banco de dados distribudo, O tema de bancos de dados distribudos um grande tpico por si s; levado a sua concluso lgica, o suporte completo a bancos de dados distribudos implica que uma nica aplicao deve ser capaz de operar de modo transparente sobre dados espalhados por uma variedade de bancos de dados diferentes, gerenciados por uma variedade de SGBDs diferentes, funcionando em uma variedade de mquinas distintas, com suporte de uma variedade de sistemas operacionais diferentes e conectados entre si por meio de uma variedade de redes de comunicaes diferentes onde de modo transparente significa que a aplicao opera, de um ponto de vista lgico, como se os dados fossem todos gerenciados por um nico SGBD funcionando em uma nica mquina. Esse recurso pode parecer algo muito difcil de conseguir, mas altamente desejvel de uma perspectiva prtica, e os fabricantes esto trabalhando arduamente para tornar realidade esses sistemas. Discutiremos em detalhes os sistemas de bancos de dados distribudos no Captulo 20. 2.13 RESUMO Neste captulo, examinamos os sistemas de bancos de dados sob o ponto de vista da arquitetura. Primeiro, descrevemos a arquitetura ANSI/SPARC, que divide um sistema de bancos de dados em trs nveis, da seguinte forma: o nvel interno o mais prximo do meio de armazenamento fsico (ou seja, o que se ocupa do modo como os dados so armazenados fisicamente); o nvel externo o mais prximo dos usurios (ou seja, o que se ocupa do modo como os dados so visualizados por usurios individuais); e o nvel conceitual um nvel indireto entre os outros dois (ele oferece uma viso comunitria dos dados). Os dados percebidos em cada nvel so descritos em um esquema (ou por vrios esquemas, no caso do nvel externo). Os mapeamentos definem a correspondncia entre (a) um dado esquema externo e o esquema conceitual, e (b) o esquema conceitual e o esquema interno. Esses mapeamentos so a chave para proporcionar independncia de dados lgica e fsica, respectivamente. Os usurios isto , usurios finais e programadores de aplicaes, ambos operando no nvel externo interagem com os dados por meio de uma sublinguagem de dados, que se divide em pelo menos dois componentes, uma linguagem de definio de dados (DDL) e uma linguagem de manipulao de dados (DML). A sublinguagem de dados est incorporada em uma linguagem hospedeira. Nota: os limites entre a linguagem hospedeira e a sublinguagem de dados e entre a DDL e a DML tm natureza principalmente conceitual; em condies ideais, elas devem ser transparentes para o usurio. Tambm examinamos mais de perto as funes do DBA e do SGBD. Entre outras tarefas, o DBA responsvel pela criao do esquema interno (projeto fsico do banco de dados); em contraste, a criao do esquema conceitual (projeto lgico ou conceitual do banco de dados) de responsabilidade do administrador de dados. Por sua vez, o SGBD responsvel, dentre outras atribuies, pela implementao de requisies DDL e DML do usurio. O SGBD tambm responsvel pelo provimento de algum tipo de funo de dicionrio de dados. Os sistemas de bancos de dados tambm podem ser imaginados de forma conveniente como sistemas formados por um servidor (o prprio SGBD) e um conjunto de clientes (as aplicaes). O cliente e o servidor podem ser, e freqentemente, sero executados em mquinas diferentes, fornecendo assim um tipo simples de processamento distribudo. Em geral, cada servidor pode servir a muitos clientes, e cada cliente pode ter acesso a muitos servidores. Se o sistema oferecer transparncia total o que significa que cada cliente pode se comportar como se estivesse lidando com um nico servidor em uma nica mquina, qualquer que seja a situao fsica global ento teremos um verdadeiro sistema de banco de dados distribudo. EXERCCIOS 2.1 Trace um diagrama da arquitetura de sistemas de bancos de dados apresentada neste captulo (a arquitetura ANSI/SPARC). 46

2.2 Defina os seguintes termos: back end linguagem de manipulao de dados banco de dados distribudo linguagem hospedeira carga mapeamento conceitual/interno cliente mapeamento externo/conceitual DDL externa, esquema externo, viso externa processamento distribudo DDL conceitual, esquema conceitual, viso conceitual projeto lgico de banco de dados DDL interna, esquema interno, viso interna projeto fsico de banco de dados definio de estrutura de armazenamento reorganizao descarregamento/recarregamento requisio no-planejada dicionrio de dados requisio planejada front end servidor gerenciador DE sistema DB/DE: interface do usurio sublinguagem de dados linguagem de definio de dados utilitrio 2.3 Explique a seqncia de passos envolvida na busca de uma determinada ocorrncia de registro externo. 2.4 Liste as funes mais importantes executadas pelo SGBD. 2.5 Estabelea a distino entre independncia de dados lgica e fsica. 2.6 O que voc entende pelo termo metadados? 2.7 Liste as funes mais importantes executadas pelo DBA. 2.8 Estabelea a distino entre o SGBD e um sistema de gerenciamento de arquivos. 2.9 D alguns exemplos de ferramentas fornecidas pelo fabricante. 2.10 D alguns exemplos de utilitrios de bancos de dados. 2.11 Examine qualquer sistema de banco de dados que esteja disponvel para voc. Tente mapear esse sistema na arquitetura ANSI/SPARC da maneira descrita neste capitulo. Ele admite os trs nveis da arquitetura? Como so definidos os mapeamentos entre os nveis? Que aparncia tm as diversas DDLs (externa, conceitual, interna)? Qual(is) subliguagem(ens) de dados o sistema admite? Que linguagens hospedeiras ele aceita? Quem executa a funo de DBA? Existe algum dispositivo de segurana ou de integridade? Existe um dicionrio? Ele autodescritivo? Que aplicaes fornecidas pelo fabricante o sistema admite? Quais utilitrios? H um gerenciador DE separado? Existe algum recurso de processamento distribudo? REFERNCIAS E BIBLIOGRAFIA As referncias a seguir so todas bastante antigas (com exceo da ltima), mas ainda so relevantes para os conceitos introduzidos neste captulo. 2.1 ANSI/X3/SPARC Study Group on Data Base Management Systems: Interim Report, FDT (bulletin of ACM SIGMOD) 7, Nmero 2 (1975). 2.2 Dionysios C. Tsichritzis e Anthony Klug (editores): The ANSI/X3/SPARC DBMS Framework: Report of the Study Group on Data Base Mangement Systems, Information Systems 3 (1978). As referncias [2.1-2.2] so o relatrio provisrio e o relatrio final, respectivamente, do chamado ANSI/SPARC Study Group. O ANSI/X3/SPARC Study Group on Data Base Management Systems (para dar a ele seu ttulo completo) foi estabelecido no final de 1972 pelo Standards Planning and Requirements Committee (SPARC) do American National Standards Institute (ANSI) Committee on Computers and Information Processing (X3). (Cerca de 25 anos depois, o nome X3 mudou para NCITS National Committee on Information Technology Standards.) Os objetivos do Study Group eram determinar que reas se que havia alguma da tecnologia de bancos de dados eram adequadas para padronizao e produzir um conjunto de recomendaes para ao em cada uma dessas reas. No trabalho para atender a esses objetivos, o Study Group adotou a posio de que as interfaces eram o nico aspecto de um sistema de bancos de dados que talvez pudesse ser adequado para padronizao e, atuando de acordo com isso, definiu uma arquitetura (ou estrutura) generalizada para sistemas de bancos de dados que enfatizava o papel dessas interfaces. O relatrio final oferece uma descrio detalhada dessa arquitetura e de algu

mas das 42(!) interfaces identificadas, O relatrio provisrio um documento de trabalho inicial que ainda tem algum interesse; em certas reas ele fornece detalhes adicionais. 2.3 J. J. van Griethuysen (editor): Concept and Terminology for the Conceptual Schema and the Information Base, International Organization for Standardization (ISO) Technical Report ISO/TR 9007: 1987(E) (maro de 1982; revisado em julho de 1987). Esse documento o relatrio de um grupo de trabalho da ISO cujos objetivos incluam a definio de conceitos para linguagens de esquemas conceituais. Ele inclui uma introduo a trs candidatos concorrentes (mais precisamente, trs conjuntos de candidatos) para um conjunto apropriado de formalismos e aplica cada um dos trs a um exemplo comum envolvendo as atividades de uma autoridade de registro de automveis hipottica. Os trs conjuntos de competidores so (1) esquemas de entidades/atributos/relacionamentos, (2) esquemas de relacionamentos binrios e (3) esquemas de lgica de predicados interpretada. O relatrio tambm inclui uma discusso dos conceitos fundamentais subjacentes noo do esquema conceitual e sugere alguns princpios como base para implementao de um sistema que admite essa noo de forma apropriada. Uma leitura pesada em certos pontos, mas um documento importante para qualquer pessoa seriamente interessada no nvel conceitual do sistema. 2.4 William Kent, Data and Reality. Amsterdam, Pases Baixos: North/Holland/Nova York, N.Y.: Elsevier Science (1978). Uma discusso estimulante e que nos faz pensar na natureza das informaes e, em particular, do esquema conceitual. Esse livro projeta uma filosofia de que a vida e a realidade so no fundo amorfas, desordenadas, contraditrias, incoerentes, irracionais e no objetivas (fragmento do ltimo captulo). O livro pode ser considerado em grande parte um compndio de problemas do mundo real com os quais ( sugerido) os formalismos existentes de bancos de dados em particular, formalismos baseados em estruturas convencionais semelhantes a registros, o que inclui o modelo relacional tm dificuldade para lidar. Recomendado. 2.5 Odysseas G. Tsatalos, Marvin H. Solomon e Yannis E. Ioannidis: The GMAP: A Versatile Tool for Physical Data Independence, Proc. 2Oth Int. Conf. on Very Large Data Bases, Santiago do Chile (setembro de 1994). GMAP significa Generalized Multi-Level Access Path. Os autores do artigo observam corretamente que os produtos de bancos de dados de hoje obrigam os usurios a enquadrarem suas consultas em termos de um esquema lgico atado diretamente a estruturas fsicas e, conseqentemente, so bastante fracos no que se refere independncia de dados fsica. Por essa razo, eles propem em seu trabalho uma linguagem de mapeamento conceitual/interno (para usar a terminologia deste captulo) que pode ser usada para especificar muito mais tipos de mapeamentos que aqueles tipicamente aceitos nos produtos atuais. Dado um determinado esquema lgico, a linguagem (baseada na lgebra relacional consulte o Captulo 6 e portanto de natureza declarativa, e no procedural) permite a especificao de numerosos esquemas fsicos diferentes, todos eles formalmente derivados desse esquema lgico. Dentre outras coisas, esses esquemas fsicos podem incluir particionamento vertical e horizontal (consulte o Captulo 20), qualquer nmero de caminhos de acesso fsico, agrupamentos e redundncia controlada. O artigo tambm fornece um algoritmo para transformar operaes do usurio sobre o esquema lgico em operaes equivalentes sobre o esquema fsico. Uma implementao de prottipo mostra que o DBA pode ajustar o esquema fsico para conseguir um desempenho significativamente melhor do que possvel com tcnicas convencionais.

48