MongoDB DATA MODEL

From some previous posts we talked about MongoDB installation and basic commands. So from this post I’m going to talk about much more advanced topic in MongoDB, Data Model.

Data in MongoDB has a flexible schema. Unlike SQL databases, where you must determine and declare a table’s schema before inserting data, MongoDB’s collections do not enforce document structure. This flexibility facilitates the mapping of documents to an entity or an object. Each document can match the data fields of the represented entity, even if the data has substantial variation. In practice, however, the documents in a collection share a similar structure.

rdbms.png

There are two main techniques used in MongoDB to keep the relationship between data,

  1. Embedded documents.
  2. Referenced/Normalized documents.

EMBEDDED DOCUMENTS

Embedded documents capture relationships between data by storing related data in a single document structure. MongoDB documents make it possible to embed document structures in a field or array within a document. These unnormalized data models allow applications to retrieve and manipulate related data in a single database operation.

data-model-denormalized

NORMALIZED DOCUMENTS

References store the relationships between data by including links or references from one document to another. Applications can resolve these references to access the related data. Broadly, these are normalized data models.

data-model-normalized.png

Next we can talk about data model design patterns. There are few patterns in used,

  1. Relationships
    • Embedded
      • One to One
      • One to Many
    • Referenced
      • One to Many
  2. Model Tree
    • Parent reference
    • Child reference
    • Array of ancestors
    • Materialized path
    • Nested sets

Now let’s see each of them with examples. Already we have talked about Relationships, Unnormalized and Normalized patterns.

MODEL TREE

PARENT REFERENCE

Here we create the parents for children. This pattern stores each tree node in a document, in addition to the tree node, the document stores the id of the node’s parent.

  • Let’s see an example of this pattern.

1.png

  • We can retrieve information from this way.

2.png

  • Now let’s try to create multiple parents for a child. It’s not possible.

3.png

  • Now let’s try to insert multiple children for a parent. It’s possible.

4.png

7.png

  • We can create an INDEX for the parent field as well. This will make the searching efficient.

8.png

CHILD REFERENCE

In the previous pattern what we did is, create parents for a specific node. But what we do here is creating children for a specific parent node.

  • Let’s do some examples. Multiple children are possible.

10.png

  • Let’s retrieve children of  the parent.

11.png

12.png

  • The main difference here over parent reference is multiple parents are possible here.

13

14

ARRAY OF ANCESTORS

Here we can create an array of ancestors for a given node.

  • Let’s do some example.

19.png

  • Now let’s retrieve the tree of ancestors.

20.png

  • It’s valid for any node in the middle of the tree.

21.png

MATERIALIZED PATH

This is somewhat similar to the array of ancestors. Here also we can give the traversal to a node from the top element. Here we use the ‘,’ separator to give the traversal.

  • Let’s try it.

24.png

  • Let’s retrieve the traversal. Here we can use regular expressions to find the traversal.

25.png

30.png

  • If you want to get the whole tree, then you can use this method.

26.png

NESTED SETS

The Nested Sets pattern identifies each node in the tree as stops in a round-trip traversal of the tree. The application visits each node in the tree twice; first during the initial trip, and second during the return trip. The Nested Sets pattern stores each tree node in a document; in addition to the tree node, document stores the id of node’s parent, the node’s initial stop in the left field, and its return stop in the right field.

data-model-example-nested-set.png

  • Let’s create the traversal for the above graph. This is a bit difficult method, because we have to give the left and right visits of the traversal.

33.png

  • Let’s retrieve data.

34.png

That’s all for MongoDB data models. Hope now you have a clear idea about data models and design patterns. See you soon with another interesting topic. Thank You!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s