Abstract
Relational database has been the de-facto database choice in most IT applications. In the last decade there has been increasing demand for applications that have to deal with massive and un-normalized data. To satisfy the demand, there is a big shift to use more relaxed databases in the form of NoSQL databases. Alongside with this shift, there is a need to have a structured methodology to transform existing data in relational database (RDB) to NoSQL database. The transformation from RDB to NoSQL database has become more challenging because there is no current standard on NoSQL database. The aim of this paper is to propose transformation rules of RDB Schema to various NoSQL database schema, namely document-based, column-based and graph-based databases. The rules are applied based on the type of relationships that can appear in data within a database. As a proof of concept, we apply the rules into a case study using three NoSQL databases, namely MongoDB, Cassandra, and Neo4j. A set of queries is run in these databases to demonstrate the correctness of the transformation results. In addition, the completeness of our transformation rules are compared against existing work.
Highlights
Relational database (RDB) stores data into tables in a normalized and structured form, which has since become a limitation for RDB with a fast evolution of applications
As a proof of concept, we apply the rules into a case study using three NoSQL databases, namely MongoDB, Cassandra, and Neo4j
We applied the rules on a case study of Service Match Company Database
Summary
Relational database (RDB) stores data into tables in a normalized and structured form, which has since become a limitation for RDB with a fast evolution of applications. RDB cannot deal with un-normalized data and massive size, which makes companies like Google, Facebook, and Amazon choose NoSQL database as the option of their data storage [1]. NoSQL database can support object-oriented paradigm in a better way in comparison to RDB [2]. A correct transformation between schemas will enable data integration, which is common in current applications. It is the aim of this paper to propose these transformation rules. The rules have to be differentiated depending on the
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
