1
00:00:01,180 --> 00:00:02,990
‫Narator: Salah satu langkah

2
00:00:02,990 --> 00:00:06,250
‫terpenting dalam membangun aplikasi intensif data adalah benar-benar

3
00:00:06,250 --> 00:00:08,700
‫memodelkan semua data ini di MongoDB.

4
00:00:08,700 --> 00:00:12,300
‫Dan itulah yang akan kita bicarakan dalam kuliah ini.

5
00:00:12,300 --> 00:00:14,710
‫Jadi, sangat penting bagi Anda untuk

6
00:00:14,710 --> 00:00:19,710
‫mengikutinya bahkan pada awalnya banyak yang harus diambil. Baiklah.

7
00:00:19,810 --> 00:00:22,013
‫Bagaimanapun, mari kita mulai sekarang.

8
00:00:23,530 --> 00:00:27,530
‫Sekarang, pemodelan data mungkin merupakan konsep yang sangat baru bagi Anda.

9
00:00:27,530 --> 00:00:28,920
‫Jadi sebelum kita

10
00:00:28,920 --> 00:00:32,070
‫mulai; mari kita perjelas apa yang sebenarnya akan kita bicarakan.

11
00:00:32,070 --> 00:00:35,656
‫Jadi, pemodelan data adalah proses pengambilan data tidak

12
00:00:35,656 --> 00:00:38,770
‫terstruktur yang dihasilkan oleh skenario dunia nyata

13
00:00:38,770 --> 00:00:42,090
‫dan kemudian menyusunnya menjadi model data logis

14
00:00:42,090 --> 00:00:43,410
‫dalam database.

15
00:00:43,410 --> 00:00:46,300
‫Dan kami melakukannya sesuai dengan serangkaian

16
00:00:46,300 --> 00:00:49,330
‫kriteria yang akan kami pelajari di video ini.

17
00:00:49,330 --> 00:00:51,980
‫Sebagai contoh; katakanlah kita ingin merancang

18
00:00:51,980 --> 00:00:54,120
‫model data toko online.

19
00:00:54,120 --> 00:00:57,040
‫Awalnya akan ada satu ton data tidak terstruktur yang kami

20
00:00:57,040 --> 00:00:58,130
‫tahu kami butuhkan.

21
00:00:58,130 --> 00:00:58,980
‫Benar.

22
00:00:58,980 --> 00:01:00,900
‫Barang-barang seperti produk,

23
00:01:00,900 --> 00:01:03,875
‫kategori, pesanan pelanggan, keranjang belanja, pemasok.

24
00:01:03,875 --> 00:01:06,300
‫Dan seterusnya dan seterusnya.

25
00:01:06,300 --> 00:01:09,240
‫Tujuan kami dengan pemodelan data adalah untuk kemudian menyusun

26
00:01:09,240 --> 00:01:11,450
‫data ini menjadi cara yang logis.

27
00:01:11,450 --> 00:01:14,090
‫Mencerminkan hubungan dunia nyata yang

28
00:01:14,090 --> 00:01:16,920
‫ada di antara beberapa kumpulan data ini.

29
00:01:16,920 --> 00:01:19,670
‫Sedikit seperti yang Anda lihat dalam contoh ini.

30
00:01:19,670 --> 00:01:23,110
‫Dan ini tentu saja hanya semacam situasi imajiner tetapi

31
00:01:23,110 --> 00:01:24,320
‫Anda mendapatkan idenya.

32
00:01:24,320 --> 00:01:25,600
‫Benar.

33
00:01:25,600 --> 00:01:28,940
‫Sekarang, banyak pengembang backend mengatakan bahwa pemodelan data adalah hal

34
00:01:28,940 --> 00:01:30,930
‫yang paling kita harus pikirkan.

35
00:01:30,930 --> 00:01:33,670
‫Itu adalah bagian yang paling menuntut dalam

36
00:01:33,670 --> 00:01:35,310
‫membangun seluruh aplikasi.

37
00:01:35,310 --> 00:01:38,100
‫Karena itu benar-benar tidak selalu lurus ke depan.

38
00:01:38,100 --> 00:01:41,070
‫Dan terkadang tidak ada jawaban yang benar.

39
00:01:41,070 --> 00:01:45,500
‫Jadi bukan hanya satu cara unik yang benar untuk menyusun data.

40
00:01:45,500 --> 00:01:48,420
‫Tapi bagaimanapun saya akan melakukan yang terbaik untuk meletakkan proses

41
00:01:48,420 --> 00:01:49,510
‫dalam video ini.

42
00:01:49,510 --> 00:01:52,367
‫Dan untuk itu kita akan melalui empat langkah.

43
00:01:52,367 --> 00:01:56,200
‫Jadi pada langkah pertama; kami belajar tentang bagaimana

44
00:01:56,200 --> 00:01:59,340
‫mengidentifikasi berbagai jenis hubungan antara data.

45
00:01:59,340 --> 00:02:00,360
‫Kemudian

46
00:02:00,360 --> 00:02:03,019
‫kita akan memahami perbedaan antara

47
00:02:03,019 --> 00:02:07,163
‫referensi atau normalisasi dan embedding atau denormalisasi.

48
00:02:07,163 --> 00:02:09,030
‫Pada langkah berikutnya dan

49
00:02:09,030 --> 00:02:11,660
‫yang paling penting; Saya akan menunjukkan kerangka

50
00:02:11,660 --> 00:02:13,560
‫kerja saya untuk memutuskan apakah

51
00:02:13,560 --> 00:02:15,750
‫kita harus menyematkan dokumen atau merujuk

52
00:02:15,750 --> 00:02:18,690
‫ke dokumen lain berdasarkan beberapa faktor yang berbeda.

53
00:02:18,690 --> 00:02:20,810
‫Juga, kita harus cepat berbicara

54
00:02:20,810 --> 00:02:22,680
‫tentang berbagai jenis referensi.

55
00:02:22,680 --> 00:02:25,920
‫Karena itu penting jika itu adalah jenis desain yang

56
00:02:25,920 --> 00:02:28,220
‫kita pilih untuk data kita.

57
00:02:28,220 --> 00:02:32,290
‫Jadi ini sebenarnya akan menjadi kuliah yang cukup teoretis.

58
00:02:32,290 --> 00:02:35,940
‫Tetapi juga sangat penting untuk kemajuan Anda

59
00:02:35,940 --> 00:02:37,660
‫sebagai pengembang back-end.

60
00:02:37,660 --> 00:02:41,553
‫Karena cara kita mendesain data sehingga cara kita memodelkan data

61
00:02:41,553 --> 00:02:45,180
‫kita dapat membuat atau menghancurkan seluruh aplikasi kita.

62
00:02:45,180 --> 00:02:47,950
‫Dan akan ada banyak contoh di sepanjang jalan untuk

63
00:02:47,950 --> 00:02:49,510
‫membuat proses ini lebih mudah.

64
00:02:49,510 --> 00:02:50,343
‫Baiklah.

65
00:02:51,320 --> 00:02:53,440
‫Dan hal pertama yang

66
00:02:53,440 --> 00:02:55,780
‫akan kita bicarakan adalah berbagai jenis

67
00:02:55,780 --> 00:02:58,210
‫hubungan yang ada di antara data.

68
00:02:58,210 --> 00:03:00,780
‫Jadi ada tiga jenis besar hubungan.

69
00:03:00,780 --> 00:03:05,150
‫Satu ke satu, satu ke banyak, dan banyak ke banyak.

70
00:03:05,150 --> 00:03:06,990
‫Dan saya akan menggunakan aplikasi

71
00:03:06,990 --> 00:03:08,890
‫film sebagai contoh di slide ini.

72
00:03:08,890 --> 00:03:10,000
‫Oke?

73
00:03:10,000 --> 00:03:12,440
‫Jadi pertama, hubungan satu ke satu

74
00:03:12,440 --> 00:03:14,140
‫antara data pada dasarnya

75
00:03:14,140 --> 00:03:17,370
‫adalah ketika satu bidang hanya dapat memiliki satu nilai.

76
00:03:17,370 --> 00:03:21,550
‫Jadi dalam contoh aplikasi film kami; satu film hanya pernah

77
00:03:21,550 --> 00:03:22,990
‫memiliki satu nama.

78
00:03:22,990 --> 00:03:24,910
‫Jadi ini adalah contoh

79
00:03:24,910 --> 00:03:27,160
‫sederhana dari hubungan satu lawan satu.

80
00:03:27,160 --> 00:03:29,690
‫Tetapi hubungan ini tidak terlalu penting dalam

81
00:03:29,690 --> 00:03:31,363
‫hal pemodelan data.

82
00:03:32,330 --> 00:03:34,430
‫Sekarang hubungan yang paling

83
00:03:34,430 --> 00:03:37,210
‫penting adalah hubungan satu ke banyak.

84
00:03:37,210 --> 00:03:39,770
‫Dan mereka sangat penting sehingga di

85
00:03:39,770 --> 00:03:42,510
‫MongoDB kami benar-benar membedakan antara tiga jenis

86
00:03:42,510 --> 00:03:44,540
‫hubungan satu ke banyak.

87
00:03:44,540 --> 00:03:49,540
‫Satu ke beberapa, satu ke banyak, dan satu ke satu ton atau ke satu juta

88
00:03:49,910 --> 00:03:53,230
‫atau sesuatu seperti itu. Jadi perbedaan di sini

89
00:03:53,230 --> 00:03:56,893
‫didasarkan pada jumlah relatif banyak. Baiklah.

90
00:03:57,840 --> 00:04:00,969
‫Jadi contoh hubungan satu ke beberapa

91
00:04:00,969 --> 00:04:05,967
‫adalah bahwa satu film dapat memenangkan banyak penghargaan tetapi sebenarnya hanya sedikit.

92
00:04:05,967 --> 00:04:09,630
‫Jadi film tidak akan memenangkan seribu penghargaan tetapi

93
00:04:09,630 --> 00:04:11,220
‫bisa memenangkan beberapa.

94
00:04:11,220 --> 00:04:14,930
‫Jadi ini adalah tipikal hubungan satu ke beberapa.

95
00:04:14,930 --> 00:04:18,710
‫Jadi Anda melihat bahwa secara umum hubungan satu ke

96
00:04:18,710 --> 00:04:23,210
‫banyak berarti bahwa satu dokumen dapat berhubungan dengan banyak dokumen lainnya.

97
00:04:23,210 --> 00:04:26,680
‫Sekarang ini mungkin terlihat agak abstrak tanpa data JSON tetapi

98
00:04:26,680 --> 00:04:28,480
‫sebenarnya itulah tujuannya di sini.

99
00:04:28,480 --> 00:04:31,040
‫Saya hanya ingin menunjukkan gambaran

100
00:04:31,040 --> 00:04:33,759
‫konseptual dari berbagai jenis hubungan ini.

101
00:04:33,759 --> 00:04:36,872
‫Bagaimanapun, setiap hubungan satu ke banyak

102
00:04:36,872 --> 00:04:40,600
‫satu dokumen dapat berhubungan dengan ratusan atau ribuan

103
00:04:40,600 --> 00:04:42,070
‫dokumen lainnya.

104
00:04:42,070 --> 00:04:44,788
‫Sebagai contoh; satu film dapat memiliki ribuan

105
00:04:44,788 --> 00:04:46,710
‫ulasan di aplikasi kami.

106
00:04:46,710 --> 00:04:49,380
‫Jadi ini bukan hubungan satu ke sedikit tetapi

107
00:04:49,380 --> 00:04:51,524
‫satu ke banyak. Oke?

108
00:04:51,524 --> 00:04:55,616
‫Dan akhirnya kami memiliki hubungan satu lawan satu.

109
00:04:55,616 --> 00:04:59,720
‫Bayangkan kami ingin menerapkan beberapa fungsi logging di

110
00:04:59,720 --> 00:05:03,110
‫aplikasi kami. Jadi pada dasarnya untuk tahu

111
00:05:03,110 --> 00:05:04,870
‫persis apa yang terjadi di server kami.

112
00:05:04,870 --> 00:05:08,770
‫Log ini kemudian dapat dengan mudah berkembang menjadi jutaan dokumen.

113
00:05:08,770 --> 00:05:11,270
‫Jadi ini adalah contoh yang

114
00:05:11,270 --> 00:05:14,200
‫sangat khas dari hubungan satu lawan satu.

115
00:05:14,200 --> 00:05:17,100
‫Dan perbedaan antara banyak dan satu ton tentu

116
00:05:17,100 --> 00:05:20,730
‫saja agak kabur tetapi pikirkan saja bahwa jika sesuatu dapat

117
00:05:20,730 --> 00:05:23,360
‫tumbuh hampir tak terbatas maka itu pasti

118
00:05:23,360 --> 00:05:25,532
‫hubungan satu banding satu.

119
00:05:25,532 --> 00:05:28,763
‫Jadi sekali lagi, hubungan satu ke banyak

120
00:05:28,763 --> 00:05:31,650
‫adalah yang paling penting untuk diketahui.

121
00:05:31,650 --> 00:05:34,050
‫Ngomong-ngomong; dalam database

122
00:05:34,050 --> 00:05:37,061
‫relasional hanya ada satu ke banyak

123
00:05:37,061 --> 00:05:39,800
‫tanpa menghitung berapa banyak sebenarnya.

124
00:05:39,800 --> 00:05:41,800
‫Dalam database MongoDB meskipun

125
00:05:41,800 --> 00:05:44,010
‫itu adalah perbedaan yang sangat penting.

126
00:05:44,010 --> 00:05:47,150
‫Karena itu salah satu faktor yang akan kita gunakan

127
00:05:47,150 --> 00:05:49,891
‫untuk memutuskan apakah kita harus mendenormalisasi

128
00:05:49,891 --> 00:05:53,340
‫atau menormalkan data seperti yang akan Anda pelajari nanti.

129
00:05:53,340 --> 00:05:57,181
‫Bagaimanapun, jenis hubungan yang lebih sedikit adalah banyak ke banyak di

130
00:05:57,181 --> 00:06:00,149
‫mana satu film dapat memiliki banyak aktor.

131
00:06:00,149 --> 00:06:04,876
‫Tetapi pada saat yang sama satu aktor dapat bermain di banyak film.

132
00:06:04,876 --> 00:06:07,910
‫Jadi di sini hubungan pada dasarnya

133
00:06:07,910 --> 00:06:09,630
‫berjalan dua arah.

134
00:06:09,630 --> 00:06:11,800
‫Dimana sebelumnya pada tipe yang

135
00:06:11,800 --> 00:06:13,939
‫lain hanya satu arah.

136
00:06:13,939 --> 00:06:17,470
‫Misalnya satu film dapat memiliki banyak ulasan tetapi satu yang

137
00:06:17,470 --> 00:06:22,450
‫spesifik hanya untuk satu film itu. Benar.

138
00:06:22,450 --> 00:06:24,560
‫Dan hal yang sama berlaku untuk penghargaan.

139
00:06:24,560 --> 00:06:27,506
‫Jadi satu penghargaan khusus seperti untuk aktor

140
00:06:27,506 --> 00:06:30,914
‫terbaik hanya diberikan pada satu film, bukan beberapa film.

141
00:06:30,914 --> 00:06:35,580
‫Tapi dengan film dan aktor memang berbeda.

142
00:06:35,580 --> 00:06:39,250
‫Jadi sekali lagi satu film dibintangi banyak aktor tetapi

143
00:06:39,250 --> 00:06:41,920
‫satu aktor memainkan banyak film

144
00:06:41,920 --> 00:06:45,020
‫dan begitu banyak hubungan banyak ke banyak.

145
00:06:45,020 --> 00:06:46,170
‫Oke.

146
00:06:46,170 --> 00:06:49,060
‫Jadi ingatlah semua ini saat kita bergerak maju dalam

147
00:06:49,060 --> 00:06:50,063
‫kuliah ini.

148
00:06:51,760 --> 00:06:54,870
‫Dan mungkin aspek terpenting yang perlu kita

149
00:06:54,870 --> 00:06:57,900
‫pelajari tentang database MongoDB adalah mereferensikan dan

150
00:06:57,900 --> 00:07:00,340
‫menyematkan dua kumpulan data.

151
00:07:00,340 --> 00:07:02,350
‫Dan kami sebenarnya sudah membicarakan

152
00:07:02,350 --> 00:07:05,050
‫sedikit tentang ini sebelumnya, tetapi mari kita tinjau

153
00:07:05,050 --> 00:07:07,311
‫di sini dan masuk lebih dalam juga.

154
00:07:07,311 --> 00:07:09,962
‫Jadi setiap kali kami memiliki dua

155
00:07:09,962 --> 00:07:13,829
‫kumpulan data terkait, kami dapat mewakili data terkait itu

156
00:07:13,829 --> 00:07:18,829
‫dalam bentuk referensi atau dinormalisasi atau dalam bentuk yang disematkan atau didenormalisasi.

157
00:07:18,842 --> 00:07:22,190
‫Dan saya terus menggunakan dua istilah terkait bersama-sama

158
00:07:22,190 --> 00:07:24,340
‫seperti referensi dan normalisasi karena

159
00:07:24,340 --> 00:07:26,460
‫Anda akan melihat keduanya

160
00:07:26,460 --> 00:07:29,510
‫digunakan dan penting bagi Anda untuk mengetahui semuanya.

161
00:07:29,510 --> 00:07:33,070
‫Bagaimanapun, dalam formulir yang direferensikan, kami menyimpan dua kumpulan

162
00:07:33,070 --> 00:07:35,826
‫data terkait dan semua dokumen terpisah.

163
00:07:35,826 --> 00:07:39,589
‫Jadi sekali lagi semua data dipisahkan

164
00:07:39,589 --> 00:07:43,275
‫dengan baik, itulah artinya dinormalisasi.

165
00:07:43,275 --> 00:07:47,110
‫Jadi melanjutkan, contoh database film dari sebelumnya kita akan

166
00:07:47,110 --> 00:07:50,750
‫memiliki satu dokumen film dan satu dokumen aktor

167
00:07:50,750 --> 00:07:54,870
‫untuk setiap aktor. Sekarang bagaimana kita membuat hubungan

168
00:07:54,870 --> 00:07:58,710
‫antara film dan aktor sehingga nanti di aplikasi kita, kita

169
00:07:58,710 --> 00:08:02,150
‫dapat menunjukkan aktor mana yang bermain dalam film tertentu.

170
00:08:02,150 --> 00:08:05,210
‫Karena jika mereka semua dokumen yang sama sekali berbeda, film tidak

171
00:08:05,210 --> 00:08:09,438
‫memiliki cara untuk mengetahui tentang para aktor. Benar.

172
00:08:09,438 --> 00:08:12,253
‫Nah di situlah ID masuk.

173
00:08:12,253 --> 00:08:16,460
‫Jadi kami menggunakan ID aktor untuk membuat referensi pada

174
00:08:16,460 --> 00:08:18,020
‫dokumen film.

175
00:08:18,020 --> 00:08:20,981
‫Secara efektif menghubungkan film dengan aktor.

176
00:08:20,981 --> 00:08:24,760
‫Jadi Anda melihat bahwa dalam dokumen film kami memiliki larik

177
00:08:24,760 --> 00:08:27,198
‫tempat kami menyimpan ID semua aktor

178
00:08:27,198 --> 00:08:30,760
‫sehingga ketika kami meminta data tentang film tertentu, kami dapat

179
00:08:30,760 --> 00:08:34,553
‫dengan mudah mengidentifikasi aktornya. Apakah itu masuk akal?

180
00:08:34,553 --> 00:08:38,830
‫Sekarang jenis referensi ini disebut referensi anak karena

181
00:08:38,830 --> 00:08:41,480
‫induknya dalam hal ini film

182
00:08:41,480 --> 00:08:45,104
‫yang merujuk anak-anaknya. Dalam hal ini para aktor.

183
00:08:45,104 --> 00:08:48,841
‫Jadi kami benar-benar membuat semacam hierarki di sini. Benar.

184
00:08:48,841 --> 00:08:51,870
‫Sekarang ada juga referensi orang tua dan

185
00:08:51,870 --> 00:08:54,390
‫kita akan membicarakannya nanti.

186
00:08:54,390 --> 00:08:58,710
‫Dan omong-omong dalam database relasional; semua data selalu

187
00:08:58,710 --> 00:09:01,958
‫direpresentasikan dalam bentuk normal seperti ini.

188
00:09:01,958 --> 00:09:05,490
‫Tetapi dalam database tanpa sekuel seperti MongoDB,

189
00:09:05,490 --> 00:09:09,700
‫kita dapat mendenormalisasi data menjadi bentuk yang didenormalisasi

190
00:09:09,700 --> 00:09:12,450
‫hanya dengan menyematkan dokumen

191
00:09:12,450 --> 00:09:15,330
‫terkait langsung ke dokumen utama.

192
00:09:15,330 --> 00:09:18,330
‫Jadi sekarang kami memiliki semua data

193
00:09:18,330 --> 00:09:22,060
‫yang relevan tentang aktor di dalam satu dokumen film

194
00:09:22,060 --> 00:09:25,700
‫utama tanpa memerlukan dokumen, koleksi, dan ID terpisah.

195
00:09:25,700 --> 00:09:30,088
‫Jadi sekali lagi, jika kita memilih untuk mendenormalisasi atau menyematkan data kita,

196
00:09:30,088 --> 00:09:34,280
‫kita akan memiliki satu dokumen utama yang berisi semua data utama

197
00:09:34,280 --> 00:09:37,197
‫serta data terkait. Baiklah.

198
00:09:37,197 --> 00:09:40,340
‫Dan hasilnya adalah aplikasi kita akan membutuhkan

199
00:09:40,340 --> 00:09:43,330
‫lebih sedikit query ke database.

200
00:09:43,330 --> 00:09:45,000
‫Karena kita bisa

201
00:09:45,000 --> 00:09:48,074
‫mendapatkan semua data tentang film dan

202
00:09:48,074 --> 00:09:51,650
‫aktor sekaligus yang tentunya akan meningkatkan performa kita.

203
00:09:51,650 --> 00:09:53,840
‫Sekarang kelemahannya di sini adalah

204
00:09:53,840 --> 00:09:57,530
‫tentu saja kita tidak dapat benar-benar menanyakan data yang disematkan sendiri.

205
00:09:57,530 --> 00:10:00,810
‫Jadi jika itu adalah persyaratan untuk aplikasi, Anda harus

206
00:10:00,810 --> 00:10:03,790
‫memilih desain yang dinormalisasi dan karena kita berbicara

207
00:10:03,790 --> 00:10:06,280
‫tentang pro dan kontra dari bentuk

208
00:10:06,280 --> 00:10:09,030
‫yang dinormalisasi; mari kita lakukan hal yang

209
00:10:09,030 --> 00:10:11,490
‫sama tentang desain yang dinormalisasi.

210
00:10:11,490 --> 00:10:13,920
‫Dan pada dasarnya kebalikan dari apa yang

211
00:10:13,920 --> 00:10:15,770
‫baru saja kita bicarakan.

212
00:10:15,770 --> 00:10:18,319
‫Jadi ada peningkatan kinerja ketika

213
00:10:18,319 --> 00:10:22,390
‫kita sering perlu meng-query data terkait itu sendiri karena kita

214
00:10:22,390 --> 00:10:25,740
‫hanya bisa meng-query data yang kita butuhkan dan

215
00:10:25,740 --> 00:10:28,490
‫tidak selalu film dan aktor bersama-sama.

216
00:10:28,490 --> 00:10:31,640
‫Tetapi di sisi lain; ketika kita perlu benar-benar

217
00:10:31,640 --> 00:10:33,906
‫menanyakan film dan aktor bersama-sama,

218
00:10:33,906 --> 00:10:36,396
‫kita akan membutuhkan banyak pertanyaan ke database.

219
00:10:36,396 --> 00:10:40,010
‫Jadi pertama-tama kueri untuk film dan kemudian dari sana kita

220
00:10:40,010 --> 00:10:42,610
‫juga akan membutuhkan kueri untuk aktor dan

221
00:10:42,610 --> 00:10:44,989
‫itu tentu saja berfungsi untuk kinerja.

222
00:10:44,989 --> 00:10:48,328
‫Jadi saat mendesain database Anda; ini adalah jenis hal yang

223
00:10:48,328 --> 00:10:50,569
‫perlu Anda ingat. Baiklah.

224
00:10:50,569 --> 00:10:54,900
‫Dan sekarang hanya sebagai catatan tambahan; kita tentu saja dapat memulai proses

225
00:10:54,900 --> 00:10:56,994
‫berpikir kita dengan data yang didenormalisasi

226
00:10:56,994 --> 00:10:59,670
‫dan kemudian sampai pada kesimpulan bahwa yang terbaik

227
00:10:59,670 --> 00:11:01,692
‫adalah benar-benar menormalkan data.

228
00:11:01,692 --> 00:11:05,043
‫Jadi ketika memikirkan model data kami, cara mengatur

229
00:11:05,043 --> 00:11:08,378
‫data ini bekerja dengan dua cara.

230
00:11:08,378 --> 00:11:12,570
‫Sekarang, bagaimana kita benar-benar memutuskan apakah kita harus

231
00:11:12,570 --> 00:11:15,330
‫menormalkan atau mendenormalisasi data?

232
00:11:15,330 --> 00:11:18,033
‫Nah itulah yang akan kita pelajari selanjutnya.

233
00:11:19,690 --> 00:11:22,974
‫Jadi ketika kita memiliki dua dataset terkait; kita harus memutuskan

234
00:11:22,974 --> 00:11:26,180
‫apakah kita akan menyematkan kumpulan data atau apakah kita akan

235
00:11:26,180 --> 00:11:27,693
‫memisahkannya dan merujuknya

236
00:11:27,693 --> 00:11:30,400
‫dari satu kumpulan data ke kumpulan data lainnya.

237
00:11:30,400 --> 00:11:32,730
‫Dan saya mengembangkan kerangka keputusan ini yang

238
00:11:32,730 --> 00:11:36,070
‫akan saya tunjukkan kepada Anda di mana kami menggunakan tiga

239
00:11:36,070 --> 00:11:37,770
‫kriteria untuk mengambil keputusan itu.

240
00:11:37,770 --> 00:11:40,450
‫Pertama kita melihat jenis hubungan yang

241
00:11:40,450 --> 00:11:42,800
‫ada di antara kumpulan data.

242
00:11:42,800 --> 00:11:45,856
‫Kedua, kami mencoba menentukan pola akses

243
00:11:45,856 --> 00:11:50,150
‫data dari kumpulan data yang ingin kami sematkan atau referensikan.

244
00:11:50,150 --> 00:11:53,320
‫Dan ini hanya berarti menganalisis seberapa sering data dibaca dan

245
00:11:53,320 --> 00:11:55,282
‫ditulis dalam kumpulan data itu.

246
00:11:55,282 --> 00:11:59,025
‫Kemudian kita juga melihat sesuatu yang saya sebut kedekatan data.

247
00:11:59,025 --> 00:12:02,940
‫Dan kedekatan data adalah istilah yang sebenarnya baru saja saya

248
00:12:02,940 --> 00:12:06,870
‫buat tetapi yang dimaksud adalah seberapa banyak data yang benar-benar terkait

249
00:12:06,870 --> 00:12:10,109
‫dan bagaimana kita ingin meng-query data dari database.

250
00:12:10,109 --> 00:12:11,850
‫Dan ini akan lebih

251
00:12:11,850 --> 00:12:14,180
‫masuk akal ketika kita membicarakannya sebentar lagi.

252
00:12:14,180 --> 00:12:17,330
‫Sekarang untuk benar-benar mengambil keputusan; kita perlu menggabungkan

253
00:12:17,330 --> 00:12:19,350
‫ketiga kriteria ini dan

254
00:12:19,350 --> 00:12:21,792
‫tidak hanya menggunakan salah satunya secara terpisah.

255
00:12:21,792 --> 00:12:25,230
‫Jadi misalnya; Hanya karena kriteria nomor satu mengatakan

256
00:12:25,230 --> 00:12:28,380
‫untuk menyematkan bukan berarti kita tidak perlu

257
00:12:28,380 --> 00:12:30,425
‫melihat dua kriteria lainnya.

258
00:12:30,425 --> 00:12:34,124
‫Baiklah dan mari kita mulai dengan tipe hubungan.

259
00:12:34,124 --> 00:12:37,968
‫Jadi biasanya ketika kita memiliki hubungan satu ke beberapa kita

260
00:12:37,968 --> 00:12:40,700
‫akan selalu menyematkan dataset terkait ke dalam

261
00:12:40,700 --> 00:12:43,430
‫dataset utama seperti yang kita pelajari di

262
00:12:43,430 --> 00:12:45,860
‫slide terakhir. Benar.

263
00:12:45,860 --> 00:12:49,110
‫Sekarang dalam hubungan satu ke banyak; hal-hal

264
00:12:49,110 --> 00:12:52,880
‫sedikit lebih kabur jadi tidak apa-apa untuk menanamkan atau referensi.

265
00:12:52,880 --> 00:12:55,140
‫Dalam hal ini kita harus memutuskan

266
00:12:55,140 --> 00:12:57,304
‫sesuai dengan dua kriteria lainnya.

267
00:12:57,304 --> 00:12:59,825
‫Sekarang di sisi lain, pada satu

268
00:12:59,825 --> 00:13:03,894
‫ke satu ton atau banyak ke banyak hubungan kita biasanya

269
00:13:03,894 --> 00:13:06,811
‫selalu referensi data. Itu karena jika kita benar-benar

270
00:13:06,811 --> 00:13:10,004
‫melakukan embed dalam kasus ini kita bisa dengan cepat membuat dokumen yang terlalu besar.

271
00:13:10,004 --> 00:13:14,902
‫Bahkan berpotensi melebihi maksimal 16 megabyte.

272
00:13:14,902 --> 00:13:18,214
‫Jadi solusi untuk itu tentu saja merujuk

273
00:13:18,214 --> 00:13:22,090
‫atau menormalkan data. Dan sebagai contoh cepat;

274
00:13:22,090 --> 00:13:24,142
‫katakanlah dalam contoh database film kami,

275
00:13:24,142 --> 00:13:27,830
‫kami memiliki sekitar 100 gambar yang terkait dengan setiap film.

276
00:13:27,830 --> 00:13:30,874
‫Jadi kita bisa mengatakan ini adalah hubungan satu

277
00:13:30,874 --> 00:13:34,230
‫ke banyak tetapi apakah kita akan menyematkan dataset atau haruskah

278
00:13:34,230 --> 00:13:37,523
‫kita merujuknya di sini. Yah kita tidak benar-benar tahu.

279
00:13:37,523 --> 00:13:40,571
‫Jadi mari kita lihat dua kriteria lainnya.

280
00:13:40,571 --> 00:13:44,420
‫Jadi yang kedua adalah tentang pola akses data di mana

281
00:13:44,420 --> 00:13:46,290
‫itu hanya deskripsi mewah

282
00:13:46,290 --> 00:13:48,242
‫untuk mengevaluasi apakah kumpulan data

283
00:13:48,242 --> 00:13:51,559
‫tertentu sebagian besar ditulis atau sebagian besar dibaca.

284
00:13:51,559 --> 00:13:55,760
‫Jadi, jika kumpulan data yang kita putuskan kebanyakan dibaca dan

285
00:13:55,760 --> 00:13:58,179
‫datanya tidak banyak diperbarui,

286
00:13:58,179 --> 00:14:01,620
‫maka kita mungkin harus menyematkan kumpulan data itu.

287
00:14:01,620 --> 00:14:04,690
‫Jadi rasio baca/tulis yang tinggi hanya berarti bahwa

288
00:14:04,690 --> 00:14:07,100
‫ada lebih banyak membaca daripada menulis.

289
00:14:07,100 --> 00:14:11,100
‫Dan sekali lagi, kumpulan data seperti itu adalah kandidat yang baik

290
00:14:11,100 --> 00:14:11,983
‫untuk disematkan.

291
00:14:12,830 --> 00:14:15,980
‫Alasan untuk ini adalah bahwa dengan menyematkan kita hanya perlu

292
00:14:15,980 --> 00:14:18,379
‫satu perjalanan ke database per kueri.

293
00:14:18,379 --> 00:14:22,197
‫Sedangkan untuk referensi kita membutuhkan dua perjalanan. Benar.

294
00:14:22,197 --> 00:14:25,660
‫Jadi jika kita menyematkan data yang banyak dibaca;

295
00:14:25,660 --> 00:14:28,383
‫di setiap kueri, kami menyimpan satu

296
00:14:28,383 --> 00:14:32,147
‫perjalanan ke database yang membuat seluruh proses lebih berkinerja.

297
00:14:32,147 --> 00:14:35,260
‫Jadi saya pikir contoh gambar film kita sebenarnya

298
00:14:35,260 --> 00:14:38,320
‫akan menjadi kandidat yang baik untuk disematkan.

299
00:14:38,320 --> 00:14:41,543
‫Karena setelah 100 gambar disimpan ke database,

300
00:14:41,543 --> 00:14:43,920
‫mereka tidak benar-benar diperbarui lagi

301
00:14:43,920 --> 00:14:46,930
‫karena sebenarnya tidak ada yang perlu diperbarui

302
00:14:46,930 --> 00:14:50,057
‫tentang suatu gambar. Benar, jadi ini

303
00:14:50,057 --> 00:14:52,563
‫semua tentang membaca dan karena itu berdasarkan

304
00:14:52,563 --> 00:14:55,501
‫kriteria ini kami akan menyematkan dokumen yang dicitrakan.

305
00:14:55,501 --> 00:14:59,092
‫Sekarang di sisi lain, jika data kita banyak

306
00:14:59,092 --> 00:15:03,118
‫diperbarui maka kita harus mempertimbangkan untuk mereferensikan atau menormalkan data.

307
00:15:03,118 --> 00:15:06,700
‫Itu karena lebih banyak pekerjaan untuk mesin database untuk

308
00:15:06,700 --> 00:15:08,870
‫memperbarui dan menyematkan dokumen

309
00:15:08,870 --> 00:15:11,600
‫daripada dokumen mandiri yang lebih sederhana.

310
00:15:11,600 --> 00:15:13,980
‫Dan karena tujuan utama kami adalah kinerja;

311
00:15:13,980 --> 00:15:15,917
‫kami hanya menormalkan dataset.

312
00:15:15,917 --> 00:15:19,653
‫Dalam contoh kami, katakanlah setiap film memiliki banyak ulasan dan

313
00:15:19,653 --> 00:15:23,284
‫setiap ulasan dapat ditandai sebagai bermanfaat oleh pengguna.

314
00:15:23,284 --> 00:15:27,560
‫Jadi setiap kali seseorang mengklik ulasan ini sangat membantu dalam

315
00:15:27,560 --> 00:15:29,780
‫aplikasi kami. Kami

316
00:15:29,780 --> 00:15:31,740
‫perlu memperbarui dokumen terkait.

317
00:15:31,740 --> 00:15:35,030
‫Dan ini berarti bahwa data dapat berubah sepanjang

318
00:15:35,030 --> 00:15:38,520
‫waktu dan ini adalah kandidat yang bagus untuk normalisasi.

319
00:15:38,520 --> 00:15:41,420
‫Sekali lagi karena kami tidak ingin selalu

320
00:15:41,420 --> 00:15:45,190
‫menanyakan film jika yang benar-benar ingin kami perbarui adalah ulasan

321
00:15:45,190 --> 00:15:47,230
‫dengan menandainya sebagai bermanfaat.

322
00:15:47,230 --> 00:15:49,464
‫Oke, apakah itu masuk akal?

323
00:15:49,464 --> 00:15:53,500
‫Dan terakhir kriteria terakhir yang saya sebut kedekatan data;

324
00:15:53,500 --> 00:15:56,320
‫yang seperti ukuran untuk seberapa banyak

325
00:15:56,320 --> 00:15:59,469
‫data terkait. Jadi, jika dua

326
00:15:59,469 --> 00:16:02,890
‫set data benar-benar dimiliki bersama, maka mereka

327
00:16:02,890 --> 00:16:05,880
‫mungkin harus disematkan satu sama lain.

328
00:16:05,880 --> 00:16:10,440
‫Dalam contoh kita; semua pengguna dapat memiliki banyak alamat email

329
00:16:10,440 --> 00:16:13,780
‫di akun mereka dan karena mereka secara

330
00:16:13,780 --> 00:16:17,190
‫intrinsik terhubung dengan pengguna, tidak diragukan lagi email

331
00:16:17,190 --> 00:16:19,920
‫harus disematkan ke dalam dokumen.

332
00:16:19,920 --> 00:16:23,830
‫Sekarang jika kita sering perlu mengkueri kedua kumpulan data sendiri,

333
00:16:23,830 --> 00:16:26,388
‫maka itu adalah alasan yang sangat

334
00:16:26,388 --> 00:16:29,696
‫baik untuk menormalkan data menjadi dua kumpulan data terpisah.

335
00:16:29,696 --> 00:16:32,790
‫Bahkan jika mereka terkait erat.

336
00:16:32,790 --> 00:16:35,227
‫Jadi bayangkan bahwa di aplikasi

337
00:16:35,227 --> 00:16:40,227
‫kami, kami memiliki kuis di mana pengguna harus mengidentifikasi film berdasarkan gambar.

338
00:16:40,440 --> 00:16:43,080
‫Ini berarti bahwa kita akan meminta banyak

339
00:16:43,080 --> 00:16:44,180
‫gambar sendiri.

340
00:16:44,180 --> 00:16:47,756
‫Jadi tanpa harus menanyakan film itu sendiri.

341
00:16:47,756 --> 00:16:50,640
‫Jadi jika kita menerapkan kriteria ketiga ini;

342
00:16:50,640 --> 00:16:54,137
‫kami sampai pada kesimpulan bahwa kami harus benar-benar menormalkan

343
00:16:54,137 --> 00:16:56,759
‫dataset gambar. Baiklah.

344
00:16:56,759 --> 00:17:00,770
‫Karena sekali lagi jika kita menerapkan fungsi kuis ini;

345
00:17:00,770 --> 00:17:04,057
‫gambar akan ditanyai sendiri sepanjang waktu.

346
00:17:04,057 --> 00:17:07,422
‫Jadi, semua ini menunjukkan bahwa kita harus benar-benar

347
00:17:07,422 --> 00:17:09,850
‫melihat ketiga kriteria tersebut bersama-sama

348
00:17:09,850 --> 00:17:12,700
‫daripada hanya satu dari mereka secara terpisah.

349
00:17:12,700 --> 00:17:15,841
‫Karena hal itu dapat mengakibatkan keputusan yang kurang optimal.

350
00:17:15,841 --> 00:17:18,908
‫Dan saya katakan kurang optimal bukannya

351
00:17:18,908 --> 00:17:21,766
‫salah karena tidak sepenuhnya benar

352
00:17:21,766 --> 00:17:25,262
‫atau sepenuhnya salah cara memodelkan data kita.

353
00:17:25,262 --> 00:17:28,970
‫Tidak ada aturan yang sulit; ini seperti panduan yang dapat

354
00:17:28,970 --> 00:17:31,380
‫Anda ikuti untuk menemukan cara

355
00:17:31,380 --> 00:17:33,860
‫yang paling benar dalam menyusun data Anda.

356
00:17:33,860 --> 00:17:37,077
‫Tapi sekali lagi, sulit untuk benar-benar salah.

357
00:17:37,077 --> 00:17:38,253
‫Oke?

358
00:17:39,740 --> 00:17:43,110
‫Sekarang, katakanlah kita telah memilih untuk menormalkan

359
00:17:43,110 --> 00:17:44,270
‫dataset kita.

360
00:17:44,270 --> 00:17:46,653
‫Jadi dengan kata lain untuk referensi data.

361
00:17:46,653 --> 00:17:49,380
‫Kemudian setelah itu kita masih harus

362
00:17:49,380 --> 00:17:52,840
‫memilih di antara tiga jenis referensi yang berbeda.

363
00:17:52,840 --> 00:17:55,460
‫Referensi anak, referensi orang tua, dan

364
00:17:55,460 --> 00:17:57,540
‫referensi dua arah.

365
00:17:57,540 --> 00:18:00,767
‫Jadi tipe pertama adalah referensi anak.

366
00:18:00,767 --> 00:18:04,440
‫Yang merupakan tipe referensi yang sebenarnya saya tunjukkan sebelumnya.

367
00:18:04,440 --> 00:18:05,470
‫Oke?

368
00:18:05,470 --> 00:18:07,850
‫Dan jangan mengambil contoh kesalahan logging yang

369
00:18:07,850 --> 00:18:10,128
‫saya sebutkan sebelumnya. Di mana

370
00:18:10,128 --> 00:18:13,021
‫kita berpotensi memiliki jutaan dokumen yang terkunci.

371
00:18:13,021 --> 00:18:17,300
‫Jadi dalam referensi anak; kami pada dasarnya menyimpan referensi ke

372
00:18:17,300 --> 00:18:20,460
‫dokumen anak terkait dalam dokumen induk.

373
00:18:20,460 --> 00:18:22,941
‫Dan mereka biasanya disimpan dalam array.

374
00:18:22,941 --> 00:18:25,735
‫Jadi Anda melihat bahwa setiap log memiliki ID

375
00:18:25,735 --> 00:18:29,040
‫dan kemudian di dokumen aplikasi ada larik dengan semua

376
00:18:29,040 --> 00:18:31,358
‫ID ini. Benar?

377
00:18:31,358 --> 00:18:34,400
‫Namun, masalahnya di sini adalah array

378
00:18:34,400 --> 00:18:39,320
‫ID ini bisa menjadi sangat besar jika ada banyak anak.

379
00:18:39,320 --> 00:18:42,230
‫Dan ini adalah anti-pola di MongoDB.

380
00:18:42,230 --> 00:18:45,156
‫Jadi sesuatu yang kita harus menghindari di semua biaya.

381
00:18:45,156 --> 00:18:47,660
‫Juga, referensi anak membuat

382
00:18:47,660 --> 00:18:51,410
‫orang tua dan anak menjadi sangat erat.

383
00:18:51,410 --> 00:18:54,840
‫Yang tidak selalu ideal. Tapi itulah mengapa

384
00:18:54,840 --> 00:18:57,020
‫kami memiliki referensi orang tua.

385
00:18:57,020 --> 00:19:00,300
‫Jadi dalam referensi orang tua; itu benar-benar

386
00:19:00,300 --> 00:19:01,870
‫bekerja sebaliknya.

387
00:19:01,870 --> 00:19:05,570
‫Jadi di sini, di setiap dokumen anak, kami menyimpan

388
00:19:05,570 --> 00:19:07,430
‫referensi ke elemen induk.

389
00:19:07,430 --> 00:19:10,267
‫Oleh karena itu referensi nama orang tua.

390
00:19:10,267 --> 00:19:13,890
‫Dalam contoh ini ID aplikasi adalah 23 dan

391
00:19:13,890 --> 00:19:16,640
‫di setiap log ada bidang aplikasi

392
00:19:16,640 --> 00:19:18,990
‫dengan 23 ID di dalamnya.

393
00:19:18,990 --> 00:19:21,660
‫Agar anak selalu mengenal orang tuanya.

394
00:19:21,660 --> 00:19:24,920
‫Jadi dalam hal ini orang tua sebenarnya tidak tahu

395
00:19:24,920 --> 00:19:26,080
‫apa-apa tentang anak-anak.

396
00:19:26,080 --> 00:19:28,768
‫Bukan siapa mereka dan bukan berapa banyak mereka.

397
00:19:28,768 --> 00:19:32,890
‫Jadi, mereka jauh lebih terisolasi dan lebih mandiri.

398
00:19:32,890 --> 00:19:35,326
‫Dalam hal itu, terkadang bisa bermanfaat.

399
00:19:35,326 --> 00:19:38,880
‫Jadi mana dari kedua jenis ini yang sebenarnya lebih baik

400
00:19:38,880 --> 00:19:40,527
‫untuk hubungan data ini.

401
00:19:40,527 --> 00:19:42,820
‫Dan ingat bagaimana saya mengatakan bahwa

402
00:19:42,820 --> 00:19:45,860
‫mungkin ada jutaan log dan jadi anggaplah ada dua

403
00:19:45,860 --> 00:19:47,652
‫juta dokumen yang dicatat.

404
00:19:47,652 --> 00:19:51,340
‫Dalam kasus referensi anak, itu berarti ada

405
00:19:51,340 --> 00:19:53,209
‫dua juta referensi

406
00:19:53,209 --> 00:19:55,091
‫ID dalam dokumen aplikasi.

407
00:19:55,091 --> 00:19:58,300
‫Benar? Sekarang juga ingat bagaimana saya

408
00:19:58,300 --> 00:20:00,545
‫mengatakan bahwa ada batas 16 megabyte pada dokumen.

409
00:20:00,545 --> 00:20:04,302
‫Jadi jika kita terus menambahkan dan menambahkan ID anak ini ke

410
00:20:04,302 --> 00:20:06,716
‫dalam larik pada induknya; maka kita akan

411
00:20:06,716 --> 00:20:09,575
‫dengan cepat mencapai batas 16 megabyte yang dapat

412
00:20:09,575 --> 00:20:11,772
‫ditampung oleh setiap dokumen Bson.

413
00:20:11,772 --> 00:20:14,702
‫Hanya karena array itu akan tumbuh begitu banyak.

414
00:20:14,702 --> 00:20:17,210
‫Jadi itu tidak akan berhasil.

415
00:20:17,210 --> 00:20:18,510
‫Apakah itu?

416
00:20:18,510 --> 00:20:20,590
‫Di sisi lain dengan referensi

417
00:20:20,590 --> 00:20:22,990
‫orang tua masalah itu tidak akan terjadi.

418
00:20:22,990 --> 00:20:25,570
‫Kami hanya akan memiliki dua

419
00:20:25,570 --> 00:20:30,540
‫juta dokumen terkunci seperti sebelumnya tetapi masing-masing memegang ID induknya.

420
00:20:30,540 --> 00:20:33,098
‫Tetapi tidak ada array yang akan

421
00:20:33,098 --> 00:20:35,740
‫tumbuh tanpa batas dan oleh karena itu referensi

422
00:20:35,740 --> 00:20:38,443
‫orang tua akan menjadi solusi terbaik di sini.

423
00:20:39,380 --> 00:20:41,901
‫Jadi kesimpulan dari semua ini adalah bahwa secara

424
00:20:41,901 --> 00:20:44,385
‫umum referensi anak paling baik digunakan untuk

425
00:20:44,385 --> 00:20:48,008
‫satu atau beberapa hubungan. Di mana kita tahu

426
00:20:48,008 --> 00:20:51,118
‫sebelumnya bahwa susunan dokumen anak tidak akan bertambah banyak.

427
00:20:51,118 --> 00:20:54,573
‫Di sisi lain, referensi orang tua paling baik digunakan

428
00:20:54,573 --> 00:20:58,690
‫untuk hubungan satu ke banyak dan satu ke satu ton

429
00:20:58,690 --> 00:21:00,927
‫seperti ini. Oke?

430
00:21:00,927 --> 00:21:04,610
‫Jadi sekali lagi, selalu ingat bahwa salah satu

431
00:21:04,610 --> 00:21:07,920
‫prinsip terpenting dari pemodelan data MongoDB

432
00:21:07,920 --> 00:21:11,900
‫adalah bahwa array tidak boleh dibiarkan tumbuh tanpa batas.

433
00:21:11,900 --> 00:21:15,420
‫Agar tidak pernah melanggar batas 16 megabyte itu.

434
00:21:15,420 --> 00:21:18,170
‫Kami juga tidak ingin mengirimi pengguna kami

435
00:21:18,170 --> 00:21:20,730
‫array dengan ribuan ID setiap kali mereka

436
00:21:20,730 --> 00:21:24,340
‫meminta kumpulan data induk. Oke?

437
00:21:24,340 --> 00:21:26,900
‫Jadi, apakah logika ini masuk akal bagi Anda?

438
00:21:26,900 --> 00:21:29,660
‫Kemudian mari kita beralih ke jenis referensi ketiga

439
00:21:29,660 --> 00:21:31,870
‫yang merupakan referensi dua arah.

440
00:21:31,870 --> 00:21:34,395
‫Dan kali ini dengan contoh film dan aktor yang

441
00:21:34,395 --> 00:21:36,380
‫saya tunjukkan kepada Anda ketika kita berbicara

442
00:21:36,380 --> 00:21:39,364
‫tentang banyak ke banyak hubungan. Ingat itu?

443
00:21:39,364 --> 00:21:42,229
‫Jadi sekali lagi, setiap film memiliki banyak aktor

444
00:21:42,229 --> 00:21:44,880
‫dan setiap aktor bermain di banyak film.

445
00:21:44,880 --> 00:21:48,464
‫Dan itulah tipikal hubungan banyak ke banyak.

446
00:21:48,464 --> 00:21:52,100
‫Dan kami biasanya menggunakan referensi dua arah ini untuk

447
00:21:52,100 --> 00:21:55,346
‫merancang banyak hubungan. Dan itu bekerja

448
00:21:55,346 --> 00:21:59,370
‫seperti ini; di setiap film kami akan menyimpan referensi ke

449
00:21:59,370 --> 00:22:03,980
‫semua aktor yang membintangi film itu. Jadi agak seperti di referensi anak.

450
00:22:03,980 --> 00:22:07,000
‫Namun dan pada saat yang sama di setiap

451
00:22:07,000 --> 00:22:09,570
‫aktor kami juga menyimpan referensi ke semua

452
00:22:09,570 --> 00:22:11,660
‫film yang dimainkan aktor tersebut.

453
00:22:11,660 --> 00:22:15,120
‫Jadi film dan aktor terhubung di kedua arah.

454
00:22:15,120 --> 00:22:17,900
‫Oleh karena itu nama referensi dua arah.

455
00:22:17,900 --> 00:22:19,950
‫Dan ini membuatnya sangat

456
00:22:19,950 --> 00:22:23,290
‫mudah untuk mencari film dan aktor sepenuhnya secara mandiri.

457
00:22:23,290 --> 00:22:25,910
‫Sementara juga memudahkan untuk menemukan aktor yang

458
00:22:25,910 --> 00:22:29,029
‫terkait dengan setiap film dan film yang terkait

459
00:22:29,029 --> 00:22:30,383
‫dengan masing-masing aktor.

460
00:22:31,623 --> 00:22:32,560
‫(napas dalam-dalam)

461
00:22:32,560 --> 00:22:34,747
‫Ini memang kuliah yang cukup panjang.

462
00:22:34,747 --> 00:22:38,030
‫Dengan banyak konsep dan prinsip dan pedoman

463
00:22:38,030 --> 00:22:40,220
‫baru yang perlu diingat.

464
00:22:40,220 --> 00:22:43,460
‫Jadi untuk membantu Anda dengan itu; inilah ringkasan

465
00:22:43,460 --> 00:22:46,650
‫singkat dan beberapa panduan umum yang dapat Anda

466
00:22:46,650 --> 00:22:48,423
‫lihat saat Anda membutuhkannya.

467
00:22:49,260 --> 00:22:52,753
‫Jadi prinsip yang paling penting adalah: susun data Anda

468
00:22:52,753 --> 00:22:56,120
‫agar sesuai dengan cara aplikasi Anda menanyakan dan

469
00:22:56,120 --> 00:22:57,436
‫memperbarui data.

470
00:22:57,436 --> 00:23:01,400
‫Atau dengan kata lain: identifikasi pertanyaan yang muncul dari kasus

471
00:23:01,400 --> 00:23:03,784
‫penggunaan aplikasi Anda terlebih dahulu, lalu

472
00:23:03,784 --> 00:23:06,634
‫modelkan data Anda sehingga pertanyaan dapat dijawab

473
00:23:06,634 --> 00:23:08,995
‫dengan cara yang paling efisien.

474
00:23:08,995 --> 00:23:12,610
‫Sebagai contoh; ketika saya perlu menanyakan film dan aktor selalu

475
00:23:12,610 --> 00:23:16,130
‫bersama atau apakah ada skenario di mana saya hanya menanyakan

476
00:23:16,130 --> 00:23:18,041
‫film atau hanya aktor.

477
00:23:18,041 --> 00:23:20,528
‫Pertanyaan semacam itu akan menjadi

478
00:23:20,528 --> 00:23:22,930
‫dasar model data Anda.

479
00:23:22,930 --> 00:23:26,730
‫Secara umum, selalu pilih penyematan kecuali ada alasan bagus

480
00:23:26,730 --> 00:23:28,440
‫untuk tidak menyematkan.

481
00:23:28,440 --> 00:23:32,513
‫Terutama pada hubungan satu ke beberapa dan satu ke banyak.

482
00:23:33,370 --> 00:23:37,713
‫Selanjutnya, hubungan satu ke satu atau banyak ke banyak biasanya

483
00:23:37,713 --> 00:23:41,543
‫merupakan alasan yang baik untuk referensi alih-alih menyematkan.

484
00:23:41,543 --> 00:23:45,734
‫Juga, pilih referensi ketika data banyak diperbarui

485
00:23:45,734 --> 00:23:50,717
‫dan jika Anda perlu sering mengakses kumpulan data sendiri.

486
00:23:50,717 --> 00:23:55,340
‫Gunakan penyematan saat data sebagian besar dibaca tetapi jarang diperbarui dan

487
00:23:55,340 --> 00:23:58,469
‫saat dua set data secara intrinsik menyatu.

488
00:23:58,469 --> 00:24:02,840
‫Jangan biarkan array tumbuh tanpa batas.

489
00:24:02,840 --> 00:24:05,982
‫Karena itu, jika Anda ingin menormalkan; gunakan referensi anak

490
00:24:05,982 --> 00:24:09,680
‫untuk hubungan satu ke banyak dan referensi orang tua untuk

491
00:24:09,680 --> 00:24:11,856
‫hubungan satu ke satu ton.

492
00:24:11,856 --> 00:24:15,160
‫Dan akhirnya gunakan referensi dua arah

493
00:24:15,160 --> 00:24:17,520
‫untuk banyak hubungan.

494
00:24:17,520 --> 00:24:18,720
‫Baiklah?

495
00:24:18,720 --> 00:24:21,202
‫Dan itu cukup banyak meringkasnya.

496
00:24:21,202 --> 00:24:23,970
‫Saya benar-benar akan merekomendasikan Anda menonton video ini

497
00:24:23,970 --> 00:24:27,144
‫dua kali jika Anda bisa, hanya karena betapa pentingnya

498
00:24:27,144 --> 00:24:30,091
‫materi ini sebenarnya. Baiklah?

499
00:24:30,091 --> 00:24:33,363
‫Pokoknya sampai jumpa di video selanjutnya.