MÓDULOS DE UM SISTEMA DE GERÊNCIA DE BANCO DE DADOS
A figura a seguir ilustra, em detalhes, os diversos módulos que compõem um SGBD, sendo a parte superior correspondente ao processamento das consultas e aplicações, e a parte inferior ao acesso a metadados e dados armazenados (a base de dados).
Vamos conferir a descrição desses módulos.
USUÁRIOS
Da esquerda para a direita, vemos os usuários, começando com os administradores de banco
de dados (ABD, do inglês DBA – Database Administrator).
ABD
O ABD usa comandos da linguagem de definição de dados (LDD, do inglês DDL – Data
Definition Language) para criar, alterar ou remover objetos do banco de dados (comandos
CREATE, ALTER, DROP no padrão SQL), os quais ficam armazenados no catálogo do
sistema, que contém os metadados.
O ABD também possui privilégio para executar comandos de controle de dados, conhecidos
por alguns autores como linguagem de controle de dados (LCD, do inglês DCL – Data Control
Language), para conceder e revogar permissões de acesso aos dados (comandos GRANT e
REVOKE no padrão SQL), entre outros. Note que o destino desses comandos privilegiados é
um nó central do SGBD, por onde passam todos os comandos destinados ao processador de
banco de dados em tempo de execução, denominado de processador de runtime ou runtime
engine.
USUÁRIOS CASUAIS
Seguindo para a direita, vemos os usuários casuais, os quais fazem consultas interativas
através de uma interface para consultas ad hoc, ou seja, consultas não programadas previamente. As consultas são feitas tipicamente com o comando SELECT no padrão SQL do
modelo relacional e provido de modo similar em outros modelos de implementação de banco
de dados. Esses comandos são compilados por um compilador da linguagem de consulta e
passam por um otimizador de consulta antes de chegar ao nó central do SGBD.
PROGRAMADORES DE APLICAÇÕES
Mais à direita, aparecem os programadores de aplicações que escrevem os programas em
uma linguagem de programação hospedeira, como por exemplo, Java, PHP ou Python, nos
quais estão embutidos comandos de consulta (SELECT), inserção, atualização e exclusão de
dados em uma linguagem de manipulação de dados (LMD, do inglês DML – Data Manipulation
Language).
No padrão SQL, esses comandos são, respectivamente, INSERT, UPDATE e DELETE. Note
que eles manipulam dados, diferentemente dos comandos da linguagem de definição de dados
(CREATE, ALTER, DROP), que manipulam metadados.
PROGRAMAS DE APLICAÇÃO
Os programas de aplicação, portanto, possuem comandos híbridos, da linguagem hospedeira e
da linguagem de consulta e manipulação de dados.
PRÉ-COMPILADOR
Os programas de aplicação são processados, inicialmente, por um pré-compilador, responsável
por separar os comandos e os repassar para os compiladores das respectivas linguagens.
COMPILADORES
Cabe a esses compiladores produzir o código das aplicações sob a forma de transações
executáveis, que ficam à disposição dos usuários paramétricos.
USUÁRIOS PARAMÉTRICOS
Os usuários paramétricos são assim chamados porque interagem com o sistema através de
parâmetros passados em interfaces apropriadas. Por exemplo, um agente de viagens faz uma
reserva de passagem aérea passando ao sistema os dados do passageiro, data e hora da
viagem, número do voo, número do assento e outros parâmetros necessários para efetivar a
reserva.
TRANSAÇÕES COMPILADAS
Uma vez executadas as transações compiladas, assim como os demais comandos
provenientes de usuários ou aplicações, são passadas ao nó central do SGBD para posterior
processamento do processador de runtime.
Atenção! Antes de prosseguir na parte de baixo da figura, note que alguns processos da parte
de cima, como o otimizador de consulta e o compilador da LMD, estão ligados ao catálogo por
linhas tracejadas, que denotam fluxos de controle, enquanto as linhas cheias representam
fluxos de dados, além de controle. Isso é necessário porque as referências a objetos do banco
de dados existentes no catálogo devem ser consistentes com os objetos, criados e mantidos
pelo ABD mediante comandos da LDD.
PROCESSAMENTO DO ACESSO AOS DADOS
ARMAZENADOS
Prosseguindo para a parte do processamento do acesso aos dados armazenados, observamos
que o processador de runtime é o coração do SGBD. De fato, o diferencial dos produtos de
SGBD reside na eficiência e na funcionalidade desse processador, segredo industrial em
muitos dos SGBDs proprietários, a ponto de exigir rigorosos termos de confidencialidade das
pessoas que têm acesso ao seu código.
ACESSO A BASE DE DADOS
O processador de runtime também precisa acessar e, por vezes, modificar o catálogo,
dependendo da natureza dos comandos, das consultas ou transações que estiver
processando. Como mostra a figura, ele acessa a base de dados diretamente, sob controle de
subsistemas de controle de concorrência, backup e recovery. Quando precisa realizar
operações de entrada e saída (gravação e leitura) na base de dados, o processador de runtime
se vale de um gerenciador de dados armazenados.
A descrição dada, embora simplificada, denota a complexidade de um SGBD, software que
evoluiu desde a década de 1960 a ponto de se tornar um recurso robusto, eficiente e
indispensável para a maioria das organizações privadas ou públicas, principalmente com base
no modelo relacional de banco de dados.
Existe uma grande quantidade de SGBDs disponíveis no mercado, como mostrou o DBEngines Ranking, ao listar mais de 300 SGBDs, sendo cerca de 130 deles do modelo
relacional.
Comentários
Postar um comentário