Relations between documents

Introduction

In Mongo DB relationships imply logical connections between a number of documents within collections. We already know that the structure of data in Mongo DB is flexible, meaning that documents stored in one collection do not necessarily have the same set of fields or similar outlines. Such a flexible approach to data representation simplifies the process of matching a document with an entity or an object. Each document can match the data fields of another object, even if the represented data differs significantly.

Types of relations

Data relations between documents in Mongo DB represent the same structure patterns as in RDMS. They are the following:

1:1 (One to One)
One record from an entity A is related to exactly one record from an entity B.

1:N (One to Many)
The relationship between entities A and B in which one party may have one or more relationships with the other. The second side always has only one connection.

N:M (Many to Many)
In such a relationship, both parties (A and B) may have one or more links to the other party.

The concept is that relationships in RDBMS are obtained using primary and foreign keys, as well as queries to them using merges (JOINs). In Mongo DB there is no direct relations mapping, but here relations are obtained by using embedded (nested) documents or specifying links to documents. In other words, Mongo DB supplies two main types of relations:

• Embedded relations (also known as the "denormalized" data model")

• Referenced relations (also known as the "normalized" data model)

Embedded relations (Nested documents)

An embedded document (nested document) in Mongo DB is a normal document incorporated into another document in a collection. In other words, nested documents fix relations between data by storing related data in a single document structure.

Let's study an example of such a relation below:

User info

{ _id:<ObjectId>
  user:"User Name",
  contact: {
             email:"[email protected]",
             phone: 0903456789,
             address:"777 ParkLain str. 38"

            },
  payment:  {
             creditcard:7659098767890876,
             bank:"City",
             taxid:66789,
            }
}

Here we can see a document with user info with embedded contact and payment sub-documents.

By allowing the user to embed document structures in a field or array within a document, embedded relation models facilitate operations of data retrieving and managing in a single database operation.

An embedded model becomes a viable option when:

• you have "one to one" relations between entities.

• you have "one to many" relationships between entities (i.e. an employee with several addresses).

• you want better performance for read operations.

Referenced relations

Within this relation type, documents exist separately and are not embedded into each other. However, one document contains a reference to the other documents. Let's consider the users' info from the above as an example:

user document

{ _id: <ObjectId>
  user: "User Name"
}

contact document

contact: {    
             _id <ObjectId2>
             user_id:<ObjectId1> 
             email:"[email protected]",
             phone: 0903456789,
             address:"777 ParkLain str. 38"

            }

payment document

payment:  {
             _id:<ObjectId3>
             user_id:<ObjectId1>
             creditcard:7659098767890876,
             bank:"City",
             taxid:66789,
            }

Above we have three documents: one is a user (including user's name) and two other documents are contact document (containing contact details of a user) and payment document (with payment details of a user). As we can see, contact and payment documents contain the reference to the user document id field. By using this reference id we can query the contact and payment method of a user.

This normalized data model of reference relations can be used when:

• embedding leads to data duplication and read performance advantages do not outweigh duplication consequences.

• you have to implement more complex "many to many" relations.

• you have to model large hierarchical data sets.

Conclusion

In this topic, we've explored the peculiarities of the relationships between documents in MongoDB. We've learned:

• what types of relations exist and what is their essence.

• what nested documents and embedded relations are in MongoDB and in what cases it is better to choose this model.

• what referenced relation model is, how it differs from the embedded one, and in what cases it works better than the nested documents.

Now it's time to challenge yourself and put the new knowledge to practice!