‫Jonas: In der letzten
‫Vorlesung haben wir also eine Theorie zur Datenmodellierung gelernt.
‫Lassen Sie uns diese Theorie
‫nun verwenden, um das Datenmodell unserer
‫Natours-Anwendung tatsächlich zu entwerfen.
‫Und das ist für mich und für viele
‫andere Entwickler tatsächlich der schwierigste Teil beim Erstellen einer App.
‫Und so hoffe ich, dass Ihnen diese Anwendung
‫als gutes Beispiel dient und Ihnen das
‫Wissen vermittelt, um später im Grunde komplett eigenständig
‫eigene Datenmodelle zu entwerfen.
‫Also lass es uns jetzt tun.
‫Beginnen wir mit allen Datensätzen,
‫die wir in unserer Anwendung tatsächlich benötigen.
‫Beginnen Sie also mit den
‫Touren, und das ist natürlich die naheliegendste.
‫Und diese haben wir bereits umgesetzt.
‫Dann brauchen wir auch einige Benutzer.
‫Und wieder haben wir bereits eine Benutzersammlung in
‫unserer Datenbank.
‫Touren und Benutzer sind also
‫im Grunde zwei völlig separate Datensätze.
‫Und so haben wir sie normalisiert.
‫Und natürlich werden sie nicht eingebettet.
‫Als nächstes werden wir auch Bewertungen haben und
‫wir werden auch Standorte haben.
‫Okay?
‫Denn die meisten Touren haben tatsächlich
‫mehrere verschiedene Orte.
‫Okay?
‫Und das ist wieder ein weiterer Datensatz.
‫Und schließlich werden wir auch Buchungen haben.
‫Aber ein bisschen mehr darüber, warum das in einer Sekunde ist.
‫Okay, wir haben alle diese Datensätze.
‫Lassen Sie uns nun tatsächlich die Beziehungen modellieren,
‫die zwischen ihnen bestehen.
‫Und ich werde mit
‫der Beziehung zwischen Benutzern und Bewertungen beginnen.
‫Und diese Beziehung ist eindeutig eine 1:n-Beziehung, da ein Benutzer
‫mehrere Bewertungen schreiben kann, eine Bewertung jedoch
‫nur einem Benutzer gehören kann.
‫Und das Elternteil in dieser Beziehung sind eindeutig die Benutzer
‫und das Kind die
‫Bewertungen, denn wiederum sind es die Eltern, also die Benutzer in diesem Fall,
‫die mit vielen Bewertungen in Verbindung gebracht werden
‫können, aber eine Bewertung kann nur einem Benutzer zugeordnet werden.
‫Wie auch immer, ich habe mich entschieden, diese Beziehung
‫mithilfe von Elternreferenzen zu modellieren.
‫Und das liegt daran, dass ein Benutzer viele Bewertungen
‫schreiben kann und wir möglicherweise nur die
‫Bewertungen selbst abfragen müssen.
‫Daher ist es sehr wichtig,
‫das Datenachsenmuster in dieser speziellen Beziehung zu berücksichtigen.
‫Nun zu der Art der Referenzierung, die wir verwenden
‫werden, es ist die Elternreferenzierung,
‫also im Grunde genommen die Überprüfung, die eine Referenz des Benutzers behält.
‫Also grundsätzlich einen Ausweis führen.
‫Und das liegt, wie Sie
‫bereits wissen, daran, dass wir nicht zulassen wollen, dass eine Rasse auf unbestimmte Zeit wächst.
‫Und das kann
‫der Fall sein, wenn ein Benutzer tonnenweise (lacht) Bewertungen schreibt.
‫Okay?
‫Außerdem ist es schön, wenn die Rezension weiß, wer
‫sie tatsächlich geschrieben hat.
‫Okay?
‫Und wenn wir die Benutzer-ID direkt in der Bewertung
‫haben, werden wir genau das tun.
‫Gut.
‫Als nächstes werfen
‫wir einen Blick auf die Beziehung zwischen Touren und Bewertungen.
‫Und dieser ist tatsächlich sehr ähnlich.
‫Auch hier handelt es sich um eine Eins-zu-Viele-Beziehung,
‫bei der eine Tour mehrere Bewertungen haben
‫kann, aber eine Bewertung nur eine Tour betreffen kann.
‫Rechts?
‫So macht es also Sinn.
‫Und wir werden es also genau so modellieren wie die
‫Beziehung zwischen Benutzern und Bewertungen.
‫Also wieder Elternreferenzierung, damit
‫die Bewertungen am Ende mit
‫einer Tour-ID und einer Benutzer-ID enden.
‫Wenn wir also einmal nach Bewertungen fragen, wissen
‫wir es immer genau.
‫Großartig, also lassen Sie uns jetzt über die
‫Beziehung zwischen Touren und Orten sprechen.
‫Wie ich bereits
‫erwähnt habe, wird jede Tour mehrere Orte haben.
‫So wird der Parkcamper zum Beispiel im Grunde in
‫drei oder vier Nationalparks Halt machen.
‫Und so wird jeder dieser
‫Nationalparks ein Ort sein.
‫Rechts?
‫Und so wird jede Tour im Grunde genommen ein paar Orte haben.
‫Nun, diesem Beispiel folgend, könnte einer dieser
‫Nationalparks auch Teil einer der anderen Touren sein.
‫Und im Grunde ist diese Beziehung
‫hier eine Beziehung von wenigen zu wenigen.
‫Und wir haben diese Beziehung früher viele-zu-viele genannt, aber
‫wir können sie immer noch auch wenige zu wenigen
‫oder eine Tonne zu einer Tonne nennen.
‫Und so nannte ich
‫sie einige wenige, weil jede Tour nur drei, vier Orte haben
‫wird, aber nicht wirklich 100.
‫Okay?
‫Und wieder kann jeder der Orte auch Teil einer
‫anderen Tour sein.
‫Nun, dies könnte ein gutes Beispiel für die
‫tatsächliche Implementierung von Zwei-Wege-Referenzen sein, also im Grunde die Standorte in
‫einen eigenen Datensatz normalisieren.
‫Rechts?
‫Aber stattdessen werde ich die Orte denormalisieren,
‫um sie in die Touren einzubetten.
‫Und das hat tatsächlich mehrere Gründe.
‫Erstens, weil es nur so wenige Standorte gibt.
‫Außerdem werden wir nicht wirklich alleine auf
‫die Orte zugreifen.
‫Und schließlich sind diese Orte untrennbar mit
‫den Touren verbunden, denn ohne Orte könnte es
‫keine Touren geben.
‫Rechts?
‫Diese Datensätze gehören also eng zusammen.
‫Und so habe ich mich entschieden, Orte in Touren einzubetten
‫und dafür keine weitere Sammlung zu erstellen.
‫Rechts?
‫Wir werden also eine Sammlung für Touren haben, eine für Benutzer
‫und etwas später werden wir auch eine neue Sammlung
‫für die Bewertungen erstellen.
‫Gut?
‫Aber auch für Locations, denn diese werden in die
‫Touren eingebettet.
‫Okay, und als nächstes gibt es auch eine Beziehung
‫zwischen den Touren und den Benutzern.
‫Und das liegt daran, dass wir
‫Reiseleiter in den Touren haben werden, und diese Reiseleiter werden tatsächlich Benutzer sein.
‫Erinnern Sie sich also daran, wie wir Benutzern in unserem Mongoose-Schema
‫tatsächlich eine Rolle gegeben haben?
‫Und die Möglichkeiten dort enthielten der Führer und
‫der Leitführer, erinnern Sie sich?
‫Es wird also
‫eine Beziehung zwischen diesen Benutzertypen und den Touren geben.
‫Nun ist diese Beziehung wieder eine wenige-zu-wenige Beziehung, da
‫eine Tour nur wenige Benutzer haben
‫kann, also einige Tourguides, aber
‫gleichzeitig kann jeder Tourguide auch einige Touren führen.
‫Gut?
‫Und wieder gibt es hier eine Many-to-Many-Beziehung, die ich
‫hier einfach nur wenige-to-wenige genannt habe.
‫Nun, um diese Beziehung tatsächlich zu modellieren, könnten
‫wir dies auf zwei Arten tun.
‫Wir könnten eine Referenzierung oder Einbettung verwenden.
‫Und tatsächlich werde ich Ihnen in
‫diesem Abschnitt zeigen, wie Sie die Einbettung beider Kindreferenzen
‫mit Mongoose implementieren.
‫Okay?
‫Und das Argument für die Einbettung ist, dass wir
‫in diesem Fall dann alle Informationen zu jeder
‫Tour mit den Informationen zu
‫Tourguides direkt auf jedem Tourdokument haben könnten.
‫Aber auf der anderen Seite würde
‫das dann einige zusätzliche Informationen in der
‫Datenbank erzeugen, weil wir die Benutzer immer
‫noch als separate Sammlung
‫haben müssen, einfach weil wir ständig auf sie für die
‫Benutzerauthentifizierung und -autorisierung und all das Zeug
‫zugreifen müssen.
‫Normalerweise sind Benutzer in jeder Datenbank also immer eine
‫eigene Entität.
‫Okay?
‫Aber wir konnten noch einige der User in die Touren einbinden.
‫Wenn der Benutzer also ein Tourguide
‫für eine bestimmte Tour ist, könnten wir alle diese Daten
‫in das Tourdokument kopieren.
‫Okay?
‫Aber auch wir müssten dann den Benutzer auf der Tour jedes
‫Mal aktualisieren, wenn sich der zugrunde liegende Benutzer selbst ändert.
‫Nehmen wir also an, dass sich die Rolle eines Benutzers
‫von einem Guide zu einem Lead Guide ändert.
‫Und in diesem Fall müssten wir dann zur
‫Tour gehen und diese Rolleninformationen direkt dort
‫in den eingebetteten Daten aktualisieren.
‫Okay?
‫Und das ist nicht ideal, und deshalb
‫werden wir dann auch die Referenzierung von Kindern implementieren.
‫Und damit können wir
‫im Wesentlichen die Informationen über die
‫Tourguides zu den Benutzern behalten, aber einfach in einer referenzierten
‫Form, also im Wesentlichen die IDs
‫dort aufbewahren, die dann auf die Benutzer verweisen.
‫Okay?
‫Und natürlich könnten wir auch eine bidirektionale Referenzierung
‫verwenden, also auch eine ID der Tour direkt beim Benutzer behalten.
‫Aber ich denke,
‫das ist etwas zu viel für so
‫ein kleines Beispiel, da nicht alle Benutzer tatsächlich eine ID der
‫Tour benötigen, da nicht alle Benutzer Tourguides sind.
‫Also, diese Beziehung hier ist ein bisschen schwierig zu modellieren, denke
‫ich, aber ich glaube, dass
‫die Bezugnahme auf Kinder am Ende der beste Weg sein wird.
‫Okay?
‫Aber trotzdem werde ich dir auch das Einbetten
‫zeigen, weil ich denke, dass es auch wichtig ist, das zu lernen.
‫Gut?
‫Als nächstes haben wir unsere Buchungen.
‫Und grundsätzlich wird jedes Mal, wenn
‫ein Benutzer eine Tour kauft, eine neue Buchung erstellt.
‫Dies ist also immer noch eine
‫Art Beziehung zwischen Benutzern und
‫Touren, denn wieder ist es ein Benutzer, der eine Tour kauft.
‫Wir möchten aber auch einige
‫Daten über diese Beziehung selbst, also
‫in diesem Fall über den Kauf selbst, in unserer Datenbank speichern.
‫Zum Beispiel der Preis oder
‫das Datum, an dem der Kauf stattgefunden hat oder ähnliches.
‫In solchen Fällen
‫ist es daher ratsam, einen zusätzlichen Datensatz zu
‫erstellen, in diesem Fall die Buchungen.
‫Okay?
‫Und so wird es natürlich
‫einen Zusammenhang zwischen Touren und Buchungen sowie Benutzern und Buchungen geben.
‫Und wiederum, weil die Buchung grundsätzlich Touren mit den
‫Nutzern verbindet, aber irgendwie mit einem Zwischenschritt.
‫Eine Tour kann also viele Buchungen haben,
‫aber eine Buchung kann nur zu einer Tour gehören.
‫Und das gleiche mit Benutzern.
‫So kann ein Benutzer viele Touren
‫buchen, aber eine Buchung kann nur einem der Benutzer gehören.
‫Und natürlich haben wir in beiden Fällen
‫eine Eins-zu-Viele-Beziehung, und auch in beiden Fällen
‫werden wir die Elternreferenzierung verwenden.
‫Das bedeutet, dass wir bei jeder
‫Buchung eine ID sowohl der gekauften Tour als auch des Benutzers
‫aufbewahren, der die Tour tatsächlich gekauft hat.
‫Okay?
‫Und in diesem Fall mache
‫ich das so, weil ich die Tourdaten im Grunde nicht
‫mit Informationen darüber belasten möchte, wer die Tour tatsächlich gekauft hat.
‫Rechts?
‫Es wäre nicht wirklich relevant für die Tourdaten selbst.
‫Und das gleiche mit Benutzern.
‫Wir wollen also auch nicht das Nutzerobjekt
‫mit all ihren Buchungen belasten.
‫Gut?
‫Und stattdessen
‫erstellen wir wieder ein Zwischenobjekt oder
‫einen Zwischendatensatz, der zwischen Benutzern
‫und Touren steht, wenn sie einen neuen Kauf erstellen.
‫Rechts?
‫Sinn ergeben?
‫Und das war es eigentlich schon für unser Datenmodell.
‫Und natürlich sieht das jetzt irgendwie abstrakt aus, aber wenn wir
‫erst einmal mit der Umsetzung
‫beginnen, wird es
‫sehr hilfreich sein, all unsere Ideen in so etwas zu organisieren.
‫Wenn Ihnen dieses Datenmodell, das wir in
‫diesem Abschnitt implementieren werden, etwas verwirrend erscheint, dann verweisen
‫Sie einfach auf diese Folie.
‫Oder Sie können es vielleicht sogar ausdrucken,
‫wenn es Ihnen das leichter macht.
‫Das ist also theoretisch unser Datenmodell.
‫Und jetzt werde ich Ihnen im weiteren Verlauf
‫des Kurses die Werkzeuge an die Hand geben, um die Daten tatsächlich
‫mit der Mongoose Library zu modellieren.