MongoDB Data Modeling with Document Structure

We have seen the environment setup for MongoDB in our last MongoDB Tutorial. Here, in this article, we will learn the MongoDB Data Modeling. In addition, we will also discuss the MongoDB Document Structure and some considerations of MongoDB data modeling.

So, let’s start with MongoDB Data Modeling.

What is MongoDB Data Modeling?

• We know that MongoDB is a document-oriented database or NoSQL database.
• It is a schema-less database or we can say, it has a flexible schema.
• Unlike the structured database, where we need to determine table’s schema in advance, MongoDB is very flexible in this area.
• MongoDB deals in collections, documents, and fields.
• We can have documents containing different sets of fields or structures in the same collection.
• Also, common fields in a collection can contain different types of data. This helps in easy mapping.

The key challenge in MongoDB data modeling is balancing the requirements of the application. Also, we need to assure the performance aspect effectively while modeling. Let’s point out some requirements while MongoDB Data Modeling taking place.

1. Design schema according to the need.
2. Objects which are queried together should be contained in one document.
3. Consider the frequent use cases.
4. Do complex aggregation in the schema.

MongoDB Document Structure

There can be two ways to establish relationships between the data in MongoDB:

• Referenced Documents
• Embedded Documents

MongoDB Document Structure

a. Referenced Documents

Reference is one of the tools that store the relationship between data by including links from one data to another. In such data, a reference to the data of one collection will be used to collect the data between the collections.

We can say, applications resolve these references to access the related data. These are normalized data models.

Reference relationships should be used to establish one to many or many to many relationships between documents. Also, when the referenced entities are frequently updated or grow indefinitely.

MongoDB Document Structure – Reference Document

b. Embedded Documents

These can be considered as de-normalized data models. As the name suggests, embedded documents create relationships between data by storing related data in a single document structure. These data models allow applications to retrieve and manipulate related data in a single database operation.

Embedded documents should be considered when the embedded entity is an integral part of the document and not updated frequently. It should be used when there is a contained relation between entities and they should not grow indefinitely.

MongoDB Document Structure – Embedded Documents

Considerations for MongoDB Data Modeling

Some special consideration should give while designing a data model of MongoDB. This is for high per performance scalable and efficient database. The following aspects should consider for MongoDB Data Modeling.

a. Data Usage

While designing a data model, one must consider that how applications will access the database. Also, what will be the pattern of data, such as reading, writing, updating, and deletion of data. Some applications are read centric and some are write-centric.

There are possibilities that some data use frequently whereas some data is completely static. We should consider these patterns while designing the schema.

b. Document growth

Some updates increase the size of the documents. During initialization, MongoDB assigns a fixed document size. While using embedded documents, we must analyze if the subobject can grow further out of bounds.

Otherwise, there may occur performance degradation when the size of the document crosses its limit. MongoDB relocates the document on disk if the document size exceeds the allocated space for that document.

c.  Atomicity

Atomicity in contrast to the database means operations must fail or succeed as a single unit. If a parent transaction has many sub-operations, it will fail even if a single operation fails. Operations in MongoDB happen at the document level.

No single write operation can affect more than one collection. Even if it tries to affect multiple collections, these will treat as separate operations. A single write operation can insert or update the data for an entity. Hence, this facilitates atomic write operations.

However, schemas that provide atomicity in write operations may limit the applications to use the data. It may also limit the ways to modify applications. This consideration describes the challenge that comes in a way of data modeling for flexibility.

This was all about MongoDB Data Modeling Tutorial. Hope you like our explanation.

Conclusion

Hence, now we are familiar with the MongoDB Data Modeling. We have seen how can we model the data in MongoDB without degrading its performance. Moreover, we saw MongoDB Document Structure: Reference and Embedded Documents.

At last, we discuss some important considerations for MongoDB Data Modeling. Furthermore, if you have any query, feel free to ask in a comment section.