Beiträge von DanielIT

Faustregel, mit der du fast immer richtig liegst: Im Zweifel Surrogatschlüssel (also eine künstliche, technische ID). Der Grund ist Stabilität – ein Primärschlüssel sollte sich nie ändern und immer eindeutig sein.

Natürliche Schlüssel klingen elegant, haben aber Tücken:

• Sie können sich ändern (eine Artikelnummer wird umgestellt, ein Nutzername geändert) – und dann musst du die Änderung durch alle Fremdschlüssel-Tabellen schleppen.
• Sie sind manchmal doch nicht so eindeutig, wie man denkt.
• Zusammengesetzte natürliche Schlüssel machen Joins und Fremdschlüssel unhandlich.

Eine technische ID ist dagegen bedeutungslos, unveränderlich und schmal – ideal als Primär- und Fremdschlüssel.

Klar 🙂 Stell dir zwei Tabellen vor: Kunden und Bestellungen. Nicht jeder Kunde hat schon bestellt.

• INNER JOIN liefert nur die Zeilen, für die es in beiden Tabellen einen Treffer gibt. Kunden ohne Bestellung fallen komplett raus. Ergebnis = Schnittmenge.
• LEFT JOIN liefert alle Kunden (die „linke“ Tabelle), egal ob sie bestellt haben. Für Kunden ohne passende Bestellung gibt es keine Werte aus der rechten Tabelle → die füllt die Datenbank mit NULL auf.

Genau daher kommen deine NULLs: Das sind die Kunden ohne Bestellung. Faustregel: „Ich will unbedingt alle aus Tabelle A sehen, auch die ohne Partner“ → LEFT JOIN. „Ich will nur die Paare“ → INNER JOIN.

Genau richtig gedacht 🙂 Referentielle Integrität heißt: Ein Fremdschlüssel darf nur auf einen Wert zeigen, der in der referenzierten Tabelle tatsächlich existiert (oder auf NULL, wenn erlaubt). Die Datenbank verhindert dadurch „verwaiste“ Zeilen – z. B. eine Bestellung, die auf einen Kunden verweist, den es gar nicht mehr gibt.

Was beim Löschen des referenzierten Datensatzes passiert, legst du mit der ON DELETE-Regel fest:

• RESTRICT / NO ACTION: Das Löschen wird verweigert, solange noch Kind-Zeilen dranhängen. Der sicherste Default – du musst erst die abhängigen Zeilen aufräumen.
• CASCADE: Die Kind-Zeilen werden automatisch mitgelöscht. Praktisch, aber gefährlich – ein gelöschter Kunde reißt alle seine Bestellungen mit.
• SET NULL: Der Fremdschlüssel in den Kind-Zeilen wird auf NULL gesetzt (setzt voraus, dass die Spalte NULL erlaubt).

Klassiker – der Fehler steckt im Verständnis von NULL 🙂 In SQL bedeutet NULL nicht „leer“ oder „0“, sondern „unbekannt“. Und mit etwas Unbekanntem kann man nicht auf Gleichheit vergleichen.

rabatt = NULL ergibt deshalb nicht TRUE oder FALSE, sondern UNKNOWN – und Zeilen mit UNKNOWN in der WHERE-Bedingung werden nicht ausgegeben. Deshalb 0 Treffer.

Richtig fragst du so ab:

• WHERE rabatt IS NULL → alle ohne Wert
• WHERE rabatt IS NOT NULL → alle mit Wert

Merksatz: Für NULL immer IS, nie =.

Guter Punkt, das wird oft verwechselt. Der Trick: die beiden kümmern sich um zwei völlig verschiedene Fragen.

• Product Owner (PO): verantwortet das Was und Warum. Er pflegt und priorisiert das Product Backlog, entscheidet, welche Features den meisten Wert bringen, und ist die Schnittstelle zu den Stakeholdern.
• Scrum Master (SM): verantwortet das Wie der Zusammenarbeit. Er sorgt dafür, dass das Team nach Scrum arbeiten kann, moderiert die Meetings und räumt Hindernisse (Impediments) aus dem Weg.

Kurz: Der PO maximiert den Produktwert, der SM maximiert die Arbeitsfähigkeit des Teams.

Gute Frage – die zwei Welten haben wirklich unterschiedliche Aufgaben 🙂

• OLTP (Online Transaction Processing): das ist deine operative Datenbank. Viele kleine, gleichzeitige Schreib-/Lesevorgänge (Bestellung anlegen, Lagerbestand ändern). Sie ist stark normalisiert, damit nichts doppelt und inkonsistent wird.
• OLAP (Online Analytical Processing): das Data Warehouse. Hier geht es ums Auswerten großer Datenmengen – „Umsatz je Region und Quartal“. Wenige, aber komplexe Leseabfragen über Millionen Zeilen.

Warum getrennt? Würdest du die dicke Auswertung direkt auf der Kassen-Datenbank laufen lassen, bremst du das Tagesgeschäft aus. Und die Strukturen widersprechen sich: OLTP will normalisiert (schnelles Schreiben), OLAP will bewusst denormalisiert (schnelles Aggregieren, z. B. Sternschema).

Klar, das ist eine typische Klausurfrage 🙂 Der Schlüssel ist: Was genau wird entfernt?

• DELETE löscht Zeilen aus einer Tabelle, die Tabelle selbst bleibt bestehen. Du kannst mit WHERE gezielt filtern (z. B. nur Kunden ohne Umsatz). Jede gelöschte Zeile wird protokolliert, deshalb ist der Befehl bei großen Mengen langsamer – aber innerhalb einer Transaktion per ROLLBACK zurücknehmbar.
• TRUNCATE leert die komplette Tabelle auf einen Schlag, ohne WHERE. Es setzt die Tabelle quasi auf „leer“ zurück (inkl. Auto-Increment-Zähler) und ist deutlich schneller, weil es die Zeilen nicht einzeln protokolliert. Die Struktur bleibt aber erhalten.
• DROP wirft die ganze Tabelle weg – Daten UND Struktur (Spalten, Indizes, alles). Danach existiert die Tabelle nicht mehr.

Merksatz: DELETE = einzelne Datensätze raus, TRUNCATE = Tabelle leerräumen, DROP = Tabelle abreißen.

Der entscheidende Unterschied ist die Lebensdauer des Teils, nicht die Beziehung selbst:

• Komposition (schwarze Raute): Das Teil kann ohne das Ganze nicht existieren. Wird das Ganze zerstört, verschwindet auch das Teil. Beispiel: Haus → Zimmer. Kein Haus, kein Zimmer.
• Aggregation (weiße Raute): Das Teil kann eigenständig weiterleben und ggf. sogar von mehreren Ganzen genutzt werden. Beispiel: Verein → Mitglied, oder Playlist → Song. Löst du den Verein auf, existiert das Mitglied als Person weiter.

Eselsbrücke: schwarze Raute = „stirbt mit dem Ganzen“, weiße Raute = „lebt weiter“. Die Raute steht dabei immer am Ganzen.

Der Kernunterschied liegt darin, wann festgelegt wird, was gebaut wird 🙂

• Wasserfall: sequenzielle Phasen (Analyse → Design → Implementierung → Test → Betrieb), die nacheinander durchlaufen werden. Die Anforderungen werden am Anfang vollständig festgelegt und dann abgearbeitet. Erst am Ende gibt es ein lauffähiges Ergebnis.
• Agil (z. B. Scrum): die Arbeit läuft in kurzen Iterationen (Sprints, 1–4 Wochen). Nach jedem Sprint gibt es ein nutzbares Teilergebnis, und die Anforderungen dürfen sich von Sprint zu Sprint anpassen.

Bild dazu: Wasserfall plant die ganze Reise im Voraus, agil navigiert von Etappe zu Etappe und korrigiert den Kurs unterwegs.

Der Überweisungs-Klassiker passt perfekt – stell dir vor, von Konto A gehen 100 € auf Konto B. Das sind zwei Schritte: abbuchen bei A, gutschreiben bei B.

• Atomicity (Atomarität): Entweder beide Schritte passieren oder keiner. Stürzt der Server nach dem Abbuchen ab, wird zurückgerollt – das Geld verschwindet nicht im Nichts.
• Consistency (Konsistenz): Vor und nach der Transaktion sind alle Regeln erfüllt (z. B. Kontostand nie negativ, Summe stimmt).
• Isolation: Laufen zwei Überweisungen gleichzeitig, sieht keine die halbfertigen Zwischenstände der anderen – es wirkt, als liefen sie nacheinander.
• Durability (Dauerhaftigkeit): Ist die Transaktion bestätigt (Commit), bleibt sie gespeichert – auch wenn direkt danach der Strom ausfällt.

Stell dir ein dickes Fachbuch ohne Stichwortverzeichnis vor: Wenn du einen Begriff suchst, musst du jede Seite durchblättern. Genau das macht die Datenbank bei einer Abfrage ohne Index – einen Full Table Scan, also Zeile für Zeile.

Ein Index ist das Stichwortverzeichnis: eine sortierte Hilfsstruktur (meist ein B-Baum), über die die DB den passenden Datensatz direkt findet, statt alles zu lesen. Deshalb bringt ein Index vor allem dort etwas, wo du suchst, filterst oder verknüpfst – also Spalten in WHERE, JOIN und ORDER BY.

GROUP BY brauchst du immer dann, wenn du etwas pro Kategorie zusammenfassen willst – also sobald eine Aggregatfunktion (COUNT, SUM, AVG, MAX …) ins Spiel kommt und du das nicht über die ganze Tabelle, sondern je Gruppe haben willst.

Beispiel: „Wie viele Bestellungen hat jeder Kunde?“

• SELECT kundeID, COUNT(*) FROM bestellung GROUP BY kundeID;

Faustregel: Jede Spalte im SELECT, die nicht in einer Aggregatfunktion steht, muss ins GROUP BY.

Auf der Tool-Seite noch ein paar Erfahrungswerte, weil das oft die halbe Miete ist:

• Ein geteiltes Dokument (egal welches), in dem ihr live mitschreibt – so entsteht ganz nebenbei eine gemeinsame Zusammenfassung, und alle sehen, dass es vorangeht.
• Ein simpler Pomodoro-Timer: 25 Minuten konzentriert, 5 Minuten Pause. Klingt banal, diszipliniert die Gruppe aber enorm – in den 25 Minuten wird gearbeitet, im Break darf gequatscht werden.
• Kamera an, wenn alle einverstanden sind. Das senkt die Hemmschwelle, abzuschweifen, deutlich.

Und: lieber regelmäßig kurz (1×/Woche, 60–90 Min.) als selten lang. Routine schlägt Marathon. Viel Erfolg beim Aufbau! 💪

Ja, und die Methode ist erstaunlich simpel: Frag die Beziehung aus beiden Richtungen, jeweils mit „ein … – wie viele …?“. Beispiel Kunde/Bestellung:

• Ein Kunde kann wie viele Bestellungen haben? → beliebig viele (n).
• Eine Bestellung gehört zu wie vielen Kunden? → genau einem (1).

Ergebnis: 1:n. Das machst du immer für beide Seiten einzeln – die zwei Antworten zusammen ergeben die Kardinalität. Bei „viele zu viele“ in beide Richtungen (z. B. Student ↔ Veranstaltung) hast du ein n:m.

Eine Eselsbrücke, die bei mir hängen geblieben ist: Der Primärschlüssel ist der Ausweis einer Zeile in ihrer eigenen Tabelle (eindeutig, nie leer). Der Fremdschlüssel ist eine Kopie dieses Ausweises in einer anderen Tabelle und sagt „ich gehöre zu genau diesem Datensatz dort drüben“. Genau deshalb sichert der Fremdschlüssel die referenzielle Integrität – die Datenbank lässt keinen Fremdschlüssel zu, zu dem es keinen passenden Primärschlüssel gibt. Das verhindert „verwaiste“ Datensätze.

Gern, am Beispiel klickt es sofort 🙂 Nimm zwei Tabellen, Kunde und Bestellung:

• Primärschlüssel (PK): identifiziert eine Zeile eindeutig innerhalb ihrer eigenen Tabelle. In Kunde ist das die KundenID. Jeder Kunde hat genau eine, sie ist nie leer und nie doppelt.
• Fremdschlüssel (FK): ist ein Feld in einer anderen Tabelle, das auf einen Primärschlüssel verweist. In Bestellung steht eine KundenID als FK – sie sagt, zu welchem Kunden die Bestellung gehört.

Kurz: Der PK identifiziert (wer bin ich?), der FK verknüpft (zu wem gehöre ich?). Über genau dieses Paar machst du später deinen JOIN.

Was ich am neuen Format spannend finde: die schiere Datenmenge 🤓 So viele Teams und Spiele – da juckt es mich in den Fingern, mal auszuwerten, welche Tipp-Strategie im Forum am besten abschneidet. Vielleicht baue ich am Ende eine kleine Auswertung, wer am konstantesten getippt hat. Bis dahin: fleißig weiter tippen, Leute!

Anna hat das Warum erklärt, hier das Wie konkret. Du baust eine Zuordnungstabelle (oft „belegt“ oder Student_Modul):

• Spalte 1: StudentID (FK auf Student)
• Spalte 2: ModulID (FK auf Modul)

Jede Zeile = genau eine Belegung. Student 5 in Modul 3 → eine Zeile (5, 3). Belegt Student 5 noch Modul 7 → zweite Zeile (5, 7). Der zusammengesetzte Primärschlüssel aus beiden Spalten verhindert, dass dieselbe Belegung doppelt drinsteht. Aus einem n:m werden so technisch zwei 1:n-Beziehungen.

Zu den Konnektoren – die unterscheiden sich nach der Anzahl der Pfade, die ausgelöst werden:

• UND: Alle ausgehenden Pfade werden parallel durchlaufen (z. B. nach 'Bestellung angenommen' gleichzeitig 'Ware kommissionieren' und 'Rechnung erstellen').
• XOR: Genau ein Pfad, sich gegenseitig ausschließend (z. B. 'Bonität ok' oder 'Bonität nicht ok').
• ODER: Mindestens einer, aber auch mehrere Pfade möglich.

Wichtige Gotcha: Nach einem Ereignis darf kein ODER- oder XOR-Konnektor zum Aufspalten stehen, weil ein Ereignis selbst keine Entscheidung treffen kann. Entscheidungen entstehen immer aus einer Funktion heraus.

Das ist völlig normal und kein Fehler. Ein (INNER) JOIN verknüpft jede passende Kombination. Wenn ein Kunde drei Bestellungen hat, erscheint dieser Kunde drei Mal im Ergebnis – einmal pro zugehöriger Bestellung. Die Anzahl der Ergebniszeilen richtet sich also nach der Anzahl der Bestellungen, nicht der Kunden.

Stell es dir so vor: Du fragst nicht 'Liste die Kunden', sondern 'Liste alle Bestellungen mitsamt Kundendaten'. Dass sich die Kundendaten wiederholen, gehört dazu.