MongoDB - Day 18 (Data Models)

Before reading this article, I highly recommend reading the following previous parts of the series:

• MongoDB - Day 1 (Introduction To MongoDB)
• MongoDB - Day 2 (Install MongoDB in Windows)
• MongoDB - Day 3 (Database Basics)
• MongoDB - Day 4 (Basics of Collection)
• MongoDB - Day 5 (Data Types in MongoDB)
• MongoDB - Day 6 (Insert Method)
• MongoDB - Day 7 (Find Method Part 1)
• MongoDB - Day 8 (Find Method Part 2)
• MongoDB- Day 9 (Update Method)
• MongoDB- Day10 (Remove Method)
• MongoDB - Day 11 (Collection Methods)
• MongoDB - Day12 (Cursor Methods)
• MongoDB - Day13 (Indexing)
• MongoDB - Day 14 (Aggregations)
• MongoDB - Day 15 (Replication)
• MongoDB - Day 16 (Sharding)
• MongoDB - Day 17 (Backup And Restore)

MongoDB contains flexible schema for data storage. Collections don’t enforce document’s structure. MongoDB provides several types of data-modeling. We can choose any data-model for our application that match our application and it’s performance requirement.

Introduction to Data Modeling

In RDBMS we must define the structure(schema) of tables but in MongoDB we don’t require to define the schema of collections. MongoDB contains flexible schema. Collection in MongoDB doesn’t enforce the documents structure. Dynamic schema makes MongoDB development faster. But it is only one side of coin, another side is that dynamic schema required high data balancing of application and performance characteristics of database engine. During designing of data model always consider the application usage of data such as queries, update and processing of data as well as structure of data itself.

Document Structure

Main decision in designing a data model for MongoDB application is that what will be the structure of documents and how application represent the relationship between data. There are two tools in MongoDB that represents the relationship between data.

• Embedded Documents
• References

Embedded Documents

Embedded documents maintain relationship between data by storing the related data in a single document structure. In MongoDB we can embed a documents structure either in the form of a single field or in the form of array within the document. Main advantage of embedded document is that it allows application to retrieve and manipulate related data within a single query.



Embedded data model allow to store related information in same document in the form of embedded documents. Due to embedded documents MongoDB required fewer query to retrieve or manipulate the data. Embedded data model make it possible to update the related data in a single atomic query. Embedded documents are generally used for one to one and one to many relationship.

References

References maintain relationship between data by including links or references from one document to another document. MongoDB or application can use these links or references to retrieve the related data.



Embedded documents contain duplicate data but references doesn’t contain duplicate data. References provide sufficient performance for read operations. References implement many to many relationship.

Data Model Examples and Patterns

MongoDB provides various data modeling patterns and common design considerations. MongoDB provides the following data models.

• Model Relationship Between Documents
• Model Tree Structure

Each data model provides a specific structure. We can select any data model as per the requirement of applications performance.

Model Relationship Between Documents

Model relationship represent relationship between data using either embedded documents or references. The following are the types of model relationship between documents.

• Model One-to-One Relationship with Embedded Documents
• Model One-to-Many Relationship with Embedded Documents
• Model One-to-Many Relationship with Documents References

Model One-to-One Relationship with Embedded Documents: In One-to-One relational model relationship between documents is represented in the form of embedded documents.

Example:

We take an example of state and district relationship. With respect to each district one and only state will exist. In this example we make relationship using referencing and embedding model and describe the advantages of embedding over relational in case of One-to-One relational model.

Firstly consider the relational model using references.



Now we take an example of embedded model:



After observation of both the examples, we can see that embedded model require extra space compared to reference model. But if our application frequently retrieve district with state name then referencing requires some extra query to retrieve data. For One-to-One relational model embedded documents are a better choice because we can retrieve and update complete record in a single query.

Model One-to-Many Relationship with Embedded Documents: In One-to-Many relationship with Embedded Documents relationship between documents is represented in the form of embedded documents.

Example:

We take an example of state and district relationship. A state contains multiple district. In this example we make relationship using referencing and embedding model and describe the advantages of embedding over referencing in case of One-to-Many relational model.

Firstly, consider the relational model using references.



Now we take an example of embedded model:



If our application frequently retrieves the district data with state name information and we are using reference model for relationship, then application requires multiple queries to retrieve or update documents. Instead of reference model we can use embedded model, using embedded model application can retrieve complete data in a single query.

Model One-to-Many Relationship with Documents References: Embedded model is not suitable for One-to-Many relationship every time. In some case we use reference model instead of embedded model.

Example:

We take an example of book and publisher. A publisher published multiple books. For this example we make relationship using referencing and embedding model and describe the advantages of referencing model over embedded in case of One-to-Many relational model.

Firstly, consider the relational model for embedded model.



Now consider the relational model for reference model.

If number of books per publisher is small and bounded, then we can store books references into publisher’s document like the following:



If number of books per publisher is larger and unbounded then it will generate a mutable array. So in such type of case we store the reference of publisher into books documents.



If a document contains multiple embedded documents and size of each embedded documents is larger than each document, it will occupy larger space and increase the system cost. So in such type of scenario we should use reference instead of embedded relational model.

Model Tree Structure

In model tree structure, MongoDB store documents in a tree node and allows various ways to use tree data structure to implement large hierarchical or nested data relationship. MongoDB provides the following methods to implement the model tree structure.

• Parent Reference
• Child Reference
• Array of Ancestor
• Materialized Paths
• Nested Sets

We use above model tree structure models for the following tree structure.



Now we will observe the above maintained five methods for this tree. We use “Map_Information” collection for above tree.

Parent Reference

In parent reference pattern approach each node of tree will store in document and each node contain the reference of parent node. The Parent links pattern provides a simple solution to tree storage but requires multiple queries to retrieve sub trees.

We store each node of above tree as a document of “Map_Information” collection using parent reference method. When we create a collection for above tree, it will be like the following: