DIFERENÇAS NO DESENVOLVIMENTO DE APLICAÇÕES WEB COM BDTRADICIONAL E BD NOSQL MONGODB

Nicolas Ignacio RYBERG 1. 2 ; Angelo Augusto FROZZA3; Daniel de Andrade VARELA3

Identificação autores: 1Bolsista PIBIC-EM/CNPq; 2Curso Téc. em Informática; 3Professor IFC-Camboriú.

ResumoEste trabalho busca fazer uma introdução aos bancos de dados (BDs)

NoSQL, apresentando os principais conceitos e características desse novoparadigma. Para demonstrar as diferenças no uso de diferentes paradigmas deBDs, foram desenvolvidas duas versões de uma aplicação web na arquiteturacliente-servidor: uma utilizando BD Relacional e outra usando BD NoSQL.

1. IntroduçãoDurante décadas, foram usados bancos de dados (BDs) relacionais

para armazenar dados estruturados. Porém, com o avanço da Internet, tem-sequantidades de dados nunca antes trabalhadas (Big Data), além destesestarem cada vez menos estruturados. São exemplos, os dados contidos emsites como Facebook, Google e Amazon. Estas empresas buscaram meioseficientes e baratos para processar seus dados. A solução encontrada foi aescalabilidade horizontal, que significa aumentar o número de máquinas, aoinvés de aumentar o poder de processamento de uma máquina (escalabilidadevertical). Os BDs NoSQL chegaram como solução para este problema, já quepermitem o gerenciamento em larga escala de dados distribuídos. Entre suascaracterísticas, destacam-se: não-relacional, distribuído, de código aberto,escalável horizontalmente, ausência de esquema ou esquema flexível, suporteà replicação nativo e acesso via APIs simples. Alguns conceitos relevantes:● Modelo de Dados: é como se percebem e se manipulam os dados

(SALADAGE; FOWLER, 2013). Informalmente, entende-se como omodelo de dados de um aplicativo. Neste artigo, refere-se à forma que oSistema Gerenciador de Banco de Dados (SGBD) organiza seus dados.

● Modelo Relacional: é o modelo de dados padrão dos BDs relacionais.Representa um conjunto de tabelas relacionadas por colunas emcomum. Cada tabela possui linhas e colunas, sendo cada linha umaentidade de interesse e as colunas são os atributos desta entidade. Amenor unidade de informação armazenada é a tupla (registro).

● Paradigmas NoSQL: BDs NoSQL se diferenciam de acordo com seuparadigma, sendo os principais: Orientado a documentos (BDOD),Armazém Chave-Valor (key-value), Orientado a colunas, Orientado agrafos. Uma característica comum entre estes paradigmas é que elespodem manipular dados agregados.

● Modelo Orientado a Agregados: é um modelo de dados paraestruturas mais complexas. Agregado é um tipo de registro complexo,com listas e outras estruturas de dados aninhadas, e leva emconsideração como os dados são acessados. Um Agregado é umconjunto de objetos relacionados que se deseja tratar como umaunidade (SALADAGE; FOWLER, 2013).

● BDs Orientado a Documentos (BDOD): Documentos são coleções deatributos e valores armazenados em formatos como JSON, XML ouPDF. Este tipo de BD é considerado como o flexível, poderoso e popularentre todos os NoSQL (MCCREARY; KELLY, 2014). Um Documentoimplica em como os dados estão estruturados e devem serapresentados, tornando-o altamente eficiente para o armazenamento dedados semiestruturados. Documentos diferentes de uma mesma coleçãopodem ter diferentes números de campos ou propriedades (PEREIRA,2014), além de permitir que um documento seja embutido em outro. Osprincipais BDs nessa categoria são o MongoDB e o CouchDB.

● MongoDB: É um dos principais BDs NoSQL orientado a documentos.Nele, os documentos são serializados no formato JSON (JavaScriptObject Notation) (Figura 1) e são armazenados fisicamente em BSON(codificação binária do JSON). Os documentos são agrupados emcoleções, em conformidade com a sua estrutura (PEREIRA, 2014).Documentos com diferentes estruturas também podem ser armazenadosna mesma coleção (BERNARDINO; ABRAMAHOVA, 2013).

Figura 1 - Exemplo de documento JSON

(Fonte: elaborado pelo autor, 2016)

O objetivo deste trabalho é adquirir domínio sobre os conceitos de BDsNoSQL e desenvolver material para introduzir esse tipo de BDs nos cursos doIFC-Camboriú, além de identificar linhas de pesquisa ligadas à BDs NoSQL.

2. Material e métodos Este projeto tem caráter bibliográfico e exploratório, pelo qual se

propõe fazer um estudo sobre a tecnologia de BD chamada NoSQL. Paraatingir os objetivos propostos, primeiro foram feitas pesquisas para entender osconceitos relacionados aos BDs NoSQL, seus diferentes paradigmas e quedados são tratados em cada paradigma. Identificar em que caso um BD NoSQLé melhor que um BD relacional, apresentar os principais produtos (nomes) debanco de dados NoSQL existentes, classificando-os de acordo com oparadigma suportado e apresentar as características de cada BD NoSQLidentificado durante a pesquisa.

Com os resultados da pesquisa, foi desenvolvida uma Wiki, acessívelem: http://www.geati.ifc-camboriu.edu.br/wiki/index.php/NoSQL (GEATI, 2016).Para melhor entendimento do funcionamento de um BD NoSQL em relação aum BD relacional, foram feitos dois sites cliente-servidor, com a mesmaestrutura do lado do cliente, diferindo no lado servidor. O primeiro usa osSGBDs relacionais MySQL e PostgreSQL, e o segundo, usa o BD NoSQLMongoDB. Com os resultados obtidos foi feita uma análise sobre odesenvolvimento dos dois sistemas. Por fim, as diferenças na implementaçãodos dois sistemas foram discutidas como resultados finais deste trabalho.

3. Resultados e discussãoAplicação proposta serve para era entender as diferenças de

modelagem e manipulação de diferentes BDs. Para tanto, foi desenvolvido umsistema de loja virtual, no qual o cliente se autentica através de um login paraacessar a aplicação. O cadastro e exclusão de usuário é feito por ele próprio napágina inicial. Uma vez autenticado na loja, o usuário adiciona itens ao carrinhode compras, visualiza os itens do carrinho, remove itens do carrinho, finaliza acompra e visualiza a nota fiscal. A aplicação não possui nenhuma estilizaçãode layout, uma vez que o foco do trabalho não é o desenvolvimento web, massim, entender as diferenças no acesso aos dados em BD. Porém, essalimitação não interfere no funcionamento do site ou nos resultados.

Para uma comparação mais precisa, o desenvolvimento da aplicaçãofoi separado em dois níveis, cliente e servidor, sendo que o lado cliente éexatamente igual para as duas aplicações. Para tal, foi usado o conceito deprogramação AJAX, pelo qual separa-se completamente os lados cliente eservidor e, desde que o cliente receba a mesma resposta do servidor,independe o que aconteça neste último.

Para a aplicação server side usando BD relacional, a criação do BD sedeu através de queries ‘CREATE TABLE’ com os respectivos Primary keys eForeign Keys. Os dados da tabela Produto, necessários antes de colocar o siteem funcionamento, foram inseridos através de queries ‘INSERT’. A conexãocom o BD foi feita através de um include do documento “_database.php”,sempre que a página PHP fosse executar qualquer tipo de query. O fragmentode código a seguir é usado para a conexão com o BD MySQL:

<?php $pdo = new PDO('mysql:host=localhost; dbname=relacional','root','',[]);

Para demonstrar o uso de todos os tipos de querys, foram criadasopções de inserir, selecionar, excluir e atualizar. Como exemplo, a seguir sãoapresentados fragmentos do código das páginas que tinham essas operações:● Cadastrar usuário:

$stmt = $pdo->prepare('INSERT INTO cliente(nome, login, senha, cpf, rg, data_nascimento) VALUES(?, ?, ?, ?, ?, ?)');

$result = $stmt→execute([$_POST['nome'],$_POST['login'],$_POST['senha'], POST['cpf'], POST['rg'],POST['data_nascimento']]);

● Verificar Login:$stmt=$pdo->prepare("SELECT * FROM cliente WHERE login=? and

senha=?"); $stmt->execute([$login,$senha]);$result = $stmt->fetchAll (PDO::FETCH_ASSOC);

● Excluir usuário:$stmt = $pdo->prepare("DELETE FROM cliente WHERE login = ? and

senha = ?"); $result = $stmt→execute([$login,$senha]);

● Alterar senha: $stmt=$pdo->prepare("UPDATE cliente SET senha=? WHERE login=?

and senha=?"); $stmt->execute([$novaSenha, $login, $senha]); $result = $stmt->fetchAll(PDO::FETCH_ASSOC);

Para a aplicação server side usando o BD MongoDB, a criação dobanco de dados é dinâmica, através do método insertOne(), pelo qual osrelacionamentos ocorrem ao inserir um objeto dentro de outro. Os objetos sãomanipulados através dos métodos: update(), find() e delete() (MONGODB,2016). Os dados da tabela Produto, foram inseridos diretamente no SGBD pelomesmo método insert(). O fragmento de código a seguir é usado para aconexão com o MongoDB e, em seguida, são apresentados os fragmentos decódigo para manipulação de dados.

require 'vendor/autoload.php';$mongo = newMongoDB\Client("mongodb://localhost:27017");

● Cadastrar usuário:$colecaoCliente = $mongo->db->cliente; $dadosCadastro =['nome_cliente'=>$_POST['nome'],'login'=>$_POST

['login'],'senha'=>$_POST['senha'],'cpf'=>$_POST['cpf'],'rg' =>$_POST['rg'],'data_nascimento'=>$_POST['data_nascimento']];

$colecaoCliente->insertOne($dadosCadastro);

● Verificar Login:$colecaoCliente = $mongo->db->cliente;$dadosLogin = ['login' => $login, 'senha'=> $senha];$cliente=$colecaoCliente>findOne($dadosLogin);

● Excluir usuário:$cliente = $mongo→db→cliente;$dadosDel = ['login' => $login, 'senha'=> $senha];$result = $cliente->deleteOne($dadosDel);

● Alterar senha: $cliente = $mongo->db->cliente;$dadosCliente = ['login' => $login,'senha'=> $senha];$result = $cliente->updateOne($dadosCliente,['$set' => ["senha"

=> $novaSenha]]);

A aplicação tem operações que exigiram queries com relacionamentosatravés de Foreign Keys, no caso da aplicação com BD relacional e dainserção e seleção de objetos aninhados através do objectID, porém, pelo

espaço limitado do artigo, foi procurado apresentar aqui as queries elementaresde CRUD (Create, Read, Update e Delete). Mais detalhes da aplicação podemser encontrados na Wiki do projeto.

4. Conclusão Não houve diferença na implementação da aplicação client side com os

dois modelos de BD, até foram usados os mesmos arquivos HTML. Isto se deugraças a aplicação cliente side ser AJAX e a aplicação server side retornar asinformações em formato de documento JSON ao cliente. No que diz respeito aaplicação server side, o código inteiro teve que ser reescrito, podendo-sereutilizar apenas pequenas partes que não tinham relação com o BD emecanismos de sessão.

A conexão ao banco em ambos os casos foi semelhante, já que foiusado o PDO do PHP, diferindo apenas na estrutura do objeto instanciado. Asdiferenças sobre como os dados são armazenados foram as mais perceptíveis.Na aplicação MongoDB, os objetos são inseridos por métodos insert(), porserem armazenados na mesma estrutura em que eram implementados. Já naaplicação MySQL (relacional), foram necessários diversos métodos do objetoPDO para poder inserir os dados na tabela, comprovando as diferençasestudadas sobre os modelos até então. Não foi foco desse trabalho avaliarperformance. Porém, teoricamente, um BD NoSQL seria mais eficiente parauma aplicação deste tipo e porte, por não exigir muitas consultas eatualizações, tendo como vantagem, o armazenando os objetos praticamenteda forma como foram implementados. Por nunca ter entrado em contato com atecnologia NoSQL e, nos três anos de curso ser apresentado apenas o modeloRelacional, inicialmente houve dificuldade para desenvolver o projeto. Porém,com o tempo ficou até mais fácil, por não existir uma diferença tão grande entreimplementação e armazenamento, facilitando a visualização do todo.

Este projeto de pesquisa recebeu apoio do IFC, através do Edital No

504/2014 PIBIC-EM.

Referências BERNARDINO, J.; ABRAMAHOVA, V. NoSQL databases: MongoDB vs Cassandra. In: Proceedings of the International C* Conference. ACM, 2013.GEATI. NoSQL. In: Wiki do GEATI. Disponível em: <http://www.geati.ifc-camboriu.edu.br/wiki/index.php/NoSQL>. Acessado em: 31 jul. 2016.MCCREARY, D. G.; KELLY, A. M. Making Sense of NoSQL: A guide for managers and the rest of us. Manning, 2014. 312 p.MONGODB. Site oficial. Disponível em: <https://mongodb.com/>. Acessado em: 25 jul. 2016.PEREIRA, D. J. P. Armazéns de dados em bases de dados NoSQL. 2014. 178 f. Dissertação (Mestrado em Engenharia Informática) – ISEP, Porto.SALADAGE, P. J; FOWLER, M. NOSQL Essencial: Um guia conciso para o mundo emergente de persistência poliglota. São Paulo: Pearson , 2013. 220 p.