1 00:00:01,150 --> 00:00:02,540 ‫Jonas: In der letzten 2 00:00:02,540 --> 00:00:04,990 ‫Vorlesung haben wir also eine Theorie zur Datenmodellierung gelernt. 3 00:00:04,990 --> 00:00:07,430 ‫Lassen Sie uns diese Theorie 4 00:00:07,430 --> 00:00:09,930 ‫nun verwenden, um das Datenmodell unserer 5 00:00:09,930 --> 00:00:12,140 ‫Natours-Anwendung tatsächlich zu entwerfen. 6 00:00:12,140 --> 00:00:15,160 ‫Und das ist für mich und für viele 7 00:00:15,160 --> 00:00:18,400 ‫andere Entwickler tatsächlich der schwierigste Teil beim Erstellen einer App. 8 00:00:18,400 --> 00:00:21,570 ‫Und so hoffe ich, dass Ihnen diese Anwendung 9 00:00:21,570 --> 00:00:24,660 ‫als gutes Beispiel dient und Ihnen das 10 00:00:24,660 --> 00:00:27,860 ‫Wissen vermittelt, um später im Grunde komplett eigenständig 11 00:00:27,860 --> 00:00:29,663 ‫eigene Datenmodelle zu entwerfen. 12 00:00:30,640 --> 00:00:32,130 ‫Also lass es uns jetzt tun. 13 00:00:32,130 --> 00:00:34,560 ‫Beginnen wir mit allen Datensätzen, 14 00:00:34,560 --> 00:00:37,690 ‫die wir in unserer Anwendung tatsächlich benötigen. 15 00:00:37,690 --> 00:00:39,430 ‫Beginnen Sie also mit den 16 00:00:39,430 --> 00:00:41,630 ‫Touren, und das ist natürlich die naheliegendste. 17 00:00:41,630 --> 00:00:44,730 ‫Und diese haben wir bereits umgesetzt. 18 00:00:44,730 --> 00:00:47,150 ‫Dann brauchen wir auch einige Benutzer. 19 00:00:47,150 --> 00:00:50,590 ‫Und wieder haben wir bereits eine Benutzersammlung in 20 00:00:50,590 --> 00:00:51,870 ‫unserer Datenbank. 21 00:00:51,870 --> 00:00:54,020 ‫Touren und Benutzer sind also 22 00:00:54,020 --> 00:00:56,470 ‫im Grunde zwei völlig separate Datensätze. 23 00:00:56,470 --> 00:00:58,270 ‫Und so haben wir sie normalisiert. 24 00:00:58,270 --> 00:01:00,593 ‫Und natürlich werden sie nicht eingebettet. 25 00:01:01,540 --> 00:01:04,270 ‫Als nächstes werden wir auch Bewertungen haben und 26 00:01:04,270 --> 00:01:06,360 ‫wir werden auch Standorte haben. 27 00:01:06,360 --> 00:01:07,300 ‫Okay? 28 00:01:07,300 --> 00:01:09,380 ‫Denn die meisten Touren haben tatsächlich 29 00:01:09,380 --> 00:01:10,930 ‫mehrere verschiedene Orte. 30 00:01:10,930 --> 00:01:11,763 ‫Okay? 31 00:01:11,763 --> 00:01:14,600 ‫Und das ist wieder ein weiterer Datensatz. 32 00:01:14,600 --> 00:01:17,300 ‫Und schließlich werden wir auch Buchungen haben. 33 00:01:17,300 --> 00:01:20,780 ‫Aber ein bisschen mehr darüber, warum das in einer Sekunde ist. 34 00:01:20,780 --> 00:01:23,320 ‫Okay, wir haben alle diese Datensätze. 35 00:01:23,320 --> 00:01:25,950 ‫Lassen Sie uns nun tatsächlich die Beziehungen modellieren, 36 00:01:25,950 --> 00:01:27,480 ‫die zwischen ihnen bestehen. 37 00:01:27,480 --> 00:01:29,100 ‫Und ich werde mit 38 00:01:29,100 --> 00:01:31,470 ‫der Beziehung zwischen Benutzern und Bewertungen beginnen. 39 00:01:31,470 --> 00:01:36,100 ‫Und diese Beziehung ist eindeutig eine 1:n-Beziehung, da ein Benutzer 40 00:01:36,100 --> 00:01:39,260 ‫mehrere Bewertungen schreiben kann, eine Bewertung jedoch 41 00:01:39,260 --> 00:01:42,360 ‫nur einem Benutzer gehören kann. 42 00:01:42,360 --> 00:01:45,550 ‫Und das Elternteil in dieser Beziehung sind eindeutig die Benutzer 43 00:01:45,550 --> 00:01:47,240 ‫und das Kind die 44 00:01:47,240 --> 00:01:51,160 ‫Bewertungen, denn wiederum sind es die Eltern, also die Benutzer in diesem Fall, 45 00:01:51,160 --> 00:01:53,560 ‫die mit vielen Bewertungen in Verbindung gebracht werden 46 00:01:53,560 --> 00:01:56,730 ‫können, aber eine Bewertung kann nur einem Benutzer zugeordnet werden. 47 00:01:56,730 --> 00:01:59,290 ‫Wie auch immer, ich habe mich entschieden, diese Beziehung 48 00:01:59,290 --> 00:02:01,160 ‫mithilfe von Elternreferenzen zu modellieren. 49 00:02:01,160 --> 00:02:04,830 ‫Und das liegt daran, dass ein Benutzer viele Bewertungen 50 00:02:04,830 --> 00:02:07,490 ‫schreiben kann und wir möglicherweise nur die 51 00:02:07,490 --> 00:02:09,600 ‫Bewertungen selbst abfragen müssen. 52 00:02:09,600 --> 00:02:12,490 ‫Daher ist es sehr wichtig, 53 00:02:12,490 --> 00:02:16,300 ‫das Datenachsenmuster in dieser speziellen Beziehung zu berücksichtigen. 54 00:02:16,300 --> 00:02:18,940 ‫Nun zu der Art der Referenzierung, die wir verwenden 55 00:02:18,940 --> 00:02:20,610 ‫werden, es ist die Elternreferenzierung, 56 00:02:20,610 --> 00:02:24,220 ‫also im Grunde genommen die Überprüfung, die eine Referenz des Benutzers behält. 57 00:02:24,220 --> 00:02:26,670 ‫Also grundsätzlich einen Ausweis führen. 58 00:02:26,670 --> 00:02:28,220 ‫Und das liegt, wie Sie 59 00:02:28,220 --> 00:02:32,510 ‫bereits wissen, daran, dass wir nicht zulassen wollen, dass eine Rasse auf unbestimmte Zeit wächst. 60 00:02:32,510 --> 00:02:33,940 ‫Und das kann 61 00:02:33,940 --> 00:02:37,860 ‫der Fall sein, wenn ein Benutzer tonnenweise (lacht) Bewertungen schreibt. 62 00:02:37,860 --> 00:02:38,930 ‫Okay? 63 00:02:38,930 --> 00:02:41,790 ‫Außerdem ist es schön, wenn die Rezension weiß, wer 64 00:02:41,790 --> 00:02:43,220 ‫sie tatsächlich geschrieben hat. 65 00:02:43,220 --> 00:02:44,053 ‫Okay? 66 00:02:44,053 --> 00:02:46,440 ‫Und wenn wir die Benutzer-ID direkt in der Bewertung 67 00:02:46,440 --> 00:02:48,273 ‫haben, werden wir genau das tun. 68 00:02:49,120 --> 00:02:49,953 ‫Gut. 69 00:02:49,953 --> 00:02:51,060 ‫Als nächstes werfen 70 00:02:51,060 --> 00:02:54,310 ‫wir einen Blick auf die Beziehung zwischen Touren und Bewertungen. 71 00:02:54,310 --> 00:02:56,580 ‫Und dieser ist tatsächlich sehr ähnlich. 72 00:02:56,580 --> 00:02:59,450 ‫Auch hier handelt es sich um eine Eins-zu-Viele-Beziehung, 73 00:02:59,450 --> 00:03:02,070 ‫bei der eine Tour mehrere Bewertungen haben 74 00:03:02,070 --> 00:03:05,260 ‫kann, aber eine Bewertung nur eine Tour betreffen kann. 75 00:03:05,260 --> 00:03:06,093 ‫Rechts? 76 00:03:06,093 --> 00:03:07,810 ‫So macht es also Sinn. 77 00:03:07,810 --> 00:03:11,180 ‫Und wir werden es also genau so modellieren wie die 78 00:03:11,180 --> 00:03:13,380 ‫Beziehung zwischen Benutzern und Bewertungen. 79 00:03:13,380 --> 00:03:15,460 ‫Also wieder Elternreferenzierung, damit 80 00:03:15,460 --> 00:03:17,670 ‫die Bewertungen am Ende mit 81 00:03:17,670 --> 00:03:20,530 ‫einer Tour-ID und einer Benutzer-ID enden. 82 00:03:20,530 --> 00:03:23,270 ‫Wenn wir also einmal nach Bewertungen fragen, wissen 83 00:03:23,270 --> 00:03:25,040 ‫wir es immer genau. 84 00:03:25,040 --> 00:03:27,930 ‫Großartig, also lassen Sie uns jetzt über die 85 00:03:27,930 --> 00:03:30,800 ‫Beziehung zwischen Touren und Orten sprechen. 86 00:03:30,800 --> 00:03:32,230 ‫Wie ich bereits 87 00:03:32,230 --> 00:03:35,230 ‫erwähnt habe, wird jede Tour mehrere Orte haben. 88 00:03:35,230 --> 00:03:38,680 ‫So wird der Parkcamper zum Beispiel im Grunde in 89 00:03:38,680 --> 00:03:41,080 ‫drei oder vier Nationalparks Halt machen. 90 00:03:41,080 --> 00:03:43,150 ‫Und so wird jeder dieser 91 00:03:43,150 --> 00:03:45,120 ‫Nationalparks ein Ort sein. 92 00:03:45,120 --> 00:03:45,953 ‫Rechts? 93 00:03:45,953 --> 00:03:49,700 ‫Und so wird jede Tour im Grunde genommen ein paar Orte haben. 94 00:03:49,700 --> 00:03:52,730 ‫Nun, diesem Beispiel folgend, könnte einer dieser 95 00:03:52,730 --> 00:03:55,930 ‫Nationalparks auch Teil einer der anderen Touren sein. 96 00:03:55,930 --> 00:03:58,260 ‫Und im Grunde ist diese Beziehung 97 00:03:58,260 --> 00:04:00,770 ‫hier eine Beziehung von wenigen zu wenigen. 98 00:04:00,770 --> 00:04:03,630 ‫Und wir haben diese Beziehung früher viele-zu-viele genannt, aber 99 00:04:03,630 --> 00:04:06,480 ‫wir können sie immer noch auch wenige zu wenigen 100 00:04:06,480 --> 00:04:08,910 ‫oder eine Tonne zu einer Tonne nennen. 101 00:04:08,910 --> 00:04:10,850 ‫Und so nannte ich 102 00:04:10,850 --> 00:04:15,290 ‫sie einige wenige, weil jede Tour nur drei, vier Orte haben 103 00:04:15,290 --> 00:04:17,460 ‫wird, aber nicht wirklich 100. 104 00:04:17,460 --> 00:04:18,370 ‫Okay? 105 00:04:18,370 --> 00:04:21,540 ‫Und wieder kann jeder der Orte auch Teil einer 106 00:04:21,540 --> 00:04:23,060 ‫anderen Tour sein. 107 00:04:23,060 --> 00:04:26,210 ‫Nun, dies könnte ein gutes Beispiel für die 108 00:04:26,210 --> 00:04:30,670 ‫tatsächliche Implementierung von Zwei-Wege-Referenzen sein, also im Grunde die Standorte in 109 00:04:30,670 --> 00:04:32,480 ‫einen eigenen Datensatz normalisieren. 110 00:04:32,480 --> 00:04:33,313 ‫Rechts? 111 00:04:33,313 --> 00:04:36,330 ‫Aber stattdessen werde ich die Orte denormalisieren, 112 00:04:36,330 --> 00:04:39,270 ‫um sie in die Touren einzubetten. 113 00:04:39,270 --> 00:04:41,350 ‫Und das hat tatsächlich mehrere Gründe. 114 00:04:41,350 --> 00:04:44,500 ‫Erstens, weil es nur so wenige Standorte gibt. 115 00:04:44,500 --> 00:04:47,400 ‫Außerdem werden wir nicht wirklich alleine auf 116 00:04:47,400 --> 00:04:48,690 ‫die Orte zugreifen. 117 00:04:48,690 --> 00:04:51,890 ‫Und schließlich sind diese Orte untrennbar mit 118 00:04:51,890 --> 00:04:55,400 ‫den Touren verbunden, denn ohne Orte könnte es 119 00:04:55,400 --> 00:04:57,280 ‫keine Touren geben. 120 00:04:57,280 --> 00:04:58,113 ‫Rechts? 121 00:04:58,113 --> 00:05:00,480 ‫Diese Datensätze gehören also eng zusammen. 122 00:05:00,480 --> 00:05:04,030 ‫Und so habe ich mich entschieden, Orte in Touren einzubetten 123 00:05:04,030 --> 00:05:06,580 ‫und dafür keine weitere Sammlung zu erstellen. 124 00:05:06,580 --> 00:05:07,413 ‫Rechts? 125 00:05:07,413 --> 00:05:10,750 ‫Wir werden also eine Sammlung für Touren haben, eine für Benutzer 126 00:05:10,750 --> 00:05:13,330 ‫und etwas später werden wir auch eine neue Sammlung 127 00:05:13,330 --> 00:05:14,710 ‫für die Bewertungen erstellen. 128 00:05:14,710 --> 00:05:15,543 ‫Gut? 129 00:05:15,543 --> 00:05:18,860 ‫Aber auch für Locations, denn diese werden in die 130 00:05:18,860 --> 00:05:19,793 ‫Touren eingebettet. 131 00:05:20,640 --> 00:05:23,710 ‫Okay, und als nächstes gibt es auch eine Beziehung 132 00:05:23,710 --> 00:05:26,250 ‫zwischen den Touren und den Benutzern. 133 00:05:26,250 --> 00:05:28,780 ‫Und das liegt daran, dass wir 134 00:05:28,780 --> 00:05:33,150 ‫Reiseleiter in den Touren haben werden, und diese Reiseleiter werden tatsächlich Benutzer sein. 135 00:05:33,150 --> 00:05:36,270 ‫Erinnern Sie sich also daran, wie wir Benutzern in unserem Mongoose-Schema 136 00:05:36,270 --> 00:05:37,760 ‫tatsächlich eine Rolle gegeben haben? 137 00:05:37,760 --> 00:05:40,770 ‫Und die Möglichkeiten dort enthielten der Führer und 138 00:05:40,770 --> 00:05:43,020 ‫der Leitführer, erinnern Sie sich? 139 00:05:43,020 --> 00:05:44,670 ‫Es wird also 140 00:05:44,670 --> 00:05:48,210 ‫eine Beziehung zwischen diesen Benutzertypen und den Touren geben. 141 00:05:48,210 --> 00:05:52,240 ‫Nun ist diese Beziehung wieder eine wenige-zu-wenige Beziehung, da 142 00:05:52,240 --> 00:05:55,550 ‫eine Tour nur wenige Benutzer haben 143 00:05:55,550 --> 00:05:58,410 ‫kann, also einige Tourguides, aber 144 00:05:58,410 --> 00:06:02,150 ‫gleichzeitig kann jeder Tourguide auch einige Touren führen. 145 00:06:02,150 --> 00:06:02,983 ‫Gut? 146 00:06:02,983 --> 00:06:06,490 ‫Und wieder gibt es hier eine Many-to-Many-Beziehung, die ich 147 00:06:06,490 --> 00:06:09,270 ‫hier einfach nur wenige-to-wenige genannt habe. 148 00:06:09,270 --> 00:06:12,140 ‫Nun, um diese Beziehung tatsächlich zu modellieren, könnten 149 00:06:12,140 --> 00:06:14,410 ‫wir dies auf zwei Arten tun. 150 00:06:14,410 --> 00:06:17,280 ‫Wir könnten eine Referenzierung oder Einbettung verwenden. 151 00:06:17,280 --> 00:06:19,620 ‫Und tatsächlich werde ich Ihnen in 152 00:06:19,620 --> 00:06:22,830 ‫diesem Abschnitt zeigen, wie Sie die Einbettung beider Kindreferenzen 153 00:06:22,830 --> 00:06:24,410 ‫mit Mongoose implementieren. 154 00:06:24,410 --> 00:06:25,620 ‫Okay? 155 00:06:25,620 --> 00:06:28,800 ‫Und das Argument für die Einbettung ist, dass wir 156 00:06:28,800 --> 00:06:31,930 ‫in diesem Fall dann alle Informationen zu jeder 157 00:06:31,930 --> 00:06:34,310 ‫Tour mit den Informationen zu 158 00:06:34,310 --> 00:06:36,700 ‫Tourguides direkt auf jedem Tourdokument haben könnten. 159 00:06:36,700 --> 00:06:38,710 ‫Aber auf der anderen Seite würde 160 00:06:38,710 --> 00:06:41,120 ‫das dann einige zusätzliche Informationen in der 161 00:06:41,120 --> 00:06:43,670 ‫Datenbank erzeugen, weil wir die Benutzer immer 162 00:06:43,670 --> 00:06:45,210 ‫noch als separate Sammlung 163 00:06:45,210 --> 00:06:48,700 ‫haben müssen, einfach weil wir ständig auf sie für die 164 00:06:48,700 --> 00:06:51,250 ‫Benutzerauthentifizierung und -autorisierung und all das Zeug 165 00:06:51,250 --> 00:06:52,510 ‫zugreifen müssen. 166 00:06:52,510 --> 00:06:56,290 ‫Normalerweise sind Benutzer in jeder Datenbank also immer eine 167 00:06:56,290 --> 00:06:57,700 ‫eigene Entität. 168 00:06:57,700 --> 00:06:58,533 ‫Okay? 169 00:06:58,533 --> 00:07:02,380 ‫Aber wir konnten noch einige der User in die Touren einbinden. 170 00:07:02,380 --> 00:07:04,750 ‫Wenn der Benutzer also ein Tourguide 171 00:07:04,750 --> 00:07:08,190 ‫für eine bestimmte Tour ist, könnten wir alle diese Daten 172 00:07:08,190 --> 00:07:09,950 ‫in das Tourdokument kopieren. 173 00:07:09,950 --> 00:07:10,783 ‫Okay? 174 00:07:10,783 --> 00:07:14,230 ‫Aber auch wir müssten dann den Benutzer auf der Tour jedes 175 00:07:14,230 --> 00:07:17,590 ‫Mal aktualisieren, wenn sich der zugrunde liegende Benutzer selbst ändert. 176 00:07:17,590 --> 00:07:19,710 ‫Nehmen wir also an, dass sich die Rolle eines Benutzers 177 00:07:19,710 --> 00:07:21,690 ‫von einem Guide zu einem Lead Guide ändert. 178 00:07:21,690 --> 00:07:24,410 ‫Und in diesem Fall müssten wir dann zur 179 00:07:24,410 --> 00:07:26,850 ‫Tour gehen und diese Rolleninformationen direkt dort 180 00:07:26,850 --> 00:07:28,840 ‫in den eingebetteten Daten aktualisieren. 181 00:07:28,840 --> 00:07:29,673 ‫Okay? 182 00:07:29,673 --> 00:07:32,320 ‫Und das ist nicht ideal, und deshalb 183 00:07:32,320 --> 00:07:35,350 ‫werden wir dann auch die Referenzierung von Kindern implementieren. 184 00:07:35,350 --> 00:07:37,280 ‫Und damit können wir 185 00:07:37,280 --> 00:07:39,590 ‫im Wesentlichen die Informationen über die 186 00:07:39,590 --> 00:07:42,860 ‫Tourguides zu den Benutzern behalten, aber einfach in einer referenzierten 187 00:07:42,860 --> 00:07:44,930 ‫Form, also im Wesentlichen die IDs 188 00:07:44,930 --> 00:07:47,630 ‫dort aufbewahren, die dann auf die Benutzer verweisen. 189 00:07:47,630 --> 00:07:48,463 ‫Okay? 190 00:07:48,463 --> 00:07:51,370 ‫Und natürlich könnten wir auch eine bidirektionale Referenzierung 191 00:07:51,370 --> 00:07:55,100 ‫verwenden, also auch eine ID der Tour direkt beim Benutzer behalten. 192 00:07:55,100 --> 00:07:56,650 ‫Aber ich denke, 193 00:07:56,650 --> 00:07:59,140 ‫das ist etwas zu viel für so 194 00:07:59,140 --> 00:08:02,850 ‫ein kleines Beispiel, da nicht alle Benutzer tatsächlich eine ID der 195 00:08:02,850 --> 00:08:05,580 ‫Tour benötigen, da nicht alle Benutzer Tourguides sind. 196 00:08:05,580 --> 00:08:08,870 ‫Also, diese Beziehung hier ist ein bisschen schwierig zu modellieren, denke 197 00:08:08,870 --> 00:08:10,800 ‫ich, aber ich glaube, dass 198 00:08:10,800 --> 00:08:14,200 ‫die Bezugnahme auf Kinder am Ende der beste Weg sein wird. 199 00:08:14,200 --> 00:08:15,033 ‫Okay? 200 00:08:15,033 --> 00:08:17,220 ‫Aber trotzdem werde ich dir auch das Einbetten 201 00:08:17,220 --> 00:08:20,120 ‫zeigen, weil ich denke, dass es auch wichtig ist, das zu lernen. 202 00:08:20,120 --> 00:08:21,400 ‫Gut? 203 00:08:21,400 --> 00:08:23,530 ‫Als nächstes haben wir unsere Buchungen. 204 00:08:23,530 --> 00:08:26,130 ‫Und grundsätzlich wird jedes Mal, wenn 205 00:08:26,130 --> 00:08:29,340 ‫ein Benutzer eine Tour kauft, eine neue Buchung erstellt. 206 00:08:29,340 --> 00:08:31,340 ‫Dies ist also immer noch eine 207 00:08:31,340 --> 00:08:33,240 ‫Art Beziehung zwischen Benutzern und 208 00:08:33,240 --> 00:08:36,950 ‫Touren, denn wieder ist es ein Benutzer, der eine Tour kauft. 209 00:08:36,950 --> 00:08:38,810 ‫Wir möchten aber auch einige 210 00:08:38,810 --> 00:08:40,920 ‫Daten über diese Beziehung selbst, also 211 00:08:40,920 --> 00:08:44,450 ‫in diesem Fall über den Kauf selbst, in unserer Datenbank speichern. 212 00:08:44,450 --> 00:08:46,430 ‫Zum Beispiel der Preis oder 213 00:08:46,430 --> 00:08:49,560 ‫das Datum, an dem der Kauf stattgefunden hat oder ähnliches. 214 00:08:49,560 --> 00:08:50,810 ‫In solchen Fällen 215 00:08:50,810 --> 00:08:53,750 ‫ist es daher ratsam, einen zusätzlichen Datensatz zu 216 00:08:53,750 --> 00:08:55,920 ‫erstellen, in diesem Fall die Buchungen. 217 00:08:55,920 --> 00:08:56,753 ‫Okay? 218 00:08:56,753 --> 00:08:58,710 ‫Und so wird es natürlich 219 00:08:58,710 --> 00:09:02,398 ‫einen Zusammenhang zwischen Touren und Buchungen sowie Benutzern und Buchungen geben. 220 00:09:02,398 --> 00:09:06,150 ‫Und wiederum, weil die Buchung grundsätzlich Touren mit den 221 00:09:06,150 --> 00:09:09,763 ‫Nutzern verbindet, aber irgendwie mit einem Zwischenschritt. 222 00:09:09,763 --> 00:09:12,530 ‫Eine Tour kann also viele Buchungen haben, 223 00:09:12,530 --> 00:09:15,760 ‫aber eine Buchung kann nur zu einer Tour gehören. 224 00:09:15,760 --> 00:09:17,350 ‫Und das gleiche mit Benutzern. 225 00:09:17,350 --> 00:09:19,870 ‫So kann ein Benutzer viele Touren 226 00:09:19,870 --> 00:09:23,610 ‫buchen, aber eine Buchung kann nur einem der Benutzer gehören. 227 00:09:23,610 --> 00:09:26,380 ‫Und natürlich haben wir in beiden Fällen 228 00:09:26,380 --> 00:09:29,080 ‫eine Eins-zu-Viele-Beziehung, und auch in beiden Fällen 229 00:09:29,080 --> 00:09:31,140 ‫werden wir die Elternreferenzierung verwenden. 230 00:09:31,140 --> 00:09:33,610 ‫Das bedeutet, dass wir bei jeder 231 00:09:33,610 --> 00:09:37,640 ‫Buchung eine ID sowohl der gekauften Tour als auch des Benutzers 232 00:09:37,640 --> 00:09:40,270 ‫aufbewahren, der die Tour tatsächlich gekauft hat. 233 00:09:40,270 --> 00:09:41,103 ‫Okay? 234 00:09:41,103 --> 00:09:42,930 ‫Und in diesem Fall mache 235 00:09:42,930 --> 00:09:46,140 ‫ich das so, weil ich die Tourdaten im Grunde nicht 236 00:09:46,140 --> 00:09:49,510 ‫mit Informationen darüber belasten möchte, wer die Tour tatsächlich gekauft hat. 237 00:09:49,510 --> 00:09:50,343 ‫Rechts? 238 00:09:50,343 --> 00:09:53,157 ‫Es wäre nicht wirklich relevant für die Tourdaten selbst. 239 00:09:53,157 --> 00:09:55,070 ‫Und das gleiche mit Benutzern. 240 00:09:55,070 --> 00:09:58,370 ‫Wir wollen also auch nicht das Nutzerobjekt 241 00:09:58,370 --> 00:10:00,740 ‫mit all ihren Buchungen belasten. 242 00:10:00,740 --> 00:10:01,573 ‫Gut? 243 00:10:01,573 --> 00:10:03,000 ‫Und stattdessen 244 00:10:03,000 --> 00:10:05,770 ‫erstellen wir wieder ein Zwischenobjekt oder 245 00:10:05,770 --> 00:10:08,450 ‫einen Zwischendatensatz, der zwischen Benutzern 246 00:10:08,450 --> 00:10:12,520 ‫und Touren steht, wenn sie einen neuen Kauf erstellen. 247 00:10:12,520 --> 00:10:13,353 ‫Rechts? 248 00:10:13,353 --> 00:10:14,590 ‫Sinn ergeben? 249 00:10:14,590 --> 00:10:17,520 ‫Und das war es eigentlich schon für unser Datenmodell. 250 00:10:17,520 --> 00:10:21,370 ‫Und natürlich sieht das jetzt irgendwie abstrakt aus, aber wenn wir 251 00:10:21,370 --> 00:10:23,150 ‫erst einmal mit der Umsetzung 252 00:10:23,150 --> 00:10:24,660 ‫beginnen, wird es 253 00:10:24,660 --> 00:10:28,730 ‫sehr hilfreich sein, all unsere Ideen in so etwas zu organisieren. 254 00:10:28,730 --> 00:10:31,310 ‫Wenn Ihnen dieses Datenmodell, das wir in 255 00:10:31,310 --> 00:10:34,560 ‫diesem Abschnitt implementieren werden, etwas verwirrend erscheint, dann verweisen 256 00:10:34,560 --> 00:10:36,970 ‫Sie einfach auf diese Folie. 257 00:10:36,970 --> 00:10:39,080 ‫Oder Sie können es vielleicht sogar ausdrucken, 258 00:10:39,080 --> 00:10:40,980 ‫wenn es Ihnen das leichter macht. 259 00:10:40,980 --> 00:10:43,960 ‫Das ist also theoretisch unser Datenmodell. 260 00:10:43,960 --> 00:10:46,080 ‫Und jetzt werde ich Ihnen im weiteren Verlauf 261 00:10:46,080 --> 00:10:48,870 ‫des Kurses die Werkzeuge an die Hand geben, um die Daten tatsächlich 262 00:10:48,870 --> 00:10:50,543 ‫mit der Mongoose Library zu modellieren.