fix structure

KN01/readme.md

@@ -0,0 +1,39 @@
+# A: Installation
+
+connection string:
+`mongodb://admin:MyPassword.42@23.22.210.87:27017/?authSource=admin&readPreference=primary&ssl=false`
+
+![alt text](<Screenshot 2025-02-18 at 14.39.04.png>)
+
+`authSource=admin` gibt an, dass die Authentifizierungsdaten in der "admin" Datenbank gespeichert sind. Das ist notwendigweil der Benutzer "admin" in der admin-Datenbank erstellt wurde
+
+mit sed kann man werde ein einer datei ersetzen
+
+![alt text](<Screenshot 2025-02-18 at 14.41.42.png>)
+
+
+# B: Erste Schritte GUI
+
+![alt text](<Screenshot 2025-02-18 at 14.45.09.png>)
+
+Ich müsste das datum so definieren:
+  "letztesLogin": {
+    "$date": "2024-02-18T14:45:00.000Z"
+  }
+Dann weiss mongodb direkt, dass es ein datum ist.
+Man kann es so definieren dass man direkt nacher das datum verwenden kann um z.b. Zeit auszurechen zum letzten login
+
+
+![alt text](<Screenshot 2025-02-18 at 14.46.52.png>)
+
+
+# C: Erste Schritte CLI
+
+
+![alt text](<Screenshot 2025-02-18 at 14.51.27.png>)
+
+![alt text](<Screenshot 2025-02-18 at 14.52.44.png>)
+
+
+Tables habe ein fixes Schema. Jede spalte hat ein Datentyp und alle Zielen müssen dem Schema folgen.
+Collections sind flexibel Dokumente in der gleichen Collection können unterschiedliche Felder haben

KN02/readme.md

@@ -0,0 +1,18 @@
+# A: Konzeptionelles Datenmodell
+
+![alt text](<Screenshot 2025-02-18 at 14.56.34.png>)
+
+
+
+# B: Logisches Modell für MongoDB
+
+![alt text](<Unbenanntes Diagramm.drawio.png>)
+Spiele werden als eigene collection gespeichert, weil sie von vielen Spielern referenziert werden und selten geändert werden. Das vermeidet auch duplikate.
+
+Achievements werden häufig nach allen Spielern gefiltert, die sie erreicht haben.
+"errungen_von" speichert, welche Spieler ein Achievement erreicht haben.
+
+# C: Anwendung des Schemas in MongoDB
+
+[db.js](db.js)
+

KN03/readme.md

@@ -0,0 +1,17 @@
+# A: Daten einfügen
+
+[create_Data.js](create_Data.js)
+
+# B: Daten löschen
+
+[delete_data_1.js](delete_data_1.js)
+[delete_data_2.js](delete_data_2.js)
+
+# C: Daten auslesen
+
+[read_data.js](read_data.js)
+
+
+# D: Daten verändern
+
+[update_data.js](update_data.js)

KN04/readme.md

@@ -0,0 +1,12 @@
+A) Aggregationen (50%)
+
+[aggregation_1.js](aggregation_1.js)
+
+B) Join-Aggregation (30%)
+
+[join_aggregation.js](join_aggregation.js)
+
+C) Unter-Dokumente / Arrays (20%)
+
+[unter_dokumente.js](unter_dokumente.js)
+

KN05/readme.md

@@ -0,0 +1,6 @@
+# A: Rechte und Rollen
+
+
+
+
+![alt text](<Screenshot 2025-02-18 at 15.30.49.png>)

readme.md

@@ -1,18 +1,15 @@
-# A: Konzeptionelles Datenmodell
 
-![alt text](<Screenshot 2025-02-18 at 14.56.34.png>)
+# KN01
+[KN01](KN01/readme.md)
 
+# KN02
+[KN02](KN02/readme.md)
 
+# KN03
+[KN03](KN03/readme.md)
 
-# B: Logisches Modell für MongoDB
-
-![alt text](<Unbenanntes Diagramm.drawio.png>)
-Spiele werden als eigene collection gespeichert, weil sie von vielen Spielern referenziert werden und selten geändert werden. Das vermeidet auch duplikate.
-
-Achievements werden häufig nach allen Spielern gefiltert, die sie erreicht haben.
-"errungen_von" speichert, welche Spieler ein Achievement erreicht haben.
-
-# C: Anwendung des Schemas in MongoDB
-
-[db.js](db.js)
+# KN04
+[KN04](KN04/readme.md)
 
+# KN05
+[KN05](KN05/readme.md)