‫Jonas: Então, na última
‫aula, aprendemos uma teoria sobre modelagem de dados.
‫E, então, vamos agora usar essa
‫teoria para realmente projetar o modelo de
‫dados de nosso aplicativo Natours.
‫E esta é para mim e para muitos outros
‫desenvolvedores, na verdade, a parte mais difícil de construir um aplicativo.
‫E, assim, espero que esta aplicação sirva como um
‫bom exemplo para você e lhe dê o
‫conhecimento para posteriormente projetar seus próprios modelos de dados,
‫basicamente por conta própria.
‫Então vamos fazer isso agora.
‫E vamos começar com todos os
‫conjuntos de dados que realmente precisamos em nosso aplicativo.
‫Então, começando com os
‫passeios, e esse é o mais óbvio.
‫E já temos este implementado.
‫Então também precisamos de alguns usuários.
‫E, novamente, já temos uma coleção de usuários em nosso
‫banco de dados.
‫E, basicamente, os passeios e os
‫usuários são dois conjuntos de dados completamente separados.
‫E, então, nós os normalizamos.
‫E é claro que eles não serão incorporados.
‫Em seguida, também teremos avaliações e
‫também teremos locais.
‫OK?
‫Porque a maioria dos passeios, na verdade,
‫tem vários locais diferentes.
‫OK?
‫E, então, novamente é mais um conjunto de dados.
‫E, finalmente, também teremos reservas.
‫Mas um pouco mais sobre o porquê disso em um segundo.
‫Ok, então, temos todos esses conjuntos de dados.
‫Agora vamos realmente modelar os relacionamentos que
‫existem entre eles.
‫E vou começar com
‫a relação entre usuários e comentários.
‫E esse relacionamento é claramente um relacionamento de um para muitos, porque
‫um usuário pode escrever várias revisões, mas uma
‫revisão pode pertencer a apenas um usuário.
‫E o pai neste relacionamento são claramente os usuários,
‫e o filho, as
‫revisões, porque novamente é o pai, então os usuários neste caso, que
‫podem estar relacionados a muitas revisões, mas
‫uma revisão só pode ser relacionada a um usuário.
‫De qualquer forma, escolhi modelar esse relacionamento
‫usando a referência dos pais.
‫E isso porque um usuário pode escrever muitos comentários e
‫também porque podemos realmente precisar consultar apenas
‫os comentários por conta própria.
‫Portanto, o padrão do eixo de
‫dados é muito importante levar em consideração neste relacionamento específico.
‫Agora, sobre o tipo de referência que vamos
‫usar, é a referência
‫do pai, então basicamente a revisão mantém uma referência do usuário.
‫Manter uma identidade, basicamente.
‫E isso é como
‫você já sabe, porque não queremos permitir que uma raça cresça indefinidamente.
‫E esse pode ser
‫o caso se um usuário escrever toneladas e toneladas (risos) de comentários.
‫OK?
‫Além disso, é bom ter a revisão sabendo
‫quem realmente a escreveu.
‫OK?
‫E, portanto, ter o ID do usuário correto na revisão
‫também nos permitirá fazer exatamente isso.
‫Tudo bem.
‫A seguir, vamos
‫dar uma olhada na relação entre passeios e avaliações.
‫E este é realmente muito semelhante.
‫Portanto, novamente, é uma relação um-para-muitos, em que
‫um tour pode ter várias revisões,
‫mas uma revisão pode ser apenas sobre um tour.
‫Direito?
‫Então é assim que faz sentido.
‫E, então, vamos modelá-lo exatamente da mesma maneira
‫que a relação usuário-avaliações.
‫Portanto, novamente, referência aos pais, de
‫modo que no final as avaliações terminem
‫com um ID de tour e um ID de usuário.
‫E, então, assim que consultarmos as avaliações,
‫sempre saberemos exatamente.
‫Ótimo, agora vamos falar sobre a
‫relação entre passeios e locais.
‫Como mencionei
‫antes, cada tour terá alguns locais.
‫Por exemplo, o campista do parque basicamente irá parar
‫em três ou quatro parques nacionais.
‫E, então, cada um desses parques
‫nacionais será um local.
‫Direito?
‫E, portanto, cada tour terá basicamente alguns locais.
‫Agora, seguindo esse exemplo, um desses parques nacionais
‫também pode fazer parte de um dos outros passeios.
‫E, portanto, basicamente essa relação aqui
‫é uma relação de poucos para poucos.
‫E nós chamamos essa relação de muitos para muitos
‫antes, mas ainda podemos chamá-los de poucos para poucos
‫ou uma tonelada para uma tonelada.
‫E, então, eu os
‫chamei de poucos para poucos porque cada turnê terá apenas três,
‫quatro locais, mas não realmente 100.
‫OK?
‫E, novamente, cada um dos locais também pode fazer
‫parte de outro passeio.
‫Agora, este poderia ser um bom exemplo para
‫realmente implementar a referência bidirecional, basicamente normalizando os locais em seu
‫próprio conjunto de dados.
‫Direito?
‫Mas, em vez disso, vou desnormalizar os
‫locais para incorporá-los aos passeios.
‫E isso, na verdade, por vários motivos.
‫Primeiro, porque há poucos locais.
‫Além disso, não iremos acessar os locais
‫por conta própria.
‫E, por fim, esses locais estão intrinsecamente
‫relacionados aos passeios, porque realmente sem locais não
‫poderia haver passeios.
‫Direito?
‫Portanto, esses conjuntos de dados estão intimamente relacionados.
‫E, então, optei por incorporar locais aos passeios e não
‫criar mais uma coleção para eles.
‫Direito?
‫Portanto, teremos uma coleção para passeios, uma para usuários e, um
‫pouco mais tarde, também criaremos uma nova coleção
‫para as avaliações.
‫Tudo bem?
‫Mas para locais, novamente, porque eles serão incorporados
‫aos passeios.
‫Ok, e a seguir também há uma relação
‫entre os passeios e os usuários.
‫E isso porque teremos guias
‫turísticos nos passeios, e esses guias turísticos serão realmente usuários.
‫Portanto, lembra como demos realmente aos usuários uma função
‫em nosso esquema Mongoose?
‫E as possibilidades continham o guia e
‫o guia principal, lembra?
‫E, então, vai haver
‫uma relação entre esses tipos de usuários e os passeios.
‫Agora, essa relação é novamente de poucos para poucos, porque
‫um passeio pode ter apenas alguns usuários, portanto,
‫alguns guias turísticos, mas, ao mesmo
‫tempo, cada guia turístico também pode guiar alguns passeios.
‫Tudo bem?
‫E, então, novamente, há um relacionamento muitos para muitos aqui, que
‫eu simplesmente chamei aqui de poucos para poucos.
‫Agora, sobre realmente modelar esse relacionamento, poderíamos
‫fazer isso de duas maneiras.
‫Podemos usar referência ou incorporação.
‫E, na verdade, vou mostrar a você como
‫implementar a incorporação de referência a filhos usando o Mongoose
‫em toda esta seção.
‫OK?
‫E o argumento para a incorporação é que, neste
‫caso, poderíamos ter todas as informações sobre cada passeio
‫contendo as informações sobre os
‫guias turísticos diretamente em cada documento turístico.
‫Mas, por outro lado, isso
‫criaria algumas informações extras no banco
‫de dados, porque ainda precisaremos ter os
‫usuários como uma
‫coleção separada, simplesmente porque precisamos acessá-los o tempo todo
‫para autenticação e autorização do usuário e
‫tudo mais.
‫Normalmente, os usuários são sempre uma entidade própria em cada
‫banco de dados.
‫OK?
‫Mas ainda podemos incorporar alguns dos usuários aos passeios.
‫Então, basicamente, quando o usuário é um
‫guia turístico de um tour específico, podemos copiar todos esses dados
‫para o documento do tour.
‫OK?
‫Mas também teríamos que atualizar o usuário no tour
‫cada vez que o próprio usuário subjacente mudasse.
‫Então, digamos que a função de um usuário
‫mude de guia para guia líder.
‫E, nesse caso, teríamos que ir para o
‫tour e também atualizar as informações da função
‫ali mesmo nos dados incorporados.
‫OK?
‫E, então, isso não é o ideal,
‫então na verdade também vamos implementar a referência de filhos.
‫E, assim, com isso,
‫ainda podemos manter basicamente as informações sobre
‫os guias turísticos dos usuários, mas simplesmente de uma forma
‫referenciada, então basicamente mantendo os IDs
‫lá, que então irão apontar para os usuários.
‫OK?
‫E, claro, também poderíamos usar a referência
‫bidirecional, mantendo também um ID do passeio direto para o usuário.
‫Mas acho que é
‫um pouco demais para este tipo de pequeno
‫exemplo, porque nem todos os usuários realmente precisarão de uma ID do passeio,
‫porque nem todos os usuários são guias de turismo.
‫E, então, essa relação aqui é um pouco complicada de modelar, eu
‫acho, mas acredito que, no final
‫das contas, a referência à criança será o melhor caminho a seguir.
‫OK?
‫Mesmo assim, também vou mostrar a
‫incorporação, porque acho que isso também é importante para aprender.
‫Tudo bem?
‫Em seguida, temos nossas reservas.
‫E, basicamente, uma nova reserva será
‫criada cada vez que um usuário comprar um tour.
‫Portanto, ainda é uma espécie de
‫relação entre usuários e
‫tours porque, novamente, é um usuário que vai comprar um tour.
‫Mas também queremos armazenar alguns
‫dados sobre esse relacionamento em si,
‫neste caso, sobre a própria compra em nosso banco de dados.
‫Por exemplo, o preço ou
‫a data em que a compra aconteceu ou algo parecido.
‫E, então, em casos
‫como este, é uma boa ideia criar um conjunto de dados
‫extra, que neste caso são as reservas.
‫OK?
‫E, assim, é claro que haverá
‫uma relação entre passeios e reservas e também entre usuários e reservas.
‫E, novamente, porque basicamente a reserva conecta os passeios com
‫os usuários, mas meio que com uma etapa intermediária.
‫Portanto, um passeio pode ter várias reservas,
‫mas uma reserva só pode pertencer a um passeio.
‫E a mesma coisa com os usuários.
‫Assim, um usuário pode reservar vários
‫passeios, mas uma reserva só pode pertencer a um dos usuários.
‫E, então, é claro que temos um relacionamento um-para-muitos
‫em ambos os casos e, também, em ambos os
‫casos, usaremos a referência dos pais.
‫E isso significa que em cada
‫reserva manteremos uma identificação do passeio que foi comprado e também
‫do usuário que realmente comprou o passeio.
‫OK?
‫E, então, neste caso, estou
‫fazendo dessa forma porque basicamente não quero poluir os
‫dados da turnê com informações sobre quem realmente comprou a turnê.
‫Direito?
‫Não seria realmente relevante para os dados do tour em si.
‫E a mesma coisa com os usuários.
‫Portanto, também não queremos poluir o objeto de usuários com
‫todas as reservas que eles fizeram.
‫Tudo bem?
‫E, então, em
‫vez disso, vamos criar um objeto intermediário ou
‫um conjunto de dados intermediário que ficará entre
‫os usuários e os passeios sempre que eles criarem uma nova compra.
‫Direito?
‫Faz sentido?
‫E é isso mesmo para o nosso modelo de dados.
‫E, claro, isso agora parece meio abstrato, mas assim
‫que começarmos a implementá-lo,
‫será muito
‫útil ter todas as nossas ideias organizadas em algo assim.
‫Portanto, sempre que o modelo de dados que
‫vamos implementar ao longo desta seção estiver ficando um pouco confuso
‫para você, basta voltar a este slide.
‫Ou você pode até mesmo imprimi-lo, se
‫isso tornar mais fácil para você.
‫Portanto, este é o nosso modelo de dados em teoria.
‫E agora, ao longo do restante do
‫curso, darei a você as ferramentas para realmente modelar os
‫dados usando a Biblioteca Mongoose.