DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CRISTOFER ZDEPSKI
PDDM: UM MÉTODO DE PROJETO DE BANCOS DE DADOS
APLICADO À PERSISTÊNCIA POLIGLOTA
DISSERTAÇÃO
PONTA GROSSA 2019
PDDM: UM MÉTODO DE PROJETO DE BANCOS DE DADOS
APLICADO À PERSISTÊNCIA POLIGLOTA
Dissertação apresentado ao programa de Pós-Graduação em Ciência da Computação da Universidade Tecnológica Federal do Paraná -Campus Ponta Grossa. Área de Concentração: Sistemas e Métodos de Computação
Orientadora: Prof. Dra. Simone Nasser Matos Co-orientador: Prof. Dr. Tarcizio Alexandre Bini
PONTA GROSSA 2019
Ficha catalográfica elaborada pelo Departamento de Biblioteca
da Universidade Tecnológica Federal do Paraná, Campus Ponta Grossa n.80/19
Elson Heraldo Ribeiro Junior. CRB-9/1413. 20/12/2019. Z39 Zdepski, Cristofer
PDDM: um método de projeto de bancos de dados aplicado à persistência poliglota. / Cristofer Zdepski, 2019.
88 f. : il. ; 30 cm.
Orientadora: Prof. Dra. Simone Nasser Matos Co-orientador: Prof. Dr. Tarcizio Alexandre Bini
Dissertação (Mestrado em Ciência da Computação) - Programa de Pós-Graduação em Ciência da Computação. Universidade Tecnológica Federal do Paraná, Ponta Grossa, 2019.
1. Banco de dados não relacionais. 2. Armazenamento de dados. 3. Projeto lógico digital. 4. Computação. I. Matos, Simone Nasser. II. Bini, Tarcizio Alexandre. III. Universidade Tecnológica Federaldo Paraná. IV. Título.
Ministério da Educação
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CÂMPUS PONTA GROSSA Diretoria de Pesquisa e Pós-Graduação
Programa de Pós-Graduação em Ciência da Computação
FOLHA DE APROVAÇÃO
Título de Dissertação Nº 17/2019
PDDM: Um método de projeto de bancos de dados aplicado à persistência poliglota
Por Cristofer Zdepski
Esta dissertação foi apresentada às 14 horas de 26 de novembro de 2019, na sala da
DIRPPG, como requisito parcial para a obtenção do título de MESTRE EM CIÊNCIA DA
COMPUTAÇÃO, Programa de Pós-Graduação em Ciência da Computação. O candidato foi arguido pela Banca Examinadora, composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho APROVADO.
Prof. Dr. Simone de Almeida (UTFPR) Prof. Dr. Marcos Sfair Sunye (UFPR)
Prof. Dr. Tarcizio Alexandre Bini (UTFPR)
Co-orientador e presidente da banca
Visto do Coordenador:
Prof. Dr. André Koscianski Coordenador do PPGCC UTFPR – Câmpus Ponta Grossa
- A FOLHA DE APROVAÇÃO ASSINADA ENCONTRA-SE ARQUIVADA NA SECRETARIA ACADÊMICA -
ZDEPSKI, Cristofer. PDDM: Um método de projeto de bancos de dados aplicado à persistência poliglota. 2019. 88 f. Dissertação (Mestrado em Ciência da Computação) -Universidade Tecnológica Federal do Paraná Ponta Grossa, 2019.
Nos últimos anos, o crescimento das bases de dados impulsionado pelas aplicações Web 2.0 evidenciou limitações do modelo relacional quando se trata de escalabilidade. Isso fez com que surgissem os bancos de dados NoSQL, com modelos de armazenamento de dados diferentes do relacional. Esses bancos de dados propõem soluções para tais limitações por meio da escala-bilidade horizontal e comprometem parcialmente a consistência dos dados. A combinação de diversos modelos de dados, chamada de persistência poliglota, amplia essas soluções provendo recursos para a implementação de sistemas complexos, que possuem componentes com requi-sitos distintos e que não seriam possíveis de ser implementados pelo emprego de apenas um modelo de dados de forma satisfatória. No entanto, não existem métodos consolidados para o projeto de banco de dados NoSQL, tão pouco para o desenvolvimento de sistemas que fazem uso da persistência poliglota. Este trabalho propõe um método de projeto de banco de dados aplicado à sistemas que utilizem persistência poliglota, pela combinação de diferentes modelos de dados. Este método pode ser aplicado ao modelo relacional e aos modelos de dados NoSQL orientados à agregados. O método proposto define um conjunto de sub-etapas pautadas nos con-ceitos já existentes de projeto de banco de dados. O objetivo é definir um processo formal para auxiliar na definição dos modelos de dados a serem utilizados e transformar o projeto conceitual em projeto lógico. Ao final, é demonstrada a aplicação do método em 3 casos de teste, visando demonstrar seus resultados e sua aplicabilidade para posterior execução do projeto físico das bases de dados.
ZDEPSKI, Cristofer. PDDM: A database design method applied to polyglot persistence. 2019. 88 p. Dissertation (Master in Computer Science) Federal University of Technology -Paraná. Ponta Grossa, 2019.
In recent years, the growth of databases by Web 2.0 applications has revealed the limitations of the relational model related to scalability. This led to the emergence of NoSQL databases, with data storage models other than relational ones. These databases propose solutions to such limita-tions through horizontal scalability and partially compromise data consistency. The combination of multiple data models, called polyglot persistence, extends these solutions by providing resour-ces for the implementation of complex systems that have components with distinct requirements that would not be possible by the use of only one data model in a satisfactory way. However, there are no consolidated methods for the NoSQL database design and neither methods for de-sign systems that apply the polyglot persistence. This work proposes a database dede-sign method applied to systems that use polyglot persistence, combining different data models. This method can be applied to the relational model and aggregate-oriented NoSQL data models. The propo-sed method defines a set of sub-steps bapropo-sed on the existing concepts of database design. The goal is to define a formal process to assist in defining the data models to be used and to transform the conceptual design into a logical design. At the end, the method application are demonstrated in 3 test cases, in order to demonstrate its results and its applicability for later execution of the physical design of these databases.
Figura 1 – Exemplo de utilização do Modelo Entidade-Relacionamento (MER) . . . 15
Figura 2 – Exemplo de dados em um repositório chave-valor . . . 19
Figura 3 – Exemplo de documento no MongoDB . . . 20
Figura 4 – Exemplo de Família de Colunas . . . 21
Figura 5 – Estrutura de um e-commerce . . . 24
Figura 6 – Exemplo de agregado . . . 26
Figura 7 – String de busca nas bases de dados . . . 31
Figura 8 – Contribuição das bases de dados . . . 32
Figura 9 – Visão geral do método desenvolvido . . . 43
Figura 10 – Fluxo de etapas para a aplicação do PDDM . . . 44
Figura 11 – Projeto conceitual de exemplo . . . 45
Figura 12 – Exemplo da segmentação de funcionalidades . . . 46
Figura 13 – Exemplo da utilização de réplicas para a segmentação . . . 47
Figura 14 – Fluxo de seleção do modelo de dados. . . 49
Figura 15 – Metamodelo para a definição do modelo de agregados . . . 50
Figura 16 – Exemplo de relacionamento de agregação . . . 51
Figura 17 – Exemplo de relacionamento de composição . . . 52
Figura 18 – Regra de conversão R1 do PDDM . . . 52
Figura 19 – Regra de conversão R2 do PDDM . . . 53
Figura 20 – Regra de conversão R2 do PDDM para auto-relacionamento . . . 53
Figura 21 – Regra de conversão R3 do PDDM . . . 54
Figura 22 – Regra de conversão R4 do PDDM . . . 54
Figura 23 – Regra de conversão R5 do PDDM . . . 54
Figura 24 – Regra de conversão R6 do PDDM . . . 55
Figura 25 – Regra de conversão R7 do PDDM . . . 55
Figura 26 – Representação do Carrinho de Compras como agregado . . . 56
Figura 27 – Comandos para a definição e extração dos dados no Redis . . . 57
Figura 28 – Comandos para a inserção e extração no MongoDB . . . 58
Figura 29 – Comandos CQL para a criação e consulta no Cassandra . . . 59
Figura 30 – Comandos CQL para a criação e consulta no Cassandra utilizando tuple . . 60
Figura 31 – MER Proposto para o Caso de Teste 1 . . . 62
Figura 32 – MER segmentado com o Controle de Cursos . . . 62
Figura 33 – Regras de conversão do PDDM aplicadas ao Controle de Cursos . . . 63
Figura 34 – Criação das famílias de colunas para o Controle de Cursos . . . 64
Figura 35 – MER proposto para o Controle de Disciplinas . . . 64
Figura 36 – PDDM aplicado ao Controle de Disciplinas . . . 65
Figura 37 – Exemplo de dados para o Controle de Disciplinas . . . 66
Figura 38 – Comandos no MongoDB para a inserção do Controle de Disciplinas . . . 67
Figura 39 – MER adaptado do caso de teste 2 . . . 68
Figura 40 – PDDM aplicado ao Controle de Pedidos . . . 69
Figura 41 – Exemplo de dados para o Controle de Pedidos . . . 69
Figura 42 – Comandos para a inserção de dados do Controle de Pedidos no Redis . . . 70
Figura 43 – MER segmentado para o Controle de Estoque . . . 70
Figura 44 – PDDM aplicado ao Controle de Estoque . . . 70
Figura 45 – Exemplo de dados para o Controle de Estoque . . . 71
Figura 49 – Criação de estruturas do Controle de Laboratório no Cassandra . . . 73
Figura 50 – MER completo para o sistema de e-commerce . . . 74
Figura 51 – MER segmentado para o Controle de Usuários . . . 75
Figura 52 – PDDM aplicado ao Controle de Usuários . . . 75
Figura 53 – Agregados do Controle de Usuários criados para a utilização no Redis . . . . 76
Figura 54 – Exemplo de criação de agregado no Redis . . . 76
Figura 55 – MER segmentado para o Controle de Produtos . . . 77
Figura 56 – PDDM aplicado ao Controle de Produtos . . . 77
Figura 57 – Comandos em CQL para a criação do Controle de Produtos no Cassandra 78 Figura 58 – MER segmentado para o Controle de pedidos . . . 78
Figura 59 – PDDM aplicado ao Controle de Pedidos . . . 79
Figura 60 – Conjunto de dados de exemplo para o Controle de Pedidos . . . 80
∑︀Ci Número de Citações.
ACID Atomic, Consistent, Isolated, Durable.
BASE Basically Available, Soft State, Eventually Consistent. BSON Binary JavaScript Object Notation.
CQL Cassandra Query Language. DDD Domain-Driven Design. DDL Data Definition Language. IF Impact Factor.
Io InOrdinatio.
JCR Journal Citation Reports. JSON JavaScript Object Notation. MER Modelo Entidade-Relacionamento. NoAM NoSQL Abstract Model.
NoSE NoSQL Schema Evaluator. NoSQL Not-Only SQL.
PDDM Polyglot Database Design Method. Py Publication Year.
QP Questões de Pesquisa. Ry Research Year.
SGBD Sistemas de Gerenciamento de Banco de Dados. SJR SCImago Journal Rank.
SNIP Source Normalized Impact per Paper. SoS Save our Systems.
SQL Structured Query Language. UML Unified Modeling Language. XML Extensible Markup Language.
1 INTRODUÇÃO . . . 10 1.1 JUSTIFICATIVA . . . 11 1.2 OBJETIVO GERAL . . . 12 1.3 OBJETIVOS ESPECíFICOS . . . 12 1.4 ORGANIZAÇÃO DO TRABALHO. . . 13 2 REFERENCIAL TEÓRICO . . . 14
2.1 PROJETO DE BANCOS DE DADOS . . . 14
2.1.1 Projeto Conceitual . . . 15
2.1.2 Projeto Lógico . . . 16
2.1.3 Projeto Físico . . . 16
2.2 MODELOS DE DADOS NOSQL . . . 17
2.2.1 Chave-Valor . . . 18 2.2.2 Orientado a Documento . . . 20 2.2.3 Famílias de Colunas . . . 21 2.2.4 Orientado a Grafos . . . 22 2.3 PERSISTÊNCIA POLIGLOTA . . . 23 2.4 DOMAIN-DRIVEN DESIGN . . . 25 2.4.1 Agregados . . . 25 2.4.2 Repositórios. . . 27 2.5 TRANSFORMAÇÃO DE MODELOS . . . 27 2.6 CONSIDERAÇÕES DO CAPíTULO . . . 28 3 ESTADO DA ARTE. . . 29 3.1 METODOLOGIA APLICADA . . . 29
3.1.1 Definição das Intenções de Pesquisa. . . 30
3.1.2 Pesquisa Preliminar Exploratória . . . 30
3.1.3 Definição das Palavras-chave e Bases de Dados . . . 31
3.1.4 Pesquisa Definitiva nas Bases de Dados . . . 32
3.1.5 Filtragem . . . 33
3.1.6 Identificação do Fator de Impacto, Ano de Publicação e Número de Citações . . . 33
3.1.7 Ordenação dos Artigos pelo InOrdinatio . . . 34
3.1.8 Localização dos Artigos Completos . . . 35
3.1.9 Leitura Final e Análise Sistemática . . . 36
3.2 RESULTADOS . . . 36
3.2.1 QP1. Quais os Principais Autores na Área de Projeto de Bancos de Dados NoSQL? 36 3.2.2 QP2. Quais São os Casos de Aplicação Mais Comuns dos Bancos de Dados NoSQL? 36 3.2.3 QP3. Quais as Estratégias Existentes Atualmente no Projeto de Banco de Dados NoSQL? . . . 37
3.2.4 QP4. Quais Dessas Estratégias se Aplicam ou Poderiam Ser Aplicadas para a Persistência Poliglota? . . . 38
3.2.5 Ameaças a Validade . . . 39
3.3 TRABALHOS RELACIONADOS . . . 40
3.4 CONSIDERAÇÕES DO CAPíTULO . . . 41
4 MÉTODO PROPOSTO . . . 42
4.1 VISÃO GERAL DO MÉTODO . . . 42
4.2 PROJETO CONCEITUAL . . . 43
4.3.3 Projeto Lógico do Modelo de Dados . . . 49
4.3.4 Regras de Conversão dos Modelos . . . 52
4.4 PROJETO FíSICO . . . 55 4.4.1 Chave-Valor . . . 56 4.4.2 Orientado a Documento . . . 57 4.4.3 Família de Colunas . . . 58 4.5 CONSIDERAÇÕES DO CAPíTULO . . . 60 5 RESULTADOS . . . 61
5.1 APLICAÇÃO DO PDDM NO CASO DE TESTE 1 . . . 61
5.2 APLICAÇÃO DO PDDM NO CASO DE TESTE 2 . . . 66
5.3 APLICAÇÃO DO PDDM NO CASO DE TESTE 3 . . . 72
5.4 ANÁLISE DO MÉTODO . . . 80
5.5 CONSIDERAÇÕES DO CAPíTULO . . . 81
6 CONCLUSÃO . . . 82
6.1 TRABALHOS FUTUROS . . . 83
1 INTRODUÇÃO
Bases de dados são aplicadas ao contexto de sistemas organizacionais desde meados da década de 70, quando gradualmente começaram a substituir os sistemas de armazenamento baseados em arquivos. Simultaneamente, o reconhecimento da importância dos dados cresceu como parte integrante dos recursos corporativos (CONNOLLY; BEGG, 2015). Ao longo dos anos, muitos Sistemas de Gerenciamento de Banco de Dados (SGBD) surgiram e, devido à sua grande capacidade de adaptação à diversos cenários e consistência dos dados, o modelo relacional dominou o mercado se tornando o mais aplicado (ATZENI, 2016).
A popularização da Web 2.0, impulsionada pelo crescimento de plataformas interati-vas como redes sociais, blogs e gerenciadores de conteúdo, trouxe um crescimento em escalas muito maiores para as bases de dados, passando a existir na escala de petabytes, com cresci-mentos diários na escala de terabytes (CORBELLINI et al., 2016). Esse crescimento evidenciou fraquezas do modelo relacional pelas suas limitações com altos volumes de acessos ou grandes quantidades de dados, ocasionados pela sua dificuldade de distribuição em múltiplos servidores, chamada de escalabilidade horizontal (CATTELL, 2011). Outra limitação do modelo relacional está na flexibilidade dos dados. Muitas aplicações Web 2.0 trabalham com dados não estrutu-rados ou semi-estrutuestrutu-rados, como é o caso dos gerenciadores de conteúdo e das mídias sociais (BHOGAL; CHOKSI, 2015). O modelo relacional trabalha com estruturas definidas na forma de linhas e colunas, o que impõe restrições ao formato dos dados e dificulta a sua utilização em aplicações com dados não estruturados.
Visando resolver as limitações de escalabilidade e flexibilidade, novos modelos de da-dos denominada-dos Not-Only SQL (NoSQL) surgiram. O termo NoSQL é utilizado para repre-sentar bases de dados "não-relacionais", que implementam outros formatos de armazenamento e acesso aos dados (CATTELL, 2011). Muitos SGBDs NoSQL surgiram com diferentes mode-los de dados, entre eles os modemode-los chave-valor, orientados a documento, famílias de colunas e orientados a grafo, buscando a capacidade de solucionar algumas das limitações do modelo relacional.
Mesmo provendo a capacidade de solucionar algumas limitações do modelo relacional, as bases de dados NoSQL não são a proposta unificada e definitiva para o armazenamento de dados. As bases de dados NoSQL utilizam estruturas de armazenamento mais simples, o que permite uma maior flexibilidade e escalabilidade dos dados, porém possuem outras limitações quando comparadas ao modelo relacional. Em geral, elas não possuem a capacidade de elaborar consultas complexas, como junções ou agregações e praticamente todas impõem limitações à consistência dos dados. Assim como ocorre com o modelo relacional, um único modelo de dados pode não ser o suficiente para suprir as necessidades de um sistema complexo. Para contornar essas limitações, autores como Srivastava e Shekokar (2017) e Sadalage e Fowler (2012) sugerem a aplicação de múltiplos modelos de armazenamento na implementação dos sistemas, visando
utilizar as melhores características de cada um, abordagem que recebe o nome de persistência poliglota.
A persistência poliglota garante mais recursos para a solução de problemas em siste-mas complexos, com partes essencialmente distintas, como por exemplo controle de sessões, históricos de acessos e buscas em redes sociais (SADALAGE; FOWLER, 2012). Essas dife-rentes partes de um mesmo sistema muitas vezes possuem requisitos distintos e a aplicação de um único modelo de dados envolve adaptações nas estruturas de dados que podem levar a solu-ções não otimizadas. Em sistemas de larga escala, essa falta de otimização se torna ainda mais evidente, pois compromete a viabilidade do sistema.
Apesar da persistência poliglota resolver certos problemas de um sistema complexo, ela também traz novos desafios (VIRGILIO; MACCIONI; TORLONE, 2014). As diferenças entre os modelos de dados NoSQL quando comparados ao modelo relacional, trazem dificuldades no processo de integração de dados. Transformar os dados entre os modelos nem sempre é um pro-cesso simples, pois as estruturas de dados são diferentes. A persistência poliglota acrescenta ao desenvolvimento de sistemas uma complexidade que precisa ser justificada pelos ganhos pro-porcionados pela diversidade de modelos de dados.
O novo cenário de múltiplos modelos de dados provido pela persistência poliglota ainda não possui um método consolidado de projeto de banco de dados. Enquanto o modelo relacional possui diversos estudos sobre o assunto, os modelos NoSQL ainda são pouco explorados nesta área, assim como a persistência poliglota (LIMA; MELLO, ). Visando a utilização de diversos modelos de dados em um único projeto, foi concebida a ideia de se criar um método de projeto de banco de dados aplicado a persistência poliglota, incorporando os modelos NoSQL e o modelo relacional, trazendo uma visão unificada.
O método proposto, denominado Polyglot Database Design Method (PDDM), foi de-senvolvido a partir das etapas essenciais do projeto de banco de dados: Projeto Conceitual, Ló-gico e Físico. Para isso, foram criados subprocessos dentro do projeto lóLó-gico. Como resultado desta dissertação, serão apresentados essas sub-etapas e sua aplicação a 3 casos de testes, pro-vendo a capacidade de projetar um sistema que se utilize de alguns dos modelos de dados NoSQL e o modelo relacional de forma integrada.
1.1 JUSTIFICATIVA
O surgimento das bases de dados NoSQL trouxe soluções ao problema de escalona-mento, alta disponibilidade e flexibilidade necessários para as aplicações Web 2.0. Os métodos existentes de projeto de banco de dados utilizados para o modelo relacional não podem ser apli-cados à esses novos modelos de dados. Devido as estruturas das bases de dados NoSQL diferi-rem do modelo relacional, tornando a aplicação das estratégias de projeto relacional ineficientes quando aplicadas aos modelos NoSQL (VIRGILIO; MACCIONI; TORLONE, 2014).
A necessidade de métodos de projeto capazes de implementar os modelos de dados NoSQL é ressaltada por diversos autores, como Bugiotti et al. (2013), Virgilio, Maccioni e Tor-lone (2014) e Mior et al. (2017). Os bancos de dados NoSQL são implementados baseados em exemplos e guias de boas práticas, que servem apenas para um SGBD e sem metodologias sis-temáticas definidas (BUGIOTTI; CABIBBO, 2014). Várias abordagens foram criadas na busca de suprir essa deficiência, por meio de métodos de projeto de bancos de dados NoSQL porém, em sua maioria são limitados a apenas um modelo de dados, ou até mesmo a apenas um SGBD. Tratando-se de persistência poliglota, até o momento da escrita deste trabalho, não foi encon-trado nenhum método de projeto capaz de integrar múltiplos modelos.
A existência de um método de projeto capaz de tratar os modelos NoSQL traz vantagens ao desenvolvimento de softwares que o utilizem. Assim como ocorre no modelo relacional, decisões de projeto podem ter impacto significante no desempenho e escalabilidade da aplicação desenvolvida (VIRGILIO; MACCIONI; TORLONE, 2014). O projeto de banco de dados auxilia no processo de identificação de falhas estruturais antes que o desenvolvimento ocorra, quando se tornam complexos de serem solucionados.
Em um sistema que utilize persistência poliglota, a decisão sobre onde e quais mode-los de dados devem ser aplicados é parte importante do projeto de banco de dados. Por meio dessa definição é possível identificar os SGBDs mais adequados e quais atendem aos requisitos necessários. Os métodos de projeto de bancos de dados NoSQL existentes, quando permitem a implementação de múltiplos modelos de dados, não tratam da divisão em modelos de armaze-namento, não sendo aplicáveis a persistência poliglota.
1.2 OBJETIVO GERAL
O objetivo geral desta dissertação é criar um método de projeto de banco de dados apli-cável à sistemas com persistência poliglota, permitindo a utilização do modelo relacional e dos modelos NoSQL orientados a agregados de forma combinada, e que também auxilie na definição dos modelos de dados a serem utilizados. Este método deve proporcionar uma visualização geral do projeto dos diversos modelos de dados, o que permite a identificação de falhas estruturais e dos pontos de integração entre os modelos de dados.
1.3 OBJETIVOS ESPECÍFICOS
Os objetivos específicos deste trabalho são:
∙ Realizar um mapeamento sistemático sobre o tema de projeto de bancos de dados NoSQL e persistência poliglota, em busca das estratégias já adotadas e suas deficiências, que servirá como fundamentação para o desenvolvimento do método;
∙ Criar um metamodelo capaz de representar as estruturas de dados utilizadas pelas bases de dados NoSQL utilizadas;
∙ Aplicar o método em pelo menos 3 casos de testes e analisar seus resultados e possíveis pontos de melhoria.
1.4 ORGANIZAÇÃO DO TRABALHO
Esse trabalho está organizado em 5 capítulos. O Capítulo 2 apresenta o referencial teó-rico sobre os modelos de dados NoSQL, projeto de banco de dados e os conceitos do
Domain-Driven Design (DDD) utilizados para o desenvolvimento do método. O Capítulo 3 apresenta
um mapeamento sistemático com o estado da arte sobre o projeto de banco de dados NoSQL e suas aplicações para a persistência poliglota. O Capítulo 4 descreve o método proposto, ba-seado no conceito de projeto unificado capaz de integrar diversos modelos de dados e suporte à persistência poliglota. O Capítulo 5 descreve a aplicação do PDDM em três casos de teste e demonstrações do projeto físico, além de uma análise do método. Por fim, o capítulo 6 apresenta as conclusões e sugestões de trabalhos futuros.
2 REFERENCIAL TEÓRICO
O projeto de banco de dados é etapa essencial no desenvolvimento de softwares base-ados em armazenamento de dbase-ados, pois otimiza o armazenamento e extração das informações, evitando redundâncias e garantindo melhor desempenho do sistema (MIOR et al., 2017). O pro-jeto de bancos de dados exige também o conhecimento dos requisitos do sistema, buscando adesão entre o armazenamento e os requisitos definidos. Devido à importância do projeto de banco de dados para a manutenção e funcionamento dos sistemas, muitas metodologias foram desenvolvidas e aplicadas para os bancos de dados relacionais.
O modelo relacional entretanto, possui limitações para aplicações de larga escala, de-vido a dificuldade em aplicar a escalabilidade horizontal. Visando contornar essas dificuldades, foram criados os SGBDs denominados de NoSQL, que fazem uso de modelos de dados dife-rentes do relacional, permitindo escalabilidade horizontal de forma simples, provendo maior desempenho e disponibilidade do sistema (CATTELL, 2011). As bases de dados NoSQL, po-rém, ainda não possuem metodologia consolidada de projeto e o desenvolvimento de aplicações que as utilizam se baseiam em exemplos e guias de boas práticas, criados para cada SGBD e sem uma metodologia sistemática (BUGIOTTI; CABIBBO, 2014).
Os modelos de dados NoSQL são mais simples que o modelo relacional e muitos deles não possuem estruturas de restrição para os dados ou permitem consultas complexas, como junções. Essas limitações exigem que os dados sejam armazenados de forma a serem extraídos mais diretamente, sem operações complexas (LI; MA; CHEN, 2014). Isso leva o projeto de banco de dados NoSQL a ter uma relação mais próxima do desenvolvimento da aplicação que o utiliza.
Este capítulo aborda os conceitos necessários para a definição do método PDDM. A Se-ção 2.1 aborda o projeto de banco de dados, a SeSe-ção 2.2 apresenta os modelos de dados NoSQL suas características e aplicações mais comuns, a Seção 2.3 introduz o conceito de persistência poliglota e suas vantagens e dificuldades. A Seção 2.4 apresenta alguns dos conceitos do DDD utilizados para a definição do projeto lógico e a Seção 2.5 apresenta a definição do conceito de transformação de modelos utilizado para a conversão do MER no modelo criado para a repre-sentação do PDDM. Ao final, são apresentadas algumas considerações finais deste capítulo.
2.1 PROJETO DE BANCOS DE DADOS
Criar uma aplicação baseada em bancos de dados é um assunto complexo pois envolve além da modelagem do esquema de banco de dados, a modelagem das aplicações que aces-sam e alteram os dados, metodologias de segurança entre outras atividades (SILBERSCHATZ; KORTH; SUDARSHAN, 2010). Este trabalho trata apenas da definição do esquema de banco de
dados e, para isso, é importante conhecer as metodologias empregadas para esse tipo de tarefa. Autores como Silberschatz, Korth e Sudarshan (2010), Rob e Coronel (2007), Robin-son, Webber e Eifrem (2015) e Martyn (2000) possuem diferentes definições para as etapas do projeto de banco de dados, mas pode-se dizer que suas definições possuem em comum as seguin-tes fases: a) Projeto Conceitual, b) Projeto Lógico e c) Projeto Físico. Essas etapas expressam de forma geral as definições comuns para o projeto de banco de dados. Alguns autores sugerem etapas anteriores, intermediárias e posteriores como, por exemplo, a definição de requisitos do sistema, mencionada por Rob e Coronel (2007), mas são considerados processos auxiliares ao projeto de banco de dados no contexto deste trabalho. Nas próximas seções serão detalhadas as etapas consideradas um consenso entre os autores da área de projeto de banco de dados.
2.1.1 Projeto Conceitual
Partindo de uma definição dos requisitos da aplicação, é necessário traduzi-los em um esquema de banco de dados, fornecendo uma visão geral do sistema (SILBERSCHATZ; KORTH; SUDARSHAN, 2010). Essa representação é essencialmente um modelo de negó-cios e representa de forma não-técnica e em alto nível uma descrição do domínio da aplicação (MARTYN, 2000). Uma das formas de se representar esse modelo é a utilização do Modelo Entidade-Relacionamento (MER), o qual traz uma representação gráfica do esquema de dados, facilitando a visualização, a conformidade com os requisitos do sistema e identificação de ca-racterísticas redundantes (ROB; CORONEL, 2007). A representação do MER é baseada em entidades, atributos e relacionamentos. A Figura 1 representa um exemplo de MER. O projeto conceitual pode ser representado por meio de outros modelos como Unified Modeling Language (UML) e o Modelo Entidade-Relacionamento Estendido, mas como esse trabalho não se utiliza das propriedades específicas destes modelos, optou-se pela utilização do MER.
Figura 1 – Exemplo de utilização do MER
Fonte: Autoria Própria
O projeto conceitual não se baseia em um modelo específico de dados, mas na represen-tação dos requisitos do sistema. Por essa razão, pode-se dizer que é independente de tecnologia, o que não impede seu uso no projeto de banco de dados de qualquer modelo de dados, apesar de ser comumente utilizado para o projeto de bancos de dados relacionais.
2.1.2 Projeto Lógico
O projeto lógico de banco de dados visa transformar o modelo conceitual na represen-tação interna de um modelo de dados (ROB; CORONEL, 2007). Ou seja, transformar o modelo conceitual em estruturas compatíveis com o modelo de dados a ser utilizado. Quando aplicado ao modelo relacional, o projeto lógico tem o objetivo de converter as entidades, atributos e rela-cionamentos em tabelas, colunas e chaves estrangeiras, que são as estruturas de dados do modelo relacional. A transformação resultante é um modelo lógico ideal pois representa diretamente a semântica do modelo conceitual (MARTYN, 2000).
A definição do projeto lógico não se restringe apenas ao modelo relacional. Sendo o projeto conceitual independente do modelo de dados, o processo de conversão pode ser apli-cado para qualquer modelo destino, transformando as entidades e relacionamentos conforme este modelo. É necessário que nesse ponto do projeto de banco de dados exista a definição do modelo de dados a ser utilizado, seja ele o modelo relacional, algum dos modelos de dados NoSQL ou qualquer outra forma de armazenamento dos dados para que suas estruturas possam ser representadas. O projeto lógico é, portanto, dependente do modelo de dados a ser utilizado. Além da conversão do modelo conceitual para o lógico, a otimização das estruturas de armazenamento são aplicadas durante o projeto lógico, em busca de melhorar os processos de extração e armazenamento dos dados. Isso pode ser obtido pela eliminação de redundâncias desnecessárias ou mesmo por meio da definição de estruturas que facilitem a extração dos da-dos pelo sistema (SILBERSCHATZ; KORTH; SUDARSHAN, 2010). No modelo relacional, o processo de normalização garante, por meio da aplicação do conjunto de regras normais, a identificação e correção de falhas estruturais do modelo de dados.
As bases de dados NoSQL, por outro lado, trabalham com conceitos como a desnor-malização dos dados para aumentar o desempenho, mesmo que isso ocasione redundâncias. Processos como a desnormalização de dados para as bases de dados NoSQL são recomendados por guias de boas práticas de cada SGBD não havendo metodologia consolidada, o que demons-tra que ainda existem poucos estudos referentes ao projeto lógico para bases de dados NoSQL (LIMA; MELLO, ).
2.1.3 Projeto Físico
O projeto físico consiste na definição das características de armazenamento e acesso aos dados (CONNOLLY; BEGG, 2015). Isso inclui desde a escolha do software a ser utilizado para gerenciamento do banco de dados até definições de acesso aos bancos de dados pela aplicação e a forma de armazenamento dos dados fisicamente. Nesta etapa são tratadas as peculiaridades específicas de cada software de banco de dados como, por exemplo, tipos diferentes de dados,
funções específicas para manipulação de dados, entre outras. O projeto físico é necessário para garantir uma melhor aderência dos dados ao software de banco de dados (MARTYN, 2000).
Nessa etapa do projeto são escritas as instruções para a criação das estruturas de banco de dados. Como exemplo tem-se os comandos em Data Definition Language (DDL) para a cria-ção de tabelas, chaves estrangeiras e índices em bancos de dados relacionais. Como cada SGBD possui particularidades sobre esses comandos, como diferenças de sintaxe ou funcionalidades, essa etapa fica responsável por tratá-las.
No caso dos SGBDs NoSQL não há uma DDL padronizada. Cada SGBD possui coman-dos próprios para a criação de estruturas, sem nenhum tipo de padronização entre eles. Muitos SGBDs NoSQL não necessitam de criação de estruturas para sua utilização. Nesse caso as es-truturas são criadas quando são utilizadas e comandos são empregados para configurações de armazenamento ou definição de índices.
A execução das etapas do projeto de banco de dados trazem uma representação com-patível com os requisitos do sistema, garantindo que os dados sejam armazenados de forma oti-mizada e de forma a poderem ser utilizados pela aplicação de forma consistente. Para o modelo relacional, esses objetivos podem ser atingidos por meio dos processos previamente descritos e a extração dos dados pode ser implementada por meio de consultas complexas sobre as estruturas de dados definidas.
Para os modelos dados NoSQL não há uma metodologia de projeto consolidada e os métodos utilizados atualmente para o projeto de bancos de dados relacionais não podem ser uti-lizados devido às diferenças nas estruturas de armazenamento de dados (SRIVASTAVA; SHE-KOKAR, 2017). Para a definição de um método de projeto para os modelos de dados NoSQL é necessário conhecer os modelos de dados NoSQL, conforme descritos na Seção 2.2.
2.2 MODELOS DE DADOS NOSQL
Durante anos o modelo relacional foi utilizado como principal alternativa para o de-senvolvimento de aplicações baseadas no armazenamento de dados, principalmente no campo corporativo. É natural à grande maioria dos projetistas tê-lo como primeira opção ao desen-volver um projeto que necessite de armazenamento de dados. Sua versatilidade e amplo co-nhecimento do modelo pela comunidade científica, atribuído ao seu longo tempo de existência, permite que seja aplicado ao desenvolvimento de praticamente qualquer sistema. Entre as prin-cipais características do modelo relacional que permitem a aplicação em diversos cenários, está na implementação das propriedades ACID (Atomic, Consistent, Isolated, Durable), conferindo ao modelo altos níveis de consistência e durabilidade dos dados (SILBERSCHATZ; KORTH; SUDARSHAN, 2010).
elas trazem restrições à sua escalabilidade. As propriedades ACID se aplicadas em bases de dados distribuídas, trazem limitações na disponibilidade dos dados enquanto os nodos do cluster se atualizam durante uma alteração nos dados. Por essa razão a escalabilidade das bases de dados relacionais é apenas vertical, o que significa que é feita pela ampliação do hardware utilizado e não pela distribuição dos dados em múltiplos servidores, também chamada de escalabilidade horizontal.
Com o foco na capacidade de distribuição de dados em múltiplos servidores, as bases de dados NoSQL surgiram como uma alternativa. Diferente das bases de dados relacionais, muitas das NoSQL aplicam as propriedades denominadas BASE (Basically Available, Soft State,
Even-tually Consistent). Essas propriedades utilizam o conceito de reduzir o nível de consistência e
durabilidade dos dados em prol da disponibilidade e desempenho da aplicação, pela possibili-dade de distribuição dos dados. As propriepossibili-dades BASE podem ser detalhadas, conforme descrito por (CHANDRA, 2015):
∙ Basically Available: A base de dados está sempre disponível, o que é garantido pela sua arquitetura distribuída em vários sistemas de arquivos e com altos níveis de replicação; ∙ Soft State: Significa que os dados podem ser alterados ao longo do tempo, mesmo que
não hajam alterações solicitadas, devido à consistência eventual, descrita a seguir; ∙ Eventually Consistent: A consistência eventual define que algum tempo após as alterações
os dados os mesmos estarão consistentes em todas as bases de dados. Essa inconsistência temporária deve-se ao tempo de propagação dos dados pelo cluster que pode aumentar no caso de alguma falha de comunicação entre os nodos.
A aplicação das propriedades BASE varia entre os diversos modelos de dados NoSQL, podendo não se aplicar, como ocorre nas bases de dados Orientadas a Grafo, que seguem as propriedades ACID. Vários autores como Sadalage e Fowler (2012), Hashem e Ranc (2016) e Abramova, Bernardino e Furtado (2014) classificam os softwares de bancos de dados NoSQL em 4 categorias, de acordo com seu formato de armazenamento dos dados, são elas: a) Chave-valor, b) Orientado a Documento, c) Famílias de Colunas e d) Orientadas a Grafo. As próximas seções trazem uma explicação de cada um desses modelos de dados e suas aplicações mais comuns.
2.2.1 Chave-Valor
O modelo chave-valor do ponto de vista da aplicação é o mais simples de todos os modelos de dados NoSQL (SADALAGE; FOWLER, 2012). Ele assemelha-se a mapas ou di-cionários de dados, onde os dados são armazenados vinculados a uma chave única (HECHT; JABLONSKI, 2011). Pela definição básica, os dados vinculados à uma chave são armazenados de forma "opaca" ao sistema de banco de dados. Isso quer dizer que o banco de dados possui apenas acesso para armazenar e extrair os valores armazenados de forma integral, sem realizar extrações parciais ou transformações dos dados. Isso dificulta recursos como buscas de dados
de maneiras que não sejam pela sua chave única, assim como a implementação de estruturas de indexação.
Os dados armazenados são livres de qualquer tipo de esquema definido no banco de da-dos e por isso podem ser distintos entre si, permitindo inclusive que sejam de formatos diferentes como JavaScript Object Notation (JSON), Extensible Markup Language (XML) ou arquivos bi-nários como Binary JavaScript Object Notation (BSON). Essa ausência de esquema permite que qualquer alteração na estrutura lógica dos dados armazenados por parte da aplicação não cause nenhum tipo de indisponibilidade do sistema.
A única maneira de definir alguma forma de organização dos dados é por meio da padronização de suas chaves, criando agrupamentos ou definições específicas para cada caso. Não há qualquer tipo de estrutura de relacionamento entre os dados controlada pelas bases de dados e, caso sejam necessários, devem ser tratados pela aplicação. A Figura 2 apresenta um exemplo de armazenamento dos dados de uma Compra e de um Cliente em um sistema de
e-commerce, onde pode-se verificar as chaves de dados à esquerda e seus valores vinculados à
direita, que nesse caso estão no formato JSON.
Figura 2 – Exemplo de dados em um repositório chave-valor
Fonte: Autoria Própria
Bases de dados que fazem uso do modelo chave-valor são úteis para operações mais simples, onde os dados são sempre acessados por uma chave. Suas aplicações mais comuns estão em implementações de cache de websites, armazenamento de dados de perfis de usuários, armazenamento de dados de sessão, carrinhos de compras em sistemas e-commerce, entre outras (SADALAGE; FOWLER, 2012).
Tratando-se de escalabilidade, o modelo chave-valor possui capacidades de fragmenta-ção e replicafragmenta-ção, sendo um dos modelos mais escalonáveis. Sua simplicidade de armazenamento permite que facilmente seus dados sejam replicados e fragmentados a partir de suas chaves de armazenamento, o que pode lhe conferir maior desempenho na recuperação de dados. Também visando desempenho, alguns bancos de dados deste modelo são implementados com a possi-bilidade de armazenamento puramente em memória, tornando seus dados voláteis mas com
alto desempenho de escrita e gravação. Exemplos de software de banco de dados que utilizam o modelo chave-valor são o Redis (REDIS, 2018), Membase (COUCHBASE, 2018) e Project Voldemort (VOLDEMORT, 2017).
2.2.2 Orientado a Documento
Bases de dados orientadas a documento são repositórios de documentos. Segundo Chan-dra (2015), os documentos armazenam dados hierárquicos do tipo pares de chaves e valor. Apesar das bases mais conhecidas utilizarem JSON como formato de armazenamento, podem ser utili-zados outros formatos como XML ou BSON, e cada SGBD utiliza apenas um desses formatos para todos os documentos.
As bases de dados orientadas a documentos são uma extensão do modelo chave-valor que possui a capacidade de analisar os valores armazenados. Cada documento possui entre suas chaves uma identificação única que pode ser especificada pela aplicação ou auto-gerada. A Fi-gura 3 exibe um documento em JSON armazenado no MongoDB (MONGODB, 2018) com sua chave única "_id". Diferente do modelo chave-valor, no orientado a documentos os dados não são "opacos" à base de dados, o que significa que os dados são acessíveis e compreensíveis ao SGBD, permitindo criação de índices para otimização das consultas, validações de formato e implementação de operações de alteração e extração parcial dos dados de seus documentos.
Figura 3 – Exemplo de documento no MongoDB
Fonte: Autoria Própria
Para organização estrutural, as bases de dados orientadas a documentos possuem co-leções (ou collections), que são conjuntos de documentos e são usadas para classificação dos dados. Mesmo dentro de uma mesma coleção, não existe qualquer restrição de esquema, por-tanto, os documentos podem ser diferentes entre si, garantindo a flexibilidade dos dados.
No modelo orientado a documentos, não há nenhum tipo de restrição de integridade, como chaves estrangeiras ou chaves únicas típicas no modelo relacional. Alguns SGBDs
im-plementam formas de estabelecer vínculos entre documentos, criando relação com outros do-cumentos, porém sem restrições à alteração ou exclusão dos dados vinculados. As aplicações mais comuns desse modelo estão relacionadas a registro de logs, sistemas de gerenciamento de conteúdo, plataformas de blog e sistemas de e-commerce (SADALAGE; FOWLER, 2012).
Assim como os modelos de chave-valor, o modelo orientado a documento também pos-sui capacidades de fragmentação e replicação, que fornece grande escalabilidade por meio da adição de nodos no cluster (CATTELL, 2011). A fragmentação nesse caso não é feita pela chave única do documento, mas por uma "chave de fragmentação"(sharding key) que pode ser especifi-cada para especifi-cada coleção de documentos. Isso permite que a fragmentação seja melhor controlada pela aplicação, definindo padrões de agrupamento dos dados como, por exemplo, distribuição geográfica. A fragmentação visa principalmente ampliar a capacidade de gravação, distribuindo os diferentes processos de gravação entre diferentes nodos do cluster. A replicação por outro lado visa ampliar as capacidades de leitura, além de ampliar a segurança e disponibilidade dos dados em caso de falha de algum dos nodos do cluster.
2.2.3 Famílias de Colunas
Os SGBDs baseados no modelo de famílias de colunas são os mais semelhantes aos relacionais por possuírem os dados armazenados na forma de tabelas com linhas e colunas. Enquanto no modelo relacional os dados são armazenados e extraídos com base em suas linhas, tendo cada linha um mesmo conjunto de colunas, nos bancos de dados de famílias de colunas os dados são armazenados pelas colunas, tendo cada coluna várias linhas. Por essa razão, as linhas de uma mesma tabela - que nesse caso são chamadas de famílias de colunas - não possuem as mesmas colunas, conforme ilustrado na Figura 4.
Figura 4 – Exemplo de Família de Colunas
Fonte: Autoria Própria
Uma das principais diferenças em relação ao modelo relacional está no tratamento de valores nulos. No modelo família de colunas o valor não fica vinculado à linha, enquanto no modelo relacional o valor fica gravado como nulo. Outra vantagem está na forma de acesso aos dados, que consegue extrair do armazenamento apenas as colunas que estão sendo utilizadas na consulta, enquanto no modelo relacional todas as colunas seriam extraídas.
Diferente dos demais modelos NoSQL, o família de colunas possui definição de es-quema, pois são estabelecidas as colunas e tipos de dados para elas, algo que não ocorre nos modelos chave-valor e orientado a documentos. Ainda assim, a criação de novas colunas não afeta a disponibilidade do sistema pois as linhas já existentes permanecem sem valores e a es-trutura fica disponível imediatamente.
As aplicações desse modelo de dados se assemelham às do modelo orientado a docu-mento, como registro de eventos, sistemas de gerenciamento de conteúdo e plataformas de blog, mas existem usos mais específicos como contadores de acesso para websites (SADALAGE; FO-WLER, 2012). Assim como os outros modelos NoSQL, permite a escalabilidade horizontal de forma simples pela adição de mais nodos ao cluster, seja para aumentar a capacidade de leitura, por meio de replicação de dados ou capacidade de gravação pela fragmentação.
2.2.4 Orientado a Grafos
As bases de dados orientadas a grafo são as mais distintas entre todos os modelos NoSQL. Enquanto os demais modelos de dados visam escalabilidade e distribuição dos dados, o modelo de dados orientado a grafos baseia-se na teoria dos grafos e é utilizado em situações onde as consultas sobre os relacionamentos das entidades são frequentes. Visam a capacidade de realizar consultas que outros modelos de armazenamento não são capazes de prover de forma eficiente, como as consultas que se utilizam de navegação sobre relacionamentos.
Segundo Robinson, Webber e Eifrem (2015), grafos são uma coleção de vértices e ares-tas ou nós e relações entre os mesmos e é dessa forma que os dados são armazenados nesse mo-delo. Para organização dos dados são utilizadas etiquetas que podem ser vinculadas aos vértices e arestas. Cada vértice ou aresta pode possuir múltiplas etiquetas, assim como uma etiqueta pode estar vinculada a diversos vértices e arestas.
Bases de dados de grafos são utilizadas em aplicações onde os dados são conectados e consultas sobre essas conexões são constantes. Exemplos comuns são redes sociais, para indicar as conexões entre as pessoas, representar rodovias para sistemas de roteirização, e a realização de buscas de recomendação de produtos para sistemas de e-commerce por meio das vendas anteriores (SADALAGE; FOWLER, 2012). A aplicação desse modelo é justificada pois as bases relacionais não são eficientes em navegar sobre seus relacionamentos, habilidade explorada nas bases de dados de grafos (ROBINSON; WEBBER; EIFREM, 2015).
Os SGBDs baseados no modelo de dados orientado a grafos respeitam as propriedades ACID, por possuírem transações e permitirem a alteração de diversos dados em operações de forma atômica. A escalabilidade desse modelo de dados possui certas limitações. Enquanto a es-calabilidade para leitura, feita por meio de réplicas em um cluster é comumente implementada, a escalabilidade de gravação não pode ser implementada por fragmentação devido às caracte-rísticas dos algoritmos de busca dos dados. Esses algoritmos envolvem o acesso aos diversos
nodos do grafo por seus relacionamento, e a navegação por relacionamentos que envolvem no-dos diferentes do cluster tem seu desempenho comprometida (SADALAGE; FOWLER, 2012). Os modelos de dados NoSQL possuem características que visam sanar as deficiências do modelo relacional, principalmente se tratando de escalabilidade para as aplicações Web 2.0. Porém, os modelos NoSQL trazem consigo limitações diferentes do modelo relacional, como a execução de consultas complexas ou a consistência dos dados. Em sistemas complexos a utiliza-ção de um único modelo de dados pode não ser suficiente para tratar partes distintas do sistema. Para isso, abordagens híbridas, que se utilizam de múltiplos modelos de dados passaram a surgir, conforme será detalhado na Seção 2.3.
2.3 PERSISTÊNCIA POLIGLOTA
O surgimento dos modelos NoSQL no cenário de bancos de dados trouxe soluções para situações em que os sistemas baseados no modelo relacional não teriam a capacidade de ser bem empregados como bases de dados de larga escala. Requisitos como alta disponibilidade, desempenho ou formatos de dados que não são compatíveis com o modelo relacional, estão entre os principais motivadores para a utilização das bases de dados NoSQL (CATTELL, 2011).
Assim, como ocorre com o modelo relacional, não se pode dizer que algum dos modelos de dados NoSQL seja suficiente para sanar as diferentes necessidades dos softwares a serem desenvolvidos. Usar um único modelo de dados para estruturas transacionais, sessões de usuários e navegação por relacionamentos normalmente leva a soluções com baixo desempenho, pois são problemas essencialmente diferentes (SADALAGE; FOWLER, 2012).
A ideia de combinar as melhores funcionalidades de cada um desses modelos de dados, por meio da utilização em conjunto dentro de uma mesma aplicação, deu origem à "Persistência Poliglota"(SADALAGE; FOWLER, 2012). O termo tem origem na definição de "Programação Poliglota", para expressar a ideia que os softwares devem ser escritos em diversas linguagens para aproveitar as vantagens de cada uma na solução de problemas específicos. Os diferentes recursos de cada linguagem permitem alcançar soluções mais eficientes e maior produtividade no desenvolvimento. Seguindo o mesmo princípio, a utilização de diferentes modelos de dados permite aproveitar suas características distintas para o armazenamento e recuperação de dados. Um exemplo utilizado na literatura para representar a aplicação da persistência poli-glota é a estrutura de um e-commerce, explorado em Srivastava e Shekokar (2017) e Sadalage e Fowler (2012), que apresentam a divisão de funcionalidades de um e-commerce, sendo cada uma implementada em diferentes bases de dados. Este conceito de divisão de funcionalidades pode ser observado na Figura 5.
Essa estratégia de implementação utilizando múltiplos modelos de dados permite que cada parte do sistema utilize o modelo de dados que melhor atende aos seus requisitos,
indepen-dente dos requisitos necessários para outras partes do mesmo sistema. É possível, por exemplo, implementar o Catálogo de Produtos utilizando um modelo de dados orientado a documentos, utilizando-se das características de alta disponibilidade e replicação desse modelo. O Módulo
Financeiropermanece implementado com um modelo relacional, mantendo a consistência das
propriedades ACID que se fazem necessárias. Figura 5 – Estrutura de um e-commerce
Fonte: Adaptado de (SRIVASTAVA; SHEKOKAR, 2017)
A utilização de uma estratégia com múltiplos modelos de dados traz vantagens ao de-senvolvimento por tratar partes distintas do sistema com as melhores estratégias para cada uma, mas traz consigo desvantagens. Entre elas estão a necessidade de replicação de dados entre os modelos, que muitas vezes possuem formatos de armazenamento distintos, aumento da comple-xidade na manipulação das transações e diferentes formas de acesso para as diferentes bases de dados, conforme mencionado por Oliveira e Cura (2016).
É importante mensurar se as vantagens trazidas por uma estratégia de persistência poli-glota são suficientes para compensar as complexidades inseridas no desenvolvimento. Sistemas de menor porte podem não justificar o aumento de complexidade imposto pela persistência po-liglota, e sua implementação por meio de um único modelo de dados ainda permaneceria a melhor alternativa. Porém, aplicações de grande porte com fortes requisitos de desempenho e disponibilidade justificam tal abordagem.
Por se tratar de uma solução que envolve múltiplos modelos de dados, a persistência poliglota depende também de uma interação maior do projeto de banco de dados com o desen-volvimento do software. Para isso é importante conhecer um método de desendesen-volvimento capaz de integrar os diversos modelos de armazenamento, como é o caso do DDD, descrito na Seção 2.4.
2.4 DOMAIN-DRIVEN DESIGN
O DDD foi definido por Evans (2004) e trata de uma metodologia de orientação a obje-tos (ATZENI, 2016). O DDD serve de guia para a aplicação de boas práticas de desenvolvimento e visa facilitar o entendimento e aplicação do contexto de um projeto ao software desenvolvido. Trata-se de um paradigma oposto ao conceito de Data-Driven Design, onde o projeto da apli-cação é baseado nos dados a serem persistidos. No DDD o foco está em como os dados são utilizados pela aplicação, ou seja, nas regras de negócio do sistema, sendo a persistência uma camada do processo de modelagem da aplicação.
A razão para o foco principal do DDD ser as regras de negócio e não a persistência dos dados está no fato de as maiores complexidades do desenvolvimento não serem os aspectos técnicos da aplicação, mas sim as regras de negócio (EVANS, 2004). Aspectos como desem-penho da aplicação podem ser melhor tratados dessa maneira, sendo que uma vez conhecidos os objetivos de consulta, o projeto da aplicação pode tratar de otimizar formas de obtenção e gravação dos dados.
Pode-se identificar a conexão entre o DDD e as bases de dados NoSQL. As bases são utilizadas para aplicações que exigem alto desempenho e disponibilidade. Porém, essas bases de dados não possuem recursos complexos de consulta como junções e isso exige que os dados sejam projetados para serem extraídos de forma mais simples e direta (LI; MA; CHEN, 2014). A simplificação do acesso aos dados pela aplicação está diretamente relacionado ao projeto dos agregados e repositórios feito pelo DDD.
2.4.1 Agregados
Entre os quatro modelos de dados NoSQL descritos anteriormente, três deles recebem a definição de "orientados a agregados", são eles: Chave-valor, Orientado a documento e Família de colunas. Autores como Sadalage e Fowler (2012) e Bugiotti e Cabibbo (2014) defendem que a origem do termo "agregados"neste contexto vem do DDD.
Agregados são um conjunto de objetos associados que são tratados como uma unidade para fins de alteração dos dados (EVANS, 2004). Esse agrupamento de objetos visa criar uma abstração para referenciar o modelo, estabelecendo limites entre o que pertence ao agregado e as entidades externas. Essa definição facilita as tarefas de manipulação do agregado, pois permite que os objetos agrupados possam ser tratados como uma unidade.
Todo agregado possui uma raiz e um limite. O limite define o que pertence ao agregado, suas entidades e os relacionamentos entre elas dentro do agregado. A raiz é a única entidade do agregado que pode ser referenciada por entidades externas a ele. Demais entidades do agregado podem referenciar entidades dentro do agregado ou externas, mas nunca podem ser referenciadas
por entidades externas. Isso ocorre porque as demais entidades tornam-se internas ao agregado e, portanto, inacessíveis externamente. Um exemplo de uma estrutura de agregados pode ser visto na Figura 6, que apresenta os dados do Pedido, como seus itens e o histórico de situações deste pedido compondo o agregado, enquanto o Cliente fica relacionado apenas ao Pedido. Figura 6 – Exemplo de agregado
Fonte: Autoria Própria
O modelo relacional utiliza o conceito de armazenamento de dados em tuplas, ou tam-bém chamadas de linhas, onde seus dados são armazenados em colunas. Isso muitas vezes en-volve a divisão dos dados em diversas tabelas e linhas com relacionamento entre elas, sempre baseados na simplificada estrutura de uma linha. As bases de dados NoSQL orientados a agre-gados trabalham com uma abordagem diferente. Elas partem do princípio que é interessante utilizar estruturas mais complexas que permitam o armazenamento de estruturas aninhadas e listas de dados, agrupando as informações relacionadas em um único registro, para facilitar sua extração e manipulação (SADALAGE; FOWLER, 2012).
Os modelos de dados são denominados como orientados a agregados pois os utilizam como unidade básica de recuperação e armazenamento dos dados, o que simplifica o trabalho em cluster, uma vez que representam uma unidade natural de replicação e fragmentação (SA-DALAGE; FOWLER, 2012). Como os agregados são formados pelas suas estruturas aninhadas, podem ser transportados entre diferentes nodos de um cluster mantendo a integridade necessária para essas bases de dados.
As formas de utilização dos agregados nos modelos de dados NoSQL diferem estrutu-ralmente, mas o conceito essencial é preservado. No modelo chave-valor a raiz para acesso ao agregado é sua chave e seu limite define o que está contido no valor dessa chave. O mesmo ocorre com o modelo orientado a documento, mudando a forma de utilização da chave de acesso e adi-cionando algumas possibilidades extras de busca. Já no modelo de família de colunas a raiz do agregado é a chave da linha e os valores são distribuídos pelas colunas podendo conter estruturas
aninhadas. A linha define o limite do agregado.
2.4.2 Repositórios
O objetivo dos repositórios dentro do DDD é a comunicação entre a aplicação e as bases de dados a serem utilizadas, ou seja, são responsáveis pela persistência dos dados. A co-municação é feita por meio da extração e gravação de agregados na base de dados, realizando as conversões estruturais necessárias para essa tarefa (EVANS, 2004). No modelo relacional isso significa extrair ou gravar as alterações em múltiplas tabelas utilizando junções ou consultas mais complexas e gravação por múltiplos processos encadeados em uma única transação. Pro-cesso semelhante é aplicável às bases de dados orientadas a grafo, porém na forma de consultas no grafo e transações com alterações de múltiplos nodos e relacionamentos.
Já nas bases de dados NoSQL orientadas à agregado essa operação é tratada de forma mais direta, pela extração dos agregados da base de dados. Uma vez que os agregados arma-zenados no banco de dados sejam compatíveis com os utilizados pela aplicação, o repositório pode tomar as ações necessárias para sua utilização, como instanciar classes ou converter tipos de dados para utilização pela aplicação.
Os repositórios definem as funções necessárias para a operação da aplicação. Funções de busca, alteração ou inserção de dados são definidas no repositório e trazem a visão dos pro-cessos necessários para a persistência dos dados e funcionamento da aplicação (EVANS, 2004). Isso os torna parte integrante da definição necessária para o projeto de bancos de dados NoSQL, uma vez que essas funções norteiam as necessidades de consulta e consequentemente a compo-sição dos agregados.
2.5 TRANSFORMAÇÃO DE MODELOS
A execução das etapas do projeto de banco de dados exigem a definição de diferentes modelos de representação devido à características distintas de cada uma delas. Esses modelos utilizam notações e linguagens diferentes na sua construção o que traz dificuldades de interpreta-ção durante processo de transformainterpreta-ção de um modelo para o outro (BOESING, 2019). Visando simplificar esse processo de conversão, diversos métodos de transformação são propostos na literatura.
Na engenharia de software, o conceito de transformação de modelos é aplicado em diversos contextos e, segundo Mens e Gorp (2006), todo tipo de transformação pode ser classi-ficada seguindo três características:
mesmo metamodelo como origem e destino, esta é considerada uma transformação endó-gena. Quando os metamodelos diferem, é considerada exógena;
∙ Nível de abstração: A transformação é considerada vertical quando os modelos envolvidos estão em diferentes níveis de abstração. Caso os modelos estejam em um mesmo nível de abstração, trata-se de uma transformação horizontal;
∙ Análise semântica: Uma transformação que trata apenas da sintaxe do método, como nome dos elementos e formas de notação, é considerada uma transformação sintática. Caso seja levado em consideração também a semântica do modelo, onde o sentido dos elementos pode levar a diferentes transformações, essa transformação é considerada semântica.
O projeto de bancos de dados relacionais envolve a transformação de modelos quando ocorre a transformação do MER para o modelo relacional. Essa transformação ocorre durante o projeto lógico e é realizada pela aplicação do conjunto de regras normais (SILBERSCHATZ; KORTH; SUDARSHAN, 2010). De forma análoga, esse trabalho propõe um processo de trans-formação de modelos considerado, segundo as classificações definidas anteriormente, exógeno, horizontal e semântico.
2.6 CONSIDERAÇÕES DO CAPÍTULO
Este capítulo apresentou os conceitos sobre os modelos de dados NoSQL, projeto de banco de dados e desenvolvimento de aplicações orientadas a objeto importantes para a condu-ção deste trabalho. A base da metodologia de projeto de bancos de dados, apesar de ser utilizada comumente para o modelo relacional, possui uma definição que pode ser aplicada a outros mo-delos de dados. Os momo-delos NoSQL, diferente do relacional, possuem foco voltado ao desem-penho e disponibilidade, utilizando-se de estruturas mais simples com grande escalabilidade. Essa simplicidade estrutural traz consigo uma necessidade maior de integração entre o projeto da aplicação e da base de dados, permitindo que os dados possam ser extraídos de forma mais direta, atendendo as necessidades do sistema a ser desenvolvido.
A aplicação da persistência poliglota para o desenvolvimento de softwares traz pos-sibilidades que não seriam facilmente alcançadas por uma estratégia que utilizasse um único modelo de dados. Porém, a ausência de uma metodologia de projeto de banco de dados capaz de trabalhar com múltiplos modelos de dados torna essa tarefa mais complexa. O conhecimento dos modelos de dados NoSQL é primordial para a elaboração de um método capaz de integrar os múltiplos modelos em uma estratégia única. A utilização dos conceitos do DDD permite a integração dos múltiplos modelos de dados em uma aplicação que utilize persistência poliglota. Por fim, a transformação de modelos permite definir regras para a conversão de um modelo de dados de origem como, por exemplo, o MER em um modelo de destino necessário para a utilização dos modelos NoSQL.
3 ESTADO DA ARTE
Esse capítulo apresenta um mapeamento sistemático sobre o tema projeto de bancos de dados NoSQL e persistência poliglota com o intuito de identificar o estado da arte sobre es-tes temas, quais seus principais autores e abordagens utilizadas. Este mapeamento sistemático também visa identificar lacunas e temas para futuras pesquisas. Entre os vários métodos en-contrados na literatura para a realização de mapeamentos sistemáticos optou-se por utilizar o
Methodi Ordinatiodetalhado por Pagani, Kovaleski e Resende (2015) devido a sua facilidade de
aplicação e sua metodologia de seleção de artigos baseada em 3 critérios: Fator de impacto, ano de publicação e número de citações. Estes critérios são os principais fatores para a definição da relevância de um trabalho científico e são utilizados para classificar os artigos selecionados.
Foram encontrados um total de 4235 artigos baseados em um conjunto de palavras-chave definido para busca em quatro bases de dados: "ACM Digital Library", "IEEE Xplorer", "Science Direct"e "Springer Link". O período de busca ficou compreendido entre os anos 2005 e 2018, período de relevância para as pesquisas relacionadas à bases de dados NoSQL. Após os processos de seleção e classificação optou-se pela utilização dos 15 artigos considerados mais relevantes para uma leitura mais detalhada e categorização. A Seção 3.1 apresenta o processo e as etapas para a execução deste mapeamento sistemático e a Seção 3.2 apresenta os seus resultados. A Seção 3.3 apresenta alguns trabalhos relacionados com a área de pesquisa. Por fim, a Seção 3.4 traz as considerações finais do capítulo.
3.1 METODOLOGIA APLICADA
As metodologias de mapeamento sistemático definem uma série de etapas para sua execução, visando otimizar os resultados e reduzir esforços de pesquisa, procurando reduzir ao máximo os riscos de desconsiderar trabalhos que sejam relevantes aos objetivos de pesquisa. O método proposto por Pagani, Kovaleski e Resende (2015) possui 9 etapas para o levantamento das Questões de Pesquisa (QP), strings de busca, filtragem, levantamento de critérios para a definição de relevância, classificação para então executar a leitura detalhada dos artigos. Dessa forma, os esforços de pesquisa vão sendo reduzidos ao longo dos processos de filtragem e clas-sificação. As próximas seções detalham a execução das etapas do Methodi Ordinatio empregado neste processo de mapeamento sistemático.
3.1.1 Definição das Intenções de Pesquisa
A intenção de pesquisa deste trabalho é conhecer quais as estratégias estão sendo atual-mente empregadas para o projeto de bancos de dados NoSQL, bem como o projeto de aplicações que se utilizem de vários modelos de bancos de dados, ou também chamada de persistência po-liglota. O Methodi Ordinatio considera que o primeiro passo desse processo é a definição de questões de pesquisa que sejam capazes de nortear as buscas de trabalhos. Para este trabalho foram definidas as seguintes questões de pesquisa:
∙ QP1. Quais os principais autores na área de projeto de bancos de dados NoSQL? ∙ QP2. Quais são os casos de aplicação mais comuns dos bancos de dados NoSQL? ∙ QP3. Quais as estratégias existentes atualmente no projeto de banco de dados NoSQL? ∙ QP4. Quais dessas estratégias se aplicam ou poderiam ser aplicadas para a persistência
poliglota?
Essas questões visam traçar um panorama das abordagens atualmente utilizadas para o projeto de banco de dados de aplicações tanto que se utilizem apenas de modelos NoSQL, como aqueles que se utilizem de múltiplos modelos de dados. É importante também identificar entre as abordagens encontradas quais seriam capazes de ser utilizadas em uma aplicação com persistência poliglota, mesmo que a abordagem não especifique essa possibilidade.
3.1.2 Pesquisa Preliminar Exploratória
De acordo com Pagani, Kovaleski e Resende (2015), após a definição das intenções de pesquisa é necessário identificar as bases de dados e conjuntos de palavras-chave a serem utilizadas para a pesquisa. Com esse objetivo, uma pesquisa exploratória é executada nas bases de dados para identificar a aderência das palavras-chave ao tema de pesquisa e às bases de dados, além de identificar outros termos que possam estar relacionados com as intenções de pesquisa. As bases de dados inicialmente utilizadas para a pesquisa exploratória foram:
∙ ACM Digital Library; ∙ IEEE Xplorer;
∙ Science Direct; ∙ Springer Link.
Essas bases de dados foram selecionadas pela sua relevância no campo de pesquisa conforme descrito por Buchinger (2014) e pela sua importância no campo de tecnologia da in-formação. O objetivo deste processo foi encontrar as melhores bases de dados a serem utilizadas. A definição da string de busca deve ter como objetivo não apenas trazer os trabalhos relevantes para a pesquisa, mas também eliminar ao máximo possível os trabalhos não relacio-nados ao tema. É necessário experimentar diversas combinações de palavras-chave e observar os
recursos disponíveis em cada uma das bases de dados, como filtros e sintaxe da string de busca. Esse processo deve setar os critérios de busca o mais próximo possível entre todas as bases, bus-cando a melhor uniformidade no processo (PAGANI; KOVALESKI; RESENDE, 2015). Nessa etapa também é validado o período de pesquisa para identificar os anos de maior relevância para o tema pesquisado.
Os termos de pesquisa testados inicialmente foram os termos relacionados a bases de dados NoSQL, como "nosql", "key-value", "column-family", "column-wide",
"document-oriented"e "graph database", termos relacionados ao projeto e modelagem de bancos de dados
como "design"e "modeling"e termos relacionados a persistência poliglota e bases de dados he-terogêneas como "polyglot persistence"e "heterogeneous database". Na pesquisa preliminar foi possível perceber que muitos dos artigos retornados tratavam de comparações de desempenho entre os diversos softwares disponíveis no mercado e esse tipo de trabalho foge ao escopo da pesquisa. Também foi possível observar que algumas bases de dados precisam de filtros especí-ficos para excluir resultados como capítulos de livros, editoriais e outros formatos de publicação não considerados relevantes para esse mapeamento sistemático. As bases de dados utilizadas na pesquisa preliminar também foram validadas quanto aos artigos retornados e sua relevância no tema pesquisado.
3.1.3 Definição das Palavras-chave e Bases de Dados
Esta etapa tem o objetivo de delimitar as palavras-chave, suas combinações e quais bases de dados serão utilizadas para a pesquisa. A seleção das bases de dados deve levar em consideração a quantidade de trabalhos retornados nas pesquisas e a disponibilidade do material publicado (PAGANI; KOVALESKI; RESENDE, 2015). Todas as bases de dados utilizadas na etapa anterior retornaram número considerável de trabalhos para as pesquisas preliminares e, algumas com pequenas adaptações, foram capazes de interpretar as strings de busca testadas. Com isso, todas as bases de dados foram utilizadas na pesquisa sistemática.
Os testes com as palavras-chave revelaram os termos de pesquisa a serem utilizados para a formação de uma string de busca capaz de retornar trabalhos do tema pesquisado. Essa
stringde busca pode ser visualizada na Figura 7.
Figura 7 – String de busca nas bases de dados
Fonte: Autoria Própria
utilizadas como critério de eliminação de artigos porém, como o objetivo da utilização de bases de dados NoSQL geralmente está voltado ao desempenho, artigos relevantes poderiam ser eli-minados. O período utilizado para a pesquisa ficou compreendido entre os dados 2005 e 2018, período de relevância para trabalhos relacionados a bases de dados NoSQL.
3.1.4 Pesquisa Definitiva nas Bases de Dados
Segundo Pagani, Kovaleski e Resende (2015), a pesquisa definitiva consiste em aplicar os termos de busca, filtros e parâmetros previamente definidos nas bases de dados e exportar os dados para um software de gerenciamento de referências. Vários softwares de gerenciamento de referências estão disponíveis no mercado, como por exemplo Zotero, Endnote e Mendeley. Optou-se por utilizar o Mendeley pelo conhecimento prévio da ferramenta e facilidade de im-portação dos formatos de exim-portação de todas as bases de dados. Há também um plugin para o
Google Chromepara facilitar o processo de importação das referências. As contribuições
quan-titativas das bases de dados podem ser observadas na Figura 8, resultando em um total de 4235 artigos encontrados.
Figura 8 – Contribuição das bases de dados
