Beiträge von Tobi89

Daniels Aufzählung ist komplett – ich geb dir noch die Praxis-Faustregel dazu, wann man was nimmt:

• CASCADE bei einer echten „gehört-zu“-Beziehung, wo das Kind ohne den Elternteil sinnlos ist – klassisch Rechnung → Rechnungspositionen. Löschst du die Rechnung, sollen die Positionen mitgehen.
• RESTRICT, wenn die Kind-Daten eigenständigen Wert haben und nicht versehentlich verschwinden dürfen – z. B. Kunde → Bestellungen. Da willst du eher gewarnt werden.
• SET NULL, wenn die Beziehung optional ist – z. B. Mitarbeiter → Abteilung: Wird die Abteilung aufgelöst, bleibt der Mitarbeiter bestehen, nur ohne Abteilung.

Und zur Sicherheit: Es gibt dieselben Regeln auch als ON UPDATE für den Fall, dass sich der Schlüsselwert selbst ändert. In der Praxis nimmt man aber besser unveränderliche Schlüssel (z. B. eine ID), dann spielt ON UPDATE kaum eine Rolle.

Daniel hat den Kern. Ich häng die zwei Fallen dran, die danach als Nächstes zuschlagen:

• NOT IN mit NULL: Steht in der Liste ein NULL (z. B. aus einer Unterabfrage), liefert WHERE id NOT IN (…) plötzlich gar nichts mehr, weil der Vergleich wieder auf UNKNOWN läuft.
• Ungleich vergisst NULL: WHERE rabatt <> 0 zeigt dir NICHT die NULL-Zeilen mit an – die musst du mit OR rabatt IS NULL extra dazuholen.

Praktisch ist außerdem COALESCE(rabatt, 0), wenn du NULL für eine Rechnung wie eine 0 behandeln willst. Und Randnotiz: COUNT(rabatt) zählt NULL-Werte nicht mit, COUNT(*) schon – auch eine beliebte Stolperstelle.

Ergänzend, weil in Klausuren gern gefragt: Keiner von beiden ist der „Chef“, der Aufgaben verteilt. Das Entwicklungsteam organisiert sich selbst und entscheidet, wie viel es pro Sprint schafft.

Eselsbrücke, die bei mir hängen geblieben ist: Der PO ist die Stimme des Kunden, der SM ist der Coach/Dienstleister fürs Team. Deshalb sollte man die Rollen auch nicht in einer Person bündeln – sonst würde der Termindruck vom PO die Team-Schutzfunktion des SM aushebeln.

Ergänzend der Punkt, der mir das Thema erst greifbar gemacht hat: Ein Data Warehouse ist historisiert und für Analysen aufbereitet. In der operativen DB wird der Kundenstatus überschrieben, wenn er sich ändert – im DWH bleibt die Historie erhalten, damit du „wie war der Umsatz vor zwei Jahren“ überhaupt beantworten kannst.

Der Weg von der einen in die andere Welt heißt ETL (Extract, Transform, Load): Daten aus den operativen Systemen ziehen, bereinigen/vereinheitlichen, ins Warehouse laden – meist nachts. Merksatz für die Klausur: OLTP = Tagesgeschäft (schreiben), OLAP = Entscheidungsunterstützung (auswerten).

Daniels Abgrenzung passt. Ein Detail, das in Klausuren gern abgefragt wird: DELETE und TRUNCATE unterscheiden sich auch technisch – DELETE ist DML (Data Manipulation Language, arbeitet an den Daten), TRUNCATE und DROP sind DDL (Data Definition Language, greifen an der Struktur an).

Praktische Konsequenz: TRUNCATE lässt sich in vielen Datenbanksystemen nicht so einfach zurückrollen wie ein DELETE. Faustregel fürs echte Arbeiten: Solange du dir unsicher bist, nimm DELETE mit WHERE – da kannst du vorher mit einem SELECT prüfen, was du triffst. TRUNCATE und DROP sind mächtig, aber gnadenlos. 😅

Genau so. Aus der Programmier-Sicht wird es oft noch greifbarer: Bei einer Komposition erzeugt und zerstört das Ganze seine Teile selbst (es „besitzt“ sie exklusiv). Bei einer Aggregation hält das Ganze nur eine Referenz auf ein Objekt, das woanders erzeugt wurde und geteilt werden kann.

Mein Klausur-Trick: Stell dir bei jeder Teil-Ganzes-Beziehung die Frage „Was passiert mit dem Teil, wenn ich das Ganze lösche?“ Verschwindet es zwingend → Komposition. Lebt es weiter → Aggregation. Und im Zweifel lieber eine schlichte Assoziation zeichnen: Rauten setzt man nur, wenn wirklich eine Teil-Ganzes-Semantik gemeint ist – sonst verliert man in der Klausur unnötig Punkte.

Daniels Erklärung passt. Für die „wann nimmt man was“-Frage merk dir die Faustregel über die Stabilität der Anforderungen:

• Anforderungen klar, stabil, gesetzlich/vertraglich fix (z. B. Brückenbau, Abrechnungssystem nach festem Gesetz) → Wasserfall. Planbarkeit und Dokumentation sind hier Stärken.
• Anforderungen unklar oder im Fluss, schnelles Feedback nötig (z. B. neue App, Produkt am Markt ausprobieren) → agil. Du reduzierst das Risiko, monatelang am Bedarf vorbei zu bauen.

Klassischer Klausur-Nachteil von Wasserfall: Fehler in der Analyse fallen erst ganz am Ende im Test auf und sind dann teuer. Agil fängt das früher ab, ist aber schwerer fix zu budgetieren. In der Praxis sieht man oft Mischformen.

Daniels Aufzählung deckt alles ab. Als Merkhilfe, welche Eigenschaft welches Problem verhindert:

• A verhindert halbfertige Aktionen,
• C verhindert ungültige Zustände,
• I verhindert, dass sich parallele Vorgänge gegenseitig in die Quere kommen,
• D verhindert Datenverlust nach dem Commit.

In der Praxis sorgt das DBMS dafür über Transaktionen (BEGIN … COMMIT/ROLLBACK) und ein Log. Für die Klausur reicht meist: ACID benennen, je ein Beispiel, und den Begriff Transaktion als Klammer drumherum. Das mit der Isolation wird übrigens am häufigsten unterschätzt – da hängen Themen wie Dirty Read und Locking dran, falls ihr das noch vertieft.

Und jetzt zum „warum nicht überall“ 😄 Ein Index kostet nämlich:

• Schreib-Aufwand: Bei jedem INSERT/UPDATE/DELETE muss die DB nicht nur die Tabelle, sondern auch jeden betroffenen Index aktualisieren. Viele Indizes = langsamere Schreibvorgänge.
• Speicherplatz: Jeder Index belegt zusätzlichen Platz.

Faustregel: Indiziere die Spalten, nach denen du oft filterst oder joinst, nicht jede Spalte. Bei zusammengesetzten Indizes ist außerdem die Spaltenreihenfolge wichtig (links beginnend nutzbar). Und mit EXPLAIN vor der Abfrage siehst du schwarz auf weiß, ob dein Index überhaupt verwendet wird.

Und jetzt der WHERE-vs-HAVING-Teil, das ist der Klassiker 🙂 Der Unterschied ist der Zeitpunkt der Filterung:

• WHERE filtert die einzelnen Zeilen, bevor gruppiert wird.
• HAVING filtert die fertigen Gruppen, nachdem aggregiert wurde.

Deshalb darf in HAVING eine Aggregatfunktion stehen, in WHERE nicht. Beispiel „Kunden mit mehr als 5 Bestellungen, aber nur Bestellungen aus 2026“:

• SELECT kundeID, COUNT(*) FROM bestellung WHERE jahr=2026 GROUP BY kundeID HAVING COUNT(*) > 5;

Reihenfolge der Verarbeitung merken: WHERE → GROUP BY → HAVING. Dann ist immer klar, welcher Filter wohin gehört.

Danny hat die Kernmethode genannt. Ein praktischer Zusatz für die Umsetzung in die Tabellen, weil das oft die eigentliche Klausurfrage ist:

• 1:n → der Fremdschlüssel kommt auf die n-Seite (in die Bestellung wandert die KundenID).
• n:m → braucht eine eigene Zwischen-/Beziehungstabelle, die die beiden Primärschlüssel als Fremdschlüssel aufnimmt; direkt geht es nicht.
• 1:1 → Fremdschlüssel auf einer der beiden Seiten (oft die „optionale“), manchmal werden die Tabellen sogar zusammengelegt.

Wenn du dir bei jeder Beziehung gleich mitnotierst, wohin der Fremdschlüssel wandert, hast du den Übergang vom Modell zur Datenbank schon halb erledigt.

Daniels Beispiel ist perfekt. Der eigentliche Sinn des Fremdschlüssels ist die referenzielle Integrität – und die ist der Grund, warum man ihn überhaupt als FK deklariert und nicht nur ein gleichnamiges Feld hinschreibt:

• Die Datenbank stellt sicher, dass jede KundenID in Bestellung auch wirklich in Kunde existiert. Du kannst keine Bestellung für einen Geister-Kunden anlegen.
• Sie verhindert, dass du einen Kunden löschst, der noch Bestellungen hat (oder regelt per ON DELETE, was dann passiert).

So bleiben deine Daten konsistent – keine verwaisten Datensätze. Das ist neben der Verknüpfung der zweite große Job des Fremdschlüssels. 🙂

Ergänzend ein Punkt, der in der Klausur gern abgefragt wird: Die Zwischentabelle ist auch der einzig saubere Ort für Attribute der Beziehung selbst. Note und Semester der Belegung z. B. gehören weder zum Studenten noch zum Modul, sondern genau zu dieser Kombination. Die packst du als weitere Spalten in die Zuordnungstabelle. Spätestens dann ist klar, warum es ohne dritte Tabelle nicht geht.

Zum LEFT JOIN: Der Unterschied zeigt sich bei Kunden ohne Bestellung.

• INNER JOIN: Nur Kunden, die mindestens eine passende Bestellung haben. Kunden ohne Bestellung fallen raus.
• LEFT JOIN: Alle Kunden der linken Tabelle bleiben erhalten. Hat ein Kunde keine Bestellung, stehen die Bestellspalten einfach auf NULL.

Tipp fürs Üben: Gewöhn dir an, statt SELECT * die Spalten explizit zu benennen. Dann siehst du sofort, woher welche Spalte kommt, und bei doppelten Spaltennamen wie KundenNr gibt es keine Verwirrung.

Du bist nah dran. Die Faustregel für die 3. NF lautet: Eine Tabelle ist in der 3. NF, wenn sie in der 2. NF ist und kein Nichtschlüsselattribut transitiv vom Primärschlüssel abhängt.

Genau das ist bei dir der Fall. Geh es so durch:

1. Primärschlüssel ist BestellNr.
2. Von BestellNr hängt KundenNr ab.
3. Aber KundenName und KundenOrt hängen eigentlich von KundenNr ab, nicht direkt von BestellNr.

Das ist die transitive Abhängigkeit (BestellNr → KundenNr → KundenName). Damit verletzt die Tabelle die 3. NF.