Nesta seção serão apresentados os resultados encontrados no processo de pesquisa e uma análise sobre os mesmos. Cada uma das questões de pesquisa definidas no início do processo serão respondidas e detalhadas.
3.2.1 QP1. Quais os Principais Autores na Área de Projeto de Bancos de Dados NoSQL?
Durante o processo de seleção foi possível perceber que alguns autores se destacam na área de pesquisa de projeto de bancos de dados NoSQL. Conhecer os principais autores de uma determinada área é importante para estabelecer um bom ponto de partida e a partir de seus trabalhos encontrar boas referências para pesquisa. Pelo número de citações encontrados em relação aos demais artigos, Rick Cattell merece destaque com o artigo (CATTELL, 2011). O número de citações do artigo coloca-o em primeiro lugar entre os demais artigos com o índice
InOrdinatio apesar do ano de publicação (2011) ser considerado menos atual em relação aos
demais trabalhos selecionados. Destacam-se também os autores Paolo Atzeni, Francesca Bugi- otti e Luca Rossi por apresentarem mais de um trabalho relevante na seleção realizada, como autores ou co-autores. Os trabalhos são Atzeni, Bugiotti e Rossi (2012), Bugiotti et al. (2013) e Bugiotti e Cabibbo (2014) e apresentam metodologias de trabalho com bases de dados NoSQL e metodologias de projeto.
3.2.2 QP2. Quais São os Casos de Aplicação Mais Comuns dos Bancos de Dados NoSQL?
Entre os artigos analisados os casos mais comuns de aplicação de bancos de dados NoSQL são aplicações voltadas para a Web 2.0, que utilizam grandes quantidades de dados não-estruturados ou semiestruturados como mídias sociais, gerenciadores de conteúdo e par- ticularmente sistemas de e-commerce. Sistemas de e-commerce são frequentemente utilizados como estrutura de exemplo nos artigos, como por exemplo em Srivastava e Shekokar (2017). A
razão para utilização dos sistemas de e-commerce se deve ao fato de possuir vários subsistemas com requisitos não-funcionais bastante distintos.
A necessidade de estruturas de armazenamento mais flexíveis é frequentemente apon- tada como uma das justificativas para a utilização de bases de dados NoSQL que possuem o chamado "schema-less"ou ausência de esquema. Esses tipos de estrutura são frequentemente necessárias em gerenciadores de conteúdos ou registros de logs.
3.2.3 QP3. Quais as Estratégias Existentes Atualmente no Projeto de Banco de Dados NoSQL?
Entre os artigos analisados, não há uma uniformidade nas estratégias utilizadas para o projeto de banco de dados NoSQL. As propostas divergem bastante em ferramentas e métodos utilizados para o projeto de banco de dados, mesmo quando se tratando do mesmo modelo de dados. Muitas delas restringem-se apenas um modelo de dados e algumas até mesmo à um único software de banco de dados NoSQL.
Bugiotti e Cabibbo (2014) apresenta o NoSQL Abstract Model (NoAM), metodologia que propõe uma forma de representação intermediária dos dados, independente do banco de dados a ser utilizado. Tal estratégia aplica-se apenas para os modelos baseados em agregados e permite que um mesmo modelo possa ser aplicado para bancos de dados chave-valor, orientado a documentos e família de colunas. Segundo os autores, o modelo intermediário poderia ser utilizado para a criação de qualquer dos modelos de dados apontados, em qualquer software, bastando para isso a conversão do modelo intermediário no modelo específico de cada software. A estratégia porém não considera particularidades de cada modelo e seus objetivos primordiais, apenas considera uma estrutura padronizada a ser utilizada para todos.
Santos e Costa (2016) propõe um conjunto de regras de conversão de uma estrutura tabular, referente à um modelo relacional para implementações em HBase, uma base de dados do modelo família de colunas e um conjunto de regras para a conversão para Hive, uma imple- mentação Structured Query Language (SQL) baseada em Hadoop. O artigo apresenta apenas a aplicação em HBase, um software que implementa o modelo de família de colunas, e Hive sendo os dados todos armazenados de forma tabular, o que sugere que a estratégia apenas se aplique a modelos de estruturas tabulares como o família de colunas e relacional.
Outra proposta, chamada de NoSQL Schema Evaluator (NoSE) propõe uma abordagem capaz de identificar a aplicação de boas práticas no desenvolvimento de bases de dados NoSQL sem necessariamente codificá-las (MIOR et al., 2017). A proposta sugere que o processo de design automatizado produz esquemas de banco de dados mais eficientes do que os que seriam produzidos em uma abordagem baseada em regras, processo normalmente aplicado nesse con- texto. A proposta é limitada exclusivamente ao uso no modelo de dados de família de colunas e mais especificamente para uso com o Cassandra, mas sugere que seria possível também ser adaptada para o uso com HBase. Ainda assim, não seria adaptável para os demais modelos,
como orientado a documentos, chave-valor ou grafos.
Outra preocupação apontada pelos autores é a ausência de uma estratégia de acesso uniforme aos diversos bancos de dados existentes. Uma proposta é apresentada por Atzeni, Bu- giotti e Rossi (2012), chamada de Save our Systems (SoS). Essa estratégia aborda também o processo de modelagem lógica necessário para que os modelos de dados se tornem compatíveis com a chamada "meta-camada", que seria uma etapa intermediária entre a aplicação e os ban- cos de dados a serem utilizados. Posteriormente, em Atzeni e Bugiotti (2014) é apresentado um modelo de programação baseado no SoS para permitir o tratamento homogêneo de diferentes bases de dados não-relacionais, mais especificamente Redis, MongoDB e HBase. Os modelos apresentados são baseados no conceito de agregados mas os autores não apresentam nenhuma restrição ao uso de outros modelos de dados.
Baseado no conceito de ausência de esquema, Gallinucci, Golfarelli e Rizzi (2018) sugere uma metodologia de documentação das variantes do esquema visando elencar as regras de armazenamento dos dados. Essa metodologia não se trata de uma metodologia de projeto para banco de dados, mas apenas de documentação de uma base de dados já implementada. A Tabela 3 mostra as principais características das estratégias identificadas e a quais modelos de dados se aplicam. É possível perceber que poucas são as estratégias capazes de atender a todos os modelos de dados, assim como muitas delas não se tratam exatamente de estratégias para o projeto de banco de dados, mas estratégias para a documentação de bancos de dados já definidos. Tabela 3 – Características das estratégias identificadas
Estratégia Modelo de dados Características
NoAM Modelos de agregados Trabalha com modelo intermediário e não consi- dera as particularidades de cada modelo
(SANTOS; COSTA, 2016)
Relacional e Família de co- lunas
É uma estratégia de conversão do modelo de dados para outros modelos tabulares.
NoSE Família de Colunas Identifica a aplicação de boas práticas na estrutura do banco de dados
SoS Todos os modelos Trata de uma metodologia de desenvolvimento, não é uma estratégia de projeto
(GALLINUCCI; GOLFARELLI; RIZZI, 2018)
Família de Colunas Processo de documentação de variantes, não trata de uma metodologia de projeto
Fonte: Autoria Própria
3.2.4 QP4. Quais Dessas Estratégias se Aplicam ou Poderiam Ser Aplicadas para a Persistência Poliglota?
A maioria dos artigos selecionados propõe metodologias voltadas apenas aos mode- los baseados em agregados, e alguns ainda apenas para um desses modelos. A metodologia SoS, proposta por Atzeni, Bugiotti e Rossi (2012) menciona ser possível sua aplicação para os
modelos de agregados e o modelo relacional, porém trata-se mais de uma metodologia de de- senvolvimento do que uma metodologia para o projeto de banco de dados. Ela estabelece o que eles chamam de "meta-camada", responsável pelas abstrações necessárias para a utilização de diferentes softwares ou mesmo modelos de dados distintos de forma transparente ao restante da aplicação. Porém, isso não estabelece um método para o projeto dos bancos de dados, apenas uma forma de utilização mais flexível, que permite a transição entre os softwares e modelos de dados de forma mais fácil.
A metodologia NoAM, proposta por Bugiotti e Cabibbo (2014), propõe uma metodo- logia para projeto de bancos de dados a partir da criação de uma camada para a definição dos agregados e futura conversão para os modelos específicos a serem utilizados. Por essa metodo- logia é possível se utilizar de um mesmo modelo lógico e aplicá-lo em bases de dados do modelo chave-valor, orientado a documentos ou família de colunas. É uma metodologia que permite a utilização de vários modelos de dados, mas apenas os orientados a agregados. Ela também não estabelece um forma de estabelecer os limites entre os modelos, caso seja o caso da aplicação de múltiplos modelos em uma mesma aplicação.
Srivastava e Shekokar (2017) demonstra um modelo de implementação utilizando a persistência poliglota para um sistema de e-commerce, porém não estabelece uma metodologia para o projeto de banco de dados. Seu enfoque está principalmente relacionado à apresentação dos desafios referentes a implementação de uma aplicação que necessite de múltiplos bancos de dados.
3.2.5 Ameaças a Validade
Apesar dos processos definidos para a construção de revisões sistemáticas proposto por Pagani, Kovaleski e Resende (2015) serem definidos de forma a garantir um mapeamento como o máximo de validade, alguns parâmetros definidos para o processo de mapeamento podem pôr em risco os resultados encontrados. Essa seção expõe os riscos identificados para este mapeamento. ∙ String de busca: A definição da string de busca foi feita com base nas pesquisas preli- minares, identificação de palavras-chave relevantes e a sua combinação visando obter o máximo de artigos relevantes e desconsiderar os artigos não relacionados ao tema. Ainda assim, pela impossibilidade de filtragem de alguns termos como desempenho pela possibi- lidade de excluir trabalhos relevantes, a pesquisa tornou-se muito ampla e muitos trabalhos não diretamente relacionados ao tema de pesquisa. Além disso, sinônimos dos termos de busca utilizados podem não ter sido identificados durante a pesquisa preliminar e com isso alguns artigos podem ter sido deixados de fora.
∙ Bases de dados: Mesmo utilizando-se de bases de dados consideradas relevantes para a área de pesquisa, alguns artigos podem não estar ainda disponíveis para a essas bases de dados, o que impediu a sua localização. Diferenças no mecanismo de pesquisa das bases
de dados também podem afetar a localização dos artigos, mesmo havendo uma validação prévia das strings de busca.
∙ Seleção dos artigos: Devido à impossibilidade de definir uma string de busca mais restri- tiva, uma quantidade muito grande artigos tiveram que passar pelos processos de filtragem manual que foi realizado apenas por uma pessoa. Isso pode acarretar em algumas falhas no processo de seleção devido a grande quantidade de conteúdo e a falhas de interpre- tação dos conteúdos, algo que poderia ser reduzido caso houvessem mais pesquisadores envolvidos no processo.