# AMANDA: A Middleware for Automatic Migration between Different Database Paradigms
## 1 Introduction  
The continuous change in the datafication process of weakly structured heterogeneous data makes it hard to carry out any analysis using manual and conventional methods [1, 2]. Concurrently, new large datafication processes are occurring in different contexts, e.g., healthcare [3, 4], software development and content management systems [5, 6, 7]. Internet of Things (IoT) and smart cities [8, 9, 10], e-business [11], and social media [12, 13, 14, 15]. Furthermore, new storage methods are constantly revisited and reassessed to support those processes at higher performance standards. Such changes occur as part of a new and challenging research field: big data. In terms of characteristics, big data refers to a category of data that is often unstructured, assorted, has increasing volume, and follows ever-tighter time constraints, thus demanding every bit of computational power and processing speed available [3, 16]. For example, the authors in [17] point out that Facebook users have uploaded more than 290 million photos and statuses per day, and the authors in [3] report that the healthcare data context is expected to reach 25,000 petabytes. Handling such a data volume imposes new storage scalability challenges for many organizations that have historically used relational databases to store, analyze, and process data [3]. To overcome such a challenge, new technologies in data storage are emerging to better scale and speed up data processing [18]. Database technologies are commonly classified into relational and non-relational (NoSQL) paradigms. The former requires a data schema, which provides interfaces for high-level, complex queries through formulas representing application-specific integrity constraints [19]. The latter is schema-agnostic [20], thus requiring no predefined data schema, alternatively providing high-performance queries on high volumes of unstructured data [21]. Examples of Relational Database Management Systems (RDBMS) includePostgreSQL [22], MySQL [23], and Oracle [24]. Common to them is the support for Structured Query Language (SQL) [25] and the presence of tables composed of rows and columns as a way of structuring data. In an RDBMS, each row is identified by a unique value called the primary key. Columns of a table represent attributes common to each row, explicitly defined through a data type that represents the intended use of the attribute data. Such constraints and their relationships are described in a database schema that must be defined prior to any database usage [5; 18]. NoSQL databases are different from RDBMS in their underlying implementation. They make use of something other than tables to store data, and can be classified based on their data model [5]: key-value (e.g., memcached [26]), document (e.g., MongoDB [27]), column-oriented (e.g., Cassandra [28]), and graph (e.g., Neo4J [29]). When working with the current trending scenarios that often contain substantial arrangements of unstructured and uncoupled data, NoSQL databases can overcome some RDBMS limitations, namely: poor distributed data processing (scalability) and high latency and complexity (performance) [30]. In effect, in comparison to RDBMS, NoSQL databases are noteworthy for their operational scalability and performance when working with flexibly structured data [31; 32; 33]. Given that RDBMS and NoSQL present very different qualities and usage benefits, there is often a need to migrate from one type to the other, something that can be achieved through the use of data migration [5] tools. Graph databases, a type of NoSQL database, handle relationships more efficiently than RDBMS [5]. One of the reasons is that RDBMS computes relationships at the query time through join operations. In contrast, graph databases store data relationships as a data entity [18].