‫Jonas : Donc, dans la dernière
‫conférence, nous avons appris une théorie sur la modélisation des données.
‫Et, donc, utilisons maintenant cette théorie
‫afin de concevoir réellement le modèle de
‫données de notre application Natours.
‫Et c'est pour moi et pour de nombreux autres
‫développeurs la partie la plus difficile de la création d'une application.
‫Et, donc, j'espère que cette application vous servira
‫de bon exemple et vous donnera les connaissances
‫nécessaires pour concevoir plus tard vos propres modèles de
‫données, essentiellement par vous-même.
‫Alors faisons-le maintenant.
‫Et commençons par tous les ensembles
‫de données dont nous avons réellement besoin dans notre application.
‫Donc à commencer par les
‫tournées, et c'est bien sûr la plus évidente.
‫Et nous avons déjà celui-ci mis en œuvre.
‫Ensuite, nous avons également besoin de quelques utilisateurs.
‫Et, encore une fois, nous avons déjà une collection d'utilisateurs dans
‫notre base de données.
‫Et donc, les visites et les utilisateurs
‫sont essentiellement deux ensembles de données complètement distincts.
‫Et, donc, nous les avons normalisés.
‫Et bien sûr, ils ne seront pas intégrés.
‫Ensuite, nous aurons également des critiques, et
‫nous aurons également des emplacements.
‫D'accord?
‫Parce que la plupart des circuits ont en fait
‫un certain nombre d'endroits différents.
‫D'accord?
‫Et, donc, c'est encore un autre ensemble de données.
‫Et enfin, nous aurons aussi des réservations.
‫Mais un peu plus sur pourquoi c'est dans une seconde.
‫D'accord, nous avons tous ces ensembles de données.
‫Modélisons maintenant les relations qui existent
‫entre eux.
‫Et je vais commencer par
‫la relation entre les utilisateurs et les avis.
‫Et cette relation est clairement une relation un-à-plusieurs car un utilisateur
‫peut écrire plusieurs avis, mais un avis ne
‫peut appartenir qu'à un seul utilisateur.
‫Et le parent dans cette relation est clairement les utilisateurs, et
‫l'enfant, les avis car
‫encore une fois c'est le parent, donc les utilisateurs dans ce cas, qui
‫peuvent être liés à de nombreux avis, mais
‫un avis ne peut être lié qu'à un seul utilisateur.
‫Quoi qu'il en soit, j'ai choisi de modéliser cette relation
‫en utilisant le référencement des parents.
‫Et c'est parce qu'un utilisateur peut écrire beaucoup d'avis et aussi
‫parce que nous pourrions en fait avoir besoin
‫d'interroger uniquement les avis par eux-mêmes.
‫Il est donc très important de prendre en
‫compte le modèle de l'axe des données dans cette relation particulière.
‫Maintenant, à propos du type de référencement que
‫nous allons utiliser, il s'agit
‫du référencement parent, donc fondamentalement, la revue conserve une référence de l'utilisateur.
‫Donc, garder une pièce d'identité, en gros.
‫Et c'est comme vous le
‫savez déjà parce que nous ne voulons pas permettre à une race de grandir indéfiniment.
‫Et cela pourrait être
‫le cas si un utilisateur écrit des tonnes et des tonnes (rires) d'avis.
‫D'accord?
‫De plus, il est agréable d'avoir la critique en sachant
‫qui l'a réellement écrite.
‫D'accord?
‫Et, donc, avoir l'ID utilisateur directement sur l'examen nous
‫permettra également de faire exactement cela.
‫D'accord.
‫Ensuite, examinons
‫la relation entre les visites et les critiques.
‫Et celui-ci est en fait très similaire.
‫Donc, encore une fois, c'est une relation un-à-plusieurs,
‫où une tournée peut avoir plusieurs critiques,
‫mais une critique ne peut concerner qu'une seule tournée.
‫Droit?
‫C'est ainsi que cela a du sens.
‫Et, donc, nous allons le modéliser exactement de la même
‫manière que la relation utilisateur-avis.
‫Donc, encore une fois, le référencement des
‫parents, de sorte qu'au final les avis se
‫retrouvent avec un identifiant de tournée et un identifiant d'utilisateur.
‫Et, donc, une fois que nous demandons des
‫avis, nous savons toujours exactement.
‫Super, parlons maintenant de la relation entre
‫les visites et les lieux.
‫Donc, comme je
‫l'ai mentionné plus tôt, chaque tournée aura plusieurs endroits.
‫Ainsi, par exemple, le camping-car du parc s'arrêtera essentiellement
‫dans trois ou quatre parcs nationaux.
‫Et, donc, chacun de ces parcs
‫nationaux va être un endroit.
‫Droit?
‫Et, donc, chaque tournée aura essentiellement quelques endroits.
‫Maintenant, en suivant cet exemple, l'un de ces parcs
‫nationaux pourrait également faire partie de l'un des autres circuits.
‫Et, donc, fondamentalement, cette relation ici
‫est une relation de quelques-uns à quelques-uns.
‫Et nous avons appelé cette relation plusieurs-à-plusieurs auparavant, mais
‫nous pouvons toujours les appeler quelques-uns à quelques-uns
‫ou une tonne à une tonne.
‫Et, donc, je les
‫ai appelés peu à peu parce que chaque tournée n'aura que trois,
‫quatre emplacements mais pas vraiment 100.
‫D'accord?
‫Et, encore une fois, chacun des lieux peut également faire
‫partie d'une autre tournée.
‫Maintenant, cela pourrait être un bon exemple pour
‫implémenter réellement un référencement bidirectionnel, donc fondamentalement normaliser les emplacements dans son
‫propre ensemble de données.
‫Droit?
‫Mais au lieu de cela, je vais en fait dénormaliser
‫les emplacements afin de les intégrer dans les tournées.
‫Et c'est en fait pour plusieurs raisons.
‫D'abord parce qu'il n'y a que si peu d'emplacements.
‫De plus, nous n'allons pas vraiment accéder aux
‫emplacements par eux-mêmes.
‫Et, enfin, ces lieux sont intrinsèquement liés
‫aux tournées car vraiment sans lieux, il ne pourrait
‫y avoir de tournées.
‫Droit?
‫Ces ensembles de données sont donc étroitement liés.
‫Et, donc, j'ai choisi d'intégrer des lieux dans des tournées et de
‫ne pas créer une autre collection pour ceux-ci.
‫Droit?
‫Nous aurons donc une collection pour les visites, une pour les utilisateurs,
‫et un peu plus tard, nous créerons également une nouvelle
‫collection pour les critiques.
‫D'accord?
‫Mais pour les lieux, encore une fois, car ceux-ci seront intégrés
‫aux visites.
‫D'accord, et ensuite, il y a aussi une relation
‫entre les visites et les utilisateurs.
‫Et c'est parce que nous allons avoir des
‫guides touristiques dans les visites, et ces guides touristiques seront en fait des utilisateurs.
‫Alors, rappelez-vous comment nous avons donné aux utilisateurs un rôle dans
‫notre schéma Mongoose ?
‫Et les possibilités là-bas contenaient le guide et le
‫guide principal, vous vous souvenez ?
‫Et, donc, il va
‫y avoir une relation entre ces types d'utilisateurs et les visites.
‫Maintenant, cette relation est à nouveau une relation de quelques-uns à
‫quelques-uns car une visite ne peut avoir que quelques
‫utilisateurs, donc quelques guides touristiques, mais en
‫même temps, chaque guide touristique peut également guider quelques visites.
‫D'accord?
‫Et, donc, encore une fois, il y a une relation plusieurs-à-plusieurs
‫ici, que j'ai simplement appelée ici quelques-uns.
‫Maintenant, à propos de la modélisation de cette relation,
‫nous pourrions le faire de deux manières.
‫Nous pourrions utiliser le référencement ou l'intégration.
‫Et en fait, je vais vous montrer comment
‫implémenter l'intégration de référencement d'enfants à l'aide de Mongoose tout au
‫long de cette section.
‫D'accord?
‫Et l'argument en faveur de l'intégration est que dans ce
‫cas, nous pourrions alors avoir toutes les informations sur chaque
‫visite contenant les informations sur les
‫guides touristiques directement sur chaque document de visite.
‫Mais d'un autre côté, cela créerait
‫alors des informations supplémentaires dans la base
‫de données car nous aurons toujours besoin d'avoir
‫les utilisateurs dans une
‫collection séparée simplement parce que nous devons y accéder tout le
‫temps pour l'authentification et l'autorisation des utilisateurs et
‫tout le reste.
‫Donc, généralement, les utilisateurs sont toujours une entité à part entière dans
‫chaque base de données.
‫D'accord?
‫Mais nous pourrions toujours intégrer certains des utilisateurs dans les visites.
‫Donc, fondamentalement, lorsque l'utilisateur est un guide touristique
‫pour une visite spécifique, nous pourrions alors copier toutes ces données
‫dans le document de visite.
‫D'accord?
‫Mais nous devrions également mettre à jour l'utilisateur lors de la
‫visite à chaque fois que l'utilisateur sous-jacent lui-même change.
‫Disons donc que le rôle d'un utilisateur
‫passe de guide à guide principal.
‫Et dans ce cas, nous devions alors aller à la
‫visite et également mettre à jour ces informations
‫de rôle sur les données intégrées.
‫D'accord?
‫Et, donc, ce n'est pas idéal, et
‫nous allons donc également implémenter le référencement des enfants.
‫Et, donc, avec cela, nous
‫pouvons toujours conserver essentiellement les informations sur
‫les guides touristiques sur les utilisateurs, mais simplement sous une forme
‫référencée, donc en gros en gardant les
‫identifiants là-bas, qui vont ensuite pointer vers les utilisateurs.
‫D'accord?
‫Et bien sûr, nous pourrions également utiliser le référencement
‫bidirectionnel, afin de conserver également un identifiant de la visite directement sur l'utilisateur.
‫Mais je pense que
‫c'est un peu trop pour ce genre de petit
‫exemple car tous les utilisateurs n'auront pas réellement besoin d'un identifiant de la visite
‫car tous les utilisateurs ne sont pas des guides touristiques.
‫Et, donc, cette relation ici est un peu difficile à modéliser, je
‫pense, mais je pense qu'en fin
‫de compte, le référencement des enfants sera la meilleure voie à suivre.
‫D'accord?
‫Mais quand même, je vais aussi vous montrer
‫l'intégration parce que je pense que c'est aussi important à apprendre.
‫D'accord?
‫Ensuite, nous avons nos réservations.
‫Et fondamentalement, une nouvelle réservation sera
‫créée chaque fois qu'un utilisateur achète une visite.
‫Il s'agit donc toujours d'une sorte de
‫relation entre les utilisateurs et les
‫visites, car encore une fois, c'est un utilisateur qui va acheter une visite.
‫Mais nous voulons également stocker
‫des données sur cette relation elle-même, donc
‫dans ce cas sur l'achat lui-même dans notre base de données.
‫Par exemple, le prix ou la
‫date à laquelle l'achat a eu lieu ou quelque chose comme ça.
‫Et, donc, dans des
‫cas comme celui-ci, c'est une bonne idée de créer un ensemble de
‫données supplémentaire, qui dans ce cas correspond aux réservations.
‫D'accord?
‫Et, bien sûr, il y aura une
‫relation entre les visites et les réservations et aussi les utilisateurs et les réservations.
‫Et, encore une fois, parce que fondamentalement, la réservation relie les visites
‫aux utilisateurs, mais en quelque sorte avec une étape intermédiaire.
‫Ainsi, une tournée peut avoir plusieurs réservations,
‫mais une réservation ne peut appartenir qu'à une seule tournée.
‫Et la même chose avec les utilisateurs.
‫Ainsi, un utilisateur peut réserver plusieurs
‫circuits, mais une réservation ne peut appartenir qu'à l'un des utilisateurs.
‫Et, donc, bien sûr, nous avons une relation un-à-plusieurs dans
‫les deux cas, et aussi dans les deux cas,
‫nous allons utiliser le référencement parent.
‫Et, donc, cela signifie que sur chaque réservation,
‫nous allons conserver un identifiant à la fois de la visite qui a été achetée
‫et également de l'utilisateur qui a réellement acheté la visite.
‫D'accord?
‫Et, donc, dans ce cas, je le
‫fais de cette façon parce que fondamentalement, je ne veux pas polluer les
‫données de la tournée avec des informations sur qui a réellement acheté la tournée.
‫Droit?
‫Cela ne serait pas vraiment pertinent pour les données de tournée elles-mêmes.
‫Et la même chose avec les utilisateurs.
‫Nous ne voulons donc pas non plus polluer l'objection des utilisateurs
‫avec toutes les réservations qu'ils ont effectuées.
‫D'accord?
‫Et donc, à la
‫place, nous allons à nouveau créer un objet intermédiaire
‫ou un ensemble de données intermédiaire qui se
‫tiendra entre les utilisateurs et les visites chaque fois qu'ils créeront un nouvel achat.
‫Droit?
‫Avoir du sens ?
‫Et c'est en fait tout pour notre modèle de données.
‫Et bien sûr, cela semble maintenant un peu abstrait, mais une
‫fois que nous aurons commencé
‫à l'implémenter, il sera
‫très utile d'avoir toutes nos idées organisées dans quelque chose comme ça.
‫Donc, chaque fois que ce modèle de données que nous
‫allons implémenter tout au long de cette section devient un peu déroutant
‫pour vous, alors référez-vous simplement à cette diapositive.
‫Ou vous pouvez peut-être même l'imprimer si
‫cela vous facilite la tâche.
‫C'est donc notre modèle de données en théorie.
‫Et maintenant, tout au long du reste du
‫cours, je vais vous donner les outils pour modéliser réellement les données
‫à l'aide de la bibliothèque Mongoose.