# Modernizing RDBMS Schemas With a MongoDB Document Model

Welcome to the exciting journey of transitioning from the traditional realm of relational databases to the dynamic world of MongoDB! This is the first entry in a series of tutorials helping you migrate from relational databases to MongoDB. Buckle up as we embark on a thrilling adventure filled with schema design, data modeling, and the wonders of the document model. Say goodbye to the rigid confines of tables and rows, and hello to the boundless possibilities of collections and documents. In this tutorial, we'll unravel the mysteries of MongoDB's schema design, exploring how to harness its flexibility to optimize your data storage like never before, using the Relational Migrator tool!

The migration from a relational database to MongoDB involves several stages. Once you've determined your database and application requirements, the initial step is schema design. This process involves multiple steps, all centered around how you intend to access your data. In MongoDB, data accessed together should be stored together. Let's delve into the schema design process.

## Schema design
The most fundamental difference between the world of relational databases and MongoDB is how your data is modeled. There are some terminology changes to keep in mind when moving from relational databases to MongoDB:

| RDBMS              | MongoDB                                          |
|--------------------|--------------------------------------------------|
| Database           | Database                                         |
| Table              | Collection                                       |
| Row                | Document                                         |
| Column             | Field                                            |
| Index              | Index                                            |
| JOIN               | Embedded document, document references, or $lookup to combine data from different collections |

Transitioning from a relational database to MongoDB offers several advantages due to the flexibility of JSON (JavaScript Object Notation) documents. MongoDB's BSON (Binary JSON) encoding extends JSON's capabilities by including additional data types like int, decimal, dates, and more, making it more efficient for representing complex data structures.

Documents in MongoDB, with features such as sub-documents (embedded documents) and arrays, align well with the structure of application-level objects. This alignment simplifies data mapping for developers, as opposed to the complexities of mapping object representations to tabular structures in relational databases, which can slow down development, especially when using Object Relational Mappers (ORMs).

When designing schemas for MongoDB, it's crucial to consider the application's requirements and leverage the document model's flexibility. While mirroring a relational database's flat schema in MongoDB might seem straightforward, it undermines the benefits of MongoDB's embedded data structures. For instance, MongoDB allows collapsing (embedding) data belonging to a parent-child relationship in relational databases into a single document, enhancing efficiency and performance. It's time to introduce a powerful tool that will streamline your transition from relational databases to MongoDB: the Relational Migrator. 

### Relational Migrator 
The transition from a relational database to MongoDB is made significantly smoother with the help of the Relational Migrator. The first step in this process is a comprehensive analysis of your existing relational schema. The Relational Migrator examines your database, identifying tables, relationships, keys, and other elements that define the structure and integrity of your data. You can connect to a live database or load a .SQL file containing Data Defining Language (DDL) statements. For this tutorial, I’m just going to use the sample schema available when you click **create new project**.

The first screen you’ll see is a diagram of your relational database relationships. This lays the groundwork by providing a clear picture of your current data model, which is instrumental in devising an effective migration strategy. By understanding the intricacies of your relational schema, the Relational Migrator can make informed suggestions on how to best transition this structure into MongoDB's document model.

.

In MongoDB, data that is accessed together should be stored together. This allows the avoidance of resource-intensive `$lookup` operations where not necessary. Evaluate whether to embed or reference data based on how it's accessed and updated. Remember, embedding can significantly speed up read operations but might complicate updates if the embedded data is voluminous or frequently changed. Use the Relational Migrator's suggestions as a starting point but remain flexible. Not every recommendation will be applicable, especially as you project data growth and access patterns into the future.

You may be stuck, staring at the daunting representation of your tables, wondering how to reduce this to a manageable number of collections that best meets your needs. Select any collection to see a list of suggestions for how to represent your data using embedded arrays or documents. Relational Migrator will show all the relationships in your database and how you can represent them in MongoDB, but they might not all be appropriate for application. In my example, I have selected the products collection.

. Use the migrator’s suggestions to iteratively refine your new schema, and understand the suggestions are useful, but not all will make sense for you.

 contains all the information you need.

### Data modeling templates
It can be difficult to understand how best to store your data in your application, especially if you’re new to MongoDB. MongoDB Atlas offers a variety of data modeling templates that are designed to demonstrate best practices for various use cases. To find them, go to your project overview and you'll see the "Data Toolkit." Under this header, click the "Data Modeling Templates." These templates are there to serve as a good starting point to demonstrate best practices depending on how you plan on interacting with your data. 

 — or pop over to our community forums to see what others are doing with MongoDB.

  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt7e10c8890fd54c23/65e8774877faff0e5a5a5cb8/image8.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt06b47b571be972b5/65e877485fd476466274f9ba/image5.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt6119b9e0d49180e0/65e877478b9c628cfa46feed/image1.png
  [4]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt5542e55fba7a3659/65e8774863ec424da25d87e0/image4.png
  [5]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt4e6f30cb08ace8c0/65e877478b9c62d66546fee9/image2.png
  [6]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt03ad163bd859e14c/65e877480395e457c2284cd8/image3.png
  [7]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt1343d17dd36fd642/65e8774803e4602da8dc3870/image7.png
  [8]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt68bfa90356269858/65e87747105b937781a86cca/image6.png