All language subtitles for 003 Designing Our Data Model_Downloadly.ir_en

So in the last lecture,

we learned a theory about data modeling.

And, so, let's now use that theory

in order to actually design the data model

of our Natours application.

And this is for me and for many other developers

actually the most difficult part of building an app.

And, so, I hope that this application will serve

as a good example to you and to give you the knowledge

in order to later design your own data models,

basically completely on your own.

So let's do it now.

And let's start with all the datasets

that we actually need in our application.

So starting with the tours,

and that's of course the most obvious one.

And we already have this one implemented.

Then also we need some users.

And, again, we already have a users collection actually

in our database.

And, so, basically tours and users

are two completely separate datasets.

And, so, we have them normalized.

And of course they're not gonna be embedded.

Next up, we're also gonna have reviews,

and we will also have locations.

Okay?

Because most tours actually have a number

of different locations.

Okay?

And, so, that again is yet another dataset.

And finally, we're also gonna have bookings.

But a little bit more about why that is in a second.

Okay, so, we have all these datasets.

Now let's actually model the relationships

that exist between them.

And I'm gonna start with the relationship

between users and reviews.

And this relationship is clearly a one-to-many relationship

because one user can write multiple reviews,

but one review can only belong to one user.

And the parent in this relationship is clearly the users,

and the child, the reviews

because again it's the parent, so the users in this case,

who can be related to many reviews,

but one review can only be related to one user.

Anyway, I chose to model this relationship

using parent referencing.

And that's because a user can write a lot of reviews

and also because we might actually need to query

only for the reviews on their own.

So the data axis pattern is really important

to take into consideration in this particular relationship.

Now, about the kind of referencing that we're gonna use,

it is parent referencing,

so basically the review keeping a reference of the user.

So keeping an ID, basically.

And that is as you already know

because we do not want to allow a race to grow indefinitely.

And that might be the case

if a user writes tons and tons (laughs) of reviews.

Okay?

Also, it's nice to have the review knowing

who actually wrote it.

Okay?

And, so, having the user ID right on the review

will also us to do just that.

All right.

Next up, let's take a look

at the relationship between tours and reviews.

And this one is actually very similar.

So, again, it's a one-to-many relationship,

where one tour can have multiple reviews

but one review can only be about one tour.

Right?

So that's the way it makes sense.

And, so, we're actually gonna model it in the exact same way

as the user-reviews relationship.

So, again, parent referencing,

so that in the end the reviews end up

with a tour ID and a user ID.

And, so, then once we query for reviews,

we always know exactly.

Great, so let's now talk about the relationship

between tours and locations.

So as I mentioned earlier,

each tour is gonna have a couple of locations.

So for example, the park camper will basically stop

in like three or four national parks.

And, so, each of these national parks

is gonna be one location.

Right?

And, so, each tour will basically have a few locations.

Now, following that example, one of these national parks

might also be part of one of the other tours.

And, so, basically this relationship here

is a few-to-few relationship.

And we called this relationship many-to-many before

but we still can also call them few-to-few

or a ton to a ton.

And, so, I called them few-to-few

because each tour is only gonna have three, four locations

but not really like 100.

Okay?

And, again, each of the locations can also be part

of another tour.

Now, this could be a good example for actually implementing

two-way referencing, so basically normalizing the locations

into its own dataset.

Right?

But instead I'm actually gonna denormalize the locations

so to embed them into the tours.

And that's actually for multiple reasons.

First, because there only so few locations.

Also, we will not really gonna access the locations

on their own.

And, finally, these locations are intrinsically related

to the tours because really without locations

there couldn't be any tours.

Right?

So these datasets belong closely together.

And, so, I chose to embed locations into tours

and not create yet another collection for these.

Right?

So we will have one collection for tours, one for users,

and a bit later we will also create a new collection

for the reviews.

All right?

But for locations, again, because these will be embedded

into the tours.

Okay, and next up there's also a relationship

between the tours and the users.

And that's because we're gonna have tour guides

in the tours, and these tour guides will actually be users.

So remember how we actually gave users a role

in our Mongoose schema?

And the possibilities there contained the guide

and lead guide, remember?

And, so, there's gonna be a relationship

between these types of users and the tours.

Now, this relationship is again a few-to-few relationship

because one tour can have only a few users,

so a few tour guides, but at the same time,

each tour guide can also be guiding a few tours.

All right?

And, so, again, there's a many-to-many relationship here,

which I simply called here few-to-few.

Now, about actually modeling this relationship,

we could do it in two ways.

We could use referencing or embedding.

And actually I'm gonna show you how to implement

both child referencing embedding using Mongoose

throughout this section.

Okay?

And the argument for embedding is that in this case

we could then have all the information about each tour

containing the information about tour guides

right on each tour document.

But on the other hand, that would then create

some extra information in the database

because we will still need to have the users

as a separate collection

simply because we need to access them all the time

for user authentication and authorization

and all that stuff.

So usually, users are always an entity on their own

in each database.

Okay?

But we could still embed some of the users into the tours.

So basically when the user is a tour guide

for a specific tour, we could then copy all this data

into the tour document.

Okay?

But also we would then have to update the user on the tour

each time that the underlying user itself changes.

So let's say that the role of a user changes

from guide to a lead guide.

And in that case, we would then have to go to the tour

and also update that role information

right there on the embedded data.

Okay?

And, so, that's not ideal, and so we're actually

also gonna then implement child referencing.

And, so, with that, we can still keep

basically the information about the tour guides

on the users but simply in a referenced form,

so basically keeping the IDs there,

which are then gonna point to the users.

Okay?

And of course we could also use two-way referencing,

so also keeping an ID of the tour right on the user.

But I think that's a bit too much

for this kind of small example

because not all users will actually need an ID of the tour

because not all users are tour guides.

And, so, this relationship here is a bit tricky to model,

I think, but I believe that in the end

child referencing is gonna be the best way to go.

Okay?

But still, I'm gonna also show you embedding

because I think that's also important to learn.

All right?

Next up, we have our bookings.

And basically a new booking will be created

each time that a user purchases a tour.

So this is still kind of a relationship

between users and tours

because again it's a user who is gonna buy a tour.

But we also want to store some data

about that relationship itself,

so in this case about the purchase itself in our database.

For example, the price or the date

when the purchase happened or something like that.

And, so, in cases like this,

it's a good idea to create an extra dataset,

which in this case is the bookings.

Okay?

And, so, of course there will be a relationship

between tours and bookings and also users and bookings.

And, again, because basically the booking connects tours

with users but kind of with an intermediate step.

So one tour can have many bookings,

but one booking can only belong to one tour.

And the same thing with users.

So one user can book many tours,

but one booking can only belong to one of the users.

And, so, of course we have a one-to-many relationship

in both cases, and also in both cases,

we're gonna use parent referencing.

And, so, that means that on each booking

we're gonna keep an ID of both the tour that was purchased

and also of the user who actually purchased the tour.

Okay?

And, so, in this case, I'm doing it this way

because basically I don't want to pollute the tour data

with information about who actually bought the tour.

Right?

It wouldn't be really relevant to the tour data itself.

And the same thing with users.

So we also don't want to pollute the users object

with all of the bookings that they did.

All right?

And, so, instead again

we're gonna create an intermediate object

or an intermediate dataset that's going to stand

between users and tours whenever they create a new purchase.

Right?

Make sense?

And that's actually it for our data model.

And of course, this now looks kind of abstract,

but once we start implementing it,

it's gonna be very helpful

to have all of our ideas organized into something like this.

So whenever this data model that we're gonna implement

throughout this section is becoming a bit confusing to you,

then just reference back to this slide.

Or you can maybe even print it out

if that makes it easier for you.

So this is our data model in theory.

And now throughout the rest of the course,

I will give you the tools to actually model the data

using the Mongoose Library.