Data Modelling

1. Model One-to-One Relationship dengan embedded document

Menyematkan data yang terhubung dalam satu dokumen dapat mengurangi jumlah operasi
baca yang diperlukan untuk mendapatkan data. Secara umum, Anda harus menyusun skema
sehingga aplikasi Anda menerima semua informasi yang diperlukan dalam satu operasi baca.

1.1. Embedded Document Pattern

Perhatikan contoh berikut yang memetakan hubungan patron dan alamat. Contoh
tersebut mengilustrasikan keuntungan penyematan dibandingkan referensi jika Anda
perlu melihat satu entitas data dalam konteks entitas lainnya. Dalam hubungan one-to-
one antara patron dan data alamat ini, alamat menjadi milik patron.

// patron document
{
_id: "joe",
name: "Joe Bookreader"
}

// address document
{
patron_id: "joe", // reference to patron document
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}

Dalam model data yang dinormalisasi, dokumen alamat berisi referensi ke dokumen
pelindung.

2. Model One-to-Many Relationship dengan embedded document

3. Model One-to-Many Relationship dengan document references

[MUSIC PLAYING] MongoDB is based on the document model, a fundamentally different

model than traditional relational databases.
The document model is the key design choice we made, and it's why developers love working with
MongoDB.
Let's walk through what the different models look like in practice.
A relational database is fundamentally Microsoft Excel on steroids.
Both are made of rows and columns, organized into tables or sheets.
Let's say we're building a patient record-keeping system for our doctor's office, and we're going to
build it in Microsoft Excel.
First, let's look at a small piece of that system-- the contact information for the patients.
It starts simply enough with a sheet that has a row for each patient.
That row has a unique patient ID number, their first and last name, email address, phone number,
and home address.
But what if we want to add a second phone number for a patient?
Maybe their work number, or their cell phone number, or even an emergency contact number.
We could just add more columns, but the same issue comes up addresses-- work, home, and even
previous addresses are things you might need.
If we just keep adding columns for all the patients' contact information, we'll eventually have a
bloated, mostly empty inefficient table like this.
So instead, in our Excel model, we'll create a separate sheet for phone numbers, and each row in
that sheet is just a phone number, the patient ID refers to in, and a label like home.
We'll do the same thing for addresses.
We already need to go to three different sheets just to look at a single patient, and we're only at the
tip of the iceberg, and haven't even thought about any medical data yet.
Add in more sheets for medications, more sheets for office visits, more sheets for emergency
contacts, lab results-- you can see how this gets out of hand quickly.
This is exactly how developers work with data in relational databases.
In real world applications, it's common to have the data for a single thing like a patient spread out
over dozens of tables.
This adds a massive amount of complexity to the application, and that has three big drawbacks.
The first is that it's just frankly hard for people maintaining the application to understand.
Second, it makes adding features harder because there is so much more to account for.
And third, pulling data from so many places is inefficient, and the applications need to have code to
deal with this.
Imagine if this was done in the real world, and the doctor's staff had to pull names from one cabinet,
phone numbers from another, and addresses from yet another cabinet.
You can see how complicated, error prone, and slow that would be.
MongoDB takes an entirely different approach.
Data is stored in records we call documents, and just like physical medical records, one patient's
document can have three phone numbers, two addresses, and 20 prescriptions, and it can live right
next to another patient document that only has one phone number, one address, and no
prescriptions.
Records aren't restricted to having the same number of columns.
Documents let you structure data in a way that is efficient for computers to process, and natural and
easy for humans to read.
This is incredibly powerful for developers because they don't have to make their applications
accommodate the needs of the database anymore.
MongoDB accommodates them, so their applications can store data in the natural way.
It also means that they can adapt, adding new data when they need to without worrying that a
simple change is going to break everything.
In addition to the document model, MongoDB is fundamentally different from legacy databases
because it natively knows how to coordinate multiple servers to store data.
That makes MongoDB something called "a distributed database," and that allows MongoDB to
provide three features that developers and architects would otherwise have to build from
themselves, saving them massive amounts of risk and work.
First, fault tolerance is natively built into MongoDB.
By keeping redundant copies of the same data on different servers, a single server failure doesn't
affect the application.
Second, MongoDB seamlessly scales across multiple servers to store and process data, so as data
volumes and performance requirements grow, you can just add more servers instead of upgrading
$10 million mainframes.
This is also great for cloud environments, where spreading load across lots of machines is by far the
best way.
And third, it lets you move data to where you need it so you can keep data near users around the
globe for fast access.
The combination of MongoDB's document model and distributed systems components is what gives
MongoDB such an advantage over relational databases.
Beyond offering the leading modern database, we've also built management tools to help operations
teams provision, configure, secure, monitor, backup, restore, and upgrade MongoDB clusters.
This is critical to making MongoDB suitable for the most demanding use cases, and for organizations
with strict SLAs and operations requirements.
We designed MongoDB for the cloud, and MongoDB has been widely deployed in the cloud for some
time.
But more and more customers are interested in building their applications with components offered
as a service.
To meet this need, we released MongoDB Atlas, our database as a service offering.
Atlas enables our customers to consume MongoDB as a service without having to worry about
managing the database.
MongoDB Atlas is available on the leading cloud platforms-- Amazon Web Services, Microsoft Azure,
and Google Cloud Platform-- giving our customers the flexibility to select the public cloud provider of
their choice, avoiding vendor lock-in, and without having to rewrite any code.
These innovations are driving more and more organizations to adopt our platform.