modul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
modul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen [2025/10/18 22:41] – gkochmodul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen [2025/10/20 14:17] (aktuell) – gkoch
Zeile 44: Zeile 44:
  
   * **Keine Prüfung / kein FK((Foreign Key = Fremdschlüssel)).** Die Datenbank (DB) kann bei «Belgien, Städtereise» **nicht** prüfen, ob diese Kategorien wirklich existieren. ((Wenn Kategorien und Posts in **separate Tabellen** liegen und per Fremdschlüssel verbunden sind, kontrolliert die DB beim Speichern, ob «Belgien» in der Kategorien-Tabelle vorhanden ist.)) → Tippfehler bleiben unbemerkt ((z. B. «Belgien, Städtereisen» statt «Belgien, Städtereise»)).   * **Keine Prüfung / kein FK((Foreign Key = Fremdschlüssel)).** Die Datenbank (DB) kann bei «Belgien, Städtereise» **nicht** prüfen, ob diese Kategorien wirklich existieren. ((Wenn Kategorien und Posts in **separate Tabellen** liegen und per Fremdschlüssel verbunden sind, kontrolliert die DB beim Speichern, ob «Belgien» in der Kategorien-Tabelle vorhanden ist.)) → Tippfehler bleiben unbemerkt ((z. B. «Belgien, Städtereisen» statt «Belgien, Städtereise»)).
-  * **Unzuverlässiges Filtern.** Suchen mit LIKE liefern leicht Teiltreffer/Varianten. Beispiel: //WHERE category_name LIKE '%Guinea%'// trifft auch «Equatorial Guinea», «Guinea», «Guinea-Bissau» und «Papua New Guinea» – vier verschiedene Länder.+  * **Unzuverlässiges Filtern.** Suchen mit LIKE liefern leicht Teiltreffer/Varianten. Beispiel: ''WHERE category_name LIKE '%Guinea%''' trifft auch «Equatorial Guinea», «Guinea», «Guinea-Bissau» und «Papua New Guinea» – vier verschiedene Länder.
   * **Schwierig auszuwerten & langsam.** Zählen/Gruppieren erfordert Strings((Zeichenketten)) zu zerlegen; darauf kann die DB nicht sinnvoll indexieren((**Index**: Ein Index ist wie ein Inhaltsverzeichnis der Datenbank. Er beschleunigt Suchen/Sortieren auf **einzelnen** Spaltenwerten. Bei Komma-Listen stecken **mehrere** Werte in **einem** Feld – darauf lässt sich kein brauchbarer Index aufbauen; zudem können Suchmuster wie LIKE '%Wort%' einen vorhandenen Index oft nicht nutzen.)).   * **Schwierig auszuwerten & langsam.** Zählen/Gruppieren erfordert Strings((Zeichenketten)) zu zerlegen; darauf kann die DB nicht sinnvoll indexieren((**Index**: Ein Index ist wie ein Inhaltsverzeichnis der Datenbank. Er beschleunigt Suchen/Sortieren auf **einzelnen** Spaltenwerten. Bei Komma-Listen stecken **mehrere** Werte in **einem** Feld – darauf lässt sich kein brauchbarer Index aufbauen; zudem können Suchmuster wie LIKE '%Wort%' einen vorhandenen Index oft nicht nutzen.)).
  
Zeile 56: Zeile 56:
  
 **Auszug:** **Auszug:**
-<WRAP center box 80% round> +{{ :modul:m290_guko:learningunits:lu08:theorie:all_in_one_table_1.png?nolink&900 | Tabelle mit allen Posts}}
-^ id ^ post_title                          ^ author_name   ^ author_email                   ^ category_name ^ created_at           ^ +
-| 1  | Hasselt – 10 Highlights             | Martin Merten | martin@wetraveltheworld.de     | Städtereise   | 2025-05-07 10:15:00 | +
-| 2  | Utrecht – 10 Sehenswürdigkeiten     | Martin Merten | martin@wetraveltheworld.de   | Städtereise   | 2025-06-05 09:30:00 | +
-| 3  | Lissabon – 8 Tipps zu den wichtigsten Sehenswürdigkeiten  | Caro Steig    | caro@wetraveltheworld.de      | Portugal      | 2025-03-21 08:40:00 | +
-</WRAP>+
  
 <WRAP box round 80% center> <WRAP box round 80% center>
Zeile 111: Zeile 106:
 //Gleicher Autor, unterschiedliche E-Mail → Daten sind inkonsistent.// //Gleicher Autor, unterschiedliche E-Mail → Daten sind inkonsistent.//
  
- +<WRAP center tip round 80%> 
-==== Warum eine N:M-Beziehung (Posts ↔ Kategorien) auflösen? ==== +[[https://www.youtube.com/watch?v=W4UkIK2BwS8|Beziehungen in relationalen Datenbanken (1:n, n:m, 1:1) – einfach erklärt]]((Patrick Boekhoven / YouTube)) -> (9:02, de) Grundlagen zu PK/FK und warum wir Beziehungen brauchen; zeigt, wie man 1:n modelliert und warum n:m ohne Zwischentabelle nicht direkt geht. 
-In einer relationalen Tabelle beschreibt **jede Zeile genau ein Ding** (entweder einen //Post// oder eine //Kategorie//). Ein Fremdschlüssel in einer Zeile kann deshalb nur auf ein anderes Ding zeigen. +</WRAP>
- +
-Bei N:M gilt jedoch: Ein Post gehört zu //0…n// Kategorien und eine Kategorie enthält //0…n// Posts. +
-→ Ein einzelnes FK-Feld reicht dafür nicht aus: +
- +
-  * FK in ''posts'' nur als ''category_id'': Pro Post wäre nur eine Kategorie möglich. Mehrere Kategorien erzwingen Duplikate desselben Posts – Änderungen und Löschungen werden fehleranfällig. +
-  * FK in ''categories'' nur als ''post_id'': Pro Kategorie wäre nur ein Post möglich. Dadurch müsste man Kategorien duplizieren – gleiches Problem wie bei obigen Punkt. +
-  * Kommaliste in einer Spalte (z. B. ''Belgien, Städtereise''): In einer Zelle stehen mehrere Werte. Die Datenbank kann nicht prüfen, ob diese Kategorien existieren (kein FK), Abfragen werden unzuverlässig und langsam. +
- +
-**Lösung: die Zwischentabelle ''post_category''.** +
-Wir trennen die Objekte (''posts'', ''categories'') und speichern **jede einzelne Zuordnung** als eigene Zeile in ''post_category'' – genau **ein Paar** (''post_id'', ''category_id'') pro Zeile. +
-So bleibt jede Beziehung eindeutig modelliert, Primärschlüssel bleiben eindeutig, Fremdschlüssel sind prüfbar, und Abfragen bleiben klar und performant. +
- +
- +
  
 ==== Ausblick ==== ==== Ausblick ====
 Auf der nächsten Seite bauen wir genau dieses Mehrtabellen-Schema **mit Fremdschlüsseln** auf und füllen es mit den obigen Reiseblog-Beispieldaten. Auf der nächsten Seite bauen wir genau dieses Mehrtabellen-Schema **mit Fremdschlüsseln** auf und füllen es mit den obigen Reiseblog-Beispieldaten.
  
  • modul/m290_guko/learningunits/lu08/theorie/b_fk-grundlagen.1760820078.txt.gz
  • Zuletzt geändert: 2025/10/18 22:41
  • von gkoch