1
00:00:01,150 --> 00:00:02,540
‫Jonas: Então, na última

2
00:00:02,540 --> 00:00:04,990
‫aula, aprendemos uma teoria sobre modelagem de dados.

3
00:00:04,990 --> 00:00:07,430
‫E, então, vamos agora usar essa

4
00:00:07,430 --> 00:00:09,930
‫teoria para realmente projetar o modelo de

5
00:00:09,930 --> 00:00:12,140
‫dados de nosso aplicativo Natours.

6
00:00:12,140 --> 00:00:15,160
‫E esta é para mim e para muitos outros

7
00:00:15,160 --> 00:00:18,400
‫desenvolvedores, na verdade, a parte mais difícil de construir um aplicativo.

8
00:00:18,400 --> 00:00:21,570
‫E, assim, espero que esta aplicação sirva como um

9
00:00:21,570 --> 00:00:24,660
‫bom exemplo para você e lhe dê o

10
00:00:24,660 --> 00:00:27,860
‫conhecimento para posteriormente projetar seus próprios modelos de dados,

11
00:00:27,860 --> 00:00:29,663
‫basicamente por conta própria.

12
00:00:30,640 --> 00:00:32,130
‫Então vamos fazer isso agora.

13
00:00:32,130 --> 00:00:34,560
‫E vamos começar com todos os

14
00:00:34,560 --> 00:00:37,690
‫conjuntos de dados que realmente precisamos em nosso aplicativo.

15
00:00:37,690 --> 00:00:39,430
‫Então, começando com os

16
00:00:39,430 --> 00:00:41,630
‫passeios, e esse é o mais óbvio.

17
00:00:41,630 --> 00:00:44,730
‫E já temos este implementado.

18
00:00:44,730 --> 00:00:47,150
‫Então também precisamos de alguns usuários.

19
00:00:47,150 --> 00:00:50,590
‫E, novamente, já temos uma coleção de usuários em nosso

20
00:00:50,590 --> 00:00:51,870
‫banco de dados.

21
00:00:51,870 --> 00:00:54,020
‫E, basicamente, os passeios e os

22
00:00:54,020 --> 00:00:56,470
‫usuários são dois conjuntos de dados completamente separados.

23
00:00:56,470 --> 00:00:58,270
‫E, então, nós os normalizamos.

24
00:00:58,270 --> 00:01:00,593
‫E é claro que eles não serão incorporados.

25
00:01:01,540 --> 00:01:04,270
‫Em seguida, também teremos avaliações e

26
00:01:04,270 --> 00:01:06,360
‫também teremos locais.

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

28
00:01:07,300 --> 00:01:09,380
‫Porque a maioria dos passeios, na verdade,

29
00:01:09,380 --> 00:01:10,930
‫tem vários locais diferentes.

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

31
00:01:11,763 --> 00:01:14,600
‫E, então, novamente é mais um conjunto de dados.

32
00:01:14,600 --> 00:01:17,300
‫E, finalmente, também teremos reservas.

33
00:01:17,300 --> 00:01:20,780
‫Mas um pouco mais sobre o porquê disso em um segundo.

34
00:01:20,780 --> 00:01:23,320
‫Ok, então, temos todos esses conjuntos de dados.

35
00:01:23,320 --> 00:01:25,950
‫Agora vamos realmente modelar os relacionamentos que

36
00:01:25,950 --> 00:01:27,480
‫existem entre eles.

37
00:01:27,480 --> 00:01:29,100
‫E vou começar com

38
00:01:29,100 --> 00:01:31,470
‫a relação entre usuários e comentários.

39
00:01:31,470 --> 00:01:36,100
‫E esse relacionamento é claramente um relacionamento de um para muitos, porque

40
00:01:36,100 --> 00:01:39,260
‫um usuário pode escrever várias revisões, mas uma

41
00:01:39,260 --> 00:01:42,360
‫revisão pode pertencer a apenas um usuário.

42
00:01:42,360 --> 00:01:45,550
‫E o pai neste relacionamento são claramente os usuários,

43
00:01:45,550 --> 00:01:47,240
‫e o filho, as

44
00:01:47,240 --> 00:01:51,160
‫revisões, porque novamente é o pai, então os usuários neste caso, que

45
00:01:51,160 --> 00:01:53,560
‫podem estar relacionados a muitas revisões, mas

46
00:01:53,560 --> 00:01:56,730
‫uma revisão só pode ser relacionada a um usuário.

47
00:01:56,730 --> 00:01:59,290
‫De qualquer forma, escolhi modelar esse relacionamento

48
00:01:59,290 --> 00:02:01,160
‫usando a referência dos pais.

49
00:02:01,160 --> 00:02:04,830
‫E isso porque um usuário pode escrever muitos comentários e

50
00:02:04,830 --> 00:02:07,490
‫também porque podemos realmente precisar consultar apenas

51
00:02:07,490 --> 00:02:09,600
‫os comentários por conta própria.

52
00:02:09,600 --> 00:02:12,490
‫Portanto, o padrão do eixo de

53
00:02:12,490 --> 00:02:16,300
‫dados é muito importante levar em consideração neste relacionamento específico.

54
00:02:16,300 --> 00:02:18,940
‫Agora, sobre o tipo de referência que vamos

55
00:02:18,940 --> 00:02:20,610
‫usar, é a referência

56
00:02:20,610 --> 00:02:24,220
‫do pai, então basicamente a revisão mantém uma referência do usuário.

57
00:02:24,220 --> 00:02:26,670
‫Manter uma identidade, basicamente.

58
00:02:26,670 --> 00:02:28,220
‫E isso é como

59
00:02:28,220 --> 00:02:32,510
‫você já sabe, porque não queremos permitir que uma raça cresça indefinidamente.

60
00:02:32,510 --> 00:02:33,940
‫E esse pode ser

61
00:02:33,940 --> 00:02:37,860
‫o caso se um usuário escrever toneladas e toneladas (risos) de comentários.

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

63
00:02:38,930 --> 00:02:41,790
‫Além disso, é bom ter a revisão sabendo

64
00:02:41,790 --> 00:02:43,220
‫quem realmente a escreveu.

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

66
00:02:44,053 --> 00:02:46,440
‫E, portanto, ter o ID do usuário correto na revisão

67
00:02:46,440 --> 00:02:48,273
‫também nos permitirá fazer exatamente isso.

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

69
00:02:49,953 --> 00:02:51,060
‫A seguir, vamos

70
00:02:51,060 --> 00:02:54,310
‫dar uma olhada na relação entre passeios e avaliações.

71
00:02:54,310 --> 00:02:56,580
‫E este é realmente muito semelhante.

72
00:02:56,580 --> 00:02:59,450
‫Portanto, novamente, é uma relação um-para-muitos, em que

73
00:02:59,450 --> 00:03:02,070
‫um tour pode ter várias revisões,

74
00:03:02,070 --> 00:03:05,260
‫mas uma revisão pode ser apenas sobre um tour.

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

76
00:03:06,093 --> 00:03:07,810
‫Então é assim que faz sentido.

77
00:03:07,810 --> 00:03:11,180
‫E, então, vamos modelá-lo exatamente da mesma maneira

78
00:03:11,180 --> 00:03:13,380
‫que a relação usuário-avaliações.

79
00:03:13,380 --> 00:03:15,460
‫Portanto, novamente, referência aos pais, de

80
00:03:15,460 --> 00:03:17,670
‫modo que no final as avaliações terminem

81
00:03:17,670 --> 00:03:20,530
‫com um ID de tour e um ID de usuário.

82
00:03:20,530 --> 00:03:23,270
‫E, então, assim que consultarmos as avaliações,

83
00:03:23,270 --> 00:03:25,040
‫sempre saberemos exatamente.

84
00:03:25,040 --> 00:03:27,930
‫Ótimo, agora vamos falar sobre a

85
00:03:27,930 --> 00:03:30,800
‫relação entre passeios e locais.

86
00:03:30,800 --> 00:03:32,230
‫Como mencionei

87
00:03:32,230 --> 00:03:35,230
‫antes, cada tour terá alguns locais.

88
00:03:35,230 --> 00:03:38,680
‫Por exemplo, o campista do parque basicamente irá parar

89
00:03:38,680 --> 00:03:41,080
‫em três ou quatro parques nacionais.

90
00:03:41,080 --> 00:03:43,150
‫E, então, cada um desses parques

91
00:03:43,150 --> 00:03:45,120
‫nacionais será um local.

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

93
00:03:45,953 --> 00:03:49,700
‫E, portanto, cada tour terá basicamente alguns locais.

94
00:03:49,700 --> 00:03:52,730
‫Agora, seguindo esse exemplo, um desses parques nacionais

95
00:03:52,730 --> 00:03:55,930
‫também pode fazer parte de um dos outros passeios.

96
00:03:55,930 --> 00:03:58,260
‫E, portanto, basicamente essa relação aqui

97
00:03:58,260 --> 00:04:00,770
‫é uma relação de poucos para poucos.

98
00:04:00,770 --> 00:04:03,630
‫E nós chamamos essa relação de muitos para muitos

99
00:04:03,630 --> 00:04:06,480
‫antes, mas ainda podemos chamá-los de poucos para poucos

100
00:04:06,480 --> 00:04:08,910
‫ou uma tonelada para uma tonelada.

101
00:04:08,910 --> 00:04:10,850
‫E, então, eu os

102
00:04:10,850 --> 00:04:15,290
‫chamei de poucos para poucos porque cada turnê terá apenas três,

103
00:04:15,290 --> 00:04:17,460
‫quatro locais, mas não realmente 100.

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

105
00:04:18,370 --> 00:04:21,540
‫E, novamente, cada um dos locais também pode fazer

106
00:04:21,540 --> 00:04:23,060
‫parte de outro passeio.

107
00:04:23,060 --> 00:04:26,210
‫Agora, este poderia ser um bom exemplo para

108
00:04:26,210 --> 00:04:30,670
‫realmente implementar a referência bidirecional, basicamente normalizando os locais em seu

109
00:04:30,670 --> 00:04:32,480
‫próprio conjunto de dados.

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

111
00:04:33,313 --> 00:04:36,330
‫Mas, em vez disso, vou desnormalizar os

112
00:04:36,330 --> 00:04:39,270
‫locais para incorporá-los aos passeios.

113
00:04:39,270 --> 00:04:41,350
‫E isso, na verdade, por vários motivos.

114
00:04:41,350 --> 00:04:44,500
‫Primeiro, porque há poucos locais.

115
00:04:44,500 --> 00:04:47,400
‫Além disso, não iremos acessar os locais

116
00:04:47,400 --> 00:04:48,690
‫por conta própria.

117
00:04:48,690 --> 00:04:51,890
‫E, por fim, esses locais estão intrinsecamente

118
00:04:51,890 --> 00:04:55,400
‫relacionados aos passeios, porque realmente sem locais não

119
00:04:55,400 --> 00:04:57,280
‫poderia haver passeios.

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

121
00:04:58,113 --> 00:05:00,480
‫Portanto, esses conjuntos de dados estão intimamente relacionados.

122
00:05:00,480 --> 00:05:04,030
‫E, então, optei por incorporar locais aos passeios e não

123
00:05:04,030 --> 00:05:06,580
‫criar mais uma coleção para eles.

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

125
00:05:07,413 --> 00:05:10,750
‫Portanto, teremos uma coleção para passeios, uma para usuários e, um

126
00:05:10,750 --> 00:05:13,330
‫pouco mais tarde, também criaremos uma nova coleção

127
00:05:13,330 --> 00:05:14,710
‫para as avaliações.

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

129
00:05:15,543 --> 00:05:18,860
‫Mas para locais, novamente, porque eles serão incorporados

130
00:05:18,860 --> 00:05:19,793
‫aos passeios.

131
00:05:20,640 --> 00:05:23,710
‫Ok, e a seguir também há uma relação

132
00:05:23,710 --> 00:05:26,250
‫entre os passeios e os usuários.

133
00:05:26,250 --> 00:05:28,780
‫E isso porque teremos guias

134
00:05:28,780 --> 00:05:33,150
‫turísticos nos passeios, e esses guias turísticos serão realmente usuários.

135
00:05:33,150 --> 00:05:36,270
‫Portanto, lembra como demos realmente aos usuários uma função

136
00:05:36,270 --> 00:05:37,760
‫em nosso esquema Mongoose?

137
00:05:37,760 --> 00:05:40,770
‫E as possibilidades continham o guia e

138
00:05:40,770 --> 00:05:43,020
‫o guia principal, lembra?

139
00:05:43,020 --> 00:05:44,670
‫E, então, vai haver

140
00:05:44,670 --> 00:05:48,210
‫uma relação entre esses tipos de usuários e os passeios.

141
00:05:48,210 --> 00:05:52,240
‫Agora, essa relação é novamente de poucos para poucos, porque

142
00:05:52,240 --> 00:05:55,550
‫um passeio pode ter apenas alguns usuários, portanto,

143
00:05:55,550 --> 00:05:58,410
‫alguns guias turísticos, mas, ao mesmo

144
00:05:58,410 --> 00:06:02,150
‫tempo, cada guia turístico também pode guiar alguns passeios.

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

146
00:06:02,983 --> 00:06:06,490
‫E, então, novamente, há um relacionamento muitos para muitos aqui, que

147
00:06:06,490 --> 00:06:09,270
‫eu simplesmente chamei aqui de poucos para poucos.

148
00:06:09,270 --> 00:06:12,140
‫Agora, sobre realmente modelar esse relacionamento, poderíamos

149
00:06:12,140 --> 00:06:14,410
‫fazer isso de duas maneiras.

150
00:06:14,410 --> 00:06:17,280
‫Podemos usar referência ou incorporação.

151
00:06:17,280 --> 00:06:19,620
‫E, na verdade, vou mostrar a você como

152
00:06:19,620 --> 00:06:22,830
‫implementar a incorporação de referência a filhos usando o Mongoose

153
00:06:22,830 --> 00:06:24,410
‫em toda esta seção.

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

155
00:06:25,620 --> 00:06:28,800
‫E o argumento para a incorporação é que, neste

156
00:06:28,800 --> 00:06:31,930
‫caso, poderíamos ter todas as informações sobre cada passeio

157
00:06:31,930 --> 00:06:34,310
‫contendo as informações sobre os

158
00:06:34,310 --> 00:06:36,700
‫guias turísticos diretamente em cada documento turístico.

159
00:06:36,700 --> 00:06:38,710
‫Mas, por outro lado, isso

160
00:06:38,710 --> 00:06:41,120
‫criaria algumas informações extras no banco

161
00:06:41,120 --> 00:06:43,670
‫de dados, porque ainda precisaremos ter os

162
00:06:43,670 --> 00:06:45,210
‫usuários como uma

163
00:06:45,210 --> 00:06:48,700
‫coleção separada, simplesmente porque precisamos acessá-los o tempo todo

164
00:06:48,700 --> 00:06:51,250
‫para autenticação e autorização do usuário e

165
00:06:51,250 --> 00:06:52,510
‫tudo mais.

166
00:06:52,510 --> 00:06:56,290
‫Normalmente, os usuários são sempre uma entidade própria em cada

167
00:06:56,290 --> 00:06:57,700
‫banco de dados.

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

169
00:06:58,533 --> 00:07:02,380
‫Mas ainda podemos incorporar alguns dos usuários aos passeios.

170
00:07:02,380 --> 00:07:04,750
‫Então, basicamente, quando o usuário é um

171
00:07:04,750 --> 00:07:08,190
‫guia turístico de um tour específico, podemos copiar todos esses dados

172
00:07:08,190 --> 00:07:09,950
‫para o documento do tour.

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

174
00:07:10,783 --> 00:07:14,230
‫Mas também teríamos que atualizar o usuário no tour

175
00:07:14,230 --> 00:07:17,590
‫cada vez que o próprio usuário subjacente mudasse.

176
00:07:17,590 --> 00:07:19,710
‫Então, digamos que a função de um usuário

177
00:07:19,710 --> 00:07:21,690
‫mude de guia para guia líder.

178
00:07:21,690 --> 00:07:24,410
‫E, nesse caso, teríamos que ir para o

179
00:07:24,410 --> 00:07:26,850
‫tour e também atualizar as informações da função

180
00:07:26,850 --> 00:07:28,840
‫ali mesmo nos dados incorporados.

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

182
00:07:29,673 --> 00:07:32,320
‫E, então, isso não é o ideal,

183
00:07:32,320 --> 00:07:35,350
‫então na verdade também vamos implementar a referência de filhos.

184
00:07:35,350 --> 00:07:37,280
‫E, assim, com isso,

185
00:07:37,280 --> 00:07:39,590
‫ainda podemos manter basicamente as informações sobre

186
00:07:39,590 --> 00:07:42,860
‫os guias turísticos dos usuários, mas simplesmente de uma forma

187
00:07:42,860 --> 00:07:44,930
‫referenciada, então basicamente mantendo os IDs

188
00:07:44,930 --> 00:07:47,630
‫lá, que então irão apontar para os usuários.

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

190
00:07:48,463 --> 00:07:51,370
‫E, claro, também poderíamos usar a referência

191
00:07:51,370 --> 00:07:55,100
‫bidirecional, mantendo também um ID do passeio direto para o usuário.

192
00:07:55,100 --> 00:07:56,650
‫Mas acho que é

193
00:07:56,650 --> 00:07:59,140
‫um pouco demais para este tipo de pequeno

194
00:07:59,140 --> 00:08:02,850
‫exemplo, porque nem todos os usuários realmente precisarão de uma ID do passeio,

195
00:08:02,850 --> 00:08:05,580
‫porque nem todos os usuários são guias de turismo.

196
00:08:05,580 --> 00:08:08,870
‫E, então, essa relação aqui é um pouco complicada de modelar, eu

197
00:08:08,870 --> 00:08:10,800
‫acho, mas acredito que, no final

198
00:08:10,800 --> 00:08:14,200
‫das contas, a referência à criança será o melhor caminho a seguir.

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

200
00:08:15,033 --> 00:08:17,220
‫Mesmo assim, também vou mostrar a

201
00:08:17,220 --> 00:08:20,120
‫incorporação, porque acho que isso também é importante para aprender.

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

203
00:08:21,400 --> 00:08:23,530
‫Em seguida, temos nossas reservas.

204
00:08:23,530 --> 00:08:26,130
‫E, basicamente, uma nova reserva será

205
00:08:26,130 --> 00:08:29,340
‫criada cada vez que um usuário comprar um tour.

206
00:08:29,340 --> 00:08:31,340
‫Portanto, ainda é uma espécie de

207
00:08:31,340 --> 00:08:33,240
‫relação entre usuários e

208
00:08:33,240 --> 00:08:36,950
‫tours porque, novamente, é um usuário que vai comprar um tour.

209
00:08:36,950 --> 00:08:38,810
‫Mas também queremos armazenar alguns

210
00:08:38,810 --> 00:08:40,920
‫dados sobre esse relacionamento em si,

211
00:08:40,920 --> 00:08:44,450
‫neste caso, sobre a própria compra em nosso banco de dados.

212
00:08:44,450 --> 00:08:46,430
‫Por exemplo, o preço ou

213
00:08:46,430 --> 00:08:49,560
‫a data em que a compra aconteceu ou algo parecido.

214
00:08:49,560 --> 00:08:50,810
‫E, então, em casos

215
00:08:50,810 --> 00:08:53,750
‫como este, é uma boa ideia criar um conjunto de dados

216
00:08:53,750 --> 00:08:55,920
‫extra, que neste caso são as reservas.

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

218
00:08:56,753 --> 00:08:58,710
‫E, assim, é claro que haverá

219
00:08:58,710 --> 00:09:02,398
‫uma relação entre passeios e reservas e também entre usuários e reservas.

220
00:09:02,398 --> 00:09:06,150
‫E, novamente, porque basicamente a reserva conecta os passeios com

221
00:09:06,150 --> 00:09:09,763
‫os usuários, mas meio que com uma etapa intermediária.

222
00:09:09,763 --> 00:09:12,530
‫Portanto, um passeio pode ter várias reservas,

223
00:09:12,530 --> 00:09:15,760
‫mas uma reserva só pode pertencer a um passeio.

224
00:09:15,760 --> 00:09:17,350
‫E a mesma coisa com os usuários.

225
00:09:17,350 --> 00:09:19,870
‫Assim, um usuário pode reservar vários

226
00:09:19,870 --> 00:09:23,610
‫passeios, mas uma reserva só pode pertencer a um dos usuários.

227
00:09:23,610 --> 00:09:26,380
‫E, então, é claro que temos um relacionamento um-para-muitos

228
00:09:26,380 --> 00:09:29,080
‫em ambos os casos e, também, em ambos os

229
00:09:29,080 --> 00:09:31,140
‫casos, usaremos a referência dos pais.

230
00:09:31,140 --> 00:09:33,610
‫E isso significa que em cada

231
00:09:33,610 --> 00:09:37,640
‫reserva manteremos uma identificação do passeio que foi comprado e também

232
00:09:37,640 --> 00:09:40,270
‫do usuário que realmente comprou o passeio.

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

234
00:09:41,103 --> 00:09:42,930
‫E, então, neste caso, estou

235
00:09:42,930 --> 00:09:46,140
‫fazendo dessa forma porque basicamente não quero poluir os

236
00:09:46,140 --> 00:09:49,510
‫dados da turnê com informações sobre quem realmente comprou a turnê.

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

238
00:09:50,343 --> 00:09:53,157
‫Não seria realmente relevante para os dados do tour em si.

239
00:09:53,157 --> 00:09:55,070
‫E a mesma coisa com os usuários.

240
00:09:55,070 --> 00:09:58,370
‫Portanto, também não queremos poluir o objeto de usuários com

241
00:09:58,370 --> 00:10:00,740
‫todas as reservas que eles fizeram.

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

243
00:10:01,573 --> 00:10:03,000
‫E, então, em

244
00:10:03,000 --> 00:10:05,770
‫vez disso, vamos criar um objeto intermediário ou

245
00:10:05,770 --> 00:10:08,450
‫um conjunto de dados intermediário que ficará entre

246
00:10:08,450 --> 00:10:12,520
‫os usuários e os passeios sempre que eles criarem uma nova compra.

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

248
00:10:13,353 --> 00:10:14,590
‫Faz sentido?

249
00:10:14,590 --> 00:10:17,520
‫E é isso mesmo para o nosso modelo de dados.

250
00:10:17,520 --> 00:10:21,370
‫E, claro, isso agora parece meio abstrato, mas assim

251
00:10:21,370 --> 00:10:23,150
‫que começarmos a implementá-lo,

252
00:10:23,150 --> 00:10:24,660
‫será muito

253
00:10:24,660 --> 00:10:28,730
‫útil ter todas as nossas ideias organizadas em algo assim.

254
00:10:28,730 --> 00:10:31,310
‫Portanto, sempre que o modelo de dados que

255
00:10:31,310 --> 00:10:34,560
‫vamos implementar ao longo desta seção estiver ficando um pouco confuso

256
00:10:34,560 --> 00:10:36,970
‫para você, basta voltar a este slide.

257
00:10:36,970 --> 00:10:39,080
‫Ou você pode até mesmo imprimi-lo, se

258
00:10:39,080 --> 00:10:40,980
‫isso tornar mais fácil para você.

259
00:10:40,980 --> 00:10:43,960
‫Portanto, este é o nosso modelo de dados em teoria.

260
00:10:43,960 --> 00:10:46,080
‫E agora, ao longo do restante do

261
00:10:46,080 --> 00:10:48,870
‫curso, darei a você as ferramentas para realmente modelar os

262
00:10:48,870 --> 00:10:50,543
‫dados usando a Biblioteca Mongoose.