~/teaching · machine learning · referenz
Data Engineering, SRE und Cloud: die Befehle, die Prinzipien und die Berufe, vom Junior zum Experten
Ein Referenz-Foliensatz des Kurses Machine Learning, gemessen an einem echten Kreditdatensatz
Zusammenfassung
Dies ist ein Referenz-Foliensatz des Kurses Machine Learning an der Centrale Méditerranée (Schwerpunkt DDEFI, 2026-2027), gedacht zur Lektüre vor dem Abschlusspraktikum und den ersten Vorstellungsgesprächen. Er behandelt, was ein Modell umgibt, sobald Daten in die Produktion gelangen: wie Daten von ihren Quellen in eine Tabelle kommen, der man vertrauen kann, wie ein Dienst verfügbar bleibt und was er kostet, welche Berufe sich diese Arbeit teilen und was sich vom Junior über den Senior bis zum Experten ändert.
Jeder Befehl wurde auf dem Kursdatensatz ausgeführt (Default of Credit Card Clients, Yeh und Lien, 2009, UCI, 30.000 Kunden), und die Ausgaben sind so wiedergegeben, wie sie kamen; Werkzeuge, die auf dem Vorführrechner fehlten (Docker, Kubernetes, Terraform, die CLIs der Cloud-Anbieter), werden ohne Ausgabe gezeigt statt mit einer erfundenen. Danach können Sie das SQL schreiben, das ein Vorstellungsgespräch verlangt, einen Ladevorgang entwerfen, der sich gefahrlos wiederholen lässt, ein Fehlerbudget berechnen, ein Dockerfile oder einen Terraform-Plan lesen und eine monatliche Cloud-Rechnung schätzen.
Aufbau des Foliensatzes
- Eröffnung. Wie man den Foliensatz liest, eine Karte in fünf Schichten (Quellen, Pipeline, Plattform, Dienst, Beobachtung) und auf jeder Folie eine Kennzeichnung der Niveaustufe.
- Data Engineering. Die Pipeline, Dateiformate, SQL mit DuckDB, Modellierung, Orchestrierung, Datenqualität, die Shell, acht Prinzipien und zwei Berufsprofile.
- SRE und Cloud. Service-Level und Fehlerbudgets, fünf Betriebsprinzipien, Linux und das Netzwerk, Container, Anbieter, Kosten, Störungen, drei Berufsprofile.
- Die Berufe und der Junior. Elf Berufe, belegte Gehaltsrichtwerte, was von einem Junior erwartet wird, Vorstellungsgespräche und der erste Monat.
- Der Senior. Von der Aufgabe zum System: Designdokumente, Entscheidungsprotokolle, Schätzungen, Code-Review, Bereitschaftsdienst und Schreiben.
- Der Experte. Staff- und Principal-Laufbahnen, Plattformarchitektur, Abwägungen, technische Schulden, Migrationen, Compliance.
- Abschluss. Der Weg als Stapel von Kompetenzen, die sich addieren, und wo man in diesem Jahr anfängt.
Die Pipeline und warum Parquet
Daten kommen aus Quellen, landen unverändert in einer Rohdatenzone, werden bereinigt und zu Tabellen modelliert und dann einem Dashboard, einem Modell oder einer API bereitgestellt.
Der Foliensatz folgt dem Lebenszyklus von Reis und Housley (2022): erzeugen, aufnehmen, speichern, transformieren, bereitstellen. Die Rohdatenzone bewahrt das Empfangene genau so auf, wie es ankam, und wird nie verändert, denn mit ihr lässt sich nach einem Fehler alles neu aufbauen. Data Warehouses in der Cloud haben die Reihenfolge der Schritte geändert: erst laden, dann im Warehouse mit SQL transformieren (ELT), das Modell, auf dem dbt aufbaut.
CSV und JSON sind Text: universell, aber groß, langsam zu parsen und ohne Typen. Parquet ist ein spaltenorientiertes Format (columnar format): Es speichert die Daten Spalte für Spalte, komprimiert, mit Typen und mit Minimum und Maximum pro Block. Avro speichert Zeilen mit einem sich weiterentwickelnden Schema, für Nachrichten; Arrow ist ein spaltenorientiertes Layout im Arbeitsspeicher, das pandas, Polars, DuckDB und Spark gemeinsam nutzen. Für eine Ausfallrate braucht man eine von 25 Spalten, also liest Parquet etwa ein Fünfundzwanzigstel der Datei, und dank der Blockstatistiken kann ein Filter ganze Blöcke überspringen.
| Datei | Größe (MB) | Zeit (s) | Mittelwert |
|---|---|---|---|
| credit.csv | 2,7 | 0,505 | 0,2212 |
| credit.parquet | 1,7 | 0,003 | 0,2212 |
| big.csv | 273,4 | 1,142 | 0,2212 |
| big.parquet | 88,9 | 0,012 | 0,2212 |
Merken Sie sich die Größenordnung, nicht die Ziffern: etwa dreimal kleiner und auf diesem Rechner etwa hundertmal schneller, bei gleicher Antwort. Zeiten im Millisekundenbereich sind verrauscht und schwanken von Rechner zu Rechner.
SQL mit DuckDB und das Sternschema
Etwa ein Dutzend SQL-Klauseln decken die meisten Abfragen eines Praktikums ab, und ein Sternschema mit klar benannter Granularität verhindert, dass Summen doppelt gezählt werden.
Der Foliensatz führt mit DuckDB zwölf Klauseln auf der Parquet-Datei aus; DuckDB ist eine analytische Datenbank in einem Python-Paket, die keinen Server braucht. Die Klauseln: Auswahl und Filter, Sortierung, GROUP BY und HAVING, CASE WHEN, Inner Joins und Left Joins, Fensterfunktionen, CTEs, Unterabfragen und ein Index mit EXPLAIN unter SQLite.
| Altersgruppe | Kunden | Ausfallrate | Mittleres Kreditlimit |
|---|---|---|---|
| Unter 30 | 9.618 | 0,228 | 124.209 |
| 30 bis 44 | 15.096 | 0,208 | 194.434 |
| 45 und älter | 5.286 | 0,245 | 169.261 |
Die klassische Frage im Vorstellungsgespräch: WHERE filtert Zeilen vor der Gruppierung, HAVING filtert Gruppen danach. Geben Sie neben einer Quote immer die Anzahl an, denn eine Quote über ein Dutzend Personen sagt nichts. Eine Fensterfunktion gibt jeder Zeile einen über ihre Gruppe berechneten Wert, ohne die Tabelle zusammenzufassen (einen Rang, einen Gruppenmittelwert, die vorherige Zeile mit LAG); nach den Joins ist sie das häufigste SQL-Thema in Vorstellungsgesprächen.
Für die Modellierung stellt Kimballs Sternschema (star schema) eine Faktentabelle mit gemessenen, additiven Ereignissen in die Mitte und Dimensionstabellen (wer, wann, was) darum herum. Entscheidend ist der Satz, der die Granularität festlegt, hier: eine Zeile pro Kunde und Abrechnungsmonat. Ändert sich eine langsam veränderliche Dimension (slowly changing dimension, SCD), überschreibt Typ 1 den alten Wert und verliert die Historie, Typ 2 fügt eine datierte Zeile hinzu, damit sich die Vergangenheit rekonstruieren lässt, Typ 3 behält einen einzigen vorherigen Wert. Das Finanzwesen braucht Typ 2: Den Ausfall von gestern mit dem Wert von heute zu erklären, ist Data Leakage, wie in der Notiz zur logistischen Regression.
Orchestrierung, Idempotenz und Datentests
Eine gute Pipeline lässt sich für jeden beliebigen Tag erneut ausführen, ohne etwas zu verdoppeln, und sie hält vor der Veröffentlichung an, wenn ein Test auf den Daten fehlschlägt.
Ein Orchestrator (Airflow, Prefect, Dagster) führt Aufgaben aus, deren Abhängigkeiten ein gerichteter azyklischer Graph (directed acyclic graph, DAG) beschreibt. Nach Maxime Beauchemin (2018) verarbeitet jeder Lauf ein datiertes Intervall und schreibt eine datierte Partition, sodass ein erneuter Versuch den fehlgeschlagenen Tag wiederholt und eine Nachberechnung (backfill) einen Bereich von Tagen mit unverändertem Code erneut ausführt. Das funktioniert nur, wenn der Job idempotent ist.
Die datierte Partition, wie im Foliensatz gemessen
- Ein Ordner pro Tag. Der Ladevorgang schreibt die Kunden über 60 in einen nach dem Datum benannten
dt=-Ordner, eine Hive-Konvention, die Engines als Spalte zurücklesen. - Erst löschen, dann schreiben. Der Ordner des Tages wird zuerst entfernt, sodass ein zweiter Lauf die Partition ersetzt, statt Zeilen an sie anzuhängen.
- Wiederholen und zählen. Mit dem doppelt geladenen 12. Oktober enthält jeder Tag weiterhin 272 Zeilen, nicht 544. Ein Anhängen hätte den Tag stillschweigend verdoppelt.
Datentests. Ein Test ist eine Abfrage, die Anomalien zählt und null zurückgeben muss; andernfalls hält die Pipeline vor der Veröffentlichung an, denn ein verspätetes Dashboard ist besser als ein falsches. Der Foliensatz schreibt die vier generischen Tests von dbt von Hand (nicht null, eindeutig, zulässige Werte, plausibler Bereich). Drei bestehen; der Test auf zulässige Werte findet 345 Kunden mit den Bildungscodes 0, 5 oder 6, die in der Dokumentation fehlen. Ein fehlschlagender Test verlangt eine schriftliche Entscheidung, nicht unbedingt eine Korrektur.
Auf Senior-Niveau beantworten ein Datenvertrag (data contract), die Datenherkunft (lineage) und ein Katalog die Frage, was nachgelagert kaputtgeht, wenn sich vorgelagert eine Spalte ändert.
SRE: SLI, SLO und das Fehlerbudget
Zuverlässigkeit wird wie ein Produktmerkmal mit einer Kennzahl behandelt: Man misst sie, einigt sich auf ein Ziel unter hundert Prozent und investiert den Abstand in Änderungen.
Site Reliability Engineering, entstanden bei Google und 2016 im Buch von Beyer und Kollegen beschrieben, beruht darauf, Zuverlässigkeit zu messen, repetitive Arbeit zu automatisieren und aus Störungen ohne Schuldzuweisung zu lernen. Der SLI ist das Verhältnis guter Ereignisse zu allen Ereignissen (etwa Scoring-Anfragen, die in weniger als 300 ms beantwortet werden). Das SLO ist das interne Ziel dafür, zum Beispiel 99,9 % über 30 Tage. Das SLA ist ein lockererer Vertrag mit Vertragsstrafen, damit das Team gewarnt wird, bevor es zahlen muss. 100 % anzustreben ist ein Fehler: Jede zusätzliche Neun kostet weit mehr, und die Nutzer bemerken sie nicht.
Rechenbeispiel mit den illustrativen Werten des Foliensatzes
- Das Zeitfenster. Dreißig Tage umfassen Minuten.
- Das Budget. Bei 99,9 % ergibt ein Zehntelprozent davon 43,2 Minuten, also 2.000 fehlgeschlagene von 2 Millionen Anfragen. Bei 99 % wären es 432 Minuten, bei 99,99 % etwa 4,3.
- Die Verbrauchsrate. Wer an einem Tag 10 Minuten verliert, kommt auf , fast das Siebenfache des gleichmäßigen Tempos.
- Die Erschöpfung. In diesem Tempo ist das Budget des Monats nach Tagen aufgebraucht.
Das Fehlerbudget (error budget) entscheidet: Solange etwas übrig ist, liefert das Team aus; ist es aufgebraucht, warten neue Funktionen, und die Arbeit geht in die Zuverlässigkeit. Die Alarmierung richtet sich nach der Verbrauchsrate (burn rate), nicht nach jedem einzelnen Fehler. Routinearbeit (toil), die manuelle Arbeit, die mit dem Traffic wächst, wird begrenzt und wegautomatisiert; der Bereitschaftsdienst braucht für jeden Alarm eine schriftliche Handlungsanweisung.
Störungen. Zuerst eindämmen (zurückrollen, eine Funktion abschalten, Kapazität hinzufügen), später verstehen, dann ein Post-Mortem ohne Schuldzuweisung (blameless post-mortem) mit datierten Maßnahmen und Verantwortlichen schreiben. Im fiktiven Fall des Foliensatzes wird ein Release, dem eine Konfigurationsvariable fehlt, vom Alarm auf die Verbrauchsrate erkannt und zurückgerollt, was 39 der 43,2 Minuten des Monats kostet.
Infrastructure as Code, Docker und Kubernetes
Server, Berechtigungen und Deployments werden in versionierten Dateien beschrieben und aus Images neu aufgebaut, nie von Hand in einer Webkonsole repariert.
- Alles ist Code (Kief Morris, 2016): Die Infrastruktur liegt in geprüften Dateien und lässt sich identisch neu aufbauen.
- Unveränderlich: Ein Server wird durch ein neues, getestetes Image ersetzt, nie von Hand gepatcht; zurückrollen heißt, das vorherige Image erneut bereitzustellen.
- Kleiner Auswirkungsradius (blast radius): Eine Änderung erreicht zuerst einen kleinen Teil des Traffics (ein Canary) und wird automatisch zurückgerollt, wenn der SLI sinkt.
- Minimale Rechte (Saltzer und Schroeder, 1975): Jede Person und jedes Programm erhält nur die Rechte, die sie oder es braucht.
- Ein getestetes Backup: Nur eine Wiederherstellungsübung beweist, dass es funktioniert, wie der Ausfall bei GitLab am 31. Januar 2017 gezeigt hat.
Die Terraform-Datei des Foliensatzes deklariert einen versionierten, mit Tags versehenen Speicher-Bucket für Rohdaten in der Region Paris. Der Zyklus ist init, plan, dann apply nach der Prüfung; erst das Lesen des Plans deckt ein unerwartetes Löschen auf. Terraform war auf dem Vorführrechner nicht installiert, daher wurde nichts ausgeführt.
Ein Container ist ein isolierter Prozess, der sein System, Python, Pakete und Code mitbringt; er teilt sich den Kernel des Hosts und startet deshalb innerhalb einer Sekunde. Gute Gewohnheiten im Dockerfile: ein schlankes offizielles Basis-Image, Abhängigkeiten vor dem Code wegen des Layer-Caches, ein Benutzer ohne Root-Rechte, Konfiguration über Umgebungsvariablen. Kubernetes hält den tatsächlichen Zustand eines Clusters im Einklang mit dem deklarierten: Pods, ein Deployment, das ausgefallene Kopien neu erzeugt, ein Service mit stabiler Adresse, ein Ingress für externen Traffic. Für ein kleines Team reicht oft ein verwalteter Container-Dienst.
Bemerkung (Die Brücke zum Machine Learning). MLOps wendet dieselben Regeln auf Modelle an (Versionierung, Registry, eine API in einem Container, Monitoring), mit einer Ergänzung: Ein Modell kann sich ohne jeden Ausfall verschlechtern, weil die Daten driften, siehe die Notiz zum Drift.
Cloud und FinOps: was ein Monat wirklich kostet
In der Cloud hat jede Ressource einen Zähler, der weiterläuft, und die Rechnung hängt oft mehr von den Daten ab, die den Anbieter verlassen, als vom Speicher.
AWS, Azure und Google Cloud dominieren; OVHcloud, Scaleway und Hetzner spielen für Preis und Souveränität eine Rolle, denn auf Daten, die ein US-Unternehmen hält, kann über den CLOUD Act (2018) zugegriffen werden. Die Bausteine sind überall dieselben, nur unter anderen Namen: Rechenleistung, Objektspeicher, verwaltete Datenbanken, Warteschlangen, Funktionen, ein Data Warehouse, Identitäten. Vier Zähler laufen ständig: Rechenleistung pro Stunde, Speicher pro Gigabyte und Monat, ausgehender Datenverkehr (egress) pro Gigabyte, das den Anbieter verlässt, und Anfragen pro Tausend.
| Posten | AWS Paris (USD) | Scaleway Paris (EUR) |
|---|---|---|
| Virtuelle Maschine | 34,46 | 16,79 |
| Objektspeicher, 100 GB | 2,40 | 1,61 |
| Ausgehender Datenverkehr, 500 GB | 36,00 | 4,25 |
| Anfragen | 0,95 | inklusive |
| Verwaltetes PostgreSQL und Disk | 15,80 | 13,37 |
| Summe | 89,61 | 36,02 |
Bei AWS kostet der ausgehende Datenverkehr so viel wie die Maschine: 400 abrechenbare Gigabyte zu 0,090 US-Dollar. Die Summen stehen in zwei Währungen, und die Maschinen sind vergleichbar, nicht identisch: Lesen Sie also eine Größenordnung ab. Im Finanzwesen prägt auch die Compliance die Architektur: die DSGVO, die DORA-Verordnung (anwendbar seit dem 17. Januar 2025), die KI-Verordnung (AI Act), die das Kredit-Scoring natürlicher Personen als hochriskant einstuft, und NIS2.
Die Berufe, die Gehälter und die Stufen Junior, Senior, Experte
Die Stufen unterscheiden sich weniger durch Werkzeuge als durch den Verantwortungsbereich: Ein Junior erledigt eine Aufgabe zuverlässig, ein Senior verantwortet ein System, ein Experte gestaltet eine Plattform.
Der Data Engineer baut die Leitungen; der Analytics Engineer macht aus Rohtabellen getestete Fachtabellen; das Fundament ist die Arbeit des Cloud- oder Platform Engineers; der SRE- oder DevOps-Engineer verantwortet die Verfügbarkeit; MLOps zieht sich durch alle diese Rollen.
| Richtwert | Zahl | Quelle |
|---|---|---|
| Frankreich, Berufsfamilie Big Data, Führungskräfte unter 35, Median | 48.000 € | Apec, Studie zur Vergütung von Führungskräften, Dezember 2025 |
| Frankreich, Data Engineer, Gehälter in Stellenanzeigen (Spanne für 80 % der Angebote) | 35.000 bis 60.000 € | Apec-Berufsprofile, abgerufen am 12. Oktober 2026 |
| Frankreich, Absolventen von Ingenieurhochschulen, Median ohne Prämien | 39.000 € | CGE-Umfrage 2026 |
| Luxemburg, Sektor Information und Kommunikation, Median | 72.157 € | STATEC, Verdiensterhebung 2022 |
| Vereinigte Staaten, Data Scientists, Median | 120.230 USD | BLS, Mai 2025 |
Keine öffentliche Statistik nennt das Gehalt eines Data Engineers in Luxemburg, und die Apec hat kein Berufsprofil für SRE oder MLOps: Diese Richtwerte vergleichen Berufe, sie legen kein erstes Angebot fest. Siehe auch die Notiz zur Geschichte der KI und zu den Berufen.
Junior. Niemand erwartet, dass ein Junior alles weiß, nur dass er nützlich und vertrauenswürdig wird: SQL, Python, Git, das Terminal, nach einer angemessenen eigenen Suche fragen, kleine Änderungen, die Produktion nie ohne Sicherheitsnetz anfassen. Die üblichen Fehler: allein festhängen, riesige Pull Requests, ein zerstörerischer Befehl im falschen Konto, ungeprüfte Zahlen, nichts aufschreiben.
Senior. Der Schritt hängt vom Verantwortungsbereich ab, nicht von den Jahren: ein vages Problem und ein System, für das man geradesteht. Der Senior schreibt ein Designdokument, hält Entscheidungen in einem ADR fest (Michael Nygard, 2011), schätzt in Spannen, prüft Code und betreut andere. Experte. Staff- und Principal Engineers arbeiten in Abwägungen: Kosten gegen Latenz, Konsistenz gegen Verfügbarkeit (CAP, PACELC), selbst bauen gegen kaufen, und sie wählen die einfachste Option, die das SLO und das Budget einhält. Was sich nicht ändert: SQL, die Shell, Netzwerkprotokolle, Idempotenz, messen, bevor man glaubt, klar schreiben.
Das Wichtigste in Kürze
- Bewahren Sie Rohdaten unverändert auf und machen Sie jeden Ladevorgang idempotent: Eine datierte Partition, die ersetzt und nie ergänzt wird, macht Wiederholungen harmlos.
- Spaltenorientierte Formate wie Parquet lesen nur die Spalten, die eine Abfrage braucht; auf den Kursdaten war die Datei etwa dreimal kleiner und viel schneller zu durchsuchen.
- Ein Datentest ist eine Abfrage, die null Zeilen zurückgeben muss, und ein fehlschlagender Test stoppt die Veröffentlichung.
- Ein SLO von 99,9 % über 30 Tage erlaubt 43,2 Minuten Ausfallzeit, und die Alarmierung sollte darauf achten, wie schnell dieses Budget verbraucht wird.
- Infrastruktur gehört in versionierten Code, Server werden durch neue Images ersetzt, und Backups beweisen sich erst durch Wiederherstellungen.
- In der Cloud wiegen ausgehender Datenverkehr und weiterlaufende Maschinen oft schwerer als der Speicher.
- Junior, Senior und Experte unterscheiden sich im Verantwortungsbereich; die Grundlagen bleiben dieselben.
Glossar
- ELT
- Extrahieren, laden, dann mit SQL im Data Warehouse transformieren.
- spaltenorientiertes Format (columnar format)
- Ein Dateilayout, das jede Spalte zusammenhängend speichert (Parquet), sodass eine Abfrage nur liest, was sie braucht.
- Sternschema (star schema)
- Eine Faktentabelle mit gemessenen Ereignissen, umgeben von Dimensionstabellen, die deren Kontext beschreiben.
- langsam veränderliche Dimension (slowly changing dimension, SCD)
- Eine Dimension, deren Werte sich im Lauf der Zeit ändern; Typ 2 bewahrt jede Version mit ihren Gültigkeitsdaten auf.
- gerichteter azyklischer Graph (directed acyclic graph, DAG)
- Aufgaben, die durch Abhängigkeitspfeile ohne Schleife verbunden sind und von einem Orchestrator ausgeführt werden.
- Idempotenz
- Ein Job hinterlässt denselben Zustand, ob er einmal oder mehrmals läuft.
- Nachberechnung (backfill)
- Die erneute Ausführung einer Pipeline über einen zurückliegenden Zeitraum mit dem aktuellen Code.
- Datenvertrag (data contract)
- Die versionierte Zusage eines Datenproduzenten zu Spalten, Typen und Aktualität.
- Fehlerbudget (error budget)
- Der Anteil an Fehlschlägen, den ein SLO über sein Zeitfenster zulässt.
- Verbrauchsrate (burn rate)
- Wie schnell das Fehlerbudget im Vergleich zu einem gleichmäßigen Tempo verbraucht wird.
- Routinearbeit (toil)
- Manuelle, repetitive, automatisierbare Betriebsarbeit, die mit dem Dienst wächst.
- Auswirkungsradius (blast radius)
- Der Anteil der Nutzer oder Systeme, die betroffen sind, wenn eine Änderung schiefgeht.
- ausgehender Datenverkehr (egress)
- Netzwerkverkehr, der einen Cloud-Anbieter verlässt, pro Gigabyte abgerechnet.
Die anderen Notizen des Kurses
Eine öffentliche Zusammenfassung pro Foliensatz, in der Reihenfolge des Kurses.
Zurück: Handbuch für Daten- und KI-FachleuteWeiter: Panorama der Machine-Learning-Modelle
- EinführungKI-Winter, Arbeitsmarkt und Methode
- WerkzeugeKaggle, GitHub, Python: die Werkzeuge
- Sitzung 1Projektrahmen und kleinste Quadrate
- Sitzung 2Maximum Likelihood und logistische Regression
- Sitzung 3Gradientenabstieg, Ridge und Lasso
- Sitzung 4Entscheidungsschwelle und reproduzierbares ML
- HausaufgabeML-Projekt abstecken: der Projektsteckbrief
- Sitzung 5Kernel, SVM und Entscheidungsbäume
- Sitzung 6Random Forests, Boosting, ehrlicher Vergleich
- Sitzung 7SHAP, Fairness, PCA und Clustering
- HausaufgabeEin einfaches Modell mit vollständiger Methode
- Sitzung 8Neuronale Netze, Drift, konforme Vorhersage
- HausaufgabeEin ausgeliefertes Machine-Learning-Projekt
- Sitzung 9Ein Machine-Learning-Projekt verteidigen
- ReferenzProjekt zum Kreditausfallscore
- ReferenzAktienrenditen: XGBoost und Sentiment
- ReferenzPython-Code für jedes ML-Modell
- ReferenzDeep Learning, das Wesentliche
- ReferenzML-Projekte mit offenen Daten nach Branche
- ReferenzHandbuch für Daten- und KI-Fachleute
- ReferenzData Engineering, SRE und Cloud
- ReferenzPanorama der Machine-Learning-Modelle
Über diese Notizen
Vom Dozenten auf Grundlage der Folien verfasst, als öffentliche Zusammenfassung: die Kernideen, die Formeln und ein durchgerechnetes Beispiel. Die Übungen, ihre Lösungen, die Tests und die Bewertung bleiben im Foliensatz, für die Studierenden des Kurses.
Stand: .