Beiträge von DanielIT

Aus der IT-Freelance-Ecke noch ein Blick darauf, wie „echte“ Selbstständigkeit in der Softwareentwicklung aussieht – dann siehst du den Kontrast zu deinem Angebot besser.

Ich habe während des Studiums zwei Jahre freiberuflich entwickelt, und was bei mir den Unterschied gemacht hat:

• Projekte statt Stunden: Vereinbart war ein Ergebnis (eine Funktion, ein Modul, eine Seite) mit Abnahme – nicht „20 Stunden pro Woche verfügbar sein“.
• Ich habe entschieden, wann und wo ich arbeite. Es gab Abstimmungstermine, aber kein tägliches Stand-up als Pflichttermin.
• Eigene Ausstattung: eigener Rechner, eigene Lizenzen, ein Gast-Zugang zum Repository des Kunden statt einer Firmen-Identität.
• Mehrere Kunden parallel und ein eigener Stundensatz, den ich auch mal nicht bekommen habe.

Bei deinem Angebot ist es umgekehrt: Du wärst faktisch eine Teilzeitkraft ohne Arbeitsvertrag. Einzelne Punkte wie ein Firmenlaptop sind in der IT übrigens nicht automatisch schädlich – aus Datenschutz- und Sicherheitsgründen bekommen auch Externe oft Hardware gestellt. Kritisch wird es in der Summe, und die ist bei dir ziemlich eindeutig.

Falls du irgendwann doch freiberuflich loslegst, noch zwei Stichworte, die man sich früh anschauen sollte: die Frage freiberuflich oder gewerblich (bei Softwareentwicklung nicht immer eindeutig, entscheidet über Gewerbeanmeldung und Gewerbesteuer) und die Kleinunternehmerregelung nach § 19 UStG, deren Umsatzgrenzen zuletzt angehoben wurden – den aktuellen Stand am besten kurz nachschlagen. Aber das ist dann Stoff fürs Steuerforum. 🙂

Tobis Systematik ist die Antwort auf „welche Arten“. Zu deiner zweiten Frage – technisch oder organisatorisch – aus der Projektpraxis ganz klar: Der technische Transport ist der einfache Teil. Die Monate gehen für die Semantik drauf.

Die typischen Stolpersteine, in der Reihenfolge, in der sie einen einholen:

• Unterschiedliche Bedeutung gleicher Felder. „Kunde“ ist im ERP der Rechnungsempfänger, im Lagersystem die Warenempfangsstelle. Beides heißt Kunde, beides ist eine Nummer – und beim ersten Abgleich passt nichts zusammen. Dafür braucht es ein Mapping, und dafür braucht es jemanden aus der Fachabteilung, nicht aus der IT.
• Schlüssel und Stammdaten. Welches System ist die führende Quelle für einen Artikel? Wenn beide Seiten Artikel anlegen dürfen, hast du früher oder später Dubletten. „Ein führendes System je Datenobjekt“ ist die Regel, an der man sich festhalten sollte.
• Formate und Einheiten. Datumsformate, Dezimaltrenner, Mengeneinheiten (Stück vs. Karton), Zeitzonen, Zeichensatz. Klingt banal, kostet reale Wochen.
• Wiederholbarkeit (Idempotenz). Was passiert, wenn dieselbe Nachricht zweimal ankommt, weil die Leitung wackelte? Wenn dann zweimal eingebucht wird, ist der Bestand falsch. Deshalb bekommt jede Nachricht eine eindeutige ID und der Empfänger ignoriert Wiederholungen.
• Fehlerbehandlung und Monitoring. Die Frage ist nie, ob ein Datensatz mal durchfällt, sondern wer es merkt. Ohne Protokoll, Alarm und definierten Wiederanlauf fällt der Fehler erst bei der Inventur auf.
• Versionierung. Die Schnittstelle muss sich ändern dürfen, ohne dass die Gegenseite am selben Tag mitziehen muss.

Für die Klausur würde ich es so zuspitzen: Eine Schnittstelle ist kein Kabel, sondern ein Vertrag – über Inhalt, Format, Zeitpunkt, Verantwortung und Fehlerfall. Der technische Teil ist nur die Umsetzung dieses Vertrags. Wenn ein Integrationsprojekt hängt, fehlt fast immer der Vertrag, nicht die Technik.

Ja, dafür gibt es ein sauberes Raster. Der Denkfehler steckt meist am Anfang: Make-or-Buy ist keine Software-Frage, sondern eine Frage nach der strategischen Bedeutung des Prozesses. Daraus folgt der Rest.

Leitfrage zuerst: Ist der Prozess ein Differenzierungsmerkmal im Wettbewerb oder eine Commodity? Buchhaltung, Lohnabrechnung und Zeiterfassung macht jedes Unternehmen im Kern gleich – dafür Standardsoftware. Wenn dagegen die Auftragsabwicklung mit einer sehr speziellen Variantenkonfiguration der Grund ist, warum Kunden bei genau diesem Maschinenbauer kaufen, spricht das für eine eigene Lösung. Merksatz: Kernkompetenz behalten, Standardprozesse kaufen.

Danach das Kriterienraster – am besten in vier Blöcken, das strukturiert die Antwort automatisch:

• Wirtschaftlich: Anschaffungs- bzw. Entwicklungskosten, vor allem aber die Gesamtkosten über die Laufzeit (Lizenzen und Wartung, Betrieb, Anpassung, Schulung, Migration, spätere Weiterentwicklung). Dazu die Zeit bis zur Einsatzbereitschaft – Standard läuft in Monaten, eine Individualentwicklung dauert deutlich länger.
• Funktional: Abdeckungsgrad der Anforderungen (Fit-Gap-Analyse), Anpassbarkeit, Integration in die bestehende Systemlandschaft, Skalierbarkeit.
• Organisatorisch: vorhandenes IT-Know-how im Haus, Personal für Wartung, Akzeptanz bei den Anwendern, Aufwand für die Prozessanpassung – bei Standardsoftware passt sich oft das Unternehmen der Software an, nicht umgekehrt.
• Risiko und Recht: Abhängigkeit vom Anbieter (Lock-in) gegen Abhängigkeit vom eigenen Entwickler-Know-how, Zukunftssicherheit und Updatefähigkeit, Datenschutz und Revisionssicherheit, Ausfall des Dienstleisters, Gewährleistung.

Wichtig für die Beurteilung: Es sind nicht nur zwei Optionen. Zwischenformen gehören in jede gute Antwort – Standardsoftware mit Customizing (Konfiguration in den vom Hersteller vorgesehenen Grenzen, bleibt updatefähig), Branchenlösung (Standard, der die Besonderheiten der Branche schon kennt), Cloud/SaaS statt eigenem Betrieb, oder ein Standardkern mit einer kleinen individuellen Ergänzung an genau der einen kritischen Stelle. Für einen Mittelständler ist das in der Praxis fast immer die realistische Lösung.

Und die entscheidende Unterscheidung dabei: Customizing über vorgesehene Parameter ist harmlos, Individualprogrammierung im Standardsystem macht jedes Update zum Projekt. Wer das erwähnt, zeigt, dass er den Praxisunterschied kennt.

Die Ordnung wird deutlich einfacher, wenn du jedes Schutzziel über die Frage definierst, die es beantwortet – und die Maßnahme anschließend danach fragst, welche dieser Fragen sie beantwortet.

• Vertraulichkeit: „Kann ein Unbefugter den Inhalt lesen?“ → Verschlüsselung, Berechtigungskonzept und Zugriffsrechte, Need-to-know, verschlossener Serverraum, VPN.
• Integrität: „Ist der Inhalt unbemerkt verändert worden?“ → Hashwerte und Prüfsummen, digitale Signatur, Schreibrechte, Versionierung, Transaktionen in der Datenbank.
• Verfügbarkeit: „Komme ich dran, wenn ich es brauche?“ → Backup, RAID, Redundanz, USV, Notfallplan, Schutz vor Überlastung.

Viele Hefte nennen zusätzlich Authentizität („ist der Absender wirklich der, der er zu sein behauptet?“) und Verbindlichkeit / Nichtabstreitbarkeit („kann der Absender es hinterher leugnen?“). Genau dort sitzt die Antwort auf deine Signatur-Frage.

Symmetrisch vs. asymmetrisch in drei Punkten:

• Symmetrisch (z. B. AES): ein Schlüssel zum Ver- und Entschlüsseln. Sehr schnell, auch für große Datenmengen – aber beide Seiten müssen den Schlüssel vorher sicher austauschen. Das ist das Schlüsselverteilungsproblem, und bei n Teilnehmern braucht man n·(n−1)/2 Schlüssel.
• Asymmetrisch (z. B. RSA): Schlüsselpaar aus öffentlichem und privatem Schlüssel. Was mit dem einen verschlüsselt wurde, geht nur mit dem anderen wieder auf. Den öffentlichen darf jeder haben – damit ist das Verteilungsproblem gelöst. Dafür ist das Verfahren um Größenordnungen langsamer.
• Hybrid = die Praxis (TLS/HTTPS, verschlüsselte Mail): Asymmetrisch wird nur ein zufälliger Sitzungsschlüssel übertragen, die eigentlichen Daten laufen dann symmetrisch. Beide Vorteile, keiner der Nachteile.

Und jetzt die Merkregel, die deine eigentliche Frage beantwortet – es kommt auf die Richtung an:

• Verschlüsseln für Vertraulichkeit: mit dem öffentlichen Schlüssel des Empfängers. Nur der Empfänger besitzt den passenden privaten Schlüssel, also kann nur er lesen.
• Signieren: Vom Dokument wird ein Hashwert gebildet, und der wird mit dem privaten Schlüssel des Absenders verschlüsselt. Jeder kann mit dessen öffentlichem Schlüssel prüfen: Passt der entschlüsselte Hash zum selbst berechneten Hash des Dokuments, stammt es von diesem Absender und wurde nicht verändert.

Daraus folgt sauber: Die Signatur sichert Integrität, Authentizität und Verbindlichkeit – aber ausdrücklich keine Vertraulichkeit. Ein signiertes Dokument ist für jeden lesbar. Wenn du beides willst, musst du signieren und verschlüsseln. Das ist eine klassische Fangfrage.

Noch zum Hash selbst: Er ist keine Verschlüsselung, sondern eine Einwegfunktion – aus dem Hashwert lässt sich das Original nicht zurückrechnen, und schon eine geänderte Stelle im Dokument kippt den kompletten Wert. Genau deshalb taugt er für Integrität (und für die Speicherung von Passwörtern), aber niemals für die Vertraulichkeit von Inhalten.

Zur zweiten Frage – EPK und BPMN sind nicht dasselbe, aber verwandt genug, dass du das Gelernte übertragen kannst.

• EPK stammt aus der deutschen ARIS-Tradition und ist auf die fachliche Dokumentation ausgelegt: Wer will verstehen, wie ein Prozess abläuft? Sie ist bewusst schlicht und deshalb in Studienheften beliebt.
• BPMN 2.0 ist ein internationaler Standard (ISO/OMG) und deutlich reicher: Pools und Lanes für Zuständigkeiten, Nachrichtenflüsse über Unternehmensgrenzen hinweg, Fehler- und Zeit-Ereignisse – und BPMN-Modelle lassen sich in einer Process Engine sogar ausführen.

Faustregel: Interne Ablaufbeschreibung einer Abteilung → EPK reicht. Sobald mehrere Beteiligte, externe Partner oder eine technische Umsetzung im Spiel sind → BPMN.

Die Übersetzung ist fast eins zu eins:

• EPK-Funktion → BPMN-Task (abgerundetes Rechteck)
• EPK-Ereignis → BPMN-Event (Kreis) – hier der Unterschied: BPMN setzt Events nur, wo sie etwas bedeuten (Start, Ende, eingehende Nachricht, Timer), nicht nach jedem Schritt. BPMN-Modelle sind dadurch spürbar kürzer.
• XOR → exklusives Gateway (Raute mit X)
• UND → paralleles Gateway (Raute mit +)
• ODER → inklusives Gateway (Raute mit O)

Zwei Modellierungsgrundsätze gelten in beiden Sprachen und werden gern abgefragt: Gateways arbeiten nicht, Aufgaben entscheiden nicht. Ein Gateway verzweigt nur den Fluss – die eigentliche Prüfung ist eine Aufgabe davor. Und der Prozess braucht eine klar benannte Auslösung und ein definiertes Ende; ein Zweig, der im Nichts endet, ist ein Modellfehler, auch wenn inhaltlich „nichts weiter passiert“ (dann gehört ein Endereignis „Bestellung abgelehnt“ hin).

Für deinen Bestellprozess heißt das konkret: Bestellung geht ein (Ereignis) → Bestellung prüfen (Funktion) → XOR → zwei Ereignisse „Bestellung ist gültig“ / „Bestellung ist fehlerhaft“, und nur der gültige Pfad läuft weiter Richtung Zahlungsart, wo das nächste XOR sitzt. Ware packen und Rechnung schreiben hängst du an ein UND – die blockieren sich nicht gegenseitig.

Der Merksatz, der bei mir hängen geblieben ist: Das Lastenheft beschreibt das WAS und WOFÜR, das Pflichtenheft das WIE und WOMIT. Oder noch kürzer: Lastenheft = die Lasten des Kunden, Pflichtenheft = die Pflichten des Auftragnehmers.

Beispiel Onlineshop:

• Lastenheft (schreibt der Auftraggeber): „Kunden müssen ihre Bestellung nach dem Absenden noch 30 Minuten stornieren können. Die Stornierung muss im ERP sichtbar sein.“ Fachlich, lösungsneutral, ohne Technikvorgabe.
• Pflichtenheft (antwortet der Auftragnehmer): „Umsetzung als Statuswechsel im Bestellobjekt, Übergabe an das ERP über die vorhandene REST-Schnittstelle im 5-Minuten-Takt, Storno-Schaltfläche im Kundenkonto, Rollen X und Y dürfen …“

Der Sinn der Trennung ist kein Formalismus: Das Lastenheft ist die Ausschreibungsgrundlage – mehrere Anbieter bekommen dasselbe Dokument und können vergleichbar anbieten. Das Pflichtenheft ist das, was der gewählte Anbieter daraus macht, und wird nach der Freigabe zur Abnahmegrundlage. Bei Streit wird genau dagegen geprüft: Steht es drin und funktioniert nicht, ist es ein Mangel. Steht es nicht drin, ist es ein Änderungsantrag – also Zusatzaufwand und Zusatzkosten.

Die Frage ist gut, weil der Nutzen erst sichtbar wird, wenn man sich das Gegenteil vorstellt 🙂 Erst die Zuordnung, die du in der Klausur brauchst:

• Präsentationsschicht: alles, was der Nutzer sieht und bedient – im Web also der Browser mit HTML/CSS/JavaScript, in der Firma die Desktop- oder Mobile-Oberfläche.
• Anwendungs- oder Logikschicht: die fachlichen Regeln und Abläufe – Preisberechnung, Rabattprüfung, Bestellprozess. Läuft auf dem Web- bzw. Applikationsserver.
• Datenhaltungsschicht: das Datenbankmanagementsystem, das speichert, sucht und die Konsistenz sichert.

Die entscheidende Regel dabei: Jede Schicht spricht nur mit ihrer Nachbarschicht. Die Oberfläche fragt die Logik, die Logik fragt die Datenhaltung – die Oberfläche redet nie direkt mit der Datenbank.

Und genau daraus kommt der Nutzen:

• Austauschbarkeit: Neue Oberfläche, etwa eine App zusätzlich zur Website? Die Logik bleibt, du tauschst nur oben. Umzug auf ein anderes Datenbanksystem? Du tauschst nur unten.
• Mehrfachnutzung: Website, App und Partnerschnittstelle nutzen dieselbe Logik – die Regel existiert einmal statt dreimal.
• Sicherheit: Die Datenbankzugangsdaten liegen auf dem Server, nicht beim Client. Beim Zwei-Schichten-Modell (klassischer „Fat Client“, der selbst SQL absetzt) hat jeder Arbeitsplatz effektiv einen Datenbank-Schlüssel in der Tasche.
• Skalierung und Arbeitsteilung: Bei Last stellst du gezielt Applikationsserver dazu, und im Team kann an Oberfläche und Logik parallel gearbeitet werden.

Das lässt sich an einem einzigen Beispiel sehr gut zeigen: Ein Kundenauftrag geht ein.

Excel-Welt: Der Vertrieb trägt den Auftrag in seine Liste ein. Das Lager erfährt davon per Mail und pflegt den Bestand in einer zweiten Datei. Die Buchhaltung tippt die Rechnung in eine dritte. Der Einkauf merkt drei Tage später, dass Material fehlt. Jeder Schritt ist eine Neuerfassung derselben Daten – und jede Neuerfassung ist eine Fehlerquelle.

ERP-Welt: Der Auftrag wird einmal erfasst und läuft als ein Datensatz durch alle Bereiche: Verfügbarkeitsprüfung im Lager, Reservierung, gegebenenfalls Bestellvorschlag im Einkauf, Kommissionierung, Lieferschein, Faktura, Buchung auf Debitor und Erlöskonto. Der Lagerbestand ändert sich in dem Moment, in dem gebucht wird – nicht dann, wenn jemand daran denkt.

Genau das ist der Integrationsgedanke, und den unterscheidet man in der Klausur meist dreifach:

• Datenintegration: eine gemeinsame Datenbasis, jede Information wird nur einmal gespeichert (Redundanzfreiheit) → keine widersprüchlichen Stände.
• Funktionsintegration: die Module (Finanzbuchhaltung, Controlling, Materialwirtschaft, Produktion/PPS, Vertrieb, Personal) greifen auf dieselben Objekte zu.
• Prozessintegration: abgebildet wird der Geschäftsprozess über Abteilungsgrenzen hinweg, nicht die einzelne Abteilung.

Nützlich ist dabei auch die Unterscheidung der Datenarten: Stammdaten (langlebig: Kunde, Artikel, Lieferant), Bewegungsdaten (vorgangsbezogen: Auftrag, Buchung, Wareneingang) und Bestandsdaten (der jeweils aktuelle Stand: Lagerbestand, Kontosaldo). Ein ERP hält die Stammdaten einmal und verknüpft alle Bewegungen damit.

Und wo Excel technisch aussteigt: Mehrbenutzerbetrieb mit Transaktionssicherheit (entweder wird der ganze Vorgang gebucht oder gar nichts), referentielle Integrität, Berechtigungskonzept und eine lückenlose, nachvollziehbare Protokollierung – letzteres ist bei buchungsrelevanten Daten nach den GoBD nicht optional. Eine Excel-Zelle kann man überschreiben, ohne dass es jemand sieht. Genau das darf bei Buchhaltungsdaten nicht möglich sein.

Tobis Reihenfolge ist der Schlüssel. Ich hänge die Stolperfallen an, die einem nach der Klausur im echten Betrieb begegnen – die kommen aber auch in Aufgaben gern als Teilfrage vor.

1. Der Klassiker: LEFT JOIN plus COUNT(*). Du willst pro Kunde die Anzahl der Bestellungen, auch für Kunden ohne Bestellung. Mit LEFT JOIN bleiben die kundenlosen Zeilen erhalten – aber COUNT(*) zählt trotzdem 1, weil die Zeile ja existiert, nur mit lauter NULL-Werten aus der rechten Tabelle. Richtig ist COUNT(bestellung.bestellID): Das zählt die NULL-Zeile nicht mit und liefert die gewünschte 0. Dieser Fehler ist in Auswertungen extrem verbreitet.

2. NULL bildet eine eigene Gruppe. Gruppierst du nach einer Spalte, in der NULL vorkommt, entsteht eine gemeinsame Gruppe für alle NULL-Werte – obwohl NULL sonst nirgends gleich NULL ist. Praktisch, aber überraschend. Und AVG(spalte) ignoriert NULL-Zeilen komplett: Der Nenner ist dann COUNT(spalte) und nicht COUNT(*). Wenn fehlende Werte als 0 zählen sollen, musst du das mit COALESCE ausdrücklich sagen.

3. Filtere so früh wie möglich. Inhaltlich kannst du eine Zeilenbedingung auch in HAVING unterbringen, wenn die Spalte in GROUP BY steht – sauber ist es trotzdem nicht. WHERE reduziert die Datenmenge, bevor gruppiert wird, und kann Indizes nutzen. HAVING arbeitet auf dem bereits berechneten Zwischenergebnis. Bei großen Tabellen ist das der Unterschied zwischen einer Sekunde und einer Minute.

4. Als Ausblick, falls es im Kurs noch kommt: Wenn du Einzelzeilen und eine Kennzahl gleichzeitig brauchst („jeder Mitarbeiter mit dem Durchschnittsgehalt seiner Abteilung daneben“), ist GROUP BY das falsche Werkzeug, weil es die Zeilen zusammenfasst. Dafür gibt es Fensterfunktionen wie AVG(gehalt) OVER (PARTITION BY abteilung) – sie rechnen dieselbe Kennzahl, behalten aber alle Zeilen. Das ist ein sehr guter Punkt für eine mündliche Prüfung, weil ihn erfahrungsgemäß kaum jemand nennt.

Zum Erkennen im Prüfungsstress hilft ein Merksatz, der die ersten drei Normalformen in einem Satz zusammenfasst:

„Der Schlüssel, der ganze Schlüssel und nichts als der Schlüssel.“

• 1. NF – alle Attributwerte sind atomar, keine Mehrfachwerte in einer Zelle: der Schlüssel.
• 2. NF – jedes Nichtschlüsselattribut hängt vom ganzen zusammengesetzten Schlüssel ab, nicht nur von einem Teil davon (das war die partielle Abhängigkeit).
• 3. NF – jedes Nichtschlüsselattribut hängt nur vom Schlüssel ab und von nichts anderem: nichts als der Schlüssel.

Praktische Erkennungsregel: Geh die Spalten durch und frag bei jeder „Kann ich diesen Wert aus einer anderen Nichtschlüsselspalte ableiten?“ Wenn ja, ist es transitiv. Zwei Klassiker, die dir immer wieder begegnen:

• PLZ → Ort in einer Adresstabelle
• ArtikelNr → Artikelbezeichnung → MwSt-Satz in einer Positionstabelle

Nebenbei: Die 2. NF ist nur dann überhaupt eine Hürde, wenn der Primärschlüssel zusammengesetzt ist. Bei einem einspaltigen Schlüssel kann es keine partielle Abhängigkeit geben – dann geht es direkt um die 3. NF, und deshalb ist sie in der Praxis die wichtigste der drei.

Zwei Ergänzungen für die Vollständigkeit: Über der 3. NF steht noch die Boyce-Codd-Normalform, die zusätzlich Abhängigkeiten zwischen Schlüsselkandidaten ausschließt – die brauchst du selten, sie taucht aber gern als Zusatzfrage auf. Und in der Praxis wird bewusst wieder denormalisiert, etwa in Data Warehouses, wo Lesegeschwindigkeit wichtiger ist als Redundanzfreiheit. Das ist kein Widerspruch zur Theorie: Man normalisiert erst sauber und weicht dann begründet ab.

Es gibt für alle drei Fälle feste Umsetzungsregeln – wenn du die einmal auswendig kannst, musst du nie wieder raten.

1:n – der Fremdschlüssel kommt immer auf die n-Seite. Beispiel Abteilung – Mitarbeiter: Eine Abteilung hat viele Mitarbeiter, ein Mitarbeiter gehört zu einer Abteilung. Also bekommt die Tabelle Mitarbeiter die Spalte abteilungsID. Die Merkregel dahinter ist rein praktisch: In einer Spalte steht genau ein Wert. Der Mitarbeiter hat eine Abteilung – das passt in eine Spalte. Die Abteilung hat viele Mitarbeiter – das passt nicht in eine Spalte, ohne dass du Werte durch Komma trennst, und genau das verbietet die erste Normalform. Kurz: Der Fremdschlüssel steht dort, wo die „1“ gebraucht wird, also auf der Seite mit den vielen Zeilen.

n:m – geht nicht direkt, es braucht eine dritte Tabelle. Das ist die Antwort auf deine eigentliche Frage. Im relationalen Modell gibt es keine Möglichkeit, eine n:m-Beziehung mit zwei Tabellen abzubilden – aus demselben Grund wie oben: Du müsstest auf beiden Seiten mehrere Werte in eine Spalte quetschen. Also legst du eine Zwischentabelle (auch Verknüpfungs- oder Assoziationstabelle) an, die die Fremdschlüssel beider Seiten enthält:

• Kunde(kundeID, name, …)
• Artikel(artikelID, bezeichnung, preis, …)
• Bestellposition(kundeID, artikelID, menge, bestelldatum)

Der Primärschlüssel der Zwischentabelle ist dabei üblicherweise die Kombination aus beiden Fremdschlüsseln.

Und damit ist auch beantwortet, warum die Menge nicht in die Artikeltabelle darf: Die Menge ist keine Eigenschaft des Artikels, sondern der Beziehung. Der Artikel „Schraube M4“ hat keine Menge – er hat eine Bezeichnung und einen Preis. Erst die Kombination aus Kunde und Artikel hat eine Menge. Schreibst du sie in die Artikeltabelle, kann nur noch ein einziger Kunde diesen Artikel bestellen. Genau das ist das Testkriterium: Wovon hängt dieses Attribut ab? Von einer Entität allein oder von der Kombination?

1:1 – Fremdschlüssel auf eine der beiden Seiten, zusätzlich mit einer UNIQUE-Bedingung, damit die Eindeutigkeit erzwungen wird. Häufig lässt man 1:1 aber ganz weg und legt beides in eine Tabelle – es sei denn, ein Teil ist optional oder aus Datenschutzgründen zu trennen.

Die Frage, die dich fast immer zum richtigen Modell führt, lautet: Was ist das kleinste Ding, das ich selbst noch verwalten muss? Die drei Modelle unterscheiden sich nur darin, an welcher Stelle des Stapels die Verantwortung wechselt.

• IaaS – der Anbieter stellt Rechenleistung, Speicher, Netz und Virtualisierung. Du verwaltest ab dem Betriebssystem aufwärts: Patches, Laufzeitumgebung, Anwendung, Daten. Dein Beispiel mit den virtuellen Servern plus selbst installierter Datenbank ist genau das.
• PaaS – der Anbieter kümmert sich zusätzlich um Betriebssystem, Laufzeitumgebung und Middleware. Du lieferst nur noch Anwendung und Daten. Die gebuchte Datenbank als Dienst fällt hierunter: Du legst Tabellen an und pflegst Inhalte, aber niemand fragt dich nach dem Sicherheitspatch des Servers.
• SaaS – der Anbieter betreibt die fertige Anwendung. Du konfigurierst, verwaltest Benutzer und Rechte, und die Daten gehören dir. Webmail, CRM-Systeme oder ein Office-Paket im Browser.

Als Bild finde ich das Wohnen ganz brauchbar: IaaS ist der Rohbau (Wände und Anschlüsse stehen, Möbel bringst du selbst), PaaS die möblierte Wohnung (du ziehst mit deinen Sachen ein), SaaS das Hotelzimmer (du nutzt nur, kümmerst dich um nichts). Und die Konstante über alle drei Modelle: Je weniger du selbst verwaltest, desto weniger kannst du individuell anpassen.

Gute Frage – die Antwort ist erstaunlich unspektakulär: Geschwindigkeit.

• Symmetrisch (z. B. AES): ein gemeinsamer Schlüssel für Ver- und Entschlüsselung. Sehr schnell, auch für große Datenmengen. Problem: Wie bekommt der Empfänger den Schlüssel, ohne dass ihn jemand abfängt? Und: bei n Teilnehmern brauchst du n·(n−1)/2 Schlüssel – bei 100 Leuten schon 4.950.
• Asymmetrisch (z. B. RSA): Schlüsselpaar. Der öffentliche Schlüssel darf jeder haben und verschlüsselt, nur der private entschlüsselt. Kein geheimer Vorab-Austausch nötig, pro Teilnehmer nur ein Paar. Dafür um Größenordnungen rechenintensiver.

Deshalb nimmt man in der Praxis beides zusammen – das hybride Verfahren: Für die eigentliche Nachricht wird ein zufälliger symmetrischer Sitzungsschlüssel erzeugt, und nur dieser kurze Schlüssel wird asymmetrisch mit dem öffentlichen Schlüssel des Empfängers verschlüsselt übertragen. Der Empfänger holt ihn mit seinem privaten Schlüssel heraus und entschlüsselt damit schnell die großen Daten. Genau so arbeiten TLS/HTTPS und verschlüsselte E-Mail. Asymmetrisch löst also das Schlüsselaustausch-Problem, symmetrisch die Massenverarbeitung.

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.