Uma abordagem para escolha entre os paradigmas de banco de dados Relacional e NoSQL em projetos de software.

(1)

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE ENSINO SUPERIOR DO SERIDÓ

DEPARTAMENTO DE COMPUTAÇÃO E TECNOLOGIA

BACHARELADO EM SISTEMAS DE INFORMAÇÃO

UMA ABORDAGEM PARA ESCOLHA ENTRE OS PARADIGMAS DE

BANCO DE DADOS RELACIONAL E NO

SQL EM PROJETOS DE

SOFTWARE

PAULO WAGNER SILVA DA COSTA

Caicó/RN

2019

(2)

PAULO WAGNER SILVA DA COSTA

UMA ABORDAGEM PARA ESCOLHA ENTRE OS PARADIGMAS DE

BANCO DE DADOS RELACIONAL E NoSQL EM PROJETOS DE

SOFTWARE

Trabalho de conclusão de curso apresentado ao curso de graduação em Sistemas de Informação, como parte dos requisitos para obtenção do título de Bacharel em Sistemas de Informação da Universidade Federal do Rio Grande do Norte.

Orientador: Prof. Dr. Taciano de Morais Silva

Caicó/RN

2019

(3)

Costa, Paulo Wagner Silva da.

Uma abordagem para escolha entre os paradigmas de banco de dados Relacional e NoSQL em projetos de software / Paulo Wagner Silva da Costa. - Caicó, 2019.

46f.: il.

Monografia (Bacharelado em Sistemas de Informação) -Universidade Federal do Rio Grande do Norte, Centro de Ensino Superior do Seridó - Campus Caicó, Departamento de Computação e Tecnologia, Curso de Sistemas de Informação.

Orientador: Taciano de Morais Silva.

1. Not only Structured Query Language. 2. Bancos de dados. 3. Structured Query Language. 4. Sistemas de Gerenciamento de Banco de Dados. 5. Paradigmas de Banco de Dados. I. Silva, Taciano de Morais. II. Título.

RN/UF/BS-Caicó CDU 004.4'2

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Profª. Maria Lúcia da Costa Bezerra - - CERES--Caicó

(4)

PAULO WAGNER SILVA DA COSTA

UMA ABORDAGEM PARA ESCOLHA ENTRE OS

PARADIGMAS DE BANCO DE DADOS RELACIONAL E

NoSQL EM PROJETOS DE SOFTWARE

Trabalho de conclusão de curso apresentado ao curso de graduação em Sistemas de Informação, como parte dos requisitos para obtenção do tí-tulo de Bacharel em Sistemas de Informação da Universidade Federal do Rio Grande do Norte.

Caicó/RN, 14 de Dezembro de 2019

Prof. Dr. Taciano de Morais Silva Orientador

Prof. Dr. Flavius da Luz e Gorgônio Examinador(a)

Prof. Dr. Humberto Rabelo Examinador(a)

Caicó/RN

2019

(5)

A minha família e aos meus amigos. Vocês são a minha motivação e determinação das minhas conquistas.

(6)

Agradecimentos

Primeiramente agradeço a Deus pela vida, força, inteligência. Aos meus pais, Cândido Santos da Costa e Maria Gorete Silva da Costa por serem minhas principais referências em educação e integridade pessoal.

À minha companheira, Andressa Ravanny Silva da Costa, por sempre estar ao meu lado durante esta longa jornada. Obrigado por me apoiar e fortalecer com suas palavras, amor, carinho e dedicação.

A todos os meus amigos, que sempre me apoiaram e nunca me deixaram desistir bem como aos colegas do curso de Bacharelado em Sistemas de Informação, por cada momento vivenciado, pelas amizades, apoios e conhecimentos.

Ao meu orientador, Prof. Me. Taciano de Morais Silva por todas as oportunidades e ensinamentos. Obrigado pela confiança e por acreditar no meu potencial.

Aos colegas do Laboratório de Inteligência Computacional Aplicada aos Negócios, pelos momentos de convivência, pelas contribuições direta ou indiretamente prestadas a este trabalho.

Por fim, a todos aqueles que, durante meu processo de formação, deram-me forças, apoio e conselhos para seguir em frente e não desistir: a vocês, minha mais sincera gratidão.

(7)

“Prefiram a minha instrução à prata, e o conhecimento ao ouro puro, pois a sabedoria é mais preciosa do que rubis;

nada do que vocês possam desejar compara-se a ela.” (Bíblia Sagrada, Provérbios 8,10-11)

(8)

Resumo

Desenvolver uma aplicação nunca é tão simples quanto parece, principalmente na fase de análise de requisitos, onde é feito um levantamento dos atributos e relacionamentos que o sistema terá. Neste momento o desenvolvedor deve reunir a maior quantidade de informação possível para obter sucesso na criação do sistema almejado, umas das informações cruciais para tal é o tipo e a quantidade de dados que o sistema irá armazenar. Definido isto, surge à necessidade de escolha de um BD (Banco de Dados) adequado às especificidades do sistema, com o crescimento do volume de dados gerados por aplicações web e principalmente pelos requisitos diferenciados que essas aplicações exigem, como a escalabilidade sob demanda e elevado grau de disponibilidade, fez surgir novos bancos de dados que implementam um paradigma diferente do Relacional, conhecidos como NoSQL (Not Only SQL) e desenvolvidos com a promessa de maior adequação ao grande volume de dados gerados por estas aplicações bem como ao tipo de dados gerados por elas dados estes semiestruturados ou em alguns casos sem nenhuma estrutura predefinida. Levando em consideração a grande quantidade de banco de dados disponíveis atualmente principalmente os que são desenvolvidos seguindo como modelo o paradigma NoSQL, torna cada vez mais difícil o processo de escolha de um paradigma específico para determinada aplicação, bem como o que melhor se adeque aos dados que a mesma irá gerar, seguindo essa linha de pensamento o presente trabalho propõe um estudo comparativo entre os dois paradigmas de BDs citados e por meio da análise dos vários tipos de BDs que os implementam foi realizado um levantamento dos principais requisitos levado em consideração no momento da escolha de um banco de dados, aliado a isto foi definido os pontos positivos e negativos de cada paradigma, ao se reunir esta gama de informações, foi desenvolvido um algoritmo de auxílio à escolha de paradigmas de banco de dados, que visa agilizar e aprimorar o processo de escolha do paradigma adequado a sua aplicação.

Palavras-chave: Not Only Structured Query Language, Bancos de dados, Structured Query Language, Sistema Gerenciador de Banco de Dados, Paradigmas de Banco de Dados.

(9)

Abstract

Developing an application is never as simple as it sounds, especially in the requirements analysis phase, where a survey of the attributes and relationships that the system will have is done. At this time the developer must gather as much information as possible to succeed in creating the desired system, one of the information crucial to this is the type and amount of data that the system will store. Defined this, arises the need to choose a BD (Database) appropriate to the specificities of the system, with the growth of the volume of data generated by web applications and mainly by the differentiated requirements that these applications require, such as on-demand scalability and a high degree of availability, new databases that implement a different relational paradigm, has been emerging, known as NoSQL (Not Only SQL) and developed with the promise of greater suitability to the large volume of data generated by these applications as well as the type of data generated by them given these semi-structured or in some cases without any predefined structure. Taking into account the large amount of databases currently available especially those that are developed following as a model the NoSQL paradigm, makes it increasingly difficult for the process of choosing a specific paradigm for a given application, as well as what best adheres to the data it will generate, following this line of thought the present work proposes a comparative study between the two paradigms of BDs cited and through the analysis of the various types of BDs that implement them, a survey of the main requirements taken into account at the moment was carried out. From the choice of a database, allied to this, the positive and negative points of each paradigm were defined. By gathering this range of information, an algorithm was developed to help the choice of database paradigms, which aims to speed and improve the process of choosing the appropriate paradigm for your application.

Keywords: Not Only Structured Query Language, Databases, Structured Query Language, DBMS, Database Paradigms.

(10)

LISTA DE FIGURAS

Figura 1 – Exemplo de banco de dados chave-valor . . . 22

Figura 2 – Exemplo de banco de dados orientado a colunas . . . 23

Figura 3 – Exemplo de banco de dados orientado a documentos . . . 24

Figura 4 – Exemplo de banco de dados baseado em grafos . . . 25

Figura 5 – Página inicial do Algoritmo de Recomendação . . . 31

Figura 6 – Nível de Escolaridade . . . 38

Figura 7 – Porcentagem de desenvolvedores que conhecem o paradigma NoSQL. . . . 39

Figura 8 – SGBDs Implementados . . . 39

Figura 9 – Divergência entre paradigma implementado e paradigma recomendado . . . 40

(11)

LISTA DE TABELAS

Tabela 1 – Comparação entre os trabalhos relacionados . . . 27

Tabela 2 – Principais diferenças entre o paradigma Relacional e NoSQL . . . 29

Tabela 3 – Comparação entre as principais características do paradigma Relacional e NoSQL . . . 30

Tabela 4 – Pontuação para questão 1 . . . 32

(12)

LISTA DE ABREVIATURAS E SIGLAS

ACID Atomicity Consistency Isolation Durability

BD Banco de dados

CAP Consistency, Availability and Partition Tolerance

DW Data Warehouse

ER Entidade Relacionamento

FK Foreign Key

IBM International Business Machines

JSON JavaScript Object Notation

NoSQL Not Only Structured Query Language

OLAP On-Line Analytical Processing

PHP Hypertext Preprocessor

PK Primary Key

SGBD Sistemas de Gerenciamento de Banco de Dados

SI Sistemas de Informação

SQL Structured Query Language

(13)

Sumário

1 INTRODUÇÃO . . . . 14 1.1 Contextualização e Problema . . . 14 1.2 Objetivos . . . 15 1.2.1 Objetivo Geral . . . 15 1.2.2 Objetivos Específicos . . . 15 1.3 Delimitação do Estudo . . . 15 1.4 Justificativa . . . 16 1.5 Apresentação do Trabalho . . . 16 2 FUNDAMENTAÇÃO TEÓRICA . . . . 18 2.1 Banco de Dados . . . 18

2.2 Banco de Dados Relacional . . . 18

2.3 Banco de Dados NoSQL. . . 19

2.3.1 Escalabilidade . . . 20

2.3.1.1 Escalabilidade Horizontal . . . 21

2.3.1.2 Escalabilidade Vertical . . . 21

2.3.2 Esquema Flexível ou Ausência de Esquema . . . 21

2.3.3 Consistência Eventual . . . 22 2.4 Tipos de NoSQL . . . 22 2.4.1 Chave Valor . . . 22 2.4.2 Orientado a Colunas . . . 23 2.4.3 Orientado a Documentos . . . 24 2.4.4 Orientado a Grafos. . . 24 2.5 Trabalhos Relacionados. . . 25 3 METODOLOGIA . . . . 28 3.1 Proposta Metodológica . . . 28 3.2 Questões de Pesquisa . . . 28 4 DESENVOLVIMENTO DA PESQUISA . . . . 29 4.1 SQL vs NoSQL . . . 29 4.2 Algoritmo de Recomendação . . . 31 4.3 Aplicação do Formulário . . . 37

4.4 Validação do Algoritmo de Recomendação . . . 40

(14)

5.1 Discussão . . . 43

5.2 Contribuições . . . 43

5.3 Trabalhos Futuros . . . 43

(15)

14

1 Introdução

1.1 Contextualização e Problema

SegundoDiana e Gerosa(2010b), a utilização de banco de dados surge com a criação de sistemas computacionais e com a necessidade de se armazenar os dados gerados por essas aplicações. Inicialmente estes bacos de dados eram simples e não existia um grande volume de dados.Silberschatz, Sundarshan e Korth(2016), diz que o inicio da utilização de banco de dados se deu em meados dos anos 60, implementados em computadores grandes e caros conhecidos como mainframes, mantendo seu uso e desenvolvimento em alta até as décadas de 70 e 80, os principais modelos ou tipos de banco de dados utilizados eram o Hierárquico e o de Rede, sendo o banco de dados baseado em rede uma evolução do banco de dados hierárquico. Em 1970, E. F. Codd, um dos pesquisadores da International Business Machines (IBM), publicou o primeiro artigo sobre banco de dados relacionais, emCodd(1970), Cood discutiu o uso de cálculo e álgebra relacional, para permitir que usuários não técnicos, armazenassem e recuperassem grandes quantidades de informação. Com a evolução de pesquisas na área, empresas como a Honeywell Information Systems Inc. e a Oracle, criaram seus próprios bancos de dados baseados em muitos princípios do sistema que a IBM desenvolveu, em meio a estas revoluções tecnológicas a IBM desenvolve o DB2, uma evolução de um banco de dados antigo chamado Sistema R, criando o precursor dos bancos de dados atuais. SegundoGalassi(2009), o banco de dados relacional foi e ainda é bastante utilizado devido a várias vantagens como densidade, velocidade, atualidade e proteção. O banco de dados Relacional passou a ser usados em todos os tipos de aplicações, não importando se eram ou não adequados ao modelo relacional o desenvolvedor tinha que adequar sua aplicação ao banco de dados relacional. Com o avanço tecnológico, a ideia de se armazenar todo tipo de dado no banco de dados relacional, fez com que diversos profissionais da área enfrentassem vários problemas, principalmente quando se trava de armazenamento de dados complexos e de grande volume.

Nos últimos anos ocorreu um crescimento exponencial no número de dados coletados e armazenados pelos mais variados dispositivos e sistemas de informação. SegundoLóscio, Oli-veira e Pontes(2011), o advento da internet tem revolucionado a forma como criamos conteúdos e trocamos informações, além de criar um ambiente favorável para o surgimento de uma série de aplicações com demanda de requisitos diferenciados como um alto grau de disponibilidade e escalabilidade sobre demanda, contribuiu para o surgimento de novos paradigmas de banco de dados e novas tecnologias de Sistemas de Gerenciamento de Banco de Dados (SGBD). O termo Big Dataé utilizado para definir este grande volume de dados de alta velocidade, complexos e variáveis que requerem técnicas e tecnologias avançadas para permitir a captura, armazenamento, distribuição, gerenciamento, e análise da informação (COLVIN,2019). A explosão no uso de

(16)

Capítulo 1. Introdução 15

Big Datafez com que grandes empresas demandassem por SGBDs capazes de gerenciar grandes volumes de dados de forma eficaz e com um alto desempenho. Nesse contexto, os tradicionais SGBDs relacionais apresentam algumas limitações quanto a alta concorrência em operações de leitura e escrita, armazenamento de forma eficiente, suporte a escalabilidade horizontal, além da garantia de um serviço rápido e uma alta disponibilidade. Levando em consideração essas necessidades, uma variedade de novos SGBDs surgiram, focados principalmente no baixo custo de operação e manutenção. Esses tipos de bancos de dados são popularmente conhecidos por NoSQL, que é um acrônimo para “Not Only SQL”. Os SGBDs NoSQL geralmente são classificados de acordo com o modelo de dados adotado como: chave-valor, documentos, colunar e orientado a grafos, sendo os três primeiros também chamados de modelos baseados em chave (FROZZA et al., 2018), com a expansão da criação e uso de novos paradigmas de BDs, em especial, os tidos como NoSQL, surge a necessidade de um estudo comparativos que indiquem em que cenários melhor se encaixam cada paradigma (NOSQL,2010).

1.2 Objetivos

1.2.1 Objetivo Geral

Criar um algoritmo de recomendação de paradigmas de banco de dados que auxilie o desenvolvedor no processo de tomada de decisões possibilitando assim uma escolha do paradigma de banco de dados ideal ou mais adequado a sua aplicação ainda na fase de seu desenvolvimento.

1.2.2 Objetivos Específicos

1. Definir os principais SGBDs que implementam o paradigma Relacional e NoSQL, bem como suas características.

2. Desenvolver um algoritmo de recomendação de paradigma de banco de dados.

3. Elaborar e aplicar uma pesquisa em desenvolvedores de softwares, para coletar informações sobre as características de uma aplicação que os mesmos desenvolveram, em seguida aplicar estas informações no algoritmo de recomendação.

4. Analisar e validar os resultados obtidos.

1.3 Delimitação do Estudo

Cada projeto tem suas peculiaridades, e pouco foi escrito até hoje a respeito da seleção de paradigmas de banco de dados (SADALAGE; FOWLER,2013). SegundoSouza et al.(2014), existe pouco estudo sobre o processo de seleção de um paradigma de banco de dados ou até mesmo de um banco de dados que realmente contenha as características necessárias para a

(17)

aplicação desejada. Aliado a este fato segundoRockenbach et al.(2018), existe um enorme crescimento no número de banco de dados disponíveis em especial quando nos referimos a banco de dados que implementam o paradigma NoSQL, o que dificulta a tomada de decisão quanto a melhor escolha na hora do desenvolvimento de uma aplicação.Oliveira et al.(2018) nos mostra que em meio a tantas possibilidades de se definir qual SGBD utilizar, mesmo com o forte conceito de que os SGBDs Relacionais são adequados a todas as situações, muitos desenvolvedores não sabem ao certo em quais situações é vantajoso aplicar as alternativas do paradigma Relacional ou NoSQL. Com poucas recomendações indicando em que contexto usar determinado paradigma surgiu a seguinte questão: Em qual situação usar o paradigma de banco de dados Relacional ou o NoSQL?.

Delimitaremos os esforços em busca dos principais fatores que levam o desenvolvedor a escolher um paradigma de banco de dados em consequente o SGBD para a sua aplicação, considerando os dois principais paradigmas de bancos de dados, o paradigma Relacional e o paradigma NoSQL, para tal, delimitaremos o grupo de desenvolvedores que iremos estudar, focaremos apenas nos desenvolvedores em formação, que estão cursando Sistemas de Informação na UFRN em Caicó-RN, e alguns desenvolvedores que se formaram no referido curso e que já atuam no mercado de trabalho.

1.4 Justificativa

A justificativa para este trabalho é fundamentada na pouca quantidade de estudos relacionados com o processo de seleção de paradigmas de banco de dados no momento de desen-volvimento de um aplicação. SegundoDiana e Gerosa(2010b), existem poucas recomendações que indiquem em que contexto usar determinado paradigma, ressalta também que existem poucos estudos comparativos que mostrem onde se utilizar cada um destes, aliado a este fato existe uma enorme quantidade de banco de dados principalmente os que implementam o paradigma NoSQL criando com isso um grande desafio para desenvolvedor que desejam migrar com êxito de sistema de gerenciamento de dados atuais para sistemas de larga escala (DAVOUDIAN; CHEN; LIU,2018).

Esta pesquisa tem como finalidade ajudar a preencher essa lacuna por meio de um levantamento bibliográfico sobre os principais critérios usados no momento da escolha de um paradigma, dentro desse contexto, visa à elaboração de um algoritmo de recomendação de escolha de paradigmas, que auxilie com uma maior precisão a escolha do paradigma mais adequado ou que melhor se adapte a aplicação almejada.

1.5 Apresentação do Trabalho

(18)

O Capítulo1definido como introdução apresenta uma visão geral da pesquisa, optamos por dividir o mesmo em 5 seções que abordam os seguintes temas: na Seção1.1 apresenta a contextualização do problema, na Seção 1.2aborda os objetivos da pesquisa que devido a especificidades existentes o mesmo foi dividido em dois sub tópicos o Objetivo Geral1.2.1e os Objetivos Específicos1.2.2, em seguida abordamos os tópicos delimitação e estudo na Seção1.3, a justificativa na Seção1.4e por fim a apresentação do trabalho Seção1.5.

O Capítulo 2trata da fundamentação teórica, onde é observado o conceito geral de banco de dados na Seção2.1, o conceito do paradigma de banco de dados relacional na Seção2.2, o conceito do paradigma de banco de dados NoSQL na Seção2.3, na Seção2.4apresentamos os principais tipos de bancos de dados que implementam o paradigma NoSQL e por fim os trabalhos relacionados Seção2.5.

O Capítulo3aborda a proposta e a elaboração da metodologia na Seção3.1bem como as questões de pesquisa Seção3.2que norteiam por onde o trabalho deve seguir.

O Capítulo 4 foi dividido em 4 seções, na Seção 4.1 foi apresentado as principais diferenças encontradas entre os dois paradigmas de banco de dados aqui estudados, bem como as principais características encontradas em ambos os paradigmas, a Seção 4.2 apresenta o algoritmo de recomendação proposto pelo presente trabalho, nesta seção esta descrito o pseudocódigo do algoritmo bem como a pontuação atribuída a cada característica, na Seção4.3 apresenta todos os dados importantes obtidos com a aplicação do survey, na quarta e ultima seção 4.4apresentamos todos os resultados obtidos com a aplicação do algoritmo de recomendação.

No Capítulo5estão os Tópicos Discussão5.1, Contribuições5.2e Trabalhos Futuros5.3. Por fim, são apresentadas as referências bibliográficas dos trabalhos lidos que forneceram o conhecimento necessário para a elaboração deste trabalho.

(19)

18

2 Fundamentação Teórica

2.1 Banco de Dados

Um banco de dados é uma coleção de dados relacionado (ELMASRI et al.,2005). O termo banco de dados é bastante genérico, cada autor o define de uma maneira própria. De uma forma geral, pode-se afirmar que um banco de dados é no computador a parte onde se pode guardar e recuperar informações de forma relacionada, aliado a isto um banco de dados pode ter diferentes tamanhos e complexidades, ficando a cargo do desenvolvedor analisar e escolher o banco de dados que forneça os recursos necessários para os dados que deseja armazenar. SegundoCampos et al.(2008), projetar e implementar a base de dados é uma das tarefas mais importantes na criação de um sistema de informação e cada projeto de banco de dados demanda diferentes especificações. Estas especificações variam de acordo com a complexidade dos dados, atualmente até mesmo tarefas simples estão sendo automatizadas e o número de sistemas com grandes volumes de dados não para de crescer (OLIVEIRA et al.,2018), conforme já apresentado na Seção1.3, o presente trabalho foca em dois paradigmas de bancos de dados o paradigma Relacional e o paradigma NoSQL, sendo assim a seguir apresentaremos ambos os conceitos dos bancos de dados que compõem estes paradigmas, na Seção2.2apresentamos o conceito de bancos de dados relacionais e na Seção2.3o conceito de banco de dados NoSQL.

2.2 Banco de Dados Relacional

SegundoElmasri et al. (2005), os SGBDs relacionais foram criados com o objetivo de separar o armazenamento físico dos dados de sua representação conceitual, o uso desta representação possibilitou a redução de enormes pilhas de papéis existentes nas empresas. O paradigma de banco de dados relacional surgiu com a ideia de Ted Codd (CODD,1970), em sua conceituação definiu que por meio do uso de cálculo e álgebra relacional o usuário poderia armazenar e recuperar os dados de uma determinada aplicação posteriormente. Segundo Ryberg, Frozza e Varela(2014), o SGBD relacional é representado por um conjunto de tabelas relacionadas, cada tabela e formada por colunas e linhas e cada registro na tabela é identificado por um campo chave que contém um valor único. Segundo (OLIVEIRA et al.,2018), a relação entre duas tabelas é estabelecida através de valores correspondentes de um campo compartilhado, estas tabelas relacionam-se umas às outras através de chaves. Uma chave é um conjunto de um ou mais atributos que tornam um registro único. Existem dois tipos de chaves:

1. Chave Primária: (PK - Primary Key) é a chave que identifica cada registro. A chave primária nunca se repetirá.

(20)

Capítulo 2. Fundamentação Teórica 19

2. Chave Estrangeira: (FK - Foreign Key) é a chave formada através de um relaciona-mento com a chave primária de outra tabela. Define um relacionarelaciona-mento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave primária seja composta na origem, a chave estrangeira também o será.

Com o uso de relacionamentos lógicos entre as informações referentes evita-se a neces-sidade de repetição de informações acelerando o processo de consulta (KAUFELD; LUDERMIR, 1996). SegundoLóscio, Oliveira e Pontes(2011), uma importante função de um SGBD relacional é o conjunto de operações de leitura e escrita dentro de uma banco de dados, e para que se possa garantir o funcionamento correto destas transações o SGBD deve seguir algumas propriedades conhecidas como propriedade ACID (Atomicity, Consistency, Isolation, Durability), conforme definidas a seguir:

1. Atomicity (Atomicidade) – Todas as execuções são realizadas por completo, se a transação realizada envolver duas ou mais partes ou é executada por completo ou não será executada.

2. Consistency (Consistência) – Após a conclusão da transação é criado um novo estado válido, caso contrário os dados voltam para o estado inicial, satisfazendo as condições de consistência e restrições de integridade.

3. Isolation (Isolamento) – transações concorrentes devem permanecer isoladas para se garantir que um não interfira na transação da outra.

4. Durability (Durabilidade) – Garantia que os dados permaneçam em um estado válido mesmo após uma falha ou reiniciado o sistema.

Existe alguns tipos de SGBD que não seguem exatamente estas propriedades pois na busca por outras características demandadas pela enorme quantidade de aplicações e dados gerados por estas aplicações abrem mão de algumas regras encontradas no paradigma relacional, é o caso dos SGBDs que implementam o paradigma NoSQL descritos na seção2.3.

2.3 Banco de Dados NoSQL

SegundoOliveira e Cura(2017), o termo NoSQL vem sendo bastante utilizado como um termo geral para agrupar uma série de projetos de implementações de modelos de banco de dados com diferenças significativas quando comparamos ao paradigma relacional. O termo foi utilizado pela primeira vez em 2009 por Carlo Strozzi, descrevendo um banco de dados criado por ele e que não utilizava a linguagem SQL para realizar consultas, nem implementava o modelo relacional (FOWLER,2015). Cada banco de dados NoSQL segue um padrão específico voltado para uma situação, trazendo assim novas perspectivas, tais como: flexibilidade no modelo de dados, alta escalabilidade permitindo estruturas de dados dinâmicas e adaptáveis e agilidade em sua implementação além de novas linguagens de consulta apropriadas aos modelos de dados e

(21)

diversas interfaces para acesso aos dados.

SegundoCarniel et al.(2012), os banco de dados NoSQL são adequados para aplicações com necessidades especificas como: necessidade de alto desempenho em uma operação especifica de processamento de dados não voláteis. Vários trabalhos que abordam o tema NoSQL, destacam 4 tipos de implementações de base de dados que seguem as premissas do paradigma NoSQl porém armazenam diferentes tipos de dados. SegundoSantos e Silva(2013),Sadalage e Fowler (2013),Carniel et al.(2012),Corbellini et al.(2017), estes 4 tipos de base de dados citados são : 1. Modelo orientado a Chave-Valor.

2. Modelo orientado a Colunas.

3. Modelo orientado a Documentos.

4. Modelo orientado a Grafos.

SegundoSadalage e Fowler(2013), os principais motivos pelos quais os pesquisadores consideram os bancos de dados NoSQL interessantes são a produtividade no desenvolvimento de aplicativos, pois em muitos casos se gasta muito tempo mapeando e adequando seus dados a base de dados relacional e a capacidade de se adequar a grandes volumes de dados. Como não existe um limite de crescimento para um BD NoSQL, este tipo de banco de dados se torna essencial para a grande demanda de espaço imposta por aplicações atuais.Rys(2011), afirma que um dos principais motivadores para o grande crescimento no uso e evolução do paradigma NoSQL é o desejo de se alcançar uma alta escalabilidade para lidar com a enorme carga de dados gerados pelos mais diversos sistemas e aplicativos da internet. O paradigma de banco de dados NoSQL conta com várias características que o diferencia do Relacional, características estas como a escalabilidade, esquema flexível ou livre de esquema e consistência eventual podem ser encontradas em vários trabalhos, a seguir descreveremos estas três principais características do paradigma NoSQL.

2.3.1 Escalabilidade

Segundo LóscioLóscio, Oliveira e Pontes(2011), a escalabilidade se dá a medida que a quantidade de dados gerado pela aplicação cresce, criado assim um aumento da necessidade de desempenho por parte da aplicação. Os bancos de dados relacionais utilizam características transacionais conhecidas como ACID, onde através destas propriedades é garantido a integridade dos dados, porém em um ambiente onde requisitos como alta disponibilidade e o uso de sistemas distribuídos, torna estas características impraticáveis e favorecem o surgimento de novas formas de se garantir a integridade dos dados. SegundoSantos e Silva(2013), para atender este problema se aplica a bancos de dados NoSQL o teorema CAP (Consistency, Availability and Partition Tolerance), este teorema exige que dois dos seus três aspectos sejam garantidos.

(22)

de uma transação.

2. Availability(Alta disponibilidade) – Garante que o sistema sempre mantenha o acesso do cliente a suas funcionalidades.

3. Partition Tolerance (Tolerância ao particionamento) – Mantém todas as características do sistema, mesmo que instalado em diferentes servidores.

A escalabilidade é dividida em dois tipos escalabilidade horizontal e vertical, definire-mos ambas em2.3.1.1e2.3.1.2.

2.3.1.1 Escalabilidade Horizontal

Segundo Lóscio, Oliveira e Pontes (2011), na escalabilidade horizontal ocorre um aumento no número de máquinas disponíveis para o armazenamento e processamento de dados. SegundoBonfim e Liang(2014), a escalabilidade horizontal acontece quando aumentamos a quantidade de maquinas, gerando assim um aumento no poder de processamento, geralmente são adicionados mais servidores, permitindo a criação de um cluster. O uso de bancos de dados que implementam o paradigma relacional é impraticável quando falamos de escalabilidade horizontal devido ao alto gral de concorrência dos processos.

2.3.1.2 Escalabilidade Vertical

Segundo Bonfim e Liang (2014), a escalabilidade vertical acontece quando a uma melhoria de hardware de um único servidor, ou seja, quando é adicionada mais memória, ou o processador é trocado por outro mais potente, entre outros aspectos. Sadalage e Fowler (2013), diz que a escalabilidade vertical consiste em aumentar o poder de processamento e armazenamento das máquinas, esta pratica de escalabilidade é tida como inviável, pois os custos elevados a cada substituição de maquina ou aumento de poder de processamento impossibilita este tipo de escalabilidade.

2.3.2 Esquema Flexível ou Ausência de Esquema

SegundoLóscio, Oliveira e Pontes(2011), o esquema flexível ou ausência de esquema é uma característica bem evidente nos bancos de dados que implementam o paradigma NoSQL. SegundoSaccol(2001), com o crescimento exponencial de dados semi estruturados criados pelas mais diversas plataformas existentes, propiciou o surgimento de uma nova categoria de Banco de dados, desenvolvido para dar suporte a consultas em um ambiente onde não se sabe o esquema ou de que forma o dado se encontra armazenado. Esta característica é fundamental para se garantir uma alta escalabilidade, também contribui para o aumento na disponibilidade da base de dados, um ponto negativo é a não garantia da integridade dos dados.

(23)

2.3.3 Consistência Eventual

Tendo como princípio o teorema CAP, nem sempre é possível se manter a consistência devido ao grande número de de pontos de distribuição de dados. Dentre os diferentes tipos de banco de dados NoSQL,Lóscio, Oliveira e Pontes(2011), afirma que não existe um melhor que o outro, e sim uma melhor adequação para cada tipo de problema, pois cada tipo de banco de dados NoSQL tem seu contexto específico de uso.

2.4 Tipos de NoSQL

Lóscio, Oliveira e Pontes(2011) classificam os principais tipos de modelos de dados NoSQL em: chave-valor, orientado a colunas, orientado a documentos e orientado a grafos. Para os autores até agora estudados, um determinado modelo não deve ser considerado melhor que o outro pois cada modelo de base de dados é mais adequado para determinados contextos. Os principais tipos de banco de dados citados anteriormente, bem como as características de cada um destes, são apresentados a seguir.

2.4.1 Chave Valor

Este tipo de banco de dados é composto de uma tabela hash, estrutura especial de dados que associa chaves de pesquisa a valores como podemos ver na figura1, uma estrutura bastante popular pois gera uma grande eficiência devido a sua facilidade de implementação e rapidez na busca de dados, seu acesso aos dados ganha agilidade pois a busca é feita através das chaves, garantindo assim maior rapidez e possibilidade de aumento de capacidade sendo um tipo de banco de dados favorável para sistemas em que a escalabilidade é um ponto forte. Um par chave-valor é um valor único que pode ser facilmente utilizado para acessar os dados (TIWARI, 2011).

Figura 1 – Exemplo de banco de dados chave-valor

(24)

2.4.2 Orientado a Colunas

SegundoPereira et al.(2013), este tipo de banco de dados armazena as informações em famílias de colunas, as linhas são ordenadas e agrupadas conforme seu contexto o que torna este tipo de banco de dados um pouco mais complexo que o modelo chave-valor. Diferente do modelo relacional que tem seu paradigma de orientação a registros ou tuplas, ele utiliza orientação a atributos ou colunas, suas operações de leitura e escrita são atômicas, onde todos os valores associados a uma linha são considerados na execução destas operações.Pokorny(2013), diz que a composição deste banco de dados e formada por uma tripla entre linha, coluna e cada linha e coluna e identificada por chaves.

Apesar de não conter o conceito de tabelas do modelo Entidade Relacionamento (ER), este modelo de BD armazena as informações em famílias de colunas. Neste conceito, as linhas são ordenadas e agrupadas conforme seu contexto, daí a semelhança com tabelas do ER. É o modelo mais propício e com melhor desempenho a ambientes com grandes processamentos de dados distribuídos.

Figura 2 – Exemplo de banco de dados orientado a colunas

Fonte: O autor (2019)

A Figura2, mostra que o modelo baseado em colunas segue um conceito conhecido como família de colunas, usado para agrupar colunas que contêm o mesmo tipo de dado. SegundoCarniel et al.(2012), o modelo orientado a colunas mesmo utilizando colunas em uma tabela se diferencia do modelo relacional pois suas tabelas não possuem relacionamentos e são armazenadas separadamente, podendo ser possível representar um DW (Data Warehouse) para se usar procedimentos em consultas OLAP (On-Line Analytical Processing), o LucidDB é um exemplo de banco de dados que implementa o tipo orientado a colunas este banco de dados foi criado voltado para o ambiente de DW, existem outros banco de dados que utilizam o tipo orientado a colunas como o Cassandra, Hbase e BigTable sendo este o primeiro banco de dados a implementar o tipo orientado a colunas, entre as características principais deste tipo de BD temos a permissão de particionamento de dados além de oferecer forte consistência, uma desvantagem encontrada neste tipo de banco de dados é a não garantia de alta disponibilidade.

(25)

2.4.3 Orientado a Documentos

SegundoCattell(2011), os bancos de dados orientado a documentos são mais robustos que o BDs chave valor, ou seja, suportam dados mais complexos. No modelo orientado a documentos o sistema armazena documentos que geralmente são do tipo JavaScript Object Notation(JSON) (GU; SHEN; ZHENG,2011).Sadalage e Fowler(2013), define que o banco de dados orientado a documento é um banco de dados que armazena e recupera documentos que podem ser dos tipos XML, JSON, BSON entre outros, estes documentos são estruturas de dados na forma de árvores hierárquicas e que se auto descrevem, constituídas de mapas coleções e valores escalares como apresentamos na figura3. SegundoNayak, Poriya e Poojary(2013), os bancos de dados orientados a documentos apresentam um ótimo desempenho e escalabilidade horizontal, os dados armazenados neste tipo de base de dados são semelhantes aos registros em bancos de dados relacionais, porem são mais flexíveis já que está estrutura de base de dados possui menos esquemas e regras de armazenamento.

Figura 3 – Exemplo de banco de dados orientado a documentos

Fonte: O autor(2019)

2.4.4 Orientado a Grafos

SegundoHiga(2016), bancos de dados orientados a grafos são uma de muitas categorias de bancos de dados NoSQL, a grande diferença para o modelo relacional está na representação explícita de relacionamentos entre os dados, através de um modelo com vértices chamados de nós e linhas chamadas de relações conforme está apresentado na Figura4. SegundoSantos e Silva(2013), o surgimento do banco de dados orientado a grafo está diretamente relacionado com o surgimento do paradigma NoSQL, este tipo de banco de dados foi desenvolvido para um ambiente que demande uma capacidade de se armazenar um grande volume de dados complexos

(26)

além de estruturas que exijam baixo acoplamento e que tendem a sofrer constantes modificações no que diz respeito a criação, remoção, atualização e leitura de dados no banco. O paradigma orientado a grafos veio para ajudar a solucionar o problema de performance existente no modelo de entidades e relacionamentos, isto por conta de sua representação de dados feita a partir de grafos, ou seja, nós e arestas, com esta última sendo responsável pela forma de navegação. Esse modelo se destaca pela velocidade constante de consulta, independentemente da quantidade de nós que constituam o grafo.

Figura 4 – Exemplo de banco de dados baseado em grafos

2.5 Trabalhos Relacionados

Em Pereira (2014), é realizado um estudo sobre a viabilidade e implicação em se adotar o paradigma de banco de dados NoSQL, para tal, o autor faz a comparação entre este paradigma e o paradigma relacional por meio da implementação de três SGBDs diferentes o MongoDB, Cassandra e SQL Server, o autor efetuou várias pesquisas sobre os paradigmas estudados, bem como um estudo específico sobre cada SGBD implementado deixando bem claro muitas características dos dois paradigmas mencionados, correlacionando assim o trabalho aqui proposto ao trabalho citado, pois muitas das características encontradas foram utilizadas neste trabalho, seguindo o mesmo princípioDavoudian, Chen e Liu(2018), apresenta as 5 principais características que devem ser levadas em consideração no momento da escolha de um paradigma de banco de dados.

EmDavidson(1982), é feito um estudo abordando os principais pontos que o desenvol-vedor deve focar no momento da escolha de uma base de dados, começando do hardware a ser

(27)

usado até o tipo de sistema operacional, para realizar sua pesquisa o autor utilizou um questio-nário com várias perguntas relevantes, nossa proposta segue o mesmo princípio de auxilio no momento de escolha de um banco de dados, porém de uma forma mais didática e automatizada, o questionário de papel será substituindo por um algoritmo.

Foram encontrados vários estudos sobre o tema NoSQL, muitos comoDiana e Gerosa (2010a),Lóscio, Oliveira e Pontes(2011), apresentam as principais diferenças entre o banco de dados que implementam o paradigma Relacional e os bancos de dados que implementam o paradigma NoSQL, outros comoLi e Manoharan(2013),Oliveira et al.(2018), comparam bancos de dados que implementam os paradigmas Relacional e NoSQL medindo o desempenho de ambos em funções básicas como velocidade de leitura e escrita.

Em Souza et al.(2014), Observamos uma maior proximidade com o trabalho aqui proposto, neste artigo é feito um amplo estudo sobre os principais critérios para a seleção de um banco de dados NoSQL, a grande diferença encontrada é a busca do autor apenas por critérios de seleção de banco de dados que fazem parte do paradigma NoSQL, o trabalho aqui proposto tem por finalidade o desenvolvimento e validação de um algoritmo de recomendação de ambos os paradigmas de bancos de dados aqui estudados o paradigma Relacional e NoSQL.

(28)

Tabela 1 – Comparação entre os trabalhos relacionados

Trabalho Realizado Trabalho Proposto

(PEREIRA,2014) Comparação ente os

pa-radigmas Relacional e NoSQL, definindo as prin-cipais características dos SGBDs implementados.

Realiza uma pesquisa das principais características dos principais bancos de da-dos que que implementam os paradigmas estudados. (DAVOUDIAN; CHEN; LIU,2018) Apresenta as 5 principais

características que devem ser levadas em considera-ção no momento da escolha de um paradigma de banco de dados.

Segue o mesmo princípio, porém é realizado uma busca mais aprofundada, com isso, identificamos 7 características principais.

(DAVIDSON,1982) Realiza um estudo abor-dando os principais pontos que o desenvolvedor deve focar no momento da esco-lha de uma base de dados.

Nosso trabalho segue a mesma linha de pensa-mento.

(SOUZA et al.,2014) Observamos uma maior pro-ximidade com o trabalho aqui proposto, neste artigo é feito um amplo estudo so-bre os principais critérios para a seleção de um banco de dados NoSQL bem como a indicação em que cenário utiliza-lo.

A principal diferença se en-contra no fato que o traba-lho proposto indica o para-digma de banco de dados ideal e não o banco de da-dos.

(29)

28

3 Metodologia

3.1 Proposta Metodológica

A primeira etapa do trabalho consistiu em um levantamento do estado da arte sobre a definição dos principais requisitos que são levados em consideração no momento da escolha de um paradigma de BD. Para tal, foi realizada uma pesquisa bibliográfica para se coletar informações a partir da leitura de livros, artigos, pesquisas e publicações pertinentes ao assunto. A partir desta pesquisa, foi feito um estudo teórico sobre as técnicas e tecnologias envolvidas no processo de escolha de um paradigma de banco de dados, levando assim a dados relevantes para se definir um algoritmo de recomendação que auxilie nesta escolha.

A segunda etapa focou em uma pesquisa quantitativa realizada por meio de um for-mulário que garantisse respostas objetivas e claras, enviadas através de e-mail para alguns desenvolvedores que atuam no mercado de trabalho e alunos do curso de Sistemas de Informação da UFRN, o que nos forneceu os dados necessários para o desenvolvimento do trabalho.

A terceira etapa reuniu o desenvolvimento e a validação do algoritmo de recomendação proposto no presente trabalho, validação foi dada por meio da comparação das escolhas feitas por desenvolvedores e as recomendações de banco de dados ideais feitas pelo algoritmo.

3.2 Questões de Pesquisa

A grande falta de manuais ou documentação que auxilie o desenvolvedor na escolha de um paradigma de banco de dados foi o principal motivador desta pesquisa, para se chegar ao resultado final almejado por este trabalho fez se necessário a resolução das seguintes perguntas:

1- Quais são os principais requisitos levados em consideração no momento da escolha de um banco de dados e consequentemente de seu paradigma no desenvolvimento de uma aplicação, levando em consideração aplicações que implementam um dos dois paradigmas estudados?

2- Em que momento utilizar cada paradigma e quais as principais vantagens e desvantagens entre o paradigma relacional e NoSQL?

(30)

29

4 Desenvolvimento da Pesquisa

As seções seguintes apresentam desenvolvimento da pesquisa bem como os experimen-tos realizados para se garantir um nível de confiança satisfatório para o presente trabalho.

4.1 SQL vs NoSQL

Com a leitura de diversos trabalhos relacionados a banco de dados e paradigma de banco de dados podemos notar que em sua grande maioria os mesmos comparam características como velocidade de leitura e escrita, tipos de dados suportados e capacidade de escalabilidade, em (FLORENCIO et al.,2017; SOUZA et al.,2014; ROCKENBACH et al.,2018; DIANA; GEROSA,2010b), estas comparações são realizadas com SGBDs que implementam o mesmo paradigma, já em (LIMA; DIóGENES; PEREIRA,2018;LI; MANOHARAN,2013;OLIVEIRA et al.,2018), as comparações são realizadas em SGBDs que implementam diferentes paradigmas. A Tabela2descreve as principais diferenças encontradas entre o paradigma Relacional e NoSQL encontradas na pesquisa realizada.

Tabela 2 – Principais diferenças entre o paradigma Relacional e NoSQL

Relacional NoSQL

Escalonamento À medida que cresce a demanda por mais espaço e capacidade de processamento, cresce proporci-onalmente os custos de implanta-ção.

Com seu desenvolvimento vol-tado para características como uma maior escalabilidade, alguns bancos de dados NoSQL permi-tem inclusive a inserção de novos servidores em tempo de execu-ção.

Consistência Devido a regras rigorosas con-tidas no paradigma Relacional, este é um ponto forte neste pa-radigma.

A depender do SGBD, a consis-tência é garantida eventualmente por meio de técnicas específicas como map/reduce e consistent hashing.

Disponibilidade Sua acessibilidade é limitada a adição de uma grande quantidade de servidores.

Por permitir particionamento ofe-rece uma excelente disponibili-dade.

Esquema de Dados Utiliza um esquema fixo de da-dos.

Esquema totalmente flexível.

Fonte: O Autor (2019)

Com a continuidade da pesquisa identificamos alguns pontos cruciais no momento da escolha de um paradigma de banco de dados, sendo possível descrever um breve resumo sobre

(31)

Capítulo 4. Desenvolvimento da Pesquisa 30

cada um.

1. Facilidade de Implementação – Geralmente o desenvolvedor busca por um SGBD que não demande um grande tempo de estudo para sua implementação, em muitos dos casos sua escolha é feita levando em consideração apenas o prévio conhecimento sobre este SGBD.

2. Tipo de Licença de Uso – Em muitos cenários a empresa ou o desenvolvedor não demanda de tantos recursos e uma licença livre pode ser o diferencial no momento da escolha.

3. Confiabilidade do SGBD – Um ponto importante é o nível de confiança que o desenvolvedor tem com o SGBD.

4. Suporte – Um SGBD que tenha uma comunidade que auxilie o desenvolvedor no momento da implementação e manutenção de seu banco de dados.

5. Continuidade – Nem sempre SGBDs inovadores, tem continuidade e ficam estagnadas como tempo, por falta de novas versões.

A Tabela3, realiza uma comparação entre as principais características encontradas nos SGBDs Redis, MongoDB e o Cassandra que implementam o paradigma NoSQL e o SGBD MySQL que implementa o paradigma Relacional.

Tabela 3 – Comparação entre as principais características do paradigma Relacional e NoSQL

MySQL MariaDB MongoDB Redis Cassandra

Relacional Sim Sim Não Não Não

NoSQL Não Não Sim Sim Sim

Código Aberto Sim Sim Sim Sim Sim

Tolerância a Partição Não Não Sim Sim Sim

Flexibilidade de Esquema Não Não Sim Sim Sim

Estrutura Fixa de Dados Sim Sim Não Não Não

Consistência de Dados Alta Alta Eventual Eventual Eventual

Disponibilidade Baixa Moderada Alta Alta Alta

Escalabilidade Limitada Limitada Alta Alta Alta

Conforme já apresentado, cada paradigma de banco de dados possui características próprias, tais como o tipo de dado que a base de dados suporta ou regra de modelagem de dado que implementa, são características como estas que utilizamos como base para levantar questões e definir o quão apropriado o paradigma é a cada situação e por meio de um algoritmo de recomendação apresentamos para o desenvolvedor um paradigma que melhor se adeque a sua aplicação.

(32)

4.2 Algoritmo de Recomendação

O algoritmo foi implementado na forma de uma aplicação web usando a linguagem de programação Hypertext Preprocessor (PHP), uma linguagem de script open source de uso geral, muito utilizada em projetos web, a página inicial onde o visitante tem acesso as primeiras informações pode ser observada na figura5, esta página contém três abas: início, formulário e informações, na aba formulário o desenvolvedor tem acesso a um formulário com sete perguntas, ao responde-las o algoritmo retorna para o desenvolvedor a recomendação de paradigma ideal.

Figura 5 – Página inicial do Algoritmo de Recomendação

Desenvolvido com base em todas as características de paradigmas de bancos de dados encontradas em nossas pesquisas, o formulário que o mesmo implementa contém 7 questões que contemplam todas estas características essenciais para ambos os paradigmas estudados, à medida que o desenvolvedor escolhe a alternativa com a característica que mais se aproxima da realidade de sua aplicação a cadeia de decisão vai adicionando “pontos” para cada paradigma a depender da característica contida na alternativa, por fim o algoritmo compara que paradigma recebeu a maior pontuação e retorna para o desenvolvedor o paradigma ideal bem como os motivos que levaram a escolha.

O pseudocódigo 4.1 descreve a forma de pontuação da questão 1, esta questão foi desenvolvida com o intuito de testar o nível de interação entre os usuários da aplicação e o banco de dados, este tipo de interação interfere diretamente no processo de escolha de um paradigma de banco de dados em aplicações que os usuários estão constantemente realizando interações com o banco de dados, esta alta interação gera uma demanda por uma disponibilidade elevada bem como uma maior velocidade na leitura e escrita deste banco de dados, devido a estes fatos

(33)

no momento que o desenvolvedor marca a opção “Sim” no questionário ele estará adicionando 2 ponto para o paradigma NoSQL, pois a alta disponibilidade e maior velocidade na leitura e escrita é uma característica de SGBDs que implementam o paradigma NoSQL (POLITOWSKI; MARAN,2014), do contrário se o desenvolvedor marcar a opção “Não” cada paradigma recebe 1 ponto como mostra a tabela4.

1 SE ( RESPOSTA_1 == SIM ) {

SE ( RESPOSTA_2 == GRANDE OU RESPOSTA_2 == MUITO GRANDE) {

3 NOSQL = NOSQL + 2 ; ; }SENAO{

5 NOSQL = NOSQL + 1 ; SQL = SQL + 1 ;

7 }

}SE SENAO( RESPOSTA_1 == NAO) {

11 }

Listing 4.1 – Pseudocódigo da questão 1

Tabela 4 – Pontuação para questão 1

Respostas RELACIONAL NoSQL

Sim 0 2

Não 1 1

1 SE ( RESPOSTA_2 == IRRELEVANTE OU RESPOSTA_2 == PEQUENA OU RESPOSTA_2 == MEDIA) {

SQL = SQL + 1 ;

3 NOSQL = NOSQL + 1 ;

}SE SENAO( RESPOSTA_2 == GRANDE OU RESPOSTA_2 == MUITO GRANDE) {

5 NOSQL = NOSQL + 1 ; }

A segunda questão foi desenvolvida sobre a mesma característica da primeira a esca-labilidade, sendo assim o pseudocódigo4.2apresenta a pontuação que foi pensada a partir da quantidade de usuários que a aplicação poderá alcançar, como mostra a tabela5, a medida que a quantidade de usuários da aplicação cresce segue proporcionalmente a demanda por uma maior escalabilidade, em cenários onde a quantidade de usuários é considerada de irrelevante a média ambos os paradigmas recebem 1 ponto, em aplicações com quantidade de usuários tidas como grande e muito grande, o paradigma NoSQL recebe 1 ponto e o paradigma Relacional não pontua pois SGBDs que implementam o paradigma Relacional enfrentam problemas com relação a escalabilidade e velocidade de leitura e escrita em ambientes com grande quantidade de usuários.

(34)

Irrelevante 1 1 Pequena 1 1 Media 1 1 Grande 0 1 Muito Grande 0 1 Fonte: O Autor (2019) SE ( RESPOSTA_3 == SIM ) { 2 NOSQL = NOSQL − 1 ; SQL = SQL + 1 ;

4 }SE SENAO( RESPOSTA_3 == NAO) { NOSQL = NOSQL + 1 ;

6 }

A terceira questão está focada em duas características que agem paralelamente a consis-tência de dados e a tolerância a falhas. SegundoDiana e Gerosa(2010b), para se atingir níveis maiores de escalabilidade os SGBDs que implementam o paradigma NoSQL optam por uma consistência de dados mais maleável denominadas consistência de dados em tempo determinado, como mostra o pseudocódigo4.3ao optar pela opção “Sim” o desenvolvedor estará adicionando 1 ponto para o paradigma relacional e -1 para o paradigma NoSQL, pois se a aplicação não tolera falhas em sua base de dados não é recomendado o uso de um SGBD NoSQL, levando em consideração apenas os dados obtido até aqui, se o desenvolvedor optar pelo quesito “Não” ele adiciona 1 ponto para o paradigma NoSQL, estas pontuações estão descritas na tabela6.

Sim 1 -1

Não 0 1

A quarta questão foi aplicada para se mensurar o quão importante é para o desenvolvedor a consistências dos dados de sua aplicação, se em algum momento o desenvolvedor ficou em dúvida sobre o que responder na questão anterior, esta questão foi desenvolvida com o intuito de se resolver este problema, pontuando de “irrelevante” a “baixa relevância” 2 pontos para o paradigma NoSQL, 1 ponto para cada paradigma no quesito “indiferente” e 2 pontos para o paradigma relacional nos quesitos “relevante” e “muito relevante”, conforme descrito na tabela7 e pseudocódigo4.4.

(35)

SE ( RESPOSTA_4 == IRRELEVANTE OU RESPOSTA_4 == BAIXA RELEVANCIA ) {

2 NOSQL = NOSQL + 2 ;

}SE SENAO ( RESPOSTA_4 == INDIFERENTE ) {

6 }SE SENAO ( RESPOSTA_4 == RELEVANTE OU RESPOSTA_4 == MUITO RELEVANTE) { SQL = SQL + 2 ;

8 }

Irrelevante 0 2 Baixa Relevância 0 2 Indiferente 1 1 Relevante 2 0 Muito Relevante 2 0 Fonte: O Autor (2019)

SE ( RESPOSTA_5 == AMBIENTE CORPORATIVO ) {

2 SQL = SQL + 2 ; NOSQL = NOSQL − 1 ;

4 }SE SENAO ( REPOSTA_5 == PUBLICO GERAL) { NOSQL = NOSQL + 1 ;

6 SQL = SQL + 1 ; }

A quinta questão leva o desenvolvedor a analisar que tipo de público sua aplicação atenderá ou atende, em aplicações denominadas de aplicações de alto risco, como aplicações hospitalares e controladores de trafego aéreo demandam uma maior integridade de dados, por não seguir a propriedade ACID o paradigma NoSQL deixa de lado a garantia de integridade de seus dados para priorizar outras propriedades, devido a estas propriedades encontradas nos SGBDs que implementam o paradigma Relacional, ao marcando a “opção 1” denominada de Ambiente Corporativo e Aplicações de Alto Risco, o desenvolvedor adiciona 1 ponto para o paradigma Relacional e -1 ponto para o paradigma NoSQL, do contrário marcando a opção 2 denominada Público Geral, o desenvolvedor estará adicionando um ponto para ambos os paradigmas, pois para aplicações de baixo risco, a integridade de dados não é um fator limitante. Podemos observar como é realizado esta distribuição de pontos na tabela8, bem como é realizado esta tomada de decisão no pseudocódigo4.5.

(36)

1 2 -1

2 1 1

1 SE ( RESPOSTA_6 == MUITO BAIXO OU RESPOSTA_6 == BAIXO OU RESPOSTA_6 == MEDIO OU REPOSTA_6 == ALTO) {

SE ( RESPOSTA_5 == AMBIENTE CORPORATIVO ) {

3 SQL = SQL + 1 ; }SENAO{

7 }

}SE SENAO ( RESPOSTA_6 == MUITO ALTO) {

A sexta questão foi desenvolvida para medir o grau de disponibilidade que o desenvol-vedor considera ideal para a sua aplicação, por ser desenvolvido justamente com a promessa de alta disponibilidade, alta escalabilidade entre outras vantagens, os SGBDs que implementam o paradigma NoSQL levam grande vantagem sobre o paradigma Relacional quando se trata da característica disponibilidade, ao optar por uma dessas características: “muito baixo”, “baixo”, “médio” e “alto”, o algoritmo testa se a resposta da questão 5 está definida como ambiente corpo-rativo, para este senário o paradigma relacional ganha 1 ponto, do contrário ambos os paradigmas recebem 1 ponto, porém se a resposta for “muito alto” apenas o paradigma NoSQL pontua pois para se atingir disponibilidades tidas como muito altas os SGBDs tem que abrir mão de características como a integridade de dados, o que é quase impossível no paradigma Relacional devido a regras de implementações muito rígidas, estas pontuações podem ser observadas na tabela9bem como no pseudocódigo4.6.

Muito Baixo 1 0 Baixo 1 0 Médio 1 1 Alto 1 1 Muito Alto 0 1 Fonte: O Autor (2019)

(37)

SE ( RESPOSTA_7 == IRRELEVANTE OU RESPOSTA_7 == BAIXA RELEVANCIA OU RESPOSTA_7 == INDIFERENTE OU RESPOSTA_7 == RELEVANTE) {

2 SE ( RESPOSTA_1 == NAO OU RESPOSTA_5 == AMBIENTE CORPORATIVO ) { SQL = SQL + 1 ;

4 }SENAO{

SQL = SQL + 1 ;

8 }SE SENAO ( RESPOSTA_7 == MUITO RELEVANTE) { NOSQL = NOSQL + 1 ;

10 }

A sétima e última questão avalia a demanda por velocidade de leitura e escrita da aplicação, para gerar a pontuação o algoritmo leva em consideração não só a alternativa esco-lhida mas também algumas respostas anteriores das questões 1-Os usuários de sua aplicação irão sempre armazenam e consultar dados em seu banco de dados ? e 5-Que descrição de público melhor define sua aplicação ?, conforme mostra a tabela10e o Pseudocódigo 4.7, podemos observar que a pontuação é análoga a questão anterior ou seja para os quesitos “Irrele-vante” e “Baixa Relevância” apenas o paradigma relacional recebe 1 ponto, para as alternativas “Indiferente” e “Relevante” ambos os paradigma pontuam e para a alternativa “Muito Relevante”

o paradigma NoSQL recebe 1 ponto.

Irrelevante 1 0 Baixa Relevância 1 0 Indiferente 1 1 Relevante 1 1 Muito Relevante 0 1 Fonte: O Autor (2019)

Para avaliar qual paradigma o algoritmo deve indicar, é realizado uma comparação entre as pontuações que cada paradigma obteve ao longo das 7 perguntas contidas no formulário, como podemos observar no pseudocódigo4.8, o algoritmo testa que paradigma de banco de dados terminou com maior pontuação, a partir desta definição o algoritmo apresenta para o desenvolvedor que paradigma é o ideal, em conjunto com a recomendação apresenta todos os 7 motivos pelos quais o levaram a definir o tipo de paradigma escolhido, em algumas situações pode ser apresentado motivos que não condizem com o paradigma indicado, porém isso nada influência no resultado final, pois somente o paradigma que obtêm a maior pontuação é o paradigma ideal para a aplicação.

(38)

Capítulo 4. Desenvolvimento da Pesquisa 37 SE ( SQL > NOSQL) { 2 ESCREVA (" Sua a p l i c a c a o d e v e r a i m p l e m e n t a r um SGBD de p a r a d i g m a R e l a c i o n a l . ") ; } 4 SE SENAO ( SQL == NOSQL) {

ESCREVA (" Sua a p l i c a c a o p o d e i m p l e m e n t a r ambos o s p a r a d i g m a s de b a n c o de d a d o s , p a r a e s c o l h e r um SGBD l e v e em c o n s i d e r a c a o o s m o t i v o s que f o r a m r e t o r n a d o s p e l o a l g o r i t m o . ") ;

6 }

SENAO {

8 ESCREVA (" Sua a p l i c a c a o d e v e r a i m p l e m e n t a r um SGBD de p a r a d i g m a NoSQL

. ") ; }

Listing 4.8 – Pseudocódigo da verificação de pontuação

4.3 Aplicação do Formulário

Para coletarmos informações necessárias para se validar o algoritmo de recomendação bem como para que realmente tivéssemos informações coesas sobre os principais aspectos que os usuários levam em consideração no momento de escolha de um Paradigma de banco de dados em consequente o SGBD, aplicamos um formulário em desenvolvedores de software de diferente níveis de escolaridade, a pesquisa abrangeu de colegas do curso de graduação em Sistemas de Informação (BSI) a desenvolvedores experientes que trabalham em grandes multinacionais da área de Tecnologia da Informação (TI), ambos cientes do uso das informações ali captadas. Ao iniciar o formulário cada desenvolvedor declarou estar ciente que as informações ali obtidas seriam usadas no presente trabalho.

As perguntas descritas a seguir compõem o formulário da pesquisa, para facilitar o entendimento das perguntas por parte dos desenvolvedores, separamos o formulário por seções e cada seção abrange uma característica encontrada nos paradigmas de bancos de dados estudados.

Perguntas sobre Escalabilidade:

1. Os usuários de sua aplicação irão sempre armazenam e consultar dados em seu banco de dados ?

2. Considerando a quantidade máxima de usuários que sua aplicação poderá alcançar, sendo irrelevante menor que 100 e muito grande maior que 100.000, marque a opção que mais se aproxima de sua realidade.

Perguntas sobre Consistência de dados e tolerância a falhas

1. Sua aplicação foi desenvolvida levando em consideração a tolerância a falhas e a inconsistência de dados ?

(39)

2. Quão relevante é para a sua aplicação a garantia de uma alta consistência nos dados.

Pergunta sobre Esquema de Dados

1. Que descrição a seguir de público melhor define sua aplicação ?

Pergunta sobre Disponibilidade

1. Qual o nível de disponibilidade ideal para sua aplicação ?

Pergunta sobre Gerenciamento de transações e controle de concorrência

1. Quão relevante é para a sua aplicação uma alta performance na leitura e escrita no banco de dados.

Dentre os vários quesitos avaliados no Formulário, o nível de escolaridade nos mostra uma quase igualdade entre as escolaridades sendo o nível superior completo com a maior quantidade de participantes, como podemos ver na Figura6.

Figura 6 – Nível de Escolaridade

Alguns autores afirmam que um dos motivos pelos quais o desenvolvedor é levado a implementar um certo paradigma, é o não conhecimento de outros paradigmas, para medirmos o grau de conhecimento dos participantes com relação ao paradigma NoSQL questionamos se os mesmos conheciam o paradigma, como podemos observar na Figura7, apenas 8% afirmou que não conhece o paradigma de banco de dados NoSQL, e dentre todos os resultados que apresenta-ram divergência entre o paradigma recomendado e o implementado, todos os desenvolvedores afirmaram que conheciam o paradigma NoSQL, tendo ciência desta informação podemos afirmar que muitas vezes não é por não conhecer o paradigma que o desenvolvedor acaba não escolhendo o paradigma mais adequado a sua aplicação.

(40)

Figura 7 – Porcentagem de desenvolvedores que conhecem o paradigma NoSQL

Questionamos ao desenvolvedor no formulário sobre qual banco de dados o mesmo já utilizou em uma de suas aplicações, com isso observamos uma grande variedade de SGBDs implementados, como mostra a figura8, em conjunto com esta questão informamos ao desenvol-vedor que as demais perguntas deveriam ser respondidas levando em consideração apenas uma aplicação desenvolvida de preferência a que seu SGBD foi informado na pergunta anterior.

Figura 8 – SGBDs Implementados

(41)

gra-Capítulo 4. Desenvolvimento da Pesquisa 40

dativamente SGBDs que implementam o paradigma NoSQL vem tomando fôlego, o SGBD MySQL dominou a pesquisa com 36% seguido de outros SGBDs relacionais, os SGBDs que implementam o paradigma NoSQl somam cerca de 19% dos SGBDs implementados na pesquisa.

4.4 Validação do Algoritmo de Recomendação

Para validarmos o algoritmo de recomendação utilizamos os dados coletados no for-mulário e aplicamos no mesmo, ao analisarmos os dados retornados por parte do algoritmo podemos identificar algumas divergências entre o paradigma de banco de dados implementado pelo desenvolvedor e o paradigma recomendado pelo algoritmo como mostra a figura9.

Figura 9 – Divergência entre paradigma implementado e paradigma recomendado

Para 25% dos SGBDs informados o algoritmo apresentou divergência ou seja o para-digma implementado foi diferente do parapara-digma que o algoritmo recomendou, em alguns casos o paradigma utilizado era o Relacional e o algoritmo recomendou o NoSQL, em outros casos foi ao contrário sendo recomendado um banco de dados de paradigma Relacional para uma aplicação que havia sido implementado um SGBD de paradigma NoSQL, a figura10nos apresenta quanto dos 25% de divergência foram de Relacional para NoSQL e NoSQL para Relacional, podemos observar que 56% das aplicações onde ocorreu divergência foram implementadas com SGBDs de paradigma Relacional e o algoritmo recomendou um SGBD com o paradigma NoSQL e 44% ocorreu o inverso.

Estão expostos na tabela 11, todos os casos aqui estudados bem como a pontuação que cada paradigma atingiu, esta pontuação exposta é a pontuação que o algoritmo utiliza para recomendar o algoritmo ideal, destacamos de negrito todos os casos que apresentaram

(42)

Figura 10 – Recomendação de Paradigma Divergentes

divergência onde o algoritmo recomendado foi diferente do escolhido por parte do desenvolvedor, obtivemos apenas um caso em que o algoritmo recomendou ambos os paradigmas destacado de vermelho, onde o desenvolvedor poderia optar por ambos os paradigmas.

Podemos destacar como exemplo o caso do desenvolvedor 1, onde a pontuação do paradigma Relacional chegou a 8 pontos e o paradigma NoSQL recebeu apenas 1 ponto, o algoritmo recomendou a implementação do paradigma Relacional, paradigma este que já era utilizado na aplicação, para chegar a esta pontuação o algoritmo levou em consideração fatores como a baixa quantidade de usuários que a aplicação irá alcançar, o fato que os usuários não irão sempre salvar e armazenar dados em sua aplicação e por ter um público de utilização da aplicação denominado de ambientes corporativos ou aplicações de alto risco. Sempre seguindo este mesmo princípio o algoritmo recomenda o paradigma levando em consideração cada característica informada.

(43)

Tabela 11 – Pontuação e Recomendações

Dev Paradigma Implemen-tado Paradigma Recomen-dado Pontuação Relacional Pontuação NoSQL

Dev 1 Relacional Relacional 8 1 Dev 2 Relacional Relacional 7 1 Dev 3 Relacional Relacional 8 4

Dev 4 NoSQL NoSQL 5 7

Dev 5 Relacional Relacional 6 5 Dev 6 Relacional Relacional 6 4 Dev 7 Relacional Relacional 6 5 Dev 8 Relacional Relacional 8 4

Dev 9 NoSQL Relacional

NoSQL

5 5

Dev 10 Relacional NoSQL 4 5

Dev 11 Relacional Relacional 8 2 Dev 12 Relacional Relacional 6 5 Dev 13 Relacional Relacional 6 2 Dev 14 Relacional Relacional 6 3 Dev 15 Relacional Relacional 6 5

Dev 16 NoSQL Relacional 7 2

Dev 18 Relacional Relacional 6 2

Dev 27 NoSQL NoSQL 4 5

Dev 34 Relacional NosQL 5 7

Dev 35 Relacional Relacional 7 1