Evolution Management in Multi-Model Databases - En.pt

Traduzido do Inglês para o Português - www.onlinedoctranslator.
com
Engenharia de dados e conhecimento 136 (2021) 101932
Listas de conteúdos disponíveis emScience Direct
Engenharia de dados e conhecimento
Página inicial do jornal:www.elsevier.com/locate/datak
Gerenciamento de evolução em bancos de dados multimodelos
Irena Holubováa,∗,Michal Vavreka,Stefanie Scherzingerb

aCharles University, Praga, República Tcheca
bUniversidade de Passau, Alemanha
ARTIGOINFO ABSTRATO
Palavras-chave: Seguindo as previsões do Gartner, a maioria dos SGBDs, tanto relacionais tradicionais quanto NoSQL,
Bancos de dados multimodelo tornaram-se multimodelos. No entanto, essa funcionalidade trouxe muitos problemas relacionados. Uma
gestão de evolução das mais complexas é a gestão da evolução e respetiva propagação das alterações a todas as partes
Alterar propagação
afetadas do sistema. Neste artigo, apresentamos nossa implementação de protótipo chamada MM-evolver
que permite realizar operações de modificação de esquema acionadas pelo usuário em um banco de dados
multimodelo e as propaga em todos os modelos. Como novidade,MM-evolveroferece suporte a operadores
de modificação de esquema entre e intramodelos. Até onde sabemos, a nossa é a primeira ferramenta
abordando o gerenciamento de evolução no mundo dos bancos de dados multimodelos.
1. Introdução
Apesar do ''um tamanho não serve para todos'' argumento [1], a maioria dos sistemas de gerenciamento de banco de dados (DBMSs) populares
existentes, sendo relacionais, NoSQL ou de outro tipo, seguiram as previsões do Gartner [2] de suportar vários modelos de dados em um único DBMS.
Embora simples na ideia – adicionar outro modelo de dados – sua realização é bastante complexa. Tal suporte requer extensões tanto na interface
unificada quanto na implementação eficiente, enquanto os modelos combinados (e respectivos sistemas) geralmente possuem características
contraditórias. Por exemplo, existem formatos estruturados, semi-estruturados e não estruturados, existem sistemas baseados em consistência forte ou
eventual, ou existem linguagens de consulta com características específicas (declarativas, funcionais, . . . ).
Exemplo 1.1.Consideremos um exemplo emFigura 1, onde um banco de dados multimodelo dá suporte a um sistema de informações de gerenciamento empresarial.
Uma rede social de clientes é capturada usando um gráfico. Uma tabela relacional registra informações adicionais, como seu limite de crédito. Os pedidos enviados
pelos clientes são armazenados como documentos JSON em uma coleção. Uma tabela de colunas largas mantém o histórico de todos os pedidos e um mapeamento
de chave/valor mantém os carrinhos de compras atuais. Uma consulta entre modelos pode retornar todos os amigos de clientes que solicitaram qualquer item com
um preço superior a 180.
Embora os principais desafios do multimodelo já tenham sido resolvidos (pelo menos até certo ponto) para permitir a funcionalidade básica necessária, ainda
restam tarefas avançadas e complexas a serem analisadas e cumpridas [4]. Uma delas, sendo nosso objetivo neste artigo, é a gestão da evolução. À medida que os
requisitos do usuário mudam, as estruturas de dados evoluem e, consequentemente, também a respectiva estratégia de armazenamento, consultas etc. Esse
problema é desafiador mesmo no mundo dos bancos de dados de modelo único. Em aplicações mais simples, podemos contar com um administrador de banco de
dados habilidoso, mas em situações mais complexas é uma tarefa difícil e sujeita a erros que exige a propagação correta e completa de uma alteração para todas as
partes afetadas do sistema. Além disso, podemos observar abordagens contraditórias desse problema em diferentes tipos de SGBDs. No mundo dos bancos de
dados relacionais ou XML tradicionais, a evolução do esquema requer mudanças imediatas tanto no esquema quanto na instância de dados (propagação ansiosa).
Com os sistemas NoSQL, podemos (até certo ponto) explorar o suporte para redundância e falta de esquema, ou seja, a capacidade de armazenar dados com
configurações semelhantes, mas não necessariamente iguais.
∗Correspondência para: Departamento de Engenharia de Software, Charles University, Malostranské nám. 25, 118 00 Praha 1, República Tcheca.
Endereço de e-mail:irena.holubova@matfyz.cuni.cz (I. Holubová),vavrekmichal@gmail.com (M. Vavrek),stefanie.scherzinger@uni-passau.de (S. Scherzinger).
https://doi.org/10.1016/j.datak.2021.101932
Recebido em 21 de novembro de 2020; Recebido no formulário revisado em 22 de junho de 2021; Aceito em 17 de setembro de 2021
Disponível online em 22 de setembro de 2021
0169-023X/©2021 Elsevier BV Todos os direitos reservados.
I. Holubová, M. Vavrek e S. Scherzinger Engenharia de dados e conhecimento 136 (2021) 101932
Figura 1.Um cenário multimodelo.

Fonte:Parcialmente emprestado de [3].
estrutura e propagar as mudanças quando necessário (propagação preguiçosa). Considerando a existência de um esquema, outra complicação é a
existência deesquema completo,sem esquemae até mesmoesquema mistobancos de dados multimodelos. Para todos estes tipos de sistemas existem
representantes multimodelos [5,6], ou seja, sistemas que foram estendidos com suporte a múltiplos modelos com essas (e outras) características em
contradição.
Exemplo 1.2.Considere novamenteFigura 1. Podemos querer adicionar uma nova propriedade a um dos modelos (por exemplo, um endereço de
entrega para documentos JSON que representam pedidos), o que não afeta os outros modelos. Mas, mais tarde, podemos decidir mover essa
propriedade para outro modelo (por exemplo, para representar endereços no modelo relacional). Portanto, precisamos fazer uma alteração em ambos
os modelos. Além disso, pode já existir uma referência à propriedade modificada, que precisa ser atualizada de acordo.
Para abordar os problemas indicados, estendemos nossos resultados de pesquisas anteriores [7] para sistemas de modelo único (XML ou relacional)
ou sistemas com modelos intimamente relacionados (nomeadamente NoSQL [8,9]). Apresentamos uma ferramenta chamadaMM-evolver, que permite
realizar alterações exigidas pelo usuário em um esquema multimodelo e as propaga em todos os submodelos. As principais contribuições podem ser
resumidas da seguinte forma:
∙ Com base em uma Model-Driven Architecture (MDA), definimos o modelo independenteLinguagem de evolução de esquema multimodelo (MM
SEL) que permite especificar todas as mudanças principais, tanto intra-modelo quanto inter-modelo.
∙ Mostramos três versões de sua implementação – referências básicas, otimizadas e de suporte – usando umLinguagem de programação de banco
de dados multimodelo(MM DBPL) que abrange todos os modelos de dados populares (coluna, documento, chave/valor, gráfico e relacional).
∙ Apresentamos uma implementação de prova de conceito, usando dados do mundo real do iMDB [10]. Demonstramos como funciona cada uma
das operações e mostramos quanto trabalho manual (e possíveis erros) nossa abordagem economiza.
∙ Discutimos desafios gerais e problemas abertos de gerenciamento de evolução no mundo multimodelo e apontamos novidades para
cientistas e profissionais.
Até onde sabemos, esta é a primeira solução real abordando o problema de gerenciamento de evolução no mundo dos bancos de dados
multimodelo, abrangendo todos os modelos de dados populares, lidando com mudanças entre modelos e considerando também referências
mútuas entre os modelos. Apesar da lista discutida de problemas ainda em aberto, vemos isso como o primeiro passo para uma unificação da
gestão da evolução em vários modelos previstos em vários artigos [11–13] e como uma direção inspiradora para trabalhos futuros em geral.
Observe queMM-evolverjá foi introduzido em um documento de demonstração [14] no EDBT '19. Este artigo difere, principalmente porque descrevemos aqui
todos os detalhes técnicos da proposta que não poderiam ser descritos em um breve artigo de demonstração.
Contorno de papel.O restante do artigo está estruturado da seguinte forma: Na Seção 2 revisamos trabalhos relacionados. Na seção3nós apresentamos
MMevolvere na Seção4descrevemos resultados de testes que demonstram sua funcionalidade. Na seção5concluímos com uma discussão geral dos
problemas em aberto restantes. Os Apêndices A e B fornecem um conjunto completo de capturas de tela relacionadas aos testes realizados.
2. Trabalho relacionado
Primeiro, fornecemos uma visão geral das abordagens existentes para gerenciamento de dados multimodelo, sua classificação e recursos com base
em [15]. Na segunda parte desta seção, descrevemos abordagens para o gerenciamento da evolução do esquema no mundo multimodelo.
2.1. Gerenciamento de dados multimodelo
Em geral, existem duas abordagens básicas para manipular e consultar dados multimodelos: (1)persistência poliglotae (2)banco de dados
como homem ageme sistema nt ms(M SGBDs M).
multimodelo
T ele histo ry depoliglota persistir ência pode ser rastreada back para multi-bancos de dados [ 16] e sistemas fedbancos de dados avaliados[ . A principal estratégia
é para empregar diferir ent dat abases para armazenar diferentes modelos de dados e, em seguida, desenvolver 17] lop um mediador para intdeles é reuni-los
2
tabela 1
Uma estratégia de extensão para múltiplos modelos.
Abordagem DBMS modelo original
PostgreSQLName relacional
Servidor SQL relacional
IBM DB2 relacional
banco de dados Oracle relacional
Nova estratégia de armazenamento Cassandra coluna
CrateDB coluna
DynamoDBName coluna
Riak valor chave
Cosmos DB documento
MySQL relacional
Extensão de
HPE Vertica coluna
o original
ArangoDBName documento
armazenar
MongoDBGenericName documento
estratégia
OrientDB gráfico
Tendão relacional
c-treeACE valor chave
Nova interface
Banco de Dados Oracle NoSQL valor chave
para o original
cache valor chave
estratégia de armazenamento
Sofá documento
MarkLogic documento
para avaliar as consultas. Recentemente, protótipos de pesquisa (principalmente voltados para a academia) também foram desenvolvidos — por
exemplo, DBMS+ [18] abrange várias plataformas de processamento e banco de dados com processamento declarativo unificado. BigDAWG [19] fornece
uma arquitetura que oferece suporte à transparência de localização e um middleware que fornece uma interface multi-ilha uniforme para executar
consultas de usuário com três sistemas integrados: PostgreSQL, SciDB e Accumulo. A evolução do esquema no contexto da persistência poliglota
também foi identificada e discutida como um desafio de pesquisa [20].
Uma nova geração de empresas voltadas principalmente para a indústriabancos de dados multimodelo[3,15] é capaz de armazenar e processar
dados estruturalmente diferentes e suportar vários modelos de dados em um único DBMS com uma linguagem de consulta unificada, bem como API.
Além disso, não existe um modelo indispensável e todo modelo é (pelo menos em teoria) igualmente importante. Devido à grande demanda, atualmente
existem mais de 20 SGBDs considerados multimodelos, com novos representantes sendo lançados.
O principal problema é que o nível de suporte para dados de vários modelos varia muito, com capacidade diferente de consultar modelos distintos,
indexar a estrutura interna de um modelo e otimizar planos de consulta entre modelos. Os atuais bancos de dados multimodelos podem ser
classificados de acordo com vários critérios. A classificação chave com base em seu modelo de dados original (ou principal) é fornecida emtabela 1
(emprestado de [21]).
Como podemos ver, a tabela lista representantes de bancos de dados relacionais tradicionais e todos os quatro tipos de bancos de dados NoSQL
(consulte a colunaDBMS). na colunaAbordagempodemos ver a classificação dos sistemas de acordo com a estratégia usada para estender o modelo
original (especificado na colunamodelo original) para outros modelos ou para combinar vários modelos. Existem quatro tipos de abordagens para
extensão multi-modelo:
1. adoção de uma estratégia de armazenamento completamente nova adequada para o(s) novo(s) modelo(s) de dados,
2. extensão da estratégia de armazenamento original para fins do(s) novo(s) modelo(s) de dados,
3. criação de uma nova interface para a estratégia de armazenamento original, e
4. nenhuma mudança na estratégia de armazenamento original.1
Embora, do ponto de vista do usuário, o resultado teoricamente ideal de suporte de todos os modelos (atualmente populares) com interconexões mútuas seja o
mesmo, as formas como os bancos de dados específicos tentam alcançá-lo diferem fortemente.
Exemplo 2.1.Quando um usuário precisa de suporte para, por exemplo, gráfico e modelo de documento, o usuário pode escolher, por exemplo, ArangoDB2ou
OrientDB.3No entanto, existem diferenças significativas entre os dois sistemas [22]. O modelo original do ArangoDB é document, então os documentos representam
os nós do grafo e as arestas são armazenadas em uma coleção especial de arestas. O OrientDB, originalmente um banco de dados de gráficos construído sobre um
banco de dados de objetos, foi estendido para o suporte a documentos cuja estrutura hierárquica pode ser capturada pelo modelo de objetos com bastante
naturalidade.
Conforme mencionado na Introdução, como os modelos combinados (e respectivos sistemas) muitas vezes têm características contraditórias, o problema de
gerenciamento da evolução precisa principalmente de uma solução suficientemente geral de alto nível definida independentemente dessas especificidades técnicas.
1Esta opção, não envolvida emtabela 1, representa um caso trivial, permite armazenar um modelo de dados mais simples em um sistema que suporta um mais complexo, como armazenar pares
chave/valor em um banco de dados de documentos.
2 https://www.arangodb.com/.
3 https://orientdb.org/.
3
Figura 2.Modelos independentes de plataforma e específicos de plataforma emDaemonX. (Para interpretação das referências a cores nesta legenda de figura, o leitor deve
consultar a versão web deste artigo.)
2.2. gestão de evolução
O problema do gerenciamento da evolução é importante e complexo mesmo no mundo de modelo único. No entanto, a quantidade de abordagens
existentes ainda é muito pequena em comparação com os outros aspectos do gerenciamento de dados. Se nos concentrarmos apenas em abordagens
multimodelo, até onde sabemos, existem apenas dois sistemas lidando com modelos múltiplos, ambos ainda com muitas limitações.
DaemonX.Em papel [23], os autores propõem umaestrutura de gerenciamento de evolução de cinco níveischamadoDaemonX. Para o projeto de
engenharia avançada de um aplicativo, eles consideram uma abordagem de cima para baixo a partir do projeto de um modelo independente de
plataforma (PIM) e, em seguida, mapeando suas partes selecionadas para os respectivos modelos específicos de plataforma de modelo único (PSMs)
seguidos por esquema, níveis operacional e extensional do MDA. Os modelos PSM suportados envolvem XML, relacional, processo de negócios e REST.
Os autores focam na propagação correta e completa das mudanças entre os modelos, principalmente quando os esquemas PSM se sobrepõem,
devendo a mudança ser propagada corretamente para todas as instâncias. Adicionalmente, é considerado o mapeamento para consultas e respetiva
propagação de alterações ao nível operacional.
Exemplo 2.2.DaemonXusa o diagrama de classe UML clássico para o nível PIM. Partes do PIM (possivelmente sobrepostas ou não cobrindo
todo o PIM) são então escolhidas e mapeadas para diagramas PSM específicos. EmFigura 2, descrevemos a situação para os modelos
relacional e documental. Para o PSM relacional (violeta), é utilizado o modelo ER. Para o documento PSM (verde), o modelo X-SEM [24]4
é usado. Ele nos permite modelar a hierarquia, repetição e outros recursos de dados semiestruturados. No nível do esquema – não
representado na figura – estaria o esquema do banco de dados das tabelas relacionais e o esquema dos documentos JSON expressos nas
respectivas linguagens.
A ideia da estrutura é geral e extensível, portanto, qualquer modelo que possa ser mapeado para o esquema PIM geral comum pode ser adicionado
à estrutura. No entanto, os autores não consideram links intermodelos entre esquemas PSM, consultas entre modelos, nem as especificidades de
armazenamento de DBMSs multimodelos.
Darwin.O sistema de protótipo acadêmicodarwin[25,26] é um middleware de gerenciamento de esquema operacional que oferece suporte a vários
armazenamentos de dados NoSQL (como MongoDB, Couchbase, Cassandra e ArangoDB). Entre as principais características dodarwin, além de extrair
um resumo do esquema de uma instância de dados NoSQL, os usuários podem derivar a série histórica de versões do esquema e declarar
semiautomaticamente as alterações entre dois esquemas consecutivos.
MigCastName[27,28] se estendedarwincom um consultor para avaliar diferentes estratégias de migração de dados com seus custos (como custos
monetários para operar na nuvem ou sobrecarga esperada nos tempos de acesso).
3. A abordagem proposta
Em nossa abordagem proposta, focamos nas limitações das soluções existentes. Neste trabalho apresentamosMM-evolver, nossa solução
que trata dos aspectos centrais. A seguir, construiremos em torno desse núcleo um sistema de gerenciamento de evolução completo para
MM DBMSs.
Em geral, para o suporte de modelos em um único SGBD, existem duas abordagens principais:
∙ motor complexo: O DBMS transforma todos os tipos de dados suportados em um modelo de núcleo único. Seu motor precisa pré-processar e mapear um
ll operações ao modelo central. ectura: O
∙ Camada - arquiteto baseado modelo de suprimento DBMS modelos orts via diferente t camadas em cima de um motor. Os dados são armazenados no respectivo
mmodelo , enquanto eac tem um dedicado componentes qual com se comunica com o motor.
4embora h ouprojetado originalmente para XM L dados, pode ser adaptado para documentos JSON como bem.
4
Figura 3.Arquitetura de um SGBD MM baseado em camadas.
Nós nos concentramos na arquitetura baseada em camadas, que é usada em uma parte significativa dos SGBDs MM existentes. Não vemos necessidade de introduzir uma
abordagem genérica para mecanismos complexos específicos, pois eles geralmente mapeiam internamente todos os modelos suportados para um único modelo. Portanto, eles
precisam resolver a evolução do esquema nesse modelo único e, além disso, usar a lógica de transformação para dar suporte aos modelos necessários. Fig. 3mostra duas camadas
principais da abordagem baseada em camadas inspirada nos princípios do MDA:específico do modeloemodelo independente
. Para simplificar, assumimos que os dados nos modelos individuais possuem um esquema. No entanto, esse esquema não precisa ser explicitamente
declarado. Pode ser uma estrutura acordada informalmente, como costuma ser usado na prática. Os motores na camada específica do modelo podem,
portanto, diferir também em relação a este aspecto.
OMecanismo MM DBMSestá localizado na camada independente do modelo. É uma fachada para funções do banco de dados (principalmente
consultas) e distribui consultas e comandos para os respectivos modelos individuais; então coleta dados deles e cria o resultado final para o usuário.
Nosso objetivo é uma solução geral para a evolução do esquema em SGBDs MM e os seguintes modelos como os representantes mais comuns:
(1) relacional, (2) coluna, (3) gráfico, (4) chave/valor e (5) documento (ou seja, JSON ou XML). Pelo termo genéricotipo, nos referimos a um rótulo abstrato
que descreve ou agrupa registros relacionados. No modelo relacional, isso corresponde a uma tabela. Alguns fornecedores de MM DBMS usam os
termosaula(como em OrientDB5) oucoleção(como em ArangoDB6).
3.1. Linguagem de evolução de esquema multimodelo (MM SEL)
Para expressar mudanças de esquema, primeiro introduzimos oLinguagem de evolução de esquema multimodelo(MM SEL) que é executado na
camada independente do modelo, ou seja, a camada mais abstrata. Nós estendemos o trabalho de [9], onde oLinguagem de Evolução do Esquema
NoSQL (NoSQL SEL) abrange os bancos de dados NoSQL de coluna e documentos orientados a agregação.7Envolve três operações básicas que afetam
todas as entidades de um determinado tipo para (1)adicionar(introduzindo uma nova propriedade com um valor padrão especificado), (2)excluir(remover
uma propriedade) e (3)renomear(alterar o nome de uma propriedade). Além disso, envolve operações para (4)mover(remover uma propriedade de um
tipo de entidade e adicioná-la a outro), e (5)cópia de(copiar uma propriedade de um tipo de entidade para outro).
O mecanismo MM DBMS deve distinguir quais modelos são afetados por uma determinada operação e propagar as operações para eles.
Podemos dividir as operações em dois grupos distintos:
∙ Intra-modelooperações (ou seja,adicionar) afetam apenas um modelo.

∙ Inter-modelooperações (ou seja,cópia de,mover,excluirerenomear) pode afetar vários modelos.8Os dois primeiros também podem acionar a transferência de
dados entre umfontee umalvomodelo; os três últimos9pode desencadear alterações em outros modelos, devido a referências que precisam ser atualizadas
adequadamente.
Fig. 4mostra a gramática Extended Backus–Naur Form (EBNF) para a sintaxe MM SEL. Os modelos de propriedade (meu nome), os tipos de
propriedade (kname) e os nomes das propriedades (pname) são terminais da gramática. Se compararmos o MM SEL com o NoSQL SEL original,
estendemos sua lógica com o identificador de modelo para distinguir o modelo de destino e um nome de propriedade opcional, porque nem todos os
modelos suportam propriedades (como, por exemplo, o modelo chave/valor).10Em geral, queremos manter o idioma o mais semelhante possível ao
idioma original para facilitar o aprendizado.
5 https://orientdb.com/. https://
6 www.arangodb.com/.
7 Os sistemas orientados a agregação de chave/valor não são considerados no documento.
8 Mas eles podem ser restritos apenas ao modelo interno, como estão nos DBMSs MM existentes. Não
9 assumimos que as referências também sejam copiadas.
10 Observe que no papel de visão [13] propomos também a sua extensão.
5
Figura 4.Sintaxe EBNF de MM SEL.
Figura 5.Diagrama de interação:adicionar,excluir,renomear.
Fig. 5mostra um diagrama de atividades da operação de processamentoadicionar. No diagrama, podemos ver a operaçãoadicionarsolicitado por um
cliente. A solicitação é tratada pelo mecanismo MM DBMS e delegada ao modelo específico. Em caso de operaçãoadicionarele não pode acionar
nenhuma outra operação.Fig. 5também descreve um diagrama de atividades quando o mecanismo MM DBMS recebe a operaçãoexcluirourenomearde
um cliente e o delega a um modelo de origem específico. Essas operações podem acionar alterações de referência em vários modelos de destino. Essas
alterações são tratadas pelo mecanismo MM DBMS.Fig. 6descreve um diagrama de atividades quando o mecanismo MM DBMS recebe a operação mover
oucópia dede um cliente. A operação é delegada a um modelo de origem específico que contém os dados originais. Os dados são carregados no
mecanismo MM DBMS. O mecanismo MM DBMS os envia para o modelo de destino específico (que pode ser o mesmo que o modelo de origem). Ambas
as operações também podem acionar alterações de referência que são tratadas pelo mecanismo MM DBMS.
As operações intra-modelo, bem como as operações inter-modelo que afetam um único modelo, são propagadas pelo mecanismo MM DBMS para
o(s) modelo(s) de destino específico(s) que já é(são) capaz(es) de garantir o processamento de dados correto.11Quando as entidades devem ser
transferidas entre os modelos (ou seja, copiadas ou movidas), o mecanismo MM DBMS obtém todas as entidades do tipo fornecido do modelo de origem
e as insere no modelo de destino. Em caso de operaçãomover, ele deve excluí-los do modelo de origem. Ele também é capaz de rastrear todas as
referências entre modelos. Quando o mecanismo MM DBMS detecta uma alteração em uma entidade referenciada, ele propaga essas alterações para a
entidade de referência.
O problema da evolução da referência torna a evolução do esquema mais complexa. A seguir, apresentamos uma solução para a evolução
do esquema em SGBDs MM sem levar em conta as referências. Em seguida, nós o estendemos com referências. Observe que a consequência
dessa explicação em duas fases (ou seja, sem e com referências) é que as operaçõesrenomeareexcluirsão intra-modelo
na primeira fase.
3.2. Implementação básica do MM SEL
Como mencionado acima, o MM SEL é avaliado na camada independente do modelo, dentro de um mecanismo MM DBMS. O motor tem que ser
capaz de distinguir entre os modelos. Para distinguir entre os modelos, introduzimos oconjunto de modelos de dadosDMS ∕ ={ , ,a
, ℎ, } e umchave modelo : ∈DMS. Para criar um modelo abstrato de um MM DBMS, seguimos notação de [9]
11Assumimos a reutilização de abordagens de propagação de mudança de modelo único existentes e focamos no novo problema de mudança de modelo múltiplo e propagação.
6
Figura 6.Diagrama de interação:mover,cópia de.
Figura 7.Os comandos para interface com o banco de dados multimodelo.
que usa o termoestado do aplicativopara o estado atual do espaço do aplicativo. É uma aplicação não persistente estadoé o na memória.Base de dados
estado atual do banco de dados e representa todos os dados armazenados.
EmFig. 7introduzimos um conjunto modificado de funções chamadoLinguagem de programação de banco de dados DBPL) que se estende
multimodelo(MM o originalLinguagem de programação de banco de dados NoSQL[9]. Como podemos ver, a funçãovazionão e aplicativo ou locação, e
modifica o espaço do banco de dados. FunçõesaddModel,putModel,deleteModel, egetModelpermite criar, armazenar no DMS, o obter um gic permanece.
modelo do DMS para o estado do aplicativo. As restantes operações são estendidas com o DMS, mas criam uma nova entidade Pudermos propriedade,
(funçãonovo). Podemos definir, remover ou recuperar propriedades de uma entidade (funçõessetPro eobterPropriedade). Ou removeProperty, eleger, e
podemos armazenar, excluir our recuperar uma entidade de/para o armazenamento persistente (funçõescolocar,d pegar). asse e para salvá-
A principal diferença, em comparação com a origemeu linguagem nal, está em operações para obter entidades do datab no los
banco de dados. Regra11ampliars função ( , )por parâmetro para distinguir onde a entidade com o objetivo principal que está armazenado. Para
introduzimos funciona ( )que retorna um modelo onde a entidade ocorre. Usamos esse modelo de abordagem em todas as isso detectar os afetados é
funções modificadas. Em regra12nós estendemos a função ( , )por chave do modelo Que contêm a entidade com chave
7
. Regras13,14, e15adicionar parâmetro funcionar . Todas as funções modificadas carregar entidade/entidades do modelo especificado por chave para
o espaço de aplicação. Regra16também é estendido pela chave modelo para carregar a propriedade do modelo especificado.
Tendo introduzido o MM DBPL, podemos nos concentrar na implementação das funções MM SEL deFig. 4. Algoritmo1retrata a implementação de
operaçõesadicionar,excluirerenomear. Todas as operações encontram o modelo correto, iteram por todas as entidades do tipo fornecido em modelo
qual consulta de correspondência , execute a modificação solicitada, incremente a propriedadeversãopara todos os elementos afetados e armazene-os
de volta no banco de dados. Operaçãoadicionarinsere propriedade com valor às entidades alvo; Operaçãoexcluirremove deles a propriedade 1. Operação
renomearcria uma nova propriedade 2com valor de imóvel 1.
Algoritmo2define uma implementação de operações entre modelosmoverecópia de. Ambas as operações verificam a existência de modelos 1e 2. Em
seguida, eles obtêm o valor da propriedade 1para todos os elementos de tipo 1em modelo 1qual consulta de correspondência 1. O valor é definido como
propriedade 1de elementos de tipo 2em modelo 2qual consulta de correspondência 2. Propriedadeversãode é incrementado e os elementos são
armazenados. Operaçãomovertambém remove propriedade 1de elementos afetados e incrementa sua propriedadeversão.
Algoritmo 1:MM SEL:adicionar,excluir,renomear Algoritmo 2:MM SEL:mover,cópia de

Deixar seja um nome de modelo, deixe seja gentil, deixe , 1, 2sejam nomes de Deixar 1, 2sejam nomes de modelo, deixe 1, 2seja gentil, deixe 1seja um
propriedade, e deixe ser um valor de propriedade de . é uma consulta conjunta nome de propriedade e deixe ser um valor de propriedade de . 1, 2são
sobre propriedades. consultas conjuntivas sobre propriedades onde 1tem átomos da forma 1. 1
. 1= , onde 1é um nome de propriedade e é um valor de . 2tem átomos da
forma 2. 2. 2= ou 1. 1. = 2. 2. , onde , e 2são nomes de propriedade.
adicionar . [. ] = onde
segetModel( )≠⟂então
para cadaelemento de ( , = ∧ )fazer
definirPropriedade( , , ); mover 1. 1. 1para 2. 2onde 1∧ 2
definirPropriedade( , , obterPropriedade( , ) + 1); se(getModel( 1)≠⟂)∧ (getModel( 2)≠⟂)então
colocar( , ); para cadaelemento de ( 1, = 1∧ 1)fazer
para cadaelemento de ( 2, = 2∧ 2)fazer
definirPropriedade( , 1, obterPropriedade( , 1));
excluir . . 1onde
definirPropriedade( , , obterPropriedade( , ) + 1); colocar( 2
segetModel( )≠⟂então , );
definirPropriedade( , , obterPropriedade( , ) + 1);
removeProperty( , 1);
removeProperty( , 1); colocar( 1, );
colocar( , );
cópia de 1. 1. 1para 2. 2onde 1∧ 2

renomear . . 1para 2onde
se(getModel( 1)≠⟂)∧ (getModel( 2)≠⟂)então
segetModel( )≠⟂então
, );
colocar( , );
Apresentamos a ideia por trás de cada algoritmo usando um exemplo.Fig. 8mostra o estado inicial dos dados de amostra.
Exemplo 3.1.Operaçãoadd document.tea.importer = ''Tea_Comp.''adiciona nova propriedadeimportadora todas as entidadeschá.

Esperamos que o resultado seja o novo imóvel com valor ''Chá_Comp.'' e propriedade incrementadaversão. Essa operação é intramodelo,
portanto, é executada dentro de um modelo usando uma sintaxe de banco de dados. O exemplo da sintaxe do comando é mostrado emFig. 9.
À primeira vista, podemos perceber que a operação manual é mais complexa que a operação MM SEL e requer o conhecimento da linguagem
específica do MongoDB. (O resultado da operação é visualizado emFig. 20emApêndice A.)
Exemplo 3.2.Operaçãoadicionar relacional.users.canDeliver = verdadeiro onde relacional.users.address = nulo

adiciona nova propriedadepodeEntregarcom valor ''verdadeiro'' para entidades do modelo relacional que atendem a condição WHERE e
aumenta a propriedadeversão. Novamente, esta é uma operação intra-modelo que afeta apenas o modelo relacional. A operação manual
pode ser vista emFig. 10. Como podemos ver, a existência de propriedadeversãotorna a implementação mais complexa, mas geralmente é
necessária em um ambiente corporativo. A solução manual consiste em quatro comandos SQL em vez de um comando no MM SEL. Isso
também significa que o desenvolvedor deve garantir que seja executado em uma única transação. (O resultado da operação é visualizado em
Fig. 23 emApêndice A.)
Exemplo 3.3.Operaçãoexcluir document.tea.countryremove propriedadepaísde todas as entidades do tipochá. Propriedade

versãoé incrementado. As diferenças entre a abordagem manual e o MM SEL são análogas ao caso da operaçãoadicionar. A
implementação manual é apresentada emFig. 11. (Fig. 21emApêndice Amostra o resultado.)
Exemplo 3.4.Operaçãorenomear relacional.users.name para fullnamerenomeia a propriedadenomede entidadeUsuáriosparanome

completo. Mais uma vez, propriedadeversãoé incrementado. O comando SQL emFig. 12representa a migração manual. O comando manual é
simples e muito semelhante ao comando add. Toda a lógica está oculta no comando SQL ALTER TABLE. (Fig. 24em Apêndice Amostra o
resultado da operação.)
8
Figura 8.O exemplo de aplicativo multimodelo de uma loja virtual.
Figura 9.O código que adiciona uma nova propriedadeimportadora todas as entidadescháno modelo de documento (MongoDB).
Figura 10.O código que adiciona uma nova propriedadepodeEntregara todas as entidadesUsuáriosno modelo relacional (MariaDB).
Figura 11.O código que remove a propriedadepaísde tudocháentidades no modelo de documento (MongoDB).
Além disso, vamos considerar o caso em que adicionamos condiçãoWHERE relacional.users.name = ''Peter Parker''. No mundo
relacional, não podemos simplesmente alterar a tabela porque queremos preservar alguns dados na coluna original. O comando de migração
manual pode agora ser visto emFig. 13. Após a execução desta operação, ambas as colunasnomeenome completocoexiste. A simples
mudança de adicionar uma condição WHERE torna o manualeu comando mais difícil. MM SEL esconde essa lógica extra e o desenvolvedor
não precisa lidar com isso.
Exemplo 3.5.Operaçãocopie keyValue.appVersion para document.teacopia a propriedadeappVersionda chave/valor

modelopara todoscháentidades no documento mo del. Mais uma vez, propriedadeversãoé incrementado. (O resultado é mostrado emFig. 22em
9
Figura 12.O código que renomeia a propriedadenomeparanome completopara todosUsuáriosentidades no modelo relacional (MariaDB).
Figura 13.O código que renomeia a propriedadenomeparanome completopara selecionadoUsuáriosentidades, selecionadas por uma condição WHERE no modelo relacional (MariaDB).
Apêndice A.) A operação é intermodelo, o que significa que o transporte de dados é feito pelo mecanismo MM DBMS. Para mostrar a migração manual
não podemos introduzir código como fizemos para as operações intra-modelo, pois precisamos de um mediador que transforme os dados entre os
modelos. (Este fato mostra um dos benefícios do MM SEL.) Portanto, o esforço manual é expresso usando pseudo-código no Algoritmo3. As operações
para obter e definir entidades requerem conhecimento de ambos os modelos afetados.
Exemplo 3.6.Operaçãomover keyValue.seller para document.tearemove propriedadevendedordo modelo de chave/valor e o move para todos
cháentidades no modelo de documento. É uma operação entre modelos, portanto, há a mesma limitação discutida no caso de operaçãocópia de. Para a
ideia por trás da migração manual, nos referimos ao Algoritmo4. O algoritmo copia a propriedade para todas as entidades de destino e a exclui quando
copiada. (Fig. 26emApêndice Amostra o resultado.)
Algoritmo 3:Copiar propriedadeappVersiondo modelo de chave/ Algoritmo 4:Mover propriedadevendedordo modelo de

valor para o modelo de documento chave/valor para o modelo de documento
lerappVersionpropriedade do modelo chave/valor; se lervendedorpropriedade do modelo chave/valor; se
propriedade existeentão propriedade existeentão
para cadachá de entidade no modelo de documentofazer para cadachá de entidade no modelo de documentofazer
obter a próxima entidade; obter a próxima entidade;
adicionar propriedadeappVersionà entidade; adicionar propriedadevendedorà entidade;
incrementar a propriedadeversão; armazenar a incrementar a propriedadeversão;
entidade; armazenar a entidade;
removervendedordo modelo chave/valor;
3.3. Implementação otimizada do MM SEL
Mostramos a implementação mais óbvia do MM SEL que é intuitivo, mas nem sempre eficiente. Nossa implementação poderia ser mais eficaz se
executássemos operações de evolução de esquema dentro de modelos específicos. A abordagem ingênua sempre carrega uma entidade no espaço do
aplicativo na camada independente do modelo, mesmo durante as operações intra-modelo. Para evitar isso, primeiro precisamos de uma interface
unificada para todos os modelos subjacentes.
3.3.1. Linguagem de evolução do esquema de banco de dados (DSEL)
Para fornecer uma solução geral independente do modelo, primeiro estabelecemos um conjunto comum de operações que podem ser suportadas por todos os
modelos. Em particular, na camada específica do modelo, introduzimos oLinguagem de Evolução do Esquema do Banco de Dados(DSEL) envolvendo, para simplificar,
as operações principaisadicionar,excluir,renomear,mover, ecópia de. Observe que, para nosso propósito, não fazemos a implementação mais eficiente das operações
em cada modelo. Nosso objetivo é mostrar que existe uma forma de garantir a interface comum para todos os modelos, ou seja, precisamos especificar a semântica
do DSEL de cada modelo de dados.12
Modelo de documento e coluna.Para os modelos de documento e coluna, podemos usar a definição pela implementação das respectivas operações para
a evolução do esquema NoSQL introduzida em [9].
12Nãoe que as operações precisam be atômico, mas por uma questão de simplicidade, omitimos a garantia específica desse recurso em p modelos articulares em seus
descriçãosobre.
10
Modelo gráfico.Para o modelo de grafos podemos usar a estratégia comum à maioria dos SGBDs MM existentes [15], ou seja, uma unificação dos modelos. Podemos,
por exemplo, tratar o modelo de gráfico como ArangoDB. É originalmente um armazenamento de documentos que foi estendido com o modelo gráfico. Os nós do
grafo correspondem aos documentos. As arestas são armazenadas em coleções especiais de documentos de arestas que contêm informações sobre as arestas que
conectam dois nós, ou seja, documentos.
Modelo chave/valor.No modelo de chave/valor não temos nenhuma propriedade como no modelo de documento. Podemos visualizar cada par chave/
valor como uma entidade que possui uma chave e um único valor, não atribuído a nenhuma propriedade específica. Algoritmo5define o comportamento
das operações para o modelo chave/valor. Operaçãoadicionarprimeiro cria uma nova entidade com a chave fornecida 1e valor em um espaço de
aplicação. Na segunda etapa, a entidade criada é armazenada no banco de dados. Operaçãoexcluirexclui uma entidade pela chave fornecida 1do banco
de dados. Operaçãorenomearcria uma nova entidade com a chave dada 2e um valor de entidade 1no espaço de aplicação. Em seguida, a entidade é
armazenada no banco de dados e a entidade original é excluída. Escolhemos essa abordagem porque podemos adicionar e remover a entidade em
todos os bancos de dados de chave/valor, enquanto renomear a chave de uma entidade nem sempre é suportado.
Algoritmo 5:Chave/valor DSEL:adicionar,excluir,renomear Algoritmo 6:Chave/valor DSEL:mover,cópia de

Deixar 1, 2seja gentil e um valor de . Deixar 1, 2seja gentil e um valor de .
adicionar 1= mover 1para 2

novo( 1, ); vazio();
colocar( 1);
cópia de 1para 2
excluir 1 novo( 2, pegar( 1));
excluir( 1); colocar( 2);
renomear 1para 2
novo( 2, pegar( 1));

colocar( 2);
excluir( 1);
A próxima consequência de propriedades ausentes é que o modelo de chave/valor não oferece suporte à operaçãomover. Decidimos
excluir a operação, pois não podemos defini-la adequadamente sem o suporte de propriedades no modelo. Pode ser definido da mesma
forma que a operaçãorenomear, mas não queremos ter duas operações com a mesma semântica. Por esta razão, a operaçãomoverno
modelo de chave/valor não modifica o espaço do aplicativo ou mesmo o estado do banco de dados. No Algoritmo6Operaçãomoverapenas
chama a operaçãovazio. Operaçãocópia decria uma nova entidade com a chave dada 2e valor da entidade 1, então a entidade é colocada no
banco de dados.
Modelo relacional.As operações para o modelo relacional podem ser facilmente implementadas usando comandos SQL ALTER TABLE padrão:
∙ Operaçãoadicionar entidade.propriedadeadiciona colunapropriedadepara mesaentidade.
ALTERAR A TABELAentidadeADICIONARpropriedade ;
∙ Operaçãoexcluir entidade.propriedaderemove colunapropriedadeda mesaentidade.

ALTERAR A TABELAentidadeDERRUBARpropriedade ;
∙ Operaçãorenomear entidade. 1para 2renomeia a coluna 1para 2na tabelaentidade.

ALTERAR A TABELAentidadeMUDARpropriedade1propriedade2;
∙ Operaçãocópia de 1.propriedade para 2.propriedadecoluna de cópiaspropriedadeda mesa 1para 2como uma sequência de comandos:
ALTERAR A TABELAentidade2ADICIONARpropriedade ;
ATUALIZARentidade2
DEFINIRpropriedade = (SELECIONEpropriedadeDEentidade1ONDEentidade1.id = entidade2.eu ia ) ;
∙ Operaçãomover entity1.property para entity2.propertycoluna de cópiaspropriedadeda mesaentidade1paraentidade2e exclui a coluna

propriedadeda mesaentidade1:
ALTERAR A TABELAentidade2ADICIONARpropriedade ;
ATUALIZARentidade2
DEFINIRpropriedade = (SELECIONEpropriedadeDEentidade1ONDEentidade1.id = entidade2.eu ia ) ; ALTERAR A
TABELAentidade1DERRUBARpropriedade ;
3.3.2. Mudanças entre modelos x intramodelos

Como podemos implementar DSEL para todos os modelos, podemos executar migrações intra-modelo dentro de um modelo específico. Também podemos
otimizar a execução de potenciais operações inter-modelos. Por exemplo, quando as operaçõesmoveroucópia demigrar dados dentro do mesmo modelo, podemos
chamar a respectiva operação de migração dentro do modelo específico.
11
No Algoritmo7, otimizamos as operações intra-modeloadicionareexcluire operação entre modelosmover. As operações intra-

modelo verificam a existência do modelo 1e se existir, delegam a operação ao modelo específico 1. O algoritmo também otimiza a
operaçãomoverque verifica a existência de ambos os modelos afetados 1e 2: Se modelo 1é igual a 2, a operação é delegada ao
modelo específico, caso contrário, executa a mesma lógica do Algoritmo2.
No Algoritmo8mostramos a operação intra-modelo otimizadarenomeare operação entre modeloscópia de. As operações seguem
a mesma lógica de antes. No caso de operação intra-modelo, verifica a existência de modelo 1e se o modelo existir, delega a
operação ao modelo específico. As operações entre modelos verificam a existência de modelos 1e 2e então, se forem iguais, delega a
operaçãocópia deao modelo específico. Se não forem iguais, a lógica não otimizada é executada.
Algoritmo 7:SEL MM otimizado:adicionar,excluir,mover Algoritmo 8:SEL MM otimizado:renomear,cópia de

Deixar 1, 2sejam nomes de modelo, deixe 1, 2seja gentil, deixe 1seja um Deixar 1, 2sejam nomes de modelo, deixe 1, 2seja gentil, deixe 1seja um
nome de propriedade e deixe ser um valor de propriedade de . 1, 2são nome de propriedade e deixe ser um valor de propriedade de . 1, 2são
consultas conjuntivas sobre propriedades onde 1tem átomos da forma 1. 1 consultas conjuntivas sobre propriedades onde 1tem átomos da forma 1. 1
. 1= , onde 1é um nome de propriedade e é um valor de . 2tem átomos da . 1= , onde 1é um nome de propriedade e é um valor de . 2tem átomos da
forma 2. 2. 2= ou 1. 1. = 2. 2. , onde , e 2são nomes de propriedade. forma 2. 2. 2= ou 1. 1. = 2. 2. , onde , e 2são nomes de propriedade.
adicionar 1. 1[. 1] = onde 1 renomear 1. 1. 1para 2onde 1

segetModel( 1)≠⟂então segetModel( 1)≠⟂então
1.executar(adicionar 1[. 1] = onde 1); 1.executar(renomear 1. 1para 2onde 1);
excluir 1. 1. 1onde 1 cópia de 1. 1. 1para 2. 2onde 1∧ 2

segetModel( 1)≠⟂então se(getModel( 1)≠⟂)∧ (getModel( 2)≠⟂)então
1.executar(excluir 1. 1onde 1); se 1= 2então
1.executar(cópia de 1. 1para 2onde 1∧ 2);
mover 1. 1. 1para 2. 2onde 1∧ 2 outro

se 1= 2então
1.executar(mover 1. 1para 2onde 1∧ 2);
definirPropriedade
outro
(, , obterPropriedade( , ) + 1);
colocar( 1, );
definirPropriedade
(, , obterPropriedade( , ) + 1);
colocar( 2, );
3.4. Evolução das referências
As operações de MM SEL introduzidas até agora ignoram possíveis referências no MM DBMS. Embora os sistemas NoSQL geralmente não ofereçam suporte à
integridade referencial, para outros sistemas, como relacionais ou de documentos (XML), é um recurso fundamental. Em seguida, discutiremos como a integridade
referencial é mantida à medida que as operações de modificação do esquema são executadas.13
Existem várias maneiras de entender a noção de referência. Na primeira versão de nossa solução, consideramos a referência simplesmente como um ponteiro de
uma propriedade de uma entidade referenciada para uma propriedade de uma entidade referenciada. Descrevemos a fonte ou o alvo de uma referência por um
triplo(modelo, entidade, propriedade). Uma referência é então representada como um par ( , )e assumimos que pelo menos um modelo é capaz de armazenar
os pares em umespaço de referência.
Relativamente às referências podemos dividir as operações apoiadas em dois grupos:Segurooperações (ou seja,adicionarecópia de) não aciona nenhuma
atualização de referência. Ambos criam novas propriedades que não são referenciadas.Insegurooperações (ou seja,excluir,renomear, e mover) pode acionar
atualizações de referência. Eles modificam uma propriedade possivelmente referenciada.
Propomos uma solução no MM SEL, ou seja, na camada independente do modelo, para todas as referências que são alteradas no mesmo
ou em outro modelo específico. Para evitar extensões complexas e, em vez disso, permanecer dentro da estrutura MM DBPL já definida,
representamos internamente uma referência como um tipo especial de entidade. Ele tem três propriedades: (1) a propriedade referenciada
da entidade, (2) a chave da propriedade no MM DBMS e (3) uma matriz de triplos descrevendo entidades que a referenciam. Cada triplo na
matriz consiste em três propriedades: um modelo, um tipo e uma propriedade. EmFig. 14definimos uma extensão de MM SEL que nos
permite registrar uma referência em um sistema. Operaçãoreferência 1por 2registra uma referência de 2para 1.
Observe que, por padrão, as referências podem nos permitir criar uma cadeia de referências. Por uma questão de simplicidade, nós os proibimos,
porque em vez da cadeia, o desenvolvedor pode usar uma referência direta à propriedade source. Durante a análise da migração de referência,
13Observe que o idioma original NoSQL SEL também não considera referências, porque a maioria dos bancos de dados NoSQL não as suporta. Manter a integridade referencial é,
portanto, outra nova contribuição deMM-evolver.
12
Figura 14.Extensão da sintaxe MM SEL em EBNF com referências.
Figura 15.Comandos dedicados para manipular referências no banco de dados multimodelo.
também descobrimos que as condições WHERE tornam a solução muito mais difícil. É causado pela natureza dos MM DBMSs que permitem que um
usuário mova um subconjunto das propriedades. Esse comportamento pode dividir, excluir ou mover completamente uma referência existente com
base no conjunto de valores afetado. Apresentamos uma solução para operações sem condições WHERE e a mantemos como um desafio aberto.
Outro ponto a ser discutido é o comportamento quando uma propriedade referenciada é removida. Temos duas opções do que pode acontecer com
a propriedade de referência: (1) definir um valor padrão ou (2) excluir a propriedade. Decidimos usar a segunda abordagem, porque é uma solução clara
para os modelos usados. (A primeira abordagem deve definir qual deve ser o comportamento quando um MM DBMS contém uma entidade sem uma
propriedade de referência, bem como valores padrão para todos os modelos. Além disso, o valor padrão pode ser considerado como um valor da
propriedade em um aplicativo , o que pode ser confuso.)
Exemplo 3.7.A sequência de operações:

referência document.tea.type por relacional.users.favTea;
excluir document.tea.type;
deve garantir que a entidade de referência também seja removida. Antes de executá-los, executamos a operação:
adicionar relacional.users.favTea = 1
para adicionar a respectiva coluna ao modelo relacional. Propriedadeversãoé alterado para1. Em seguida, executamos a operaçãoreferênciaprimeiro
e depois operaçãoexcluir. (Fig. 25emApêndice Amostra o estado resultante da entidade de referência.)
Para poder realizar essa migração manualmente sem o MM SEL, o desenvolvedor precisa saber qual propriedade faz referência à
propriedade afetada. No Algoritmo9, mostramos um pseudocódigo de alto nível dessa migração realizada manualmente. A complexidade do
algoritmo está escondida na primeira etapa que deve obter as informações sobre as referências no MM DBMS. A segunda complexidade
oculta é que as entidades podem ser armazenadas em modelos diferentes, de modo que o algoritmo precisa distingui-las.
Algoritmo 9:Excluir propriedade de referência

obter todas as entidades afetadas;
para cadaentidade afetadafazer
obter a próxima entidade;
remova a propriedade de referência;

incrementar a propriedadeversão;
armazenar a entidade;
A próxima etapa define operações para criar e gerenciar referências no MM DBPL. Precisamos ser capazes de criar uma referência,
. Usamos o RSM para
armazená-lo, removê-lo ou encontrá-lo. Deixarmodelo de loja de referênciaRSM ser uma loja que é capaz de per Entidades de
referência sist estendem o MM DBPL e definem funções que nos ajudam a implementar o gerenciamento de referência no MM EU.Fig. 15mostra o pe
SE extensão do MM DBPL que fornece funções para as operações mencionadas. Introduzimos referências especiais de ty que sãode entidades para as
armazenadas no RSM, mas trabalhamos com o tipo da mesma forma que com outras entradas de banco de dados idades.
Agora, podemos introduzir a nova operação MM SELreferênciae operações modificadasexcluir,renomear, e mover, ou seja, o inseguro
operações. Algoritmo10define operaçãoreferência. Ele verifica se o RSM já contém uma entidade para o re a entidade é propriedade ferenciada. Se
encontrada, a propriedade de referência é adicionada às fontes, caso contrário, a função cria uma nova entidade com ar
entidade de referência e
armazena as alterações no RSM. Algoritmo11define operaçãorenomearque executa a renomeação padrão e i no final corrige o
13
referências. Primeiro, ele tenta renomear todas as referências à propriedade renomeada porrenomearReferênciafunção. Em seguida, itera por todas as
referências referenciadas pela propriedade renomeada e corrige o novo nome da propriedade. Ao final da operação, todas as alterações são salvas no
RSM. Algoritmo12define operaçãoexcluirque exclui uma propriedade e, em seguida, itera por todas as propriedades que fazem referência à propriedade
removida e as remove. Quando todas as referências são removidas, também a entidade da referência é excluída. A última etapa é remover a própria
propriedade de todas as entidades de referência que são referenciadas por ela. Algoritmo13define operação moverque move uma propriedade para
uma nova entidade e então renomeia todas as referências para a nova. A última etapa é substituir o novo nome da entidade nas propriedades
referenciadas no RSM.
Algoritmo 10:MM SEL com referências:referência

Deixar 1, 2sejam nomes de modelo, deixe 1, 2seja gentil, deixe 1, 2ser nomes de propriedade.
referência 1. 1. 1por 2. 2. 2
se (( 1. 1, 1)) =⟂então
=novaReferência(( 1. 1, 1));
definirPropriedade( , "m", 1);
definirPropriedade( , "k", ( 1. 1, 1));
definirPropriedade( , "p", 1);
definirPropriedade( , "s", "[{"m": 2, "k": 2, "p": 2}]");
outro
=getReference(( 1. 1, 1));
definirPropriedade( , "s", getProperty( , "s").push ({"m": 2, "k": 2, "p": 2}));
putReference( );
Algoritmo 11:MM SEL com referências:renomear

Deixar 1seja um nome de modelo, deixe 1seja gentil, deixe 1, 2ser uma propriedade nomes.
renomear 1. 1. 1para 2
segetModel( 1)≠⟂então
para cadaelemento de ( 1, = 1)fazer
colocar( , );
renomearReferência(( 1. 1, 1),( 1. 1, 2)); para cada
elemento de ( 1, 1, 1)fazer
para cadaelemento de getProperty( , "s")fazer
segetProperty( , "m") = 1∧getProperty( , "k") = 1∧getProperty( , "p")= 1então
getProperty( , "s").delete ({"m": 1, "k": 1, "p": 1});
getProperty( , "s").push ({"m": 1, "k": 1, "p": 2});
putReference( );
3.5. Robustez do MM SEL
Por último, mas não por último, vamos mencionar que a implementação proposta do MM SEL também é robusta graças à propriedadeversão.
Podemos introduzir mecanismos de controle que podem recuperar o banco de dados em caso de falha. A recuperação retoma as migrações restantes
interrompidas anteriormente. A ideia da implementação é ter um log de ação persistente que contenha todas as operações de evolução executadas no
SGBD MM. O MM DBMS registra todos os eventos de início e término de migrações com a versão atual da entidade de migração. A inconsistência pode
acontecer quando o MM DBMS é interrompido durante a execução da migração (por exemplo, um desligamento do banco de dados). O MM DBMS
verifica se o log contém algum log inicial sem o final. Se o log for encontrado, podemos encontrar todas as entidades que não foram migradas usando
uma condição WHERE com um determinado valor de propriedadeversão. Se a versão for a mesma de quando o evento de início foi registrado, significa
que ainda não foi migrado.
4. Prova de conceito
Para nos ajudar a demonstrar e validar ainda mais a funcionalidade do MM SEL, implementamos uma ferramenta de protótipo chamada MM-evolver.
Para poder trabalhar no futuro com vários modelos, não apenas aqueles fornecidos por um determinado MM DBMS, emMM-evolver nós criamos um
abstratomodelo baseado em camada, onde cada modelo particular pode ser representado por um DBMS separado. Para testar também esta
funcionalidade, na primeira versão utilizamos o MongoDB14e MariaDB.15
14 https://www.mongodb.com/.
15 https://mariadb.org/.
14
Algoritmo 12:MM SEL com referências:excluir

Deixar 1seja um nome de modelo, deixe 1seja gentil, deixe 1ser um nome de propriedade.
excluir 1. 1. 1
segetModel( 1)≠⟂então
colocar( , );
=getReference(( 1. 1, 1)); se ≠
⟂então
para cadaelemento de get(getProperty( , "m"),obterPropriedade( , "k"))fazer
removeProperty( , obterPropriedade( , "p"));
put(getProperty( , "m"), );
deleteReference(( 1. 1, 1));
para cadaelemento de ( 1, 1, 1)fazer
segetProperty( , "m")= 1∧getProperty( , "k")= 1∧getProperty( ,"p")= 1então
getProperty( , "s").delete ( {"m": 1, "k": 1, "p": 1});
putReference( );
Algoritmo 13:MM SEL com referências:mover

Deixar 1, 2sejam nomes de modelo, deixe 1, 2seja gentil, deixe 1ser um nome de propriedade.
mover 1. 1. 1para 2. 2
definirPropriedade( , 1,obterPropriedade( , 1));
, );

renomearReferência(( 1. 1, 1),( 2. , 1)); para cada

elemento de ( 1, 1, 1)fazer
para cadaelemento de getProperty( , "fontes")fazer
segetProperty( , "m")= 1∧getProperty( , "k") = 1∧getProperty( , "p") = 1então
getProperty( , "s").delete({"m": 1, "k": 1, "p": 1});
getProperty( , "s").push({"m": 2, "k": 2, "p": 1});
putReference( );
MM-evolverimplementa o MM SEL com gerenciamento de referências e utiliza a versão otimizada das operações. A arquitetura do aplicativo pode ser
dividida em três camadas: (1) Acamada independente de modeloé o principal responsável pela análise da entrada do usuário, execução da operação de
evolução e comunicação com os modelos afetados. A entrada do usuário é analisada com um tokenizador que também é usado para validação da
entrada. A próxima função importante da camada é a distribuição das operações que ocorrem no mecanismo MM DBMS. O mecanismo distribui
comandos para os modelos específicos. (2) Ocamada específica do modelocontém adaptadores para cada modelo de dados. Em particular, um modelo
abstrato do MM DBMS é construído para chave/valor, documento e modelos relacionais. Cada um deles implementa a respectiva interface DSEL para
poder fornecer operações otimizadas. (3) Ocamada de banco de dadosrepresenta modelos de dados específicos que contêm os dados em evolução. No
nosso caso, a camada consiste no MongoDB representando o documento (e também o modelo chave/valor para simplificar a implementação). MariaDB
representa o modelo relacional.
4.1. Teste com dados do mundo real
Até agora, existem apenas benchmarks que simulam uma carga de trabalho de consulta em um MM DBMS [22,29,30], no entanto, o cenário é
restrito a um esquema estático. Embora as primeiras ideias para benchmarks de evolução de esquema dedicados tenham sido discutidas recentemente [
31,32], neste momento, não existe tal referência prontamente disponível.
15
Figura 16.Operações de modificação de esquema.
mesa 2
Total de entidades carregadas/afetadas no pior cenário, melhor cenário e usando MM SEL.
Op. Teste Entidades de destino Pior caso Melhor caso MM SEL
Carregado Afetado Carregado Afetado Carregado Afetado

entidades entidades entidades entidades entidades entidades
Q1 64.424.283 64.424.283 64.424.283 0 64.424.283 0 64.424.283

Q2 149.636 149.636 149.636 0 149.636 0 149.636
Q3 7.504.078 7.504.078 7.504.078 0 7.504.078 0 7.504.078
Intra-modelo
Q4 4.920.457 4.920.457 4.920.457 0 4.920.457 0 4.920.457
Q5 56.920.205 56.920.205 56.920.205 0 56.920.205 0 56.920.205
Q6 133.778 133.778 133.778 0 133.778 0 133.778
Q7 23.594.251 23.594.251 23.594.251 0 23.594.251 0 23.594.251

+ 458.107
Inter-modelo Q8 4.169.190 4.169.190 4.169.190 0 4.169.190 0 4.169.190

+ 2.835.862 + 2.835.862 + 2.835.862 + 2.835.862
Q9 16 8.534.771 16 8.534.771 16 8.534.771 16
+ 64.424.283 + 64.424.283 + 64.424.283
Q10 2 8.534.771 8.534.771 8.534.771 8.534.771 8.534.771 8.534.771
+ 6.693.529 + 6.693.529 + 6.693.529
Q11a 8.534.771 8.534.771 8.534.771 0 8.534.771 0 8.534.771
+ 6.693.529b + 6.693.529 + 6.693.529 + 6.693.529 + 6.693.529
aNúmeros da última operação de exclusão.

bEntidades que fazem referência à propriedade excluída. As propriedades de referência são excluídas durante a operação.
Para efeitos dos testes, recorremos, portanto, a um conjunto de dados bem conhecido - oBanco de Dados de Filmes da Internet(IMDb) [10]. Os dados
que usamos estão disponíveis para o modelo relacional [33] e para o modelo de documento [34] então nosso MM DBMS abstrato para os testes do
mundo real contém esses dois modelos.16As operações executadas estão listadas emFig. 16.
Dividimos os testes do mundo real em duas categorias: intramodelo (Teste Q1–Q7) e (potencialmente) intermodelo (Teste Q8–Q11). Em
Além disso, o Teste Q11 trabalha com referências. Mudamos gradativamente o estado do banco de dados (de acordo com as ideias propostas em [31]), em vez de
de usar uma nova instância do banco de dados be antes de cada operação, para que possamos simular o dema contínuo do mundo real, nds. Para cada teste, nós
também mencione o número de entidades afetadas (ou seja, o número de entidades que são alteradas durante a execução e o número de ção de uma operação)
entidades de destino( ou seja, o número de entidades que correspondem ao pedido de alteração).
Nossa métrica na avaliação das operações de teste é o número de entidades afetadas, o queeu l contraste com o cenário de o pior teórico
melhor casoio s. Emmesa 2, as duas últimas colunas listam o número de entidades afetadas para cada teste, operando as outras íon. (Vamos discutir
colunas ao resumir nossas observações.)
16Detalhes técnicos do acervo de dadoseu ção pode ser encontrada em [35].
16
Figura 17.Exclui propriedadeFunçãoIdadede todas as entidadesMovieRoleno modelo de documento.
4.1.1. Operações intra-modelo

As operações intra-modelo sãoadicionar,excluir, erenomear. Optamos por executar uma operação de cada tipo para ambos os modelos simulando
demandas do mundo real.
Teste Q1.A primeira demanda é adicionar uma nova propriedadeFunçãoIdadea todas as entidadesMovieRolecom valor padrão ''desconhecido
''. (Fig. 27em Apêndice Bmostra exemplos de entidades antes e depois da execução da operação.) A operação afeta 64.424.283 entidades.
Como a implementação do MM SEL é rápida, modificamos todas as entidades de uma só vez, o que leva alguns minutos.
Teste Q2.O próximo possível requisito do mundo real é preparar o banco de dados para países restritos na tabelatitle_basicscom base na
propriedadeé adulto. O valor será preenchido pelos usuários do aplicativo para que possamos escolher um valor padrão. A operação define a
propriedade país_restriçãocom valor ''nulo'' para 149.636 entidades, onde a propriedadeé adultotem valor1e propriedadeversãoEstá
adicionado. Na verdade, o valor nulo é definido para todas as propriedades, porque também é um valor padrão para uma coluna adicionada
no modelo relacional. (Fig. 28em Apêndice Bmostra exemplos de entidades antes e depois da execução da operação.) Assim, a quantidade
real de entidades afetadas é de 4.920.457. No entanto, os desenvolvedores não precisam saber disso e não precisam, porque é tratado pelo
MM SEL. (A migração manual usaria a mesma ideia que mostramos emFig. 10.)
Teste Q3.Seguindo o requisito anterior para o modelo de documento, recebemos uma solicitação de alteração para remover a propriedade
FunçãoIdade, ondeClasseContribé variado. O teste Q3 exclui a propriedade de todas as entidadesMovieRole, onde a condição é atendida e a
versão da entidade é1. (Fig. 29emApêndice Bapresenta um exemplo de entidade migradaMovieRolee uma entidade que não corresponde à
condição WHERE.) As entidades são migradas e a propriedadeversãoé aumentada apenas para as entidades afetadas. Observe que agora as
entidades coexistem com dois valores diferentes de propriedadeversão.
A operação exclui a propriedade de 7.504.078 entidades e incrementa a versão. Um código de amostra da migração manual
correspondente é mostrado emFig. 17. Graças aMM-evolver, não precisamos do conhecimento da linguagem de consulta MongoDB usada e
não precisamos gerenciar propriedadeversão.
Teste Q4.A propriedade adicionadacountry_restictionnão foi usado, então recebemos uma solicitação para removê-lo de todas as entidades.
Adicionamos a propriedade apenas a entidades onde a propriedadeé adultoé1, mas não há necessidade de especificar esta condição na
operaçãoexcluir. A migração manual será semelhante à que mostramos emFig. 11. A operação remove a colunapaís_restriçãoda tabela e
muda de propriedadeversãopara2. (O resultado da operação é exibido emFig. 31emApêndice B.) Da perspectiva do aplicativo, removemos a
propriedade de todas as 4.920.457 entidades.
Teste Q5.O próximo teste pode acontecer durante a refatoração de dados — o nome da propriedadeFunçãoIdadenão é autodescritivo, por
isso queremos alterá-lo paraAgeofRole. Nos exemplos anteriores introduzimos o campo para todas as entidadesMovieRolee então nós o
removemos de entidades ondeContribClass = ''diversos''. Temos que removê-lo de todas as entidades ondeContribClass !=
''diversos''mas MM SEL não suporta o operador de desigualdade. No entanto, podemos executar o Teste Q5 com a propriedade versãoigual
a1; o resto das entidades têm propriedadeversãoigual a2e não contêm a propriedade.
A migração manual não será muito diferente da mostrada emFig. 12. (Fig. 30emApêndice Bmostra um exemplo de entidades migradas,
diversas e não diversas. A primeira entidade não contém a propriedade alteradaFunçãoIdadee a propriedadeversãoestá inalterado. A
segunda entidade tem propriedadeFunçãoIdademudou paraAgeOfRolee a versão incrementada para2.) O valor da propriedadeversãoé o
mesmo em todas as entidadesMovieRoleagora, então todas as operações a seguir podem usar a propriedadeversãopara uma execução
segura. A operação modificou todas as 56.920.205 entidades alvo.
Teste Q6.O próximo teste simula um requisito para renomear um subconjunto de entidades no modelo relacional; para filmes cujo gênero é ''Adulto'',
renomeamos a propriedadeé adultoparaé restritopara torná-lo mais significativo. O teste Q6 renomeia a propriedade para todos os filmes com o gênero
''Adulto'' e com a versão mais recente.17
A migração manual será semelhante à que mostramos na prova de conceito (consulteFig. 13). A operação renomeou a propriedade para
133.778 entidades. (EmFig. 32emApêndice B, mostramos um exemplo de entidadesAdultoeComédia. Podemos ver uma nova coluna é restrito
que tem valor apenas para entidadesAdulto; eles não têm um valor na colunaé adultoe eles têm uma propriedade incrementadaversão.)
17Observe que no banco de dados, também podemos encontrar filmes com o gênero ''Adulto.Comédia'' que ignoramos neste teste. O MM SEL não suporta operação
substring e pode ser migrado com as strings de gênero específicas.
17
Figura 18.Copiar propriedadeContribBioda entidadeContribuintepara entidadeMovieRoleno modelo de documento.
Figura 19.Mover propriedadelinguagemda mesatitle_akaspara mesatitle_basicsno modelo relacional.
4.1.2. Operações entre modelos

As (potencialmente) operações entre modelos sãomoverecópia de. Também incluímos a operaçãoreferêncianesta seção, para demonstrar o
comportamento da propagação de referência entre modelos.
Teste Q7.O próximo requisito é ter propriedadeContribBiode entidadesContribuintetambém em entidadesMovieRole, porque aderir MovieRoleentidades
em cada carregamento de dados para obter uma propriedade extra pode ser caro. A desnormalização no modelo de documento é uma prática comum,
então optamos por copiar o valor. Observe que durante sua execução, descobrimos uma limitação do MongoDB que não é capaz de lidar com big data (∼
6.000.000) em operaçãodistinto.18Por esse motivo, modificamos nossa implementação para limitar a consulta a 1.000 entidades. No entanto, calculamos
os números do resultado do algoritmo não modificado: A operação copiou a propriedade de 458.107 entidadesContribuinteque contêm a propriedade
para 23.594.251 entidadesMovieRolesem carregá-los no espaço do aplicativo. PropriedadeversãoparaMovieRoletambém foi incrementado durante o
processamento de dados. (Fig. 33emApêndice Bcomo está o resultado do Teste Q7.)
A migração manual é mais complicada do que as migrações anteriores — consulteFig. 18. A parte diferente é a implementação da
condição WHERE. O exemplo seleciona todas as propriedades possíveisNome da contribuiçãoe combinandoMovieRoles e então procura por
entidades Contribuinte. A operação é segura [9], devido à relação 1:N.
Teste Q8.A solicitação de teste é para mover a propriedadelinguagemda entidadetitle_akaspara entidadetitle_basics. Não queremos copiar a
propriedade, pois no modelo relacional geralmente não é necessário desnormalizar os dados. O teste Q8 afeta um único modelo, portanto, será
executado como uma operação intramodelo dentro do modelo. A operação movimentou a propriedade de todas as 2.084.595 entidadestitle_akas para
entidades correspondentestitle_basics.19Também incrementa a propriedadeversãopara ambos os tipos de entidades. Toda a operação é executada no
modelo para que nenhuma entidade seja carregada no espaço da aplicação.Fig. 19mostra um exemplo da migração manual com gerenciamento de
propriedadeversão. (EmFig. 34emApêndice Bmostramos o estado final após a execução do Teste Q8.)
Teste Q9.O próximo teste é um requisito para copiar a propriedadeknownForTitlesde entidadesname_basicsno modelo relacional para entidades
MovieRoleno modelo de documento. Para corresponder entidades relevantes, usamos as propriedades de nome (nomeprincipaleNome da contribuição)
conforme mostrado no Teste Q9. Porém, nas exportações do IMDb para modelos distintos essas propriedades possuem formatos de dados diferentes —
por exemplo, no modelo de documento o valor da propriedade é ''$lim, Bee Moe'' enquanto no modelo relacional é ''Bee Moe$lim''. Nesta situação,
não podemos mapear entidades, então decidimos modificar manualmente 2 valores de propriedadesnomeprincipalno modelo relacional para poder
para executar a operação. Na verdade, o número de entidades correspondentes não é importante para este teste. Desde que movalores definidos para duas
entitie No modelo relacional, havia apenas 16 entidades correspondentes no modelo de documento. Mas desde a aberturaeu asrações são intermodelos,
entidades devem ser carregadas no mecanismo MM DBMS na memória do aplicativo. O número de modelo entiti carregado é es das entidades ded
8.534.771. Do modelo de documento tem que carregar 64.424.283. O número total é 72.959.054 loa relacionais.
Nesse caso, a migração manual é complexa e não podemos mostrar um script simples para isso. Algoritmo3é desc a melhor maneira de como
ri. (Fig. 35emApêndice Bmostra um exemplo da propriedade movida.)
18 A mensagem de erroeu s''errmsg'': ''exceção: distinto muito grande, limite de 16 mb''.

19 Embora no modelo relacional a propriedade seja adicionada a todas as entidades e definida comonulopara aqueles que não correspondem à condição.
18
Teste Q10.Este teste move a propriedadeContribBiode entidadesContribuinteno modelo de documento para entidadesname_basicsno modelo relacional.
No teste anterior, alteramos a propriedade name para poder corresponder entidades entre modelos e usamos essa correspondência novamente.
EmFig. 36emApêndice Bmostramos o resultado do Teste Q10. A operação corresponde a duas entidades no modelo de documento e duas entidades
no modelo relacional. Mas, como podemos ver no resultado, apenas uma entidade no modelo relacional contém novas propriedades ContribBio, pois
apenas uma entidade no modelo do documento tinha a propriedade preenchida. A operação modifica duas entidades mas carrega 6.693.529 entidades
Contribuintee 8.534.771 entidadesname_basicspara o mecanismo MM DBMS na memória do aplicativo.
Teste Q11.O último teste se concentra em referências. Primeiro, criamos uma referência da propriedadeContributor.ContibNameno modelo de
documento para propriedadename_basics.primaryNameno modelo relacional. O próximo passo é renomear a propriedadeNome da contribuiçãopara
PrimaryNamee, como último passo, excluímos a propriedadenomeprincipaldas entidades relacionais. Isso aciona a exclusão da propriedade
PrimaryNameque está fazendo referência a eles a partir do modelo de documento.
A última operação do Teste Q11 é a mais interessante. Se não houvesse referência das etapas anteriores, seria apenas operaçãoexcluirque
descrevemos antes. Mas a referência o torna mais complexo, especialmente para migração manual. Do modelo relacional, ele exclui a
propriedade de 8.534.771 entidades e, em seguida, a propriedade de referência de 6.693.529 entidades no modelo de documento (15.225.300
no total). O problema da migração manual é que os desenvolvedores precisam estar atentos a uma referência intermodelo, caso contrário os
dados chegariam a um estado inconsistente. Eles precisam saber quais modelos são afetados e preparar os scripts de migração apropriados
para eles. MM SEL esconde essa lógica e cuida dela. (Fig. 37emApêndice Bmostra a evolução da referência persistente no modelo de
documento e um exemplo de entidadeContribuinteapós a exclusão da propriedade referenciada.)
4.1.3. Resumo
Nos testes executados sempre mencionamos como uma migração manual poderia ser feita. Isso ajuda a entender a semântica, mas evidentemente
é preferível uma linguagem declarativa para especificar as operações de modificação do esquema. Podemos ser limitados, por exemplo, pela falta de
comandos para modificações do modelo específico ou a linguagem do modelo pode não ser bem conhecida pelos desenvolvedores. Por esse motivo,
assumimos que as migrações também podem ser executadas carregando cada entidade na memória do aplicativo de migração, sua modificação e
armazenamento de volta no MM DBMS.
Emmesa 2nós fornecemos as estatísticas resumidas:
1. ColunaOp.: A classificação das operações em intra-modelo e (possivelmente) inter-modelo.

2. ColunaTeste: A identificação do teste.
3. ColunaEntidades de destino: O número de entidades que devem ser modificadas por este teste.
4. ColunaPior caso: O pior cenário de carregamento de todos os dados na memória do aplicativo.
5. ColunaMelhor caso: o melhor cenário quando os desenvolvedores podem executar um script de migração ideal.
6. ColunaMM SEL: A implementação otimizada do MM SEL que delega operações intra-modelo ao modelo afetado.
Para todos os três casos, calculamos o seguinte:
1. ColunaEntidades carregadas: O número de todas as entidades que são carregadas na memória do aplicativo, ou seja, o número de todas as operações de
leitura/gravação.
2. ColunaEntidades afetadas: O número de entidades afetadas após a execução da operação de migração.
Como podemos ver na tabela, os cenários de melhor caso e os cenários MM SEL executam operações intra-modelo diretamente no modelo afetado,
portanto, ao contrário dos cenários de pior caso, não precisamos carregar entidades na memória do aplicativo. Os cenários de melhor caso também
sempre atingem o mínimo de entidades afetadas, mas à custa da complexidade do script de migração, ou do conhecimento das linguagens de migração
de cada modelo, entre outros fatores. Todas as abordagens escolhidas modificam o número de entidades que é igual ou maior que o número de
entidades alvo.
Assumimos que o uso da linguagem declarativa MM SEL é mais amigável e em nossos testes é tão eficiente quanto os melhores cenários.
Mas, por exemplo, se removermos a condição WHERE do Teste Q5, a renomeação é a mesma, mas a propriedadeversão deve ser atualizado
em todas as entidades e o MM SEL seria menos eficaz do que o melhor cenário. Tais situações podem ocorrer, pois o MM SEL não especifica o
comportamento quando uma operação visa uma entidade sem modificar a propriedade. Portanto, podemos ver que a eficácia do MM SEL é a
mesma que nos melhores cenários, se usarmos a linguagem corretamente. Ao contrário dos cenários de pior caso, ele carrega entidades no
espaço do aplicativo somente quando necessário para operações entre modelos.
5. Conclusão
As instâncias de dados multimodelos tornaram-se um novo fenômeno que desafia fundamentalmente as abordagens tradicionais de gerenciamento de dados.
Bancos de dados tradicionalmente projetados para tarefas altamente específicas agora precisam ser capazes de gerenciar dados cujas subpartes específicas têm
recursos e requisitos diferentes e até contraditórios para processamento eficiente. Além disso, as mudanças nos requisitos do usuário, que precisam ser refletidas
não apenas na parte especificada pelo usuário, mas também globalmente em todas as outras partes afetadas, complicam ainda mais esse problema.
Neste artigo mostramos o primeiro passo para uma solução robusta de gerenciamento de evolução de dados multimodelos. Apresentamos uma
ferramenta que permite aos usuários especificar as alterações necessárias em um esquema multimodelo e as propaga em todos os submodelos. As
principais vantagens da proposta são as seguintes:
19
• Cobrimos todos os modelos de dados populares atualmente.

• Lidamos com mudanças intra-modelo e inter-modelo.
• Apoiamos também referências mútuas entre os modelos.
No entanto, como indicamos na introdução, o problema de gerenciamento da evolução é geralmente complexo mesmo no mundo de
modelo único e, portanto, ainda não existem muitas soluções. Para o mundo multimodelo podemos identificar os seguintes principais
desafios:
• Extração de Alterações:O principal problema do gerenciamento de evolução é como obter as informações sobre as mudanças exigidas pelo
usuário. Neste artigo definimos linguagens que especificam as operações particulares; no entanto, existem várias abordagens de como obtê-los:
(1) O usuário pode especificá-los diretamente (ou ações mais complexas) usando uma interface amigável, ou seja, precisamos de uma maneira
unificada de como descrever/visualizar/modelar multimodelos dados . (2) As alterações podem ser extraídas de uma nova versão de dados/
esquemas, ou seja, precisamos encontrar o script de edição (ótimo) transformando o antigo esquema multimodelo em um novo. (3) As alterações
podem ser derivadas das modificações na carga de trabalho da consulta indicando a necessidade de alteração, ou seja, precisamos de um log de
operações multimodelo e sua análise detalhada. No entanto, nos três casos a solução não é trivial.
• Propagação para Operações:As instâncias de dados não constituem o único nível que devemos levar em conta para uma correta gestão
da evolução. Existem vários níveis [36] representando todo o aplicativo. Um dos críticos é o nível operacional. Quando a estrutura dos
dados muda, precisamos adaptar também as respectivas consultas [37–39] para que eles ainda sejam sintaticamente e semanticamente
corretos. Em outras palavras, precisamos resolver a direção de propagação oposta ao caso anterior — dos dados (estruturas) às
operações.
• Estratégias de propagação para armazenamento:O principal objetivo do gerenciamento da evolução é a preservação da consistência de todo o
sistema. No entanto, outro objetivo igualmente importante é preservar a eficiência da avaliação da consulta. No mundo multimodelo, isso pode
significar migração de dados entre os modelos. Até onde sabemos, atualmente existe apenas uma abordagem [8] que lida com a migração de
dados entre vários modelos, mas lidando apenas com os casos orientados para agregação.
• Engenharia reversa:Outra situação que vale a pena considerar é o caso em que temos um aplicativo multimodelo em execução com sucesso
explorando modelos mutuamente interconectados, enquanto um novo requisito do usuário é integrar um (conhecido) +1- º modelo (ou mesmo
um conjunto de modelos, possivelmente interligados). Essa tarefa envolve subproblemas, como o mapeamento do esquema recém-chegado ao
esquema multimodelo existente [40] ou inferência de esquema a partir de dados de vários modelos de amostra [41,42]. Na verdade, o
conhecimento de um esquema é crucial também para outras situações, nomeadamente para avaliação de consultas.
• Integração de Novos Formatos:Uma possível grande mudança que pode ocorrer e precisa ser considerada é o caso quando um novo
formato de dados ocorre e precisa ser facilmente integrado ao sistema atual. Esta é a situação extrema quando a nova parte do
aplicativo é desconhecida de antemão. No entanto, em vez de reimplementar todo o sistema, podemos (por exemplo,
temporariamente) ''reutilizar'' uma combinação de modelos existentes. O problema é como denotar a escolha ótima.
• avaliação comparativaPor último, mas não menos importante, como em todos os outros aspectos do gerenciamento de dados, também o mundo do
gerenciamento de evolução e propagação de mudanças requer uma forma unificada de benchmark. No mundo multi-modelo existe atualmente a primeira
proposta de um benchmark para consulta [22,30,43] que poderia servir como ponto de partida oferecendo um cenário de amostra e operações a serem
evoluídas. Além disso, benchmarks de evolução de esquema dedicados para MM DBs estão sendo desenvolvidos [31,32], e espera-se que em breve esteja
disponível.
Declaração de contribuição de autoria do CRediT
Irena Holubová:Concepção e desenho, análise e interpretação dos dados, revisão e edição.Michal Vavrek:Concepção e
desenho, análise e interpretação dos dados, rascunho original.Stefanie Scherzinger:Concepção e design, revisão e edição.
Declaração de interesse concorrente
Os autores declaram que não têm interesses financeiros concorrentes conhecidos ou relacionamentos pessoais que possam parecer
influenciar o trabalho relatado neste artigo.
Agradecimentos
Este artigo é baseado na dissertação de mestrado de Michal Vavrek [35]. Em parte, este projeto foi financiado pelo projeto GAČR, República Tcheca
no. 20-22276S e peloDeutsche Forschungsgemeinschaft(DFG, Fundação Alemã de Pesquisa), conceder #385808805. Agradecemos a Uta Störl pelo
feedback sobre uma versão anterior deste artigo.
Todos os autores aprovaram a versão do manuscrito a ser publicada.
Apêndice A
Neste apêndice emFig. 20paraFig. 26fornecemos capturas de tela que descrevem as operações realizadas nos testes de prova de conceito.
20
Figura 20.O resultado da operaçãoadicionaruma nova propriedade para o modelo de documento.
Figura 21.O resultado da operaçãoexcluiruma propriedade no modelo de documento.
21
Figura 22.O resultado da operaçãocópia dedo modelo de chave/valor para o modelo de documento.
Figura 23.O resultado da operaçãoadicionaruma nova propriedade para o modelo relacional.
Figura 24.O resultado da operaçãorenomearuma propriedade no modelo relacional.
Figura 25.O resultado da operaçãoexcluirde uma propriedade referenciada no modelo relacional.
22
Figura 26.O resultado da operaçãomoverdo modelo de chave/valor para o modelo de documento.
Apêndice B
Neste apêndice emFig. 27paraFig. 37fornecemos capturas de tela que descrevem as operações realizadas nos testes com dados do mundo real.
Figura 27.O estado inicial das entidadesMovieRolee o estado após a operaçãoadicionar.
23
Figura 28.O estado inicial das entidadestitle_baciscse o estado após a operaçãoadicionar.
Figura 29.O resultado da operaçãoexcluirpropriedadeClasseContribde entidadesMovieRole.
Figura 30.O resultado da operaçãorenomearpropriedadeFunçãoIdadeparaAgeOfRolepara entidadesMovieRole.
24
Figura 31.O resultado da operaçãoexcluirpropriedadepaís_restriçãode entidadestitle_basics.
Figura 32.O resultado da operaçãorenomearpropriedadeé adultoparaé restritopara entidadestitle_basics.
Figura 33.O resultado da operaçãocópia depropriedadeContribBioda entidadeContribuintepara entidadeMovieRole.
Figura 34.o feu estado final das entidadestitle_baciscsetitle_akasapós a operaçãomover.
25
Figura 35.O resultado da operaçãocópia depropriedadeknownForTitlesde entidadesname_basicsno modelo relacional para entidadesMovieRoleno modelo de documento.
Figura 36.O estado final das entidadesname_basicseContribuinteapós a operaçãomover.
26
Figura 37.Uso de referência no MMSEL.
Referências
[1]M. Stonebraker, U. Cetintemel, ''Tamanho único'': uma ideia cujo tempo veio e se foi, em: ICDE 2005, IEEE Computer Society, Washington, DC, EUA, 2005, pp. 2–
11.
[2]D. Feinberg, M. Adrian, N. Heudecker, AM Ronthal, T. Palanca, Gartner magic quadrant for operating database management systems, 12 de outubro de 2015,
2015.
[3] J. Lu, I. Holubová, B. Cautis, Bancos de dados multimodelos e polystores fortemente integrados: práticas atuais, comparações e desafios abertos, em: CIKM 2018, 2018, pp. 23
01–2302.
[4]ZH Liu, J. Lu, D. Gawlick, H. Helskyaho, G. Pogossiants, Z. Wu, Multi-model database management systems - a look forward, em: VLDB 2018 Workshops, Revised
Selected Papers, em: LNCS, 11470, Springer, 2018, pp. 16–29.
[5]J. Lu, I. Holubová, Bancos de dados multimodelos: uma nova jornada para lidar com a variedade de dados, ACM Comput. Sobreviver 52 (3) (2019).
[6]E. Pluciennik, K. Zgorzalek, The multi-model databases - a review, in: BDAS 2017, in: Communications in Computer and Information Science, 716, 2017, pp.
[7]M. Nečaský, J. Klímek, J. Malý, I. Mlýnková, Evolução e gerenciamento de mudanças de sistemas baseados em XML, J. Syst. Softw. 85 (3) (2012) 683–707.
[8]M. Klettke, U. Störl, M. Shenavai, S. Scherzinger, evolução do esquema Nosql e migração de big data em escala, em: BigData 2016, 2016, pp. 2764–2774.
[9]S. Scherzinger, M. Klettke, U. Störl, Gerenciando a evolução do esquema em armazenamentos de dados NoSQL, em: DBPL'13, arXiv, Riva del Garda, Trento, Itália, 2013.
[10] Banco de dados de filmes na Internet, 2018, URLhttp://www.imdb.com/, [On-line; Acessado em 2 de fevereiro de 2018].
[11]I. Holubová, S. Scherzinger, Desbloqueando o potencial de bancos de dados multimodelos NextGen para projetos semânticos de big data, em: SBD 2019, Association for
Computing Machinery, Nova York, NY, EUA, 2019.
[12]I. Holubová, M. Svoboda, J. Lu, Unified management of multi-model data, em: ER 2019, Springer International Publishing, Cham, 2019, pp. 439–447.
[13]I. Holubová, M. Klettke, U. Störl, Evolution management of multi-model data, em: Poly@VLDB 2019, Springer International Publishing, Cham, 2019, pp. 139–153.
[14]M. Vavrek, I. Holubová, S. Scherzinger, MM-evolver: Uma ferramenta de gerenciamento de evolução multimodelo, em: EDBT 2019, 2019, pp. 586–589.
27
[15]J. Lu, I. Holubová, Gerenciamento de dados multimodelo: o que há de novo e o que vem a seguir? em: EDBT 2017, 2017, pp. 602–605.
[16]JM Smith, PA Bernstein, U. Dayal, N. Goodman, T. Landers, KW Lin, E. Wong, Multibase: Integrando sistemas de banco de dados distribuídos heterogêneos, em:
AFIPS 1981, ACM, Nova York, NY, EUA, 1981, pp 487–499.
[17]M. Hammer, D. McLeod, em arquitetura de sistema de gerenciamento de banco de dados, em: MIT/LCS/TM, Mass. Inst. de Tecnologia, Laboratório de Informática, 1979.
[18] H. Lim, Y. Han, S. Babu, How to fit when no one size fits, in: CIDR 2013, 2013,www.cidrdb.org.
[19]Elmore, et al., Uma demonstração do sistema polystore BigDAWG, PVLDB 8 (12) (2015) 1908–1911.
[20]A. Stiemer, M. Vogt, H. Schuldt, U. Störl, PolyMigrate: evolução dinâmica do esquema e migração de dados em um polystore distribuído, em: V. Gadepally, T.
Mattson, M. Stonebraker, T. Kraska, F. Wang , G. Luo, J. Kong, A. Dubovitskaya (Eds.), Heterogeneous Data Management, Polystores e Analytics for Healthcare,
Springer International Publishing, Cham, 2021, pp.
[21]J. Lu, I. Holubová, Bancos de dados multimodelos: uma nova jornada para lidar com a variedade de dados, ACM Comput. Sobreviver 52 (3) (2019).
[22]C. Zhang, J. Lu, avaliação holística em benchmarking de bancos de dados multi-modelo, Distrib. Bancos de dados paralelos 39 (2021).
[23]M. Polák, M. Nečaský, I. Holubová, DaemonX: Design, adaptação, evolução e gerenciamento de formatos XML nativos (e mais outros), em: IIWAS 2013, 2013, pp.
484–493.
[24]M. Necasky, XSEM: Um modelo conceitual para XML, em: APCCM '07 - Volume 67, ACS, Inc., AUS, 2007, pp. 37–48.
[25]U. Störl, D. Müller, A. Tekleab, S. Tolale, J. Stenzel, M. Klettke, S. Scherzinger, Curando dados variacionais no desenvolvimento de aplicativos, em: ICDE 2018, 2018, pp. 1605–1608.
[26] U. Störl, D. Müller, M. Klettke, S. Scherzinger, Habilitando o desenvolvimento de software ágil e eficiente de aplicativos baseados em nosql, em: BTW'17, 2017, URL https://
dl.gi.de/20.500.12116/667, Demo.
[27]A. Hillenbrand, M. Levchenko, U. Störl, S. Scherzinger, M. Klettke, MigCast: Colocando um preço na evolução do modelo de dados em armazenamentos de dados NoSQL, em:
SIGMOD '19, ACM, Nova York, NY, EUA, 2019, pp. 1925–1928.
[28] A. Hillenbrand, U. Störl, M. Levchenko, S. Nabiyev, M. Klettke, Towards self-adapting data migration in the context of schema evolution in NoSQL databases, in:
36th IEEE International Conference on Data Engineering Workshops, ICDE Workshops 2020, Dallas, TX, EUA, 20 a 24 de abril de 2020, IEEE, 2020, pp. 133–138,
http://dx.doi.org/10.1109/ICDEW49219.2020.00013.
[29] C. Zhang, J. Lu, P. Xu, Y. Chen, UniBench: A benchmark for multi-model database management systems, em: TPCTC 2018, Rio de Janeiro, Brasil, 27 a 31 de agosto de 2018,
revisado Documentos selecionados, 2018, pp. 7–23.
[30] J. Lu, Towards benchmarking multi-model databases, em: CIDR 2017, 2017,www.cidrdb.org.
[31]ML Möller, M. Klettke, U. Störl, EvoBench - A framework for benchmarking schema evolution in nosql, em: Big Data 2020, Atlanta, GA, EUA, 10-13 de dezembro de
2020, IEEE, 2020, pp. 1974–1984 .
[32]ML Möller, S. Scherzinger, M. Klettke, U. Störl, Por que é hora de mais um benchmark de evolução de esquema - artigo visionário, em: CAiSE Forum 2020, em:
Lecture Notes in Business Information Processing, 386, Springer, 2020, pp. 113–125.
[33] Interfaces do Imdb, 2018, [Online; Acessado em 2 de fevereiro de 2018], URLhttps://www.imdb.com/interfaces/.
[34] Importando dados do IMDB para o mongodb: siga as instruções de michael havey, 2018, [Online; Acessado em 2 de fevereiro de 2018], URLhttp://log4idea.blogspot.cz/
2015/05/importing-imdb-data-into-mongodb-follow.html.
[35] M. Vavrek, Evolution Management in NoSQL Document Databases (tese de doutorado), Charles University em Praga, República Tcheca, 2018,http://www.ksi.mff.
cuni.cz/~holubova/dp/Vavrek.pdf.
[36]M. Nečaský, I. Mlýnková, J. Klímek, J. Malý, Quando o modelo conceitual encontra a gramática: Uma abordagem dupla para modelagem de dados XML, Data Knowl. Eng. 72
(2012) 1–30.
[37]M. Chytil, M. Polák, M. Nečaský, I. Holubová, Evolução de um esquema relacional e seu impacto em consultas SQL, em: IDC '14, vol. 511, Springer, 2014, pp. 5–15.
[38]M. Polák, I. Mlýnková, E. Pardede, Adaptação da consulta XML à medida que o esquema evolui, em: ISD 2012, Springer Science+Business Media, Inc., Prato, Itália, 2013, pp. 401–
416.
[39]ML Möller, M. Klettke, A. Hillenbrand, U. Störl, Reescrita de consultas para bancos de dados NoSQL em constante evolução, em: ER 2019, em: LNCS, 11788, 2019, pp. 213–221.
[40]A. Wojnar, I. Mlynkova, J. Dokulil, Aspectos estruturais e semânticos da similaridade de definições de tipo de documento e esquemas XML, Informe. ciência 180 (10) (2010) 1817–
1836, edição especial sobre sistemas de informação distribuídos inteligentes.
[41]MA Baazizi, D. Colazzo, G. Ghelli, C. Sartiani, Inferência de esquema paramétrico para conjuntos de dados JSON massivos, VLDB J. 28 (4) (2019) 497–521.
[42]I. Mlýnková, M. Nečaský, métodos heurísticos para inferência de esquemas XML: lições aprendidas e problemas em aberto, Informatica 24 (4) (2013) 577–602.
[43]C. Zhang, J. Lu, P. Xu, Y. Chen, UniBench: Uma referência para sistemas de gerenciamento de banco de dados multimodelo, em: TPCTC 2018, Springer International Publishing,
Cham, 2019, pp. 7–23.
Irena Holubovaé professor associado da Charles University, Praga, República Tcheca. Seus principais interesses atuais de pesquisa incluem gerenciamento de Big Data e bancos de
dados NoSQL, bancos de dados multimodelos, evolução e gerenciamento de alterações de aplicativos de banco de dados, análise de dados do mundo real e inferência de esquema.
Ela publicou mais de 80 artigos em conferências e periódicos; seus trabalhos ganharam 4 prêmios. Ela publicou 2 livros sobre bancos de dados XML e NoSQL.
Michal Vavrekformou-se na Charles University em Praga em 2018. Sua experiência na indústria, principalmente como engenheiro de software ou desenvolvedor, envolve empresas
como Microsoft, Skype, Profinit ou Logio.
Stefanie Scherzingeré professor da Universidade de Passau, Alemanha. Antes dessa posição, ela foi professora na OTH Regensburg, Alemanha. Sua pesquisa é fortemente influenciada por sua
experiência na indústria como ex-engenheira de software na IBM e no Google. Atualmente, ela se concentra na manutenção de aplicativos apoiados por armazenamentos de dados NoSQL e suporte
sistemático para a evolução do esquema do banco de dados.
28

Evolution Management in Multi-Model Databases - En.pt

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Evolution Management in Multi-Model Databases - En.pt

Enviado por

Direitos autorais:

Formatos disponíveis

Traduzido do Inglês para o Português - www.onlinedoctranslator.

Engenharia de dados e conhecimento 136 (2021) 101932

Listas de conteúdos disponíveis emScience Direct

Engenharia de dados e conhecimento

Página inicial do jornal:www.elsevier.com/locate/datak

Gerenciamento de evolução em bancos de dados multimodelos

Irena Holubováa,∗,Michal Vavreka,Stefanie Scherzingerb

Figura 1.Um cenário multimodelo.

2.1. Gerenciamento de dados multimodelo

2.2. gestão de evolução

Figura 3.Arquitetura de um SGBD MM baseado em camadas.

3.1. Linguagem de evolução de esquema multimodelo (MM SEL)

∙ Intra-modelooperações (ou seja,adicionar) afetam apenas um modelo.

Figura 4.Sintaxe EBNF de MM SEL.

Figura 5.Diagrama de interação:adicionar,excluir,renomear.

3.2. Implementação básica do MM SEL

Figura 6.Diagrama de interação:mover,cópia de.

Figura 7.Os comandos para interface com o banco de dados multimodelo.

Algoritmo 1:MM SEL:adicionar,excluir,renomear Algoritmo 2:MM SEL:mover,cópia de

cópia de 1. 1. 1para 2. 2onde 1∧ 2

Exemplo 3.1.Operaçãoadd document.tea.importer = ''Tea_Comp.''adiciona nova propriedadeimportadora todas as entidadeschá.

Exemplo 3.2.Operaçãoadicionar relacional.users.canDeliver = verdadeiro onde relacional.users.address = nulo

Exemplo 3.3.Operaçãoexcluir document.tea.countryremove propriedadepaísde todas as entidades do tipochá. Propriedade

Exemplo 3.4.Operaçãorenomear relacional.users.name para fullnamerenomeia a propriedadenomede entidadeUsuáriosparanome

Figura 8.O exemplo de aplicativo multimodelo de uma loja virtual.

Exemplo 3.5.Operaçãocopie keyValue.appVersion para document.teacopia a propriedadeappVersionda chave/valor

Algoritmo 3:Copiar propriedadeappVersiondo modelo de chave/ Algoritmo 4:Mover propriedadevendedordo modelo de

removervendedordo modelo chave/valor;

3.3. Implementação otimizada do MM SEL

3.3.1. Linguagem de evolução do esquema de banco de dados (DSEL)

Algoritmo 5:Chave/valor DSEL:adicionar,excluir,renomear Algoritmo 6:Chave/valor DSEL:mover,cópia de

adicionar 1= mover 1para 2

novo( 2, pegar( 1));

∙ Operaçãoadicionar entidade.propriedadeadiciona colunapropriedadepara mesaentidade.

∙ Operaçãoexcluir entidade.propriedaderemove colunapropriedadeda mesaentidade.

∙ Operaçãorenomear entidade. 1para 2renomeia a coluna 1para 2na tabelaentidade.

∙ Operaçãomover entity1.property para entity2.propertycoluna de cópiaspropriedadeda mesaentidade1paraentidade2e exclui a coluna

3.3.2. Mudanças entre modelos x intramodelos

No Algoritmo7, otimizamos as operações intra-modeloadicionareexcluire operação entre modelosmover. As operações intra-

Algoritmo 7:SEL MM otimizado:adicionar,excluir,mover Algoritmo 8:SEL MM otimizado:renomear,cópia de

adicionar 1. 1[. 1] = onde 1 renomear 1. 1. 1para 2onde 1

excluir 1. 1. 1onde 1 cópia de 1. 1. 1para 2. 2onde 1∧ 2

mover 1. 1. 1para 2. 2onde 1∧ 2 outro

para cadaelemento de ( 1, = 1∧ 1)fazer

3.4. Evolução das referências

Figura 14.Extensão da sintaxe MM SEL em EBNF com referências.

Figura 15.Comandos dedicados para manipular referências no banco de dados multimodelo.

Exemplo 3.7.A sequência de operações:

Algoritmo 9:Excluir propriedade de referência

remova a propriedade de referência;

Algoritmo 10:MM SEL com referências:referência

Algoritmo 11:MM SEL com referências:renomear

3.5. Robustez do MM SEL

Algoritmo 12:MM SEL com referências:excluir

Algoritmo 13:MM SEL com referências:mover

definirPropriedade( , , obterPropriedade( , ) + 1);

renomearReferência(( 1. 1, 1),( 2. , 1)); para cada

4.1. Teste com dados do mundo real

Figura 16.Operações de modificação de esquema.

Op. Teste Entidades de destino Pior caso Melhor caso MM SEL

Carregado Afetado Carregado Afetado Carregado Afetado

Q1 64.424.283 64.424.283 64.424.283 0 64.424.283 0 64.424.283

Q7 23.594.251 23.594.251 23.594.251 0 23.594.251 0 23.594.251