Beiträge von Tobi89

Daniels Zuordnung ist genau das, was in der Klausur verlangt wird. Ich ergänze die Praxisseite – die erklärt auch, warum bei euch in der Firma alles „testen“ heißt.

Was in der Realität dazukommt:

• Regressionstest. Keine eigene Stufe, sondern ein Anlass: Nach jeder Änderung wird geprüft, ob etwas kaputtgegangen ist, das vorher funktioniert hat. Das ist der Grund, warum automatisierte Tests so wertvoll sind – ein Mensch führt 400 Prüfschritte nicht jede Woche erneut aus, eine Pipeline schon.
• Smoke-Test. Der schnelle Grundcheck nach einer Auslieferung: Startet die Anwendung, kommt die Anmeldeseite, geht ein Beispielvorgang durch? Fünf Minuten, bevor man mit dem Rest anfängt.
• Testfall ist nicht gleich Testdaten. Der Testfall beschreibt Vorbedingung, Eingabe, erwartetes Ergebnis und Nachbedingung. Das erwartete Ergebnis muss vorher feststehen – sonst testet man nicht, sondern schaut zu, was passiert, und findet es dann plausibel. Klingt banal, ist in der Praxis der häufigste Kardinalfehler.

Warum man früh testet – die Zehnerregel der Fehlerkosten. Die Faustformel besagt: Ein Fehler, der in der Anforderungsphase entdeckt wird, kostet 1. In der Entwicklung das Zehnfache, im Systemtest das Hundertfache, beim Kunden im Betrieb das Tausendfache. Die genauen Zahlen sind eine Faustregel, kein Naturgesetz, aber die Größenordnung stimmt und wird gern abgefragt. Der Grund ist simpel: Je später der Fund, desto mehr hängt bereits an dem Fehler – Code, Dokumentation, Schulungsunterlagen, Daten in der Produktivdatenbank.

Und noch ein Satz, den man sich merken sollte: Testen kann die Anwesenheit von Fehlern zeigen, nie ihre Abwesenheit beweisen. Vollständiges Testen ist bei realen Systemen nicht möglich – schon eine Handvoll Eingabefelder erzeugt astronomisch viele Kombinationen. Deshalb arbeitet man mit Äquivalenzklassen (Eingaben, die sich gleich verhalten sollten, in Gruppen zusammenfassen und je einen Vertreter testen) und mit der Grenzwertanalyse (genau an den Rändern testen: 17, 18 und 19 Jahre bei einer Altersgrenze von 18). Erfahrungsgemäß sitzen dort die meisten Fehler.

Sehr schöne Frage, weil sie genau den Punkt trifft, an dem Lehrbuch und Praxis auseinandergehen. Für die Klausur sortiere ich Integration immer nach der Ebene, auf der zwei Systeme gekoppelt werden – das ist die gängige Systematik:

• Datenintegration (Dateiaustausch / Batch): System A exportiert nachts eine CSV, System B liest sie ein. Billig, robust, funktioniert auch mit uralten Systemen. Nachteil: Die Daten sind immer nur so aktuell wie der letzte Lauf, und keiner merkt sofort, wenn ein Lauf ausfällt.
• Direkte Datenbankkopplung: System B liest direkt in die Tabellen von System A. Schnell gebaut – und auf lange Sicht die schlechteste Idee. Man umgeht die Logik von A, und beim nächsten Update ändert der Hersteller sein Datenmodell und alles bricht.
• Funktions-/Anwendungsintegration (API, z. B. REST oder SOAP): B ruft eine definierte Funktion von A auf. A behält die Kontrolle über seine Regeln, die Schnittstelle ist dokumentiert und versioniert. Das ist heute der Normalfall.
• Nachrichtenorientierte Integration (Middleware, Message Broker / Bus): A schickt ein Ereignis („Wareneingang gebucht“) in eine Warteschlange, alle interessierten Systeme hören mit. Das entkoppelt die Systeme zeitlich – wenn B kurz weg ist, bleibt die Nachricht liegen und wird später verarbeitet.
• Prozessintegration: Ein übergeordneter Workflow steuert die Reihenfolge über mehrere Systeme hinweg.

Die zweite Achse, die in Klausuren gern vergessen wird, ist synchron vs. asynchron. Synchron heißt: A wartet auf die Antwort von B (nötig z. B. bei einer Bonitäts- oder Verfügbarkeitsprüfung). Asynchron heißt: A gibt ab und macht weiter. Asynchron ist deutlich stabiler, weil ein langsames oder ausgefallenes B nicht den ganzen Prozess in A blockiert.

Und noch eine Regel, die die Auswahl in den meisten Fällen erklärt: Punkt-zu-Punkt-Verbindungen skalieren nicht. Bei n Systemen brauchst du im schlimmsten Fall n·(n−1)/2 Verbindungen – bei 10 Systemen also 45 statt 10 Anbindungen an eine zentrale Middleware. Genau das ist das Argument für einen Integrationsbus, und genau das ist auch die typische Musterlösung, wenn nach dem Nutzen von Middleware gefragt wird.

Zur Struktur deiner Antwort – das ist ja dein eigentliches Problem – gibt es ein Vorgehen, das in Klausuren immer trägt:

1. Anforderungen zuerst. Ohne Anforderungen kann man nichts beurteilen. Stichwort Lastenheft: Was muss das System können, unterteilt in Muss-, Soll- und Kann-Anforderungen? Liefert die Aufgabe keine, formulierst du zwei bis drei plausible selbst und schreibst dazu, dass du sie annimmst. Benannte Annahmen kosten nie Punkte, unbegründete Behauptungen schon.
2. Quantitative Kriterien rechnen. Kostenvergleich über einen festen Zeitraum, z. B. fünf Jahre, mit allen Positionen: Lizenz oder Entwicklung, Einführung, Schulung, Migration, laufende Wartung, Betrieb. Das ist der Punkt, an dem die meisten scheitern, weil sie nur den Anschaffungspreis vergleichen – die Folgekosten drehen das Ergebnis regelmäßig um.
3. Qualitative Kriterien bewerten. Dafür ist die Nutzwertanalyse das Standardwerkzeug: Kriterien festlegen, gewichten (Summe 100 %), je Alternative Punkte vergeben (etwa 1 bis 5), gewichtete Summe bilden. Damit wird aus „passt besser“ eine nachvollziehbare Zahl. Wichtig: die Gewichtung begründen, denn sie entscheidet das Ergebnis – und genau diese Subjektivität ist auch der Standard-Kritikpunkt, den man am Ende nennt.
4. Empfehlung mit Begründung und Risiken. Ein Satz Entscheidung, zwei bis drei Sätze Begründung mit Bezug auf die höchstgewichteten Kriterien, dann die Gegenargumente ernst nehmen und sagen, wie man das Risiko begrenzt: Referenzkunden, Pilotphase, Exit-Klausel im Vertrag, Datenexportformat vertraglich sichern.

Kurz: Kriterien → Bewertung → Entscheidung → Risiken. Wenn du diese vier Blöcke als Zwischenüberschriften nimmst, sieht der Korrektor die Struktur sofort, und deine Argumente wirken nicht mehr wie Meinung, sondern wie ein Bewertungsverfahren.

Ein Schlusssatz, der fast immer trägt: Die Entscheidung fällt selten „Standard gegen Individual“, sondern über die Frage, wie viel Abweichung vom Standard sich das Unternehmen dauerhaft leisten will – denn jede Abweichung bezahlt man bei jedem Update erneut.

Daniels Zuordnung würde ich genau so in die Klausur schreiben. Ich ergänze das, was in solchen Aufgaben zusätzlich abgefragt wird.

Antwortmuster für „ordnen Sie zu und begründen Sie“ – immer dreiteilig: Maßnahme → Schutzziel → Wirkmechanismus. Also nicht „Das Backup dient der Verfügbarkeit“, sondern: „Das Backup dient der Verfügbarkeit, weil die Daten nach einem Verlust aus einer zweiten Kopie wiederhergestellt werden können und die Arbeitsfähigkeit dadurch erhalten bleibt.“ Der dritte Teil ist der, der übrig bleibt, wenn die ersten beiden geraten wirken.

Die Falle bei der Verfügbarkeit: RAID ist kein Backup. Das wird gern geprüft. RAID (z. B. Spiegelung) fängt den Ausfall einer Festplatte ab, der Betrieb läuft weiter. Gegen versehentliches Löschen, einen Verschlüsselungstrojaner oder einen Brand hilft es nicht – der Schaden wird sekundenschnell mitgespiegelt. Dafür brauchst du ein Backup, und zwar nach der 3-2-1-Regel: drei Kopien, auf zwei verschiedenen Medien, eine davon räumlich getrennt bzw. offline. Und der Satz, den Prüfer hören wollen: Ein Backup, das nie zurückgespielt wurde, ist kein Backup – Restore-Tests gehören dazu.

Zweite häufige Unterscheidung: technische vs. organisatorische Maßnahmen. Firewall, Verschlüsselung und RAID sind technisch; Berechtigungskonzept, Vier-Augen-Prinzip, Schulungen, Passwortrichtlinie, Notfallhandbuch und Besucherregelung sind organisatorisch. Bei Aufgaben, in denen „drei Maßnahmen“ gefordert sind, holst du oft einen Punkt allein dadurch, dass du beide Kategorien bedienst, statt drei technische aufzuzählen. Dahinter steckt die alte Wahrheit, dass der Mensch die größte Schwachstelle ist – Phishing und Social Engineering umgehen jede Verschlüsselung.

Und eine Maßnahme darf auf mehrere Ziele einzahlen. Ein Berechtigungskonzept schützt die Vertraulichkeit (wer darf lesen) und die Integrität (wer darf ändern). Das ist kein Widerspruch, sondern gibt Extrapunkte, wenn du es dazuschreibst – wichtig ist nur, dass du je Ziel den Mechanismus nennst.

Spiel das Schema einmal an fünf Maßnahmen aus deinem Heft durch, dann musst du in der Klausur nicht mehr raten: Du fragst dich nur noch „lesen, verändern oder drankommen?“ und hast die Zuordnung.

Ja, dafür gibt es klare Regeln – und wenn du sie einmal hast, modelliert sich das fast von selbst.

Erst die EPK-Grundmechanik, weil daran die halbe Bewertung hängt: Eine EPK wechselt immer zwischen Ereignis und Funktion ab.

• Ereignis = ein Zustand, passiv formuliert, im Partizip: „Bestellung ist eingegangen“, „Bonität ist geprüft“. Ein Ereignis tut nichts, es ist etwas.
• Funktion = eine Tätigkeit, aktiv formuliert, Verb + Objekt: „Bonität prüfen“, „Ware kommissionieren“.

Zwei Funktionen dürfen nie direkt aufeinander folgen, zwei Ereignisse auch nicht. Die EPK beginnt und endet mit einem Ereignis. Allein damit sortierst du die meisten Anfängerfehler aus.

Jetzt die Konnektoren. Frag dich bei jeder Verzweigung nur eines: Wie viele der ausgehenden Pfade werden durchlaufen?

• XOR – genau einer. Das ist die echte Entscheidung: entweder Rechnung oder Lastschrift, entweder Kunde ist zahlungsfähig oder eben nicht. Die Pfade schließen sich gegenseitig aus.
• UND – alle, parallel. Ware packen und Rechnung schreiben passieren beide, nur eben unabhängig voneinander und zeitlich egal in welcher Reihenfolge.
• ODER – mindestens einer, es dürfen aber auch mehrere sein. Beispiel: Der Kunde wird per E-Mail und/oder per SMS benachrichtigt. Das ist der seltenste Fall und wird oft fälschlich statt XOR gesetzt.

Die wichtigste Regel, die fast jeder in der ersten Aufgabe verletzt: Ein Ereignis kann keine Entscheidung treffen. Nach einem Ereignis darf deshalb kein XOR-Split stehen – dort ist ja noch niemand tätig geworden, der entscheiden könnte. Ein XOR-Split gehört hinter eine Funktion („Bonität prüfen“ → XOR → „Bonität ist ausreichend“ / „Bonität ist nicht ausreichend“). Danach folgt auf jedem Pfad ein Ereignis, das das Ergebnis benennt.

Und: Was du aufmachst, musst du wieder zusammenführen – und zwar mit demselben Typ. XOR öffnen, XOR schließen. Ein UND-Split, der später als XOR zusammenläuft, ist ein logischer Fehler (die parallelen Zweige laufen beide an, der XOR-Join wartet aber nur auf einen).

Zwei Dinge, die in Klausuren gern abgefragt werden, ergänzend zu Daniels Erklärung:

1. Funktionale vs. nichtfunktionale Anforderungen. Funktional = was das System tun soll (stornieren, drucken, exportieren). Nichtfunktional = wie gut (Antwortzeit, Verfügbarkeit, Bedienbarkeit, Datenschutz, Skalierbarkeit). Die nichtfunktionalen werden im Lastenheft am häufigsten vergessen – und sind später der teuerste Nachtrag.
2. Priorisierung nach Muss, Soll und Kann. Ohne die redet man am Ende über 300 gleichrangige Punkte. Gute Anforderungen sind außerdem prüfbar formuliert: „schnell“ ist keine Anforderung, „Seitenaufbau unter 2 Sekunden bei 200 gleichzeitigen Nutzern“ schon.

Zur Agil-Frage: Die Dokumente verschwinden nicht, sie ändern nur die Form. Aus dem Lastenheft wird die Produktvision plus Product Backlog mit User Stories („Als Kunde möchte ich …, damit …“), aus dem Pflichtenheft werden Akzeptanzkriterien und die Definition of Done. Der Unterschied ist, dass klassisch alles einmal vorne festgezurrt wird, agil dagegen laufend nachgeschärft. Der eigentliche Grund für die Trennung – Anforderung und Lösungsweg auseinanderhalten – gilt in beiden Welten.

Aus der Praxis noch das Beispiel, das es bei uns im Team endgültig klick gemacht hat: Regel im Shop – „Rabatt über 20 % nur mit Freigabe durch den Vertriebsleiter.“

Liegt diese Prüfung in der Oberfläche, dann gilt sie nur für Leute, die über die Website bestellen. Sobald die App, ein Import aus dem Außendienst oder eine Partnerschnittstelle dazukommt, läuft der Rabatt daran vorbei – und keiner merkt es, bis die Marge nicht mehr stimmt. Liegt sie in der Logikschicht, gilt sie für alle Wege, weil alle durch dieselbe Tür müssen.

Als Merksatz für die Prüfung: Die Oberfläche fragt, die Logik entscheidet, die Datenhaltung erinnert sich. Wenn du bei einem Beispiel unsicher bist, welcher Schicht etwas gehört, frag dich, ob es eine fachliche Entscheidung ist (dann Logik), eine Darstellungsfrage (dann Präsentation) oder eine Speicherfrage (dann Datenhaltung). Damit kriegst du fast jede Zuordnungsaufgabe hin.

Danke Daniel, dem ist wenig hinzuzufügen – ich hänge nur die Begriffe an, die in Klausuren gern zusätzlich abgefragt werden 🙂

Standardsoftware statt Individualsoftware: Ein ERP kauft man fertig und passt es an, statt es zu programmieren. Vorteil: geringere Entwicklungskosten und -risiken, laufende Updates, eingebaute Referenzprozesse. Nachteil: Man muss sich in Teilen an die Logik des Herstellers anpassen – der berühmte Satz „das System kann das so nicht“.

Daraus folgt die Unterscheidung Customizing vs. Individualprogrammierung: Customizing heißt, das System über Parameter und Konfiguration einzustellen (Buchungskreise, Belegarten, Workflows) – updatefest. Individualprogrammierung ist eigener Code – flexibel, aber teuer und bei jedem Release erneut zu prüfen. Faustregel aus der Praxis: so viel Customizing wie möglich, so wenig Eigenentwicklung wie nötig.

Der häufigste Grund, warum ERP-Projekte scheitern, ist übrigens weder Technik noch Budget, sondern Stammdatenqualität und fehlende Prozessdisziplin. Ein integriertes System verzeiht schlampige Datenpflege nicht: Ein falscher Artikelstamm pflanzt sich sofort in Disposition, Kalkulation und Abschluss fort. In der Excel-Welt fällt so etwas erst gar nicht auf.

Merksatz fürs Verständnis: Excel bildet Tabellen ab, ein ERP bildet Prozesse ab. Deshalb kann Excel schneller sein, solange nur eine Person damit arbeitet – und wird unbrauchbar, sobald mehrere Bereiche dieselben Daten brauchen.

Du hast völlig recht: Es ist ein Grundprinzip, und wenn du das einmal hast, beantworten sich alle drei Fragen von selbst. Das Prinzip heißt logische Verarbeitungsreihenfolge – und die ist eine andere als die Schreibreihenfolge:

FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

Man schreibt SELECT zuerst, aber die Datenbank wertet es fast zuletzt aus. Damit ist alles erklärt:

1. WHERE läuft vor der Gruppierung und filtert einzelne Zeilen. Zu diesem Zeitpunkt existiert noch keine Gruppe, also kann es auch noch kein COUNT geben – deshalb die Fehlermeldung. HAVING läuft nach der Gruppierung und filtert fertige Gruppen. Faustregel: Bedingung auf einen Einzelwert einer Zeile → WHERE. Bedingung auf ein Ergebnis wie COUNT, SUM oder AVG → HAVING.
2. Warum jede Spalte in GROUP BY muss: Nach dem Gruppieren ist aus vielen Zeilen eine geworden. Fragst du eine Spalte ab, die innerhalb der Gruppe verschiedene Werte hat, gibt es keine sinnvolle Antwort – welchen Namen sollte die Datenbank für eine Abteilung mit acht Mitarbeitern ausgeben? Deshalb gilt: Jede Spalte in SELECT muss entweder in GROUP BY stehen oder in einer Aggregatfunktion. (MySQL/MariaDB waren hier historisch lax und haben irgendeinen Wert geliefert; mit aktivem ONLY_FULL_GROUP_BY verhalten sie sich heute wie die anderen. Verlass dich in der Klausur auf die strenge Regel.)
3. COUNT(*) vs. COUNT(spalte): Das ist kein Zufall, sondern NULL. COUNT(*) zählt Zeilen. COUNT(spalte) zählt nur Zeilen, in denen diese Spalte nicht NULL ist. Wenn drei von zehn Mitarbeitern keine Telefonnummer haben, liefert COUNT(*) zehn und COUNT(telefon) sieben. Dazu kommt COUNT(DISTINCT spalte) für die Anzahl verschiedener Werte.

Deine Abfrage sieht damit ungefähr so aus:

SELECT abteilung, COUNT(*) AS anzahl FROM mitarbeiter WHERE austrittsdatum IS NULL GROUP BY abteilung HAVING COUNT(*) > 5 ORDER BY anzahl DESC

Beachte, dass hier beides vorkommt und das völlig normal ist: WHERE wirft ausgeschiedene Mitarbeiter raus, bevor gezählt wird, HAVING wirft danach die kleinen Abteilungen raus. Ein letzter Merkposten: Der Alias anzahl darf in ORDER BY verwendet werden (das läuft nach SELECT), in WHERE und HAVING dagegen in der Regel nicht – dort musst du den Ausdruck wiederholen.

Für das Üben zu Hause noch die Werkzeugseite – zum Kontrollieren, nicht zum Ersetzen der Handrechnung.

Tabellenkalkulation (Solver): Variablen in zwei Zellen, Zielfunktion und jede Restriktion als SUMMENPRODUKT aus Koeffizientenzeile und Variablenzellen. Im Solver dann Zielzelle auf Maximum, veränderbare Zellen und die Nebenbedingungen eintragen, Verfahren „Simplex-LP“. Wichtig: Die Option „ganzzahlig“ nur setzen, wenn die Aufgabe wirklich unteilbare Stücke verlangt – damit wird aus dem LP ein ganzzahliges Problem, und der Sensitivitätsbericht mit den Schattenpreisen ist dann nicht mehr aussagekräftig. Ohne Ganzzahligkeit liefert genau dieser Bericht dir Lisas Dualwerte frei Haus.

Python: scipy.optimize.linprog. Zwei Stolpersteine, an denen praktisch jeder einmal hängen bleibt:

• Die Funktion minimiert grundsätzlich. Für eine Maximierung übergibst du die Zielfunktion mit umgekehrtem Vorzeichen und drehst das Ergebnis am Ende zurück.
• Alle Ungleichungen müssen in der Form „≤“ vorliegen. Eine Mindestmengenbedingung (≥) multiplizierst du dafür mit −1, wodurch sich das Ungleichheitszeichen umdreht.

Der eigentliche Nutzen fürs Lernen: Du rechnest die Aufgabe von Hand, tippst sie ein und vergleichst. Weichen die Ergebnisse ab, liegt der Fehler fast immer beim Aufstellen – vertauschte Koeffizienten oder eine vergessene Restriktion –, nicht beim Rechnen. Das trainiert genau den Schritt, der in der Klausur die Punkte bringt.

Und zur Einordnung: Grafisch geht es nur mit zwei Variablen, weil man drei Dimensionen nicht mehr sinnvoll zeichnen kann. Deshalb bleiben Prüfungsaufgaben bei zwei Produkten – nicht weil die Realität so aussieht, sondern weil man daran die Logik sichtbar machen kann, die der Simplex-Algorithmus später rechnerisch abarbeitet: Er wandert von Ecke zu Ecke, solange sich der Zielwert verbessert 🙂

Eine Praxisergänzung zur Zwischentabelle bei n:m, die im Modell oft fehlt: Der zusammengesetzte Primärschlüssel aus beiden Fremdschlüsseln ist die Lehrbuchlösung und modelltheoretisch sauber. In produktiven Datenbanken bekommt die Zwischentabelle trotzdem häufig einen eigenen künstlichen Schlüssel – nämlich genau dann, wenn an ihr selbst wieder etwas hängt (eine Bestellposition mit Chargen, Seriennummern oder Retouren). Dann müsstest du sonst überall zwei Spalten als Fremdschlüssel mitschleppen.

Die Regel, die beides zusammenbringt: eigener Schlüssel für die Handhabung, zusätzlich ein UNIQUE über beide Fremdschlüssel, damit die fachliche Eindeutigkeit erhalten bleibt. Sonst kannst du dieselbe Kombination zweimal anlegen und hast genau die Dubletten, die der zusammengesetzte Schlüssel verhindern sollte.

Und der Bezug zu deinen (min,max)-Angaben: Ob die Fremdschlüsselspalte auf der n-Seite NOT NULL ist oder NULL erlaubt, ist die direkte Umsetzung der Mindestkardinalität. Ein Auftrag ohne Kunde ist fachlich Unsinn → NOT NULL. Ein Mitarbeiter ohne Abteilung während der Einarbeitung kann vorkommen → NULL erlaubt. Diese eine Entscheidung erledigst du beim Anlegen der Tabelle oder nie wieder ohne Datenbereinigung.

Zum Haftungsteil deiner Frage, weil der in Klausuren gern als „Diskutieren Sie“-Aufgabe kommt – und weil die intuitive Antwort dort falsch ist.

Es gilt ein geteiltes Verantwortungsmodell: Der Anbieter ist verantwortlich für die Sicherheit der Cloud (Rechenzentrum, Hardware, Virtualisierung, bei PaaS/SaaS auch die Plattform), der Kunde für die Sicherheit in der Cloud. Und der zweite Teil ist größer, als die meisten denken: Zugriffsrechte, Passwörter, Verschlüsselung, Konfiguration – und vor allem die Sicherung der eigenen Daten. Ein gelöschter Datensatz ist bei den meisten Anbietern schlicht gelöscht; die Verfügbarkeitsgarantie im Vertrag bezieht sich auf den Dienst, nicht auf deine Inhalte.

Datenschutzrechtlich verschiebt sich das ebenfalls nicht: Der Kunde bleibt Verantwortlicher im Sinne der DSGVO, der Anbieter ist Auftragsverarbeiter. Deshalb braucht es einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, und deshalb ist auch der Serverstandort ein Prüfpunkt.

Zwei Punkte, mit denen du in einer Bewertungsaufgabe immer landest:

• Skalierbarkeit und Kostenmodell: aus einer Investition in eigene Hardware werden laufende, nutzungsabhängige Kosten.
• Abhängigkeit vom Anbieter: Je höher du im Stapel einsteigst, desto bequemer ist der Betrieb und desto schwerer der Wechsel – bei SaaS hängen Datenformate und Prozesse am Anbieter. Genau das ist der Preis für die abgegebene Verantwortung.

Ein Baustein fehlt noch, sonst hat das Ganze eine Lücke: Woher weiß ich, dass ein öffentlicher Schlüssel wirklich zu der Person oder dem Server gehört, den er vorgibt?

Ohne Antwort darauf könnte sich jemand dazwischenhängen, beiden Seiten seinen eigenen öffentlichen Schlüssel unterschieben und alles mitlesen (Man-in-the-Middle). Deshalb gibt es die Zertifikate: Eine Zertifizierungsstelle bestätigt mit ihrer eigenen Signatur die Zuordnung „dieser öffentliche Schlüssel gehört zu dieser Identität“. Dein Browser vertraut einer Liste solcher Stellen – deshalb prüft er bei HTTPS zuerst das Zertifikat und handelt erst dann den Sitzungsschlüssel aus. Dieses Gesamtkonstrukt aus Schlüsseln, Zertifikaten und Stellen heißt Public-Key-Infrastruktur (PKI).

Wenn du in der Klausur die vier Schutzziele nennen sollst: Vertraulichkeit (Verschlüsselung), Integrität (Hash), Authentizität (Signatur/Zertifikat) und Verfügbarkeit (organisatorisch, nicht kryptografisch). Verschlüsselung deckt eben nicht alles ab.

Genau das ist der Punkt – und zugleich die Kehrseite, deshalb die Frage „wann besser nicht“ 😄 Trigger haben einen ernsten Nachteil: versteckte Logik.

• Ein Trigger läuft unsichtbar mit. Wenn ein simples UPDATE plötzlich drei weitere Tabellen verändert oder einen Fehler wirft, sucht man sich beim Debuggen dumm und dämlich, weil im Anwendungscode nichts davon steht.
• Trigger, die weitere Änderungen auslösen, können Kaskaden oder sogar Endlosschleifen erzeugen, und sie kosten bei Massen-Updates Performance (sie feuern pro betroffener Zeile bzw. Anweisung).

Faustregel aus der Praxis: Trigger sind stark für datennahe, tabellenübergreifende Automatik (Historisierung, Audit-Log, Integrität, die kein Fremdschlüssel abbildet). Fachliche Geschäftslogik gehört dagegen eher in die Anwendung bzw. eine klar aufgerufene Stored Procedure, wo man sie sieht und testen kann. Sparsam einsetzen und gut dokumentieren – dann sind sie ein Segen statt einer Falle.

Und der Grund, warum es nicht ewig hängt: Das DBMS erkennt den Wartekreis aktiv (Wait-for-Graph) oder über einen Timeout und macht dann eines der beiden Opfer: es rollt eine Transaktion zurück (deadlock victim). Die bekommt einen Fehler zurück und kann einfach neu gestartet werden, die andere läuft durch.

Praxistipp gegen Deadlocks: Sperren immer in derselben Reihenfolge anfordern (z. B. immer erst die kleinere ID), Transaktionen kurz halten und nicht mehr sperren als nötig. Dann entsteht der Wartekreis gar nicht erst.

Zum „JOINs sind immer schneller“: Das ist tatsächlich ein Mythos. Bei modernen Datenbanken formt der Query-Optimizer viele Unterabfragen intern ohnehin in JOINs um – die Laufzeit ist dann gleich. Wichtiger als JOIN-vs-Subquery sind meist die Indizes auf den Verknüpfungsspalten.

Einen Fall solltest du aber kennen: die korrelierte Unterabfrage, die sich für jede Zeile der äußeren Abfrage neu ausführt – die kann bei großen Tabellen wirklich bremsen. Für „gibt es mindestens einen Treffer?“ ist EXISTS oft die sauberste und schnellste Variante, weil die Datenbank beim ersten Treffer abbricht. Und Vorsicht bei NOT IN in Kombination mit NULL-Werten – das liefert gern mal gar keine Zeilen; da ist NOT EXISTS die robustere Wahl.

Daniels Beispiel ist perfekt. Zum „Woran erkenne ich es“: Frag bei jedem Nicht-Schlüsselattribut „Brauche ich wirklich den kompletten Schlüssel, um diesen Wert eindeutig zu bestimmen?“

• Ja, den ganzen Schlüssel → bleibt in der Tabelle.
• Nein, ein Teil reicht → raus in eine eigene Tabelle (z. B. Artikel-Tabelle mit ArtikelNr + Bezeichnung).

Der praktische Grund dahinter ist die Redundanz: In der unnormalisierten Version steht die Artikelbezeichnung bei jeder Bestellung erneut. Änderst du sie mal, musst du sie überall ändern (Update-Anomalie). Nach der Aufteilung steht sie genau einmal. Genau das ist der Sinn der Übung.

Daniels Punkte sind genau die Klausur-Argumente. Zwei Ergänzungen aus der Praxis, die oft in Aufgaben abgefragt werden:

• Aktualisierbarkeit: Über eine einfache View (eine Tabelle, kein GROUP BY/DISTINCT/Aggregat) kann man teils auch schreiben (INSERT/UPDATE). Sobald Aggregationen oder mehrere Tabellen im Spiel sind, wird sie in der Regel read-only.
• Materialized View: Das ist die Ausnahme zu „speichert keine Daten“ – eine materialisierte View legt das Ergebnis physisch ab und muss aktualisiert (refreshed) werden. Vorteil: schnelle Leseabfragen bei teuren Auswertungen; Nachteil: die Daten sind nur so aktuell wie der letzte Refresh.

Merksatz fürs Verständnis: Standard-View = Abkürzung/Sichtfenster (immer aktuell), Materialized View = zwischengespeicherter Schnappschuss (schnell, aber altert).

Dem schließe ich mich an, mit einer wichtigen Ergänzung aus der Praxis: Ein Surrogatschlüssel als Primärschlüssel ersetzt nicht die fachliche Eindeutigkeit. Die bildest du zusätzlich über ein UNIQUE-Constraint auf den natürlichen Schlüssel ab.

Beispiel Student: id (Surrogat, Primärschlüssel) + matrikelnummer mit UNIQUE. So hast du beides: eine stabile ID für die Verknüpfungen und die Garantie, dass keine Matrikelnummer doppelt vergeben wird. Genau das übersehen viele in der Klausur – sie werfen den natürlichen Schlüssel ganz weg, und dann kann die Tabelle plötzlich Dubletten enthalten.

Genau, und ein super praktischer Nutzen vom LEFT JOIN: Lücken finden. Wenn du wissen willst, welche Kunden noch nie bestellt haben, machst du LEFT JOIN und filterst hinterher auf WHERE bestellung.id IS NULL – übrig bleiben genau die ohne Treffer.

Zwei Stolpersteine noch:

• Wenn ein Kunde mehrere Bestellungen hat, erscheint er bei beiden Join-Arten mehrfach – einmal pro Bestellung. Das ist normal, kein Fehler.
• Filterst du beim LEFT JOIN eine Bedingung auf die rechte Tabelle im WHERE statt im ON, wirfst du die NULL-Zeilen versehentlich wieder raus und machst den LEFT JOIN faktisch zum INNER JOIN. Bedingungen an die rechte Tabelle gehören ins ON.