Explorative Analyse von Speiseplänen in Deutschlands Mensen

Fallstudie im Sommersemester 2026

Autor:innen

Prof. Dr. Nicolas Meseth

Prof. Dr. Melanie Speck

Julia Heinz

Hintergrund

Die Fallstudie steht im Kontext des Forschungsprojekts “Linse”, in dessen Rahmen Daten zu den Speiseplänen von Mensen an Universitäten und Hochschulen in Deutschland gesammelt wurden. Die Daten stammen aus den IT-Systemen der jeweiligen Studierendenwerke und bieten die Gelegenheit, die Entwicklung der Speisepläne über einen Zeitraum von fast einem Jahrzehnt zu analysieren.

Das Projekt Linse zielt darauf ab, den Leguminosenkonsum zu steigern, und untersucht mögliche Maßnahmen insbesondere im Außer-Haus-Verzehr. Dazu zählen auch Großküchen wie die Mensen der Studierendenwerke, die täglich Tausende von Mahlzeiten zubereiten und damit erheblichen Einfluss auf die Ernährungsgewohnheiten der Studierenden nehmen können.

Forschungsfragen

Von zentralem Interesse für das Projekt ist, wie sich die Zusammensetzung der Speisepläne in den Mensen über die Zeit verändert hat, insbesondere der Anteil an Hülsenfrüchten und die Hauptproteinquelle der angebotenen Speisen.

Bevor die eigentliche Analyse beginnen kann, müssen die Daten harmonisiert werden: Jede Mensa verwendet eigene Bezeichnungen für die Speisen, viele davon inhaltlich ähnlich oder identisch, und die Rohdaten sind über zahlreiche Excel- und CSV-Dateien mit teils unterschiedlichen Strukturen verteilt.

Auf dieser Grundlage sollen Antworten auf die folgenden Forschungsfragen erarbeitet werden:

  • Wie hat sich die Zusammensetzung der Speisepläne in den Mensen über die Zeit entwickelt? Gibt es erkennbare Trends, etwa in Bezug auf die Anzahl der vegetarischen oder veganen Gerichte oder den Anteil von Gerichten mit Hülsenfrüchten? Gibt es Unterschiede zwischen den Mensen und Studierendenwerken?

  • Was sind die wichtigsten Proteinquellen und deren Anteile in den angebotenen Gerichten? Wie ist die Entwicklung über die Zeit? Gibt es hier Unterschiede zwischen den Mensen und Studierendenwerken?

Informationen zum Datensatz

Der Datensatz besteht aus einer Vielzahl von Excel- und CSV-Dateien, die die Speisepläne von insgesamt 31 Mensen von 13 verschiedenen Studierendenwerken in Deutschland über einen Zeitraum von mehreren Jahren enthalten. Insgesamt sind mehr als 1,3 Mio. Einträge enthalten.

Folgende Studierendenwerke sind im Datensatz enthalten:

Studierendenwerk Dateien Ordner
Brandenburg Ost 5 data/projekt-linse/brandenburg-ost
Chemnitz-Zwickau 5 data/projekt-linse/chemnitz-zwickau
Erlangen-Nürnberg 1 data/projekt-linse/erlangen-nuernberg
Freiburg 1 data/projekt-linse/freiburg
Kassel 1 data/projekt-linse/kassel
Mainz 1 data/projekt-linse/mainz
Oldenburg 6 data/projekt-linse/oldenburg
Osnabrück 3 data/projekt-linse/osnabrueck
Paderborn 3 data/projekt-linse/paderborn
Saarland 1 data/projekt-linse/saarland
Schleswig-Holstein 1 data/projekt-linse/schleswig-holstein
Stuttgart 1 data/projekt-linse/stuttgart
Wuppertal 2 data/projekt-linse/wuppertal

Jedes Studierendenwerk verwendet eine abweichende Struktur im Hinblick auf die Spaltennamen und die enthaltenen Informationen. Manche Spalten existieren nur in bestimmten Studierendenwerken. Es gibt einige gemeinsame Kernvariablen, die in der folgenden Tabelle zusammengefasst sind. Diese sind mit Ausnahme des Studierendenwerks “Brandenburg Ost” in allen Dateien enthalten. Brandenburg Ost weist eine vollständig abweichende Dateistruktur auf, die nicht mit den übrigen Studierendenwerken kompatibel ist, und wird daher in Teil 1 nicht berücksichtigt:

Variablenname Beschreibung
Prod.Dat. Das Datum, an dem die Speise im Plan angeboten wurde
Prod.Art. Die Art der Speise, wie “Beilage”, “Hauptgericht”, “Dessert” usw.
Bezeichnung Die vom Studierendenwerk vergebene Bezeichnung der Speise
Produktionsort Der Ort, an dem die Speise zubereitet wird
Ausgabe Die Anzahl der Portionen, die tatsächlich ausgegeben wurden
Ausgabetext Der Text, der auf der Speisekarte erscheint, ggf. mit Zusatzangaben

Aufgabenstellung

Teil 1: Zusammenführung und Bereinigung

Im ersten Teil dieser Fallstudie überführt ihr die Dateien der Studierendenwerke — mit Ausnahme von Brandenburg Ost, dessen Daten eine vollständig abweichende Struktur aufweisen — in eine einheitliche CSV-Datei. Dafür verwendet ihr R und die Funktionen aus dem Tidyverse. Die Zieltabelle soll die folgende Struktur haben:

Variablenname Datentyp Beschreibung
id dbl Eine eindeutige fortlaufende ID für jede Zeile
source_file chr Der Name der Quelldatei, aus der die Zeile stammt
student_service fct Das Studierendenwerk, dem die Zeile zugeordnet werden kann
cafeteria fct Die Mensa, der die Zeile zugeordnet werden kann
date date Das Datum, an dem die Speise im Plan angeboten wurde
product_type chr Die Art der Speise, wie “Beilage”, “Hauptgericht”, “Dessert”
product_name chr Die vom Studierendenwerk vergebene Bezeichnung der Speise
production_location chr Der Ort, an dem die Speise zubereitet wird
actual_output dbl Die Anzahl der Portionen, die tatsächlich ausgegeben wurden
menu_text chr Der Text, der auf der Speisekarte erscheint

Speichert die Zieltabelle als data/menus_consolidated.csv ab.

Erstellt für die Überführung der Daten ein R-Skript scripts/consolidate.R, das von oben nach unten ausführbar ist. Verwendet Kommentare, um die Schritte eurer Datenbereinigung zu erklären und zu dokumentieren. Beginnt mit dem Laden der Quelldateien, führt dann Schritt für Schritt die notwendigen Transformationen durch und speichert die fertige Zieltabelle als CSV-Datei ab. Nutzt dafür write_csv() aus dem readr-Paket.

TippHinweis

Ein mögliches Ergebnis für den ersten Teil der Fallstudie findet ihr in der Datei menus_consolidated.csv im Ordner data/. Ihr könnt euch an diesem Ergebnis orientieren und damit in den folgenden Aufgaben arbeiten. Diesen Teil der Fallstudie müsst ihr somit nicht bearbeiten.

Teil 2: Einheitliche Klassifikation der Speisen

Im zweiten Teil klassifiziert ihr die Speisen inhaltlich nach einem Klassifikationsschema, das das Projekt Linse entwickelt hat. Dabei sollt ihr für eine Speise wie folgt vorgehen:

  1. Prüft, ob einer Speise eine oder mehrerer Lebensmittelklassen aus dem Klassifikationsschema zugeordnet werden können. Die Zuordnung geschieht auf Basis der (angenommenen) Hauptzutaten einer Speise. Diese können aus dem Speisentext explizit ersichtlich sein, es kann aber auch notwendig sein, sie durch Wissen über die typischen Rezepte eines Gerichts abzuleiten.

    Beispiel 1: Ein Gericht “Kalbsschnitzel mit Kartoffeln und Champignonrahmsauce” besteht aus den drei Komponenten “Kalbschnitzel”, “Kartoffeln” und “Champignonrahmsauce”. Eure Klassifikation sollte entsprechend diesem Gericht die Klassen “Rotes Fleisch”, “Knollen / stärkehaltige Gemüse” und “Gemüse” (für die Pilze) sowie “Milchprodukte” (für den Rahm) zuordnen.

    Beispiel 2: Ein Gericht “Flammkuchen Griechischer Art” könnte den Lebensmittelklassen “Weizen” (für den Teig), “Milchprodukte” (für den Käse) und “Gemüse” (für die Tomaten) zugeordnet werden. Keine der Komponenten steht explizit im Speisentext.

  2. Entscheidet für jede enthaltene Lebensmittelklasse, wie groß der Anteil an der gesamten Speise ist. Verwendet dafür eine einfache qualitative Skala.

Mit der Zuordnung zu einer Lebensmittlklasse ist auch die Zuordnung zu einer Hauptproteinquelle verbunden, die über ein Codesystem definiert ist. Auf der Grundlage der in Schritt 2 ermittelten ungefähren Anteile jeder Klasse könnt ihr später die Proteinzusammensetzung der Speisepläne analysieren und die Entwicklung über die Zeit verfolgen.

Überlegt euch ein effizientes und reproduzierbares Vorgehen, um die Speisen zu Lebensmittelklassen aus dem Klassifikationsschemas zuzuordnen. Nutzt dabei sowohl die Techniken der regelbasierten Arbeit mit Texten, speziell für die Vorverarbeitung, als auch die KI-gestützte Vorgehensweise mit Sprachmodellen. Auch manuelle Schritte können hilfreich oder notwendig sein.

Es ist wichtig, dass ihr die Genauigkeit eurer Klassifikation bewerten und einordnen könnt. Denkt bei der Entwicklung eures Vorgehens also auch daran, wie er das Ergebnis evaluieren könnt und entscheidet auf dieser Basis, ob eine Veränderung eures Vorgehens das Ergebnis verbessert oder verschlechtert hat.

Eure Verarbeitungsschritte müssen gut dokumentiert, reproduzierbar und nachvollziehbar sein. Erstellt deshalb ein zentrales R-Skript scripts/classify.R, von dem aus alle relevanten Schritte ausgeführt werden. Wenn ihr auf Sprachmodelle zurückgreift, ruft die Python-Funktionen über das reticulate-Paket und die Funktion source_python() auf, damit die gesamte Verarbeitung von einem Skript gesteuert wird. Bei komplexen Schritten mit R könnt ihr den Code in Sub-Skripte auslagern, die aus dem zentralen Skript mittels source() aufgerufen werden. Stellt sicher, dass die Skripte fehlerfrei von oben nach unten ausführbar sind und alle Dateiverweise relativ angegeben werden.

Erweitert die Zieltabelle aus Teil 1 um die folgenden Spalten, die die Klassifikation der Speisen enthalten:

Neue Variable Datentyp Beschreibung
group_level_1 fct Die Zuordnung zur Ernährungsform “omnivor”, “vegetarisch” oder “vegan”
group_level_2 fct Die Zuordnung zur Lebensmittelklasse, etwa “Rotes Fleisch”, “Geflügel” oder “Milchprodukte”
code_main_protein fct Die Zuordnung zur Hauptproteinquelle über ein Codesystem

Speichert die erweiterte Zieltabelle mit den obigen Klassifikationsspalten als menus_classified.csv im Ordner data/ ab.

Das Klassifikationsschema für die Lebensmittelgruppen inklusive der Codierung für die Proteinquelle aus dem Projekt Linse findet ihr in der Datei classification_schema.xlsx im Ordner data/projekt-linse.

TippHinweis: Entwickelt zunächst mit einer Stichprobe

Zieht eine reproduzierbare, zufällige Stichprobe für die Entwicklung eures Vorgehens für die Klassifikation. Für die Evaluation bietet es sich an, die Stichprobe einmal manuell zu klassifizieren und etwa in einer Excel-Datei zu speichern. Damit hättet ihr eine Grundlage für die Evaluation, die dann natürlich automatisch durchgeführt werden sollte.

TippHinweis: Gute Vorverarbeitung reduziert den Aufwand

Bei der Enteilung eines Gerichts in Lebensmittelklassen werden euch Sprachmodelle helfen können. Dabei ist es nicht notwendig, alle 1,1 Mio. Einträge durch ein LLM klassifizieren zu lassen. Über eine gute, regelbasierte Vorverarbeitung könnt ihr die Anzahl der Einträge, die ihr an ein LLM übergeben müsst, erheblich reduzieren.

Teil 3: Explorative Analysen

Im dritten Teil der Fallstudie erntet ihr die Früchte der aufwendigen Vorarbeit. Auf der Basis der zusammengeführten, harmonisierten und klassifizierten Daten beantwortet ihr die folgenden Forschungsfragen mit geeigneten Analysen:

  • Wie hat sich die Zusammensetzung der Speisepläne in den Mensen über die Zeit entwickelt? Gibt es erkennbare Trends, etwa in Bezug auf die Anzahl der vegetarischen oder veganen Gerichte oder den Anteil von Gerichten mit Hülsenfrüchten? Gibt es Unterschiede zwischen den Mensen und Studierendenwerken?

  • Was sind die wichtigsten Proteinquellen und deren Anteile in den angebotenen Gerichten? Wie ist die Entwicklung über die Zeit? Gibt es hier Unterschiede zwischen den Mensen und Studierendenwerken?

  • Welche Schlüsse lassen sich zu der Beliebtheit der Speisen mit unterschiedlichen Proteinquellen ziehen? Gibt es hier Unterschiede zwischen den Mensen und Studierendenwerken?

Erstellt ein oder mehrere R-Skripte scripts/analyze.R bzw. scripts/subscripts_analyze/, in denen ihr sämtliche Analysen durchführt und die Visualisierungen erstellt, die ihr später auf eurem Poster verwendet. Ihr könnt die Analysen auf mehrere Skripte aufteilen, die im zentralen Skript mithilfe von source() eingebunden werden.

Das Skript sollte alle Visualisierungen beim Ausführen automatisch erstellen und im Ordner communications/visualizations/ abspeichern. Verwendet für die Visualisierungen ausschließlich Funktionen aus dem ggplot2-Paket (und entsprechend Erweiterungspakete wie z. B. ggridges) und gestaltet sie so, dass sie auf einem wissenschaftlichen Poster präsentiert werden können. Achtet dabei auf eine einheitliche Auswahl der Farben, die Formatierung der Achsen und die Lesbarkeit der Beschriftungen.

Teil 4: Erstellung eines wissenschaftlichen Posters

Auf der Basis eurer Analysen erstellt ihr ein wissenschaftliches Poster, das die wichtigsten Ergebnisse ansprechend und strukturiert präsentiert. Es sollte so klar und übersichtlich gestaltet sein, dass Betrachtende die zentralen Befunde schnell erfassen können.

Erstellt das Poster mit einem Werkzeug eurer Wahl (z. B. PowerPoint, Canva, Inkscape oder Quarto) im Hochformat (Portrait, DIN A0: 841 × 1189 mm) und exportiert es als PDF-Datei. Speichert es im Projekt unter communications/poster.pdf. Bringt eine ausgedruckte Version im Format DIN A0 zum Präsentationstermin mit, damit ihr es im Rahmen der Poster-Galerie präsentieren könnt.

Bewertung

Die Fallstudie wird mit insgesamt 100 Punkten bewertet, die sich wie folgt auf die vier Teile verteilen:

Teil Gewichtung Schwerpunkt der Bewertung
Teil 1: Datenzusammenführung 0 % Vollständigkeit und Korrektheit der Zieltabelle, Codequalität
Teil 2: Klassifikation 50 % Tiefe und Kreativität der Lösung, Nachvollziehbarkeit des Vorgehens, Reproduzierbarkeit, Abdeckung
Teil 3: Explorative Analysen 30 % Relevanz der Analysen, Qualität der Visualisierungen
Teil 4: Poster und Präsentation 20 % Gestaltung, Verständlichkeit, Präsentation und Diskussionsfähigkeit

Übergreifend gelten in allen Teilen folgende Kriterien:

  • Reproduzierbarkeit: Die Skripte laufen ohne Anpassungen auf einem anderen Rechner durch.
  • Codequalität: Lesbarer, einheitlich formatierter Code ohne überflüssige Reste oder Kommentare.
  • Dokumentation: Annahmen und Designentscheidungen sind im Code oder in der README.md nachvollziehbar festgehalten.

Hinweise zur Fallstudie

Bearbeitung

  • Beantwortet die Forschungsfragen mithilfe von geeigneten Visualisierungen. Verzichtet auf tabellarische Darstellungen und nutzt sie nur als Ergänzung.

  • Führt die explorative Datenanalyse ausschließlich mit R durch. Für sämtliche Datentransformationen und Visualisierungen verwendet ihr Funktionen aus dem Tidyverse.

  • Die explorative Datenanalyse lebt von eurer Kreativität und Ausdauer. Gebt euch nicht mit der ersten Analyse zufrieden, die ihr erstellt. Probiert mehrere Ansätze aus. Wenn ihr ein interessantes Muster entdeckt, geht dem tiefer auf den Grund. Obwohl alle Teams die gleichen Aufgaben haben, wird es viele verschiedene Lösungswege geben.

  • Wenn ihr bei einer Aufgabe nicht sicher seid, wie sie gemeint ist, oder euch Informationen fehlen, trefft sinnvolle Annahmen und dokumentiert sie. Nutzt die Fragetermine, um Unklarheiten zu beseitigen.

  • Lesbarer Code ist besser als schwer verständlicher Code. Verwendet den Pipe-Operator, verteilt lange Ausdrücke auf mehrere Zeilen, rückt den Code ein und fügt Kommentare hinzu, wo es angebracht ist. Entfernt Codereste, die nicht mehr benötigt werden, um die Übersicht zu verbessern.

  • Reproduzierbarkeit ist in der Wissenschaft von großer Bedeutung. Stellt sicher, dass eure R-Skripte ohne zusätzlichen Aufwand auf einem anderen Computer ausgeführt werden können. Vermeidet also unbedingt absolute Pfadangaben und haltet euch strikt an die Projektstruktur (s. unten).

  • Es ist in Ordnung, sich bei der Analyse inspirieren zu lassen. Auch die Übernahme von Ideen oder Code anderer, inklusive der Einsatz von KI, ist erlaubt, solange der verwendete Code verstanden und erklärt werden kann und die Quelle als Kommentar angegeben wird.

  • Make it work, make it nice! Erst die Funktion, dann die Ästhetik! Verliert euch nicht in Details wie Achsenformatierung oder Farbpaletten, bevor ihr die korrekte Datenbasis erstellt und die geeignete Visualisierungsform gewählt habt. Eine unpassende Visualisierung, selbst wenn sie optisch ansprechend ist, wird euch nicht helfen. Denkt umgekehrt! Auf eurem Poster sollte aber alles glänzen.

Abgabe

  • Die Abgabe erfolgt über eine ZIP-Datei, die alle Dateien enthält, die ihr für die Bearbeitung der Fallstudie verwendet und erstellt habt. Die ZIP-Datei sollte die gleiche Struktur haben wie das bereitgestellte Repository, nur um eure Arbeiten ergänzt:

    case-study-linse/
├── data/
│   ├── projekt-linse/
│   │   ├── brandenburg-ost/
│   │   ├── chemnitz-zwickau/
│   │   ├── erlangen-nuernberg/
│   │   ├── freiburg/
│   │   ├── kassel/  
│   │   ├── mainz/
│   │   ├── oldenburg/
│   │   ├── osnabrück/
│   │   ├── paderborn/
│   │   ├── saarland/
│   │   ├── schleswig-holstein/
│   │   ├── stuttgart/
│   │   └── wuppertal/
│   ├── menus_consolidated.csv
│   └── classification_schema.xlsx
├── communications/
│   ├── visualizations/
│   │   ├── scatter_plot.svg
│   │   └── ...
│   └── poster.pdf
├── scripts/
│   ├── subscripts_classify/
│   │   ├── <script_name>.R
│   │   ├── <script_name>.py
│   │   └── ...
│   ├── subscripts_analyze/
│   │   ├── <script_name>.R
│   │   └── ...
│   ├── setup.R
│   ├── classify.R
│   └── analyze.R
└── README.md

Postergalerie und Präsentation

  • Im Rahmen der Postergalerie präsentiert jede Gruppe ihr Poster in 10 Minuten. Während der Präsentation sollte jedes Gruppenmitglied ungefähr den gleichen Sprechanteil haben.

  • Im Anschluss an die Präsentation findet eine Frage- und Diskussionsrunde statt. Stellt sicher, dass jedes Gruppenmitglied auf mögliche Fragen vorbereitet ist. Das gilt auch für das Erläutern bestimmter Schritte eurer Analyse, die vielleicht nicht auf dem Poster dargestellt sind.

  • Das Poster im PDF-Format müsst ihr nicht zeitgleich mit den anderen Ergebnissen einreichen. Ihr müsst es aber bis spätestens 21 Uhr am Abend vor der Postergalerie abgegeben haben.

Viel Spaß und Erfolg bei der Bearbeitung der Fallstudie!