Open Archive Toulouse Archive Ouverte

OATAO is an open access repository that collects the work of Toulouse

researchers and makes it freely available over the web where possible

This is an author’s version published in:

http://oatao.univ-toulouse.fr/19119

Official URL: https://ieeexplore.ieee.org/document/8308297

DOI : http://doi.org/10.1109/AICCSA.2017.76

To cite this version: Abdelhédi, Fatma and Ait Brahim, Amal

and Atigui, Faten and Zurfluh, Gilles UMLtoNoSQL: Automatic
Transformation of Conceptual Schema to NoSQL Databases. (2017)
In: 14th International Conference on computer Systems And
Applications (AICCSA 2017), 30 October 2017 - 3 November 2017
(Hammamet, Tunisia).

Any correspondence concerning this service should be sent

to the repository administrator: [email protected]
 UMLtoNoSQL: Automatic Transformation of Conceptual Schema to NoSQL
Databases

Fatma ABDELHEDI Amal AIT BRAHIM Faten ATIGUI Gilles ZURFLUH

CBI2 – TRIMANE IRIT, Toulouse Capitole CEDRIC- CNAM IRIT, Toulouse Capitole
University University
Paris, France Toulouse, France Paris, France Toulouse, France
[email protected] [email protected] [email protected] [email protected]

Abstract—Volume, Variety and Velocity are the three While NoSQL systems have proven their efficiency to
dimensions that have definitely changed the tools we need to handle Big Data, it is still an unsolved problem how the
store and process Big Data effectively, giving rise to NoSQL automatic storage of Big Data in NoSQL systems could
systems for faster data access, better scalability and higher be done. In our view, it is important to have a precise and
flexibility. While NoSQL systems have proven their automatic approach that helps and assists developer in the
efficiency to handle Big Data, it is still an unsolved problem Big Database implementation task within NoSQL
how the automatic storage of Big Data in NoSQL systems systems. One solution for addressing this problem is to
could be done. One solution for addressing this problem is model Big Data, and then define mapping rules towards
to model Big Data, and then define mapping rules towards
the physical level. As discussed in the related work (see
the physical level. This paper proposes an automatic MDA-
section 5), there are only few solutions that focus on
based approach that translates conceptual models expressed
using the Unified Modeling Language (UML) into NoSQL mapping UML conceptual models into NoSQL physical
physical models. Our approach rely on an intermediate models.
logical model compatible with column, document and graph To overcome this situation, we propose the
oriented systems which allows to choose the system type that UMLtoNoSQL approach that automatically translates
suits the best with business rules and technical constraints. conceptual models expressed using the Unified Modeling
Language (UML) into several NoSQL physical models.
Keywords-UML conceptual model; NoSQL; Big Data This approach is based on the Model Driven Architecture
storage; MDA; Models Transformation (MDA) especially known as a framework for models
automatic transformations and allows the developer to
I. CONTEXT AND RESEARCH PROBLEM choose the system type (column, document or graph) that
Big data have received a great deal of attention in suits the best with business rules and technical
recent years. Not only the amount of data is on a constraints.
completely different level than before, but also we have The rest of the paper is structured as follows: Section
different type of data including factors such as format, 2 motivates our work using a case study in the healthcare
structure, and sources. In addition, the speed at which field. Section 3 introduces our approach; two
these data must be collected and analyzed is increasing. transformations processes are presented in this section,
This has definitely changed the tools we need to benefit the first one creates a NoSQL generic model starting
from Big Data, giving rise to new kinds of data from a UML conceptual model, and the second one
management tools. NoSQL systems are a widely generates NoSQL physical models from this generic
accepted tool able to support larger volumes of data by model; Section 4 details our experiments; Section 5
providing faster data access, better scalability and higher reviews previous work on models transformation; Section
flexibility [16]. 6 provides a discussion on our approach and announces
The lack of a model when creating a database is a key future work. Finally, Section 7 concludes the paper.
feature in NoSQL systems. In a table, attributes names
and types are specified as and when the row is entered II. ILLUSTRATIVE EXAMPLE
[8]. Unlike relational systems, where the model must be To motivate our work and illustrate the different steps
defined when creating the table, the schema less appears of our approach, we introduce in this section an example
in NoSQL systems. This property offers undeniable of Big Data application in the healthcare filed. This
flexibility that facilitates the evolution of models in application concerns international scientific programs for
NoSQL systems; but, it concerns exclusively the physical monitoring patients suffering from serious diseases. The
level (implementation) of a database [2]. A conceptual main goal of this program is (1) to collect data about
model is still required to define how data are stored and diseases development over time, (2) to study interactions
related in the database [3]. It provides a high level of between different diseases and (3) to evaluate the short
abstraction and a semantic knowledge element close to and medium-term effects of their treatments. The medical
human logic, which guarantees efficient data program can last up to 3 years.
management [1]. The Unified Modeling Language
(UML) has gained much attention in this area [1].

DOI 10.1109/AICCSA.2017.76
 Figure 1. Overview of UMLtoNoSQL process.

Data collected from establishments involved in this conceptual (business description) and physical (technical
kind of program have the features of Big Data (the 3 V): description) levels in which a generic logical model is
Volume: the amount of data collected from all the developed. This logical model exhibits a sufficient degree
establishments in three years can reach several terabytes. of independence so as to enable its mapping to one or
more NoSQL platforms. Developers will benefit from it
Variety: data created while monitoring patients come in
in two ways: (1) it describes data according to the
different types; it could be (1) structured as the patient's
common features of NoSQL models (column, document
vital signs (respiratory rate, blood pressure, etc.), (2) and graph), which allow it’s mapping on several
semi-structured document such as the package leaflets of platforms. (2) it abstracts out technical details of NoSQL
medicinal products, (3) unstructured such as consultation systems, this mean that the logical level remains stable,
summaries, paper prescriptions and radiology reports. even though the NoSQL system evolves over time. In this
Velocity: some data are produced in continuous way by case, it would be enough to evolve the physical model,
sensors; it needs a [near] real time process because it and of course adapt the transformation rules; this
could be integrated into a time-sensitive processes (for simplifies the transformation process and saves time for
example, some measurements, like temperature, require developers.
an emergency medical treatment if they cross a given To formalize and automate UMLtoNoSQL process,
threshold). we use the Model Driven Architecture (MDA) proposed
This is a typical example in which the use of a by the OMG [4]. One of the main aims of MDA is to
NoSQL system is suitable. As mentioned. This kind of separate the functional specification of a system from the
systems operate on schema less data model enabling details of its implementation in a specific platform. This
users to quickly and easily incorporate new data into their architecture defines a hierarchy of models from three
applications without rewriting tables. Nevertheless, there points of view: Computation Independent Model (CIM),
is still a need for a semantic model to know how data are Platform Independent Model (PIM), and Platform
structured and related in the database; this is particularly Specific Model (PSM) [5]. Among this proposed models,
necessary to write declarative queries where tables and we use:
columns names are specified. UMLtoGenericModel (1) is the first transformation
UML is widely accepted as a standard modelling (section 3.1) in UMLtoNoSQL process. It is in charge of
language for describing complex data. In the medical converting the input UML class diagram (conceptual
application, briefly presented above, the database PIM) into the generic logical model (2) conforming to the
contains structured data, data of various types and generic logical metamodel proposed in Section 3.1.2; this
formats (explanatory texts, medical records, x-rays, etc.), metamodel describes a data structure compatible with the
and big tables (records of variables produced by sensors). three types of NoSQL systems.
Therefore, we choose the UML class diagram to describe GenericModeltoPhysicalModel (3) is the second
the medical data. transformation (section 3.2) in UMLtoNoSQL process. It
is in charge of transforming the generic logical model
III. CONTRIBUTION into NoSQL physical models (PSMs) (4).
Our purpose in this paper is to assist developers in We note that UMLtoNoSQL process generates
storing Big Data in NoSQL systems. For this, we propose several NoSQL physical models from a UML class
the UMLtoNoSQL approach that automatically diagram. In order to do this, it’s necessary to register, for
transforms a UML conceptual model describing Big Data each physical model, its specific parameters
into a NoSQL physical model. (transformation rules). To illustrate our work, we have
In our approach, we introduce a logical level between taken as example three physical models that correspond
to: Cassandra, MongoDB and Neo4j systems. If the variable number of attributes. The schema of
developer chooses to use another system, the process each attribute ƒ୲ ‫ א‬A is a pair (N,Ty) where
must be completed by adding new parameters specific to “ƒ୲ .N” is the attribute name and “ƒ୲ .Ty” the
this system. attribute type.
A. UMLtoGenericModel Transformation • t. †‡–୲ is a special attribute of t; it has a name
†‡–୲ .N and a type called “Rid”. In this paper,
In this section we present the UMLtoGenericModel an attribute whose type is “Rid” represents a
transformation, which is the initial step in our approach unique row identifier, i.e. an attribute whose
presented in Figure 1. We first define the source (UML value distinguishes a row from all other rows of
Class Diagram) and the target (Generic Logical Model), the same table.
and then we focus on the transformation itself.
Source: A Class Diagram (CD) is defined as a tuple R is a set of binary relationships. In the generic logical
(N, C, L), where: model there are only binary relationships between tables.
N is the class diagram name, Each relationship r ‫א‬R between –ଵ and – ଶ is defined as a
C is a set of classes. Classes are composed from tuple (N,” ୰ ), where:
structural and behavioral constituents; in this paper, we • r.N is the relationship name.
consider only the structural part. Since the operations are • r.” ୰ = {’”ଵ୰ ǡ ’”ଶ୰ } is a set of two pairs. ‫׊‬i ‫א‬
linked to the behavior, we will not take them into {1,2}, ’”୧୰ = (t, ” ୲ ), where ’”୧୰ .t is a related table
account. The schema of each class c ‫א‬C is a tuple (N, A, and ’”୧୰ . ” ୲ is the cardinality placed next to t.
†‡–ୡ ), where: Metamodel of the proposed generic logical model is
• c.N is the class name. shown in Figure 3. Note that the attribute value may be
• c.A = {ܽଵ௖ ǡ ǥ ǡ ܽ௤௖ } is a set of q attributes. The either atomic or complex (set of attributes). We represent
schema of each attribute ܽ௖ ‫ א‬A is a pair (N,C) this by using the XOR constraint (UML predefined
where “ܽ௖ .N” is the attribute name and “ܽ௖ .C” constraint).
the attribute type; C can be a predefined class, i.e.
a standard data type (String, Integer, Date ...) or a
business class (class defined by user).
• c. †‡–ୡ is a special attribute of c; it has a
name †‡–ୡ .N and a type called “Oid”. In this
paper, an attribute whose type is “Oid” represents
a unique object identifier, i.e. an attribute whose
value distinguishes an object from all other
objects of the same class.
L is a set of links. Each link l between n classes, with
n>=2, is defined as a tuple (N, Ty,ܲ‫ ݎ‬௟ ), where:
• l.N is the link name.
• l.Ty is the link type. In this paper, we will only
consider the three main types of links between
classes: Association, Composition and
Generalization.
• l.” ୪ = {’”ଵ୪ ǡ ǥ ǡ ’”୬୪ } is a set of n pairs. ‫׊‬i ‫א‬
{1,..,n}, ’”୧୪ = (c, ” ୡ ), where ’”୧୪ .c is a linked
Figure 2. Source Metamodel.
class and ’”୧୪ . ” ୡ is the cardinality placed next to
c. Note that ’”୧୪ . ” ୡ can contain a null value if no
cardinality is indicated next to c (like in
generalization link).
Class diagram metamodel is shown in Figure 2; this
metamodel is adapted from the one proposed by the
OMG [7].
Target: The target of UMLtoGenericModel
transformation corresponds to a generic logical model
that describes data according to the common features of
the three types of NoSQL systems: column-oriented,
document-oriented and graph-oriented. In the generic
logical model, a DataBase (DB) is defined as a tuple (N,
T, R), where:
N is the database name, {XOR}

T is a set of tables. The schema of each table t ‫א‬T is a

tuple (N, A, †‡–௧ ), where:
• t.N is the table name.
• t.A = {ƒ୲ଵ ǡ ǥ ǡ ƒ୲୯ } is a set of q attributes that will
be used to define rows of t; each row can have a Figure 3. Target Metamodel.
Transformation Rules: R6: each association class ୟୱୱ୭ between n classes
R1: each class diagram CD is transformed into a database { ଵ ǡ ǥ ǡ ୬ } (n>=2) is transformed like a link between
DB, where DB.N = CD.N. multiple classes (R5) using (1) a new table – ୟୡ , where
R2: each class c ‫ א‬C is transformed into a table t ‫ א‬DB, – ୟୡ .N = l.N, and (2) n relationships {”ଵ ǡ ǥ ǡ ”୬ }, ‫ ׊‬i ‫א‬
where t.N = c.N, †‡–୲ .N = †‡–ୡ .N. {1,..,n} ”୧ links – ୟୡ to another table – ୧ representing a
R3: each attribute ƒୡ ‫ א‬c.A is transformed into an related class ୧ , where ”୧ .N = (– ୟୡ .N)_(– ୧ .N) and ”୧ .” ୰ =
attributeƒ୲ , where ƒ୲ .N = ƒୡ .N, ƒ୲ .Ty = ƒୡ .C, and added {(– ୟୡ , null), (– ୧ , null)}. Like any other table, – ୟୡ contain
to the attribute list of its transformed container t such as also a set of attributes A, where – ୟୡ .A = ୟୱୱ୭ .A.
ƒ୲ ‫ א‬t.A. Example:
R4: each binary link l ‫ א‬L (regardless of its type: The association class “Category” that links the
Association, Composition or Generalization) between the classes: “Patients” and “Antecedents” is transformed by
classes ଵ and ଶ is transformed into a relationship r ‫ א‬R applying R6 into: (1) a new table “T-Category” that
between the tables –ଵ and – ଶ representing ଵ and ଶ , contain the attribute “category” and (2) two relationships:
where r.N = l.N, r.” ୰ = {(–ଵ , ” ୡభ ),(– ଶ , ” ୡమ )}, ” ୡభ and “R-Category_Patients” and “R-Category_Antecedents”
” ୡమ are the cardinality placed respectively next to ଵ and that relate “T-Category” respectively to “T-Patients” and
ଶ. “T-Antecedents”.
Example:
As an example, consider the classes “Prescriptions”
and “Protocols”, and the link “Update”. Applying the
transformation rules R2 and R3 generates the tables “T-
Prescriptions” and “T-Protocols”. As soon as R4 applies,
the appropriate transformation is made, and the link
“Update” is transformed into a relationship “R-Update”
as follow:
These transformation rules have also been specified
with QVT (Query / View / Transformation), which is a
standard defined by OMG for expressing models
transformation. An excerpt from QVT rules is shown in
Figure 6.
B. GenericModeltoPhysicalModel Transformation
In this section we present the
GenericModeltoPhysicalModel transformation, which is
R5: each link l ‫ א‬L between n classes { ଵ ǡ ǥ ǡ ୬ } (n>=3) the second step in our approach UMLtoNoSQL (figure
is transformed into (1) a new table – ୪ , where – ୪ .N = l.N 1). It is in charge of creating NoSQL physical models
and – ୪ .A = ‫׎‬, and (2) n relationships {”ଵ ǡ ǥ ǡ ”୬ }, ‫ ׊‬i ‫א‬ from the proposed generic logical model.
{1,..,n} ”୧ links – ୪ to another table – ୧ representing a related Source: The source of
class ୧ , where ”୧ .N = (– ୪ .N)_(– ୧ .N) and ”୧ .” ୰ = {(– ୪ , GenericModeltoPhysicalModel transformation is the
null), (– ୧ , null)}. target of the previous UMLtoGenericModel
Example: transformation.
In the example shown below, the n-ary link “Consult” Target: To illustrate our approach, we have chosen:
that relates the classes: “Patients”, “Doctors” and “Dates” Cassandra (column-oriented), MongoDB (documents-
is transformed by applying R5 into: (1) a new table “T- oriented) and Neo4j (graph-oriented); three well known
Consult” that does not contain attributes and (2) three NoSQL systems.
relationships: “R-Consult_Patients”, “R- In Cassandra physical model, KeySpace (KS) is the
Consult_Doctors” and “R-Consult_Dates” that relate “T- top-level container that owns all the elements. It’s
Consult” respectively to “T-Patients”, “T-Doctors” and defined as a tuple (N, F), where:
“T-Dates”.We note that the tables “T-Patients”, “T- N is the keyspace name,
Doctors” and “T-Dates” were created by applying R2 and F is a set of columns-families. The schema of each
R3. columns family f ‫א‬F is a tuple (N, Cl, ”‹ƒ”›‡› ୤ ),
where:
• f.N is the columns-family name,
• f.Cl = { Žଵ ǡ ǥ ǡ Ž୯ } is a set of q columns that will
be used to define rows of f; each row can have a
variable number of columns. The schema of each
column cl ‫ א‬Cl is a pair (N,Ty) where “cl.N” is
the column name and “cl.Ty” the column type.
• f.”‹ƒ”›‡› ୤ is a special column of f; it has a
name ”‹ƒ”›‡› ୤ .N and a type
”‹ƒ”›‡› ୤ .Ty (standard data type).
”‹ƒ”›‡› ୤ identifies uniquely each row of f.
 In MongoDB physical model, DataBase ( ୑ୈ ) is R4: As Cassandra does not support imbrication; the only
the top-level container that owns all the elements. It’s solution we can use to express relationships between
defined as a tuple (N, Cll), where: columns-families consists in using reference columns. A
N is the database name, reference column is a monovalued or multivalued column
Cll is a set of collections. The schema of each collection in one columns-family whose values must have matching
cll ‫א‬Cll is a tuple (N, Fl, †ୡ୪୪ ), where: values in the primary key of another columns-family; we
• cll.N is the collection name, note that this constraint is not automatically managed by
the system Cassandra; it remains the responsibility of the
• cll.Fl = Ž୅ ‫Ž ׫‬େଡ଼ is a set of atomic and complex
user to check it.
fields that will be used to define rows, called
For each relationship r between two tables –ଵ and – ଶ ,
documents, of Cll. Each document can have a
three solutions could be considered:
variable number of fields. The schema of an
Solution 1: r is transformed into a reference column cl
atomic field ˆŽୟ ‫Ž א‬୅ is a tuple (N,Ty) where
referencingˆଶ (the columns-family representing– ଶ ),
“ˆŽୟ .N” is the field name and “ˆŽୟ .Ty” is the field
where cl.N = (ˆଶ .N)_Ref and cl.Ty = ”‹ƒ”›‡› ୤ଶ .Ty,
type. The schema of a complex field ˆŽୡ୶ ‫Ž א‬େଡ଼ is
and then added to the columns list of ˆଵ (the columns-
also a tuple (N, Fl’) where ˆŽୡ୶ .N is the field
family representing–ଵ ) such as cl ‫ˆ א‬ଵ .Cl. While
name and ˆŽୡ୶ .Fl’ is a set of fields where Fl’⊂ Fl.
instantiatingˆଵ , the value of the reference column cl will
• cll. †ୡ୪୪ is a special field of cll; it has a name correspond to one or many values in the primary key of
†ୡ୪୪ .N and a type †ୡ୪୪ .Ty (standard data ˆଶ .
type). †ୡ୪୪ identifies uniquely each document of Solution 2: r is transformed into a reference column cl
cll. referencingˆଵ (the columns-family representing–ଵ ),
In Neo4j physical model, Graph (GR) is the top-level where cl.N = (ˆଵ .N)_Ref et cl.Ty = ”‹ƒ”›‡› ୤ଵ .Ty,
container that owns all the elements. It’s defined as a and then added to the columns list of ˆଶ (the columns-
tuple (V, E), where: family representing– ଶ ) such as cl ‫ˆ א‬ଶ .Cl. While
V is a set of vertex. The schema of each vertex v ‫א‬V is a instantiatingˆଶ , the value of the reference column cl will
tuple (L, Pro, †୴ ), where: correspond to one or many values in the primary key
• v.L is the vertex label, ofˆଵ .
• v.Pro = {’”‘ଵ ǡ ǥ ǡ ’”‘୯ } is a set of q properties. Solution 3: r is transformed into a new columns-family f
The schema of each property pro ‫ א‬Pro is a pair composed of two reference columns referencing the
(N,Ty), where “pro.N” is the property name and columns-families ˆଵ and ˆଶ representing the related tables
“pro.Ty” the property type. –ଵ and – ଶ , where f.N = r.N, f.Cl = { Žଵ ǡ Žଶ}, Žଵ .N =
• v. †୴ is a special property of v; it has a name (ˆଵ .N)_Ref, Žଵ .Ty = ”‹ƒ”›‡› ୤ଵ .Ty, Žଶ .N =
†୴ .N, a type †୴ .Ty and the constraint “Is (ˆଶ .N)_Ref and Žଶ .Ty = ”‹ƒ”›‡› ୤ଶ .Ty.
Unique ”. It identifies uniquely v in the graph. A reference column can either be monovalued or
E is a set of edges. The schema of each edge e ‫א‬E is a multivalued. Table 1 indicates the type of the reference
tuple (L, ‫ݒ‬ଵ , ‫ݒ‬ଶ ), where: column according to the relationship cardinalities and the
• e.L is the edge label, transformation solution used.
• e.˜ଵ and e.˜ଶ are the vertexes related by e.
TABLE I. DESCRIPTIVE TABLE OF REFERENCE COLUMN TYPES
Transformation Rules: For some NoSQL systems,
many solutions can ensure the implementation of the Relationship Solution Reference
generic logical model. In order to choose the most column type
suitable solution, the developer can use the performance
r= Solution 1 Monovalued
measurement shown in Section 4.2. These measurements
concern the response time of queries that accesses to two (N,{(–ଵ ,*),( – ଶ ,1)}) Solution 2 Multivalued
related tables; the relationship between these tables has Solution 3 Monovalued
been implemented according to the different solutions r= Solution 1 Monovalued
shown below. The developer will make his choice (N,{(–ଵ ,1),( – ଶ ,1)}) Solution 2 Monovalued
according to the characteristics of queries he wants to
Solution 3 Monovalued
perform and the expected performances.
We note that the set of solutions proposed in this r= Solution 1 Multivalued
section is not inclusive; more marginal solutions may be (N,{(–ଵ ,*),( – ଶ ,*)}) Solution 2 Multivalued
considered. Solution 3 Monovalued
To Cassandra physical model:
R1: each database DB is transformed into a keyspace KS,
where KS.N = DB.N. To MongoDB physical model:
R2: each table t ‫ א‬DB is transformed into a columns- R1: each database DB is transformed into a MongoDB
family f ‫ א‬KS, where f.N = t.N, ”‹ƒ”›‡› ୤ .N = database ୑ୈ , where  ୑ୈ .N = DB.N.
†‡–୲ .N. R2: each table t ‫ א‬DB is transformed into a collection cll
R3: each attribute ƒ୲ ‫ א‬t.A is transformed into a column ‫୑  א‬ୈ , where cll.N = t.N et †ୡ୪୪ .N = †‡–୲ .N.
cl, where cl.N = ƒ୲ .N, cl.Ty = ƒ୲ .Ty, and added to the R3: each attribute ƒ୲ ‫ א‬t.A is transformed into an atomic
column list of its transformed container f such as cl ‫א‬ field ˆŽୟ , where ˆŽୟ .N = ƒ୲ .N, ˆŽୟ .Ty = ƒ୲ .Ty, and added to
f.Cl.
the field list of its transformed container cll such as fl ‫א‬ vertex ˜ଵ and ˜ଶ , where ˜ଵ and ˜ଶ are the vertex
cll. Ž୅ . representing –ଵ and – ଶ .
R4: relationships in MongoDB could be transformed by
using reference fields or embedding. A reference field is IV. EXPERIMENTS
a monovalued or multivalued field in one collection In this section we show how to implement the
whose values must have matching values in the Id of UMLtoNoSQL process according to each transformation
another collection; checking this constraint remains the solution proposed in section 3.2. Then we evaluate the
responsibility of the user. performances of each solution in order to assist developer
For each relationship r between two tables –ଵ and – ଶ , in choosing the most effective one.
five solutions could be considered:
Solution 1: r is transformed into a reference field fl A. Implementation
referencing ŽŽଶ (the collection representing– ଶ ), where We have implemented UMLtoGenericModel and
fl.N = ( ŽŽଶ.N)_Ref and fl.Ty = †ୡ୪୪మ .Ty, and then added GenericModeltoPhysicalModel transformations using a
to the fields list of  ŽŽଵ (the collection representing–ଵ ) set of tools provided by Eclipse Modeling Framework
such as fl ‫ŽŽ א‬ଵ. Ž୅ . (EMF). Each transformation is expressed as a sequence
Solution 2: r is transformed into a reference field fl of elementary steps that builds the resulting model step
referencing ŽŽଵ (the collection representing–ଵ ), where by step from the source model. First, we create the source
fl.N = ( ŽŽଵ.N)_Ref and fl.Ty = †ୡ୪୪భ .Ty, and added to and the target metamodels. Second, we build an instance
the field list of  ŽŽଶ (the collection representing– ଶ ) such of the source metamodel; for this, we use the standard-
as fl ‫ŽŽ א‬ଶ. Ž୅ . based XML Metadata Interchange (XMI) format. Third,
Solution 3: r is transformed by embedding the collection we implement the transformation rules by means of the
ŽŽଶ representing– ଶ in the collection ŽŽଵ representing –ଵ , Query / View / Transformation (QVT) language (the
OMG standard language for specifying model
where ŽŽଶ ‫ŽŽ א‬ଵ Ǥ Žେଡ଼.
transformations). Finnaly, we test the transformation by
Solution 4: r is transformed by embedding the collection
running the QVT script; the result is provided in the form
ŽŽଵ representing–ଵ in the collection ŽŽଶ representing – ଶ ,
of XMI file. Note that due to lack of space, we only
where ŽŽଵ ‫ŽŽ א‬ଶ Ǥ Žେଡ଼.
present excerpts from models and QVT scripts.
Solution 5: r is transformed into a new collection cll, UMLtoGenericModel is the first transformation in
where cll.N = r.N, cll.Fl = {ˆŽଵ ǡ ˆŽଶ }, ˆŽଵ .N = ( ŽŽଵ.N)_Ref, UMLtoNoSQL process. It transforms the input UML
ˆŽଵ .Ty = †ୡ୪୪మ .Ty, ˆŽଶ .N = ( ŽŽଶ.N)_Ref and ˆŽଶ .Ty = class diagram (figure 4) into the proposed generic logical
†ୡ୪୪మ .Ty, where ŽŽଵ and ŽŽଶare the collections model (figure 5). This model is conform to the generic
representing –ଵ and – ଶ . logical metamodel (figure 3) presented in Section 3.1.
Each reference field used in Solution 1, 2 and 5 can This transformation is performed by means of the
either be monovalued or multivalued. Table 2 indicates transformation rules defined in section 3.1.3. An excerpt
the type of the reference field according to the from the QVT script is shown in Figure 6; the comments
relationship cardinalities and the transformation solution in the script indicate the rules used.
used. GenericModeltoPhysicalModel is the second
transformation in UMLtoNoSQL process. It takes as
TABLE II. DESCRIPTIVE TABLE OF REFERENCE FIELD TYPES
input the generic logical model generated by the previous
Relationship Solution Reference field transformation (UMLtoGenericModel) and return as
type output a NoSQL physical model. As presented in section
r= Solution 1 Monovalued 3.2, the generic logical model proposed in this paper does
(N,{(–ଵ ,*),(– ଶ ,1)}) not imply a specific system; several instances can be
Solution 2 Multivalued
generated from this model to target a specific NoSQL
Solution 5 Monovalued system (Cassandra, MongoDB or Neo4j). Depending on
r= Solution 1 Monovalued the target system functionalities, relationships of the
(N,{(–ଵ ,1),(– ଶ ,1)}) Solution 2 Monovalued logical model could be converted into different forms.
Solution 5 Monovalued We have proposed different solutions to transform these
relationships under Cassandra and MongoDB (3 solutions
r= Solution 1 Multivalued for Cassandra and 5 for MongoDB). Lacks of place, we
(N,{(–ଵ ,*),(– ଶ ,*)}) Solution 2 Multivalued only present two implementations of the generic logical
Solution 5 Monovalued model. The first one was performed on Cassandra
according to solution 1 (figure 7) and the second one was
To Neo4j physical model: done within MongoDB according to solution 4 (figure 8).
R1: each table t ‫ א‬DB is transformed into a vertex v ‫ א‬V,
where v.L = t.N, †୴ .N = †‡–୲ .N.
R2: each attribute ƒ୲ ‫ א‬t.A is transformed into a property
pro, where pro.N = ƒ୲ .N, pro.Ty = ƒ୲ .Ty, and added to the
property list of its transformed container v such as pro ‫א‬
v.Pro.
R3: Each relationship r between two tables –ଵ and – ଶ is
transformed into an edge e, where e.L = r.N, relating two
 CSV format for Cassandra and JSON format for
MongoDB; these files are loaded into the systems using
shell commands.
We have written 6 queries; each query concerns two
tables and the relationship between them. The complexity
of these queries increases gradually; the simplest one
applies a filter to a table and returns attributes of the other
table; the most complex applies several filters and returns
attributes of the two related tables. We note that the
concepts “table” and “attribute” correspond respectively
to “columns-family” and “column” in Cassandra or
“collection” and “field” in MongoDB.
An excerpt from our experiment results is depicted in
Figure 9. For each query, we indicate the obtained
response time according to (1) the relationship
cardinalities and (2) the used transformation solution.
Figure 4. Source Model. Figure 5. Target Model.
modeltype UML uses "http://UMLClassDiagram.com";
modeltype COLM uses "http://GenericLogicalModel.com";
transformation TransformationUmlToColumnsOrientedModel
(in Source: UML, out Target: COLM);main()
{Source.rootObjects()[ClassDiagram]
-> map toDataBase();}
-- Transforming Class Diagram to DataBase
mapping ClassDiagram::toDataBase():DataBase{name := self.name;
table:=self.classes -> map toClass();relationship:=self.links -> toRelationship();}
-- Transforming Class to Table
mapping UML ::Class::toClass():COLM::Table{name:=self.name;attributet:=
self.attributec -> map toAttribute();}
-- Transforming Attribute to Column
mapping UML ::Attribute::toAttribute():COLM::Attribute{name:=self.name;
typea:=self.typea -> map toType(); }
mapping UML ::Type::toType():COLM::Type{typea:=self.typea;}
mapping UML ::Link::toRelationship():COLM::RelationShip{name:=self.name;
li k dt bl self li k d l > map t Li k dT bl ()
Figure 6. UMLtoGenericModel Transformation

Figure 9. Experimental Results.

To implement a relationship under Cassandra or

MongoDB, the developer can use our experiment results
Figure 7. CassandraModel. Figure 8. MongoDBModel. and choose the most suited solution according to the
following criteria: (1) The features of each query that
uses this relationship (number of filters, number of
B. Evaluation attributes to return), (2) The time response and (3) How
Once the NoSQL physical model (Cassandra or frequently this query is used.
MongoDB model) has been created according to each V. RELATED WORK
proposed solution, an evaluation has to be performed to
study the impact that the choice of the solution used may NoSQL systems have proven their efficiency in terms
have on the execution time of queries. The graph-oriented of flexibility and handling Big Data. In the literature, a
system Neo4j does not offer many solutions to implement number of researchers have proposed approaches for
relationships; therefore, the developer does not need to transforming the multidimensional conceptual model to a
choose between several solutions. NoSQL model. For example, Dehdouh et al. [12] propose
We carry out the experimental assessment using a three approaches to map a multidimensional model into a
cluster made up of 3 machines. Each machine has the logical model adapted to column-oriented NoSQL
following specifications: Intel Core i5, 8GB RAM and systems. While this approach has the advantage to start
2TB disk. On the other hand, we have used data from the conceptual level, the proposed models are
generator tools to generate a dataset of about 1TB with Domain-Specific (Data Warehouses system). So they
consider fact, dimension, and typically one type of links on conceptual models in a declarative way similar to
only. predicate logic [13].
Other studies [10] and [9] have investigated the Once the NoSQL physical model is created, another
process of transforming relational databases into a process has to be performed to check the OCL constraints
NoSQL model. Li [10] have proposed an approach for defined in the conceptual model. Checking OCL
transforming a relational database into HBase (column- constraints at the physical level is a real challenge within
oriented system). Vajk et al. [9] defined a mapping from NoSQL systems since the vast majority of NoSQL
a relational model to document-oriented model using approaches lack any advanced mechanism for integrity
MongoDB. These works rely on the relational model that, constraint checking. Considering this limitation, we plan
unlike UML class diagram, lacks of semantic richness, to complete and generalize the UMLtoNoSQL approach
especially through the several types of relationships that by taking into account other more complex constraint.
exist between classes.
To the best of our knowledge, only few works have VII. CONCLUSION
presented approaches to implement UML conceptual This paper is about an investigation on the
model into NoSQL systems. Li et al. [11] propose a implementation of Big Data base within NoSQL systems.
MDA-based process to transform UML class diagram We have proposed respectively, two transformations for
into column-oriented model specific to HBase. Starting this purpose, UMLtoGenericModel and
from the UML class diagram and HBase metamodels, GenericModeltoPhysicalModel, in order to generate a
authors have proposed mapping rules between the physical model from a UML class diagram. Using MDA
conceptual level and the physical one. Obviously, these formalism, we define rules to transform the conceptual
rules are applicable to HBase, only. Gwendal et al. [3] model to NoSQL systems automatically. Our contribution
describe the mapping between a UML conceptual model illustrates an intermediate unified logical model between
and graph databases via an intermediate graph UML conceptual model and NoSQL physical model. Our
metamodel. In this work, the transformation rules are logical model is compatible with column, document and
specific to graph databases used as a framework for graph oriented systems. This model uses tables and
managing complex data with many connections. binary relationships that link them. The independence
Generally, this kind of NoSQL systems is used in social between the three physical models is ensured.
networks where data are highly connected. Reagrding Furthermore, we propose different solutions to transform
this state of the art, [11] and [3] consider, each, a the binary relationships of the logical model under
single type of NoSQL systems (column-oriented in [11] Cassandra and MongoDB. Depending on the system
and graph-oriented in [3]). However, it makes more sense functionalities, the binary relationships could be
to choose the target system according to the user’s needs. converted into different forms.
For example, if processing operations requires access to Our experimental work demonstrates an evaluation of
hierarchically structured data, the document-oriented NoSQL physical model, Cassandra or MongoDB model,
system proves to be the most adapted solution. according to each proposed solution. The developer can
The main purpose of our work is to assist developers then use our experimental results and choose the most
in storing Big Data in NoSQL systems. For this, we have suited solution according to the criteria considered in the
proposed a new MDA-based approach that transforms a paper.
UML conceptual model describing Big Data into several
NoSQL physical models. This automatic process allows REFERENCES
the developer to choose the system type (column, [1] A. Abello, “Big Data Design”. In DOLAP, 2015.
document or graph) that suits the best with business rules [2] Herrero, V., Abelló, A., & Romero, O. NOSQL Design for
and technical constraints. Analytical Workloads: Variability Matters. In ER, 2016.
[3] D. Gwendal, S. Gerson, C. Jordi. “UMLtoGraphDB: Mapping
VI. DISCUSSION & FUTURE WORK Conceptual Schemas to Graph Databases”. In ER, 2016.
Big Data applications developers have to deal with [4] J. Hutchinson, M.Rouncefield, and J.Whittle. "Model-driven
engineering practices in industry". In ICSE, 2011.
the question: how to store Big Data in NoSQL systems?
To address this problem, we have proposed the [5] J. .Bézivin and O. Gerbé. "Towards a Precise Definition of the
OMG/MDA Framework". In ASE, 2001.
UMLtoNoSQL approach, a MDA-based approach, to
[6] D.Abadi , S.Madden , N.Hachem, "Column-stores vs. row-stores".
implement UML conceptual models describing Big Data In international conference on Management of data, 2008.
in NoSQL systems. Our approach rely on a pivotal model [7] http://www.omg.org/spec/UML/2.5/
(the “Generic Logical Model” in the paper) designed for
[8] A. Angadi, Ak. Angadi, Karuna. Gull. “Growth of New Databases
NoSQL systems. Instances of this model can be & Analysis of NOSQL Datastores”. In IJARCSSE. 2013.
generated to target specific NoSQL system (Cassandra, [9] T. Vajk, P. Feher, K. Fekete, H. Charaf. “Denormalizing data into
MongoDB, Neo4j, etc.). schema-free databases”. In CogInfoCom, 2013.
In this approach, we have considered some [10] C. Li. "Transforming relational database into HBase: A case
constraints such as data type and identifier uniqueness. study". In ICSESS, 2010.
However, other constraints are required as context [11] Yan Li, Ping Gu. "Transforming UML Class Diagrams into HBase
restrictions to further refine the semantics of the UML Based on Meta-model. Information Science". In ISEEE, 2014
conceptual model elements. These constraints are defined [12] Dehdouh, K., Bentayeb, F., Boussaid, O., Kabachi, N. Using the
by well-formedness rules expressed using the Object column oriented model for implementing big data warehouses. In
PDPTA, 2015.
Constraint Language (OCL). It’s a widely accepted
standard allowing the specification of formal constraints [13] http://www.omg.org/spec/OCL/2.4/