‫Jonas: Entonces, en la última
‫conferencia, aprendimos una teoría sobre el modelado de datos.
‫Entonces, usemos ahora esa teoría para
‫diseñar realmente el modelo de datos
‫de nuestra aplicación Natours.
‫Y esto es para mí y para muchos
‫otros desarrolladores la parte más difícil de crear una aplicación.
‫Y, entonces, espero que esta aplicación te sirva
‫de buen ejemplo y te brinde los conocimientos
‫para luego diseñar tus propios modelos de datos,
‫básicamente por tu cuenta.
‫Así que hagámoslo ahora.
‫Y comencemos con todos los conjuntos
‫de datos que realmente necesitamos en nuestra aplicación.
‫Entonces, comenzando con las giras,
‫y esa es, por supuesto, la más obvia.
‫Y ya tenemos este implementado.
‫Entonces también necesitamos algunos usuarios.
‫Y, nuevamente, ya tenemos una colección de usuarios en nuestra
‫base de datos.
‫Entonces, básicamente, los recorridos y los
‫usuarios son dos conjuntos de datos completamente separados.
‫Y, entonces, los tenemos normalizados.
‫Y, por supuesto, no se incrustarán.
‫A continuación, también tendremos revisiones y
‫también tendremos ubicaciones.
‫¿Okey?
‫Porque la mayoría de los tours
‫tienen diferentes ubicaciones.
‫¿Okey?
‫Y, de nuevo, ese es otro conjunto de datos.
‫Y finalmente, también tendremos reservas.
‫Pero un poco más sobre por qué eso es en un segundo.
‫Bien, tenemos todos estos conjuntos de datos.
‫Ahora modelemos realmente las relaciones que
‫existen entre ellos.
‫Y comenzaré con
‫la relación entre usuarios y reseñas.
‫Y esta relación es claramente una relación de uno a varios porque
‫un usuario puede escribir varias reseñas, pero una
‫reseña solo puede pertenecer a un usuario.
‫Y el padre en esta relación son claramente los usuarios,
‫y el hijo, las
‫reseñas porque nuevamente es el padre, por lo que los usuarios en este
‫caso, que pueden estar relacionados con muchas reseñas,
‫pero una reseña solo puede estar relacionada con un usuario.
‫De todos modos, elegí modelar esta relación
‫usando referencias de padres.
‫Y eso se debe a que un usuario puede escribir muchas reseñas
‫y también a que es posible que debamos consultar
‫solo las reseñas por su cuenta.
‫Por lo tanto, es muy importante tener en
‫cuenta el patrón del eje de datos en esta relación en particular.
‫Ahora, sobre el tipo de referencia que vamos a
‫usar, es la referencia de
‫los padres, así que básicamente la revisión mantiene una referencia del usuario.
‫Así que, básicamente, mantener una identificación.
‫Y eso es
‫como ya sabéis porque no queremos permitir que una raza crezca indefinidamente.
‫Y ese podría ser
‫el caso si un usuario escribe toneladas y toneladas (risas) de reseñas.
‫¿Okey?
‫Además, es bueno que la reseña sepa
‫quién la escribió.
‫¿Okey?
‫Y, por lo tanto, tener la identificación de usuario en la
‫revisión también nos permitirá hacer precisamente eso.
‫Está bien.
‫A continuación, echemos
‫un vistazo a la relación entre recorridos y reseñas.
‫Y este en realidad es muy similar.
‫Entonces, nuevamente, es una relación de uno a
‫varios, donde un recorrido puede tener varias
‫reseñas, pero una reseña solo puede ser sobre un recorrido.
‫¿Derecha?
‫Entonces esa es la forma en que tiene sentido.
‫Y, entonces, lo modelaremos exactamente de la misma manera que
‫la relación entre usuarios y reseñas.
‫Entonces, nuevamente, referencias de los padres,
‫para que al final las reseñas terminen
‫con una identificación de recorrido y una identificación de usuario.
‫Entonces, una vez que solicitamos reseñas, siempre
‫lo sabremos exactamente.
‫Genial, ahora hablemos de la relación
‫entre recorridos y ubicaciones.
‫Entonces, como mencioné
‫anteriormente, cada gira tendrá un par de ubicaciones.
‫Entonces, por ejemplo, el campista del parque básicamente se detendrá
‫en tres o cuatro parques nacionales.
‫Y, entonces, cada uno de estos
‫parques nacionales será una ubicación.
‫¿Derecha?
‫Y, entonces, cada recorrido tendrá básicamente algunas ubicaciones.
‫Ahora, siguiendo ese ejemplo, uno de estos parques nacionales
‫también podría ser parte de uno de los otros recorridos.
‫Y, entonces, básicamente esta relación aquí
‫es una relación de pocos a pocos.
‫Y antes llamamos a esta relación de muchos a
‫muchos, pero todavía podemos llamarlos de pocos a pocos
‫o de una tonelada a una tonelada.
‫Y, entonces, los llamé
‫pocos a pocos porque cada gira solo tendrá tres, cuatro
‫lugares, pero no como 100.
‫¿Okey?
‫Y, nuevamente, cada una de las ubicaciones también puede ser
‫parte de otro recorrido.
‫Ahora bien, este podría ser un buen ejemplo para
‫implementar realmente referencias bidireccionales, por lo que básicamente normalizar las ubicaciones en su
‫propio conjunto de datos.
‫¿Derecha?
‫Pero en lugar de eso, desnormalizaré las
‫ubicaciones para integrarlas en los recorridos.
‫Y eso es en realidad por múltiples razones.
‫Primero, porque hay muy pocas ubicaciones.
‫Además, realmente no accederemos a las ubicaciones
‫por su cuenta.
‫Y, finalmente, estos lugares están intrínsecamente relacionados
‫con los recorridos porque realmente sin lugares no
‫podría haber recorridos.
‫¿Derecha?
‫Por tanto, estos conjuntos de datos pertenecen estrechamente.
‫Entonces, elegí incrustar ubicaciones en recorridos y no
‫crear otra colección para estos.
‫¿Derecha?
‫Así que tendremos una colección para recorridos, otra para usuarios y,
‫un poco más tarde, también crearemos una nueva
‫colección para las reseñas.
‫¿Está bien?
‫Pero para las ubicaciones, nuevamente, porque estas estarán integradas en
‫los recorridos.
‫De acuerdo, y a continuación también hay una relación
‫entre los recorridos y los usuarios.
‫Y eso es porque vamos a tener
‫guías turísticos en los recorridos, y estos guías turísticos en realidad serán usuarios.
‫Entonces, ¿recuerdas cómo les dimos a los usuarios un rol en
‫nuestro esquema de Mongoose?
‫Y las posibilidades allí contenían la guía
‫y la guía principal, ¿recuerdas?
‫Entonces, habrá una
‫relación entre este tipo de usuarios y los recorridos.
‫Ahora, esta relación es nuevamente una relación de pocos a pocos
‫porque un recorrido puede tener solo unos pocos usuarios,
‫por lo que algunos guías turísticos, pero
‫al mismo tiempo, cada guía turístico también puede guiar algunos recorridos.
‫¿Está bien?
‫Y, entonces, nuevamente, hay una relación de muchos a muchos aquí,
‫que simplemente llamé aquí de pocos a pocos.
‫Ahora, acerca de modelar realmente esta relación,
‫podríamos hacerlo de dos maneras.
‫Podríamos usar referencias o incrustaciones.
‫Y, de hecho, le mostraré cómo implementar
‫la incrustación de referencias de niños usando Mongoose a lo
‫largo de esta sección.
‫¿Okey?
‫Y el argumento para la incrustación es que, en este
‫caso, podríamos tener toda la información sobre cada recorrido que
‫contenga la información sobre los guías
‫turísticos directamente en cada documento del recorrido.
‫Pero, por otro lado, eso crearía
‫información adicional en la base de datos
‫porque todavía necesitaremos tener a los usuarios
‫como una colección separada
‫simplemente porque necesitamos acceder a ellos todo el tiempo para
‫la autenticación y autorización del usuario y
‫todo eso.
‫Por lo general, los usuarios son siempre una entidad por sí mismos en
‫cada base de datos.
‫¿Okey?
‫Pero aún podríamos incorporar a algunos de los usuarios en los recorridos.
‫Entonces, básicamente, cuando el usuario es un
‫guía turístico para un recorrido específico, podríamos copiar todos estos datos
‫en el documento del recorrido.
‫¿Okey?
‫Pero también tendríamos que actualizar al usuario en el
‫recorrido cada vez que cambia el usuario subyacente.
‫Entonces, digamos que el rol de un usuario
‫cambia de guía a guía principal.
‫Y en ese caso, tendríamos que ir al recorrido
‫y también actualizar la información de esa función
‫allí mismo en los datos incrustados.
‫¿Okey?
‫Y, entonces, eso no es ideal, por
‫lo que en realidad también implementaremos referencias de niños.
‫Y, entonces, con eso, todavía
‫podemos mantener básicamente la información sobre los
‫guías turísticos en los usuarios, pero simplemente en una forma
‫referenciada, por lo que básicamente mantener
‫las ID allí, que luego apuntarán a los usuarios.
‫¿Okey?
‫Y, por supuesto, también podríamos usar referencias bidireccionales, por
‫lo que también mantenemos una identificación del recorrido directamente en el usuario.
‫Pero creo que eso
‫es demasiado para este tipo de pequeño
‫ejemplo porque no todos los usuarios realmente necesitarán una identificación del
‫recorrido porque no todos los usuarios son guías turísticos.
‫Y, entonces, esta relación aquí es un poco complicada de
‫modelar, creo, pero creo que
‫al final la referencia infantil será la mejor manera de hacerlo.
‫¿Okey?
‫Pero aún así, también les mostraré cómo
‫integrar porque creo que eso también es importante de aprender.
‫¿Está bien?
‫A continuación, tenemos nuestras reservas.
‫Y básicamente se creará una nueva
‫reserva cada vez que un usuario compre un tour.
‫Así que esta sigue siendo una especie
‫de relación entre los usuarios y
‫los recorridos porque, nuevamente, es un usuario el que va a comprar un recorrido.
‫Pero también queremos almacenar algunos
‫datos sobre esa relación en sí,
‫en este caso sobre la compra en nuestra base de datos.
‫Por ejemplo, el precio o
‫la fecha en que ocurrió la compra o algo así.
‫Entonces, en casos como
‫este, es una buena idea crear un conjunto de datos adicional,
‫que en este caso son las reservas.
‫¿Okey?
‫Y, por supuesto, habrá una relación
‫entre los tours y las reservas y también entre los usuarios y las reservas.
‫Y, de nuevo, porque básicamente la reserva conecta los tours
‫con los usuarios, pero con un paso intermedio.
‫Por lo tanto, un tour puede tener muchas
‫reservas, pero una reserva solo puede pertenecer a un tour.
‫Y lo mismo con los usuarios.
‫Por lo tanto, un usuario puede reservar muchos
‫viajes, pero una reserva solo puede pertenecer a uno de los usuarios.
‫Y, por supuesto, tenemos una relación de uno a
‫muchos en ambos casos, y también en ambos
‫casos, usaremos referencias de padres.
‫Y, entonces, eso significa que en
‫cada reserva mantendremos una identificación tanto del tour que se compró como
‫del usuario que realmente compró el tour.
‫¿Okey?
‫Y, entonces, en este caso,
‫lo hago de esta manera porque básicamente no quiero contaminar los
‫datos del tour con información sobre quién realmente compró el tour.
‫¿Derecha?
‫No sería realmente relevante para los datos del recorrido en sí.
‫Y lo mismo con los usuarios.
‫Por lo tanto, tampoco queremos contaminar el objeto de los
‫usuarios con todas las reservas que hicieron.
‫¿Está bien?
‫Entonces, en su
‫lugar, nuevamente crearemos un objeto intermedio o un
‫conjunto de datos intermedio que se interpondrá entre
‫los usuarios y los recorridos cada vez que creen una nueva compra.
‫¿Derecha?
‫¿Tener sentido?
‫Y eso es todo para nuestro modelo de datos.
‫Y, por supuesto, esto ahora parece algo abstracto, pero una
‫vez que comencemos a
‫implementarlo, será muy
‫útil tener todas nuestras ideas organizadas en algo como esto.
‫Entonces, siempre que este modelo de datos que implementaremos
‫a lo largo de esta sección se vuelva un poco confuso para
‫usted, simplemente vuelva a consultar esta diapositiva.
‫O incluso puede imprimirlo si eso
‫se lo pone más fácil.
‫Entonces este es nuestro modelo de datos en teoría.
‫Y ahora, durante el resto del curso,
‫le daré las herramientas para modelar realmente los datos
‫usando la biblioteca Mongoose.