‫Jonas: Jadi di
‫kuliah terakhir, kami belajar teori tentang pemodelan data.
‫Jadi, sekarang mari kita gunakan
‫teori itu untuk merancang model
‫data aplikasi Natours kita.
‫Dan ini bagi saya dan bagi banyak pengembang
‫lain sebenarnya adalah bagian tersulit dalam membangun sebuah aplikasi.
‫Jadi, saya berharap aplikasi ini akan menjadi contoh
‫yang baik bagi Anda dan memberi Anda
‫pengetahuan untuk kemudian merancang model data Anda sendiri,
‫pada dasarnya sepenuhnya sendiri.
‫Jadi mari kita lakukan sekarang.
‫Dan mari kita mulai dengan semua
‫kumpulan data yang sebenarnya kita butuhkan dalam aplikasi kita.
‫Jadi dimulai dengan tur,
‫dan itu tentu saja yang paling jelas.
‫Dan kami sudah menerapkan yang ini.
‫Kemudian juga kita membutuhkan beberapa pengguna.
‫Dan, sekali lagi, kami sebenarnya sudah memiliki koleksi pengguna
‫di database kami.
‫Jadi, pada dasarnya tur dan pengguna
‫adalah dua kumpulan data yang sepenuhnya terpisah.
‫Dan, jadi, kami membuatnya dinormalisasi.
‫Dan tentu saja mereka tidak akan disematkan.
‫Selanjutnya, kami juga akan memiliki ulasan, dan
‫kami juga akan memiliki lokasi.
‫Oke?
‫Karena kebanyakan wisata sebenarnya memiliki sejumlah
‫lokasi yang berbeda.
‫Oke?
‫Dan, sekali lagi, itu adalah kumpulan data lain.
‫Dan akhirnya, kami juga akan memiliki pemesanan.
‫Tetapi sedikit lebih banyak tentang mengapa itu terjadi dalam hitungan detik.
‫Oke, jadi, kami memiliki semua kumpulan data ini.
‫Sekarang mari kita benar-benar memodelkan hubungan yang
‫ada di antara mereka.
‫Dan saya akan mulai
‫dengan hubungan antara pengguna dan ulasan.
‫Dan hubungan ini jelas merupakan hubungan satu-ke-banyak karena satu pengguna
‫dapat menulis beberapa ulasan, tetapi satu ulasan
‫hanya dapat dimiliki oleh satu pengguna.
‫Dan orang tua dalam hubungan ini jelas adalah pengguna,
‫dan anak, ulasan karena
‫sekali lagi itu adalah orang tua, jadi pengguna dalam hal ini,
‫yang dapat dikaitkan dengan banyak ulasan,
‫tetapi satu ulasan hanya dapat dikaitkan dengan satu pengguna.
‫Bagaimanapun, saya memilih untuk memodelkan hubungan ini
‫menggunakan referensi orang tua.
‫Dan itu karena seorang pengguna dapat menulis banyak ulasan dan juga
‫karena kami mungkin sebenarnya hanya perlu melakukan
‫kueri untuk ulasan mereka sendiri.
‫Jadi pola sumbu data sangat
‫penting untuk dipertimbangkan dalam hubungan khusus ini.
‫Sekarang, tentang jenis referensi yang akan kita
‫gunakan, itu adalah
‫referensi orang tua, jadi pada dasarnya ulasan menyimpan referensi pengguna.
‫Jadi menyimpan ID, pada dasarnya.
‫Dan itu seperti yang
‫sudah Anda ketahui karena kami tidak ingin membiarkan suatu ras tumbuh tanpa batas.
‫Dan itu
‫mungkin terjadi jika pengguna menulis berton-ton (tertawa) ulasan.
‫Oke?
‫Juga, senang memiliki ulasan mengetahui siapa
‫yang sebenarnya menulisnya.
‫Oke?
‫Dan, jadi, memiliki ID pengguna yang tepat di ulasan juga
‫akan membuat kami melakukan hal itu.
‫Baiklah.
‫Selanjutnya, mari
‫kita lihat hubungan antara tur dan ulasan.
‫Dan yang satu ini sebenarnya sangat mirip.
‫Jadi, sekali lagi, ini adalah hubungan satu-ke-banyak, di
‫mana satu tur dapat memiliki beberapa ulasan
‫tetapi satu ulasan hanya dapat berisi tentang satu tur.
‫Benar?
‫Jadi itu cara yang masuk akal.
‫Dan, jadi, kami sebenarnya akan memodelkannya dengan cara yang sama
‫persis seperti hubungan ulasan pengguna.
‫Jadi, sekali lagi, referensi
‫orang tua, sehingga pada akhirnya ulasan
‫berakhir dengan ID tur dan ID pengguna.
‫Jadi, begitu kami meminta ulasan, kami
‫selalu tahu persis.
‫Bagus, jadi sekarang mari kita bicara tentang
‫hubungan antara tur dan lokasi.
‫Jadi seperti yang
‫saya sebutkan sebelumnya, setiap tur akan memiliki beberapa lokasi.
‫Jadi misalnya, taman kemping pada dasarnya akan berhenti di
‫seperti tiga atau empat taman nasional.
‫Dan, jadi, masing-masing taman nasional ini
‫akan menjadi satu lokasi.
‫Benar?
‫Jadi, setiap tur pada dasarnya memiliki beberapa lokasi.
‫Sekarang, mengikuti contoh itu, salah satu taman nasional
‫ini mungkin juga menjadi bagian dari salah satu wisata lainnya.
‫Jadi, pada dasarnya hubungan
‫ini di sini adalah hubungan sedikit-ke-sedikit.
‫Dan kami menyebut hubungan ini banyak-ke-banyak sebelumnya,
‫tetapi kami masih dapat menyebutnya sedikit-ke-sedikit atau
‫satu ton ke satu ton.
‫Dan, jadi, saya menyebutnya
‫sedikit-ke-sedikit karena setiap tur hanya akan memiliki tiga, empat lokasi
‫tetapi tidak terlalu seperti 100.
‫Oke?
‫Dan, sekali lagi, setiap lokasi juga bisa menjadi bagian
‫dari tur lainnya.
‫Sekarang, ini bisa menjadi contoh yang baik untuk
‫benar-benar menerapkan referensi dua arah, jadi pada dasarnya menormalkan lokasi ke
‫dalam kumpulan datanya sendiri.
‫Benar?
‫Tapi sebaliknya, saya sebenarnya akan mendenormalisasi lokasi
‫untuk memasukkannya ke dalam tur.
‫Dan itu sebenarnya karena berbagai alasan.
‫Pertama, karena hanya ada sedikit lokasi.
‫Juga, kami tidak akan benar-benar mengakses lokasi
‫mereka sendiri.
‫Dan akhirnya, lokasi-lokasi ini secara intrinsik
‫terkait dengan tur karena tanpa lokasi tidak
‫mungkin ada tur.
‫Benar?
‫Jadi kumpulan data ini saling terkait erat.
‫Jadi, saya memilih untuk menyematkan lokasi ke dalam tur dan
‫tidak membuat koleksi lain untuk ini.
‫Benar?
‫Jadi kami akan memiliki satu koleksi untuk tur, satu untuk pengguna,
‫dan sebentar lagi kami juga akan membuat koleksi
‫baru untuk ulasan.
‫Baiklah?
‫Tapi untuk lokasi, sekali lagi, karena ini akan disematkan ke
‫dalam wisata.
‫Oke, dan selanjutnya ada juga hubungan
‫antara tur dan pengguna.
‫Dan itu karena kita akan memiliki
‫pemandu wisata dalam tur, dan pemandu wisata ini sebenarnya akan menjadi pengguna.
‫Jadi ingat bagaimana kami benar-benar memberi pengguna peran dalam
‫skema Mongoose kami?
‫Dan kemungkinan di sana terdapat guide
‫dan lead guide, ingat?
‫Dan, jadi, akan
‫ada hubungan antara jenis pengguna ini dan tur.
‫Sekarang, hubungan ini sekali lagi merupakan hubungan beberapa ke beberapa karena
‫satu tur hanya dapat memiliki beberapa pengguna, jadi
‫beberapa pemandu wisata, tetapi pada saat
‫yang sama, setiap pemandu wisata juga dapat memandu beberapa tur.
‫Baiklah?
‫Dan, sekali lagi, ada hubungan banyak-ke-banyak di sini,
‫yang saya sebut di sini sedikit-ke-sedikit.
‫Sekarang, tentang memodelkan hubungan ini, kita bisa
‫melakukannya dengan dua cara.
‫Kita bisa menggunakan referensi atau embedding.
‫Dan sebenarnya saya akan menunjukkan kepada
‫Anda bagaimana menerapkan kedua penyematan referensi anak menggunakan Mongoose
‫di seluruh bagian ini.
‫Oke?
‫Dan argumen untuk penyematan adalah bahwa dalam hal ini
‫kita kemudian dapat memiliki semua informasi tentang setiap
‫tur yang berisi informasi tentang
‫pemandu wisata tepat di setiap dokumen tur.
‫Tetapi di sisi lain, itu
‫kemudian akan membuat beberapa informasi tambahan
‫dalam database karena kita masih perlu
‫memiliki pengguna sebagai
‫koleksi terpisah hanya karena kita perlu mengaksesnya setiap saat
‫untuk otentikasi dan otorisasi pengguna dan
‫semua itu.
‫Jadi biasanya, pengguna selalu merupakan entitas mereka sendiri di
‫setiap database.
‫Oke?
‫Tapi kami masih bisa menyematkan beberapa pengguna ke dalam tur.
‫Jadi pada dasarnya ketika pengguna adalah pemandu
‫wisata untuk tur tertentu, kami kemudian dapat menyalin semua data
‫ini ke dalam dokumen tur.
‫Oke?
‫Tetapi kami juga harus memperbarui pengguna di tur setiap
‫kali pengguna yang mendasari itu sendiri berubah.
‫Jadi, katakanlah peran pengguna berubah dari
‫pemandu menjadi pemandu utama.
‫Dan dalam hal ini, kami kemudian harus pergi ke
‫tur dan juga memperbarui informasi peran itu di
‫sana pada data yang disematkan.
‫Oke?
‫Dan, jadi, itu tidak ideal, jadi
‫kami sebenarnya juga akan menerapkan referensi anak.
‫Jadi, dengan itu, pada
‫dasarnya kita masih dapat menyimpan informasi
‫tentang pemandu wisata pada pengguna tetapi hanya dalam bentuk
‫referensi, jadi pada dasarnya menyimpan ID
‫di sana, yang kemudian akan mengarah ke pengguna.
‫Oke?
‫Dan tentu saja kami juga dapat menggunakan
‫referensi dua arah, demikian juga dengan menyimpan ID tur pada pengguna.
‫Tapi menurut saya
‫itu terlalu berlebihan untuk contoh kecil
‫seperti ini karena tidak semua pengguna benar-benar membutuhkan ID tur
‫karena tidak semua pengguna adalah pemandu wisata.
‫Dan, jadi, hubungan ini di sini agak sulit untuk dimodelkan,
‫saya pikir, tapi saya percaya
‫bahwa pada akhirnya referensi anak akan menjadi cara terbaik untuk dilakukan.
‫Oke?
‫Tapi tetap saja, saya juga akan
‫menunjukkan embedding karena menurut saya itu juga penting untuk dipelajari.
‫Baiklah?
‫Selanjutnya, kami memiliki pemesanan kami.
‫Dan pada dasarnya pemesanan baru
‫akan dibuat setiap kali pengguna membeli tur.
‫Jadi ini masih semacam hubungan
‫antara pengguna dan
‫tur karena sekali lagi pengguna yang akan membeli tur.
‫Tapi kami juga ingin menyimpan
‫beberapa data tentang hubungan itu sendiri,
‫jadi dalam hal ini tentang pembelian itu sendiri di database kami.
‫Misalnya, harga atau
‫tanggal terjadinya pembelian atau semacamnya.
‫Dan, jadi, dalam
‫kasus seperti ini, ada baiknya untuk membuat kumpulan data
‫tambahan, yang dalam hal ini adalah pemesanan.
‫Oke?
‫Dan, jadi, tentu saja akan
‫ada hubungan antara tur dan pemesanan dan juga pengguna dan pemesanan.
‫Dan, sekali lagi, karena pada dasarnya pemesanan menghubungkan tur
‫dengan pengguna tetapi semacam dengan langkah perantara.
‫Jadi satu tur dapat memiliki banyak pemesanan,
‫tetapi satu pemesanan hanya dapat dimiliki oleh satu tur.
‫Dan hal yang sama dengan pengguna.
‫Jadi satu pengguna dapat memesan banyak
‫tur, tetapi satu pemesanan hanya dapat dimiliki oleh salah satu pengguna.
‫Dan, jadi, tentu saja kami memiliki hubungan satu-ke-banyak
‫dalam kedua kasus, dan juga dalam kedua kasus,
‫kami akan menggunakan referensi induk.
‫Jadi, itu berarti bahwa pada
‫setiap pemesanan kami akan menyimpan ID dari tur yang dibeli
‫dan juga pengguna yang benar-benar membeli tur.
‫Oke?
‫Dan, jadi, dalam hal ini,
‫saya melakukannya karena pada dasarnya saya tidak ingin mengotori
‫data tur dengan informasi tentang siapa yang sebenarnya membeli tur.
‫Benar?
‫Itu tidak akan benar-benar relevan dengan data tur itu sendiri.
‫Dan hal yang sama dengan pengguna.
‫Jadi kami juga tidak ingin mengotori objek pengguna dengan
‫semua pemesanan yang mereka lakukan.
‫Baiklah?
‫Dan, jadi, sebagai
‫gantinya, sekali lagi kita akan membuat objek perantara
‫atau kumpulan data perantara yang akan berdiri
‫di antara pengguna dan tur setiap kali mereka membuat pembelian baru.
‫Benar?
‫Masuk akal?
‫Dan itu sebenarnya untuk model data kami.
‫Dan tentu saja, ini sekarang terlihat agak abstrak, tetapi
‫begitu kita mulai menerapkannya,
‫akan sangat
‫membantu untuk mengatur semua ide kita menjadi sesuatu seperti ini.
‫Jadi setiap kali model data yang akan kita
‫terapkan di seluruh bagian ini menjadi sedikit membingungkan bagi Anda,
‫maka cukup rujuk kembali ke slide ini.
‫Atau Anda bahkan dapat mencetaknya
‫jika itu memudahkan Anda.
‫Jadi ini adalah model data kami secara teori.
‫Dan sekarang sepanjang sisa kursus, saya
‫akan memberi Anda alat untuk benar-benar memodelkan data
‫menggunakan Perpustakaan Mongoose.