Data Model Examples and Patterns
The following documents provide overviews of various data modeling patterns and common schema design considerations
Model One-to-One Relationships with Embedded Documents – Data in MongoDB has a flexible schema. Collections do not enforce document structure. Decisions that affect how you model data can affect application performance and database capacity. Consider the following example that maps patron and address relationships. The example illustrates the advantage of embedding over referencing if you need to view one data entity in context of the other. In this one-to-one relationship between patron and address data, the address belongs to the patron. In the normalized data model, the address document contains a reference to the patron document.
{ _id: “joe”,
name: “Joe Bookreader” }
{ patron_id: “joe”,
street: “123 Fake Street”,
city: “Faketon”,
state: “MA”,
zip: 12345 }
If the address data is frequently retrieved with the name information, then with referencing, your application needs to issue multiple queries to resolve the reference. The better data model would be to embed the address data in the patron data, as in the following document
{ _id: “joe”,
name: “Joe Bookreader”,
address: {
street: “123 Fake Street”,
city: “Faketon”,
state: “MA”,
zip: 12345
}
}
With the embedded data model, your application can retrieve the complete patron information with one query.
Model One-to-Many Relationships with Embedded Documents – Data in MongoDB has a flexible schema. Collections do not enforce document structure. Decisions that affect how you model data can affect application performance and database capacity. Consider the following example that maps patron and multiple address relationships. The example illustrates the advantage of embedding over referencing if you need to view many data entities in context of another. In this one-to-many relationship between patron and address data, the patron has multiple address entities. In the normalized data model, the address documents contain a reference to the patron document.
{ _id: “joe”,
name: “Joe Bookreader”
}
{ patron_id: “joe”,
street: “123 Fake Street”,
city: “Faketon”,
state: “MA”,
zip: 12345
}
{ patron_id: “joe”,
street: “1 Some Other Street”,
city: “Boston”,
state: “MA”,
zip: 12345
}
If your application frequently retrieves the address data with the name information, then your application needs to issue multiple queries to resolve the references. A more optimal schema would be to embed the address data entities in the patron data, as in the following document
{ _id: “joe”,
name: “Joe Bookreader”,
addresses: [
{
street: “123 Fake Street”,
city: “Faketon”,
state: “MA”,
zip: 12345
},
{ street: “1 Some Other Street”,
city: “Boston”,
state: “MA”,
zip: 12345
}
]
}
With the embedded data model, your application can retrieve the complete patron information with one query.
Model One-to-Many Relationships with Document References – Data in MongoDB has a flexible schema. Collections do not enforce document structure. Decisions that affect how you model data can affect application performance and database capacity. Consider the following example that maps publisher and book relationships. The example illustrates the advantage of referencing over embedding to avoid repetition of the publisher information. Embedding the publisher document inside the book document would lead to repetition of the publisher data, as the following documents show
{ title: “MongoDB: The Definitive Guide”,
author: [ “Kristina Chodorow”, “Mike Dirolf” ],
published_date: ISODate(“2010-09-24”),
pages: 216,
language: “English”,
publisher: { name: “O’Reilly Media”,
founded: 1980,
location: “CA”
}
}
{ title: “50 Tips and Tricks for MongoDB Developer”,
author: “Kristina Chodorow”,
published_date: ISODate(“2011-05-06”),
pages: 68,
language: “English”,
publisher: {
name: “O’Reilly Media”,
founded: 1980,
location: “CA”
}
}
To avoid repetition of the publisher data, use references and keep the publisher information in a separate collection from the book collection. When using references, the growth of the relationships determine where to store the reference. If the number of books per publisher is small with limited growth, storing the book reference inside the publisher document may sometimes be useful. Otherwise, if the number of books per publisher is unbounded, this data model would lead to mutable, growing arrays, as in the following example
{ name: “O’Reilly Media”,
founded: 1980,
location: “CA”,
books: [12346789, 234567890, …]
}
{ _id: 123456789,
title: “MongoDB: The Definitive Guide”,
author: [ “Kristina Chodorow”, “Mike Dirolf” ],
published_date: ISODate(“2010-09-24”),
pages: 216,
language: “English”
}
{ _id: 234567890,
title: “50 Tips and Tricks for MongoDB Developer”,
author: “Kristina Chodorow”,
published_date: ISODate(“2011-05-06”),
pages: 68,
language: “English”
}
To avoid mutable, growing arrays, store the publisher reference inside the book document:
{ _id: “oreilly”,
name: “O’Reilly Media”,
founded: 1980,
location: “CA”
}
{ _id: 123456789,
title: “MongoDB: The Definitive Guide”,
author: [ “Kristina Chodorow”, “Mike Dirolf” ],
published_date: ISODate(“2010-09-24”),
pages: 216,
language: “English”,
publisher_id: “oreilly”
}
{ _id: 234567890,
title: “50 Tips and Tricks for MongoDB Developer”,
author: “Kristina Chodorow”,
published_date: ISODate(“2011-05-06”),
pages: 68,
language: “English”,
publisher_id: “oreilly”
}
Model Tree Structures – MongoDB allows various ways to use tree data structures to model large hierarchical or nested data relationships, as
- Model Tree Structures with Parent References – Presents a data model that organizes documents in a tree-like structure by storing references to “parent” nodes in “child” nodes.
- Model Tree Structures with Child References – Presents a data model that organizes documents in a tree-like structure by storing references to “child” nodes in “parent” nodes.
- Model Tree Structures with an Array of Ancestors – Presents a data model that organizes documents in a tree-like structure by storing references to “parent” nodes and an array that stores all ancestors.
- Model Tree Structures with Materialized Paths – Presents a data model that organizes documents in a tree-like structure by storing full relationship paths between documents. In addition to the tree node, each document stores the _id of the nodes ancestors or path as a string.
- Model Tree Structures with Nested Sets – Presents a data model that organizes documents in a tree-like structure using the Nested Sets pattern. This optimizes discovering subtrees at the expense of tree mutability.
Model Tree Structures with Parent References – Data in MongoDB has a flexible schema. Collections do not enforce document structure. Decisions that affect how you model data can affect application performance and database capacity. This document describes a data model that describes a tree-like structure in MongoDB documents by storing references to “parent” nodes in children nodes. The Parent References pattern stores each tree node in a document; in addition to the tree node, the document stores the id of the node’s parent. Consider the following hierarchy of categories:
The following example models the tree using Parent References, storing the reference to the parent category in the field parent:
db.categories.insert( { _id: “MongoDB”, parent: “Databases” } )
db.categories.insert( { _id: “dbm”, parent: “Databases” } )
db.categories.insert( { _id: “Databases”, parent: “Programming” } )
db.categories.insert( { _id: “Languages”, parent: “Programming” } )
db.categories.insert( { _id: “Programming”, parent: “Books” } )
db.categories.insert( { _id: “Books”, parent: null } )
- The query to retrieve the parent of a node is fast and straightforward
db.categories.findOne( { _id: “MongoDB” } ).parent
- You can create an index on the field parent to enable fast search by the parent node
db.categories.ensureIndex( { parent: 1 } )
- You can query by the parent field to find its immediate children nodes
db.categories.find( { parent: “Databases” } )
The Parent Links pattern provides a simple solution to tree storage but requires multiple queries to retrieve sub-trees.
Apply for MongoDB Certification Now!!
https://www.vskills.in/certification/databases/mongodb-server-administrator
