Data Modelling is the process of taking unstructured data generated by a real world scenario and

then structure it into a logical data model in a database. And we do this according to a set of criterias.

Real worl scenario Online shop

Unstructured data categories, suppliers, orders, cart, customers,

Products

Structured, logical data modal categories

Products suppliers

Customers

Orders cart

Many backend developers say the data is where we have to think the most and that it’s the most
demanding part of building an entire application. Because it’s not always straightforward and
sometimes there are simply no right answers.

4 steps for data modelling:

1. Different types of relationships between data

2. Referencing/normalization vs. embedding/denormalization
3. Embedding or referencing other documents?
4. Types of referencing

1. Types of Relationships between data

There are 3 big types of relationships
- 1:1 (one to one)
- 1:Many (one to many)
- Many:Many (many to many)

1:1 relationship between data is basically when one field can only have one value. For example in a
movie application, one movie can only have one name.

1: Many relationship is clearly when one field has more than one value. There are 3 types of 1:Many

- 1:Few
- 1:Many
- 1:Ton
1:Few -> a movie can win several awards

1:Many -> a movie can have many reviews (hundreds / thousands of them)

1:Ton -> logging in activity to an app (can be millions)

1:Many relationship is the most important to know. In MongoDB, it is very important to know the
quantity of 1:Many because it’s a factor to decide to normalize or denormalize.

Many:Many relationship is when a field has more than one values in a document and those values
can also be values in another field of another document. Like a movie has more than one actors, and
those actors starred in other movies too. In this type, the relation goes both ways, whereas in the first
two types of relationship it goes from one to the other.

2. Referencing vs. Embedding

Referencing / normalizing:

“_id”: ObjectID(‘222’),

“title”: “Interstellar”,

“releaseYear”: 2014,

“actors”: [

ObjectID(‘555’),

ObjectID(‘777’),

Embedding / denormalizing:

“_id”: ObjectID(‘222’),

“title”: “Interstellar”,

“releaseYear”: 2014,

“actors”: [

“name”: “Matthew McConaughey”,

 “age”: 50,

“born”: “Uvalde, USA”,

“name”: “Anne Hathaway”,

“age”: 37,

“born”: “NYC, USA”,

In relational databases, all data is always represented in referenced / normalized form. In a NoSQL
database like MongoDB we can denormalize data into a denormalized form simply by embedding
documents right into the main document.

Embedded / denormalized way is good for perfomance because we can get all the information in one
query. The downside here is that we can’t really query the embedded data on its own. The vice versa
of these pro and con is valid for referenced / normalized way.

3. Embedding or referencing other documents?

How to decide if normalize or denormalize?

Combine all 3 criterias to make EMBEDDING REFERENCING

the decision

1. Relation types 1:Few 1:Many

1:Many 1:Ton
Many:Many
2. Data access patterns Data is mostly read Data is updated a lot
Data does not change quickly Low read / write ratio
High read / write ratio
3. Data closeness Datasets really belong together We frequently need to query
both datasets on their own

4. Types of Referencing
- Child referencing
- Parent referencing
- Two-way referencing
Child referencing:

“_id”: ObjectID(‘222’),

“title”: “Interstellar”,

“releaseYear”: 2014,

“actors”: [

ObjectID(‘555’),

ObjectID(‘777’),

“_id”: ObjectID(‘555’),

“name”: “Matthew McConaughey”,

“age”: 50,

“born”: “Uvalde, USA”,

“_id”: ObjectID(‘777’),

“name”: “Anne Hathaway”,

“age”: 37,

“born”: “NYC, USA”,

Parent referencing:

App “_id”: ObjectID(‘23’),

“app”: “My Movie Database”,

}
 {

“_id”: ObjectID(‘1’),

Log “app”: ObjectID(‘23’)

“type”: “error”,

“timestamp”: 1412184926

“_id”: ObjectID(‘654897’),

Log “app”: ObjectID(‘23’)

“type”: “error”,

“timestamp”: 1412789926

There is 16 mb limit in documents.

Child referencing best for 1:Few

Parent referencing best for 1:Many and 1:Ton

Two-way referencing:

“_id”: ObjectID(‘222’),

“title”: “Interstellar”,

movie “releaseYear”: 2014,

“actors”: [

ObjectID(‘555’),

ObjectID(‘777’),

}
 {

“_id”: ObjectID(‘555’),

actor “name”: “Matthew McConaughey”,

“age”: 50,

“born”: “Uvalde, USA”,

“movies”: [

ObjectID(‘222’),

// … and many more

SUMMARY
The most important principle is to structure your data to match the ways that your application
queries and updates data.

In other words, identify the questions that arise from your application’s use cases first, and then
model your data so that the questions can get answered in the most efficient way.

In general, always favor embedding, unless there is a good reason not to embed.

A 1:TON and a Many:Many relationship is usually a good reason to reference instead of embedding.

Also favor referencing when data is updated a lot and if you need to frequently access a dataset on its
own.

Use embedding when data is mostly read but rarely updated and when two datasets belong
instrinsically together.

Don’t allow arrays to grow indefinitely. Therefore, if you need to normalize, use child referencing for
1:Many relationships and parent referencing for 1:Ton relationships.

Use two-way referencing for Many:Many relationships.