|
| 1 | +--- |
| 2 | +id: mongodb-data-modeling |
| 3 | +title: MongoDB - Data Modelling |
| 4 | +sidebar_label: Data Modelling |
| 5 | +sidebar_position: 5 |
| 6 | +tags: [mongodb, data modeling, schema design] |
| 7 | +description: Learn about data modeling in MongoDB, including embedded and normalized data models, with examples and considerations for schema design. |
| 8 | +--- |
| 9 | + |
| 10 | +# MongoDB - Data Modelling |
| 11 | + |
| 12 | +Data in MongoDB has a flexible schema. Documents in the same collection do not need to have the same set of fields or structure. Common fields in a collection’s documents may hold different types of data. |
| 13 | + |
| 14 | +## Data Model Design |
| 15 | + |
| 16 | +MongoDB provides two types of data models: Embedded data model and Normalized data model. Based on the requirement, you can use either of the models while preparing your document. |
| 17 | + |
| 18 | +### Embedded Data Model |
| 19 | + |
| 20 | +In this model, you can have (embed) all the related data in a single document. It is also known as the de-normalized data model. |
| 21 | + |
| 22 | +For example, assume we are getting the details of employees in three different documents, namely, Personal_details, Contact, and Address. You can embed all three documents into a single one as shown below: |
| 23 | + |
| 24 | +```json |
| 25 | +{ |
| 26 | + "_id": "ObjectId", |
| 27 | + "Emp_ID": "10025AE336", |
| 28 | + "Personal_details": { |
| 29 | + "First_Name": "Radhika", |
| 30 | + "Last_Name": "Sharma", |
| 31 | + "Date_Of_Birth": "1995-09-26" |
| 32 | + }, |
| 33 | + "Contact": { |
| 34 | + |
| 35 | + "phone": "9848022338" |
| 36 | + }, |
| 37 | + "Address": { |
| 38 | + "city": "Hyderabad", |
| 39 | + "Area": "Madapur", |
| 40 | + "State": "Telangana" |
| 41 | + } |
| 42 | +} |
| 43 | +``` |
| 44 | + |
| 45 | +### Normalized Data Model |
| 46 | + |
| 47 | +In this model, you can refer to the sub-documents in the original document using references. For example, you can rewrite the above document in the normalized model as: |
| 48 | + |
| 49 | +#### Employee |
| 50 | + |
| 51 | +```json |
| 52 | +{ |
| 53 | + "_id": "<ObjectId101>", |
| 54 | + "Emp_ID": "10025AE336" |
| 55 | +} |
| 56 | +``` |
| 57 | + |
| 58 | +#### Personal_details |
| 59 | + |
| 60 | +```json |
| 61 | +{ |
| 62 | + "_id": "<ObjectId102>", |
| 63 | + "empDocID": "<ObjectId101>", |
| 64 | + "First_Name": "Radhika", |
| 65 | + "Last_Name": "Sharma", |
| 66 | + "Date_Of_Birth": "1995-09-26" |
| 67 | +} |
| 68 | +``` |
| 69 | + |
| 70 | +#### Contact |
| 71 | + |
| 72 | +```json |
| 73 | +{ |
| 74 | + "_id": "<ObjectId103>", |
| 75 | + "empDocID": "<ObjectId101>", |
| 76 | + |
| 77 | + "phone": "9848022338" |
| 78 | +} |
| 79 | +``` |
| 80 | + |
| 81 | +#### Address |
| 82 | + |
| 83 | +```json |
| 84 | +{ |
| 85 | + "_id": "<ObjectId104>", |
| 86 | + "empDocID": "<ObjectId101>", |
| 87 | + "city": "Hyderabad", |
| 88 | + "Area": "Madapur", |
| 89 | + "State": "Telangana" |
| 90 | +} |
| 91 | +``` |
| 92 | + |
| 93 | +## Considerations while Designing Schema in MongoDB |
| 94 | + |
| 95 | +1. **Design your schema according to user requirements.** |
| 96 | +2. **Combine objects into one document if you will use them together. Otherwise, separate them (but make sure there is no need for joins).** |
| 97 | +3. **Duplicate the data (but limited) because disk space is cheap compared to compute time.** |
| 98 | +4. **Do joins while writing, not on reading.** |
| 99 | +5. **Optimize your schema for the most frequent use cases.** |
| 100 | +6. **Do complex aggregation in the schema.** |
| 101 | + |
| 102 | +## Example |
| 103 | + |
| 104 | +Suppose a client needs a database design for their blog/website. Let's see the differences between RDBMS and MongoDB schema design. The website has the following requirements: |
| 105 | + |
| 106 | +- Every post has a unique title, description, and URL. |
| 107 | +- Every post can have one or more tags. |
| 108 | +- Every post has the name of its publisher and the total number of likes. |
| 109 | +- Every post has comments given by users along with their name, message, date-time, and likes. |
| 110 | +- On each post, there can be zero or more comments. |
| 111 | + |
| 112 | +### RDBMS Schema Design |
| 113 | + |
| 114 | +In RDBMS schema design, for the above requirements, you will have at least three tables. |
| 115 | + |
| 116 | +### MongoDB Schema Design |
| 117 | + |
| 118 | +In MongoDB schema design, you will have one collection called `post` with the following structure: |
| 119 | + |
| 120 | +```json |
| 121 | +{ |
| 122 | + "_id": "POST_ID", |
| 123 | + "title": "TITLE_OF_POST", |
| 124 | + "description": "POST_DESCRIPTION", |
| 125 | + "by": "POST_BY", |
| 126 | + "url": "URL_OF_POST", |
| 127 | + "tags": ["TAG1", "TAG2", "TAG3"], |
| 128 | + "likes": "TOTAL_LIKES", |
| 129 | + "comments": [ |
| 130 | + { |
| 131 | + "user": "COMMENT_BY", |
| 132 | + "message": "TEXT", |
| 133 | + "dateCreated": "DATE_TIME", |
| 134 | + "like": "LIKES" |
| 135 | + }, |
| 136 | + { |
| 137 | + "user": "COMMENT_BY", |
| 138 | + "message": "TEXT", |
| 139 | + "dateCreated": "DATE_TIME", |
| 140 | + "like": "LIKES" |
| 141 | + } |
| 142 | + ] |
| 143 | +} |
| 144 | +``` |
| 145 | + |
| 146 | +So, while showing the data, in RDBMS you need to join three tables, but in MongoDB, data will be shown from one collection only. |
| 147 | + |
| 148 | +### Data Modeling Diagram |
| 149 | + |
| 150 | +```mermaid |
| 151 | +graph TD |
| 152 | + A[Data Model Design] --> B[Embedded Data Model] |
| 153 | + A --> C[Normalized Data Model] |
| 154 | + B --> D[Single Document] |
| 155 | + C --> E[Separate Documents] |
| 156 | + E --> F[References] |
| 157 | +``` |
| 158 | + |
| 159 | +### Data Modeling Summary |
| 160 | + |
| 161 | +| Feature | Embedded Data Model | Normalized Data Model | |
| 162 | +|---------------------------------|-----------------------------|-----------------------------| |
| 163 | +| **Data Storage** | Single document | Separate documents | |
| 164 | +| **Schema Complexity** | Simple | Complex | |
| 165 | +| **Performance** | Fast reads | Fast writes | |
| 166 | +| **Use Case** | High read/write frequency | Large data with references | |
| 167 | + |
| 168 | +MongoDB provides a flexible and efficient way to model your data based on your application needs. Choosing the right data model depends on the use case and access patterns. |
0 commit comments