Data modeling is the process of developing a visual representation of either an entire software application or components of it to communicate the connections between data points and structure. It involves meticulously reviewing its application and database requirements and as the connection between the two concerning core data operations – read, write, and update.
A stable data model is created by assessing the application’s usage pattern and aligning the database schema with it. Therefore, schema design shapes your data model. When it comes to a relational database, you can’t populate your tables without creating the table schema.
Key Terms to Know
Before you move ahead, here are some basic definitions you must know:
- Collection – A collection is the set of documents in MongoDB. It is the equivalent of a table in a RDBMS.
- Document – A document is a structure comprised of file and value pairs. It is the equivalent of a row in RDBMS.
- Database Schema – Schema design is a logical and visual architecture of a database designed for a database management system (DBMS).
How Is Data Modeling Different In MongoDB?
Thanks to the flexibility of NoSQL, you don’t have to create a schema before data insertion. That’s because MongoDB supports a dynamic form of database schema. This eliminates the need to design your schema in advance. Instead, you can now store your data and make adjustments according to your collection.
You can store different data types in a collection’s given field and can even add new fields, update field values, and delete existing fields. You will find the true benefit of this flexibility when you map documents to an object or entity.
Generally, a collection and its document follow a similar structure. You can also “enforce” validation rules for your collection’s documents by using schema validation.
When creating a data model, look into how your application will interact with the database. For instance, if it is going to process documents that were inserted recently, then it is a good idea to use capped collections – collections with a fixed size that support high-throughput operations.
Similarly, if your application is going to work with read operations most of the time, you can set indexes to support common queries and enhance performance.
Traditionally, one of the considerations in creating a data model is how to store related data. Relational databases use tables to store data, where primary and foreign keys are used to set data relationships.
Similarly, joins are used to access and run operations over multiple tables. As someone who has switched to MongoDB from a relational DBMS, such as SQL Server, you are not going to find joins in MongoDB. That is because MongoDB stores collection data by either referencing the data or embedding the data into a collection.
Therefore, if your data model takes ten tables in a relational database, it’s possible that MongoDB lets you consolidate it in a single collection.
Types of Data Models
Now that you know how data modeling works in MongoDB, let’s go through the types of data models supported by MongoDB. Usually, it depends on your document’s structure and your application’s data relationships.
Embedded Data Models
You can embed data in a single document or structure in MongoDB. Also referred to as de-normalized data models, it leverages the full potential of MongoDB’s rich documents. For example, consider the following example: we have a collection, students, containing a document Matt. In this document, we have embedded two documents, contact details and grade.
{
"_id": "4aad66a4c13bb24f12gh199e",
name: “Matt”,
contact details: {
phone:”555-555-1234”
email address: “abc123@gmail.com”
},
grade: {
subject: “CS101”
score: “B”
}}Embedding stores relevant details in the same document or database record. This way, you can minimize queries and updates required to perform common DB operations.
When should you use embedded data models? They are useful to improve the performance of read operations. In addition, they are effective for processing data retrieval of a single record. With this model, you can use a single write operation to update related data.
However, there is something that you need to keep in mind: embedding increases the document size after its creation. In some cases, this can affect the write performance and there is also the possibility of data fragmentation due to the expanding document size.
Lastly, you can interact with embedded documents by using the dot notation and traverse them with ease. Here is the syntax:
field.nestedField:valueFor above example, you can access your nested documents by writing the following query:
db.students.find({contact details: { phone:”555-555-1234” ,email address: “abc123@gmail.com”}}).pretty()Normalized Data Models (References)
Normalized data models are used to build one-to-many and many-to-many relationship models. While working with embedded document models, there will be times when you have to repeat data. This is where references come in handy – they tackle the redundancy. Here’s how we can use references for the above example.
We have split our single document into three documents and since contact details and grade have the id from Matt document, you can call them when needed.
student
{
_id:
username: “Matt”
}
contact details
{
_id:
user_id:
email:“abc123@gmail.com”
phone:”555-555-1234”
}
grade
id:
user_id: ,
subject: “CS101”,
score: “B”
}As you can see, normalized data models split data into multiple collections by using references between the newer collections. You can update a single document, which will update other collections. This is an efficient way of updating data and is mostly used when your data goes through frequent changes.
Here are the times when a normalized data model is the wiser choice:
- You have to model large data sets that follow a certain hierarchy.
- You have to represent multiple many-to-many relationships.
- Embedding would cause data duplication without benefiting your read performance to a sufficient extent.
Now You Can Model Data In MongoDB with Ease
By now, you know how data modeling in MongoDB is different from relational DBMs, especially when it comes to schema. You have also learnt about the types of data models in MongoDB – de-normalized and normalized – and learn when to use them.
And this is just the beginning; there’s much more to learn about how MongoDB can organize your data.