1
00:00:01,150 --> 00:00:02,540
‫Jonas: Jadi di

2
00:00:02,540 --> 00:00:04,990
‫kuliah terakhir, kami belajar teori tentang pemodelan data.

3
00:00:04,990 --> 00:00:07,430
‫Jadi, sekarang mari kita gunakan

4
00:00:07,430 --> 00:00:09,930
‫teori itu untuk merancang model

5
00:00:09,930 --> 00:00:12,140
‫data aplikasi Natours kita.

6
00:00:12,140 --> 00:00:15,160
‫Dan ini bagi saya dan bagi banyak pengembang

7
00:00:15,160 --> 00:00:18,400
‫lain sebenarnya adalah bagian tersulit dalam membangun sebuah aplikasi.

8
00:00:18,400 --> 00:00:21,570
‫Jadi, saya berharap aplikasi ini akan menjadi contoh

9
00:00:21,570 --> 00:00:24,660
‫yang baik bagi Anda dan memberi Anda

10
00:00:24,660 --> 00:00:27,860
‫pengetahuan untuk kemudian merancang model data Anda sendiri,

11
00:00:27,860 --> 00:00:29,663
‫pada dasarnya sepenuhnya sendiri.

12
00:00:30,640 --> 00:00:32,130
‫Jadi mari kita lakukan sekarang.

13
00:00:32,130 --> 00:00:34,560
‫Dan mari kita mulai dengan semua

14
00:00:34,560 --> 00:00:37,690
‫kumpulan data yang sebenarnya kita butuhkan dalam aplikasi kita.

15
00:00:37,690 --> 00:00:39,430
‫Jadi dimulai dengan tur,

16
00:00:39,430 --> 00:00:41,630
‫dan itu tentu saja yang paling jelas.

17
00:00:41,630 --> 00:00:44,730
‫Dan kami sudah menerapkan yang ini.

18
00:00:44,730 --> 00:00:47,150
‫Kemudian juga kita membutuhkan beberapa pengguna.

19
00:00:47,150 --> 00:00:50,590
‫Dan, sekali lagi, kami sebenarnya sudah memiliki koleksi pengguna

20
00:00:50,590 --> 00:00:51,870
‫di database kami.

21
00:00:51,870 --> 00:00:54,020
‫Jadi, pada dasarnya tur dan pengguna

22
00:00:54,020 --> 00:00:56,470
‫adalah dua kumpulan data yang sepenuhnya terpisah.

23
00:00:56,470 --> 00:00:58,270
‫Dan, jadi, kami membuatnya dinormalisasi.

24
00:00:58,270 --> 00:01:00,593
‫Dan tentu saja mereka tidak akan disematkan.

25
00:01:01,540 --> 00:01:04,270
‫Selanjutnya, kami juga akan memiliki ulasan, dan

26
00:01:04,270 --> 00:01:06,360
‫kami juga akan memiliki lokasi.

27
00:01:06,360 --> 00:01:07,300
‫Oke?

28
00:01:07,300 --> 00:01:09,380
‫Karena kebanyakan wisata sebenarnya memiliki sejumlah

29
00:01:09,380 --> 00:01:10,930
‫lokasi yang berbeda.

30
00:01:10,930 --> 00:01:11,763
‫Oke?

31
00:01:11,763 --> 00:01:14,600
‫Dan, sekali lagi, itu adalah kumpulan data lain.

32
00:01:14,600 --> 00:01:17,300
‫Dan akhirnya, kami juga akan memiliki pemesanan.

33
00:01:17,300 --> 00:01:20,780
‫Tetapi sedikit lebih banyak tentang mengapa itu terjadi dalam hitungan detik.

34
00:01:20,780 --> 00:01:23,320
‫Oke, jadi, kami memiliki semua kumpulan data ini.

35
00:01:23,320 --> 00:01:25,950
‫Sekarang mari kita benar-benar memodelkan hubungan yang

36
00:01:25,950 --> 00:01:27,480
‫ada di antara mereka.

37
00:01:27,480 --> 00:01:29,100
‫Dan saya akan mulai

38
00:01:29,100 --> 00:01:31,470
‫dengan hubungan antara pengguna dan ulasan.

39
00:01:31,470 --> 00:01:36,100
‫Dan hubungan ini jelas merupakan hubungan satu-ke-banyak karena satu pengguna

40
00:01:36,100 --> 00:01:39,260
‫dapat menulis beberapa ulasan, tetapi satu ulasan

41
00:01:39,260 --> 00:01:42,360
‫hanya dapat dimiliki oleh satu pengguna.

42
00:01:42,360 --> 00:01:45,550
‫Dan orang tua dalam hubungan ini jelas adalah pengguna,

43
00:01:45,550 --> 00:01:47,240
‫dan anak, ulasan karena

44
00:01:47,240 --> 00:01:51,160
‫sekali lagi itu adalah orang tua, jadi pengguna dalam hal ini,

45
00:01:51,160 --> 00:01:53,560
‫yang dapat dikaitkan dengan banyak ulasan,

46
00:01:53,560 --> 00:01:56,730
‫tetapi satu ulasan hanya dapat dikaitkan dengan satu pengguna.

47
00:01:56,730 --> 00:01:59,290
‫Bagaimanapun, saya memilih untuk memodelkan hubungan ini

48
00:01:59,290 --> 00:02:01,160
‫menggunakan referensi orang tua.

49
00:02:01,160 --> 00:02:04,830
‫Dan itu karena seorang pengguna dapat menulis banyak ulasan dan juga

50
00:02:04,830 --> 00:02:07,490
‫karena kami mungkin sebenarnya hanya perlu melakukan

51
00:02:07,490 --> 00:02:09,600
‫kueri untuk ulasan mereka sendiri.

52
00:02:09,600 --> 00:02:12,490
‫Jadi pola sumbu data sangat

53
00:02:12,490 --> 00:02:16,300
‫penting untuk dipertimbangkan dalam hubungan khusus ini.

54
00:02:16,300 --> 00:02:18,940
‫Sekarang, tentang jenis referensi yang akan kita

55
00:02:18,940 --> 00:02:20,610
‫gunakan, itu adalah

56
00:02:20,610 --> 00:02:24,220
‫referensi orang tua, jadi pada dasarnya ulasan menyimpan referensi pengguna.

57
00:02:24,220 --> 00:02:26,670
‫Jadi menyimpan ID, pada dasarnya.

58
00:02:26,670 --> 00:02:28,220
‫Dan itu seperti yang

59
00:02:28,220 --> 00:02:32,510
‫sudah Anda ketahui karena kami tidak ingin membiarkan suatu ras tumbuh tanpa batas.

60
00:02:32,510 --> 00:02:33,940
‫Dan itu

61
00:02:33,940 --> 00:02:37,860
‫mungkin terjadi jika pengguna menulis berton-ton (tertawa) ulasan.

62
00:02:37,860 --> 00:02:38,930
‫Oke?

63
00:02:38,930 --> 00:02:41,790
‫Juga, senang memiliki ulasan mengetahui siapa

64
00:02:41,790 --> 00:02:43,220
‫yang sebenarnya menulisnya.

65
00:02:43,220 --> 00:02:44,053
‫Oke?

66
00:02:44,053 --> 00:02:46,440
‫Dan, jadi, memiliki ID pengguna yang tepat di ulasan juga

67
00:02:46,440 --> 00:02:48,273
‫akan membuat kami melakukan hal itu.

68
00:02:49,120 --> 00:02:49,953
‫Baiklah.

69
00:02:49,953 --> 00:02:51,060
‫Selanjutnya, mari

70
00:02:51,060 --> 00:02:54,310
‫kita lihat hubungan antara tur dan ulasan.

71
00:02:54,310 --> 00:02:56,580
‫Dan yang satu ini sebenarnya sangat mirip.

72
00:02:56,580 --> 00:02:59,450
‫Jadi, sekali lagi, ini adalah hubungan satu-ke-banyak, di

73
00:02:59,450 --> 00:03:02,070
‫mana satu tur dapat memiliki beberapa ulasan

74
00:03:02,070 --> 00:03:05,260
‫tetapi satu ulasan hanya dapat berisi tentang satu tur.

75
00:03:05,260 --> 00:03:06,093
‫Benar?

76
00:03:06,093 --> 00:03:07,810
‫Jadi itu cara yang masuk akal.

77
00:03:07,810 --> 00:03:11,180
‫Dan, jadi, kami sebenarnya akan memodelkannya dengan cara yang sama

78
00:03:11,180 --> 00:03:13,380
‫persis seperti hubungan ulasan pengguna.

79
00:03:13,380 --> 00:03:15,460
‫Jadi, sekali lagi, referensi

80
00:03:15,460 --> 00:03:17,670
‫orang tua, sehingga pada akhirnya ulasan

81
00:03:17,670 --> 00:03:20,530
‫berakhir dengan ID tur dan ID pengguna.

82
00:03:20,530 --> 00:03:23,270
‫Jadi, begitu kami meminta ulasan, kami

83
00:03:23,270 --> 00:03:25,040
‫selalu tahu persis.

84
00:03:25,040 --> 00:03:27,930
‫Bagus, jadi sekarang mari kita bicara tentang

85
00:03:27,930 --> 00:03:30,800
‫hubungan antara tur dan lokasi.

86
00:03:30,800 --> 00:03:32,230
‫Jadi seperti yang

87
00:03:32,230 --> 00:03:35,230
‫saya sebutkan sebelumnya, setiap tur akan memiliki beberapa lokasi.

88
00:03:35,230 --> 00:03:38,680
‫Jadi misalnya, taman kemping pada dasarnya akan berhenti di

89
00:03:38,680 --> 00:03:41,080
‫seperti tiga atau empat taman nasional.

90
00:03:41,080 --> 00:03:43,150
‫Dan, jadi, masing-masing taman nasional ini

91
00:03:43,150 --> 00:03:45,120
‫akan menjadi satu lokasi.

92
00:03:45,120 --> 00:03:45,953
‫Benar?

93
00:03:45,953 --> 00:03:49,700
‫Jadi, setiap tur pada dasarnya memiliki beberapa lokasi.

94
00:03:49,700 --> 00:03:52,730
‫Sekarang, mengikuti contoh itu, salah satu taman nasional

95
00:03:52,730 --> 00:03:55,930
‫ini mungkin juga menjadi bagian dari salah satu wisata lainnya.

96
00:03:55,930 --> 00:03:58,260
‫Jadi, pada dasarnya hubungan

97
00:03:58,260 --> 00:04:00,770
‫ini di sini adalah hubungan sedikit-ke-sedikit.

98
00:04:00,770 --> 00:04:03,630
‫Dan kami menyebut hubungan ini banyak-ke-banyak sebelumnya,

99
00:04:03,630 --> 00:04:06,480
‫tetapi kami masih dapat menyebutnya sedikit-ke-sedikit atau

100
00:04:06,480 --> 00:04:08,910
‫satu ton ke satu ton.

101
00:04:08,910 --> 00:04:10,850
‫Dan, jadi, saya menyebutnya

102
00:04:10,850 --> 00:04:15,290
‫sedikit-ke-sedikit karena setiap tur hanya akan memiliki tiga, empat lokasi

103
00:04:15,290 --> 00:04:17,460
‫tetapi tidak terlalu seperti 100.

104
00:04:17,460 --> 00:04:18,370
‫Oke?

105
00:04:18,370 --> 00:04:21,540
‫Dan, sekali lagi, setiap lokasi juga bisa menjadi bagian

106
00:04:21,540 --> 00:04:23,060
‫dari tur lainnya.

107
00:04:23,060 --> 00:04:26,210
‫Sekarang, ini bisa menjadi contoh yang baik untuk

108
00:04:26,210 --> 00:04:30,670
‫benar-benar menerapkan referensi dua arah, jadi pada dasarnya menormalkan lokasi ke

109
00:04:30,670 --> 00:04:32,480
‫dalam kumpulan datanya sendiri.

110
00:04:32,480 --> 00:04:33,313
‫Benar?

111
00:04:33,313 --> 00:04:36,330
‫Tapi sebaliknya, saya sebenarnya akan mendenormalisasi lokasi

112
00:04:36,330 --> 00:04:39,270
‫untuk memasukkannya ke dalam tur.

113
00:04:39,270 --> 00:04:41,350
‫Dan itu sebenarnya karena berbagai alasan.

114
00:04:41,350 --> 00:04:44,500
‫Pertama, karena hanya ada sedikit lokasi.

115
00:04:44,500 --> 00:04:47,400
‫Juga, kami tidak akan benar-benar mengakses lokasi

116
00:04:47,400 --> 00:04:48,690
‫mereka sendiri.

117
00:04:48,690 --> 00:04:51,890
‫Dan akhirnya, lokasi-lokasi ini secara intrinsik

118
00:04:51,890 --> 00:04:55,400
‫terkait dengan tur karena tanpa lokasi tidak

119
00:04:55,400 --> 00:04:57,280
‫mungkin ada tur.

120
00:04:57,280 --> 00:04:58,113
‫Benar?

121
00:04:58,113 --> 00:05:00,480
‫Jadi kumpulan data ini saling terkait erat.

122
00:05:00,480 --> 00:05:04,030
‫Jadi, saya memilih untuk menyematkan lokasi ke dalam tur dan

123
00:05:04,030 --> 00:05:06,580
‫tidak membuat koleksi lain untuk ini.

124
00:05:06,580 --> 00:05:07,413
‫Benar?

125
00:05:07,413 --> 00:05:10,750
‫Jadi kami akan memiliki satu koleksi untuk tur, satu untuk pengguna,

126
00:05:10,750 --> 00:05:13,330
‫dan sebentar lagi kami juga akan membuat koleksi

127
00:05:13,330 --> 00:05:14,710
‫baru untuk ulasan.

128
00:05:14,710 --> 00:05:15,543
‫Baiklah?

129
00:05:15,543 --> 00:05:18,860
‫Tapi untuk lokasi, sekali lagi, karena ini akan disematkan ke

130
00:05:18,860 --> 00:05:19,793
‫dalam wisata.

131
00:05:20,640 --> 00:05:23,710
‫Oke, dan selanjutnya ada juga hubungan

132
00:05:23,710 --> 00:05:26,250
‫antara tur dan pengguna.

133
00:05:26,250 --> 00:05:28,780
‫Dan itu karena kita akan memiliki

134
00:05:28,780 --> 00:05:33,150
‫pemandu wisata dalam tur, dan pemandu wisata ini sebenarnya akan menjadi pengguna.

135
00:05:33,150 --> 00:05:36,270
‫Jadi ingat bagaimana kami benar-benar memberi pengguna peran dalam

136
00:05:36,270 --> 00:05:37,760
‫skema Mongoose kami?

137
00:05:37,760 --> 00:05:40,770
‫Dan kemungkinan di sana terdapat guide

138
00:05:40,770 --> 00:05:43,020
‫dan lead guide, ingat?

139
00:05:43,020 --> 00:05:44,670
‫Dan, jadi, akan

140
00:05:44,670 --> 00:05:48,210
‫ada hubungan antara jenis pengguna ini dan tur.

141
00:05:48,210 --> 00:05:52,240
‫Sekarang, hubungan ini sekali lagi merupakan hubungan beberapa ke beberapa karena

142
00:05:52,240 --> 00:05:55,550
‫satu tur hanya dapat memiliki beberapa pengguna, jadi

143
00:05:55,550 --> 00:05:58,410
‫beberapa pemandu wisata, tetapi pada saat

144
00:05:58,410 --> 00:06:02,150
‫yang sama, setiap pemandu wisata juga dapat memandu beberapa tur.

145
00:06:02,150 --> 00:06:02,983
‫Baiklah?

146
00:06:02,983 --> 00:06:06,490
‫Dan, sekali lagi, ada hubungan banyak-ke-banyak di sini,

147
00:06:06,490 --> 00:06:09,270
‫yang saya sebut di sini sedikit-ke-sedikit.

148
00:06:09,270 --> 00:06:12,140
‫Sekarang, tentang memodelkan hubungan ini, kita bisa

149
00:06:12,140 --> 00:06:14,410
‫melakukannya dengan dua cara.

150
00:06:14,410 --> 00:06:17,280
‫Kita bisa menggunakan referensi atau embedding.

151
00:06:17,280 --> 00:06:19,620
‫Dan sebenarnya saya akan menunjukkan kepada

152
00:06:19,620 --> 00:06:22,830
‫Anda bagaimana menerapkan kedua penyematan referensi anak menggunakan Mongoose

153
00:06:22,830 --> 00:06:24,410
‫di seluruh bagian ini.

154
00:06:24,410 --> 00:06:25,620
‫Oke?

155
00:06:25,620 --> 00:06:28,800
‫Dan argumen untuk penyematan adalah bahwa dalam hal ini

156
00:06:28,800 --> 00:06:31,930
‫kita kemudian dapat memiliki semua informasi tentang setiap

157
00:06:31,930 --> 00:06:34,310
‫tur yang berisi informasi tentang

158
00:06:34,310 --> 00:06:36,700
‫pemandu wisata tepat di setiap dokumen tur.

159
00:06:36,700 --> 00:06:38,710
‫Tetapi di sisi lain, itu

160
00:06:38,710 --> 00:06:41,120
‫kemudian akan membuat beberapa informasi tambahan

161
00:06:41,120 --> 00:06:43,670
‫dalam database karena kita masih perlu

162
00:06:43,670 --> 00:06:45,210
‫memiliki pengguna sebagai

163
00:06:45,210 --> 00:06:48,700
‫koleksi terpisah hanya karena kita perlu mengaksesnya setiap saat

164
00:06:48,700 --> 00:06:51,250
‫untuk otentikasi dan otorisasi pengguna dan

165
00:06:51,250 --> 00:06:52,510
‫semua itu.

166
00:06:52,510 --> 00:06:56,290
‫Jadi biasanya, pengguna selalu merupakan entitas mereka sendiri di

167
00:06:56,290 --> 00:06:57,700
‫setiap database.

168
00:06:57,700 --> 00:06:58,533
‫Oke?

169
00:06:58,533 --> 00:07:02,380
‫Tapi kami masih bisa menyematkan beberapa pengguna ke dalam tur.

170
00:07:02,380 --> 00:07:04,750
‫Jadi pada dasarnya ketika pengguna adalah pemandu

171
00:07:04,750 --> 00:07:08,190
‫wisata untuk tur tertentu, kami kemudian dapat menyalin semua data

172
00:07:08,190 --> 00:07:09,950
‫ini ke dalam dokumen tur.

173
00:07:09,950 --> 00:07:10,783
‫Oke?

174
00:07:10,783 --> 00:07:14,230
‫Tetapi kami juga harus memperbarui pengguna di tur setiap

175
00:07:14,230 --> 00:07:17,590
‫kali pengguna yang mendasari itu sendiri berubah.

176
00:07:17,590 --> 00:07:19,710
‫Jadi, katakanlah peran pengguna berubah dari

177
00:07:19,710 --> 00:07:21,690
‫pemandu menjadi pemandu utama.

178
00:07:21,690 --> 00:07:24,410
‫Dan dalam hal ini, kami kemudian harus pergi ke

179
00:07:24,410 --> 00:07:26,850
‫tur dan juga memperbarui informasi peran itu di

180
00:07:26,850 --> 00:07:28,840
‫sana pada data yang disematkan.

181
00:07:28,840 --> 00:07:29,673
‫Oke?

182
00:07:29,673 --> 00:07:32,320
‫Dan, jadi, itu tidak ideal, jadi

183
00:07:32,320 --> 00:07:35,350
‫kami sebenarnya juga akan menerapkan referensi anak.

184
00:07:35,350 --> 00:07:37,280
‫Jadi, dengan itu, pada

185
00:07:37,280 --> 00:07:39,590
‫dasarnya kita masih dapat menyimpan informasi

186
00:07:39,590 --> 00:07:42,860
‫tentang pemandu wisata pada pengguna tetapi hanya dalam bentuk

187
00:07:42,860 --> 00:07:44,930
‫referensi, jadi pada dasarnya menyimpan ID

188
00:07:44,930 --> 00:07:47,630
‫di sana, yang kemudian akan mengarah ke pengguna.

189
00:07:47,630 --> 00:07:48,463
‫Oke?

190
00:07:48,463 --> 00:07:51,370
‫Dan tentu saja kami juga dapat menggunakan

191
00:07:51,370 --> 00:07:55,100
‫referensi dua arah, demikian juga dengan menyimpan ID tur pada pengguna.

192
00:07:55,100 --> 00:07:56,650
‫Tapi menurut saya

193
00:07:56,650 --> 00:07:59,140
‫itu terlalu berlebihan untuk contoh kecil

194
00:07:59,140 --> 00:08:02,850
‫seperti ini karena tidak semua pengguna benar-benar membutuhkan ID tur

195
00:08:02,850 --> 00:08:05,580
‫karena tidak semua pengguna adalah pemandu wisata.

196
00:08:05,580 --> 00:08:08,870
‫Dan, jadi, hubungan ini di sini agak sulit untuk dimodelkan,

197
00:08:08,870 --> 00:08:10,800
‫saya pikir, tapi saya percaya

198
00:08:10,800 --> 00:08:14,200
‫bahwa pada akhirnya referensi anak akan menjadi cara terbaik untuk dilakukan.

199
00:08:14,200 --> 00:08:15,033
‫Oke?

200
00:08:15,033 --> 00:08:17,220
‫Tapi tetap saja, saya juga akan

201
00:08:17,220 --> 00:08:20,120
‫menunjukkan embedding karena menurut saya itu juga penting untuk dipelajari.

202
00:08:20,120 --> 00:08:21,400
‫Baiklah?

203
00:08:21,400 --> 00:08:23,530
‫Selanjutnya, kami memiliki pemesanan kami.

204
00:08:23,530 --> 00:08:26,130
‫Dan pada dasarnya pemesanan baru

205
00:08:26,130 --> 00:08:29,340
‫akan dibuat setiap kali pengguna membeli tur.

206
00:08:29,340 --> 00:08:31,340
‫Jadi ini masih semacam hubungan

207
00:08:31,340 --> 00:08:33,240
‫antara pengguna dan

208
00:08:33,240 --> 00:08:36,950
‫tur karena sekali lagi pengguna yang akan membeli tur.

209
00:08:36,950 --> 00:08:38,810
‫Tapi kami juga ingin menyimpan

210
00:08:38,810 --> 00:08:40,920
‫beberapa data tentang hubungan itu sendiri,

211
00:08:40,920 --> 00:08:44,450
‫jadi dalam hal ini tentang pembelian itu sendiri di database kami.

212
00:08:44,450 --> 00:08:46,430
‫Misalnya, harga atau

213
00:08:46,430 --> 00:08:49,560
‫tanggal terjadinya pembelian atau semacamnya.

214
00:08:49,560 --> 00:08:50,810
‫Dan, jadi, dalam

215
00:08:50,810 --> 00:08:53,750
‫kasus seperti ini, ada baiknya untuk membuat kumpulan data

216
00:08:53,750 --> 00:08:55,920
‫tambahan, yang dalam hal ini adalah pemesanan.

217
00:08:55,920 --> 00:08:56,753
‫Oke?

218
00:08:56,753 --> 00:08:58,710
‫Dan, jadi, tentu saja akan

219
00:08:58,710 --> 00:09:02,398
‫ada hubungan antara tur dan pemesanan dan juga pengguna dan pemesanan.

220
00:09:02,398 --> 00:09:06,150
‫Dan, sekali lagi, karena pada dasarnya pemesanan menghubungkan tur

221
00:09:06,150 --> 00:09:09,763
‫dengan pengguna tetapi semacam dengan langkah perantara.

222
00:09:09,763 --> 00:09:12,530
‫Jadi satu tur dapat memiliki banyak pemesanan,

223
00:09:12,530 --> 00:09:15,760
‫tetapi satu pemesanan hanya dapat dimiliki oleh satu tur.

224
00:09:15,760 --> 00:09:17,350
‫Dan hal yang sama dengan pengguna.

225
00:09:17,350 --> 00:09:19,870
‫Jadi satu pengguna dapat memesan banyak

226
00:09:19,870 --> 00:09:23,610
‫tur, tetapi satu pemesanan hanya dapat dimiliki oleh salah satu pengguna.

227
00:09:23,610 --> 00:09:26,380
‫Dan, jadi, tentu saja kami memiliki hubungan satu-ke-banyak

228
00:09:26,380 --> 00:09:29,080
‫dalam kedua kasus, dan juga dalam kedua kasus,

229
00:09:29,080 --> 00:09:31,140
‫kami akan menggunakan referensi induk.

230
00:09:31,140 --> 00:09:33,610
‫Jadi, itu berarti bahwa pada

231
00:09:33,610 --> 00:09:37,640
‫setiap pemesanan kami akan menyimpan ID dari tur yang dibeli

232
00:09:37,640 --> 00:09:40,270
‫dan juga pengguna yang benar-benar membeli tur.

233
00:09:40,270 --> 00:09:41,103
‫Oke?

234
00:09:41,103 --> 00:09:42,930
‫Dan, jadi, dalam hal ini,

235
00:09:42,930 --> 00:09:46,140
‫saya melakukannya karena pada dasarnya saya tidak ingin mengotori

236
00:09:46,140 --> 00:09:49,510
‫data tur dengan informasi tentang siapa yang sebenarnya membeli tur.

237
00:09:49,510 --> 00:09:50,343
‫Benar?

238
00:09:50,343 --> 00:09:53,157
‫Itu tidak akan benar-benar relevan dengan data tur itu sendiri.

239
00:09:53,157 --> 00:09:55,070
‫Dan hal yang sama dengan pengguna.

240
00:09:55,070 --> 00:09:58,370
‫Jadi kami juga tidak ingin mengotori objek pengguna dengan

241
00:09:58,370 --> 00:10:00,740
‫semua pemesanan yang mereka lakukan.

242
00:10:00,740 --> 00:10:01,573
‫Baiklah?

243
00:10:01,573 --> 00:10:03,000
‫Dan, jadi, sebagai

244
00:10:03,000 --> 00:10:05,770
‫gantinya, sekali lagi kita akan membuat objek perantara

245
00:10:05,770 --> 00:10:08,450
‫atau kumpulan data perantara yang akan berdiri

246
00:10:08,450 --> 00:10:12,520
‫di antara pengguna dan tur setiap kali mereka membuat pembelian baru.

247
00:10:12,520 --> 00:10:13,353
‫Benar?

248
00:10:13,353 --> 00:10:14,590
‫Masuk akal?

249
00:10:14,590 --> 00:10:17,520
‫Dan itu sebenarnya untuk model data kami.

250
00:10:17,520 --> 00:10:21,370
‫Dan tentu saja, ini sekarang terlihat agak abstrak, tetapi

251
00:10:21,370 --> 00:10:23,150
‫begitu kita mulai menerapkannya,

252
00:10:23,150 --> 00:10:24,660
‫akan sangat

253
00:10:24,660 --> 00:10:28,730
‫membantu untuk mengatur semua ide kita menjadi sesuatu seperti ini.

254
00:10:28,730 --> 00:10:31,310
‫Jadi setiap kali model data yang akan kita

255
00:10:31,310 --> 00:10:34,560
‫terapkan di seluruh bagian ini menjadi sedikit membingungkan bagi Anda,

256
00:10:34,560 --> 00:10:36,970
‫maka cukup rujuk kembali ke slide ini.

257
00:10:36,970 --> 00:10:39,080
‫Atau Anda bahkan dapat mencetaknya

258
00:10:39,080 --> 00:10:40,980
‫jika itu memudahkan Anda.

259
00:10:40,980 --> 00:10:43,960
‫Jadi ini adalah model data kami secara teori.

260
00:10:43,960 --> 00:10:46,080
‫Dan sekarang sepanjang sisa kursus, saya

261
00:10:46,080 --> 00:10:48,870
‫akan memberi Anda alat untuk benar-benar memodelkan data

262
00:10:48,870 --> 00:10:50,543
‫menggunakan Perpustakaan Mongoose.