What is Data Modeling?
• Variable Field Data Types: A field's data type
can differ between documents within a
Data modeling is the process of defining the structure,
collection.
storage, and retrieval of data in a database. It involves
• Similar Structure: Generally, documents in a
organizing data to fit the requirements of an application
collection share a similar structure. To ensure
and ensuring efficient data management.
consistency, schema validation rules can be
created.
Use Cases for Flexible Schema
Employee Tracking:
Scenario: Your company needs to track which
department each employee works in.
Solution: Embed department information inside the
Mapping between relational terms and MongoDB terms employee collection. This setup allows relevant
information to be returned in a single query.
E-commerce Reviews:
Scenario: Your e-commerce application displays the five
most recent reviews when showing a product.
Solution: Store recent reviews in the same collection as
the product data. Older reviews, which are accessed less
frequently, can be stored in a separate collection.
Product Catalog for a Clothing Store:
Data Modeling in MongoDB Scenario: Your clothing store needs a single-page
Data modeling refers to organizing data within a application for a product catalog. Different products
database and establishing links between related have different attributes and thus use different
entities. MongoDB uses a flexible schema model, which document fields.
entails: Solution: Store all products in the same collection
• No Uniform Field Set: Documents within a despite the varied attributes
single collection are not required to have the
same set of fields.
Identifying Database Workloads Prior to Data Data Relationships:
Modeling and Schema Design Identify relationships between data entities.
Understanding database workloads is essential before Decide on using embedded documents or references.
starting data modeling and schema design. This ensures
Scalability Needs:
the data model aligns with application needs, optimizing
performance and efficiency. Determine the need for horizontal scaling.
Application Purpose: Identify potential for sharding and partitioning.
~ Define the application's primary function (e.g., Performance Requirements:
e-commerce, social media).
Set expectations for query response times.
~ Identify the types of data handled (e.g., user
Identify performance-critical paths in the application.
profiles, transactions).
Data Consistency:
CRUD Operations:
Choose the appropriate consistency model (e.g.,
~ Create: Identify data frequently
eventual or strong consistency).
inserted/updated.
~ Read: Determine data frequently queried. Determine if transactional support is necessary.
~ Update: Note data often modified. Security and Compliance:
~ Delete: Understand data frequently removed.
Identify required security measures (e.g., encryption,
Query Patterns: access control).
~ Identify common queries and their frequency. Ensure compliance with relevant regulations (e.g.,
~ Determine which fields need indexing. GDPR, HIPAA).
~ Analyze if queries require joins, aggregations, or
Practical Steps
text searches.
Workload Analysis:
Data Volume and Velocity:
Conduct a thorough analysis of application
~ Estimate initial and future data volumes.
requirements and workloads.
~ Assess the speed of incoming data (e.g.,
Document findings to guide the data modeling process.
transactions per second).
Stakeholder Interviews:
Read/Write Ratios:
Gather insights from developers, business analysts, and
Determine the proportion of read to write operations.
end-users on data usage patterns and performance
Identify if the application is read-heavy, write-heavy, or
expectations.
balanced.
Prototype and Test: To link related data, you can either:
Develop and test a prototype schema with simulated • Embed related data within a single document.
data to evaluate performance and scalability. • Store related data in a separate collection and
access it with a reference.
Iterate and Refine:
Embedded Data
Refine the schema based on test results to address
performance issues. Embedded documents store related data in a single
document structure. A document can contain arrays and
Iterate until the schema meets all requirements.
sub-documents with related data. These denormalized
data models allow applications to retrieve related data
in a single database operation
Modeling Data Relationships
References data
SQL: You must determine a table's schema before
inserting data, often require joining data from multiple References store relationships between data by
tables to meet application needs, which can be including links, called references, from one document to
performance-intensive. Relationships between tables another. For example, a customerId field in an orders
using foreign keys. collection indicates a reference to a document in a
customer’s collection.
NoSQL: Schema can evolve over time as application
requirements change, Embedded documents or Applications can resolve these references to access the
references reducing the need for joins. This improves related data. Broadly, these are normalized data models.
performance and simplifies data retrieval.
Link Related Data
When you design your data model in MongoDB,
consider the structure of your documents and the ways
your application uses data from related entities.
Extended Reference Pattern
Embedded pattern with a single collection
3. Hybrid Data Model
Combining embedded and referenced models based on use case.