A Model-Driven Approach to Database Migration with a Unified Data Model María-José Ortína , José R. Hoyosa , Jesús J. García-Molinaa a Facultad de Informática, Universidad de Murcia, Campus de Espinardo, 30100, Murcia, Spain
arXiv:2604.22415v1 [cs.DB] 24 Apr 2026
Abstract Database migration is a key task in software modernization, increasingly involving transformations across heterogeneous data models such as relational and NoSQL systems. Existing approaches are typically designed for specific source–target combinations, which limits their applicability in multi-model environments. This paper proposes a generic database migration approach based on the U-Schema unified data model, which acts as a pivot representation. By defining mappings between each data model and U-Schema, the approach reduces the number of required transformations and enables schema conversion across heterogeneous paradigms. Trace information is generated during schema transformation to capture correspondences between source and target elements, and is subsequently used to guide data migration in a decoupled manner. The approach has been implemented and evaluated through experiments covering schema-level validation, data-level semantic preservation, and performance analysis. The results show that the migration pipeline achieves high structural preservation under round-trip reconstruction, produces document schemas consistent with the intended design decisions, and preserves query behavior across a variety of access patterns, including joins, aggregations, and nested structures. Performance results demonstrate the feasibility of the approach for datasets of increasing size. The evaluation focuses on relational-to-document migration using both synthetic datasets and the Northwind benchmark. While this scenario provides a concrete instantiation, the approach is designed to support multiple data models within a unified framework. Keywords: Database migration, Heterogeneous data models, NoSQL, Model-driven engineering, Schema transformation, Data migration, U-Schema
1. Introduction Database migration is a common task in software modernization, where data must be moved from legacy systems to new platforms that better satisfy current requirements. For decades, most migrations were performed within the relational model. This situation changed with the emergence of NoSQL (Notonly SQL) systems, which introduced alternative data models designed to overcome some limitations of relational databases. NoSQL systems were developed to support data-intensive applications, providing flexibility in schema evolution, horizontal scalability, and high availability. Many of them are schemaless and follow a schema-on-read approach, supporting data abstractions such as column families, documents, key–value pairs, or graphs [1]. In contrast to the relational model, where foreign keys are the main mechanism to relate data, NoSQL models provide constructs such as nested objects, aggregation hierarchies, or explicit relationship types. However, these models lack a standard specification, and each paradigm— and often each system—defines its own data model. As a consequence of this evolution, the database landscape has become heterogeneous, as illustrated by the DB-Engines
Email addresses: [email protected] (María-José Ortín), [email protected] (José R. Hoyos), [email protected] (Jesús J. García-Molina)
ranking [2], although relational systems remain the most widely used by a considerable margin. This ranking reflects not only the growing relevance of NoSQL systems, but also the evolution of major relational DBMSs towards multi-model platforms with native support for document data (e.g., PostgreSQL JSONB, Oracle Multimodel, MySQL JSON). In parallel, research on polystore systems has gained increasing attention [3], demonstrating unified query and data management across heterogeneous models. Moreover, the adoption of polyglot persistence [1] has grown, with different data models coexisting within the same system to address diverse application requirements [4]. In this context, database migration increasingly involves transformations between different data models. Existing approaches are usually designed for specific source–target combinations, most often relational to document databases [5, 6, 7, 8, 9, 10]. However, migrations may occur between any pair of models, and defining dedicated transformations for each combination does not scale, as the number of mappings grows quadratically with the number of supported paradigms. This motivates the need for model-independent migration strategies. This paper proposes a generic database migration approach based on Model-Driven Engineering (MDE), supporting the automated transformation of both schema and data across heterogeneous data models within a unified framework. It focuses on logical migration, addressing schema and data migration in-
• An extensive validation of the approach. The proposal is evaluated through unit and integration testing of transformation rules, schema-level validation via round-trip reconstruction, data-level validation using representative queries, and performance and scalability analysis over datasets of increasing size.
dependently of deployment concerns (e.g., cloud migration or platform-specific configurations). The proposal is based on U-Schema [11], a unified and technology-independent logical data model used as a pivot representation. We define mappings between each supported model and U-Schema in both directions, enabling migration through a common intermediate representation. These mappings can be composed into a transformation pipeline in which a target schema is systematically derived from the source schema through U-Schema. The transformations also generate trace links that relate each element of the target schema to its origin in the source schema. This trace is used during data migration to access the source database in a model-independent way, without requiring knowledge of its native structures. The resulting target schema corresponds to a canonical representation, obtained by applying predefined mapping rules without introducing application-specific design changes. In practice, such canonical schemas often require adaptation to meet specific requirements. In our proposal, this adaptation is performed at the level of the intermediate U-Schema model, allowing designers to influence the structure of the generated target schema before its materialization. To support this, we employ the generic schema evolution language Orion [12], with its engine adapted to ensure trace consistency. In this paper, the evaluation focuses on the canonical transformation pipeline, while schema adaptation is treated as a separate concern and does not alter its execution. Both schema and data migration are evaluated for two case studies.
Paper organization. The remainder of this paper is organized as follows. Section 2 introduces the necessary background and key concepts, including the U-Schema model, as well as fundamental notions of database migration, schema mappings and MDE. Section 3 contrasts our proposal with the most relevant work on database migration using several comparison criteria. Section 4 presents the proposed migration approach, describing both the transformation pipeline and the data migration process. Section 5 defines the mapping rules for the data models involved in the relational-to-document case selected to validate our approach. Section 6 reports the experimental validation of the approach, including schema-level, data-level, and performance analyses. Finally, Section 7 concludes the paper and outlines directions for future work. 2. Background This section briefly reviews the key concepts required to understand the proposal developed in the following sections. We begin by outlining the main characteristics of database migrations. Next, we describe the U-Schema data model. We then summarize the MDE concepts underlying the transformationbased approach adopted in this work. Finally, we briefly introduce Orion [12], which is used to support schema adaptation within the migration pipeline.
Contributions. The contributions of this work can be summarized as follows: • A generic approach for automated schema and data migration. To the best of our knowledge, this work is the first to provide a unified, model-driven approach to database migration across heterogeneous data models, supporting both schema and data transformation within a single framework. This generality is achieved through the use of the U-Schema model as a pivot representation, which enables the definition of transformations independently of specific source–target combinations.
2.1. Elements of a database migration process A database migration is the process by which a target database T is obtained from a source database S . Migrations are commonly considered homogeneous if S and T share the same database technology, and heterogeneous otherwise [13]. In this work, however, this distinction is defined in terms of the data model. In heterogeneous migrations, a schema conversion step is always required, whereas in homogeneous migrations this step is only necessary when the target design introduces structural changes beyond a direct copy of the schema. Whenever schema conversion takes place, data extracted from S must be transformed before being written to T , and the application code that manipulates the data must be adapted to preserve functional correctness. A database migration process therefore typically includes three main activities: (i) schema conversion, (ii) data migration, and (iii) adaptation of the application code. A fourth activity, is the validation of the migrated data, which is essential to ensure correctness and consistency of the resulting database. These activities can be partially or fully automated by specialized tools or services, which we refer to as migrators. In this paper, we focus on schema and data conversion, as is common in the literature on database migration.
• A trace-based mechanism for model-independent data migration. We introduce a fine-grained traceability model generated during schema transformation, which is used to drive data migration. This trace enables platform-independent access to source data through a generic adapter, decoupling the migration process from the native data model. • A separation between canonical schema generation and schema adaptation. The approach distinguishes between the systematic derivation of a canonical target schema through mapping rules and the application of design-specific schema adaptations. When required, these adaptations are performed at the level of the intermediate model, allowing controlled refinement without modifying the mapping rules.
2
Figure 1: Simplified U-Schema metamodel (union-schema flavor).
approaches have been proposed to tackle problems involving schema mappings [15, 16]. Over the years, the co-existence of the relational model with other data models motivated the definition of generic or unified data models, e.g., EER [17] and DB-Main [18]. With the emergence of NoSQL systems, new unified proposals were introduced to integrate NoSQL and relational paradigms, such as U-Schema [11], PartiQL [19], and SOS [20], each differing in the supported NoSQL paradigms and their underlying features. The migration approach presented in this paper is based on USchema, whose main characteristics are the following, as described in detail in [11]: (i) it integrates the four most popular NoSQL paradigms together with the relational model; (ii) it distinguishes between entity types an relationship types; (iii) it provides aggregation and reference constructs to model relationships between entity types; and (iv) it supports structural variations of types, since the possible absence of a declared schema allows an entity or relationship to be stored with different data structures. Next, we describe this metamodel, as illustrated by the excerpt shown in Figure 1. U-Schema represents the logical structure of a database through a unified set of constructs that apply across relational, document, columnar, graph, and key–value paradigms [11]. A schema is defined as a set of SchemaTypes, either EntityTypes or RelationshipTypes, which describe the domain entities and their relationships. EntityTypes represent domain concepts whose instances store data. They contain Features, which may be structural or logical. Structural features describe the stored values and include simple or multivalued Attributes and Aggregations, the latter used to embed objects of other entity types. Log-
The cardinality of a migration refers to the number of source and target systems involved. While the most common case is 1:1 (one source migrated to one target), other scenarios are possible [13]. Cardinality 1:n occurs when a single source is migrated to several heterogeneous targets, as in deployments involving polyglot persistence. Conversely, cardinality n:1 appears when several databases are consolidated into a single target system. The general n:m case, although conceptually feasible, is less frequent and normally appears in large-scale data integration or modernization initiatives. Migration processes often create an opportunity to improve the database design. For example, the target schema may be customized to better reflect the usage patterns of the application, for instance by merging tables in relational systems to optimize read-intensive workloads, or by transforming references into aggregations in document-oriented databases to reduce the need for joins. We refer to this design refinement step as schema customization or schema adaptation. 2.2. The unified metamodel U-Schema A data model defines the data structuring rules that can be used to represent real world data in a database, as well as the operations that can be applied on the data. A schema results of applying a data model to a particular domain or problem. The link between a schema and its data model, can formally be established through the conforms-to or instance-of relationship that is characteristic of the software modeling: a schema is represented as a model that is an instance of the metamodel representing the data model [14]. Thus, metamodeling has traditionally been applied to define data models, and transformational
3
ical features capture links among data and consist of Keys (unique identifiers) and References, which represent associations through key values. EntityTypes may be declared as root (top-level objects) or non-root (objects embedded through aggregations). A RelationshipType denotes an explicit association that connects two (or more) EntityTypes and may contain its own attributes. Such elements usually originate from associative tables representing M:N relationships in relational schemas and from edge types in graph data models. Similarly to association classes in UML, a RelationshipType models both the connectivity between entities and the properties attached to the association itself. U-Schema supports two flavors [11]. The full-variability flavor records all structural variations of each entity type, while the union-schema flavor merges them into a single structure by marking optional features. In this work we adopt the unionschema flavor. This choice simplifies the presentation of our migration approach without affecting its generality. To illustrate the expressive capabilities of U-Schema, Figure 2 presents a fragment of a simple music–streaming domain specified using Athena, a generic schema definition language that provides a textual notation for U-Schema [21]. The schema defines root entity types such as User, Song, and MusicalStyle, together with non-root entity types PlayList and Listening, which are aggregated within User. The example is intentionally small and serves solely as an introductory illustration of U-Schema. A more detailed version of this domain will be reused later (Section 5.2) as the running example for the mapping rules. Understanding the full syntax of Athena is not required here, as the modeling constructs used are selfexplanatory.
Schema MusicStreaming:1 Root entity User { +id: String, name: String, isPremium: Boolean, registerDate: Date, playLists: Aggr<PlayList>, mostRecentlyListened: Ref<Song>* } Entity PlayList { +id: String, name: String, creationDate: Date, songs: Ref<Song>* } Root entity Song { +id: String, title: String, duration: Decimal(4,2), artist: String, playsCount: Integer, styles: Ref<MusicalStyle>* } Root entity MusicalStyle { +id: String, name: String } Entity Listening { user: Ref<User>, song: Ref<Song>, playsCount: Integer, status: String }
Figure 2: A U-Schema schema example declared with Athena.
guages (DSLs) are commonly used to express the input models to the transformation chain; their notation or concrete syntax is defined on top of a metamodel describing the domain of the language. In the MDE setting, a database schema is represented as a model conforming to the metamodel of the corresponding data model, and schema migration is realized as a chain of model transformations. The source model is derived from the schema, which may be explicitly specified in a DDL or inferred from data or application code [11]. Our approach adopts MDE principles to automate database migration as follows:
2.3. Schema mappings and Model-Driven Engineering Schema mappings define correspondences between elements of two data models and constitute the foundation of schema transformation tasks. In the context of database migration, a schema mapping specifies how the constructs of a source schema (e.g., tables, collections, or entities) are represented in a target schema expressed in a different data model. Schema mappings are commonly specified using declarative formalisms, such as graph transformations, first-order logic, or set theory. These formalisms provide the theoretical basis for model transformation languages (e.g., QVT, ATL, and AGG). Model-Driven Engineering (MDE) provides a systematic framework for automating software and data engineering tasks by representing artifacts as models conforming to metamodels, and by applying transformations between them [14]. Two kinds of model transformations are typically distinguished: model-tomodel (m2m) transformations, which convert an input model into an output model by establishing a mapping between their respective metamodels, and model-to-text (m2t) transformations, which generate textual artifacts (e.g., source code, JSON documents, or SQL scripts) from an input model. An MDE solution aimed at automating a given task usually consists of one or more m2m transformations, followed by a final m2t transformation that produces the desired artifact. Domain-specific lan-
• Specific and unified data models are represented as metamodels, and schemas are therefore represented as models conforming to them. • Schema migration is performed through a chain of model transformations, using U-Schema as a canonical representation. • Schema mappings are implemented as m2m transformations. • Transformation traces are leveraged to automate part of the data migration process: data are automatically traversed, transformed, and transferred to the target database. • The Orion DSL can be used as a generic schema-evolution language when customizations are required prior to generating the target schema; it is introduced in the following subsection. 4
U-Schema
Relational
Document
Schema
Schema
Optional (schema-on-read)
Entity Type
Table
Collection and nested objects
Relationship Type
Associative table
N/A
Structural Variation
No (fixed structure of tables)
Yes
Key
Primary key
Document identifier
Reference
Foreign key
Reference -limited support (e.g., MongoDB)
Aggregation
N/A
Nested object
Attribute
Column
Document property field
Primitive Types
Scalar types
Scalar types
Structured Types
N/A
Arrays
Table 1: Correspondence between U-Schema, the relational model, and the document model.
Table 1 summarizes the correspondences between the elements of U-Schema and those of the relational and document data models considered in this paper, two of the paradigms unified by U-Schema. These correspondences are implemented in the m2m transformations that compose the migration pipeline in the case study, including the transformations from the relational model to U-Schema and from U-Schema to the document model, as well as the corresponding inverse transformations. All metamodels used in this work (relational, document, and U-Schema) have been implemented using the Ecore metamodeling language, which is integrated into the Eclipse Modeling Framework (EMF) [22]. EMF is a widely adopted open-source platform for developing MDE solutions and provides tooling such as model transformation languages, model comparison and diff/merge utilities, as well as workbenches for the creation of domain-specific languages (DSLs). Model transformations, both m2m and m2t, have been implemented in Xtend, a Javabased general-purpose language (GPL) that forms part of the Xtext DSL-definition workbench [23].
2.4. The Orion Schema Evolution Language Orion is a generic schema–evolution language that implements a taxonomy of schema–change operations defined over U-Schema [12]. The language provides a declarative mechanism for expressing schema refinements independently of the underlying data model or database technology such as renaming, type modification, attribute extraction, entity merging, and the reconfiguration of references and aggregations Given the Music Streaming schema introduced earlier, the script shown in Figure 3 illustrates several Orion schema evolution operations, including entity renaming, attribute type casting, conversion of a reference into an aggregation (MORPH), and attribute deletion. // Example evolution in Orion RENAME ENTITY User TO AppUser RENAME Song::duration TO length CAST ATTR Song::length TO Integer MORPH REF Song::styles TO styles DELETE Listening::status
Figure 3: Example of Orion script.
Trace models in m2m transformations. Most m2m transformation languages maintain an explicit trace model that records the correspondence between elements of the source and target models. Traceability information is essential when writing complex mappings that require access to source or target elements not directly reachable from the current transformation rule. In our context, trace models are used to record schema-level correspondences. Since Xtend is a GPL and does not provide builtin trace management, trace links are programmatically recorded during the execution of m2m transformations using a dedicated format defined in this work, as detailed in Section 4.4. These links enable the automation of the data migration stage by providing a uniform mechanism to retrieve the correspondences established during schema transformation, as described in Section 4.3.
In our approach, we employ Orion to introduce controlled refinements during the migration process. Orion enables designers to modify the U-Schema model to guide the generation of the target schema according to specific design requirements. For instance, a reference can be converted into an aggregation to improve query efficiency in document-oriented databases. Regarding implementation aspects, Orion is executed in schema-only mode, performing logical schema evolution without applying data migration scripts. Since Orion does not natively produce trace information for the applied changes, the trace generated during the transformation process must be updated accordingly. To this end, we reuse Orion’s parsing and schema evolution components and extend its execution to maintain trace consistency during the application of schema change operations. 5
3. Related Work
In our case, the use of U-Schema provides a unified representation that can accommodate both relational and NoSQL data models, as illustrated in Section 5 for the relational-todocument example.
In this section, we compare representative approaches proposed to automate database migrations. We restricted our review to migration proposals that involve at least one NoSQL data model and address schema and/or data migration across heterogeneous paradigms. Schema-evolution approaches were excluded because their goals and underlying assumptions differ fundamentally from full database migration. The majority of published proposals focused on relational-to-document conversion—primarily to MongoDB. From these works, we selected those most technically significant and conceptually sound for our review. We also include the DB-Main approach due to its conceptual closeness to our proposal, even though it predates the NoSQL era. To perform the comparison, we derived a set of criteria from the characterization of database migration presented in Section 2.1. We complemented these criteria with additional dimensions specific to data migration, since existing proposals differ substantially in how extraction, transformation, and loading are handled. Considering both schema- and data-migration aspects, the criteria used in our comparison are: (i) the data models supported as source and target; (ii) the level of data model independence; (iii) the representations used to describe the involved schemas—source, target, intermediate or canonical models, and any annotations enriching the source schema; (iv) how schema mappings are defined and implemented; (v) the cardinalities handled; (vi) the degree to which schema conversion may be customized; (vii) the use of source-database usage information (e.g., statistics or workload analysis); (viii) whether data migration is performed; (ix) the strategy applied to extract, transform, and load the data; (x) the presence and granularity of traceability mechanisms; and (xi) the degree of application-code adaptation required. Each of these dimensions is analyzed in the subsections below.
Platform independence. refers to whether a migration approach is intrinsically coupled to specific data models or whether it defines abstractions that enable its application across different source and target technologies. Most existing proposals are model-specific: their transformation logic is hardcoded for a particular migration direction (e.g., relational-toMongoDB) and cannot be reused for other NoSQL models without redesigning the mapping rules or the extraction and loading procedures. Approaches of this kind include Jia et al. [5], Rocha et al. [8], and Zhao et al. [24], whose algorithms are tailored to the document model. Only a few works move toward a more general perspective. Metamorfose [7] introduces a transformation pipeline based on an intermediate structure, although its rules remain specific to the document and column-family models it supports. Dynamite [25] achieves a higher degree of generality by synthesizing Datalog programs that can operate over different data representations, but it does not define a unifying schema model and focuses solely on data transformation. Earlier attempts at broader platform independence can be found in tools such as DB-Main, which supported schema evolution and migration across relational, XML, and object databases [26]. However, DB-Main was never extended to incorporate NoSQL models, and to the best of our knowledge, no existing approach provides a unified and model-independent framework for schema and data migration across relational and NoSQL systems. In contrast, our proposal relies on U-Schema as a common intermediate representation, enabling schema mappings and transformations to be defined independently of the specific source or target data model. Representations in schema conversion. Migration approaches differ substantially in the abstractions they use to represent source and target schemas, as well as in whether an intermediate representation is employed. Intermediate models are typically introduced for two reasons: (i) to reduce the semantic gap between heterogeneous data models, thus simplifying the conversion process, and (ii) to provide a universal format that reduces the number of transformations from N × M to N + M for N source and M target models. Schema conversion can also operate at the physical or logical level [27]; in the former case, reverse engineering is applied to recover a logical schema that carries richer semantic information. A logical intermediate representation is used in Jia et al. [5], where an ER model is extracted from the relational source and enriched with usage-based annotations (e.g., join frequency). This ER model is then converted into a directed graph whose nodes correspond to entity types (tables) and whose edges represent foreign keys, forming the basis for generating the MongoDB schema. Zhao et al. [24] also adopt a graph-based abstraction, proposing a schema conversion algorithm over a relational-to-NoSQL graph model.
Data models. This criterion refers to which data models are supported as source and target during migration. Most existing proposals focus on a single direction, namely relational-todocument conversion, typically targeting MongoDB. Representative examples include the automated or semi-automated approaches by Jia et al. [5], Rocha et al. [8], and Zhao et al. [24], all of which assume a relational source and a document-store target. Metamorfose [7] extends this common scenario by also supporting column-family stores, making it one of the few proposals addressing more than a single NoSQL target. Support for data models different from document stores is less common. Scavuzzo et al. [9] consider the migration from relational databases to HBase (a columnar store) by defining a columnar metamodel. A more general approach is represented by the Dynamite system [25], which addresses heterogeneous data transformation by synthesizing Datalog programs capable of handling relational, document, and graph data. However, it focuses on data transformation rather than explicit schema migration. 6
Several works define explicit intermediate metamodels. Scavuzzo et al. [9] introduce a columnar metamodel that provides a canonical format for HBase schemas, while Metamorfose [7] uses a DAG-based representation as the core structure for expressing relational-to-document and relational-tocolumn-family transformations. Schreiner et al. [10] propose a hierarchical canonical model that captures relational schemas in a semi-structured format to facilitate their mapping to aggregate-based NoSQL schemas. In contrast, Dynamite [25] does not rely on a unifying schema representation: instead, it synthesizes Datalog programs from examples, focusing solely on data transformation and leaving schema abstraction implicit. Our approach is explicitly model-based: both source and target schemas are represented using metamodels specific to each data model, and U-Schema serves as a unified intermediate representation that enables schema mappings to be expressed independently of the underlying database technology.
Parameterized mappings. Beyond the structural information contained in the schema, some approaches parameterize their mappings with additional information provided by users or derived from database usage statistics. Jia et al. [5] exploit several indicators—such as frequent joins, very large tables, and the frequency of insertions and updates—to decide whether a given foreign key should be mapped to an embedded document or to a reference in MongoDB. Kim et al. [6] perform a query-workload analysis to detect joins and guide denormalization decisions when migrating to HBase. Other proposals, including Metamorfose [7] and the canonical-model approach by Schreiner et al. [10], rely mainly on schema structure and do not incorporate such statistical parameters. Currently, our approach does not use workload or statistical data to parameterize mappings, although it could be extended to do so. Schema-conversion customization. Another relevant aspect is the degree to which the schema conversion performed by a tool can be customized or adapted to user requirements. Most existing approaches apply fixed, hard-coded conversion rules that leave little room for variation (e.g., Zhao et al. [24], Schreiner et al. [10], Kuszera et al. [7]). Although Jia et al. [5] use database statistics to influence some decisions (e.g., embedding vs. referencing), these heuristics do not expose alternative mappings to the user and therefore do not constitute genuine customization. In our proposal, customization is achieved by separating schema generation from schema adaptation. A canonical target schema is first derived through the U-Schema intermediate model, while design-oriented refinements can be applied at the U-Schema level prior to target generation using Orion, a generic schema-evolution language.
Schema mapping. When automating schema migration, the target schema may be obtained in two ways: either generated automatically through explicit mapping rules, or hard-coded within the transformation procedures themselves. Most existing proposals fall into the latter category, with mappings embedded procedurally in algorithms that specify the step-by-step conversion logic (e.g., Jia et al. [5], Zhao et al. [24], Schreiner et al. [10]). These algorithms typically handle simple relational structures and do not capture the variability inherent in real-world schemas, such as recognizing many-to-many associations, identifying weak–strong relationships, or deciding whether foreign keys should be mapped to references or aggregates in the target model. Other approaches do not provide an explicit formulation of the schema mapping. Metamorfose [7] defines a transformation pipeline over a DAG-based representation, but the mapping rules remain implicit in the traversal and construction procedures. Similar implicit strategies appear in the guidelines by Kim et al. [6] and in the approach of Rocha et al. [8]. Dynamite [25] departs entirely from rule-based mappings: the system synthesizes Datalog transformation programs from examples, making the schema mapping implicit and preventing a declarative specification of the mapping space. In our approach, schema mappings are formally specified over U-Schema and implemented using model-transformation languages (e.g., Xtend), which allows alternative mappings to be expressed explicitly and ensures that the mapping logic is defined independently of the source or target data model.
Data migration. A key distinction among the reviewed approaches is whether they support data migration in addition to schema conversion. Several proposals handle schema migration only (e.g., Zhao et al. [24], Rocha et al. [8]), while others implement both schema and data transformation (e.g., Jia et al. [5], Scavuzzo et al. [9], Schreiner et al. [10], Kuszera et al. [7]). Dynamite [25] focuses exclusively on data transformation. Our proposal supports both schema and data migration. For those approaches that support data migration, two additional aspects are relevant for comparison and are analyzed below: the kinds of inputs used to drive the migration process, and the ETL strategies applied to materialize the target data. Data-migration inputs. Approaches differ in the kinds of artefacts and information they use to drive data extraction, transformation, and loading. In DB-Main [18], ETL flows are derived from explicitly specified schema mappings. Jia et al. [5] rely on an annotated ER-derived graph, enriched with usage statistics (e.g., join frequency, table size, and update rates), which guides both schema decisions and the materialization of MongoDB documents. Schreiner et al. [10] use their canonical model as the primary input for generating target data instances, whereas Scavuzzo et al. [9] and Kuszera et al. [7] base their ETL logic mainly on the structural information captured in
Cardinality. Most approaches assume a 1:1 migration scenario, where a single source database is mapped to a single target system. Only Dziedzic et al. [28] address more complex situations, supporting 1:n migrations in the context of a polystore architecture. Although this area remains largely unexplored, the use of a common intermediate representation in our approach facilitates supporting 1:n migration scenarios, as mappings can be defined independently for each target model.
7
their intermediate models (columnar metamodel and DAG, respectively). Dynamite [25] takes a different route by synthesizing Datalog programs from input–output examples, effectively specifying data transformations by example rather than through explicit mappings. In our approach, data migration is driven by the trace links generated during the execution of the schema transformation pipeline. This trace, together with the generated target schema, is used to identify and transform the source data corresponding to the elements of the target schema, as explained below. This eliminates the need for independently specified ETL logic.
The table highlights the heterogeneity of current approaches: most focus on a single source–target direction, rely on fixed mapping rules, and implement migration logic tightly coupled to specific NoSQL technologies. Only a few works employ intermediate models or provide partial forms of model independence, and support for customizable schema conversion or systematic data migration remains limited. In contrast, our approach builds upon a unified intermediate representation (U-Schema) and explicitly defined schema mappings, enabling model-independent schema conversion together with a structured data-migration process. The combination of a metamodel-based foundation with customizable mappings offers a more general and flexible solution than existing proposals, as reflected in the final column of Table 7.
ETL strategies. The strategies adopted to execute data migration also vary significantly. Some approaches implement custom, procedural ETL code tightly coupled to a specific source–target pair, as in Jia et al. [5] or Schreiner et al. [10]. Scavuzzo et al. [9] use a queue-based producer–consumer architecture to populate HBase, while Metamorfose [7] generates Apache Spark commands to transform relational data into document or column-family structures, thus leveraging data-parallel execution. Dynamite [25] executes synthesized Datalog programs on top of a logic engine, providing a declarative execution model for data transformation. Other approaches, such as Rocha et al. [8] or Kim et al. [6], focus mainly on query rewriting and denormalization guidelines rather than on a dedicated ETL pipeline. In contrast to these approaches, our proposal does not rely on custom, procedural ETL logic tied to specific source–target pairs. Instead, data migration is executed based on the trace links and schema mappings derived from the schema transformation process, without requiring independently specified transformation scripts. The execution is supported by a USchema-based adapter that provides model-independent access to the source data, decoupling data access from technologyspecific APIs and enabling uniform execution across heterogeneous systems.
4. Migration Approach This section presents our migration approach. We first introduce the design principles that guide it, followed by an overview of the migration process. We then describe the schema transformation and the structure of the trace, and finally detail the data migration process. 4.1. Design Principles Our migration approach is structured around the following design principles, which guide both schema and data transformation: • Model-based automation. Schemas are represented as models, and schema migration is realized through a chain of model-to-model transformations. • U-Schema as a unified pivot model. The U-Schema unified data model enables database independence by serving as a technology-independent pivot representation for schema transformation across heterogeneous database paradigms. • Explicit trace management. Trace links are explicitly generated and maintained throughout schema migration to preserve the correspondences between source, U-Schema, and target schema elements. This trace is later exploited to drive data migration consistently with the schema mappings derived by the transformation pipeline.
Code adaptation. Some proposals also address the problem of adapting existing application code to the target NoSQL system. Several techniques have been explored in this context: (i) translating SQL queries into HBase API calls [6, 9] or into MapReduce jobs executed on HBase [29]; (ii) generating REST API calls from DML statements (SELECT, INSERT, UPDATE, DELETE) as in Schreiner et al. [10]; and (iii) wrapping original SQL queries so that they are intercepted and redirected as calls to the target NoSQL store [8]. These techniques vary in scope and automation level but share a common focus on query and API translation. In our case, code evolution is outside the scope of the present work. Table 7 summarizes the comparison of all reviewed approaches with respect to the proposed criteria. Due to its size and horizontal layout, the table is placed at the end of the paper to preserve readability and avoid interrupting the flow of the discussion. The cardinality and parameterized mappings criteria are excluded, as they are not supported by most of the analyzed approaches.
• Convention with controlled configuration. When multiple schema transformation alternatives are possible, predefined conventions are applied to derive a canonical target schema, rather than requiring explicit configuration or automatically selecting alternatives based on workload characteristics. When deviations from these conventions are required, the Orion schema-evolution language enables designers to explicitly adapt the generated schema to specific migration requirements. • Schema-derived data migration. Data migration is derived from the schema transformation process through mappings and trace links, avoiding the need for independently specified transformation logic. 8
• Database-independent data access. Source data are accessed through a U-Schema-based adapter that abstracts from the underlying data models, providing a unified mechanism for instance extraction across relational and NoSQL systems. 4.2. Migration Process Overview As illustrated in Figure 4, the migration process is organized into two clearly differentiated phases: schema migration and data migration. In the first phase, the source schema is transformed into a target schema through a sequence of model transformations using U-Schema as a pivot model. The initial transformation produces trace links (T 1 ) relating source and U-Schema elements. Afterwards, optional schema adaptation may be applied over the U-Schema model. During this step, trace links are updated to remain consistent with the evolved schema. Finally, the adapted U-Schema model is transformed into the target schema, producing trace links (T 2 ) between pivot and target elements. Together, these trace links enable the Data Migrator to relate source and target structures through the intermediate model, while preserving consistency across schema evolution steps. The second phase, data migration, builds upon these artifacts produced during schema migration, namely (i) generated target schema model, and (ii) the trace derived from the schemalevel correspondences. Instance-level transformations therefore materialize, at runtime, the relationships captured by this trace, without requiring additional heuristic mappings or ad-hoc rules. This design ensures structural and semantic consistency between schema and data transformations.
Figure 5: Migration Framework architecture.
Schema as an intermediate canonical representation. During this process, trace links are systematically generated and updated to capture the correspondences established between models. This transformation follows a four-step model transformation chain, illustrated in Figure 4. The following describes these four steps. Before executing this process, a model representing the source schema must be available. This model can be obtained through two alternatives. When a schema definition (e.g., SQL DDL, JSON Schema, or CQL) is available, a model injection process is applied: the abstract syntax tree (AST) of the schema is traversed and the corresponding model instance is created. If no explicit schema specification exists, the schema model can instead be inferred from the data [11] or from application code [30]. Step 1. Translation to U-Schema. An m2m transformation derives the U-Schema model from the source schema model, establishing a mapping between the metamodel of the source data model and that of the unified data model. This mapping is defined by a set of predefined rules that preserve structural and semantic properties. In cases where multiple structural representations are possible, a predefined convention is applied. For example, a 1:N relationship in a relational schema may be represented either as a Reference or as an Aggregate; by default, the former is selected. This step generates the trace T 1 , which records the correspondences between source and U-Schema elements. Step 2. Schema adaptation in U-Schema. When predefined conventions embedded in the mapping rules do not lead to the desired target schema, the U-Schema model can be refined to incorporate specific design decisions, as illustrated in Figure 6. This optional step allows designers to influence the structure of the final schema before its generation. Schema adaptations are specified using Orion, as described in Section 2.4. The designer interacts with the intermediate USchema model, typically through its textual representation (i.e., an Athena script). In our approach, the Orion engine is adapted to operate in schema-only mode, without performing data transformations, while preserving trace consistency, ensuring that T 1 is updated for each applied schema change operation. Step 3. Generation of the target schema. The U-Schema model, whether adapted or not, is transformed into the target
Figure 4: U-Schema-based Migration Process.
Figure 5 presents the architecture of the migration tool supporting the proposed process. It is organized around two main components: the Schema Migrator and the Data Migrator, connected through the traceability mechanism that captures correspondences between models. The Schema Migrator performs the model transformations required to obtain the target schema and produces the trace links, while the Data Migrator uses both the generated schema and the trace to execute data migration. Data access is encapsulated through a Reader Adapter, which abstracts interactions with the source database. The following subsections describe these components. 4.3. Schema Migrator Component The Schema Migrator transforms a schema from the source data model into the corresponding target schema using U9
stores identifier-to-identifier pairs for lightweight persistence and fast lookup, and (ii) an object map (Map<String,Object>), which links identifiers to the corresponding model elements (EObjects in EMF) to enable semantic navigation during execution. Together, these maps provide both a compact representation and an executable structure for trace queries. Figure 7 illustrates both perspectives through the transformation of a relational schema into U-Schema. A relational Table user gives rise to an EntityType user in the USchema model, while the column user.is_premium of type Boolean produces two elements: Attribute(is_premium) and PrimitiveType(Boolean).
Figure 6: Adaptation of the U-Schema model.
schema, producing the trace T 2 and completing the schema transformation process. Together with the trace T 1 generated in Step 1 and updated in Step 2, these traces establish correspondences between source, pivot, and target schema elements. Step 4. Target schema serialization. The resulting target schema model can be translated into an executable schema definition (e.g., SQL DDL, JSON, or CQL) through a model-to-text (m2t) transformation. This step materializes the schema in the target database platform and provides the structural basis for subsequent data loading. Since the semantic gap between the schema metamodel and its concrete syntax is typically small, this transformation is largely straightforward. Although this four-step process is presented as a linear process, it is inherently iterative. Designers may inspect the generated target schema and, if needed, refine the intermediate U-Schema model using Orion. Once the desired structure is achieved, the final target schema and trace links are generated.
Figure 7: Logical and physical representation of trace links (Relational to U-Schema).
In the physical representation, each logical trace entry is reflected in both maps. For example, the logical correspondence for user appears in the symbolic map as (key: “user", value: “user"), and in the object map as (key: “user", value: EObject(user)). This dual representation ensures that trace links remain structured, navigable, and technologyindependent, supporting both forward and backward exploration of mappings at different levels of granularity.
4.4. Traceability Mechanism Model-to-model transformations establish explicit mappings between elements of an input model and the elements created in the output model. These mappings are commonly recorded in order to preserve the relationships established during the transformation and to enable subsequent operations such as navigation between models, debugging, or change propagation. In our migration approach, traceability plays a central role, as the trace is used to guide data migration. During schema migration, trace links are captured, preserving the relationships between source, U-Schema, and target schema elements. As discussed in the Schema Migrator component, the traces T 1 and T 2 collectively define the schema-level correspondences between source and target elements. In this section, we focus on how these trace links are represented, maintained, and exploited in the implementation.
Composition and usage. During schema migration, trace links are generated incrementally across the transformation steps. In particular, T 1 captures mappings between the source schema model and the U-Schema model, and T 2 captures mappings between U-Schema and the target schema model. If schema adaptation is applied, T 1 is updated accordingly to maintain consistency with the adapted schema. Together, these trace structures preserve the schema-level correspondences established during the Schema Migrator phase. Figure 8 illustrates a concrete view of these correspondences for the relational-to-document running scenario. Operationally, trace information is exploited in a modular manner. The (possibly refined) T 1 trace determines how source structures are accessed at runtime, while T 2 guides the data transformation, as explained below.
A dual-map implementation for the trace. The traceability mechanism can be better understood by distinguishing two complementary perspectives. A logical view captures the abstract correspondences established between model elements during transformation, while a physical view defines how these links are implemented to support efficient lookup and navigation. From a logical perspective, trace links relate one or more elements of a source model to one or more elements of a target model, while preserving their metamodel typing. The physical view materializes the logical trace using two complementary maps: (i) a symbolic map (Map<String,String>), which
4.5. Data Migrator Component The Data Migrator is responsible for executing data migration between the source and target databases. Its behavior is driven by the trace established during schema migration. While 10
Figure 8: Schema-level correspondences (Relational to Document migration). Figure 9: U-Schema-based Adapter for reading source data.
trace information establishes what structural correspondences exist between source and target schemas, this component defines how data instances are read, transformed, and written consistently with those correspondences. It relies on the T 2 trace to determine how U-Schema elements are materialized in the target schema, while source data access is delegated to a USchema-based adapter, which exploits the (possibly refined) T 1 trace to ensure database independence. The following subsections describe its operation.
instances are exposed through the USchemaCursor, which provides uniform access to identifiers, attributes, references, and aggregates regardless of the source database technology. public interface USchemaCursor { String getEntityName(); Object getAttributeValue(Attribute att); String getAttributeType(Attribute att); USchemaID getID(); USchemaCursor getReference(Reference ref); USchemaCursor getAggregate(Aggregate agg); boolean hasData(); void next(); void close(); }
4.5.1. The Unified Reader Adapter Data migration across heterogeneous database systems typically requires technology-specific mechanisms to access source data. In our approach, this variability is handled through a U-Schema-based adapter named USchemaAdapter, which provides a uniform abstraction for reading source instances independently of the underlying data model. The adapter isolates the Data Migrator from technologyspecific details, including connection management, data access, and result handling. Each supported database system (e.g., PostgreSQL, MongoDB, Cassandra, Neo4j) provides a concrete implementation of the USchemaAdapter interface, as illustrated in Figure 9. The adapter follows a driver–cursor pattern, abstracting query execution and iterative access to result sets. The USchemaAdapter interface defines a minimal, technologyagnostic contract for opening connections, retrieving instances of a given U-Schema EntityType, and closing sessions:
Each adapter implementation translates these abstract operations into the native access language of the source database (e.g., SQL queries, MongoDB cursors, Cypher traversals), returning data in a form consistent with the U-Schema model. This abstraction enables the Data Migrator to process entities uniformly across relational and NoSQL systems, while supporting streaming iteration over instances through cursor-based access, thereby avoiding the need to materialize entire datasets in memory. The USchemaAdapter API therefore provides: • A logical interface expressed in terms of U-Schema elements (EntityType, Attribute, Reference, Aggregate);
public interface USchemaAdapter { //open and terminate session String openConnectionService( String server, String service, String username, String password); void closeConnection(); // Iterate over all instances USchemaCursor readEntityAll(EntityType st); }
• Iterative, cursor-based access that abstracts systemspecific result formats; • Extensibility through the implementation of new adapters for additional database technologies; • Seamless integration with the trace mechanism, since USchema identifiers align data instances with their schemalevel correspondences.
Through this interface, the Data Migrator accesses instances of a given EntityType defined in the U-Schema model. These 11
between entities, the trace enables the migrator to reconstruct nested structures and complex object hierarchies during transformation. 4. Writing data to the target system. Once a source instance has been transformed, it is serialized according to the target schema and written to the target database using its native access mechanisms. (e.g., SQL INSERT statements or MongoDB insertMany operations). To improve performance, transformed instances may be temporarily buffered and written in batches, reducing the overhead of individual write operations. During this stage, the Data Migrator maintains concurrent connections to the source and target systems, allowing data to be efficiently streamed or buffered between them. Depending on the configuration, the migration process may either generate intermediate files (e.g., JSON or CSV) for bulk loading or perform direct streaming migration. 5. Finalization and integrity checking. After all target entities have been processed, connections to the source and target databases are properly closed.
4.5.2. Execution Pipeline The Data Migrator executes a trace-driven pipeline that transforms source data into target instances according to the schema correspondences established during schema migration. It iterates over the entities in the target schema and performs the following stages: 1. Initialization and connection. The concrete adapter corresponding to the source database is initialized. A connection is established through the openConnectionService method, enabling the migration process to operate either in batch or streaming mode depending on data volume. 2. Preparing source data access through a cursor. The entities in the target schema are traversed and, for each entity te in the target schema, the trace T 2 is consulted to determine the corresponding EntityType ue in the U-Schema model. The adapter operation readEntityAll is then invoked to obtain a USchemaCursor for ue, which provides access to the corresponding source instances 3.Instance transformation guided by the trace. Each instance of ue retrieved through the cursor is transformed into an instance of te. For each feature of te, the trace T 2 is consulted to identify the corresponding U-Schema feature (attributes, keys, references, and aggregates), and the transformation is performed accordingly, ensuring that the resulting instances conform to the target schema. These transformations realize at the instance level the correspondences established during schema migration. Attributes may be renamed or cast to different data types, aggregates can be embedded or flattened, and references may be normalized or externalized depending on the structural mapping. No new semantics are introduced at this stage; the migrator materializes the target representation of each source instance according to the defined mappings.
The pipeline can be abstracted as: // Step 1: Initialization sourceAdapter = initializeAdapter(T1) sourceAdapter.openConnectionService() targetConnection = open() // Step 2: Preparing source data access for each target entity te in targetSchema: ue = lookupUSchemaEntity(T2, te) // retrieve source instances corresponding to ue cursor = sourceAdapter.readEntityAll(ue) // Step 3: Instance transformation while cursor.hasData(): src = cursor.current() tgt = transformInstance(T2, src)
Attributes. Attribute values are transformed by mapping them to the corresponding target data types.
// Step 4: Writing to target writeNative(targetConnection, te, tgt) cursor.next()
Keys. Keys are handled similarly to attributes, with additional processing required for compound keys. References. The processing of references varies depending on their type and cardinality, for example, some references originate from RelationshipTypes and may have additional attributes. For each reference, the adapter provides a cursor capable of iterating through the referenced instances. This makes it possible to retrieve the values of their identifiers to include them in the reference and also provides the capability to retrieve the values of additional attributes in the case of RelationshipTypes.
// Step 5: Finalization targetConnection.close() sourceAdapter.closeConnection()
This iterative, cursor-based execution strategy enables scalable data processing while preserving independence from the source data model through the adapter abstraction. 4.5.3. Implementation and Integration The implementation of the Data Migrator component is structured into three main modules that cooperate to execute the migration pipeline while maintaining independence from the underlying database technologies:
Aggregates. Aggregates are processed in a similar way to references. For each aggregate, the adapter provides a cursor capable of traversing the instances of the aggregate entity and retrieving its attributes, references and any other aggregates it may contain. The trace also determines the origin of reference and aggregate features, guiding the retrieval of related data through the adapter. By encoding structural dependencies
1. Trace Interpreter: Parses the trace T 2 and resolves, for each target schema feature, the corresponding U-Schema elements and the conversion functions required to materialize them in the target database. 12
2. Adapter Manager: Executes queries on the source database through the U-Schema adapter and manages the cursors required to navigate attributes, references, and aggregates. This module ensures that all data associated with an entity instance—including nested or referenced structures—can be retrieved consistently.
key dependencies are explicitly modeled by the class FKey. A foreign key references a target key and specifies the referential actions applied on deletion or update through the enumeration ReferentialAction (e.g., CASCADE, SET_NULL).
3. Transformation Engine: Executes the migration loop, invoking cursor operations through the Adapter Manager and applying the mappings defined in the trace to construct the target representation of each instance. 5. Schema Mapping Rules: the Relational to Document case Schema migration is not defined through direct source–target mappings, but through U-Schema as a pivot representation. For each supported paradigm, a set of mapping rules specifies how the structural elements of its schema are represented in terms of U-Schema constructs (forward mapping), and conversely how U-Schema models can be materialized in the schema constructs of that paradigm (reverse mapping). In this way, a migration between two database systems can be expressed as the composition of two transformations: one from the source schema to U-Schema, and another from U-Schema to the target schema. This pivot-based design reduces the number of required transformations from n × n pairwise mappings between paradigms to n + n mappings, while enabling uniform migration across heterogeneous database models, including relational, document, graph, and column-oriented systems. To illustrate the proposed framework, we focus on the relational–to–document migration case, one of the most frequently studied scenarios in the literature on database modernization. It involves two paradigms that differ substantially in structure and semantics, requiring the transformation from normalized relational schemas to hierarchical document structures. This scenario provides a suitable setting to demonstrate how the proposed framework separates schema and data concerns. To bridge U-Schema with the relational and document data models, we define dedicated metamodels for each paradigm together with forward and reverse mapping rules. The next two subsections introduce these metamodels and present a running example used to illustrate the mappings. We then summarize the mappings Relational → USchema and U-Schema → Document, which together describe relational-to-document migration through the pivot model. The reverse mappings follow analogous principles and are omitted for brevity, but have been implemented and applied in the evaluation of the approach.
Figure 10: Relational metamodel.
The document metamodel (Figure 11) represents the structural components of document-oriented databases, which store documents as JSON-like objects. A DocumentSchema contains one or more DocumentType elements, each of which defines a set of Property instances. A property can be either a Field, a Reference, or an Embedded element. Fields represent properties whose value is a scalar (BOOLEAN, INTEGER, DOUBLE, or STRING) or an array of scalar values. A field may optionally be marked as a key through the attribute isKey. Embedded properties represent nested document structures, and the flag isMany indicates whether the embedded object appears as a single element or as an array. References represent links between document types and specify the target document type. They are modeled as single-valued properties that store the identifier of the target document, following common practices in document-oriented databases, where relationships are typically represented through single-field identifiers rather than composite ones. Cardinality is determined through the Type hierarchy: a PrimitiveType represents single-valued properties, while an Array type represents multi-valued properties.
5.1. Relational and Document metamodels The relational metamodel (Figure 10) captures the structural components of a classical relational schema. A RelationalSchema contains one or more Tables. Each table may contain a set of Columns, and defines one or more Key elements and optionally FKey elements. Primary keys and unique key constraints are represented by the class Key, while foreign
Figure 11: Document metamodel.
13
format consisting of three parts: a short preamble, the mapping expression itself, and an optional set of final remarks. In addition, a small set of auxiliary functions and predicates is used across all mappings. This subsection introduces the notation together with two functions and three predicates used in the rules.
5.2. Running Example: Music Streaming Service To illustrate the mappings defined in the following subsections, we use a simplified Music Streaming service that captures a representative variety of structural elements. The example covers the main constructs of U-Schema, including entities, attributes, references, and aggregates. It therefore serves as a suitable domain to demonstrate both relational and document transformations. The domain involves users, playlists, songs, albums, and musical styles, as well as auxiliary structures that record listening activity. Each user has a unique identifier, can be premium or standard, and can create multiple playlists containing an ordered list of songs. Each song has a title, duration, one or more musical styles (e.g., Rock, Jazz, Pop), and may optionally be part of an album. For every user, the system maintains a list of the most recently played songs. The system also records listening activity, including the number of times each user has played a given song. Figure 12 shows the conceptual schema of this domain as a UML class diagram. This example is used in Sections 5.5 and 5.6 to illustrate the mapping rules between relational, USchema, and document models.
1) Preamble. Each rule begins with a brief textual preamble that introduces the intent of the mapping and identifies the kinds of source and target elements involved. The preamble does not contain formal expressions; its purpose is purely descriptive, helping the reader understand the scope and applicability of the rule. 2) Mapping expression. The core of each rule is written using the correspondence operator →: s → t ∥ { C1 , C2 , . . . , Cn } where s denotes an element of the source metamodel, t denotes one or more elements of the target metamodel, and each Ci is a clause expressing a declarative constraint that must be satisfied by the elements involved in the mapping. Mapping expressions are purely declarative: they specify properties that must hold between source and target elements, without prescribing any execution order, update semantics, or operational behavior. Clauses may take one of the following forms: • Equality constraint: p1 = p2 , stating that two properties have the same value (e.g., s.name = t.name). • Value constraint: p = v, stating that property p has the fixed value v (e.g., t.root = true). • Conditional clause: Q ⇒ C, meaning that clause C must hold whenever condition Q is satisfied.
Figure 12: Conceptual schema of the Music Streaming service used as running example.
• Universal clause: {C1 , C2 , . . . , Cn } : ∀x, Q(x) meaning that the clauses Ci must hold for all elements x satisfying condition Q.
Table 2 contrasts the relational and document representations of the Music Streaming service. The relational schema (left) defines normalized tables for users, playlists, and songs, with some tables (e.g., song, album, and musical_style) omitted for clarity. The document model (right) reorganizes the same information around the user, embedding playlists as nested arrays while maintaining references to songs stored in a separate collection. User listening activity is also stored in a separate collection due to its potentially large size. The structural correspondences between schemas based on different data models, such as those illustrated in Table 2, can be formally captured through mapping rules. The following subsections present the mapping rules defined in our approach for relational-to-document migration.
Clauses may include set operators (e.g., ∪, ∈, ⊆) and may be composed of subclauses connected by boolean operators such as ∧, ∨, and ¬. 3) Final remarks (optional). Following the mapping expression, certain rules include short remarks to clarify notational details or to indicate the specific collections of the target model where the resulting elements are placed. These remarks are complementary and do not introduce additional formal constructs. Auxiliary functions. Two model-independent auxiliary functions are used uniformly across all mappings:
5.3. Mapping Rule Notation and Auxiliary Functions and Predicates To formally express the schema mappings in a concise and uniform way, we adopt a declarative notation based on mapping expressions. Each mapping rule is described using a structured
• Mapping lookup. When a rule needs to refer to the target element corresponding to a source element s, we use the function map(s), which denotes “the target element produced from s by the transformation”. 14
Table 2: Relational and document representations of the Music Streaming service.
(a) Relational schema (SQL DDL, simplified)
(b) Document model (JSON excerpts)
CREATE TABLE user ( user_id CHAR(36) PRIMARY KEY, name VARCHAR(80) NOT NULL, is_premium BOOLEAN DEFAULT false, register_date DATE NOT NULL );
// Example of "user" document { "user_id": "u001", "name": "Alice", "is_premium": true, "register_date": "2025-02-25 14:09:30", "playlists": [ { "playlist_id": "p001", "name": "indi90s", "creation_date": "2026-08-26 18:20:00", "playlist_songs": [ { "position_idx": 1, "song_id": "s002" }, { "position_idx": 2, "song_id": "s007" } ] }, { "playlist_id": "p002", "name": "moviesOST", "creation_date": "2025-05-20 19:50:00", "playlist_songs": [ { "position_idx": 1, "song_id": "s054" } ] } ] }
CREATE TABLE playlist ( -- Weak table playlist_id CHAR(36) NOT NULL, user_id CHAR(36) NOT NULL, name VARCHAR(30), creation_date DATE NOT NULL, PRIMARY KEY (user_id, playlist_id), FOREIGN KEY (user_id) REFERENCES user(user_id) ); CREATE TABLE playlist_song ( -- Weak table playlist_id CHAR(36) NOT NULL, user_id CHAR(36) NOT NULL, position_idx INT NOT NULL, song_id CHAR(36) NOT NULL, PRIMARY KEY (user_id, playlist_id, position_idx), FOREIGN KEY (user_id, playlist_id) REFERENCES playlist(user_id, playlist_id), FOREIGN KEY (song_id) REFERENCES song(song_id) ); CREATE TABLE listening ( -- Associative table (MN) user_id CHAR(36) NOT NULL, song_id CHAR(36) NOT NULL, plays_count INT NOT NULL, status VARCHAR(10), PRIMARY KEY (user_id, song_id), FOREIGN KEY (user_id) REFERENCES user(user_id), FOREIGN KEY (song_id) REFERENCES song(song_id) );
// Example of "listening" document { "listening_id": "72af18c52a0f8162fc1ae15b", "user_id": "u001", "song_id": "s007", "plays_count": 7, "status": "completed" }
• Primitive type mapping. The function typeMap(dt) returns “the target data type associated with a data type dt", according to the appropriate mapping. It provides a uniform treatment of data domains for all supported paradigms.
• MN(t). The predicate MN(t) holds true when a table t represents an associative table. This occurs when there exist two foreign keys f k1 and f k2 in t such that f k1 references a table t1 and f k2 references a table t2 , and the columns of both foreign keys are also components of the primary key pk of t. In other words, the primary key of t is defined by the two foreign keys that link t to t1 and t2 , thereby materializing a many-to-many relationship between them. Moreover, pk could include additional columns. MN(t) = ∃ f k1 , f k2 ∈ t. f ks ( f k1 , f k2 ∧
Auxiliary predicates. We introduce three predicates to characterize relational structures: foreign keys that are part of the primary key of their table, weak tables, and associative tables. • FkInPk(t, fk). The predicate FkInPk(t, f k) holds true when a foreign key f k in a table t is part of the primary key pk of t.
FkInPk(t, f k1 ) ∧ FkInPk(t, f k2 ) )
FkInPk(t, f k) = f k.columns ⊆ pk.columns
5.4. Mapping Conventions When multiple alternatives exist for representing a given schema structure, our approach applies predefined conventions to derive a canonical target schema. These conventions ensure deterministic transformations and avoid the need for additional configuration during schema migration. The main conventions used in the relational to document migration are as follows:
where pk ∈ t.keys ∧ pk.isPK • Weak(t). The predicate Weak(t) holds true when a table t represents a weak table. This situation occurs when the primary key pk of t includes exactly one foreign key f k that references another table s (the strong one). In this case, the foreign key contributes to the identification of each row in t, meaning that the existence of the records in t depends on the corresponding records in s.
• Foreign keys. – If a foreign key participates in the primary key of a table t satisfying Weak(t), t is mapped to an aggregate of the referenced entity, unless it is referenced by other tables.
Weak(t) = ∃ f k ∈ t. f ks ( FkInPk(t, f k) ∧ ( ∄ f k′ ∈ t. f ks ( f k′ , f k ∧ FkInPk(t, f k′ ) ) ) ) 15
– Otherwise, the foreign key is mapped to a reference. For 1:1 relationships, the reference is stored in the source entity, whereas for 1:N relationships, it is stored in the target entity.
Let c be a Column in a Table t that is not part of a foreign key. Then, c is mapped to an Attribute at with the same name and the corresponding U-Schema datatype, and whose optionality (nullable or mandatory) is determined by the nullable property of the column.
• Associative tables.
c → at ∥ { at.name = c.name,
– Associative tables are mapped to separate collections rather than aggregates.
at.type = typeMap(c.datatype), at.optional = c.nullable }
– Their foreign keys are transformed into references that link the corresponding entity types.
The Attribute instance at is added to the collection st. f eatures, where st is the schema type corresponding to table t (i.e., st = map(t)). In our example, all columns are mapped to attributes, except for user_id in table playlist, user_id and playlist_id in table playlist_song, and album in table song, as they participate in foreign keys and are handled by other mapping rules.
• Composite keys. – Each composite key is mapped to a derived key attribute whose value is obtained by concatenating the values of their component attributes. 5.5. Relational to U-Schema Mapping Given a relational schema represented as a model conforming to the Relational metamodel (Figure 10), the following rules are defined to map the relational constructs to U-Schema (Figure 1). Both metamodels have a root element denoting the schema, RelationalSchema for the relational model and USchema for the U-Schema model. In that follows, such root elements denote the source and target schema. Figure 13 is used throughout this section to illustrate the application of the mapping rules. This figure omits some elements, such as MusicalStyle entity and some attributes, for the sake of clarity.
Rule R4 – Key Mapping. Let ck be a Key (primary or alternative) of t, composed by a set of columns. Assume that t is a table that does not satisfy the MN(t) predicate, and t is associated with entity type et by Rule R2, i.e., et = map(t). Then, Key ck maps to a Key k in et, and k.attributes denotes the set of attributes of et that correspond to the columns of ck, mapped by Rule R3. If ck is the primary key of t, then k is marked as identifier. ck → k ∥ { k.name = ck.constraintName, k.isID = ck.isPK,
Rule R1 – Schema Mapping.
k.attributes = {map(c) | c ∈ ck.columns } }
A RelationalSchema rS in a relational model maps to a USchemaModel uS in a U-Schema model. The mapping preserves the schema name and serves as the entry point for subsequent element-level correspondences.
The Key instance k is added to et. f eatures. For table playlist_song, for instance, the composite key pls_pk is mapped to a Key in the U-Schema model. Only the attribute position_idx is added to its attributes collection.
rS → uS ∥ { rS .name = uS .name }
Rule R5 – Weak Table Mapping. Rule R2 – Table Mapping.
Let w be a Table that satisfy the Weak(w) predicate through the foreign key f k, and let s be the table referenced by f k. Assume that w and s are associated with entity types ew and es respectively by Rule R2, i.e., ew = map(w) and es = map(s). Then, i) the entity type ew is marked as non-root, and ii) the strong/weak relationship is represented by an Aggregate ag belonging to es and specified by ew, which expresses that instances of es may contain zero or more instances of ew, capturing the 0..n multiplicity.
Each Table t in rS is mapped to a SchemaType st in uS , which is a root EntityType except when MN(t) predicate is satisfied, in which case t corresponds to a RelationshipType as specified by Rule R6. This distinction captures the semantic difference between entity tables and associative tables. t → st ∥ { st.name = t.name, (¬MN(t) ⇒ class(st) = EntityType, st.root = true ) ∨ ( MN(t) ⇒ class(st) = RelationshipType ) }
w → (ew, ag) ∥ { ew.root = false, ag.name = plural(ew.name),
The class(x) function returns the metaclass of x. The instance st is added to uS .entities if ¬MN(t), and to uS .relationships otherwise. In the running example (Fig. 13), tables app_user, album and song are mapped to entity types with root = true, and the associative table listening is mapped to a RelationshipType.
ag.lowerBound = 0, ag.upperBound = n, ag.speci f iedBy = ew } The function plural returns the plural form of its string argument. Aggregate instance ag is added to the collection es.features.
Rule R3 – Column Mapping. 16
Figure 13: Transformation of the running example across the relational, U-Schema, and document models.
17
As shown in Fig. 13, weak tables such as playlist and playlist_song are mapped to entity types with root = f alse, and to aggregates. Each aggregate belongs to the features of the corresponding root entity type, capturing the containment of weak entities, and is specified by the non root entity type.
FKey f k is mapped to a 1:1 Reference r s in et, which references to es. The reference r s is associated with new attributes corresponding to the columns of the primary key pk s of s. f k → r s ∥ { r s .name = s.name, r s .re f sT o = es,
Rule R6 – Associative Table Mapping.
r s .lowerBound = 0, r s .upperBound = 1,
As established in Rule R2, a Table m that satisfies the MN(m) predicate is mapped to a RelationshipType rm, and by Rule R3, rm contains the attributes corresponding to all columns of m, except for the foreign key components. Assume that m contains two foreign keys f k1 and f k2 referencing tables t1 and t2 , respectively. And let et1 and et2 be their corresponding entity types. i.e. et1 = map(t1 ) and et2 = map(t2 ). Those foreign keys are mapped to two Reference r1 and r2 , which denote mutual references between et1 and et2 . This representation explicitly captures the semantics of many-to-many relationships in U-Schema.
r s .attributes = {at | c → at : ∀c ∈ pk s .columns where pk s ∈ s.keys ∧ pk s .isPK} } Reference r s is added to the collection et. f eatures. Each Attribute instance at, included in r s .attributes, is also added to et. f eatures. If f k is unique, that is, there exists a Key uk in t whose columns are the same as the columns of f k, then each at is also added to the collection map(uk).attributes. Here, the correspondence operator → also appears within a clause. The weak table playlist_song provides an example of this rule, as the foreign key pls_song does not participate in the primary key and is therefore mapped to a reference in the corresponding entity type.
m →(rm, r1 , r2 ) ∥ { ∀i, i ∈ {1, 2} : { ri .name = f ki .constraintName, ri .lowerBound = 1, ri .upperBound = n,
R7.2: Foreign Key is not unique and its Table is not Weak. FKey f k maps to a 1:N Reference rt in es, which references to et. The reference rt is associated with new attributes corresponding to the columns of the primary key pkt of t. These attributes are named by appending ‘_’ followed by the referenced table name to the column name, in order to avoid duplicate attribute names.
ri .re f sT o = map( f ki .re f sT o.owner), ri .isFeaturedBy = rm } } Reference r1 is added to the features of the entity type et2 and r2 is added to the features of the entity type et1 . Both references r1 and r2 are added to rm.re f erences collection. The component columns of f k1 and f k2 are not mapped to attributes according to Rule R3, as they are not needed in the target entity types et1 and et2 , since references in U-Schema are sufficient to connect them. In the running example, the associative table listening is mapped to a RelationshipType (by Rule R2). Rule R6 introduces two references, listening_user and listening_song, within the features of entity types song and app_user respectively. These references are associated with the relationship type through isFeaturedBy and point to the corresponding entity types via refsTo.
f k → rt ∥ { rt .name = plural(t.name), rt .re f sT o = et, rt .lowerBound = 0, rt .upperBound = n, rt .attributes = {at | {c → at, at.name = concat(c.name, ‘_’, et.name) } : ∀c ∈ pkt .columns where pkt ∈ t.keys ∧ pkt .isPK} } Reference rt is added to the collection es. f eatures. Each Attribute instances at, included in rt .attributes, is also added to the collection es. f eatures. In the running example, this rule is only applied to the foreign key album_fk in the table song, which is mapped to the reference songs in the entity type album.
Rule R7 – Foreign Key Mapping. This rule defines how a foreign key f k that is not part of the primary key of its owner table t, is mapped to a reference between entities. Two variants of this rule are considered depending on whether the foreign key values must be unique, and whether the owner table t satisfies the predicate Weak(t). If the foreign key is declared as unique or is into a weak table, then it is mapped to a one-to-one reference in the same direction as f k; otherwise, it corresponds to a one-to-many reference in the reverse direction. Together, these two sub-rules model explicit referential links between entities, different from strong/weak or many-to-many relationships. Thus, let f k be a FKey element in table t that does not satisfy the predicate FkInPk(t, f k) and references table s, and let et and es the corresponding entity types, i.e., et = map(t) and es = map(s).
5.6. U-Schema to Document Mapping This section defines the mapping from U-Schema to the Document metamodel. The functions map and typeMap are used with the same meaning as in the relational to U-Schema mapping. Figure 13 is also used to illustrate the mappings. Rule R1 – Schema Mapping. A USchemaModel uS is mapped to a DocumentSchema dS preserving its name. uS → dS ∥ { dS .name = uS .name }
R7.1: Foreign Key is unique or its Table is Weak. 18
The elements of dS (i.e., its documents and types) are defined by the following rules.
link between two entity types, analogous to a foreign key in the relational model. Such a reference is mapped to a direct Reference rD . Any attributes associated with the reference are not preserved, as references are represented as single-field identifiers. The cardinality is preserved according to rU .upperBound.
Rule R2 – Root Entity Type Mapping. Each EntityType e in uS that satisfies e.root = true is mapped to a DocumentType d with the same name. e → d ∥ { d.name = e.name }
rU → rD ∥ { rD .name = rU .name,
d is added to the dS .documents collection, where dS is the document schema obtained by Rule R1, i.e., dS = map(uS ). The features of e (i.e., e.features) will be mapped to Property elements as established in rules R3 to R6, and will be added to d.properties. In the running example, the entity types song, album, and app_user are mapped to DocumentType instances, whereas those with root = f alse are handled by rule R6.
In the running example, the references pls_song and songs satisfy this condition, as they are not associated with any RelationshipType. Therefore, they are mapped to direct references, preserving their cardinality.
Rule R3 – Attribute Mapping.
Rule R6 – Aggregate (and non-root Entity Type) Mapping.
Let at be an Attribute that belongs to a schema type st (either an entity type or a relationship type) and is not part of a reference (i.e., at.re f erences is NULL). Then, at is mapped to a Field f preserving its name and with the corresponding type.
Aggregations are mapped as embedded documents, as follows. Let ag be an Aggregate that belongs to an entity type e and is specified by a non-root EntityType enr (i.e. ag.speci f iedBy = enr ). Then ag and enr are mapped to an Embedded element em. The features in enr are then recursively mapped to properties added to em.aggregates by applying the corresponding rules R3 to R6.
(rU .upperBound == 1) ⇒ rD .type = PrimitiveType, (rU .upperBound > 1) ⇒ rD .type = Array, rD .target = map(rU .re f sT o) }
at → f ∥ { f.name = at.name, f.type = typeMap(at.type) } As shown in Figure 13, all attributes are mapped to fields, with the exception of song_id in entity type playlist_song, and song_id_song in entity type album, which participate in references pls_song and songs respectively.
(ag, enr ) → em ∥ { em.name = ag.name, em.aggregates = {p | x → p, ∀x ∈ enr . f eatures}, em.isMany = ¬ (ag.upperBound == 1) }
Rule R4 – Key Mapping.
In the U-Schema model, the entity type app_user aggregates playlist which, in turn, aggregates playlist_songs. In the document model, these aggregates are mapped to embedded objects to preserve this nesting relation.
Both simple and composite keys are mapped to a single identifier field. Let k be a Key in an entity type et such that k.isID is true. If k consists of a single attribute at, then the corresponding field f = map(at) is marked as a key field. Otherwise, k is mapped to a new Field f also marked as a key. This field acts as a single identifier derived from the values of the attributes composing the key. The attribute components of k are mapped to their corresponding fields according to Rule R3 and are treated as regular fields in the target schema.
Rule R7 – RelationshipType Mapping. A RelationshipType rt in uS is mapped to a DocumentType d. The features in rt are then recursively mapped to properties added to d.properties by applying the corresponding rules. Moreover, d includes a new Field element f that plays the role of d identifier, and each reference associated with rt is expressed as the corresponding Reference within d.
k → f ∥ { ( | k.attributes | == 1 ∧ (∃ at ∈ k.attributes) ∧ f = map(at) ) ∨
rt → d ∥ { d.name = rt.name,
( | k.attributes | > 1 ∧ f.name = ‘_id’ ),
d.properties = {p | x → p, ∀x ∈ rt. f eatures},
f.isKey = true }
f.name = concat(rt.name, ‘_id’), f.isKey = true, ∀ri ∈ rt.re f erences, i ∈ {1, 2 . . . n} :
Fields corresponding to attributes belonging to keys with isID=true are marked with isKey=true in the document model. The remaining key, user_name_ak, which enforces the uniqueness of the name attribute, is not preserved, as each document type can only contain a single identifier.
[ rdi .name = ri .name, rdi .target = map(ri .re f sT o) ] } Field f and references rdi are added to d.properties, and d to dS .documents, where dS = map(uS ). Listening is the only relationship type in the U-Schema model, and it is mapped to a document type that includes two references connecting the corresponding song and app_user documents.
Rule R5 – Reference Mapping. In U-Schema, a Reference rU that belongs to an entity type e and is not associated with a RelationshipType (i.e., rU .isFeaturedBy is NULL) represents a simple, unidirectional 19
Table 3: Relational dataset composition for the Music Streaming case study.
6. Validation This section presents the evaluation of the proposed migration process through a case study involving migration from a relational to a document-oriented database. The goal is to assess whether the approach preserves the structural and semantic properties of an input relational database, and to evaluate its performance and scalability across datasets of different sizes. Therefore, the evaluation is structured around three complementary perspectives: schema-level structural preservation, data-level semantic preservation, and performance and scalability of the data migration process. To support this evaluation, the correctness of the transformation rules and their integration within the migration pipeline is verified through unit and integration testing. The schema adaptation stage, supported by the Orion language, is not considered in this evaluation. This does not affect the validity of the results, as schema adaptation is orthogonal to the migration process. Therefore, the evaluation focuses on the baseline behavior of the migration process under canonical mappings. The remainder of this section presents the validation methodology (subsection 6.1), the experimental setup (6.2), and the results of the different experiments: unit and integration testing (6.3), schema-level validation (6.4), performance and scalability (6.5), and data-level validation (6.6).
Table app_user listening most_recent_song playlist playlist_song song song_style musical_style
S
M
L
1,000 50,000 10,000 10,000 200,000 5,000 10,046 25
10,000 500,000 100,000 100,000 2,000,000 50,000 100,021 25
100,000 5,000,000 1,000,000 1,000,000 20,000,000 500,000 999,945 25
• Semantic validation of queries: representative SQL queries are executed on the source database, translated into equivalent MongoDB queries, and evaluated on the migrated data. Result equivalence is used as evidence of semantic preservation. • Performance and scalability analysis: the execution time of the migration process is measured on datasets S, M, and L to assess the feasibility and scalability of the approach. 6.2. Experimental Setup Building on the objectives and methodology outlined above, this subsection describes the datasets, execution environment, and configuration used to evaluate the proposed migration pipeline.
6.1. Methodology To evaluate the proposed approach, we combine several complementary types of experiments:
Datasets. Our evaluation relies on both synthetic and real datasets. Three synthetic datasets (S, M, L) are generated to analyze performance and scalability across increasing data volumes. The smallest dataset (S) is used for integration testing and detailed inspection. These datasets are generated from the Music Streaming running example introduced in Section 5.2 using a Python-based data generator that populates the relational schema according to parametrized cardinalities. A fixed random seed is used to ensure reproducibility. The schema includes representative relational structures such as composite keys, associative tables (M:N), and weak entities, thereby ensuring that all mapping rules involved in the migration pipeline are exercised. The composition of the relational datasets used in the experiments is summarized in Table 3, which provides a detailed view of the data distribution across the source schema. To assess generality beyond the running example, we additionally use the Northwind 1 database, a widely adopted benchmark in relational database research. Northwind includes a representative variety of relational patterns (simple and composite keys, mandatory and optional foreign keys, and associative tables), and is used to evaluate the generality of the mapping rules and the semantic preservation of business-oriented queries. This dataset has a limited size, containing approximately 1,000 tuples.
• Unit testing of transformation rules: each m2m rule participating in the migration workflow is tested in isolation using minimal input models that activate a single pattern. These tests verify rule-level correctness and conformance to the target metamodel. • Integration testing of the transformation workflow: the composed Relational → U-Schema → Document transformation is applied to representative schemas to verify that multiple rules interact correctly and produce structurally coherent intermediate and target models. • Validation of generated target schemas: the resulting document schemas are compared against the expected structures derived from the mapping rules. This step validates the correctness of the schema transformation process prior to round-trip reconstruction. • Round-trip reconstruction: relational schemas are migrated to U-Schema and then to a document-oriented model, from which a relational schema is reconstructed by applying the inverse transformation Document→ U-Schema → Relational. The reconstructed schema is compared with the original relational schema to assess structural preservation. Precision, recall, and F1-score are used to quantify the degree of correspondence between both schemas.
1 https://en.wikiversity.org/wiki/Database_Examples/Northwind/ PostgreSQL
20
Execution platform. All experiments were executed on an Amazon Web Services instance using Docker containers to deploy PostgreSQL 16 and MongoDB 2.6.0 databases. The environment runs on an x86_64 architecture with 8 GB of RAM and an Intel Xeon processor (2.50 GHz). The migration component is implemented in Java (OpenJDK 21), with the JVM heap size limited to 675 MB to ensure stable memory usage across executions.
behavior. For each test case, the resulting target model was inspected to verify that it matched the expected output, including the correct creation of elements, assignment of properties, and establishment of relationships required for subsequent transformations. (b) Integration Testing with Representative Schemas Once all rules of a transformation had passed their unit tests, we executed a second set of tests using small but representative schemas that combine multiple patterns (e.g., a relational schema with associative tables and weak entities, or a document schema involving both embedded documents and references). In these composite tests, the resulting models were also manually inspected to verify that the interaction of multiple rules produced structurally coherent and semantically meaningful models.
Pipeline configuration. Each experiment executes the complete migration pipeline, i.e., the transformation from Relational to U-Schema and from U-Schema to Document. The migration process comprises both schema transformation and data migration. Data is extracted from the relational database, transformed according to the mapping rules, and materialized as documents in the target database. To improve performance, documents are inserted in batches of 1,000 elements. In round-trip experiments, the inverse mappings of the transformation chain are applied to reconstruct a relational schema from the generated document model, following the path Document → U-Schema → Relational. This enables the evaluation of structural preservation at the schema level. All artifacts required to reproduce the experiments, including source schemas, generated document schemas, datasets, and migration scripts, are publicly available 2 .
6.4. Structural Validation This section evaluates structural preservation in the schema transformations. The validation is conducted from three complementary perspectives: (i) the correctness of the generated document schemas with respect to the expected ones, (ii) their semantic adequacy as document-oriented designs, and (iii) the preservation of the original relational schema through roundtrip reconstruction.
6.3. Testing of the m2m Transformations
6.4.1. Validation of Generated Target Schemas Document schemas were generated for the Music Streaming and Northwind case studies, covering a representative set of relational patterns. Both the generated and expected schemas are represented as instances of the Document metamodel, enabling a direct model-level comparison. The validation was conducted using complementary approaches. First, for qualitative inspection, models were visualized as UML object diagrams using a custom exporter based on PlantUML 3 , facilitating the inspection of entities, attributes, and relationships. Second, an automated comparison was performed using EMF Compare 4 , which identifies differences between model elements. In both validation approaches, no discrepancies were identified between the expected and generated schemas for either case study. While the previous subsection evaluates the structural correctness of the generated schemas by comparing them with the expected ones, we now analyze their semantic adequacy from a document-oriented perspective. In particular, we assess whether the transformation produces document structures that are consistent with established design principles, such as the use of embedding for composition-like relationships and references for associative ones. In the Music Streaming case study, tables representing weak entities (e.g., playlist, playlist_song, and most_recent_song) are systematically embedded within their
We next describe the procedure followed to ensure the correctness of the m2m transformations that form the basis of our migration process. We adopt a unit testing strategy inspired by the methodology proposed by Fernández-Candel et al. [31] for validating m2m transformations in model-driven reengineering workflows, which has also been applied in recent work on NoSQL schema extraction and refactoring [32]. Following this methodology, each m2m transformation involved in the relational to document case study was tested in isolation. In our validation scenario, the workflow includes two forward transformations, Relational → U-Schema and Document →U-Schema, as well as their corresponding reverse transformations, for which unit tests were also developed. In addition, round-trip experiments are performed to validate the behavior of the transformation chain as a whole. (a) Unit Testing of Transformation Rules The mapping rules of each transformation were developed following a test-driven approach. For each rule, we defined a minimal source micro-model and its expected target model, and then implemented and refined the rule until the produced output matched the expected result. Input models contain only the elements necessary to activate the rule under test. When a rule admits multiple alternatives, distinct input models were defined to cover each case. These micro-models are deliberately minimal to avoid interference between rules and to enable precise analysis of the transformation
3 https://plantuml.com/ 4 https://eclipse.dev/emfcompare/ 2 https://github.com/modelum/db-generic-migration
21
Here, ti and ti−1 denote forward and reverse transformations, respectively; U and U ′ are the intermediate U-Schema models, D is the document model, and R′ is the reconstructed relational schema. The original schema R and the reconstructed schema R′ were compared using two complementary approaches. First, a model-level comparison was performed using EMF Compare. Second, both schemas were exported to SQL DDL through a model-to-text transformation and compared using a structural diff. This DDL-based comparison provides a readable, implementation-level view of discrepancies in table definitions and key constraints.
corresponding strong entities (e.g., user), forming hierarchical aggregates. This avoids the use of explicit references while preserving containment relationships, in line with the mapping conventions. In contrast, relationships such as listening, which correspond to many-to-many associations without ownership semantics, are mapped to independent collections rather than embedded structures. In contrast, the Northwind schema does not contain weak tables and therefore does not give rise to embedded structures. Instead, all tables are mapped to document collections, and relationships are represented through references. In particular, foreign keys are translated into arrays of identifiers, capturing one-to-many relationships, while many-to-many relationships (e.g., order_details) are mapped to independent collections with references to the related entities. These results show that the migration process adapts the structure of the target document schema according to the semantics of the source model, applying embedding for composition-like relationships and referencing for associative ones. This behavior reflects the mapping rules defined in Section 5, where weak entities are systematically transformed into embedded structures, and associative relationships are mapped to references or separate collections. A representative fragment of the generated document structure for the app_user entity in the Music Streaming case study is shown below, illustrating the embedding of weak entities and the use of references.
Metrics. Schema preservation is assessed using precision, recall, and F1-score over the set of matched schema elements. These metrics provide a quantitative indication of how accurately the reconstructed schema preserves the elements of the original schema. Precision reflects the absence of spurious elements, while recall captures the degree of preservation of the original ones, and the F1-score summarizes both aspects. The evaluation is performed at different structural levels, including entity types (tables), attributes, primary keys, foreign key relationships, integrity constraints, and data types. For each category, true positives correspond to correctly reconstructed elements, false negatives to missing elements, and false positives to incorrectly generated elements. Matching is performed at the structural level, ignoring naming differences, so that semantically equivalent elements are considered correct even if their identifiers differ.
{ "_id": "...", "user_id": "...", "name": "user_0", "is_premium": true, "register_date": "...", "playlists": [ { "playlist_id": "...", "name": "Playlist_0", "creation_date": "...", "playlists_songs": [ { "position_idx_id": 1, "playlist_song": ["song_id_1"] } ] } ], "most_recent_songs": [ { "position_idx_id": 1, "most_recent_song": ["song_id_1"] } ]
Results. Table 4 reports the schema preservation metrics for both case studies. Entity types are perfectly preserved in both datasets, achieving precision and recall of 1.0. This confirms that the transformation pipeline consistently reconstructs the overall structure of the schema. Attribute-level preservation is also high in both cases. Slightly lower scores in the Northwind dataset are explained by the larger number of foreign keys and associative tables, which require more complex transformations and increase the likelihood of attribute restructuring. This effect is more pronounced in schemas with a higher density of relationships, such as Northwind. More significant differences are observed in primary keys. Composite keys are systematically replaced by surrogate identifiers when mapping through the document model. This transformation affects associative tables and other structures relying on composite identifiers, which are present in both datasets. In Northwind, these mainly correspond to classical many-to-many relationships, making the effect more apparent. While this preserves entity identification, it reduces recall since the original key semantics are not fully retained. Foreign key relationships are well preserved in both case studies. In the Northwind dataset, which contains a higher number of foreign keys, including multiple references within the same table, the transformation correctly generates distinct attributes for each reference. As a result, no ambiguities arise,
}
6.4.2. Round-trip Validation The round-trip reconstruction experiment evaluates whether the migration pipeline preserves the structural information of a relational schema when it is transformed into a document model and subsequently reconstructed back into a relational representation. Methodology. For a given relational schema R, the round-trip is defined as: t1
t2−1
t2
t1−1
R− → U −−→ D − → U ′ −−→ R′ . 22
Table 4: Schema preservation metrics (P: Precision, R: Recall, F1: F1score).
Element Entities Attributes Primary Keys Foreign Keys Constraints Data Types
Music Streaming P R F1 1.00 1.00 1.00 0.97 0.95 0.96 0.90 0.75 0.82 0.96 0.90 0.93 0.70 0.50 0.58 0.60 0.60 0.60
Table 5: Data migration performance across datasets of increasing size (S: small, M: medium, L: large), derived from the running example.
Northwind P R F1 1.00 1.00 1.00 0.95 0.92 0.93 0.85 0.65 0.74 0.96 0.88 0.92 0.65 0.40 0.49 0.55 0.55 0.55
Metric
and the observed differences are limited to naming conventions that do not affect structural correctness. The preservation of integrity constraints shows lower scores. Some constraints, such as uniqueness, are not retained, while some NOT NULL constraints are lost. This indicates that, although the transformation rules aim to preserve both structure and semantics, certain constraint semantics are only partially captured in the target schema. Unique keys are not preserved, as the document model supports only one identifying field per document type. Data type preservation is also limited, as the document model does not strictly distinguish between types of length or precision. Specific relational types are consistently mapped to more general representations such as VARCHAR(255) and NUMERIC(38). This results in a loss of expressiveness rather than structural correctness. Overall, the results indicate that the approach achieves high structural fidelity, particularly for entities and relationships, while partially losing semantic information related to keys, constraints, and data types. These differences arise from the transformation between data models with different structural characteristics and constraint mechanisms. The migration process does not aim to produce an identical representation of the source schema, but rather to preserve its essential structural and semantic properties within the constraints of the target document model. As a result, certain aspects of the original schema, such as composite keys and constraint semantics, cannot be fully preserved.
S
M
L
Dataset characteristics Total rows Database size (relational) Database size (document)
286,071 95 MB 16.17 MB
2,860,046 879 MB 159.18 MB
28,599,970 8,706 MB 1,546.24 MB
Migration performance Elapsed time Throughput (rows/sec) CPU usage RAM usage
1 min 3 s 4,540.80 30% 675 MB
9 min 40 s 4,931.11 32% 675 MB
96 min 54 s 4,919.15 30% 675 MB
prove performance, documents were generated and inserted in batches of 1,000. Throughput is measured in terms of processed source rows per second. Scalability analysis. As shown in Table 5, the throughput remains relatively stable across all dataset sizes (around 4.9K rows/sec), with only minor variations. This indicates nearlinear scalability with respect to the data volume, and that the overall migration time increases proportionally with the dataset size. Impact of schema structure. The migration cost varies significantly across entities. The app_user entity dominates the total execution time, as it requires aggregating data from multiple relational tables (playlist, playlist_song, and most_recent_song) into nested document structures. This aggregation avoids the creation of separate collections for these tables, but increases the complexity of the transformation process. The migration of the app_user entity alone takes 39 seconds for dataset S, 6 minutes and 14 seconds for M, and 62 minutes and 41 seconds for L, confirming that complex aggregation patterns have a significant impact on the overall migration cost. Storage comparison. As shown in Table 5, the size of the document database is significantly smaller than that of the relational database in all cases. This reduction is mainly due to the elimination of associative tables and the use of embedded structures, which reduce redundancy in relationship representation. It is important to note that this effect depends on the chosen mapping strategy. In scenarios with high duplication due to embedding, the document database may become larger. Therefore, storage size is influenced by the structural decisions made during schema transformation.
6.5. Data migration performance While schema migration is completed in the order of milliseconds, its execution time is negligible compared to the cost of data migration. Therefore, this subsection focuses on evaluating the performance of the data migration process and its scalability across datasets of increasing size. To this end, we conducted experiments on the datasets defined in the experimental setup (S, M, and L), derived from the Music Streaming running example. Table 5 reports the observed performance results. The reported time includes the complete data migration process (i) accessing trace T 2 to identify the U-Schema elements corresponding to target collections, attributes, and references, (ii) resolving source elements through trace T 1 using the adapter, (iii) reading data from the relational database, (iv) transforming it into document-oriented structures, and (v) writing the resulting documents into the target database. To im-
Northwind dataset. The migration of the Northwind dataset was completed in 0.02 seconds. Due to its limited size, this dataset is not suitable for performance analysis, but shows that the approach can be applied to a widely used relational benchmark schema. 6.6. Data-level validation Beyond structural preservation, the migration process must ensure that applications observe the same behavior when interacting with the migrated database. To assess this, we executed 23
a set of representative SQL queries over the source relational databases of both case studies and translated each of them into corresponding MongoDB queries over the migrated document stores. The results of both query versions were compared to verify that they return identical result sets. Simple queries were expressed using MongoDB’s find API, while more complex queries involving joins, aggregations, or nested structures were implemented using the MongoDB aggregation framework. Each SQL query was translated into MongoDB following the structural correspondences defined by the mapping rules presented in Section 5. Both query versions were executed over datasets S and M. A larger set of queries was executed during validation, from which Table 6 presents a representative subset. The selected queries cover the main relational access patterns exercised by the mapping rules, including joins (1:N and M:N), aggregations, weak-entity structures, and self-referencing relationships. These patterns are reflected in queries involving weak entities and their corresponding embedded structures in the document model (Q1), multiple joins and join–aggregation combinations (Q2 and Q3), and more complex join patterns such as 1:N, M:N, and self-referencing relationships (Q4–Q6). In the document model, these cases are resolved through aggregation pipelines and traversal of embedded objects or arrays of references. For each query, the table summarizes its purpose, the relational pattern involved, the MongoDB operators used in the translation, the cardinality of the result on the source database, and an equivalence score. The score is 1 when both versions return identical result sets (ignoring ordering when not semantically relevant), and 0 otherwise. All evaluated queries returned identical results across the source and target databases, confirming correct data migration and preservation of query semantics. The comparison considered both the number of returned tuples and their content, ensuring full equivalence between relational and document query results. The migration pipeline therefore preserves the behavior of common operations even when the underlying representation changes from a normalized relational schema to a denormalized document model. The correct handling of joins, aggregations, and nested document access patterns indicates that the transformation chain preserves the semantics expected for typical query patterns. In particular, relational joins are realized either through embedded document traversal or through explicit reference resolution (e.g., using $lookup), depending on the structure of the generated document schema. This is illustrated by queries such as Q3 and Q6, where joins are translated into aggregation pipelines involving multiple stages. The evaluation also highlights that the choice between embedding and referencing does not compromise query semantics, although it influences the form of the query in the target model. Queries such as Q1 traverses nested document structures without requiring explicit joins. Finally, the evaluation confirms that the migration process correctly handles self-referencing relationships, as demonstrated by queries over hierarchical structures in the Northwind dataset.
6.7. Threats to Validity Internal validity. The correctness of the data-level validation depends on the accurate translation of SQL queries into MongoDB queries. Although these translations were carefully constructed following the applied mappings, manual errors may still affect the results. In addition, result equivalence was assessed by comparing tuple counts and contents, ignoring ordering when not semantically relevant. External validity. The evaluation focuses on the migration from relational to document databases based on two datasets, which may limit the generalizability of the results to other data models and migration scenarios. Although round-trip validation partially assesses the reverse direction, additional experiments would be required to confirm the applicability of the approach to other combinations of source and target models. Furthermore, the evaluated datasets, although representative, may not capture the full diversity of schema complexity found in real-world systems. Scope of the evaluation. This study focuses on correctness and scalability of the migration process. Query performance was not assessed, as optimization is considered a separate concern that depends on workload characteristics and schema design decisions. 7. Conclusions This work presents a generic approach to database migration based on a unified intermediate representation (U-Schema) and a set of bidirectional mappings between data models. The use of a pivot model reduces the number of required transformations from pairwise mappings between data models to a linear set of mappings to and from the intermediate representation. In addition, the approach decouples data migration from the source schema through the use of trace information, enabling data extraction and transformation to be performed independently of specific source and target technologies. This combination provides a practical form of model independence, while preserving the essential structural characteristics of the data. The experimental evaluation confirms that the approach achieves a high degree of structural preservation. Round-trip reconstruction shows that entity types and relationships are consistently preserved, while expected differences arise in aspects such as composite keys, constraints, and data types due to the transformation across data models. The generated document schemas are also consistent with the intended design decisions, reflecting the use of embedding and referencing according to the semantics of the source model. At the data level, the results demonstrate that the migrated databases produce results equivalent to those of the original systems across a representative set of queries, covering joins, aggregations, nested structures, and self-referencing relationships. A key contribution of this work is the separation between canonical schema generation and schema adaptation within a unified migration workflow, both coordinated through trace information. The trace also enables data migration to be performed independently of the source schema, ensuring consistency between schema and data transformations while allowing 24
Table 6: Representative queries used for semantic validation.
ID
Dataset
Q1
Music Streaming
Q2
Music Streaming
Q3
Music Streaming
Q4
Northwind
Q5
Northwind
Q6
Northwind
Purpose Playlists of a user with their songs. Styles of a given song. Number of users who have listened to more than 4 songs at least 10 times each. Customers and order dates information for a given shipper’s orders. Customer, products and product categories in a given order. Managers of employees involved in a given customer’s orders.
SQL Pattern
MongoDB ops
Card.
Eq.
Join(1:N) strong/weak
aggregate+unwind
∼200
1
Join(M:N)
aggregate+lookup
∼3–5
1
Aggregation+Join (1:N)
aggregate+group+lookup
1
1
Join(1:N)
aggregate+unwind+lookup
∼100–300
1
Joins(1:N and M:N)
aggregate+lookup+unwind
∼5–10
1
Join(1:N) + self-reference
aggregate+lookup
∼1–2
1
Finally, we plan to explore the extension of the approach to application-level migration, including query and code transformation. In this context, recent advances in large language models (LLMs) offer promising opportunities to assist in translating data-access logic across heterogeneous paradigms, complementing model-driven techniques.
the target schema to be adapted without redefining the schema transformation pipeline. Overall, the use of a pivot model combined with trace-based transformations provides a practical foundation for building extensible and technology-agnostic migration workflows, while maintaining a clear separation of concerns between the different stages of the process. The proposed approach does not currently incorporate workload information when generating the target schema, as its primary goal is to provide a generic and model-driven migration mechanism across heterogeneous data models rather than to produce optimized schemas. Instead, schema optimization is deliberately left to the database designer, who can adapt the generated schema to application-specific requirements using transformation mechanisms such as Orion during the migration process. However, workload-aware optimization is considered a complementary extension that can be further integrated to guide schema transformations in a more automated manner. Future work will focus on several directions. First, we plan to extend the approach to additional data models, such as graph and columnar databases, to further assess its generality. Another important direction concerns schema adaptation within the migration pipeline. While the current migration strategy supports adaptation through the Orion language, we plan to incorporate workload-aware information (e.g., query patterns, data access frequency, or data volume) into this stage to guide and parameterize schema transformations. This would enable the generation of target schemas better aligned with application requirements, while preserving the generality of the migration process.
CRediT author statement María-José Ortín: Conceptualization, Investigation, Methodology, Software, Validation, Writing- Original draft preparation, Writing– Reviewing and Editing. José R. Hoyos: Conceptualization, Investigation, Methodology, Software, Supervision, Validation, Writing- Original draft preparation, Writing– Reviewing and Editing. Jesús J. García-Molina: Conceptualization, Funding acquisition, Project administration, Investigation, Methodology, Supervision, Validation, WritingOriginal draft preparation, Writing- Reviewing and Editing. Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Declaration of AI-assisted tools The authors used generative AI tools (ChatGPT, OpenAI) for language refinement and editing to improve clarity and readability of the manuscript. All generated content was carefully 25
reviewed, validated, and revised by the authors. The authors take full responsibility for the content of the published article.
[11] C. J. F. Candel, D. S. Ruiz, J. J. G. Molina, A unified metamodel for nosql and relational databases, Information Systems 104 (2022) 101898. doi:10.1016/ J.IS.2021.101898.
Acknowledgements
[12] A. H. Chillón, M. Klettke, D. S. Ruiz, J. G. Molina, A generic schema evolution approach for nosql and relational databases, IEEE Trans. Knowl. Data Eng. 36 (7) (2024) 2774–2789. doi:10.1109/TKDE.2024.3362273.
This work was supported by project PID2020-117391GBI00, funded by MICIU/AEI/10.13039/501100011033 (Spain), and co-funded by ERDF/EU.
[1] P. Sadalage, M. Fowler, NoSQL Distilled. A Brief Guide to the Emerging World of Polyglot Persistence, AddisonWesley, 2012.
[13] Google Cloud Architecture Center, Database migration: Concepts and principles, last updated April 29, 2025 (2025). URL https://cloud.google.com/architecture/ database-migration-concepts-principles-part-1
[2] DB-Engines, Db-engines ranking, engines.com/en/ranking, accessed: (2026).
https://dbJanuary 2026
[14] M. Brambilla, J. Cabot, M. Wimmer, Model-Driven Software Engineering in Practice, Morgan & Claypool Publishers, 2012.
[3] F. Kiehn, M. Schmidt, D. Glake, F. Panse, W. Wingerath, B. Wollmer, M. Poppinga, N. Ritter, Polyglot data management: state of the art & open challenges, Proc. VLDB Endow. 15 (12) (2022) 3750–3753. doi:10.14778/ 3554821.3554891.
[15] P. A. Bernstein, A. Y. Halevy, R. Pottinger, A vision of management of complex models, SIGMOD Rec. 29 (4) (2000) 55–63.
References
[16] J. Hainaut, The transformational approach to database engineering, in: Generative and Transformational Techniques in Software Engineering, International Summer School, GTTSE 2005, Braga, Portugal, July 4-8, 2005. Revised Papers, 2005, pp. 95–143. doi:10.1007/ 11877028\_4.
[4] N. Roy-Hubara, P. Shoval, A. Sturm, Selecting databases for polyglot persistence applications, Data Knowl. Eng. 137 (2022) 101950. URL https://doi.org/10.1016/j.datak.2021.101950
[17] R. Elmasri, S. B. Navathe, Fundamentals of Database Systems, 7th Edition, Pearson, 2015.
[5] T. Jia, et al., Model transformation and data migration from relational database to mongodb, in: IEEE Int. Congress on Big Data, 2016, pp. 60–67.
[18] J.-M. Hick, J.-L. Hainaut, Strategy for database application evolution: The DB-MAIN approach, in: International Conference on Conceptual Modeling, Springer, 2003, pp. 291–306.
[6] H. Kim, E. Ko, Y. Jeon, K. Lee, Techniques and guidelines for effective migration from RDBMS to nosql, J. Supercomput. 76 (10) (2020) 7936–7950.
[19] PartiQL Specification Committee, PartiQL Specification, accessed May 2023. URL https://partiql.org/assets/PartiQLSpecification.pdf
[7] E. M. Kuszera, L. M. Peres, M. D. D. Fabro, Toward RDB to nosql: transforming data with metamorfose framework, in: C. Hung, G. A. Papadopoulos (Eds.), Proceedings of the 34th ACM/SIGAPP Symposium on Applied Computing, SAC 2019, Limassol, Cyprus, April 8-12, 2019, ACM, 2019, pp. 456–463. doi:10.1145/ 3297280.3299734.
[20] P. Atzeni, F. Bugiotti, L. Rossi, Uniform Access to Nonrelational Database Systems: The SOS Platform, in: 24th International Conference on Advanced Information Systems Engineering (CAiSE), Gdansk, Poland, 2012, pp. 160–174.
[8] L. Rocha, et al., A framework for migrating relational datasets to nosql, in: Procs. ICCS 2014, Vol. 51 of Procedia Computer Science, Elsevier, 2015, pp. 2593–2602.
[21] A. Hernández Chillón, D. Sevilla Ruiz, J. Garcia-Molina, Athena: A Database-Independent Schema Definition Language, in: Advances in Conceptual Modeling - ER 2021 Workshops CoMoNoS, St.John’s, NL, Canada, Vol. 13012, 2021, pp. 33–42. doi:10.1007/978-3-03088358-4.
[9] M. Scavuzzo, E. D. Nitto, S. Ceri, Interoperable data migration between nosql columnar databases, in: 18th IEEE EDOC Workshops, 2014, pp. 154–162. [10] G. Schreiner, D. Duarte, R. dos Santos Mello, Bringing SQL databases to key-based nosql databases: a canonical approach, Computing 102 (1) (2020) 221–246.
[22] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks, EMF: Eclipse Modeling Framework 2.0, Addison-Wesley Professional, 2009. 26
[23] L. Bettini, Implementing Domain Specific Languages with Xtext and Xtend - Second Edition, 2nd Edition, Packt Publishing, 2016. [24] G. Zhao, Q. Lin, L. Li, Z. Li, Schema conversion model of sql database to nosql, in: 9th Int. Conf. on P2P, Parallel, Grid, Cloud and Internet Computing, IEEE, 2014, pp. 355–362. [25] Y. Wang, R. Shah, A. Criswell, R. Pan, I. Dillig, Data migration using datalog program synthesis, Proc. VLDB Endow. 13 (7) (2020) 1006–1019. doi:10.14778/3384345.3384350. URL http://www.vldb.org/pvldb/vol13/p1006wang.pdf [26] J. Hainaut, V. Englebert, J. Henrard, J. Hick, D. Roland, Database Evolution: the DB-Main Approach, in: P. Loucopoulos (Ed.), Entity-Relationship Approach ER’94, Business Modelling and Re-Engineering, 13th International Conference on the Entity-Relationship Approach, Manchester, UK, December 13-16, 1994, Proceedings, Vol. 881 of Lecture Notes in Computer Science, Springer, 1994, pp. 112–131. [27] J.-L. Hainaut, A. Cleve, J. Henrard, J.-M. Hick, Migration of Legacy Information Systems, Springer Berlin Heidelberg, 2008, pp. 105–138. doi:10.1007/978-3-54076440-3\_6. [28] A. Dziedzic, A. J. Elmore, M. Stonebraker, Data transformation and migration in polystores, in: IEEE HPEC, 2016, pp. 1–6. [29] W.-C. Chung, H.-P. Lin, S.-C. Chen, M.-F. Jiang, Y.-C. Chung, Jackhare: a framework for sql to nosql translation using mapreduce, Automated Software Engineering 21 (2014) 489–508. [30] C. J. F. Candel, A. Cleve, J. J. G. Molina, Towards the automated extraction and refactoring of nosql schemas from application code, J. Syst. Softw. 236 (2026) 112787. doi:10.1016/J.JSS.2026.112787. [31] C. J. F. Candel, J. G. Molina, F. J. B. Ruiz, J. R. H. Barceló, D. S. Ruiz, B. J. C. Viera, Developing a modeldriven reengineering approach for migrating PL/SQL triggers to java: A practical experience, Journal Systems and Software 151 (2019) 38–64. doi:10.1016/ j.jss.2019.01.068. [32] C. J. F. Candel, A. Cleve, J. J. G. Molina, Towards the automated extraction and refactoring of nosql schemas from application code, CoRR abs/2505.20230 (2025). doi: 10.48550/ARXIV.2505.20230.
27
Rel → Doc, Col
[7]
Rel → KV/Doc/Col
[8]
Rel → Col
[9]
Rel → Doc/Col/KV
[10]
Rel → Doc/Col/KV
[24]
[25]
Table 7: Comparison of migration approaches according to the proposed criteria. [6]
Our approach
Rel → Col
Rel/NoSQL →
[5]
Model-independent via U-Schema
Rel → Doc
Producer–consumer queue ETL
Traversal of canonical model
SQL→KV middleware
No
Execute programs
Datalog
I/O examples
Yes (data only)
Datalog program synthesis No (implicit mappings)
(data
[18]
Multi-model only)
[28]
(query
REST API generation
U-Schema mappings + U-Schemabased adapter Batch ETL applying U-Schema mappings Not addressed
Model transformations (Xtend) Yes: alternative mappings + Orion refinement Yes
Rel/NoSQL
Model-specific
Rel → Polystore
Model-specific
Criterion
Model-specific
C1. Data models (source → target)
Model-specific
Rel/Doc/Graph → Rel/Doc/Graph (data)
Model-specific
Rel/ORel/XML → Same models
(no
No ETL rewriting)
HBase API adaptation
Partially described
DDL → HBase
C2. Platform independence
DAG
DDL → MongoDB
Multi-model NoSQL)
ETL-layer logic
Model transformations Limited (manual)
ETL
None
Not modelindependent
Partially modelindependent (Doc+Col) DDL + target logical schema DAG per entity
C4b. Schema mappings: implementation No
in
No
C5. Schema-conversion customization
Yes
for-
DDL (parsed)
Metamodels per model U-Schema universal model Explicit mappings over U-Schema
C3a. Schema reps.: source/target
No explicit schema abstraction None (examplebased) Implicit in synthesized Datalog
C3b. Schema reps.: intermediate models
Relational DDL → NoSQL model Rel→NoSQL conversion graph Algorithmic (implicit variability)
DDL + logical schemas Extended ER (DBMain) Explicit
Partially modelindependent (Doc/Col/KV) Relational DDL → NoSQL schema Canonical hierarchical model Procedural mapping over canonical model Procedural canonical transformations No (canonical fixed)
No
Yes
ER → MongoDB schema Annotated ER + directed graph Procedural rules
Binary/CSV mats Implicit
Transformations to column model No
Yes
C6. Data migration supported
C4a. Schema mappings: explicitness
Procedural rules + wrappers No (fixed strategy)
Yes
Canonical model
Spark-based from DAG
SQL wrapping to NoSQL
Graph algorithm
DAG traversal procedures No (fixed pipeline)
No
Relational schema + columnar model
Annotated derived graph
No dedicated ETL
No
Columnar metamodel Implicit in columnar mapping Heuristics, no mapping language No
Yes
Relational schema + SQL queries
Explicit mappings
Traversal-based ETL
SQL→HBase API adaptation
Implicit logic Algorithmic traversal Limited (heuristics only)
DAG + columnar metamodel
Schema + binary formats
Mapping-driven ETL
No
ER-
C7. Data-migration inputs
Binary-format ETL
Some code generation
schema
C8. ETL strategies
No
DDL + workload graphs Transaction/query graphs Implicit (guidelines)
Yes
Partial (denormalization only) Schema + workload stats
Relational schema + NoSQL target model Not described
C9. Code adaptation required
28