Embed Size (px)
Citation preview
44
Arquiteturas de Sistemas de Banco de Dados
A arquitetura de um sistema de banco de dados é fortemente influenciada pelo sistema básico
computacional sobre o qual o sistema de banco de dados é executado. Aspectos da arquitetura de computadores
– como rede, paralelismo e distribuição – têm influência na arquitetura do banco de dados.
• Rede de computadores permite que algumas tarefas sejam executadas no servidor do sistema e outras
sejam executadas no cliente. Essa divisão de trabalho tem levado ao desenvolvimento de sistemas de
banco de dados cliente-servidor.
• Processamento paralelo em um sistema de computadores permite que atividades do sistema de banco de
dados sejam realizadas com mais rapidez, reduzindo o tempo de resposta das transações e, assim,
aumentando o número de transações processadas por segundo. Consultas podem ser processadas de
forma a explorar o paralelismo oferecido pelo sistema operacional. A necessidade de processamento
paralelo de consultas tem levado ao desenvolvimento de sistemas de banco de dados paralelos.
• A distribuição de dados pelos nós da rede ou pelos diversos departamentos de uma organização
permitem que esses dados residam onde são gerados ou mais utilizados, mas, ainda assim, estejam
acessíveis para outros nós de outros departamentos. Dispor de diversas cópias de um banco de dados em
diferentes nós também permite a organizações de grande porte manter operações em seus bancos de
dados mesmo quando um nó é afetado por um desastre natural, como inundações, incêndios ou
terremotos. Sistemas de banco de dados distribuídos têm se desenvolvido para tratar dados distribuídos
geográfica ou administrativamente por diversos sistemas de banco de dados.
Vamos agora estudar a arquitetura dos sistemas de banco de dados, começando com os sistemas
centralizados tradicionais e passando por sistemas de banco de dados cliente-servidor, paralelos e distribuídos.
Sistemas Centralizados
Sistemas de banco de dados centralizados são aqueles executados sobre um único sistema computacional
que n ao interagem com outros sistemas. Tais sistemas podem ter a envergadura de um sistema de banco de
dados de um só usuário executado em um computador pessoal até sistemas de alto desempenho em sistema de
grande porte.
Um sistema computacional genérico moderno consiste em uma ou poucas CPUs e dispositivos de controle
que são conectados por meio de um bus comum que proporciona acesso à memória compartilhada (fig. 16.1). As
CPUs têm memórias cache locais que armazenam cópias de partes da memória para acesso rápido aos dados.
Cada dispositivo de controle atende a um tipo específico de dispositivo (por exemplo, um drive de disco, um
dispositivo de áudio ou de vídeo). A CPU e os dispositivos de controle podem trabalhar concorrentemente,
competindo pelo acesso à memória. A memória cache parcialmente reduz a contenção de acesso à memória,
uma vez que reduz o número de tentativas de acesso da CPU à memória compartilhada.
45
Dividimos em dois modos a forma pela qual os computadores são usados: por um sistema de um único
usuário e sistemas multiusuários. Computadores pessoais e estações de trabalho caem na primeira categoria. Um
sistema monousuário típico é uma unidade de trabalho de uma única pessoa, com uma única CPU e um ou dois
discos rígidos, com um sistema operacional que pode dar suporte a apenas um único usuário. Um sistema
multiusuário típico, por outro lado, possui um número maior de discos e área de memória, podendo ter diversas
CPUs e um sistema operacional multiusuário. Atende a um grande número de usuários que estão conectados ao
sistema por meio de terminais. Tais sistemas são frequentemente chamados de sistemas servidor.
Sistemas de banco de dados projetados para ser monousuários, como os de computadores pessoais,
normalmente não proporcionam muitos recursos comuns aos banco de dados multiusuários. Em particular, ele
não dão suporte ao controle de concorrência, o que não é necessário quando somente um usuário pode gerar
atualizações.
A recuperação de perdas nesse tipo de sistema é, senão inexistente, primitiva – por exemplo, fazendo um
backup do banco de dados antes de qualquer atualização. Muitos desses sistemas não dão suporte à SQL,
fornecendo linguagens de consulta bem mais simples, como uma variante da QBE.
Embora os sistemas de computadores de propósito geral possuam atualmente múltiplos processadores,
eles têm paralelismo de granulação-grossa, com um número limitado de processadores (entre dois e quatro,
normalmente), todos compartilhando a memória principal. Os banco de dados rodando em tais equipamentos
normalmente não promovem o particionamento de uma consulta entre processadores: ao contrário, cada
consulta roda em um único processador, permitindo que diversas consultas sejam executada concorrentemente.
Assim, tais sistemas proporcionam alto throughput, isto é, um grande número de transações é processador por
segundo, embora uma transação, individualmente, não seja necessariamente processada com maior rapidez.
Banco de dados processados em equipamento de um só processador já dispõem de recursos multitarefas,
nos quais diversos processos podem ser executados em um mesmo processador de modo compartilhado, dando
ao usuário a impressão de que diversos processos são executados em paralelo. Assim, equipamentos com
paralelismo de granulação-grossa parecem, na lógica, idênticos a um equipamento de um único processador;
sistemas de banco de dados projetados para equipamentos time-shared podem facilmente ser adaptados para
esse ambiente.
Em contrate, os equipamentos de granulação-fina têm um grande número de processadores, e os
sistemas de banco de dados rodando nesse tipo de equipamento podem processar unidades de tarefas
(consultas, por exemplo) submetidas pelos usuários em paralelo.
46
Sistemas Cliente-Servidor
Como os computadores pessoais têm se tornado mais rápidos, mais poderosos e baratos, há uma
tendência de seu uso nos sistemas centralizados. Terminais conectados a sistemas centralizados estão sendo
substituídos por computadores pessoais. Simultaneamente, interfaces com o usuário usadas funcionalmente para
manuseio direto com sistemas centralizados estão sendo adequadas ao trato com computadores pessoais.
Como resultado, sistemas centralizados atualmente agem como sistemas servidores que atendem a
solicitações de sistemas clientes. A estrutura geral de um sistema cliente-servidor é exibida na fig. 16.2.
As funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias –
front-end e back-end – como mostra a fig. 16.3. O back-end gerencia as estruturas de acesso, desenvolvimento e
otimização de consultas, controle de concorrência e recuperação. O front-end dos sistemas de banco de dados
consiste em ferramentas como formulários, gerador de relatórios e recursos de interface gráfica. A interface
entre front-end e o back-end é feita por meio da SQL ou de um programa de aplicação.
Sistemas servidores podem ser caracterizados, de modo geral, como servidores de transações e
servidores de dados.
• Sistemas servidores de transações, também chamados sistemas servidores de consultas (query-server),
proporcionam uma interface por meio da qual os clientes podem enviar pedidos para determinada ação
e, em resposta, eles executam a ação e mandam de volta os resultados ao cliente. Usuários podem
especificar pedidos por SQL ou por meio de um programa de aplicação usando um mecanismo de
chamada de procedimento remota (remote-procedure-call).
• Sistemas servidores de dados permitem que os servidores interajam com clientes que fazem solicitações
de leitura e atualização de dados em unidades como arquivos ou páginas. Por exemplo, servidores de
arquivos que proporcionam uma interface sistema-arquivo na qual os clientes podem criar, atualizar, ler e
remover arquivos. Servidores de dados para sistemas de banco de dados oferecem muito mais recursos:
dão suporte a unidades de dados – como páginas, tuplas ou objetos – menores que um arquivo.
Proporcionam meios para indexação de dados e transações, tal que os dados nunca se tornem
inconsistentes se um equipamento cliente ou processo falhar.
47
Servidores de Transações
Em sistemas centralizados, o front-end e o back-end são ambos executados dentro de um único sistema.
Entretanto, a arquitetura de servidores de transações segue a divisão funcional entre front-end e back-end.
Devido à grande exigência de processamento para código de interface gráfica e ao aumento do poder de
processamento dos computadores pessoais, o recurso para front-end é possível em computadores pessoais. Os
computadores pessoais agem como clientes de sistemas servidores, os quais armazenam grandes volumes de
dados e dão suporte aos recursos de back-end. Clientes enviam solicitações ao sistema servidor no qual essas
transações são executadas e os resultados são enviados de volta ao cliente que tem a responsabilidade de exibir
esses dados.
Padrões do tipo ODBC (open database connectivity) visam atender à interface de clientes e servidores.
ODBC são programas de aplicação de interface que possibilitam aos clientes a criação de comandos SQL que são
enviados para o servidor, no qual são executados. Qualquer cliente que use uma interface ODBC pode se conectar
a qualquer servidor que forneça essa interface. Nas primeiras gerações de sistemas de banco de dados, a falta
desse tipo de padrão levou ao uso de software de mesmo fabricante tanto para back-end quanto para front-end.
Com a difusão de padrões para interfaces, diversos fabricantes passaram a disponibilizar ferramentas de
front-end e os servidores back-end. Gupta SQL e PowerBuilder são exemplos de sistemas front-end
independentes dos servidores back-end. Logo, alguns programas de aplicação, como as planilhas eletrônicas e
pacotes para análise estatística, usarão interfaces cliente-servidor para acesso direto aos dados de um servidor
back-end. Com efeito, eles funcionam como front-ends especializados para tarefas específicas.
Interfaces cliente-servidor não ODBC são também usadas para alguns sistemas de processamento de
transações. São definidas por uma interface de programa de aplicação na qual os clientes enviam chamadas de
procedimento transacional remota (transactional remote procedure call) para o servidor. Essas chamadas
parecem chamadas de procedimentos simples feitas por programas, mas, na verdade, todas as chamadas de
procedimentos simples feitas por programas, mas, na verdade, todas as chamadas de procedimentos remotas
feitas pelo cliente são encapsuladas em uma única transação para o servidor. Assim, se a transação for abortada,
o servidor poderá reverter os resultados da chamada de procedimento remota.
Como os equipamentos pequenos e individuais apresentam atualmente custo bem menor de aquisição e
manutenção, as grandes corporações tendem a adotar o down-sizing. Muitas empresas estão substituindo seus
equipamentos de grande porte por redes de computadores com estacoes de trabalho ou computadores pessoais
conectados a equipamentos servidores back-end. Algumas das vantagens são a maior funcionalidade e o menor
custo, mais flexibilidade na disseminação, expansão e alocação dos recursos, melhores interfaces com os usuários
e manutenção mais fácil.
Servidores de dados
Sistemas servidores de dados são usados em redes locais, nas quais há conexões de alta velocidade entre
clientes e servidores, os equipamentos clientes são comparáveis, em poder de processamento, aos equipamentos
servidores e as tarefas executadas são do tipo processamento intensivo. Em tal ambiente, faz sentido o tráfego de
dados para o equipamento cliente, para o processamento local (o que pode levar certo tempo) e então o envio
dos dados de volta para o servidor. Note que essa arquitetura exige ampla funcionalidade back-end (fig. 16.3) nos
clientes. Arquiteturas de servidores de dados têm sido comuns nos sistemas de banco de dados orientados a
objetos.
A origem do interesse nesse tipo de arquitetura surge a partir do momento em que o custo, relativo ao
consumo de tempo, da comunicação entre cliente e servidor é alta comparada ao tempo de referência à memória
local (milissegundos versus menos de cem nanossegundos).
• Transmissão de páginas versus transferência de itens. A unidade de comunicação para os dados pode ser
de granularidade grossa, como uma página, ou de granularidade fina, como uma tupla (ou um objeto, no
contexto de banco de dados orientado a objetos).
48
Se a unidade de comunicação é um único item, o overhead para a troca de mensagens é alto se
comparado ao volume de dados transmitido. Quando um item é solicitado, faz sentido também enviar
outros itens que certamente serão usados em um futuro próximo. A busca de itens antes mesmo que
sejam solicitados é chamada prefetching. A transferência de páginas pode ser considerada uma forma de
prefetching se diversos itens residirem em uma mesma página, já que todos os itens na página são
transferidos quando um processo deseja ter acesso a um único item de uma página.
• Bloqueio. Os bloqueios, em geral, são utilizados pelo servidor em itens de dados transitando entre
clientes. Uma desvantagem da transferência de páginas é que as máquinas clientes precisam bloquear a
unidade da granularidade – um bloqueio de uma página implica o bloqueio de todos os itens dessa
página. Mesmo que o cliente não esteja acessando mais de um item dessa página, fica implícito o
bloqueio sobre todos os itens reservados. Outro cliente que solicite bloqueio nesses itens será impedido
desnecessariamente. Algumas técnicas para escala de liberação de bloqueio (lock deescalation) já foram
propostas, nas quais o servidor pode solicitar de volta para seus clientes a transferência dos bloqueios
dos itens reservados. Se o cliente não precisar de um item reservado, ele pode transferir o bloqueio do
item de volta ao servidor, que então pode ser bloqueado por outro cliente.
• Data caching. Os dados que navegam para um cliente durante uma transação pode ser cached no cliente,
mesmo depois de completada a transação, se houver espaço suficiente disponível. Transações sucessivas
em um mesmo cliente podem acarretar o uso de dados cached. Entretanto, o uso de cache exige certa
coerência: mesmo que uma transação ache um dado cached, é preciso ter certeza de que esse dado
esteja atualizado, uma vez que ele pode ter sido alterado por um outro cliente depois de ter sido
colocado em cache. Assim, uma mensagem precisará ainda ser trocada com o servidor para checar a
validade e conseguir um bloqueio sobre o dado.
• Bloqueio cache (lock caching). Se os dados forem bem particionados entre os clientes, com um cliente
raramente solicitando um dado ao mesmo tempo que outro, os bloqueios podem também ser
armazenados localmente (cached) no equipamento cliente. Suponha que um item de dado esteja em
cache e que o bloqueio solicitado para acesso a esse dado também esteja em cache. Então, o acesso pode
ser realizado sem qualquer comunicação com o servidor. Entretanto, o servidor precisa controlar os
bloqueios em cache: se um cliente solicita um bloqueio ao servidor, o servidor precisa recuperar todos os
bloqueios em conflito de itens de dados de qualquer outro equipamento cliente que possua bloqueio em
cache. Essa tarefa torna-se muito mais complicada quando são consideradas as falhas de equipamento.
Essa técnica difere da escala de liberação de bloqueios apenas pelo fato de ser realizada ao longo da
transação; de resto, ambas as técnicas são similares.
Sistemas Paralelos
Sistemas paralelos imprimem velocidade ao processamento e à I/O por meio do uso em paralelos de
diversas CPUs e discos. Equipamentos paralelos estão se tornando bastante comuns, fazendo com que o estudo
de sistema de bancos de dados paralelos seja também cada vez mais importante. O direcionamento das atenções
para os sistemas de banco de dados paralelos proveem da demanda de aplicações que geram consultas em banco
de dados muito grandes (da ordem de terabytes – isto é, 1012 bytes) ou que tenham de processar um volume
enorme de transações por segundo (da ordem de milhares de transações por segundo). Sistemas de banco de
dados centralizados e cliente-servidor não são poderosos o suficiente para tratar desse tipo de aplicação.
No processamento paralelo, muitas operações são realizadas simultaneamente, ao contrário do
processamento serial, no qual os passos do processamento são sucessivos. Um equipamento paralelo de
granulação-grossa consiste em poucos e poderosos processadores; um paralelismo intensivo ou de granulação-
fina usa milhares de pequenos processadores; um paralelismo intensivo ou de granulação-fina usa milhares de
pequenos processadores. A maioria das máquinas high-end, atualmente, oferece algum grau de paralelismo de
granulação-grossa: dois a quatro processadores em uma única máquina já é comum. Computadores de
paralelismo intensivo podem ser diferenciados dos equipamentos de paralelismo de granulação-grossa pelo grau
49
de paralelismo muito mais alto que podem oferecer. Computadores paralelos com centenas de CPUs e discos já
estão disponíveis comercialmente.
São duas as principais formas de avaliar o desempenho de um sistema de banco de dados. A primeira é o
throughput: o número de tarefas realizadas em um dado intervalo de tempo. A segunda é o tempo de resposta: o
tempo total que o sistema leva para completar uma única tarefa. Um sistema que processa um grande número de
pequenas transações pode aumentar o throughput por meio do processamento de diversas transações em
paralelo. Um sistema que processa um grande volume de transações pode aumentar o tempo de resposta, assim
como o throughput por meio do processamento em paralelo.
Aceleração e Escalabilidade
Duas metas são importantes no estudo do paralelismo, a aceleração e a escalabilidade. A aceleração
refere-se à redução do tempo de execução de uma tarefa por meio do aumento do grau de paralelismo. A
escalabilidade diz respeito ao manuseio de um maior número de tarefas por meio do aumento do grau de
paralelismo.
Considere uma aplicação de banco de dados rodando em um sistema paralelo com um certo número de
processadores e discos. Agora, suponha que incrementemos o número de processadores ou discos e outros
componentes do sistema. A meta é processar a tarefa em tempo inversamente proporcional aos processadores e
discos alocados. Suponha que o tempo de execução de uma tarefa em um equipamento de grande porte seja TL e
que o tempo de execução da mesma tarefa em uma máquina de menor porte seja TS. A aceleração em função do
paralelismo é definida por Ts/TL.
O sistema paralelo apresenta um comportamento de aceleração linear se a aceleração for N quando um
sistema de maior porte tiver N vezes mais recursos (CPU, disco e assim por diante) que o sistema de menor porte.
Se a aceleração é menor que N, diz-se que o sistema apresenta comportamento de aceleração sublinear. A fig.
16.4 ilustra as acelerações linear e sublinear.
A escalabilidade relaciona-se à capacidade de processar grande volume de tarefas em um mesmo
intervalo de tempo por meio do aumento dos recursos. Seja Que uma tarefa e QN uma tarefa que é N vezes maior
que Q. Suponha que o tempo de execução de Que em um determinado equipamento MS seja TS e o tempo de
execução da tarefa QN em um equipamento paralelo ML, que é N vezes maior que MS, seja TL.
A escalabilidade é, então, definida como TS /TL. o sistema paralelo ML apresenta um comportamento de
escalabilidade linear na tarefa Q se TL = TS. Se TL > TS, o sistema apresenta um comportamento de escalabilidade
sublinear. A fig. 16.5 ilustra a escalabilidade linear e sublinear. Há dois tipos de escalabilidade relevantes em
sistemas de banco de dados paralelos, dependendo de como se mede a tarefa:
• Na escalabilidade em lote (batch), o tamanho do banco de dados aumenta e as tarefas são grandes jobs
cujo tempo de execução depende do tamanho do banco de dados. Um exemplo de tarefa desse tipo é a
pesquisa em uma relação cujo tamanho é proporcional ao tamanho do banco de dados. Assim, o
tamanho do banco de dados é determinante para a medição do problema. A escalabilidade no
50
processamento em lote também vale para as aplicações científicas, como na execução de uma consulta
com refinamento de N vezes ou a execução de uma simulação com N repetições.
• Na escalabilidade de transação, a taxa de submissão das transações para o banco de dados aumenta e o
tamanho do banco de dados aumenta proporcionalmente à taxa de transações. Esse tipo de
escalabilidade é o que é relevante nos sistemas de processamento de transações nos quais as transações
são pequenas atualizações – por exemplo, um depósito ou saque de uma conta – e a taxa de transações
cresce à medida que mais contas são criadas. Esse tipo de processamento de transações é especialmente
adequado para execução em paralelo, uma vez que as transações podem ser executadas concorrente e
independentemente em processadores separados, e cada transação leva, aproximadamente, o mesmo
tempo, até mesmo se o banco de dados crescer.
A escalabilidade é a mais importante métrica para medir a eficiência de um sistema de banco de dados
paralelo. Normalmente, o objetivo do paralelismo em sistemas de banco de dados é garantir um desempenho
aceitável, mesmo se o tamanho do banco de dados e o volume de transações crescerem. O aumento da
capacidade do sistema em função do paralelismo proporciona um caminho mais suave para o crescimento de
uma empresa que a transferência do sistema centralizado para um equipamento mais rápido (mesmo supondo
que tal máquina exista).
Entretanto, devemos também dar uma olhada nos números relativos ao desempenho absoluto quando
avaliamos a escalabilidade: uma máquina cujo crescimento da escalabilidade seja linear pode resultar em um
desempenho pior que outra cuja escala de crescimento seja menor que a linear, porque se partiu de uma
premissa indevida.
Alguns fatores trabalham contra a eficiência das operações em paralelo e podem reduzir tanto a
aceleração quanto a escalabilidade.
• Custo inicial. Existe um custo inicial associado à inicialização de um processo. Em operações paralelas
consistindo de milhares de processos, o tempo de iniciação (startup time) pode se sobrepor ao tempo
real de processamento, afetando de modo negativo a aceleração.
• Interferência. Uma vez que os processos executando em um sistema paralelo frequentemente mantem
seus acessos a recursos compartilhados, alguma lentidão pode resultar da interferência de cada novo
processo, já que ele disputará os recursos comuns com os processos existentes, tais como cabos, discos
compartilhados ou mesmo bloqueios. Tanto a aceleração quanto a escalabilidade são afetadas por esse
fenômeno.
• Distorção (skew). Com a quebra de uma tarefa em um número determinado de passos paralelos
reduzimos o tamanho do passo médio. Nem sempre o tempo de serviço do passo mais lento determinará
o tempo de serviço para a tarefa como um todo. Frequentemente, é difícil dividir uma tarefa em partes
iguais e o modo de estabelecer essas partes é, portanto, distorcido. Por exemplo, se uma tarefa de
tamanho menor que 10 ou de tamanho maior que 10; mesmo que uma tarefa tenha tamanho 20, a
51
aceleração obtida executando as tarefas em paralelo é de apenas 5, em vez de 10, como poderia ser
esperado.
Interconexão de Redes
Os sistemas paralelos são conjuntos de componentes (processadores, memória, e discos) que podem se
comunicar entre si via redes interconectadas. Exemplos de interconexão de redes incluem:
• Bus. Todos os componentes do sistema podem enviar e receber dados em um único bus (cabo) de
comunicação. O bus pode ser uma ethernet ou um interconector paralelo. Arquiteturas com bus
trabalham bem com um pequeno número de processadores. Entretanto, não respondem bem ao
aumento do paralelismo, já que o bus só pode servir a uma comunicação por vez.
• Malha (mesh). Os componentes são organizados como nós de uma grade, e cada componente é
conectado na grade a todos os componentes adjacentes. Em uma malha bidimensional, cada nó é
conectado a quatro nós adjacentes, enquanto em uma malha tridimensional, cada nó é conectado a seis
nós adjacentes. Os nós que não estão diretamente interconectados podem se comunicar roteando
mensagens por meios dos nós intermediários. O número de ligações para comunicação cresce com o
crescimento do número de componentes e a capacidade de comunicação da malha, portanto responde
melhor ao aumento do paralelismo.
• Hipercúbica (hypercube). Os componentes são numerados em binários e um componente é conectado a
outro se a representação binaria de seus números diferirem em exatamente um bit. Assim, cada um dos n
componentes está conectado a log(n) outros componentes. Isso pode ser verificado quando em uma
interconexão hipercúbica uma mensagem de um componente pode alcançar outro por meio de, no
máximo, log(n) ligações. Em contraste, em uma malha, um componente pode manter √�-1 ligacoes com
algum outro componente (ou √�/2 ligacoes, se a interconexão pela malha alcançar as bordas da grade).
Assim, atrasos na comunicação em um hipercubo são significativamente menores que em uma malha.
Arquiteturas de Banco de Dados Paralelo
Há diversos modelos arquitetônicos para máquinas paralelas. Entre elas, as mais promissoras são
mostradas na fig. 16.6 (na figura, M denota memória, P, processador e os discos são representados por cilindros):
• Memória compartilhada. Todos os processadores compartilham uma mesma memória. Esse modelo é
mostrado na fig. 16.6a.
• Disco compartilhado. Todos os processador compartilham o mesmo disco. Esse modelo é mostrado na
fig. 16.6b. Sistemas com discos compartilhados são, às vezes, chamados de clusters.
• Ausência de compartilhamento. Os processadores não compartilham nem a memória nem disco. Esse
modelo é apresentado na figura 16.6c.
• Hierárquico. Esse modelo é mostrado na fig. 16.6d; ele é um hibrido das arquiteturas anteriores.
52
Memória compartilhada
Na arquitetura com memória compartilhada, os processadores e os discos acessam a memória comum,
normalmente, por meio de cabo ou por meio de rede de interconexão. A vantagem da memória compartilhada é
sua extrema eficiência na comunicação entre processadores – qualquer processador pode ter acesso aos dados
em memória compartilhada sem necessidade de ser movido por software. Um processador pode enviar
mensagens a outro processador usando a memória. Essas trocas de mensagens são bem mais rápidas
(normalmente, menos de um microssegundo) se comparadas às que usam mecanismos de comunicação. O
problema das máquinas com memória compartilhada é que a arquitetura não é adequada ao uso de mais de 32
ou 64 processadores, uma vez que o bus ou a interconexão por rede torna-se um gargalo (pois é compartilhado
por todos os processadores). Após determinado ponto, adicionar mais processadores não resolve; eles gastarão a
maior parte de seu tempo esperando sua vez de usar o bus para acesso à memória. Arquiteturas de memória
compartilhada utilizam, normalmente, grande memória cache em cada processador para que o acesso à memória
compartilhada seja evitado sempre que possível. Porém, pelo menos alguns desses dados não estarão em
memória cache e os acessos serão dirigidos à memória compartilhada. Consequentemente, máquinas com
memória compartilhada não possibilitam aumento de escala além de determinado ponto; as máquinas de
memória compartilhada, atualmente, não dão suporte a mais de 64 processadores.
Disco Compartilhado
No modelo de disco compartilhado, todos os processadores podem ter acesso direto a todos os discos, via
interconexão por rede, mas os processadores possuem memórias próprias. Há duas vantagens da arquitetura de
discos compartilhados sobre a de memória compartilhada. Primeiro, uma vez que cada processador possui
memória exclusiva, o bus de memória não representa um gargalo. Segundo, essa arquitetura oferece um modo
barato de aumentar a tolerância a falhas: se o processador (ou sua memória) falha, o outro processador pode
assumir suas tarefas, já que o banco de dados residente nos discos é acessível a todos os processadores. Podemos
fazer o subsistema de discos, ele próprio, tolerante a falhas usando a arquitetura RAID. A arquitetura de discos
compartilhados vem obtendo aceitação em diversos tipos de aplicações; os sistemas construídos sobre
arquitetura desse tipo são frequentemente chamados de clusters.
53
O principal problema dos sistemas de discos compartilhados é, novamente, o grau de crescimento.
Embora o bus de memória não represente mais um gargalo, a restrição é agora a interconexão com o subsistema
de discos; esse caso é particularmente determinante quando o banco de dados acessa muito os discos.
Comparando aos sistemas de memória compartilhada, os sistemas de discos compartilhados podem ser usados
com um número maior de processadores, mas a comunicação entre os processadores é lenta (um pouco acima de
milissegundos quando não há hardware específico para a comunicação), uma vez que ela tem de atravessar a
rede.
Cluster DEC rodando Rdb foi um dos primeiros usuários comerciais a utilizar a arquitetura de discos
compartilhados (o Rdb é atualmente propriedade da Oracle e é chamado de Oracle Rdb).
Ausência de Compartilhamento
Em um sistema sem compartilhamento, cada equipamento de um nó consiste em um processador, uma
memória e discos. O processador de um nó pode comunicar-se com outros processadores de outros nós usando
intercomunicação de rede de alta velocidade. Um nó serve de servidor dos dados alocados em seus discos. Uma
vez que as referências aos discos são atendidas em cada processador por discos locais, o modelo sem
compartilhamento transpõe os percalços de submeter todos os I/Os por meio de uma única rede de
interconexão; somente consultas, acessos a discos remotos e o resultado das relações são transportados por
meio da rede. Além disso, as redes de interconexão dos sistemas sem compartilhamento são normalmente
projetadas para permitir o crescimento de escala, o que significa que sua capacidade aumenta quanto mais nós
são acrescidos. Consequentemente, arquiteturas sem compartilhamento são mais flexíveis quanto à escala e
podem, facilmente, dar suporte a um grande número de processadores. Os principais problemas dos sistemas
sem compartilhamento são os custos de comunicação e os acessos a discos remotos, que são maiores que não
arquitetura com memória ou discos compartilhados, já que a transmissão de dados envolve interação feita por
software em ambos os lados.
A máquina de banco de dados Teradata foi um dos primeiros sistemas comerciais a usar a arquitetura de
banco de dados com ausência de compartilhamento.
Hierárquica
A arquitetura hierárquica combina as características das arquiteturas de compartilhamento de memória e
discos com a arquitetura sem compartilhamento. Em seu nível mais alto, o sistema constitui-se de nós que são
conectados por uma rede sem compartilhar discos ou memória entre si. O topo de linha é um sistema sem
compartilhamento. Cada nó do sistema pode ser um sistema com memória compartilhada entre poucos
processadores. Alternativamente, cada nó poderia ser um sistema de discos compartilhados e cada um desses
sistemas que compartilham um conjunto de discos poderia também compartilhar memória. Desse modo, o
sistema poderia ser construído obedecendo a uma hierarquia, com o compartilhamento de memória por alguns
processadores na base e sem compartilhamento algum no nível mais alto, com possivelmente uma arquitetura de
compartilhamento de discos intermediaria. A fig. 16.6d ilustra uma arquitetura hierárquica de nós com memória
compartilhada conectada por uma arquitetura com ausência de compartilhamento. Sistemas de banco de dados
paralelos comerciais atualmente rodam em diversas dessas arquiteturas.
Tentativas para redução da complexidade de programação desse tipo de sistema resultaram em
arquiteturas de memória virtual distribuída, nas quais há uma única memória lógica compartilhada, mas
fisicamente há diversos sistemas de memória separados; o acoplamento de hardware com mapeamento da
memória virtual por meio de suporte extra de memória oferece uma visa única de área de memória virtual dessas
memórias separadas.
Sistemas Distribuídos
Em um sistema de banco de dados distribuído, o banco de dados é armazenado em diversos
computadores. Os computadores de um sistema de banco de dados distribuído comunica-se com outros por
54
intermédio de vários meios de comunicações, como redes de alta velocidade ou linhas telefônicas. Eles não
compartilha memória principal ou discos. Os computadores em um sistema de banco de dados distribuído podem
variar, quanto ao tamanho e funções, desde estacoes de trabalho até sistemas de grande porte (mainframe).
Os computadores de um sistema de banco de dados distribuído recebem diversos nomes, como sites ou
nós, dependendo do contexto no qual são inseridos. Usaremos preferencialmente o termo site (local, sítio) para
enfatizar a distribuição física desses sistemas. A estrutura geral do sistema distribuído é mostrada na fig. 16.7.
As principais diferenças entre os banco de dados paralelos sem compartilhamento e os banco de dados
distribuídos são que, nos banco de dados distribuídos, há a distribuição física geográfica, administração separada
e uma intercomunicação menor. Outra importante diferença é que, nos sistemas distribuídos, distinguimos
transações locais de globais. Uma transação local acessa um único site, justamente no qual ela se inicia. Uma
transação global, por outro lado, é aquela que busca acesso a diferentes sites, ou a outro site além daquele em
que se inicia.
Exemplo Ilustrativo
Considere o sistema de uma empresa da área bancária que consiste em quatro agências em quatro
cidades diferentes. Cada agência possui seu próprio computador, com um banco de dados abrangendo todas as
contas referentes àquela agência.
Cada uma dessas instalações é, assim, um site. Há também um único site que mantem informações sobre
todas as agências do banco. Cada agência mantém (entre outras) uma relação conta (Esquema_conta), em que:
Esquema_conta = (nome_agência, número_conta, saldo)
O site que mantém informações sobre as quatro agências possui a relação agência(Esquema_agência), em
que:
Esquema_agência = (nome_agência, cidade_agência, fundos)
Há outras relações nos diversos sites; nós a ignoramos em nosso exemplo.
Para ilustrar a diferença entre os dois tipos de transações, consideramos a transação de adicionar 50
dólares à conta A-177 localizada na agência Valleyview. Se uma transação foi iniciada na agência Valleyview, ela é
então considerada local; caso contrário, será considerada global. Uma transação para transferir 50 dólares da
conta A-177 para a conta A-305, a qual está localizada na agência Hillside, é uma transação global, uma vez que
conta em sites diferentes sofrem acessos como resultado de sua execução.
O que faz dessa configuração um sistema de banco de dados distribuído são os seguintes aspectos:
55
• Os vários sites estão disponíveis entre si.
• Os sites compartilham um esquema global comum, embora algumas relações possam estar armazenadas
em alguns sites.
• Cada site proporciona um ambiente para execução tanto de transações locais quanto de transações
globais.
• Cada site roda o mesmo software para o gerenciamento de banco de dados.
Se houver sistemas gerenciadores de banco de dados diferentes rodando nos sites, torna-se difícil o
gerenciamento de transações globais. Tais sistemas são chamados de sistemas de banco de dados múltiplos
(multidatabase) ou sistemas de banco de dados distribuídos heterogêneos.
Tradeoffs
Há diversas razoes para a utilização de sistemas de banco de dados distribuídos, como o
compartilhamento de dados, a autonomia e a disponibilidade.
• Compartilhamento de dados. A maior vantagem de um sistema de banco de dados distribuído é criar um
ambiente no qual os usuários de um site podem ter acesso a dados residentes em outros sites. Por
exemplo, no sistema distribuído bancário usado como exemplo, os usuários de uma agência podem ter
acesso aos dados de outra agência. Sem essa disponibilidade, um usuário que desejasse transferir fundos
de uma agência para outra teria de recorrer a algum mecanismo externo.
• Autonomia. A primeira vantagem do compartilhamento dos dados por meio da distribuição dos dados é
que cada site pode manter certo nível de controle sobre os dados que estão armazenados localmente. Em
sistemas centralizados, o administrado do banco de dados central é quem gerencia o banco de dados. Em
sistemas de banco de dados distribuídos há um administrador geral responsável pelo banco como um
todo. Uma parte dessa responsabilidade é delegada ao administrador local de cada site. Dependendo do
projeto do banco de dados distribuído, os administradores podem possuir diferentes graus de autonomia
local é provavelmente uma das maiores vantagens dos banco de dados distribuídos.
• Disponibilidade. Se um site sai do ar em um sistema distribuído, os demais sites podem continuar em
operação. Particularmente, se os itens de dados são replicados em diversos sites, uma transação que
precise de um item de dado em particular pode encontrar tal item presente em diversos sites. Assim, a
queda de um site não implica, necessariamente, a queda do sistema.
A queda de um site precisa ser detectada pelo sistema, assim como determinadas ações devem ser
executadas para recuperá-lo da falha. O sistema não poderá mais usar os serviços do site fora do ar. Finalmente,
quando um site volta a funcionar ou quando é consertado, é necessário dispor de mecanismos para integrá-lo
paulatinamente ao sistema.
Embora a recuperação de uma falha seja mais complexa nos sistemas distribuídos que nos sistemas
centralizados, a capacidade da maioria dos sistemas manter-se em operação a despeito da falha de um site acaba
por aumentar a disponibilidade. A disponibilidade é crucial para os sistemas de banco de dados usados em
aplicações de tempo real. A perda do acesso aos dados em, por exemplo, uma companhia aérea pode fazer com
que um cliente em potencial prefira viajar com uma companhia concorrente.
A principal desvantagem dos sistemas de banco de dados distribuídos é o acréscimo de complexidade
necessário para assegurar a coordenação entre os sites. Esse aumento de complexidade toma diversas formas:
• Custo de desenvolvimento de software. É mais difícil implementar sistemas de banco de dados
distribuídos, portanto, o custo é mais alto.
• Maior possibilidade de bugs. Uma vez que os sites que constituem o sistema distribuído operam em
paralelo, é difícil assegurar a precisão dos algoritmos, especialmente durante a ocorrência e recuperação
de falha em parte do sistema. Há, potencialmente, a chance de bugs extremamente sutis.
56
• Aumento do processamento e overhead. A troca de mensagens e processamento adicional necessários à
coordenação entre sites são uma forma de overhead que não ocorre nos sistemas centralizados.
Na escolha do projeto do sistema de banco de dados, o projetista deve ponderar as vantagens e
desvantagens da distribuição dos dados. Há diversas abordagens para um projeto de banco de dados distribuído,
partindo de projetos totalmente distribuídos até os que mantêm alto nível de centralização.
Tipos de Redes
Sistemas de banco de dados distribuídos e sistemas cliente-servidor são apoiados em redes de
comunicação. Há basicamente dois tipos de redes: redes locais (local-area networks – LAN) e redes de longa
distância (wide-area networks – WAN). A principal diferença entre as duas é o modo pelo qual são distribuídas
geograficamente. Redes locais são compostas por processadores distribuídos sobre pequenas extensões
geográficas, como um único edifício ou alguns prédios próximos. Redes de longa distância, por outro lado, são
compostas por determinado número de processadores autônomos, distribuídos por uma extensa área geográfica.
Essas diferenças envolvem maiores variações na velocidade e confiabilidade das redes de comunicação e se
refletem no projeto do sistema operacional.
Redes Locais
As redes locais (LANs) apareceram no início dos anos 70 como meio de comunicação entre computadores
e para compartilhamento de dados. Percebeu-se que, em diversas empresas, numerosos pequenos
computadores, cada um com suas próprias aplicações, são mais econômicos que um único grande sistema. Como
cada pequeno equipamento provavelmente necessita de acesso a um grande número de dispositivos periféricos
(como discos e impressoras) e como a necessidade de alguma forma de compartilhamento de dados é
frequentemente em uma empresa, a consequência natural foi a conexão desses pequenos sistemas em uma rede
de computadores.
As LANs são normalmente projetadas para cobrir uma pequena área geográfica e são, geralmente, usadas
me escritórios. Todos os sites deste tipo de sistema estão próximos entre si, assim a comunicação entre eles
tende a manter velocidades mais altas e menores taxas de erro que as apresentadas pelas redes de longa
distância. O tipo de ligação mais comum entre os computadores de uma rede local é o par trançado, cabo coaxial
de banda larga e fibra ótica. A velocidade de comunicação gira em torno de um megabyte por segundo, para rede
como Appletalk e IBM, redes lentas em anel (token ring), até um gigabit por segundo, para redes óticas
experimentais. Dez megabits por segundo é bastante comum, é essa a velocidade da Ethernet. As redes de fibra
ótica FDDI (optical-fiber-based) e Fast Ethernet rodam a cem megabits por segundo. Redes com base no
protocolo chamado protocolo assíncrono (asynchronous transfer mode – ATM) podem alcançar velocidades
superiores, como 144 megabits por segundo, e estão se tornando bastante populares.
Uma LAN típica consiste em diferentes estações de trabalho, um ou mais sistemas servidores, vários
dispositivos periféricos compartilhados (como impressora a laser ou unidades de fita magnética) e um ou mais
gateways (processadores especializados) que proporcionam acesso a outras redes (fig. 16.8). o esquema Ethernet
é usado com frequência em LANs.
57
Redes de Longa Distância
As redes de longa distância (WANs) apareceram no final da década de 1960, principalmente em projetos
de pesquisas acadêmicas para comunicação eficiente entre sites, permitindo que o hardware e o software
pudessem ser compartilhados conveniente e economicamente entre a grande comunidade de usuários. Os
sistemas que permitiram a conexão de terminais remotos com um computador central via linhas telefônicas
foram desenvolvidos no início da década de 1960, embora não fossem de fato uma WAN. A primeira WAN
projetada e desenvolvida foi a Arpanet. Os trabalhos na Arpanet começaram em 1968. A Arpanet desenvolveu-se
a partir de quatro redes experimentais até chegar à rede mundial, a Internet, compreendendo milhões de
sistemas computacionais. A ligação característica da WAN são circuitos telefônicos que usam linhas de fibra ótica
e (por vezes) canais de satélite.
Como exemplo, consideremos a Internet, que conecta computadores pelo mundo. O sistema possibilita
que hosts em sites geograficamente separados comuniquem-se entre si. Os computadores hosts diferem uns dos
outros no tipo, velocidade, tamanho da palavra, sistema operacional, etc. Os hosts são, geralmente, LANs
conectadas a redes regionais. As redes regionais são interligadas a roteadores para formar a rede mundial. As
conexões entre as redes usam frequentemente o serviço de telefonia chamado T1, que oferece taxas de
transferência de cerca de 44.736 megabits por segundo. As mensagens enviadas para a rede são roteadas por
sistemas chamados de roteadores, que controlam o caminho percorrido por cada mensagem através da rede.
Esse roteamento pode ser dinâmico, para aumentar a eficiência da comunicação, ou estático, para reduzir riscos
ou permitir que a carga de comunicação seja processada mais facilmente.
Outras WANs em operação usam linhas telefônicas padrão como principal meio de comunicação. Os
modems são dispositivos que recebem sinal digital de um computador e convertem esses dados em sinais
analógicos, que são usados pelo sistema de telefonia. Um modem no site de destino converte o sinal analógico
em digital e, assim, o equipamento de destino recebe o dado. A velocidade dos modems varia de 2400 bips a 32
kilobits por segundo. Os sistemas de telefonia que aceitam o padrão Rede Digital de Serviços Integrados
(Integrated Services Digital Network – ISDN) permitem que os dados sejam transferidos ponto a ponto a altas
taxas, normalmente 128 kilobits por segundo.
A rede UNIX, UUCCP, permite que os sistemas se comuniquem uns com os outros um número limitado de
vezes (e, geralmente, predeterminado), via modems, para troca de mensagens. Essas mensagens são roteadas
para outro sistema próximo e, dessa forma, propagadas para todos os hosts da rede (mensagens publicas) ou
transferidas para seu destino (mensagens particulares).
58
As WANs são classificadas em dois tipos:
• WAN conexão descontínua, como aquelas que têm por base a UUCP, em que os hosts estão conectados à
rede somente por determinados períodos.
• WAN conexão contínua, como a Internet, cujos hosts estão conectados à rede o tempo todo.
O projeto de um sistema de banco de dados distribuído é fortemente influenciado pelo tipo de WAN de
apoio. Os verdadeiros sistemas de banco de dados distribuídos podem rodar apenas sobre as redes conectadas
continuamente – pelo menos durante as horas em que o banco de dados distribuído está operacional.
Redes que não estão continuamente conectadas, geralmente, não permitem transações entre sites, mas
tomam cópias locais dos dados remotos e atualizam periodicamente essas cópias (toda noite, por exemplo). Para
aplicações cuja consistência não seja crítica, como compartilhamento de documentos, sistemas de trabalho em
grupo (groupware systems) como o Lotus Notes, permitem atualizações em dados remotos feitos localmente e
essas atualizações retornam periodicamente ao site remoto. Há conflito potencial de atualizações entre sites que
precisa ser detectado e resolvido. Um mecanismo para detecções de atualizações conflitantes existe; o
mecanismo para resolução de conflitos de atualização, entretanto, é dependente da aplicação.
Arquitetura de sistemas de bancos de dados
INTRODUÇÃO
Agora temos condições de apresentar uma arquitetura para um sistema de bancos de dados. Nosso
objetivo ao apresentar essa arquitetura é fornecer um arcabouço sobre o qual possamos desenvolver os capítulos
subsequentes. Esse arcabouço é útil para descrever conceitos gerais de bancos de dados e explicar a estrutura de
sistemas de bancos de dados específicos — mas não afirmamos que todo sistema pode se enquadrar bem nesse
arcabouço em particular, nem queremos sugerir que essa arquitetura prevê o único arcabouço possível. Em
especial, é provável que sistemas “pequenos” (ver Capítulo 1) não ofereçam suporte para todos os aspectos da
arquitetura. Porém, a arquitetura em questão de fato parece se ajustar razoavelmente bem à maior parte dos
sistemas; além disso, ela é basicamente idêntica à arquitetura proposta pelo ANSI/SPARC Study Group on Data
Base Management Systems (a chamada arquitetura ANSI/SPARC — consulte as referências [2.1-2.2]). Contudo,
optamos por não seguir a terminologia ANSI/SPARC em todos os detalhes.
OS TRÊS NÍVEIS DA ARQUITETURA
A arquitetura ANSI/SPARC se divide em três níveis, conhecidos como nível interno, nível conceitual e nível
externo, respectivamente (ver Figura 2.1). De modo geral:
• O nível interno (também conhecido como nível físico) é o mais próximo do meio de armazenamento físico — ou
seja, é aquele que se ocupa do modo como os dados são fisicamente armazenados.
• O nível externo (também conhecido como nível lógico do usuário) é o mais próximo dos usuários — ou seja, é
aquele que se ocupa do modo como os dados são vistos por usuários individuais.
• O nível conceitual (também conhecido como nível lógico comunitário, ou às vezes apenas nível indireto, sem
qualificação) é um nível de “simulação” entre os outros dois.
Observe que o nível externo se preocupa com as percepções dos usuários individuais, enquanto o nível
conceitual está preocupado com uma percepção da comunidade de usuários. Em outras palavras, haverá muitas
“visões externas” distintas, cada qual consistindo em uma representação mais ou menos abstrata de alguma
parte do banco de dados completo, e haverá exatamente uma “visão conceitual”, consistindo em uma
representação analogamente abstrata do banco de dados em sua totalidade.* (Lembre-se de que a maioria dos
usuários não estará interessada em todo o banco de dados, mas somente em alguma porção restrita do banco de
dados.) Do mesmo modo, haverá precisamente uma “visão interna”, representando o modo como o banco de
dados está fisicamente armazenado.
59
Um exemplo ajudará a esclarecer essas ideias. A Figura 2.2 mostra a visão conceitual, a visão interna
correspondente e duas visões externas correspondentes (uma para um usuário PL/I e outra para um usuário
COBOL), todas para um simples banco de dados de pessoal. É claro que o exemplo é inteiramente hipotético —
ele não pretende se assemelhar a qualquer sistema real — e muitos detalhes irrelevantes foram deliberadamente
omitidos. Explicação:
• No nível conceitual, o banco de dados contém informações 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 dígitos decimais).
• No nível interno, os empregados são representados por um tipo de registro armazenado, denominado
EMP_ARMAZENADO, com vinte bytes de comprimento. EMP_ARMAZENADO contém quatro campos
armazenados: um prefixo de seis bytes (presumivelmente contendo informações de controle, tais como flags ou
ponteiros) e três campos de dados correspondentes às três propriedades de empregados. Além disso, os registros
EMP_ARMAZENADO são indexados sobre o campo EMP# por um índice chamado EMPX, cuja definição não é
mostrada.
• O usuário PL/I tem uma visão externa do banco de dados na qual cada empregado é representado por um
registro PL/I que contém dois campos (números de departamentos não são de interesse para esse usuário, e por
isso foram omitidos da visão). O tipo de registro é definido por uma declaração de estrutura PL/I comum, de
acordo com as regras normais de PL/I.
• De modo semelhante, o usuário COBOL tem uma visão externa em que cada empregado é representado por um
registro COBOL contendo, mais uma vez, dois campos (agora, foram omitidos os salários). O tipo de registro é
definido por uma descrição 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 referência ao número do empregado é chamada EMP# na visão externa de PL/I, EMPNO na visão
externa COBOL, NUMERO EMPREGADO na visão conceitual e novamente EMP# na visão interna. É claro que o
sistema deve estar ciente das correspondências; 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 representação
60
em questão envolve construções como registros e campos, mais orientadas para o usuário, em oposição a
construções como bits e bytes, mais orientadas para a máquina.
Observe que faz pouca diferença para as finalidades deste capítulo saber se o sistema que está sendo
considerado é relacional ou não. Contudo, pode ser útil indicar de forma resumida como os três níveis da
arquitetura são em geral percebidos especificamente em um sistema relacional:
• Primeiro, o nível conceitual em tal sistema será definitivamente relacional, no sentido de que os objetos visíveis
nesse nível serão tabelas relacionais, e os operadores serão operadores relacionais (incluindo, em especial, os
operadores de restrição e projeção examinados de forma abreviada no Capítulo 1).
• Em segundo lugar, uma determinada visão externa também será tipicamente relacional, ou algo muito próximo
disso; por exemplo, as declarações de registros PL/I ou COBOL da Figura 2.2 podem ser consideradas de maneira
informal, respectivamente, os equivalentes PL/I ou COBOL da declaração de uma tabela relacional em um sistema
relacional.
Nota: devemos mencionar de passagem que o termo “visão externa” (em geral abreviado apenas como “visão”)
infelizmente tem um significado bastante específico em contextos relacionais que não é idêntico ao significado
atribuído ao termo neste capítulo. Consulte os Capítulos 3 e 9 para ver uma explicação e uma descrição do
significado relacional.
• Terceiro, o nível interno não será relacional, porque os objetos nesse nível não serão apenas tabelas relacionais
(armazenadas) — em vez disso, eles serão os mesmos tipos de objetos encontrados no nível interno de qualquer
outra espécie de sistema (registros armazenados, ponteiros, índices, hashing etc.). De fato, o modelo relacional
em si não tem absolutamente nenhuma relação com o nível interno; ele se preocupa, como vimos no Capítulo 1,
com o modo como o banco de dados é visto pelo usuário.
Agora vamos prosseguir com o exame dos três níveis da arquitetura com um nível muito maior de
detalhes, começando pelo nível externo. Em toda a nossa descrição, faremos repetidas referências à Figura 2.3,
que mostra os principais componentes da arquitetura e seus inter-relacionamentos pelo administrador de banco
de dados (DBA) .
61
62
O NÍVEL EXTERNO O nível externo é o nível do usuário individual. Como foi explicado no Capítulo 1, um determinado usuário pode ser ou programador de aplicações ou um usuário final com qualquer grau de sofisticação. (O DBA é um caso especial importante; porém, diferentemente de outros usuários, o DBA também precisará estar interessado nos níveis conceitual e interno. Consulte as duas seções seguintes.)
Cada usuário tem uma linguagem à sua disposição: • Para o programador de aplicações, essa linguagem será uma linguagem de programação convencional (como PL/I, C+ +, Java) ou uma linguagem proprietária específica para o sistema em questão. Essas linguagens proprietárias são frequentemente chamadas de linguagens de “quarta geração” (L4Gs), pelo fato (muito difuso!) de que (a) o código de máquina, a linguagem assembler e a linguagem PL/I podem ser consideradas como três “gerações” mais antigas de linguagens e (b) as linguagens proprietárias representam o mesmo tipo de aperfeiçoamento em relação às linguagens de “terceira geração” (L3Gs) que essas linguagens representavam em relação à linguagem assembler e esta última, por sua vez, representava em relação ao código de máquina. • Para o usuário final, a linguagem será uma linguagem de consulta ou alguma linguagem de uso especial, talvez dirigida por formulários ou menus, adaptada aos requisitos desse usuário e com suporte de algum programa aplicativo on-line.
Para nossos propósitos, o ponto importante sobre todas essas linguagens é que elas incluirão uma sublinguagem de dados — isto é, um subconjunto da linguagem completa relacionado de modo específico aos objetos e às operações 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 é responsável pelo fornecimento de diversos recursos não relacionados com bancos de dados, como variáveis locais, operações de cálculo, lógica de desvios condicionais (if-then-else), e assim por diante. Um dado sistema poderia admitir qualquer número de linguagens hospedeira e qualquer número de sublinguagens de dados; porém, uma determinada sublinguagem de dados reconhecida por quase todos os sistemas atuais é a linguagem SQL, discutida brevemente no Capítulo 1. A maioria desses sistemas permite que a SQL seja usada tanto de modo interativo como uma linguagem de consulta autônoma, quanto incorporada a outras linguagens como PL/I ou Java (consulte o Capítulo 4 para ver detalhes adicionais). Observe que, embora seja conveniente para propósitos arquiteturais distinguir entre a sublinguagem de dados e
63
a linguagem hospedeira que a contém, as duas podem de fato não ser distintas para o usuário; na verdade, talvez seja preferível sob a perspectiva do usuário que elas não sejam distintas. Se elas não forem distintas, ou se só puderem ser distinguidas com dificuldade, diremos que elas estão fortemente acopladas. Se forem clara e facilmente distinguíveis, dizemos que elas estão fracamente acopladas. Apesar de alguns sistemas comerciais (em especial sistemas de objetos — ver Capítulo 24) admitirem o acoplamento forte, a maioria não 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 usuário, mas sem dúvida envolve maior esforço por parte dos desenvolvedores de sistemas, um fato que presumivelmente contribui para o status quo.) Em princípio, qualquer sublinguagem de dados determinada é, na realidade, uma combinação de pelo menos duas linguagens subordinadas — uma linguagem de definição de dados (DDL — Data Definition Language), que dá suporte à definição ou à declaração de objetos dos bancos de dados, e uma linguagem de manipulação de dados (DML — Data Manipulation Language), que admite a manipulação ou o processamento desses objetos. Por exemplo, considere o usuário PL/I da Figura 2.2, na Seção 2.2. A sublinguagem de dados para esse usuário consiste nos recursos de PL/I utilizados para a comunicação com o SGBD: • A parte de DDL consiste nas construções declarativas de PL/I necessárias para se declararem objetos do banco de dados — a própria instrução DECLARE(DEL), certos tipos de dados de PL/I, possivelmente extensões especiais de PL/I para oferecer suporte a novos objetos não manipulados pela PL/I existente. • A parte da DML consiste nas instruções executáveis de PL/I que transferem informações de e para o banco de dados — mais uma vez incluindo, possivelmente, novas instruções especiais. Nota: mas precisamente, devemos dizer que a PL/I não inclui na realidade nenhum recurso específico de bancos de dados na época em que este livro foi escrito. Em particular, as instruções de “DML” costumam ser apenas instruções CALL de PL/I que invocam o SGBD (embora essas chamadas possam estar sintaticamente disfarçadas de algum modo, a fim de torná-las um pouco mais amistosas para o usuário — consulte a discussão sobre a SQL embutida no Capítulo 4).
Voltando à arquitetura: já indicamos que um usuário individual geralmente só estará interessado em alguma parte do banco de dados como um todo; além disso, a visão que esse usuário tem dessa parte será em geral um tanto abstrata quando comparada com o modo como os dados estão fisicamente armazenados. O termo ANSI/SPARC para a visão de um usuário individual é visão externa. Uma visão externa é, portanto, o conteúdo do banco de dados visto por algum usuário determinado (ou seja, para esse usuário a visão externa é o banco de dados). Por exemplo, um usuário do Departamento de Pessoal poderia considerar o banco de dados uma coleção de ocorrências de registros de departamentos e empregados, e ele poderia não ter nenhum conhecimento das ocorrências de registros de fornecedores e peças vistas pelos usuários do Departamento de Compras.
Nível Conceitual A visão conceitual é uma representação de todo conteúdo de informação de informações do banco de dados, mais uma vez (como no caso de uma visão externa) em uma forma um tanto abstrata, em comparação com o modo como os dados são visualizados por qualquer usuário em particular. Em termos gerais, a visão conceitual pretende ser uma visão dos dados “como eles realmente são”, em vez de forçar os usuários a vê-los pelas limitações (por exemplo) da linguagem ou do hardware que eles possam estar utilizando. A visão conceitual consiste em muitas ocorrências de cada um dos vários tipos de registros conceituais. Por exemplo, ela pode consistir em uma coleção de ocorrências de registros de departamentos, junto com uma coleção de ocorrências de registros de empregados, junto com uma coleção de ocorrências de registros de fornecedores, mais uma coleção de ocorrências de registros de peças, e assim por diante. Um registro conceitual não é necessariamente o mesmo que um registro externo, nem o mesmo que um registro armazenado. A visão conceitual é definida por meio do esquema conceitual, que inclui definições de cada um dos vários tipos de registros conceituais (mais uma vez, observe um exemplo simples da fig. 2.2). o esquema conceitual é escrito por meio de outra linguagem de definição de dados, a DDL conceitual. Se quisermos alcançar a independência física dos dados, então essas definições de DDL conceitual não deverão envolver quaisquer considerações sobre a representação física ou a técnica conceitual, não deverá haver nenhuma referência a representações de campos armazenados, sequencias de registros armazenados, índices, esquemas de hashing, ponteiros ou quaisquer outros detalhes de armazenamento e acesso. Se o esquema conceitual se tornar verdadeiramente independente de dados dessa maneira, então os esquemas externos, definidos em termos do esquema conceitual, também são independentes dos dados. Portanto, a visão conceitual é uma visão do conteúdo total do banco de dados, e o esquema conceitual é uma definição dessa visão. Porém, seria enganoso sugerir que o esquema conceitual nada mais é do que um
64
conjunto de definições muito semelhante às definições de registros simples, encontradas hoje em (por exemplo) um programa COBOL. As definições no esquema conceitual têm por finalidade incluir muitos recursos adicionais, como as restrições de segurança e integridade. Algumas autoridades no assunto chegariam até a sugerir que o objetivo final do esquema conceitual é descrever a empresa inteira – não apenas seus dados em si, mas também o modo como esses dados são usados; como eles fluem de um ponto para outro dentro da empresa, para q eles são usados em cada ponto, quais controles de auditoria ou outros controles devem ser aplicados em cada ponto, e assim por diante. No entanto, devemos enfatizar que nenhum sistema atual admite realmente um esquema conceitual q sequer se aproxime desse grau de complexidade; na maior parte dos sistemas existentes, o “esquema conceitual” é, na verdade, pouco mais que uma simples união de todos os esquemas externos individuais, juntamente com determinadas restrições de segurança e integridade. Porém, sem dúvida, é possível q sistemas futuros eventualmente se tornem muito mais sofisticados em seu suporte ao nível conceitual. O NÍVEL INTERNO
O terceiro nível da arquitetura é o nível interno. A visão interna é uma representação de baixo nível do banco de dados por inteiro; ela consiste em muitas ocorrências de cada um dos vários tipos de registros internos. “Registro interno” é o termo ANSI/SPARC que representa a construção que temos chamado de registro armazenado (e continuaremos a usar essa última forma). Assim, a visão interna ainda está muito afastada do nível físico, pois ela não lida com registros físicos — também chamados blocos ou páginas — nem com quaisquer considerações específicas de dispositivos, como tamanhos de cilindros ou trilhas. Em outras palavras, a visão interna pressupõe efetivamente um espaço de endereços linear infinito; os detalhes de como esse espaço de endereços é mapeado no meio de armazenamento físico são bastante específicos para cada sistema e foram deliberadamente omitidos da arquitetura geral. Nota: o bloco, ou a página, é a unidade de entrada e saída (E/S) — isto é, ele representa a quantidade de dados transferidos entre o meio de armazenamento secundário e a memória principal em uma única operação de E/S. Os tamanhos de páginas típicos são 1 K, 2 K ou 4 K bytes (K = 1.024). A visão interna é descrita por meio do esquema interno, que não somente define os diversos tipos de registros armazenados mas também especifica quais índices existem, como os campos armazenados estão representados, em que sequência física estão 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 definição 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 “visão interna”, e ainda “definição de estrutura de armazenamento” em lugar de “esquema interno”.
Para encerrar lembramos que, em certas situações excepcionais, os programas aplicativos — em particular as aplicações de natureza utilitária (ver Seção 2.11) — podem ter permissão para operar diretamente no nível interno, e não no nível externo. Não é preciso dizer que essa prática não é recomendável; ela representa um risco de segurança (pois as restrições de segurança são ignoradas) e um risco de integridade (pois também as restrições de integridade são ignoradas), e o programa terá uma inicialização dependente dos dados; porém, às vezes essa poderá ser a única maneira de obter a funcionalidade ou o desempenho exigido — do mesmo modo o usuário em uma linguagem de programação de alto nível poderia ter a necessidade ocasional de descer até a linguagem assembler para satisfazer certos objetivos de funcionalidade ou desempenho.
MAPEAMENTOS Além dos três níveis básicos, a arquitetura da Figura 2.3 envolve, em geral, certos mapeamentos — um mapeamento conceitual/interno e vários mapeamentos externos/conceituais: • O mapeamento conceitual/interno define a correspondência entre a visão conceitual e o banco de dados armazenado; ele especifica o modo como os registros e campos conceituais são representados no nível interno. Se a estrutura do banco de dados armazenado for alterada — isto é, se for efetuada uma mudança na definição do banco de dados armazenado – o mapeamento conceitual/interno terá de ser alterado de acordo, a fim de q o esquema conceitual possa permanecer invariável. (é responsabilidade do DBA, ou provavelmente, do SGBD, administrar tais alterações.) Em outras palavras, os efeitos dessas mudanças devem ser isolados abaixo do nível conceitual, a fim de preservar a independência de dados física. • Definir o esquema interno
65
O DBA também deve decidir como serão representados os dados no banco de dados armazenado. Em geral, esse processo é chamado projeto de banco de dados físico.* Tendo elaborado o projeto físico, o DBA deve então criar a definição da estrutura de armazenamento correspondente (isto é, o esquema interno), usando a DDL interna. Além disso, ele também deve definir o mapeamento conceitual/interno associado. Na prática, a DDL conceitual ou a DDL interna — mais provavelmente a primeira — deverá incluir os meios para definir esse mapeamento, mas as duas funções (criação do esquema, definição do mapeamento) devem ser claramente distinguíveis. Como no caso do esquema conceitual, o esquema interno e o mapeamento correspondente existirão tanto na forma de fonte quanto de objeto. • Ligação com usuários É tarefa do DBA fazer a ligação com os usuários, a fim de garantir que os dados de que eles necessitam estarão disponíveis, e escrever (ou ajudar os usuários a escreverem) os esquemas externos necessários, usando a DDL externa aplicável. (Como já foi dito, um dado sistema pode admitir várias DDLs externas distintas.) Além disso, os mapeamentos externos/conceituais correspondentes também devem ser definidos. Na prática, a DDL externa provavelmente incluirá os meios para especificar esses mapeamentos, mas, de novo, os esquemas e os mapeamentos devem ser claramente distinguíveis. Cada esquema externo e o mapeamento correspondente deverão existir tanto na forma de fonte quanto de objeto. Outros aspectos da função de ligação com o usuário incluem a consultoria em projeto de aplicações, o fornecimento de instrução técnica, a assistência para determinação e resolução de problemas e serviços profissionais semelhantes. • Definir restrições de segurança e integridade Como já vimos, as restrições de segurança e integridade podem ser consideradas uma parte do esquema conceitual. A DDL conceitual deve incluir recursos para a especificação de tais restrições. • 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 crítico 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 questão com um mínimo de demora e com o menor efeito possível sobre o restante do sistema. Por exemplo, em condições ideais, a disponibilidade dos dados que não tenham sido danificados não deve ser afetada. O DBA tem de definir e implementar um esquema apropriado de controle de danos, em geral envolvendo (a) descarga periódica ou dumping do banco de dados para o meio de armazenamento de backup e (b) recarregamento do banco de dados quando necessário, a partir do dump mais recente. A propósito, a discussão anterior fornece uma razão pela qual seria uma boa ideia espalhar a coleção total de dados por vários 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 é, instalações de bancos de dados comerciais que armazenam bem mais de um trilhão de bytes de dados, em termos informais — e que os sistemas do futuro deverão ser muito maiores. E desnecessário dizer que tais sistemas VLDB (“banco de dados muito grande” — very large database) exigem administração muito cuidadosa e sofisticada, em especial se houver um requisito de disponibilidade contínua (que normalmente existe). Não obstante, por simplicidade, continuaremos a falar como se de fato houvesse um único banco de dados. * Observe a sequência: primeiro, defina que dados você deseja; depois, decida como representá-los no meio de armazenamento.
O projeto físico sempre deve ser feito depois do projeto lógico. **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 bilhão de bytes (a abreviatura BB é empregada às vezes em lugar de GB).
66
• Monitorar o desempenho e responder a requisitos de mudanças Como foi indicado na Seção 1.4, o DBA é responsável pela organização 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 necessário reorganizar o banco de dados armazenado de tempos em tempos para assegurar que os níveis de desempenho permanecerão aceitáveis. Como já mencionamos, qualquer mudança no nível de armazenamento físico (interno) do sistema deve ser acompanhada por uma mudança correspondente na definição do mapeamento de nível conceitual/interno, de modo que o esquema conceitual possa permanecer constante. E claro que a lista anterior não esgota o assunto — ela pretende apenas dar uma ideia da extensão e da natureza das responsabilidades do DBA. 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 usuário 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 versões objeto desse esquema) para esse usuário, o mapeamento externo/conceitual correspondente, o esquema conceitual, o mapeamento conceitual/interno e a definição da estrutura de armazenamento. 4. O SGBD executa as operações necessárias sobre o banco de dados armazenado. Como exemplo, considere as ações relacionadas com a busca de uma determinada ocorrência de registro externo. Em geral, serão necessários campos de várias ocorrências de registros conceituais e, por sua vez, cada ocorrência de registro conceitual exigirá campos de várias ocorrências de registros armazenados. Então, conceitualmente, o SGBD deve primeiro buscar todas as ocorrências necessárias de registros armazenados, depois construir as ocorrências de registros conceituais exigidas e, em seguida, construir a ocorrência de registro externo. Em cada estágio, podem ser necessárias conversões de tipos de dados ou outras conversões. Naturalmente, a descrição anterior é muito simplificada; em particular, ela implica que todo o processo é interpretativo, à medida que sugere que os processos de análise do pedido, inspeção dos diversos esquemas etc., são todos realizados durante a execução. A interpretação, por sua vez, em geral implica um desempenho sofrível devido à sobrecarga em tempo de execução. Porém, na prática talvez seja possível fazer os pedidos de acesso serem compilados antes do momento da execução (em particular, diversos produtos atuais de SQL fazem isso — consulte as anotações relativas às referências [4.12] e [4.26] do Capítulo 4). Vamos examinar agora as funções do SGBD com um pouco mais de detalhes. Essas funções incluirão o suporte a pelo menos todos os itens a seguir (observe a Figura 2.4): • Definição de dados O SGBD deve ser capaz de aceitar definições 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 definição de dados (DDLs). O SGBD também deve “entender” as definições da DDL, no sentido de que, por exemplo, ele “entende” que os registros externos EMPREGADO incluem um campo SALARIO; ele deve então ser capaz de usar esse conhecimento para analisar e responder a pedidos de manipulação de dados (por exemplo, “obtenha todos os empregados com salário < R$ 50.000,00”). • Manipulação de dados O SGBD deve ser capaz de lidar com solicitações do usuário para buscar, atualizar ou excluir dados existentes no banco de dados, ou para acrescentar novos dados ao banco de dados. Em outras
67
palavras, o SGBD deve incluir um componente processador de DML ou compilador de DML para lidar com a linguagem de manipulação de dados (DML — data manipulation language). Em geral, as solicitações de DML podem ser “planejadas” ou “não-planejadas”: a. Uma solicitação planejada é aquela para a qual a necessidade foi prevista com bastante antecedência em relação ao momento em que a solicitação é executada. O DBA provavelmente terá ajustado o projeto de banco de dados físico de modo a garantir um bom desempenho para solicitações planejadas. b. Em contraste, uma solicitação não-planejada é uma consulta ad hoc, isto é, uma solicitação cuja necessidade não foi prevista com antecedência mas, em vez disso, surgiu no último instante. O projeto de banco de dados físico pode estar ou não adaptado de forma ideal para a solicitação específica sendo considerada. Para usar a terminologia introduzida no Capítulo 1 (Seção 1.3), as solicitações planejadas são características de aplicações “operacionais” ou “de produção”, ao passo que as solicitações não-planejadas são características de aplicações para “apoio à decisão”. Além disso, as solicitações planejadas em geral serão emitidas a partir de programas aplicativos escritos previamente, enquanto as solicitações não-planejadas serão, por definição, emitidas de modo interativo por meio de algum processador de linguagem de consulta. Nota: como vimos no Capítulo 1, o processador de linguagem de consulta é na realidade uma aplicação on-line embutida, não uma parte do SGBD per se; ele foi incluído na Figura 2.4 por completitude. • Otimização e execução As requisições de DML, planejadas ou não-planejadas, devem ser processadas pelo componente otimizador, cujo propósito é determinar um modo eficiente de implementar a requisição. A otimização é discutida em detalhes no Capítulo 17. As requisições otimizadas são então executadas sob o controle do gerenciador em tempo de execução (run time). Nota: na prática, o gerenciador em tempo de execução provavelmente invocará algum tipo de gerenciador de arquivos para obter acesso aos dados armazenados. Os gerenciadores de arquivos são descritos resumidamente no final desta seção. • Segurança e integridade de dados O SGBD deve monitorar requisições de usuários e rejeitar toda tentativa de violar as restrições de segurança e integridade definidas pelo DBA (consulte a seção anterior). Essas tarefas podem ser executadas em tempo de compilação ou em tempo de execução, ou ainda em alguma mistura dos dois. • Recuperação e concorrência de dados O SGBD — ou, mais provavelmente, algum outro componente de software relacionado, cm geral chamado gerenciador de transações ou monitor de processamento de transações (monitor TP) — deve impor certos controles de recuperação e concorrência. Os detalhes desses aspectos do sistema estão além do escopo deste capítulo; consulte a Parte IV deste livro, que contém uma descrição em profundidade do assunto. Nota: o gerenciador de transações não é mostrado na Figura 2.4 porque, em geral, ele não faz parte do SGBD propriamente dito.
• Dicionário de dados O SGBD deve fornecer uma função de dicionário de dados. O dicionário de dados pode ser considerado um banco de dados em si (mas um banco de dados do sistema, não um banco de dados impõem restrições - de segurança e integridade do usuário), O dicionário contém “dados sobre os dados” (às vezes chamados metadados ou descritores) — ou seja, definições de outros objetos do sistema, em vez de “dados brutos” somente. Em particular, todos os vários esquemas e mapeamentos (externos, conceituais etc.) e todas as diversas restrições de segurança e integridade estarão armazenados, tanto na forma de fonte quanto de objeto, no dicionário. Um dicionário completo também incluirá muitas informações adicionais mostrando, por exemplo, os programas que utilizam determinadas partes do banco de dados, os usuários que exigem certos relatórios, os terminais conectados ao sistema, e assim por diante. O dicionário poderia até estar — na verdade, provavelmente deve estar — integrado ao banco de dados que define e, portanto, incluir sua própria definição. Por certo, deve haver a opção de consultar o dicionário como qualquer outro banco de dados para que, por exemplo, seja possível saber que programas e/ou usuários terão maior probabilidade de serem afetados
68
por alguma alteração proposta no sistema. Consulte o Capítulo 3 para ver uma discussão adicional sobre o assunto. Nota: estamos entrando agora em uma área sobre a qual existe muita confusão de terminologia. Algumas pessoas fariam referência ao que estamos chamando de dicionário como um diretório ou catálogo, o que implica que diretórios ou catálogos são de algum modo inferiores a um verdadeiro dicionário — e reservariam o termo dicionário para designar uma variedade específica (importante) de ferramenta para desenvolvimento de aplicações. Outros termos que também são algumas vezes empregados para designar essa última variedade de objetos são repositório de dados (ver Capítulo 13) e enciclopédia de dados.
É desnecessário dizer que o SGBD deve realizar todas as funções identificadas anteriormente de forma tão eficiente quanto possível.
Podemos resumir tudo o que foi mencionado antes afirmando que a função geral do SGBD é fornecer a interface do usuário para o sistema de banco de dados. A interface do usuário pode ser definida como a fronteira no sistema abaixo da qual tudo é invisível para o usuário. Por definição, portanto, a interface do usuário está no nível externo. Contudo, como veremos no Capítulo 9, há algumas situações em que é improvável que a visão externa seja significativamente diferente da porção relevante da visão conceitual subjacente, pelo menos nos produtos SQL comerciais de hoje.
Concluímos esta seção com uma breve comparação 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 básico que administra arquivos armazenados; portanto, em termos informais, ele está “mais próximo ao disco” que o SGBD. (Na verdade, o SGBD costuma ser montado sobre algum tipo de gerenciador de arquivos.) Desse
69
modo, o usuário de um sistema de gerenciamento de arquivos será capaz de criar e destruir arquivos armazenados e de executar operações simples de busca e atualização sobre registros armazenados em tais arquivos. No entanto, em contraste com o SGBD: • Os gerenciadores de arquivos não têm conhecimento da estrutura interna dos registros armazenados e, por isso, não podem lidar com requisições que dependam de um conhecimento dessa estrutura. • Em geral, eles fornecem pouco ou nenhum suporte para restrições de segurança e integridade. • Em geral, eles fornecem pouco ou nenhum suporte para controles de recuperação e concorrência. • Não há verdadeiramente um conceito de dicionário de dados no nível do gerenciador de arquivos. • Eles proporcionam muito menos independência de dados que o SGBD. • Em geral, os arquivos não estão “integrados” ou “compartilhados” no mesmo sentido que o banco de dados (normalmente, eles são privativos de algum usuário ou alguma aplicação em particular). O GERENCIADOR DE COMUNICAÇÕES DE DADOS
Nesta seção, consideraremos resumidamente o tópico de comunicações de dados. As requisições a bancos de dados de um usuário final são, na verdade, transmitidas da estação de trabalho do usuário — que pode estar fisicamente afastada do próprio sistema de banco de dados — para alguma aplicação on-line (embutida ou não), e daí até o SGBD, sob a forma de mensagens de comunicação. De modo semelhante, as respostas do SGBD e da aplicação on-line para a estação de trabalho do usuário também são transmitidas sob a forma de mensagens. Todas essas transmissões de mensagens têm lugar sob o controle de outro componente de software, o gerenciador de comunicações de dados (gerenciador DE — data communications).
O gerenciador DE não faz parte do SGBD, mas é um sistema autônomo. Porém, como o gerenciador DE e o SGBD são claramente obrigados a trabalhar em harmonia, às vezes os dois são considerados parceiros de igual nível em um empreendimento cooperativo de nível mais alto, denominado sistema de banco de dados/comunicações 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 aplicações que utilizam o SGBD. Porém, neste livro, teremos pouco a dizer sobre o manejo de mensagens como essas (o que, por si só, é um assunto extenso). A Seção 2.12 descreve resumidamente a questão das comunicações entre sistemas distintos (ou seja, entre máquinas diferentes em uma rede de comunicações, como a Internet), mas esse é, na realidade, um tópico à parte. ARQUITETURA CLIENTE/SERVIDOR
Descrevemos até agora neste capítulo os sistemas de bancos de dados sob o ponto de vista da chamada arquitetura ANSI/SPARC. Em particular, a Figura 2.3 forneceu uma representação simplificada dessa arquitetura. Nesta seção, examinaremos os sistemas de bancos de dados sob uma perspectiva um pouco diferente. Naturalmente, o objetivo geral desses sistemas é fornecer suporte ao desenvolvimento e à execução de aplicações de bancos de dados. Portanto, sob um ponto de vista de mais alto nível, um sistema de banco de dados pode ser considerado como tendo uma estrutura muito simples em duas partes, consistindo em um servidor (também chamado back end) e um conjunto de clientes (também chamados front ends). Consulte a Figura 2.5. Explicação: • O servidor é o próprio SGBD. Ele admite todas as funções básicas de SGBDs discutidas na Seção 2.8 — definição de dados, manipulação de dados, segurança e integridade de dados, e assim por diante. Em particular, ele oferece todo o suporte de nível externo, conceitual e interno que examinamos nas Seções 2.3 a 2.6. Assim, o termo “servidor” neste contexto é tão-somente um outro nome para o SGBD. • Os clientes são as diversas aplicações executadas sobre o SGBD — tanto aplicações escritas por usuários quanto aplicações internas, ou seja, aplicações fornecidas pelo fabricante do SGBD ou por produtores independentes. No que se refere ao servidor, é claro que não existe nenhuma diferença entre aplicações escritas pelo usuário e aplicações internas — todas elas empregam a mesma interface para o servidor, especificamente a interface de nível externo discutida na Seção 2.3.
70
Nota: certas aplicações especiais chamadas “utilitários” poderiam constituir uma exceção ao que vimos antes, pois às vezes elas podem precisar operar diretamente no nível interno do sistema (conforme mencionamos na Seção 2.5). Esses utilitários devem ser considerados componentes integrais do SGBD, em vez de aplicações no sentido usual. Os utilitários serão discutidos com mais detalhes na próxima seção. Vamos aprofundar o exame da questão de aplicações escritas pelo usuário versus aplicações fornecidas pelo fabricante: • Aplicações escritas pelo usuário são basicamente programas aplicativos comuns, escritos (em geral) em uma linguagem de programação convencional de terceira geração (L3G), como C ou COBOL, ou então em alguma linguagem proprietária de quarta geração (L4G) — embora em ambos os casos a linguagem precise ser de algum modo acoplada a uma sublinguagem de dados apropriada, conforme explicamos na Seção 2.3. Banco de dados • Aplicações fornecidas por fabricante (chamadas frequentemente de ferramentas — tools) são aplicações cuja finalidade básica é auxiliar na criação e execução de outras aplicações! As aplicações criadas são aplicações adaptadas a alguma tarefa específica (elas podem não ser muito semelhantes às aplicações no sentido convencional; de fato, a finalidade das ferramentas é permitir aos usuários, em especial aos usuários finais, criar aplicações sem ter de escrever programas em uma linguagem de programação convencional). Por exemplo, uma das ferramentas fornecidas pelo fabricante será um gerador de relatórios, cuja finalidade é permitir que os usuários finais obtenham relatórios formatados a partir do sistema sob solicitação. Qualquer solicitação de relatório pode ser considerada um pequeno programa aplicativo, escrito em uma linguagem de geração de relatórios de nível 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 relatórios. c. Subsistemas gráficos de negócios. d. Planilhas eletrônicas. e. Processadores de linguagem natural. f. Pacotes estatísticos. g. Ferramentas para gerenciamento de cópias ou “extração de dados”. h. Geradores de aplicações (inclusive processadores L4G). i. Outras ferramentas para desenvolvimento de aplicações, inclusive produtos de engenharia de software auxiliada pelo computador (CASE — computer-aided software engineering). Os detalhes dessas ferramentas e de várias outras estão além do escopo deste livro; entretanto, observamos que, tendo em vista que (como foi dito antes) toda a importância de um sistema de banco de dados está em dar suporte à criação e à execução de aplicações, a qualidade das ferramentas disponíveis é, ou deve ser, um fator preponderante na “decisão sobre o banco de dados” (isto é, o processo de escolha do produto de banco de dados apropriado). Em outras palavras, o SGBD em si não é o único fator que precisa ser levado em consideração, nem mesmo é necessariamente o fator mais significativo. Encerramos esta seção com uma referência para o que se segue. Como o sistema por completo pode estar tão claramente dividido em duas partes, servidores e clientes, surge a possibilidade de executar os dois em
71
máquinas diferentes. Em outras palavras, existe o potencial para o processamento distribuído. O processamento distribuído significa que máquinas diferentes podem estar conectadas entre si para formar algum tipo de rede de comunicações, de tal modo que uma única tarefa de processamento de dados possa ser dividida entre várias máquinas na rede. Na verdade, essa possibilidade é tão atraente — por urna variedade de razões, principalmente de ordem econômica — que o termo “cliente/servidor” passou a se aplicar a quase exclusivamente ao caso em que o cliente e o servidor estão de fato localizados em máquinas diferentes. Examinaremos o processamento distribuído com mais detalhes na Seção 2.12. UTILITÁRIOS Utilitários são programas projetados para auxiliar o DBA com diversas tarefas administrativas. Como mencionamos na seção anterior, alguns programas utilitários operam no nível externo do sistema e, portanto, são na verdade apenas aplicações de uso especial; alguns podem nem mesmo ser fornecidos pelo fabricante do SGBD, mas sim por algum fabricante independente. Porém, outros utilitários operam diretamente no nível interno (em outras palavras, eles realmente fazem parte do servidor) e, desse modo, devem ser oferecidos pelo fornecedor do SGBD.
Aqui estão alguns exemplos dos tipos de utilitários que costumam ser necessários na prática: • Rotinas de carga, a fim de criar a versão 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 cópias de backup (é claro que o “utilitário de recarregamento” é basicamente idêntico ao utilitário de carga que acabamos de mencionar). • Rotinas de reorganização, a fim de rearranjar os dados no banco de dados armazenado por várias razões (em geral, relacionadas com o desempenho) — por exemplo, para agrupar dados de algum modo particular no disco, ou para reaver o espaço ocupado por dados que se tornaram obsoletos. • Rotinas estatísticas, a fim de calcular diversas estatísticas de desempenho, tais como tamanhos de arquivos e distribuição de valores de dados ou contagens de E/S etc. • Rotinas de análise, a fim de analisar as estatísticas mencionadas antes. A lista precedente representa apenas uma pequena amostra das funções em geral oferecidas pelos utilitários; existe uma série de outras possibilidades. PROCESSAMENTO DISTRIBUÍDO Repetindo o que mencionamos na Seção 2.10, a expressão “processamento distribuído” significa que máquinas diferentes podem estar conectadas entre si em uma rede de comunicações como a Internet, de tal modo que uma única tarefa de processamento de dados possa se estender a várias máquinas na rede. (A expressão “processamento paralelo” também é utilizada algumas vezes com significado quase idêntico, exceto pelo fato de que as diferentes máquinas tendem a manter uma certa proximidade física em um sistema “paralelo” e não precisam estar tão próximas em um sistema “distribuído” — por exemplo, elas poderiam estar geograficamente dispersas no último caso.) A comunicação entre as várias máquinas é efetuada por algum tipo de software de gerenciamento de rede — possivelmente uma extensão do gerenciador DE discutido na Seção 2.9 ou, com maior probabilidade, um componente de software separado.
São possíveis muitos níveis ou variedades de processamento distribuído. Conforme mencionamos na Seção 2.10, um caso simples envolve a execução do back end do SGBD (o servidor) em uma das máquinas e dos front ends da aplicação (os clientes) em outra. Ver Figura 2.6.
Como vimos no final da Seção 2.10, o termo “cliente/servidor”, embora seja estritamente uma expressão relacionada com a arquitetura, passou a ser quase um sinônimo da disposição ilustrada na Figura 2.6, na qual o cliente e o servidor funcionam em máquinas 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 estão sendo agora aplicadas na tarefa global, enquanto o processamento do servidor (o banco de dados) e o processamento do cliente (a aplicação) estão sendo feitos em paralelo. O tempo de resposta e a vazão (throughput) devem assim ser melhorados. • Além disso, a máquina servidora pode ser uma máquina feita por encomenda para se ajustar à função de SGBD (uma “máquina de banco de dados”) e pode assim fornecer melhor desempenho de SGBD.
72
• Do mesmo modo, a máquina cliente poderia ser uma estação de trabalho pessoal, adaptada às necessidades do usuário final e, portanto, capaz de oferecer interfaces melhores, alta disponibilidade, respostas mais rápidas e, de modo geral, maior facilidade de utilização para o usuário.
• Várias máquinas clientes distintas poderiam ser capazes (na verdade, normalmente serão capazes) de obter acesso à mesma máquina servidora. Assim, um único banco de dados poderia ser compartilhado entre vários sistemas clientes distintos (ver Figura 2.7).
Além dos argumentos anteriores, existe também o fato de que a execução do(s) cliente(s) e do servidor em máquinas diferentes combina com a maneira como as empresas operam na realidade. E 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 provável que os usuários de uma agência precisem ocasionalmente obter acesso a dados armazenados em outra agência. Portanto, observe que as máquinas clientes poderiam ter seus próprios dados armazenados, e a máquina servidora poderia ter suas próprias aplicações. Dessa forma, em geral caia maquina atuará como um servidor para alguns usuários e como cliente para outros (ver Figura 2.8); em outras palavras, cada máquina admitirá um sistema de banco de dados por inteiro, no sentido estudado em seções anteriores deste capítulo. O último ponto a mencionar é que uma única máquina cliente poderia ser capaz de obter acesso a várias máquinas servidoras diferentes (a recíproca do caso ilustrado na Figura 2.7). Esse recurso é desejável porque, como mencionamos antes, as empresas em geral operam de tal maneira que a totalidade de seus dados não fica armazenada em uma única máquina, mas se espalha por muitas máquinas diferentes, e as aplicações às vezes precisarão ter a capacidade de conseguir acesso a dados de mais de uma máquina. Basicamente, esse acesso pode ser fornecido de dois modos distintos: • Um dado cliente pode ser capaz de obter acesso a qualquer número de servidores, mas somente um de cada vez (ou seja, cada requisição individual ao banco de dados tem de ser direcionada para apenas um servidor). Em um sistema desse tipo não é possível, dentro de uma única requisição, combinar dados de dois ou mais servidores diferentes. Além disso, o usuário de tal sistema tem de saber qual máquina em particular contém cada um dos fragmentos de dados. • O cliente pode ser capaz de obter acesso a muitos servidores simultaneamente (isto é, uma única solicitação ao banco de dados poderia ter a possibilidade de combinar dados de vários servidores). Nesse caso, os servidores aparentam para o cliente — de um ponto de vista lógico — ser realmente um único servidor, e o usuário não precisa saber qual máquina contém cada um dos itens de dados.
73
Esse último caso constitui um exemplo daquilo que se costuma chamar sistema de banco de dados
distribuído, O tema de bancos de dados distribuídos é um grande tópico por si só; levado a sua conclusão lógica, o suporte completo a bancos de dados distribuídos implica que uma única aplicação 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 máquinas distintas, com suporte de uma variedade de sistemas operacionais diferentes e conectados entre si por meio de uma variedade de redes de comunicações diferentes — onde “de modo transparente” significa que a aplicação opera, de um ponto de vista lógico, como se os dados fossem todos gerenciados por um único SGBD funcionando em uma única máquina. Esse recurso pode parecer algo muito difícil de conseguir, mas é altamente desejável de uma perspectiva prática, e os fabricantes estão trabalhando arduamente para tornar realidade esses sistemas. Discutiremos em detalhes os sistemas de bancos de dados distribuídos no Capítulo 20.
