VAIBZDE 》Vaibhav Dewangan's Blog
#Day41 - Mastering Data Modeling with MongoDB: A Comprehensive Guide

#Day41 - Mastering Data Modeling with MongoDB: A Comprehensive Guide

Data Modeling in MongoDB: Understanding JSON Schema, Relationships, Validation & Best Practices for Efficient Data Management

Vaibhav Dewangan's photo
Vaibhav Dewangan
·

12 min read

Table of contents

Welcome to the 41st day of your "Code, Blog, Repeat: A 50-Day Quest for Back-End Mastery" blog series! Today, we will delve into the world of data modeling with MongoDB.

Data modeling is an essential aspect of building software. It involves defining the structure and organization of data, which is critical in ensuring the efficiency and scalability of an application. Data modeling helps in establishing a clear understanding of the relationships between different data elements, making it easier to develop and maintain an application.

The purpose of data modeling in MongoDB is to ensure that the data in a MongoDB database is organized in an efficient and scalable manner. MongoDB, being a NoSQL database, differs from traditional SQL databases in its approach to data modeling. In MongoDB, there is no need to define a fixed schema before inserting data. This allows for greater flexibility in organizing data and making changes to the schema as needed.

In this blog, we will explore the intricacies of data modeling in MongoDB, including the structure of documents in MongoDB collections, embedded data, references, atomization of written operations, schema, embedding vs referencing, types of relationships, and schema validation. Let's dive in!

Data Modeling:

Data modeling is a crucial aspect of building software applications, as it helps to determine the structure and organization of data within a system. MongoDB, a popular NoSQL database, offers a unique approach to data modeling compared to traditional SQL databases.

One of the key differences between MongoDB and SQL databases is that MongoDB does not require a defined schema before inserting data. This allows for greater flexibility in the structure of data, as the schema can evolve and change over time as the needs of the application change.

In MongoDB, data is stored in collections of documents. Each document can contain different data types and can have a different structure from other documents within the same collection. This allows for a more dynamic and flexible approach to data modeling compared to traditional SQL databases where data must conform to a predefined schema.

When creating data models for MongoDB applications, it is important to consider the structure of documents and the relationships between data. This includes decisions such as whether to use embedded data or references to connect data, and the type of relationships that exist between data (e.g. one-to-one, one-to-many, many-to-many). These decisions can have a significant impact on the performance and scalability of the application.

Embedded Data

Embedded data is a method of storing relationships between data by including relevant information within the same document. In MongoDB, this is achieved by nesting fields within a document. For example, consider a blog post document which includes information about the author and comments. The author information could be embedded within the same document as the post, rather than being stored as a separate document in a different collection. This allows for retrieval of the post and related information in a single database operation.

The benefits of using embedded data in MongoDB include:

  • Improved read performance as all relevant data is stored within a single document

  • Efficient storage utilization as related data does not need to be stored in separate collections

  • Simplified data retrieval as all relevant data is available in a single document

  • Better data consistency as related data is stored together, reducing the need for multiple database operations.

Here is an example of embedded data in MongoDB:

{
    _id: ObjectId("5f6789aad734a4567b1e0d1f"),
    name: "John Doe",
    address: {
        street: "123 Main St",
        city: "Anytown",
        state: "CA",
        zip: "12345"
    },
    orders: [
        {
            order_id: ObjectId("5f6789aad734a4567b1e0d20"),
            product: "iPhone",
            quantity: 2,
            date: ISODate("2022-07-01T00:00:00Z")
        },
        {
            order_id: ObjectId("5f6789aad734a4567b1e0d21"),
            product: "Macbook Pro",
            quantity: 1,
            date: ISODate("2022-08-15T00:00:00Z")
        }
    ]
}

In the above example, the address field contains embedded data of the user's address information, while the orders field contains an array of embedded documents of the user's order history. Each order document has its own order_id, product, quantity, and date fields.

Overall, embedded data is a useful tool for capturing relationships between data in MongoDB, allowing for more efficient data storage and retrieval.

References

In MongoDB, references allow for connections between data to be stored by adding links or references from one document to another. This can be useful when you want to represent relationships between different data entities.

Here's an example of how references might look in code:

{
    _id: ObjectId("5f0d54a73f33be4083e54321"),
    name: "John",
    address: ObjectId("5f0d54a73f33be4083e54322")
}

{
    _id: ObjectId("5f0d54a73f33be4083e54322"),
    street: "123 Main St.",
    city: "New York",
    state: "NY"
}

In this example, the first document represents a user, and the second document represents the user's address. The "address" field in the user document is a reference to the address document, as it stores the ObjectId of the address document. This allows you to easily access and update the relevant data in a single database operation.

The benefits of using references in MongoDB include the ability to easily access relevant data, and the ability to represent complex relationships between data entities in a clear and organized way.

Atomization of Written Operations

Single Document Atomicity:

In MongoDB, write operations are atomic at the document level. This means that even if the operation modifies many embedded documents within a single document, the operation will still be atomic at the document level. The denormalized data model, with its embedded data, combines relevant data into a single document, making atomic operations easier to perform. For example, a single document atomicity operation can be performed as follows:

$session.startTransaction();
db.users.update({_id:3}, {$set: {age: 50}});
$session.commitTransaction();

Multi-Document Transactions:

When modifying multiple documents in a single written operation, such as using db.collection.updateMany, the update of each document is atomic, but the whole operation is not atomic. Other operations may be interleaved during multi-document writing operations, either by a single writing operation or by multiple writing operations. To ensure the atomic power of reading and writing multiple documents, MongoDB supports multi-document transactions. For example, a multi-document transaction can be performed as follows:

$session.startTransaction();
db.users.updateMany({{_id: 3}}, {{$set: {age: 50}}});
db.users.update({_id:4}, {$set: {age: 40}});
$session.commitTransaction();

Schema

JSON (JavaScript Object Notation) is a lightweight data-interchange format that is easy to read and write for humans and machines alike. In MongoDB, a schema is used to define the structure of the data stored in a collection.

A JSON schema is a way to describe the structure of a JSON document, including the types of data it contains and their relationships to each other. In MongoDB, a document can have nested objects and arrays, so the schema design is more flexible compared to traditional relational database management systems.

Difference between MongoDB Schema and Relational Schema

In MongoDB, there is no formal process or algorithm for designing a schema like in a relational database management system. The focus is on designing a schema that fits the needs of the application. This means that two different applications with the same data can have different schemas, depending on how the data is used.

Key Considerations for MongoDB Schema Design

When designing a MongoDB schema, it is important to keep the following in mind:

  1. Store data: The schema should store the data in a way that makes sense for the application and supports the required operations.

  2. Provide good query performance: The schema should be designed to support the queries that the application needs to perform, such as filtering and sorting.

  3. Adequate hardware: The schema should take into account the amount of hardware required to support the size and complexity of the data.

Example:

Consider a database that stores information about people and their cars. In this case, a possible MongoDB schema could be:

{
  "first_name": "Paul",
  "last_name": "Smith",
  "phone_number": "447557505611",
  "address": {
    "city": "London",
    "location": {
      "type": "Point",
      "coordinates": [45.123, 47.232]
    }
  },
  "profession": "Trader",
  "cars": [
    {
      "make": "Bentley",
      "year": 1973
    },
    {
      "make": "Rolls Royce",
      "year": 1965
    }
  ]
}

In this example, the first_name, last_name, phone_number, and address fields describe the person, while the profession and cars fields describe additional information. The address field contains a nested object with the city and location fields, and the location field contains an object with information about the coordinates of the person's location. The cars field is an array that contains information about the person's cars.

Embedding vs Referencing:

When it comes to designing the data model for a MongoDB database, there are two main approaches for storing related data: embedding and referencing. Each approach has its own pros and cons, so it's important to understand both and choose the one that best suits your needs.

Embedding Data Embedding is a method of storing related data within a single document. The advantage of this approach is that it can result in smaller documents, which can improve query performance as less data needs to be retrieved and processed. Additionally, all relevant data is stored within a single document, which can simplify queries and reduce the need for multiple queries to retrieve data from multiple documents.

However, there are also some drawbacks to this approach. For example, as the document size increases, it can become difficult to manage the data and make updates. Additionally, it can be difficult to enforce consistency across multiple documents as it can be difficult to identify which documents need to be updated when changes occur.

Referencing Data Referencing is a method of storing related data in separate documents and linking them through a reference field. The advantage of this approach is that it can help keep documents smaller, as only the relevant information is stored in each document. This can also help reduce the complexity of updating data as changes only need to be made to the referenced document, not every document that contains the related data.

However, there are also some drawbacks to this approach. Queries that require data from multiple documents can become more complex, as they may need to join the referenced data from multiple documents. Additionally, not every query requires the same level of detail, so it may be necessary to retrieve additional data that isn't relevant to the query, which can negatively impact query performance.

The choice between embedding and referencing data in MongoDB depends on the specific requirements of your application. It's important to consider both the advantages and disadvantages of each approach and choose the one that best fits your needs.

Types of Relationships:

In MongoDB, there are several types of relationships that can exist between data within the same or different collections. These relationships include:

One-to-One

In a one-to-one relationship, a single document in one collection is associated with only one document in another collection.

Example: Consider a collection of "users" where each document represents a unique user, and a collection of "user_profiles" where each document represents a profile for a unique user. Here, each user document in the "users" collection is associated with only one user profile document in the "user_profiles" collection.

// users collection
{
  _id: 1,
  name: "John Doe",
  email: "johndoe@example.com"
}

// user_profiles collection
{
  _id: 1,
  user_id: 1,
  occupation: "Software Engineer",
  address: "1234 Main St"
}

One-to-Many

In a one-to-many relationship, a single document in one collection is associated with multiple documents in another collection.

Example: Consider a collection of "users" where each document represents a unique user, and a collection of "user_posts" where each document represents a post made by a user. Here, each user document in the "users" collection can be associated with multiple user post documents in the "user_posts" collection.

// users collection
{
  _id: 1,
  name: "John Doe",
  email: "johndoe@example.com"
}

// user_posts collection
{
  _id: 1,
  user_id: 1,
  title: "My First Post",
  content: "This is my first post"
}
{
  _id: 2,
  user_id: 1,
  title: "My Second Post",
  content: "This is my second post"
}

Many-to-Many

In a many-to-many relationship, multiple documents in one collection are associated with multiple documents in another collection.

Example: Consider a collection of "users" where each document represents a unique user and a collection of "groups" where each document represents a group. Here, multiple user documents in the "users" collection can be associated with multiple group documents in the "groups" collection.

// users collection
{
  _id: 1,
  name: "John Doe",
  email: "johndoe@example.com"
}
{
  _id: 2,
  name: "Jane Doe",
  email: "janedoe@example.com"
}

// groups collection
{
  _id: 1,
  name: "Group A",
  members: [1, 2]
}
{
  _id: 2,
  name: "Group B",
  members: [2]
}

To model these relationships in MongoDB, different techniques such as embedding data, referencing data, or using a combination of both can be used. The choice of technique depends on the specific requirements and use-case for the data being stored.

Schema Validation:

Schema validation in MongoDB refers to the process of checking if the documents stored in a collection conform to a specified validation schema. The validation schema defines the structure and type of fields in the document, and any constraints that must be met, such as required fields and maximum field length.

Using Schema Validation to Enforce Constraints

To enforce constraints on documents in a MongoDB collection, you can specify a validation schema. The validation schema is defined using the validator option in the createCollection() method or the collMod command. You can specify the validation schema using the JSON Schema standard or using MongoDB's validation expressions.

For example, the following code creates a collection with a validation schema that requires a name field with a maximum length of 50 characters:

db.createCollection("users", {
  validator: { $jsonSchema: {
    bsonType: "object",
    required: ["name"],
    properties: {
      name: {
        bsonType: "string",
        maxLength: 50
      }
    }
  }}
})

Using the $jsonSchema Operator to Specify a Validation Schema

MongoDB also provides a special operator, $jsonSchema, to specify a validation schema. The $jsonSchema operator is used in the validator option in the createCollection() method or the collMod command. The $jsonSchema operator allows you to specify a JSON Schema validation schema, which provides more expressive and flexible validation rules than MongoDB's validation expressions.

For example, the following code creates a collection with a validation schema that requires a name field with a maximum length of 50 characters, and a birthday field with the format of a date:

db.createCollection("users", {
  validator: { $jsonSchema: {
    bsonType: "object",
    required: ["name", "birthday"],
    properties: {
      name: {
        bsonType: "string",
        maxLength: 50
      },
      birthday: {
        bsonType: "date",
        format: "date"
      }
    }
  }}
})

Schema validation is an important tool for ensuring the consistency and integrity of data in a MongoDB collection. The use of the $jsonSchema operator provides a more expressive and flexible way to specify a validation schema, compared to MongoDB's validation expressions.

Conclusion:

In this post, we discussed the basics of data modeling in MongoDB. We talked about the differences between JSON schema and relational schema design, and the considerations to take into account when designing a MongoDB schema. We also explored the different types of relationships in MongoDB and how to model them, and the importance of schema validation in enforcing constraints on documents.

Key Takeaways:

  • JSON schema and MongoDB schema design differ from relational schema design

  • When designing a MongoDB schema, consider factors such as data storage, query performance, and hardware

  • MongoDB supports different types of relationships including one-to-one, one-to-many, and many-to-many

  • Schema validation can be used to enforce constraints on documents in MongoDB

  • The $jsonSchema operator can be used to specify a validation schema

Data modeling in MongoDB is a crucial step in ensuring that your application runs smoothly and efficiently. It is important to understand the differences between JSON schema and relational schema design and the key considerations to keep in mind when designing a MongoDB schema. Additionally, modeling relationships between documents and enforcing constraints through schema validation can greatly improve the functionality and performance of your application.

We hope this post has been helpful in your journey to learn about data modeling in MongoDB. If you liked this post, please feel free to share it with others. And, as always, we welcome your comments and questions. Happy coding!

MongoDBdata-modeling