MongoDB: data modeling

This is a completed online course called MongoDB: data modeling with an estimated workload of 8 hours, carrying out 50 of 50 activities, from 02/20/2024 to 02/22/2024. Topics include the following:

• Data modeling;
• Structuring the data;
• Relationships;
• Hierarchical data;
• Practicing.

MongoDB has implemented ACID transactions which are features already used by relational databases. This database transaction acronyms stands for: Atomicity, Consistency, Isolation, and Durability. This atomicity works at the level of a document, even if some command is updating several documents at the same time, that means, the modification will be atomic at the document level, and not for the entire operation.

Below there are the data structures that MongoDB works with:

• Embedded data: the structure of data that has relationships, is stored in a single document, such as, Name(Nome), Address (Endereco) and Accounts (Contas) information together in the clients (clientes) collection.

Name, address and accounts information stored in the clients collection

• References: the structure of data that has relationships, are stored in several collections, such as, clients(clientes), address (endereco) and accounts (contas) information separated in their own collections.

Below, there are examples of reference structures where the id (_id) of a document is manually inserted into the other documents (id_clientes).

Clients collection

Address collection

Accounts collection

Below, there are examples of reference structures using DBRefs. They more easily reference documents stored in multiple collections or databases. As a reference, the value of the _id field ($id) of the first document, the name of the collection ($ref) and the name of the database ($db - optional) are used. In this case, the Visual Studio Code tool needs to be used, since it is not possible to declare variables (original_id) in the NoSQLBooster platform. The command line can be also used instead of VSCode.

Clients collection

Address collection

Accounts collection

In the DBRefs examples above, _id received the contents of ObjectId(), but it could also manually receive any value.

Get Dalvolinda Silva’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

As a NoSQL database, the concept of relationships in MongoDB occurs between documents and can be classified into three models:

• One-to-One Relationships with Embedded Documents: As an example, there is just one collection, in which each client (clientes) has only an address (Endereco) and account (Contas).

Clients collection

• One-to-Many Relationships with Embedded Documents: As an example, there is just one collection, in which each client (clientes) has an account (Contas), but two addresses (Endereco). In this case, square brackets ([]) must be added after Address (Endereco) in order to indicate that it is an array.

Clients collection

• One-to-Many Relationships with Document References: as an example, there are three collections, in which each client (clientes) has an account (contas), but it can have many addresses (enderecos). Square brackets ([]) must also be used in order to indicate that addresses is an array. The $id, $ref and $db parameters were assigned to address and accounts collections.

Clients collection

Address collection

Accounts collection

MongoDB works also with hierarchical data and below there is a tree structure as an example:

Tree structure example

The patterns used by MongoDB in order to organize data in a tree structure are described below:

• Parent references: in this pattern, only 2 pieces of information are stored within each document: the node and its parent.

Parent references pattern

• Child references: in this pattern, 2 pieces of information are stored in each document: the node and its children within an array.

Child references pattern

• Array of ancestors: in this pattern, the node of all its ancestors is stored in each document.

Array of ancestors pattern

• Materialized paths: in this pattern, the node and the id of its ancestors or the node path are stored in the document.

Materialized paths pattern

• Nested Sets: as the structure below, in this pattern each node in the tree is considered as a stop on a journey. Therefore, each document needs to store information about how to traverse each node.

Tree node journey

Nested Sets pattern

In conclusion, the relationships in MongoDB exemplified in this story are related to document creation (insert), but they can also be adapted to schema validation. In this case, address must have its schema validation changed from bsonType “string” to “array” in One-to-Many Relationships with Embedded Documents topic. See MongoDB: validating data for more details.

[Here is the Certificate of Completion.]