• Nenhum resultado encontrado

Sumário

2.3 Estado da Arte

2.3.5 Linguagem BQL ( CURÉ et al , 2011 )

O trabalho de Curé et al. (2011), investiga a eĄciência das consultas sobre ban- cos de dados relacionais e NoSQL, com abordagem na solução de mapeamento baseado em caminhos de acesso. Foi proposta uma linguagem de consulta BQL - Bridge Query Language que permite a transformação de uma consulta SQL deĄnida sobre um banco de dados relacional para a consulta executada sobre um determinado banco de dados NoSQL. A linguagem faz a tradução do SQL para BQL e a partir de BQL para a linguagem de consulta suportada por cada armazenamento NoSQL.

Com relação ao mapeamento baseado em caminhos de acesso, é deĄnida a seguinte especiĄcação: RelationT(a,b,c) ←−

𝑎 EntityS(<key;value>), onde RelationT e EntityS de- notam a relação entre conjunto de coleções, família de colunas ou relações do banco de dados NoSQL. Um caminho de acesso com o atributo ŚaŠ é deĄnido quando a entidade de destino (bancos de dados NoSQL) oferece um acesso eĄciente, usando uma chave ou um índice, a uma coleção, conjunto de colunas ou tupla. A arquitetura geral do proces-

samento de consulta é apresentada na Figura 14. Primeramente, um usuario grava uma consulta SQL sobre um esquema relacional. Posteriormente, a consulta SQL será tradu- zida na linguagem de consulta interna BQL usando as declarações de mapeamento. Então para cada consulta BQL, é realizada uma segunda transformação, desta vez para gerar uma consulta no sistema de banco de dados NoSQL. Assim, para cada implementação de sistemas NoSQL, é deĄnida um conjunto de regras para tradução da consulta BQL.

Figura 14 Ű Arquitetura de processamento de consulta com abordagem BQL (CURÉ et al., 2011)

São deĄnidas declarações de mapeamento para traduzir uma consulta na lingua- gem SQL para linguagem BQL. Na Tabela 9 são exibidos os seguintes mapeamentos: o mapeamento número 1 representa o caminho de acesso por (Ş*Ť), isso considerando que todos os atributos da coleção drugD estão indexados. A coleção drugD está armazenada em um banco de dados orientado a documentos. Neste mapeamento, o atributo ŞcŤ não está mapeado para qualquer atributo de origem, desde que as informações não estejam disponível no banco de dados que contenha a coleção. O mapeamento número 3 mostra a utilização de varias entidades num único mapeamento. Intuitivamente, esta consulta acessa uma determinada entrada de família de coluna drugNameC identiĄcada pelo nome do medicamento (←−

n) e itera seus identiĄcadores de medicamentos, representadas por ŞiŤ, que são chaves (usando expressão ŚIN KEYŠ) então ele usa esses identiĄcadores para

2.3. Estado da Arte 61

acessar na família de coluna drugC.

Foram extraídas semelhanças entre consultas expressas sobre bancos de dados NoSQL e implementados padrões em templates BQL e associadas a métodos Java com o propósito de realizar o mapeamento da consulta BQL para o banco de dados destino. A linguagem BQL contêm um conjunto de palavras reservadas cuja semântica inclui a instrução GET que permite deĄnir os valores necessários para o resultado da consulta.

Tabela 9 Ű Mapeamento de consultas SQL para BQL (CURÉ et al.,2011) 1. drug(i,l,n,c,p) ←−

∗ drugD(<PKEY AS i; name AS n, lab AS l, price AS p> 2. drug(i,n,l,c,p) ←−i drugC(<PKEY AS i; name AS n, lab AS l, compo as c, price AS p>)

3. drug(i,n,l,c,p) ←−n drugNameC(<PKEY AS n; FOREACH id AS i IN KEY>, drugC(<id, lab AS l, compo as c,price AS p>)

4. therapDrug(i,t) ←−

i drugD(<PKEY AS i; FOREACH the AS t IN Therap>) 5. therapDrug(i,t) ←−

t therapD(<PKEY AS t; FOREACH id AS i IN Drugs>) 6. therapDrug(i,t) ←−i DrugC(<PKEY AS i; FOREACH the AS t IN Therap>) 7. therapDrug(i,t) ←−

t therapD(<PKEY AS t; FOREACH id AS i IN KEY >)

Apresenta-se na Listagem 2.11 um exemplo de consulta expressa em SQL (linhas 1-4) e traduzida para bancos de dados de documentos (linhas 7-9) e colunar (linhas 11-13). A consulta acessa uma única tabela através de sua chave primária.

1 SQL :

2 SELECT drugName , price

3 FROM drug

4 WHERE drugId = 3 2 9 5 9 3 5 ; 5

6 /* docDB ’ s BQL : */

7 ans ( drugName , price ) = docDB . drugD .get({ PKEY = 3295935} ,{ name , 8 price })

9 R e s p o s t a : ( Advil , 1.88) 10 /* colDB ’ s BQL : */

11 ans ( drugName , price ) = colDB . drugC .get({ PKEY = 3295935} ,{ name , 12 price })

13 R e s p o s t a : ( Advil , 2.05)

Listagem 2.11 Ű Exemplo de consulta SQL mapeada na linguagem BQL (CURÉ et al., 2011)

2.3.6 Álgebra ER (PARENT; SPACCAPIETRA,

1984)

O trabalho de Parent e Spaccapietra (1984) propõe uma deĄnição de um con- junto de operadores algébricos a serem aplicados em um banco de dados de Entidade-

Relacionamento. A álgebra ER inclui os operadores básicos: união, diferença de conjun- tos, produto cartesiano, projeção e seleção. Támbem é estudada a operação de junção (Şrelationship joinŤ). O resultado de uma operação deve poder servir como operando para qualquer um dos operadores, de modo que qualquer expressão desejada pode ser formulada usando uma combinação apropriada de operações.

Entramos em detalhes com a operação de junção, que foi utilizada para proporci- onar uma semântica operacional focada no modelo de documentos.

Suponha que: 𝐸1, 𝐸2, ..., 𝐸n são tipos de entidades associados através de um rela- cionamento R (ver Figura15):

Figura 15 Ű Relacionamento R, relationship join (PARENT; SPACCAPIETRA,1984)

O relationship join de 𝐸1, ..., 𝐸n através de R deĄne um novo tipo de entidade E: 𝐸 = 𝐸1∗R(𝐸2, 𝐸3, ..., 𝐸n).

Uma ocorrência de E consiste em uma ocorrência de E1 juntamente com todas as ocorrências (se houver) de R, com as entidades associadas 𝐸2, .., 𝐸n, nas quais a corrente de E1 está envolvida. Em outras palavras, E é um novo tipo de entidade com dois atributos:

• um atributo complexo, obrigatório, monovalorado que agrupa todos os atributos de E1,

• um atributo complexo, opcional, multivalorado agrupando n atributos complexos, obrigatórios e monovalentes, onde cada um desses atributos n, respectivamente, agrupa todos os atributos de 𝑅, 𝐸2, ..., 𝐸n.

É apresentado o seguinte exemplo extraído do trabalho de Parent e Spaccapietra (1984): suponha que o conteúdo do banco de dados de exemplo - representa os seguintes fatos:

• uma pessoa chamada SMITH tem um contrato 247 com uma empresa chamada LIFE-INS para o seu carro com número 1111 e outro contrato (número 3412) com a mesma empresa do carro número 2222;

• uma pessoa chamada CHEN tem um número de contrato 81 com LLOYD para o número de carro 1234. Então, um novo tipo de entidade PC pode ser construído para armazenar dados sobre pessoas junto com seus carros e companhia de seguros (ver Figura 16), onde () denota valores para atributos complexos e {} denota atributos multivalorados.

2.3. Estado da Arte 63

Figura 16 Ű Exemplo relationship join (PARENT; SPACCAPIETRA, 1984)

A composição de relationship joins (e de outras operações também) é possível porque o resultado da operação é estabelecido como um novo tipo de entidade (Entidade Computada) que herda os relacionamentos que associam as entidades ŞinternasŤ (aqueles que aparecem dentro da fórmula que deĄne o novo tipo de entidade) para entidades ŞexternasŤ (aquelas que não estão envolvidas na fórmula).

A facilidade oferecida por este operador de junção é fundamental para a manipu- lação de dados, pois permite que a estrutura do resultado desejada seja independente das estruturas existentes gravadas no esquema.