UMLto[No]SQL: Mapping Conceptual Schemas toHeterogeneous Datastores

Gwendal DanielInternet Interdisciplinary Institute, IN3Universitat Oberta de Catalunya, UOC

Barcelona, Spaingdaniel@uoc.edu

Abel GómezInternet Interdisciplinary Institute, IN3Universitat Oberta de Catalunya, UOC

Barcelona, Spainagomezlla@uoc.edu

Jordi CabotICREA

Universitat Oberta de Catalunya, UOCBarcelona, Spain

jordi.cabot@icrea.cat

Abstract—The growing need to store and manipulate largevolumes of data has led to the blossoming of various families ofdata storage solutions. Software modelers can benefit from thisgrowing diversity to improve critical parts of their applications,using a combination of different databases to store the data basedon access, availability, and performance requirements. However,while the mapping of conceptual schemas to relational databasesis a well-studied field of research, there are few works that targetthe role of conceptual modeling in a multiple and diverse datastorage settings. This is particularly true when dealing with themapping of constraints in the conceptual schema. In this paperwe present the UMLto[No]SQL approach that maps conceptualschemas expressed in UML/OCL into a set of logical schemas (ei-ther relational or NoSQL ones) to be used to store the applicationdata according to the data partition envisaged by the designer.Our mapping covers as well the database queries required toimplement and check the model’s constraints. UMLto[No]SQLtakes care of integrating the different data storages, and providesa modeling layer that enables a transparent manipulation of thedata using conceptual level information.

Index Terms—Database Design, UML, OCL, NoSQL, RDBMS,constraint, SQL, model partitioning

I. INTRODUCTION

The NoSQL movement [6] is recognized as one of themain solutions to handle large volumes of diverse data.NoSQL solutions are based on a flexible schemaless datamodel focused on efficiency, horizontal scalability, and highavailability, and can be categorized into four major groups:key-value stores, document databases, graphs, and columndatabases [22]. NoSQL stores complement relational databasesand other hybrid solutions to offer a large number of optionswhen it comes to decide where to store the data managedby a software system. In fact, it is not unusual that thebest alternative is to combine several technologies for anoptimal result. E.g., the same application could use a relationaldatabase for transactional data but opt for a key-value store forevent log management.

Unfortunately, current conceptual modeling methods andtools offer little support for this “multi-store” modeling andgeneration challenge. Modelers should be able to easily anno-tate the model with details on the type of data solution to use asstorage mechanism and to generate from that annotated modelthe corresponding implementation in a (semi)automatic way.Still, only the mapping of conceptual schemas to relational

databases has been widely investigated so far. Very fewsolutions targeting NoSQL backends exist and, when they do,they target individual datastores and typically skip the mappingof the model constraints.

In this paper, we present UMLto[No]SQL, a new approachto partition conceptual schemas (including constraints andbusiness rules) and to map each fragment to a different datastorage solution. Without loss of generality we assume that theconceptual schema is modeled as a UML class diagram [25]and its integrity constraints are expressed in OCL [24] (ObjectConstraint Language), both OMG standards.

UMLto[No]SQL is based on existing works targeting themapping of conceptual schemas to specific datastore technolo-gies [9], [11] and integrates them in a unique multi-datastoredesign method. The main contributions of the paper are:• A conceptual model partitioning approach integrated as

an UML profile allowing to group model elements inregions to be persisted in a specific datastore.

• A set of mappings from conceptual schema regions todatastore-specific models, including a new mapping fromUML class diagrams to document databases.

• A translation approach from constraints and businessrules to database-specific queries, also covering constraintexpressions that require evaluating elements stored indifferent and heterogeneous backends.

• A runtime modeling layer that automatically deploys themodeled application, and provides a high-level API tomanipulate and check constraints on top of the underlyingpersistent storage mechanisms transparently.

The rest of the paper is organized as follows: Section IIpresents the UMLto[No]SQL approach, Section III introducesour model partitioning technique, Section IV details the map-ping of (UML) models to a variety of store metamodelsand Section V does the same for the OCL constraints. Sec-tion VI introduces the UMLto[No]SQL runtime layer. Finally,Section VII describes the related works, and Section VIIIsummarizes the contributions and draws future work.

II. UMLTO[NO]SQL APPROACH

The MDA standard [23] proposes a structured methodologyto system development that promotes the separation betweena platform independent specification (Platform Independent

Model, PIM), and the refinement of that specification (Plat-form Specific Model, PSM) adapted to the technical con-straints of the implementation platform. In this context, amodel-to-model transformation (M2M) generates the PSMsfrom the PIMs, while a model-to-text transformation (M2T)typically takes care of producing the final system implemen-tation out of the PSM models. This PIM-to-PSM phasedarchitecture brings two important benefits: (i) the PIM levelfocuses on the specification of the structure and functions,raising the level of abstraction and postponing technical detailsto the PSM level; and (ii) multiple PSMs can be generatedfrom one PIM, improving portability and reusability.

This PIM-to-PSM staged development perfectly fits thephases of our UMLto[No]SQL approach, where a runtimemodeling layer – able to interact with heterogeneous datas-tores – is generated out of a conceptual schema expressed inUML and OCL. Thus, following the MDA approach, Fig. 1describes a typical UMLto[No]SQL development process to-gether with the main artifacts involved.

The only actor involved in a UMLto[No]SQL process isthe system modeler, who specifies the conceptual schema ofthe system using a UML class diagram and its correspondingOCL constraints at the PIM level. At this level, the modelercan manually annotate ii the conceptual schema (see Sec-tion III-B for more details) to group its entities in differentregions. A region is a logical partition that determines theconceptual elements that should be persisted in the samedatastore. For example, the Annotated UML class diagram inFig. 1 has been annotated specifying two regions: one containsthe elements with horizontal stripes, and the other contains theelements with vertical stripes. The initial OCL expressionsremain unaffected.

Next, two automatic M2M transformations are executed inparallel to convert our PIMs into PSMs:• UmlTo[No]SQL iii transforms each region – and its

elements – of the annotated model at the PIM level,into a set of datastore-specific models at the PSM level(the so-called (Datastore Models), precisely representingthe data structures to be used to record the data in thatparticular datastore. In Fig. 1, elements annotated withvertical stripes are transformed to a Datastore model forthe # backend, while elements annotated with horizontalstripes are transformed to a Datastore model for the Dbackend. Note that this transformation also handles thetranslation of relationships among elements in differentregions producing cross-Datastore Models relationships(⇔). These special relationships are discussed in Sec-tion IV.

• OCLToQuery iiii transforms the OCL constraints at thePIM level into a set of Query Models adapted to theselected storage technology. As it can be seen in Fig. 1,Query Models can contain both elements of the # andthe D backend. This is because the transformation alsohandles the translation of queries spanning different data-stores. Such cross-datastore queries exploit a dedicatedquery mechanism presented in Section V.

UMLClass Diagram

OCLToQueryTransformations

Modeling Layer

QueryModels

PSMtoCodeTransformations

DatastoreModels

PIM

PSM

Code

UmlTo[No]SQLTransformations

context Binv myInvariantcontext A

inv myInvariantself.value > 0

OCL Constraints

i

iv

iii

Datastore⬠Datastore○

A

B C

D E

F G

H

I J

K L

M N

iv v v

ii

Annotated UMLClass Diagram

context Binv myInvariantcontext A

inv myInvariantself.value > 0

OCL Constraints

Fig. 1. Overview of the UMLto[No]SQL Infrastructure

Finally, the generated Datastore Models and Query Modelsare sent to a final set of PSMtoCode M2T transformations.These transformations generate the database schema defini-tions (in the case of SQL datastores) and software artifacts (inall cases) that are capable of retrieving the different entitiesof the conceptual schema from their corresponding datastores

iiv . Additionally, the code to evaluate the different queriesand constraints is also generated iv .

The result of these transformations is an integrated Model-ing Layer that allows interacting with the different databases,retrieving and modifying the data stored in them, and alsochecking the corresponding integrity constraints. All accessesto the underlying data are done in a transparent way, only usingconceptual level information. This Modeling Layer can be seenas a runtime model [2] built on top of the storage solutions.That way, users can query the data by directly referring to thetypes and associations they are interested in, instead of havingto know the internal data structure names used to record thatdata in each specific datastore.

III. CONCEPTUAL SCHEMA PARTITIONING

As introduced in the previous Section, the first step of ourapproach is partitioning the initial conceptual schema into aset of regions. Each region identifies a group of entity typesin the schema that should be stored together in the datastoreassociated to the region. A schema can have one or moreregions. The regions of a schema can be homogeneous (allregions are linked to a different backends but all backends areof the same “family”) or heterogeneous (different regions maybe linked to completely different types of backends).

At the PIM level, the modeler only needs to focus ondefining the limits of the region and the desired type ofdatastore. Low-level details (e. g., connection information) areprovided later on, in the PSM models, as part of the typicalMDA refinement process (see Section IV).

Fig. 2. Partition Domain Model

Without loss of generality, conceptual schemas are ex-pressed as UML class diagrams but other conceptual modelinglanguages could have been used instead. Still, UML offers amodeling primitive that is especially useful to implement ourconcept of regions, the UML profiling mechanism.

Profiling opens the possibility of extending or restrictingUML to satisfy the modeler needs in a standard way. More-over, the vast majority of UML tools support this mechanism,facilitating a quick adoption of profiles like ours.

To construct a technically correct high-quality UML profile,several steps need to be followed according to the generallyaccepted good practices [27]. First, a domain model definingthe additional modeling concepts must be created. In our case,this domain model should capture the concepts to specifyschema partitions as presented next in Sect III-A. Second, aprofile is defined by mapping the concepts from the domainmodel to UML concepts. In our case, each class of the partitiondomain model is examined, together with its attributes, associ-ations and constraints, to identify the most suitable UML baseconcepts for it. Based on this, we built the partition profilepresented in Sect. III-B.

A. A domain model for conceptual schemas partitioning

Figure 2 shows our proposed domain model for the par-titioning of conceptual schemas. In this proposal, a givenconceptual schema (not shown) relates to one Partition Modelcontaining the Regions for the different datastores the modelerwants to use. Regions have a name that identifies them,and a storage attribute indicating the type of data storageapproach that will be used in subsequent steps. Thee possibledata storage approaches can be specified, each one associatedto a different data persistence technique: Graph for graph-based databases, Document for document-based stores, andRelational for classical relational databases. Finally, UMLclasses from the conceptual schema may be associated to aspecific region via its regionElement association. All UMLclasses belonging to the same region should be stored togetherat the end of the development process.

B. A profile for conceptual schemas partitioning

In order to put our partition approach in practice, wehave defined the accompanying UML profile as proposedby Selic [27]. Following the good practices proposed byLagarde [18], Figure 3 shows our UML profile for conceptualschemas partitioning.

As it can be seen, there exists almost a one-to-one mappingbetween the concepts of the Partition Domain Model and thePartition Profile. Now, the link between a Partition Model

Fig. 3. Partition Profile

and a conceptual schema represented as a UML Model isexplicit via the extension relationship. For its part, Regionsextend Namespaces, which typically, are Packages containingthe entity types (e. g., classes) of the conceptual schema.Finally, the RegionElement stereotype is used to annotate theClassifiers (typically UML classes) within a Region that willbe persisted.

The Partition Profile is exemplified in Figure 4. The con-ceptual schema shown in the figure depicts an e-commerceapplication that will be used as running example for the rest ofthe paper. The schema specifies the Client, Orders, Products,and Comment concepts and the relationships among them,organized in three packages Clients, Business, and Comments.

By means of the profile, we have expressed that thebusiness part of this schema should be stored in a documentdatabase, the clients one should go to a relational database,and the comments one to a graph database. Therefore, wehave defined three Regions, each one tagged with a different

Fig. 4. Example Schema Partition

target storage solution. Note that in our example Regions arecreated based on the domains of their data, but alternativePartition Models based on performance requirements (e.g.data proximity) can also be specified through our profile

IV. MAPPING CLASS DIAGRAM FRAGMENTS

The partitioned conceptual schema is the input of ourUMLto[No]SQL transformation component, in charge of gen-erating the PSMs representing the logical database structurecorresponding to each conceptual region in the partition.

Our approach currently embeds three transformations, eachone associated to a specific data store. Two of them are basedon previous works: UmlToGraphDB covering mappings tograph databases (taken from [9]) and UmlToSQL that reuses“classical” works on mapping UML (or ER) to relationaldatabases (e.g. [11]). The third one is completely new. As itis also a novel contribution the possibility to have in the sameschema regions linked to heterogeneous backends. As such,in this section we review the relevant parts of existing UMLto database mappings and show how we adapt them to handlecross-datastore associations. We also introduce DocumentDB:a novel metamodel representing the structure of Documentdatabases, as well as the associated mapping rules to deriveDocumentDB instances from class diagrams.

In the following we denote a partitioned class diagram CDas a tuple CD = (Cl,As,Ac, I, R), where Cl is the setof classes, As is the set of associations, and Ac is the setof association classes. I is a set of pairs of classes such as(cl1, cl2) represents the fact that c1 is a direct or indirectsubclass of c2, and R is a set of pairs (cl, r) mapping eachclass of the conceptual model to a region defined with the helpof our partition metamodel. Note that for the sake of simplicityattributes of classes and associations are denoted cl.attr (e.g.cl.name represents the name of a class).

We also define two additional predicates that are reusedacross our mappings: reg(cl) = r.storage, (cl, r) ∈ R repre-sents the storage value of the region containing the class cl,and parents(c) ⊂ Cl, ∀p ∈ parents(c), (c, p) ∈ I representsthe set of super-classes in the hierarchy of c.

A. Relational Database Mapping

1) RelationalDB Metamodel: Figure 5 presents our Rela-tionalDB metamodel which is a simplified version of existingmetamodels aiming at representing relational databases. Itcontains a top-level Schema that stores a set of named Tables.Tables contain Columns that store information of a givenDataType. Our metamodel currently supports primitive types,as well as an UUID type which is used to identify elementsacross datastores. A Table also contains a PrimaryKey whichrefers to one or multiple Columns. Finally, Tables can containForeignKeys, each one associated to an existing PrimaryKeyand linking a Column to a foreign one stored in another Table1.

1For simplicity purposes, this metamodel does not support foreign keysspanning over multiple columns

Fig. 5. RelationalDB Metamodel

Fig. 6. RelationalDB Instance

2) Class Diagram to RelationalDB Transformation: Wedenote a RelationalDB model RM as a tuple RM =(S, T, C, P, F ), where S is a schema, T is the set of tables, Cis the set of columns, P is the set of primary keys, and F is theset of foreign keys that compose the relational model. In thefollowing we present the mapping from CD to RM. This map-ping is based on existing approaches from the literature [11],and adapts them to support cross-datastore queries.• R1: each relational region r.storage = Relational,∀cl(cl, r) ∈ R is mapped to a schema s such as s.name= r.name.

• R2: each class cl ∈ Cl is mapped to a table t ∈ T , wheret.name = cl.name, and added to the schema s mappedfrom its containing region such as t ∈ s.tables. Inaddition, a column c ∈ C is created such as c.name = id,c.dataType = UUID, c ∈ t.columns. This columnis set as the primary key pk of t such as pk ∈ P ,pk.name = cl.name + _pk, c ∈ pk.columns, pk ∈t.primaryKey.

• R3: each inheritance relationship between two classes cl1,cl2 ∈ Cl, (cl1, cl2) ∈ I (respectively mapped by R2 tot1, t2 ∈ T ) such as reg(cl1) = reg(cl2) = Relationalis mapped to a foreign key such as fk ∈ F , fk.name= cl1.name_parent_fk, fk ∈ t1.foreignKeys such asfk.primaryKey = t2.primaryKey, fk.ownColumn= t1.primaryKey.column, fk.foreignColumn =t2.primaryKey.column. Note that this rule does notcreate foreign keys for cross-datastore inheritance links.

• R4: each attribute of a class cl ∈ Cl such as a ∈cl.attributes is mapped to a column c ∈ C where

c.name = a.name, c.datatype = a.type2, and addedto the column list of its mapped container t such asc ∈ t.columns.

• R5: each single-valued association assingle ∈ As be-tween two classes cl1, cl2 ∈ Cl is mapped to acolumn c ∈ C, c.name = as.name, c.dataType= UUID added to the table t1 such as c ∈t1.columns. If reg(c1) = reg(c2) = Relational,a foreign key fk ∈ F is also created such asfk.name = assingle.name + _ + cl2.name + _fk,fk.primaryKey = t2.primaryKey, f.ownColumn =c, f.foreignColumn = t2.primaryKey.column andadded to the containing table’s foreign key set such asf ∈ t1.foreignKeys. This means that cross-datastoreassociations are mapped to UUID columns (with nocorresponding foreign key).

• R6: each multi-valued association asmulti ∈ As be-tween two classes cl1, cl2 ∈ Cl is mapped to a tablet ∈ T , t.name = as.name containing two columnsc1, c2 ∈ C, c1, c2 ∈ t.columns such as c1.name =cl1.name + _id, c1.dataType = UUID, c2.name =cl2.name + _id, c2.dataType = UUID. This mappingrule also creates a primary key pk ∈ P , pk.name= asmulti.name_pk, pk ∈ t.primaryKeys such asc1, c2 ∈ pk.columns. Finally, classes involved in theassociation such as reg(cln) = Relational are mappedto a foreign key fk ∈ F , fk.name = asmulti.name +_cln.name + _fk, fk ∈ t.foreignKeys such asfk.primaryKey = tn.primaryKey, fk.ownColumn= cn, fk.foreignColumn = tn.primaryKey.column.

Figure 6 presents the RelationalDB model produced whenapplying the mapping rules to our running example. Theproduced model defines a top-level Schema element namedclients and containing three Tables. The Table t1 is mappedfrom the Client abstract class, and contains three columns tostore the Client’s UUID, name, and address. It also definesa PrimaryKey pk1 defined over the UUID column. TheTable t2 is mapped from the CorporateCustomer class, anddefines two columns to store its UUID and its contractRefattributes. It also define a PrimaryKey pk2 over its id column,and a ForeignKey fk1 associating the CorporateCustomerid to its parent Client one. Finally, t3 is created from theorder_client association, and contains two Columns (set asprimary key through the pk3 instance) storing the identifiersof the involved Client and Order instances. This Table containsa single ForeignKey linking the client_id Column to the idColumn of the Client table. Since Order is not part of therelational region, the mapping does not produce a foreign keyfor this column. Navigation of this cross-datastore associationis detailed in Section V.

B. Graph Database Mapping1) GraphDB Metamodel: Figure 7 presents the GraphDB

metamodel [9] that defines the possible strutural elements

2We assume that a mapping mechanism is available to convert conceptualmodel types to the ones defined in our target metamodels.

Fig. 7. GraphDB Metamodel

in graph databases. This metamodel is compliant with theBlueprints specification [28], which is an interface designedto unify graph databases under a common API.

The GraphDB metamodel defines a top-level GraphSpecifi-cation which contains all the VertexDefinitions and EdgeDef-inition of the database under design. VertexDefinitions andEdgeDefinitions can be linked together using outEdges andinEdges association, meaning respectively that a VertexDefi-nition has outgoing edges and incoming edges. In addition,VertexDefinition and EdgeDefinition are both subtypes ofGraphElement, which defines a set of labels describing thetype of the element, and a set of PropertyDefinition throughits properties association. In graph databases properties arerepresented by a key (the name of the property) and a type.The GraphDB metamodel defines 5 primitives types (Object,Integer, String, Boolean, and our own UUID type).

2) Class Diagram to GraphDB Transformation: Herein wepresent the mapping from a partitioned class diagram to theGraphDB metamodel. This mapping is an adaptation of ourprevious work [9].

We denote a GraphDB model GD as a tuple GD =(G,V,E, P ), where G is a GraphSpecification, V is set ofVertexDefinitions, E the set of EdgeDefinitions, and P the setof PropertyDefinitions that compose the graph. The mappingfrom CD to GD is formalized in the following rules:

• R1: each graph region r.storage = Graph,∀cl(cl, r) ∈R is mapped to a graph specification g such as g.name =r.name.

• R2: each class cl ∈ Cl,¬cl.isAbstract is mappedto a vertex definition v ∈ V , where v.label =cl.name ∪ parents(cl).name. In addition, a propertyp ∈ P, p.key = id, p.type = UUID is added to the prop-erty list of the created vertex such as p ∈ v.properties.This property is used to uniquely identify the element andwill be used to retrieve specific instances when navigatingcross-datastore associations.

• R3: each attribute a ∈ (cl ∪ parents(cl)).attributesis mapped to a property definition p, where p.key =a.name, p.type = a.type, and added to the property listof its mapped container v such as p ∈ v.properties. Notethat this rule flattens the inheritance hierarchy by mappingthe attributes of all cl’s parents in the produced vertex.

• R4: each association as ∈ As between two classesc1, c2 ∈ Cl with reg(c1) = reg(c2) = Graph is mapped

Fig. 8. Mapped GraphDB Instance

to an edge definition e ∈ E, where e.label = as.name,e.tail = v1, and e.head = v2, where v1 and v2 arethe VertexDefinitions representing c1 and c2. Notethat e.tail and e.head values are set according to thedirection of the association. Aggregation associationsare mapped the same way, but their semantic is handleddifferently at the application level. In order to supportinherited associations, EdgeDefinitions are also createdto represent associations involving the parents of c.

• R5: each association as ∈ As between two classesc1, c2 ∈ Cl with reg(c1) = Graph, reg(c2) 6= Graph istranslated to a property p ∈ P where p.key = as.name,p.type = UUID and added to the property list of itsmapped container v such as p ∈ v.properties.

Figure 8 shows the result of applying this mapping ruleson our running example. The created model defines a Graph-Specification mapped from the comments region, and containsa single VertexDefinition v mapped from the class Comment.This VertexDefinition is associated to a single EdgeDefinition erepresenting the replies association. V contains a single labelrepresenting its class, and a PropertyDefinition p1 holdingits UUID identifier. V also contains two PropertyDefinitionscorresponding to its content and date attributes, and two addi-tional PropertyDefinitions p4 and p5 representing referencesto the Clients and Products classes, respectively stored in arelational and a document database.

C. Document Database Mapping

1) DocumentDB Metamodel: Figure 9 shows the Docu-mentDB metamodel, our contribution to represent the internalstructure of document-oriented datastores. A Database is de-fined by a name, and contains a set of Collections representingfamilies of DocumentSchemas. DocumentSchemas are low-level data structures that can be seen as associative arrayscontaining a set of Fields. A Field is identified by a key,and a Type of data it can hold. In our metamodel, Types arecategorized into three groups: (i) PrimitiveTypes representingprimitive type values (including the UUID introduced before),(ii) DocumentTypes representing document references, (iii)CollectionTypes representing list of nested elements (contain-ing an elementType attribute representing the type of the col-

Fig. 9. DocumentDB Metamodel

lection). Note that the DocumentType construct is independentof the concrete, platform-specific implementation of documentreferences (e.g. logical link between existing document such asin MongoDB vs. duplication of its content in a nested copy).

2) Class Diagram to DocumentDB Transformation: A Doc-ument diagram DD is defined as a tuple DD = (C,D, F ),where C the set of collections, D is a set of documents, andF the set of documents’ fields. In addition, we define theCollectionType and DocumentType constructs that are derivedfrom the DocumentDB metamodel, and are initialized with asingle parameter, representing respectively their elementTypeand referredDocument. Based on these definitions, the map-ping rules are expressed as:

• R1: each document region r = Document,∀cl(cl, r) ∈R is mapped to a document database d such as d.name =r.name

• R2: each class cl ∈ Cl, reg(cl) = Document,@x(cl, x) ∈ I is mapped to a collection c ∈ C suchas c.name = cl.name. Note that this rule produces acollection for each superclass in the model.

• R3: each class cl ∈ Cl (including the ones mappedby R2) are mapped to a document schema d ∈ Dand its containing collection is set as d.collection =c, where c represents the mapped collection of thetop-level element in cl inheritance hierarchy. As a re-sult, document schemas mapped from classes in thesame inheritance hierarchy will be contained in thesame collection. This mapping rule also creates a fieldfid ∈ F, fid ∈ d.fields, fid.name =′ _id′, fid.type =UUID representing the unique identifier of the element.Finally, an additional field fclasse ∈ F, fclasses ∈d.fields, fclasses.key =′ _classes′, fclasses.type =String is also created to store the names of the classesin cl’s hierarchy, and is required to filter concrete sub-classes from generic super-class collections.

• R4: each attribute a ∈ (c ∪ parents(c)).attributesis mapped to a field f , where f.key = a.name,f.type = a.type, and added to the property list ofits mapped container d such as f ∈ d.fields. Multi-valued attribute are mapped similarly, using the Collec-tionType construct to represent multiple values: f.type =

CollectionType(a.type).• R5: each association as ∈ As between two

classes c1, c2 ∈ Cl, reg(c1) = reg(c2) =Document is mapped to two fields fc1, fc2 ∈F where fc1 ∈ d1.fields, fc1.key = a.name,fc2 ∈ d2.fields, fc2.key = a.name, fc1.type =DocumentType(d2), fc2.type = DocumentType(d1),where d1 and d2 are the Documents representing c1and c2. This rule creates Fields in the documents rep-resenting the classes involved in the association, andset their type as a DocumentType referring to the otherend of the association. In order to support inheritedassociations, Fields are also created to represent associ-ations involving the parents of c. Note that multi-valuedends of the associations are mapped as multi-valuedattributes using the CollectionType construct: fc1.type =CollectionType(DocumentType(d2)).

• R6: each association between two classes from het-erogeneous datastores c1, c2 ∈ Cl, reg(c1) =Document, reg(c2) 6= Document is mapped to afield fc1 ∈ F where fc1 ∈ d1.fields, fc1.key =a.name, fc1.type = UUID. Multi-valued ends of theassociations are mapped similarly to R5. Note that thisinitial version of our mapping does not consider associ-ations involving more than two classes.

• R7: each association class ac ∈ Ac between classescl1...cln is mapped to a document dac such asdac.collection = c, c ∈ C, c.name = ac.name. Asfor a regular class, dac contains the Fields correspond-ing to the attributes ac.attributes, and a set of Fieldsfaci ∈ F where faci.key = ci.name, faci.type =DocumentType(di) linking to each document repre-senting a class involved in the association. In ad-dition, an identifier Field fid ∈ F is also pro-duced such as fid ∈ fac.fields, fid.name =′

_id′, fid.type = UUID and added to the containedfields. Multi-valued ends are mapped as multi-valuedattributes using the CollectionType construct: fci.type =CollectionType(DocumentType(dac)).

To better illustrate the different mapping rules, we presentin Listing 1 the output of the UmlToDocumentDB translationwhen applied on the running example. For clarity, the resultingDocumentDB model is shown using a JSON-like concrete syn-tax derived from the metamodel (abstract syntax) presented inFigure 9. A Database instance named business contains threecollections representing the classes of the input model: order,product, and the association class orderLine. The order collec-tion defines a single document schema orderDoc which con-tains a set of Fields mapping Order class attributes in the con-ceptual schema. orderDoc also includes a multi-valued docu-ment reference to orderLineDoc, as a result of the mapping ofthe relationship between Order and the OrderLine associationclass, and an external reference to client (materialized as aUUID), as part of the mapping between Order and the Clientclass, located in a different region in the conceptual schema.

Database "business" {Collection "order" {DocumentSchema orderDoc {

_id : UUID_classes : [String]reference : StringshipmentDate : DatedeliveryDate : Datepaid : Booleanclient : UUIDorderLine : [orderLineDoc]

} }Collection : "product" {DocumentSchema productDoc {

_id : UUID_classes : [String]name : Stringprice : Integerdescription : StringorderLine : [orderLineDoc]

} }Collection : "orderLine" {DocumentSchema orderLineDoc {

_id : UUID_classes : [String]quantity : IntegerproductPrice : IntegerorderLine_order : orderDocorderLine_product : productDoc

} } }

Listing 1. Mapped DocumentDB Model (Textual Syntax)

context Product inv validPrice: self.price ≥ 0context Comment inv validComment: self.date > self.

repliesTo.datecontext Order inv validOrder: if self.paid then self.

orderLine→forAll(o | o.quantity > 0) else false endifcontext Client inv maxUnpaidOrders: self.orders→select(o |

not o.paid)→size()< 3

Listing 2. Textual Constraints

V. MAPPING OCL EXPRESSIONS

To complete the PIM-to-PSM transformation process, theOCL constraints attached to the input conceptual schemaare translated to queries expressed in the query language/savailable in the data stores where the model elements affectedby the query will be mapped.

In this section, we first discuss the translation of OCLqueries local to a single region and, later, how the processdeals with global OCL constraints, i.e. constraints referencingmodel elements in different regions. Note that the generatedqueries can be manually integrated in an existing databaseinfrastructure, or wrapped in constraint checking methodsprovided by the runtime component presented in Section VI.

To illustrate this section, we will use the four OCL con-straints of Listing 2 defined on top of our running example(Figure 4). The first one checks that the price of a Productis always positive, the second one checks that the date of acomment is always greater than its parent one, the third oneverifies that once an Order has been paid all its orderLineshave a positive quantity value, and the last one ensures that aClient has less than three unpaid Orders. Note that constraints1-3 target a single region, while the last one referenceselements from the relational and document datastores.

TABLE IOCL TO SQL MAPPING

OCL expression SQL FragmentType "Type.name"C.allInstances() select * from Co.collect(attribute) select attribute from C where id in o.ido.collect(reference) select reference from C where id in o.id(single valued)o.collect(reference) select * from reference where reference_C_id in o.id(multi valued)size() count()col1→union(col2) col1 union col2col1→including(o) col1 union select * from o.class where id = o.idcol1→excluding(o) col1 except select * from o.class where id = o.idcol→select(condition) select * from o.class where conditioncol→reject(condition) select * from o.class where not(condition)=, >, >=, <, <=, <> ==, >, >=, <, <=, <>+, -, /, %, * +, -, /, %, *and, or, not and, or, notliterals literals

select * from product where price < 0

Listing 3. Generated SQL Query from the validPrice Constraint

Currently, UMLto[No]SQL supports three simple mappings:OCLToGraphDB [9] that complements the UmlToGraphDBtransformation by generating graph queries, OCLToSQL that isadapted from existing work on UML/OCL translation to rela-tional models [3], [11], and OCLToMongoDB that maps OCLconstructs to the MongoDB query language [7]. Below we de-tail this last mapping, which is a new contribution of this paper.

A. Relational Query Mapping

SQL [16] is the obvious target for our translation process onrelational databases. Given the (mostly) universal support forthis standard language, our generated SQL expressions will beuseful no matter what particular RDBMS vendor is used.

Table I shows an excerpt of the OCL to SQL mapping usedin our translation process 3. This mapping is adapted from theone presented by Demuth et al. [11].

Specifically, attribute and single-valued association naviga-tions are mapped to projections of the corresponding columnin the table containing instances of the input object. Instancefiltering is performed based on the id field defined in our rela-tional metamodel. Element selections are mapped into selectstatements, with a where clause containing the translation of itscondition. Collection operators (such as union), mathematicaloperations, logical operators and literals are direclty translatedto their SQL equivalent.

The created fragments are combined into a query thatretrieves all the records which do not satisfy the constraint,a common pattern when evaluating OCL constraints overmodels [11]. As an example, Listing 3 shows the result ofapplying our OCL to SQL translation on the first constraintof our running example.

3We focus on the mappings applicable to the running example for brevity.

TABLE IIOCL TO GREMLIN MAPPING

OCL expression Gremlin stepType "Type.name"C.allInstances() g.V().hasLabel("C.name")collect(attribute) property(attribute)collect(reference) outE(’reference’).inVoclIsTypeOf(C) o.hasLabel("C.name")col1→union(col2) col1.fill(var1); col2.fill(var2); union(var1, var2);including(object) gather{it << object;}.scatter;excluding(object) except([object]);size() count()isEmpty() toList().isEmpty()select(condition) c.filter{condition}reject(condition) c.filter{!(condition)}exists(expression) filter{condition}.hasNext()=, >, >=, <, <=, <> ==, >, >=, <, <=, !=+, -, /, %, * +, -, /, %, *and,or,not &&,‖,!variable variableliterals literals

B. Graph Query Mapping

1) Gremlin Query Language: Gremlin is a Groovy domain-specific language built over Pipes, a lazy data-flow frameworkon top of Blueprints. We have chosen Gremlin as the targetquery language for our graph query translation due to itsadoption in several graph databases.

Gremlin is based on the concept of process graphs. A pro-cess graph is composed of vertices representing computationalunits and communication edges which can be combined tocreate a complex processing flow. In the Gremlin terminology,these complex processing flows are called traversals, and arecomposed of chains of simple computational units namedsteps. Gremlin define four types of steps: transform stepsthat map inputs of a given type to output of another one,filter steps, selecting or rejecting input elements according toa given condition, branch steps, which split the computationinto several parallel sub-traversals, and side-effect steps thatperform operations like edge or vertex creation, propertyupdate, or variable definition or assignments.

In addition, the step interface provides a set of built-inmethods to access meta information: number of objects in astep, output existence, or first element in a step. These methodscan be called inside a traversal to control its execution or checkconditions on particular elements in a step.

2) OCL to Gremlin Transformation: Table II presents themappings between OCL expressions and Gremlin concepts.Supported OCL expressions are divided into four categoriesbased on Gremlin step types: transformations, collectionoperations, iterators, and general expressions. As before, weonly present a subset of the OCL expressions we support4.

These mappings are systematically applied on the inputOCL expression, following a postorder traversal of the OCLsyntax tree. Listing 4 shows the Gremlin query generatedfrom the third OCL constraint of our running example. The v

4A complete version of this mapping is available in our previous work [10]

variable represents the vertex that is being currently checked,and the following steps are created using the mapping.

C. Document Query Mapping

1) MongoDB Query Language: We have chosen the Mon-goDB query language as a representative of the family ofquery languages for document databases. A similar mappingcould be implemented for other document query languages.Together with the DocumentDB metamodel presented in theprevious section, this OCL transformation enables a completetranslation of UML/OCL schemas to document databases.As we said above, this transformation complements otheravailable transformations from UML to other relational andNoSQL backends, including mixed solutions.

The MongoDB Query Language is a Javascript-based lan-guage that defines additional constructs to retrieve documentswithin a collection, filter them, or retrieve fields given a spe-cific condition. This language is embedded in the MongoDBshell, and can be sent for computation to a MongoDB server.

2) OCL to MongoDB Query Language Transformation: Ta-ble III shows the OCL to MongoQL mapping (again, focusingon a number of the most relevant OCL operations; many otherscan be easily reexpressed in terms the ones listed here [5]).

In the following, we explain these mappings using the exam-ple constraints introduced before. Note that we apply a similartranslation process as we did for the SQL mapping, i.e. thegenerated queries return the instances violating the constraints.

According to this, Listing 5 shows how the first constraint ismapped to a db.product.find() method with a where conditionthat traverses all documents in the product collection andreturns those with a negative price (if any). Second constraintincludes an if-then construct to first filter out unpaid orders.For the paid ones, the translation proceeds with a documentlookup (mapped to a nested collection lookup in MongoDB)to retrieve all the order lines of the order being processedsearching for at least one that violates the forAll condition inthe original OCL expression. If found, the order is returned aspart of the query result. Note that the find operation is one ofthe cornerstones of our mapping since it is expressive enoughto be the mapping target of multiple OCL operations.

In addition, we reuse the Javascript native support of thequery language to map general expressions such as arithmeticand logical operators, comparisons, literals, and variables.We also define the union, intersection, and set subtractionoperations, that can be called as regular functions. Finally, ourmapping relies on the methods push and splice of Javascriptarrays to translate including and excluding operations.

D. Cross-Datastore Query Mapping

Cross-datastore queries are OCL expressions that referenceelements in separate regions. Typically, they include a naviga-tion operation from an element in a region to an element in

v.property(’date’)>v.outE(’repliesTo’).inV.property(’date’)

Listing 4. Generated Gremlin Query from the validComment Constraint

db.product.find({$where: "this.price ≤ 0"}) // validPricedb.order.find({_id: {$where:"if(this.paid) {!(db.orderLine.find({_id: {$in : db.order.find({$where:

"_id == this._id"}, {orderLine : 1})}, $where: "this.quantity ≤ 0"}).hasNext());

} else {false}"}}); // validOrder

Listing 5. Generated MongoDB Queries from the Running Example

Context Client inv maxUnpaidOrders:// clients region (Relational)let orders : Sequence(Order) =self.orders

in// business region (Document)orders→select(o | not o.paid)→size()<3

Listing 6. Rewritten OCL Constraint Example

a neighbour region. Our approach handles such queries by: 1)translating datastore-specific fragments of the input expressioninto native database queries, and 2) providing a compositionmechanism to complete their overall evaluation.

To do so, we first perform a simple rewriting of the OCLexpression that encapsulates each datastore-specific opera-tion sequence in an intermediate variable. This initial stepdecouples datastore-specific OCL fragments, and allows toeasily translate the value of each variable using our mappings.Listing 6 shows the result of this initial processing for the thirdquery of our running example: a variable orders is created tostore the results of the self.orders navigation (from therelational region), and the in clause reuses the created variableto compute the select operation (in the document region).

This refactored OCL expression is then translated into aninstance of our Cross-Datastore Query Metamodel (Figure 10)that provides primitives to compose native database queries.Specifically, a cross-datastore script (CDScript) is composedof an ordered collection of instructions representing Functioncalls. A Function takes a set of Variables as parameters andreturns a result which is also stored in a Variable. This firstversion of our metamodel supports two kind of Functions:NativeQueries that are produced by the native translations pre-sented above, and JoinFunctions that handle the computationof cross-region associations. Generate NativeQueries take hasparameter the result of the previously executed JoinFunction,allowing to push most of the data processing to the datastores.Note that the concrete implementation of JoinFunctions isdiscussed in the next section.

Instances of the Cross-Datastore Query Metamodel aregenerated by mapping each let source expression to aNativeQuery, and each in clause to a JoinFunction adaptingthe previous query’s results, followed up by a the NativeQuerygenerated from its inner expression. Figure 11 shows theresult of this translation for the maxUnpaidOrders constraintof our running example, which contains an initial SQLQuerycomputing the orders navigation, a JoinFunction that adaptsthe Orders returned by the relational database to documents,and a final MongoQuery that computes the Order selection.

TABLE IIIOCL TO MONGODB

OCL expression MongoDB Query FragmentCl.allInstances() db.Ccl.find()o.attra db.Ctype(o).find({$where : "_id == o"},{attra: 1})o.refa db.Ctype(refa).find({_id: {$in: db.Ctype(o).find({$where : "_id == o"},{refa: 1})}})o.oclIsTypeOf(Cl) db.Ccl.contains(o)col1->union(col2) union(col1, col2)col1->intersection(col2) intersection(col1, col2)col1 - (col2) (set subtraction) subtract(col1, col2)col->including(o) col.push(o)col->excluding(o) col.splice(col.indexOf(o), 1)col->select(condition) db.C.find({_id: {$in: col}, $where : "condition"})col->reject(condition) db.C.find({_id: {$in: col}, $where : "!(condition)"})col->exists(expression) db.C.find({_id: {$in: col}, $where : "condition"}).hasNext()col->forAll(expression) !(db.C.find({_id: {$in: col}, $where : "!(condition)"}).hasNext())col->size() C.lengthcol->isEmpty() C.length == 0if(c) then e1 else e2 endif if(c) { e1} else {e2}=, >, >=, <, <=, <> ==, >, >=, <, <=, !=+, -, /, %, * +, -, /, %, *and, or, not &&, ‖, !variable variable

Legend — Cl: class; o: object; col: object collection; Ca: database collection containing objects of type a; the :1 suffix is a boolean flag to indicate theexpression should return only the indicated field and not the whole document.

Fig. 10. Cross-Datastore Query Metamodel

Fig. 11. Cross-Datastore Query Instance

VI. CODE GENERATION

As a final step in UMLto[No]SQL, a code generationprocess takes as input the previous PSMs and query modelsand generates the software artifacts to guarantee the properimplementation of such models in the chosen data stores.

The concrete artifacts to generate depends on the type ofstorage solution. For instance, for relational databases, most ofthe code generation focuses on creating the SQL DDL scriptsto setup the database. Instead, for NoSQL databases (whichare mostly schemaless), a large part of the generation processis devoted to producing application code that integrates and

enforces the designed structures and constraints. To ease thisprocess, we provide a generic Modeling Layer that definesprimitives to persist, query, and update data in NoSQL data-stores. The generated application code is then plugged intothis generic infrastructure, and extends it to provide additionaloperations derived from the conceptual schema (e.g. getting allthe clients stored in the system).

Figure 12 shows the architecture of our generic ModelingLayer. The Middleware class is the central component thatallows to create, search, and delete Beans representing themodel elements at the PIM level. It contains a set of Datastoresthat are responsible for the raw database initialization andaccesses. Currently, our framework embeds three Datastoresubclasses, that allow to access MongoDB, PostgreSQL, andBlueprints. The Middleware also embeds a set of QueryPro-cessors, that are responsible of the constraint computation.NativeProcessors support the execution of native queries overtheir associated Datastore, and CDProcessor handles the com-putation of cross-datastore queries. The CDProcessor relies ona set of NativeProcessors that are used to compute the nativefragment of the composite query, and uses the join methodprovided by the Datastores to compute the join functionintroduced in Section V. This method retrieves the storedrecords matching the provided UUIDs and type, that can beprovided as input of the next composite query computationdefined in the CDQuery. Note that these functions do notreturn Bean instances, but native objects that can be handledby the Datastore to compute a query.

The UMLto[No]SQL code generator creates additionalclasses that extend the ones shown in Figure 12 (light-greynodes). Individual Beans are created, wrapping the classesdefined in the conceptual schema, allowing to natively ma-nipulate them. In our example, this process generates the

Fig. 12. UMLto[No]SQL Modeling Layer Infrastructure

Client, Order, Product, and OrderLine beans, and creates aset of methods to access and update their attributes and relatedassociations by delegating the operation transparently on thecorresponding datastore. Finally, a specific implementationof the Middleware class containing the generated constraintQueries, and initialized with the Datastores and QueryPro-cessors associated to the conceptual schema is also generated.

We would like to remark that an important benefit of thismiddleware is that it enables users to access the data using thesame concepts and types they employed when modeling thedomain, regardless of how those model elements have beenrefined and transformed to implement them in the data store.Still, our approach can be used to simply generate standalonedatabase artifacts, that could then be integrated into separatesolutions.

public class Order extends MongoBean {public Order(ObjectId id, MongoDatastore mongoDatastore){super(id, mongoDatastore); }

public Date getShipmentDate() {Long timestamp = getValue("shipmentDate");return new Date(timestamp); }

public void setShipmentDate(Date newShipmentDate) {Long timestamp = newShipmentDate.getTime();updateField("shipmentDate", timestamp); }

// Cross-datastore referencepublic Client getClient() throws ConsistencyException {ObjectId clientId = getValue("client");return DemoMiddleware.getInstance().getClient(clientId.

toString()); }public void setClient(Client newClient) {if(isNull(newClient))

throw new ConsistencyException("Cannot set nullClient, the association cardinality is 1");

String clientId = newClient.getId();ObjectId oId = new ObjectId(clientId);updateField("client", oId); }

}

Listing 7. Generated Order Class

As an example, the Listing 7 shows an excerpt of the codegenerated for the class Order. The generated bean extendsthe MongoBean class, that provides generic methods such asgetValue and updateField, and is responsible of the connectionto the underlying MongoDatastore. Getters and setters aregenerated for all the attributes and associations. The getClientmethod shows how cross-datastore associations are handled:the UUID stored in the the Order document is deserialized intoa String, that is used to retrieve the Client instance thanks to

the Middleware singleton class (which delegate the search tothe relational database managing Client instances). A similarprocess is followed to implement the constraints. See theproject repository for a full implementation of the example.

VII. RELATED WORK

UMLto[No]SQL can be related to several works focusing onthe mapping of conceptual schemas to databases. We proposehere a classification of relevant approaches into two families:generative approaches that translate conceptual schemas todata storage solutions, and abstraction layers built on top ofexisting backends that aim to unify them under a commonmodel/API that could be used to simplify the mapping.

The mapping of conceptual schemas to relational databasesis a well-studied field of research [20]. A few works also cover(OCL) constraints. For example, Demuth and Hussman [11]provide a code generator from UML/OCL to SQL [12]. Simi-larly, Brambilla et al. [3] propose a methodology to implementintegrity constraints into relational databases recommendingalternative implementations based on performance parameters.Fewer works address non-relational databases. Zhao et al. [29]propose an approach to model MongoDB databases startingfrom a relational model. Li et al.focus on the transformationfrom UML class diagrams into HBase [19] while NoSQLSchema Evaluator [21] focuses on generating column familydefinitions and query implementation plans from a conceptualschema optimized for a given workload. Nevertheless, noneof these approaches support multiple data stores nor providesupport for the constraint mapping part.

On the other hand, some approaches try to provide somekind of modeling language or abstraction to simplify theinteraction with NoSQL databases. Bugiotti et al. [4] propose adesign methodology for NoSQL databases based on NoAM, anabstract data model that aims to represent NoSQL systems in asystem-independent way. NoAM models can be implementedin several NoSQL databases. Federated data management andquerying approaches can also be related to our work [13].For instance, CloudMdsQL [17] is a SQL-like query languagecapable of querying multiple data stores within a single query.To do so, the language extends the standard SQL syntax withadditional constructs allowing to call native queries that targeta specific datastore. Apache Drill [15] is a similar framework

that provides an extended SQL syntax to query multiple datasources including relational databases, Json documents, ordocument databases. These approaches could be potentiallyuseful as intermediate representations in our own mappingprocess as a way to enlarge the number of stores that wecould support but we believe our UML-based approach offersa lower barrier of entry since it allows designers to model theirschemas using well-known notations (and tools, most likelyalready part of their standard modeling tool chain) instead ofrequiring them to learn new languages and adhoc solutionsfrom the very beginning.

VIII. CONCLUSION AND FUTURE WORK

In this paper we have presented UMLto[No]SQL, a MDA-based framework to partition and map conceptual schemas toseveral data storage solutions. Our approach combines modelmapping techniques with a set of rules to translate OCLconstraints into various native query languages, including anad-hoc mechanism to compute multi-platform queries. Ourcode generator hides all internal details of the chosen datastores, allowing designers to keep a unified view of the modelregardless the actual data storage.

As future work, we plan to evaluate our approach throughreal-world use cases, and benefit from the modular architectureof our framework to add more data storage options. We alsowant to improve the flexibility of our approach by proposingPSM-level refactoring operations to let designers tune themappings according to specific needs (e.g. performancerequirements, availability, data replication, data locality, etc.).In addition, we plan to benchmark the performance of theproduced queries, especially cross-datastore ones. In thissense, we also envision to reuse advanced query compositiontechniques such as CloudMdsQL [17] or Apache Drill [15].

Another ongoing work is the integration of automaticschema partitioning techniques according to an expected/mea-sured workload. This optimization problem has been heavilystudied in the context of relational database physical schemadesign [1], [14], and can be adapted to define regions on theconceptual schema. Finally, we would like to work on thereverse direction, i.e. the automatic extraction of conceptualschemas from an existing set of datastores. This is a complexproblem even when targeting a single NoSQL data store (e.g.see works such as [26] or [8]) that becomes much harder totackle when considering the relationships between data acrossdifferent data stores.

ACKNOWLEDGEMENT

This work was supported by the Programa Estatal deI+D+i Orientada a los Retos de la Sociedad Spanish program(Ref. TIN2016-75944-R); and the ECSEL Joint Undertakingunder grant agreement No. 737494 – MegaM@Rt2. This JointUndertaking receives support from the European Union’sHorizon 2020 research and innovation program and fromSweden, France, Spain, Italy, Finland & Czech Republic.

REFERENCES

[1] S. Agrawal, V. Narasayya, and B. Yang. Integrating Vertical andHorizontal Partitioning into Automated Physical Database Design. InProc. of the ACM SIGMOD International Conference on Managementof Data, pp. 359–370. ACM, 2004.

[2] G. Blair, N. Bencomo, and R. France. Models@run.time. Computer,42(10), 2009.

[3] M. Brambilla and J. Cabot. Constraint Tuning and Management for WebApplications. In Proc. of the 6th ICWE Conference, pp. 345–352, 2006.

[4] F. Bugiotti, L. Cabibbo, P. Atzeni, and R. Torlone. Database Design forNoSQL Systems. In Proc. of the 33rd ER Conference, pp. 223–231.Springer, 2014.

[5] J. Cabot and E. Teniente. Transformation Techniques for OCL Con-straints. SCP, 68(3):179 – 195, 2007.

[6] R. Cattell. Scalable SQL and NoSQL Data Stores. Acm Sigmod Record,39(4):12–27, 2011.

[7] K. Chodorow. MongoDB: The Definitive Guide: Powerful and ScalableData Storage. O’Reilly Media, Inc., 2013.

[8] I. Comyn-Wattiau and J. Akoka. Model Driven Reverse Engineering ofNoSQL Property Graph Databases: The Case of Neo4j. In Proc. of BigData 2017, pp. 453–458. IEEE, 2017.

[9] G. Daniel, G. Sunyé, and J. Cabot. UMLtoGraphDB: Mapping Concep-tual Schemas to Graph Databases. In Proc. of the 35th ER Conference,pp. 430–444. Springer, 2016.

[10] Gwendal Daniel, Gerson Sunyé, and Jordi Cabot. Mogwaï: a frameworkto handle complex queries on large models. In Proc. of the 10th RCISConference, pp. 1–12. IEEE, 2016.

[11] B. Demuth and H. Hussmann. Using UML/OCL Constraints forRelational Database Design. In Proc. of the 2nd UML Conference, pp.598–613. Springer, 1999.

[12] B. Demuth, H. Hußmann, and S. Loecher. OCL as a SpecificationLanguage for Business Rules in Database Applications. In Proc. of the4th UML Conference, pp. 104–117. Springer, 2001.

[13] Olaf Görlitz and Steffen Staab. Federated data management and queryoptimization for linked open data. In New Directions in Web DataManagement 1, pp. 109–137. Springer, 2011.

[14] M. Grund, J. Krüger, H. Plattner, A. Zeier, P. Cudre-Mauroux, andS. Madden. HYRISE: a Main Memory Hybrid Storage Engine. Proc.of the VLDB Endowment, 4(2):105–116, 2010.

[15] M. Hausenblas and J. Nadeau. Apache Drill: Interactive Ad-HocAnalysis at Scale. Big Data, 1(2):100–104, 2013.

[16] International Organization for Standardization. ISO/IEC 9075-1:2016,2019. URL: https://www.iso.org/standard/63555.html.

[17] B. Kolev, P. Valduriez, C. Bondiombouy, R. Jiménez-Peris, R. Pau, andJ. Pereira. CloudMdsQL: Querying Heterogeneous Cloud Data Storeswith a Common Language. DAPD, 34(4):463–503, 2016.

[18] François Lagarde, Huáscar Espinoza, François Terrier, and SébastienGérard. Improving uml profile design practices by leveraging conceptualdomain models. In Proc. of the 22nd ASE Conference, ASE ’07, pp.445–448, New York, NY, USA, 2007. ACM.

[19] Y. Li, P. Gu, and C. Zhang. Transforming UML Class Diagrams intoHBase Based on Meta-Model. In Proc. of the 4th ISEEE Conference,volume 2, pp. 720–724. IEEE, 2014.

[20] E. Marcos, B. Vela, and J.M. Cavero. A Methodological Approach forObject-Relational Database Design Using UML. SoSyM, 2(1):59–72,2003.

[21] M.J. Mior, K. Salem, A. Aboulnaga, and R. Liu. NoSE: Schema Designfor NoSQL Applications. IEEE TKDE, 29(10):2275–2289, 2017.

[22] A. Moniruzzaman and S.A. Hossain. NoSQL Database: New Era ofDatabases for Big Data Analytics - Classification, Characteristics andComparison. IJDTA, 6(4):1–14, 2013.

[23] OMG. MDA Specifications, 2018. URL: http://www.omg.org/mda/specs.htm.

[24] OMG. About the Object Constraint Language Specification Version 2.4,2019. URL: https://www.omg.org/spec/OCL/2.4/.

[25] OMG. About the Unified Modeling Language Specification Version2.5.1, 2019. URL: https://www.omg.org/spec/UML/2.5.1/.

[26] D. Ruiz, S. Morales, and J. Molina. Inferring Versioned Schemasfrom NoSQL Databases and Its Applications. In Proc. of the 34th ERConference, pp. 467–480. Springer, 2015.

[27] B. Selic. A systematic approach to domain-specific language designusing uml. In Proc.of the 10th ISORC Symposium, volume 00, pp. 2–9,05 2007.

[28] Tinkerpop. Tinkerpop Website, 2018. URL: www.tinkerpop.com.[29] G. Zhao, W. Huang, S. Liang, and Y. Tang. Modeling MongoDB with

Relational Model. In Proc. of the 4th EIDWT Conference, pp. 115–121.IEEE, 2013.