A amplitude conceitual da área de banco de dados – processamento de consulta parte 2

No post anterior apresentei algumas considerações sobre o arcabouço teórico que existe por trás da teoria de processamento de uma consulta em um banco de dados.

No texto percebemos que uma determinada consulta será transformada em uma expressão algébrica/relacional.

SELECT nome FROM tbCliente WHERE tipo = 1

pode gerar duas expressões distintas:

π  _{nome (}  σ  _{tipo = 1}   ^(tbClientes)  _{) [1]}

ou

σ  _{tipo = 1  (}  π  _nome ^(tbClientes)  _{) [2]}

 

O texto termina com a seguinte questão: Qual delas é mais apropriada?

Para responder esta questão vamos partir do seguinte contexto:

• Estamos trabalhando localmente em uma máquina qualquer.
• O Sistema Operacional (SO) gerencia a memória da máquina da maneira dinâmica.
• A memória RAM está configurada da seguinte forma: 4 processos foram alocados na memória, uma partição de 2 kbytes está disponível para um quinto processo (vide figura).
• A consulta acima foi disparada, um quinto processo foi criado.
• Cada registro da tabela tbClientes ocupa um espaço em disco de 182 bytes.
• A tabela possui 15 registros, o espaço de armazenamento de mesma caracteriza-se em 2730 bytes.
• O campo nome ocupa 40 bytes, e o campo tipo ocupa 1 byte.
• Assuma que existe 3 clientes classificados com tipo 2 na tabela.
• Neste caso temos 12 clientes com tipo 1, totalizando 2184 bytes para os mesmos.

Respondendo a questão.

Para a expressão algébrica 1: Ao selecionarmos os clientes do tipo 1 não teremos espaço para alocá-los, diretamente, na memória visto que os 2184 bytes superam os 2048 da partição livre (vide figura) – pois selecionamos 12 registros com 182 bytes – Para alocar as informações o SO teria que partir para um swapp ou aplicar as técnicas de paginação ou segmentação, fato esse que degrada o desempenho geral da aplicação.

Para a expressão algébrica 2: Ao projetarmos o nome dos 12 clientes, criamos um conjunto de 480 bytes (12 * 40). Temos também que alocar o campo tipo na memória, neste caso o tamanho do conjunto salta para 492 bytes. A partição livre, de 2048, acondiciona tranquilamente o processo, o SO não terá que realizar swapp ou aplicar as técnicas de paginação ou segmentação.

Concluindo.

O contexto aplicado para responder a questão caracteriza-se pela simplicidade, porém ele pode se generalizado. E se fosse necessário realizar uma consulta com dados de duas tabelas? Sendo que uma delas encontra-se armazenada em um servidor remoto, distante geograficamente da estação de processamento da consulta.

Neste exemplo, a responsabilidade pelo desempenho do processo ficou com o sistema de gerenciamento de banco de dados, mas se você disparar em sua aplicação a consulta:

SELECT * FROM tbCliente WHERE tipo = 1

e utilizar somente o campo nome, ai meu caro …

Pense nisso…

Enfim, Banco de dados é a sistematização teórica de Sistema Operacional e de Estrutura de Dados.

Abraços

J. A. Fabri

fabri@utfpr.edu.br

A amplitude conceitual da área de banco de dados – processamento de consulta parte 1

Silberschatz et. al. (2006)

O que realmente sabemos sobre a área de banco de dados? Você já parou para pensar nisso? 

Se você é desenvolvedor de software garanto que tenha uma grande facilidade para a construção de consultas utilizando SQL. E por trás de uma SQL, o que existe? 

Uma subestrutura complexa que possibilita o seu processamento (vide figura). 

Neste e nos próximos post, vamos desvendar cada funcionalidade da referida subestrutura. 

Analisador / Tradutor 

Antes de ser processada, toda SQL, é analisada e transformada em uma expressão algébrica relacional, por exemplo: 

SELECT nome FROM tbCliente WHERE tipo = 1 

O analisador irá verificar se a construção sintática e semântica da consulta está correta, algo semelhante a compilação um determinado programa. 

A análise léxica 

A palavra SELECT está grafada corretamente? Em nosso exemplo sim. Porém, se por acaso você esquecer a letra T, o analisador irá retornar uma mensagem dizendo que SELEC não é um comando válido. 

Análise sintática 

Transforma um texto  em uma estrutura de dados caracterizada por uma árvore.  Neste caso o analisador irá analisar a seqüência das palavras da consulta. 

A análise semântica   

Tem como objetivos verificar erros semânticos, por exemplo a adição de dois tipos diferentes de dados. 

A tradução  

Existe uma série de operadores algébricos / relacionais, este texto apresenta dois deles: 

Projeção (responsável pela apresentação dos dados), representado pela letra grega π; 

Seleção (responsável pela seleção de algumas tuplas da tabela, dada uma determinada condição), representado pela letra grega σ; 

Exemplos: 

π  _nome ^(tbClientes) 

– Projetamos o campo nome do cliente da tabela tbClientes. 

σ  _{tipo = 1} ^(tbClientes)  

– Selecionamos os clientes que possuem tipo = 1, neste caso todos os campos da tupla fazem parte da seleção. 

Traduzindo a SQL: 

A SQL apresentada no início do texto pode ser traduzida de duas formas: 

π  _{nome (}  σ  _{tipo = 1}   ^(tbClientes)  ₎  

– Selecionamos os clientes que possuem tipo = 1, ou seja, geramos um subconjunto e, posteriormente, projetamos somente o campo nome deste subconjunto. 

σ  _{tipo = 1  (}  π  _nome ^(tbClientes)  ₎  

-Selecionamos os clientes que possuem tipo = 1, ou seja, geramos um subconjunto e, posteriormente, projetamos somente o campo nome deste subconjunto. 

Para finalizar, questiono: Qual das traduções algébricas proporciona uma maior eficiência no processamento da consulta? 

Abraços 

fabri@utfpr.edu.br