Beiträge von DanielIT

Ein Trigger ist eine gespeicherte Aktion, die das DBMS automatisch ausführt, sobald ein bestimmtes Ereignis an einer Tabelle passiert – typischerweise ein INSERT, UPDATE oder DELETE. Du legst fest, ob er BEFORE oder AFTER dem Ereignis feuert.

• Beispiel Protokollierung: Immer wenn eine Zeile in „Konto“ geändert wird, schreibt ein AFTER-UPDATE-Trigger automatisch den alten und neuen Wert in eine „Konto_Historie“-Tabelle. Der Anwendungsentwickler muss daran nie wieder denken.
• Beispiel Konsistenz: Ein BEFORE-INSERT-Trigger setzt ein Feld wie „erstellt_am“ oder prüft/normalisiert einen Wert, bevor er gespeichert wird.

Der entscheidende Vorteil gegenüber „mach ich in der Anwendung“: Der Trigger greift immer – egal, ob die Änderung aus deiner App, aus einem Import-Skript oder von Hand im SQL-Client kommt. Die Regel sitzt zentral an der Datenbank, nicht verstreut in jeder Anwendung, die draufzugreift.

Klassisches Bild: zwei Transaktionen, die je eine Sperre halten und auf die des anderen warten.

• Transaktion A sperrt Zeile 1 und will dann Zeile 2.
• Transaktion B sperrt Zeile 2 und will dann Zeile 1.

Jetzt wartet A auf B und B auf A – keiner gibt seine Sperre frei, bevor er die andere bekommt. Das ist der Deadlock: ein Wartekreis. Es hängt nicht alles fest, nur die zwei beteiligten Transaktionen; der Rest der DB läuft weiter.

Als IT-ler predige ich da immer dasselbe 😄 Zwei Dinge lösen 90 % des Chaos:

• Eine feste Ordnerlogik, konsequent gleich pro Modul: z. B. Semester → Modul → 01_Skript, 02_Mitschrift, 03_Zusammenfassung, 04_Aufgaben. Immer dieselben Unterordner, dann musst du nie überlegen, wo etwas hingehört.
• Einheitliche Dateinamen: Modul_Thema_JJJJ-MM-TT. Das Datum rückwärts sortiert automatisch chronologisch, und du findest alles per Suche.

Alles in einer Cloud (OneDrive, Drive, Nextcloud – egal welche, aber nur eine), damit Laptop und Handy denselben Stand haben. Abfotografierte Mitschriften direkt per Scanner-App in den Modulordner statt in die Foto-Galerie – die machen daraus gleich durchsuchbare PDFs.

Gute Frage, das ist genau der Punkt, an dem SQL „klick“ macht 🙂 Faustregel:

• JOIN, wenn du Spalten aus mehreren Tabellen im Ergebnis zusammenführen willst (Kundenname und die zugehörigen Bestellungen nebeneinander).
• Unterabfrage, wenn du nur filtern willst und die zweite Tabelle gar nicht anzeigen musst – z. B. „alle Kunden, die schon mal bestellt haben“.

Beispiel für den Filterfall:

• Mit Subquery: SELECT name FROM kunde WHERE kundeNr IN (SELECT kundeNr FROM bestellung)
• Mit JOIN: SELECT DISTINCT k.name FROM kunde k JOIN bestellung b ON k.kundeNr = b.kundeNr

Beim JOIN brauchst du hier das DISTINCT, weil ein Kunde mit fünf Bestellungen sonst fünfmal auftaucht. Die Subquery mit IN hat das Problem nicht – ein netter Grund, für reine Existenz-Filter die Unterabfrage zu nehmen.

Zur 2. Normalform noch ein Beispiel aus einem echten Projekt, weil der abstrakte „partielle Abhängigkeit“-Begriff dann sofort klick macht: Wir hatten eine Tabelle Bestellposition (BestellNr, ArtikelNr, Menge, Artikelbezeichnung, Einzelpreis) mit dem zusammengesetzten Schlüssel (BestellNr, ArtikelNr).

Das Problem: Artikelbezeichnung und Einzelpreis hängen nur von der ArtikelNr ab, nicht von der ganzen Bestellung. Ergebnis: Jede Bestellung, die denselben Artikel enthielt, wiederholte den Namen – und als ein Artikel umbenannt wurde, war er in hunderten Zeilen inkonsistent (klassische Update-Anomalie). Nach dem Auslagern in eine eigene Artikel-Tabelle stand der Name genau einmal. Genau dafür ist die 2. NF da.

Der Knackpunkt: Die 2. NF ist nur dann ein Thema, wenn du einen zusammengesetzten Primärschlüssel hast (also aus mehreren Spalten). Bei einem einzelnen Schlüsselfeld bist du automatisch schon in der 2. NF.

Beispiel: Tabelle Bestellposition mit dem Schlüssel (BestellNr, ArtikelNr) und den Spalten Menge, Artikelbezeichnung, Kundenname.

• Menge hängt von der ganzen Kombination ab (voll funktional abhängig) – korrekt.
• Artikelbezeichnung hängt nur von der ArtikelNr ab, also nur von einem Teil des Schlüssels. Das ist die partielle Abhängigkeit.
• Kundenname hängt nur von der BestellNr ab – auch partiell.

Regel: Sobald ein Nicht-Schlüsselattribut nur von einem Teil des zusammengesetzten Schlüssels abhängt, lagerst du es aus.

Gute Frage – der Knackpunkt zuerst: Eine „normale“ View speichert keine Daten, nur die Abfrage-Definition. Bei jedem Zugriff wird das hinterlegte SELECT frisch auf den Basistabellen ausgeführt. Du siehst also immer aktuelle Daten, ohne etwas zu duplizieren.

Der Nutzen wird an drei Punkten greifbar:

• Wiederverwendung: Ein komplexer Join über vier Tabellen, den du ständig brauchst, schreibst du einmal als View kundenumsatz. Danach reicht SELECT * FROM kundenumsatz WHERE jahr=2026.
• Vereinfachung: Fachanwender oder Reports greifen auf die übersichtliche View zu und müssen die Join-Logik dahinter nicht kennen.
• Sicherheit/Kapselung: Du gibst nur die View frei (z. B. ohne Gehaltsspalte), nicht die Rohtabelle. So steuerst du, welche Spalten/Zeilen jemand sieht.

Kurz: Die View ist ein gespeicherter Blick auf die Daten, keine zweite Kopie davon.

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! 💪