Zwei Hotels, vier Fragen
Der Datensatz beschreibt die Buchungen zweier Hotels derselben Kette in Portugal: ein City Hotel in Lissabon und ein Resort Hotel an der Algarve. Jede Zeile ist eine Buchung mit Anreisedatum zwischen Juli 2015 und August 2017 – ob sie angetreten wurde oder nicht. Die Daten enthalten auch die stornierten Buchungen – 44.224, mehr als jede dritte. Die Daten stammen aus dem Artikel Hotel booking demand datasets von Nuno Antonio, Ana de Almeida und Luis Nunes, erschienen in Data in Brief, Band 22, Februar 2019 (CC BY 4.0); Lab 01 beschreibt den Weg von dort bis in das Notebook.
| Kennzahl | City Hotel | Resort Hotel | beide Hotels |
|---|---|---|---|
| Buchungen | 79.330 | 40.060 | 119.390 |
| Stornoquote | 41,7 % | 27,8 % | 37,0 % |
| Ø Zimmerpreis (ADR) | 105,30 € | 94,95 € | 101,83 € |
| Ø Aufenthalt | 2,98 Nächte | 4,32 Nächte | 3,43 Nächte |
| Stornobereinigter Umsatz | 14,4 Mio. € | 11,6 Mio. € | 26,0 Mio. € |
Aus diesen Zahlen ergeben sich die vier Fragen, die das Projekt durchziehen. Jede spätere Auswertung – im Notebook, in Power BI, im Dashboard – lässt sich einer davon zuordnen.
Welche Buchungen werden storniert – und lässt sich das vorher erkennen? Vorlaufzeit, Kautionstyp, Marktsegment und Herkunftsland sind die Verdächtigen. Dahinter steht Geld: Jede stornierte Buchung ist gebuchter Umsatz, der nicht ankommt.
Wie verteilen sich Buchungen, Umsatz und Stornierungen über die Monate? Wer die Saisonkurve kennt, plant Personal, Preise und Überbuchung nicht nach Gefühl.
Über welche Kanäle und Segmente kommen die Buchungen – und welche bringen Umsatz statt nur Buchungen? Online-Reisebüros liefern die Menge, Direktbuchungen sparen Provision.
Aus welchen Ländern kommen die Gäste, und verhalten sich Inlandsgäste anders als ausländische? Portugiesische Gäste stornieren deutlich häufiger – ein Befund, der Stornoregeln nach Markt nahelegt.
Was Business Intelligence beiträgt
Business Intelligence (BI) heißt: aus den Daten des laufenden Betriebs Kennzahlen zu machen, die Entscheidungen tragen. Zuerst ist das eine Frage der Definition. „Umsatz“ ist erst dann eine Kennzahl, wenn feststeht, ob stornierte Buchungen mitzählen (im Projekt: nein, das ist der stornobereinigte Umsatz), ob Frühstück und Parkplatz dazugehören (nein, nur die Übernachtung) und auf welchen Zeitraum sich die Zahl bezieht (Anreisemonat, nicht Buchungsmonat).
Drei Ebenen, die man auseinanderhalten muss
- Operative Daten – das Buchungssystem des Hotels. Eine Zeile je Buchung, für den Betrieb gemacht, nicht für die Auswertung. Hier: die Rohdatei mit 32 Spalten.
- Auswertungsmodell – die Daten so umgebaut, dass Fragen wie „Umsatz je Monat und Segment“
in einer Abfrage beantwortbar sind. Hier: das Sternschema
hotel_biin PostgreSQL. - Berichte – Kennzahlen und Diagramme für Menschen, die entscheiden. Hier: der Bericht in Power BI und das Dashboard im Browser.
Jede Ebene hat ein eigenes Lab. Wer weiß, auf welcher Ebene er sich gerade bewegt, versteht, warum dieselbe Zahl an drei Orten stehen muss – und warum sie dort identisch sein muss.
Das Vorgehen in sechs Schritten
Das Projekt folgt dem Ablauf, der sich in der Praxis für Datenprojekte durchgesetzt hat und den das Vorgehensmodell CRISP-DM seit den 1990er-Jahren beschreibt: erst die Frage, dann die Daten verstehen, dann aufbereiten, dann auswerten, dann bereitstellen. Jeder Schritt beantwortet eine Frage, ohne die der nächste nicht sinnvoll ist.
| Schritt | Frage, die er beantwortet | Ergebnis | Lab |
|---|---|---|---|
| 1 Fragen klären | Welche Entscheidungen sollen die Zahlen tragen? | die vier Fragestellungen | 00 |
| 2 Daten verstehen | Was steht in jeder Spalte, und was fehlt? | Spaltenbeschreibung, Liste der Eigenheiten | 01, 03 |
| 3 Bereinigen | Womit kann man rechnen, womit nicht? | gefüllte Lücken, abgeleitete Merkmale wie revenue | 03 |
| 4 Kennzahlen | Wie ist jede Kennzahl genau definiert? | Katalog mit zehn Kennzahlen | 06 |
| 5 Modellieren | Wie müssen die Daten liegen, damit jede Frage eine Abfrage ist? | Sternschema, Datenbank hotel | 04, 05 |
| 6 Berichten | Wie sieht die Antwort aus, und was folgt daraus? | Power-BI-Bericht, Dashboard, Handlungsempfehlungen | 07, 08, 09 |
Die Reihenfolge ist wichtiger, als sie aussieht. Wer mit Schritt 6 anfängt – „erst mal ein Dashboard bauen“ –,
merkt in Schritt 4, dass Umsatz noch nicht definiert ist, und in Schritt 2, dass adr negative
Werte enthält. Dann werden Diagramme umgebaut, die schon jemand gesehen hat.
Was am Ende vorliegt
Das Projekt hinterlässt vier Artefakte, die dieselben Zahlen zeigen: 119.390 Buchungen, 37,0 % Stornoquote, 26,0 Mio. € stornobereinigter Umsatz.
BI_Hotel_Booking_Demand.ipynb in Google Colab: lädt die Rohdaten, bereinigt sie, rechnet die
Kennzahlen, zeichnet vier Auswertungen und baut das Sternschema, das es als neun CSV-Dateien exportiert.
Abschnitt 7.1 liest zur Probe aus der fertigen Datenbank.
PostgreSQL auf einem Server der Hochschule, Datenbank hotel, Schema hotel_bi:
eine Faktentabelle mit 119.390 Buchungen und acht Dimensionen. Studierende lesen mit der Rolle
studi_hotel; verändern kann sie nichts.
Ein Modell mit neun Beziehungen, 13 Measures in DAX und vier Berichtsseiten: Management-Übersicht,
Saisonalität und Herkunft, Vertrieb und Kundensegmente, Stornoanalyse. Liegt als Hotel.pbix
und als Projekt Hotel.pbip im Repository.
Eine Webanwendung aus Python (FastAPI) und JavaScript (Observable Plot), die bei jedem Filterwechsel live aus der Datenbank liest. Läuft als Container auf Render und ist öffentlich erreichbar.
Alles außer der Datenbank liegt im öffentlichen Repository swrobuts/hotel; die Datenbank ist von dort aus in vier Befehlen neu aufbaubar. Das ist Absicht: Ein BI-Projekt, das sich nicht reproduzieren lässt, ist eine Zahl ohne Beleg.
Die Werkzeuge
Jeder Schritt hat ein Werkzeug, und jedes Werkzeug hat Alternativen. Die Wahl im Projekt folgt einem Kriterium: ohne Kosten und ohne Installation ausprobierbar – oder für Studierende der Hochschule kostenfrei.
| Schritt | Werkzeug im Projekt | Alternativen auf derselben Ebene | Lizenz, Stand 09/2026 |
|---|---|---|---|
| Daten laden, bereinigen, rechnen | Google Colab mit pandas | Jupyter lokal, Deepnote, Kaggle Notebooks | Colab: kostenfrei mit Google-Konto |
| Speichern und modellieren | PostgreSQL (Supabase, selbst gehostet) | Supabase Cloud, Neon, SQLite als Datei | PostgreSQL: Open Source |
| Abfragen und prüfen | psql, DBeaver | DataGrip, pgAdmin | DBeaver Community: Open Source |
| Berichten | Power BI Desktop | Tableau, Apache Superset, Metabase | Power BI Desktop: kostenfrei; Veröffentlichen braucht ein Konto |
| Dashboard programmieren | FastAPI, Observable Plot, D3 | Streamlit, Dash, Shiny | Open Source |
| Bereitstellen | Render (Docker, Free-Plan) | Fly.io, Railway, eigener Server | Render Free: schläft nach 15 Minuten Ruhe ein |
Hinweis. Bei den in dieser Lernumgebung gezeigten Tools handelt es sich um eine Auswahl – diese ist weder als Empfehlung noch als Werbung zu verstehen. Alles, was in den Labs an Handgriffen gezeigt wird, gilt sinngemäß auch für die genannten Alternativen; die Begriffe heißen dort nur anders.
Was die Daten nicht können
Drei Fragen beantwortet der Datensatz nicht; alle drei stehen im Notebook, im Power-BI-Bericht und in der Fußzeile des Dashboards dabei.
Keine Kapazität. Der Datensatz enthält keine Zimmerzahl. Deshalb lassen sich weder eine Auslastung noch ein RevPAR (Umsatz je verfügbarem Zimmer) berechnen – zwei Kennzahlen, die in jedem echten Hotelbericht ganz oben stehen. Das Projekt weicht auf gebuchte Zimmernächte aus und sagt das dazu.
Nur Übernachtung. Die Spalte adr ist der Zimmerpreis je Nacht. Frühstück,
Parkplatz, Restaurant und Spa fehlen. „Umsatz“ heißt im Projekt deshalb immer Logisumsatz – Zimmerpreis mal
Nächte – und nichts anderes.
Zwei Häuser, zwei Jahre. Nur 2016 ist ein vollständiges Kalenderjahr; 2015 beginnt im Juli, 2017 endet im August. Jahresvergleiche brauchen deshalb den Vorjahresmonat, nicht das Vorjahr. Und was für diese beiden Hotels gilt, gilt nicht automatisch für die Branche.
Übungen
Vier Übungen: eine zu den Fragestellungen, eine Zuordnung von Auswertungen zu Fragen, die Reihenfolge des Vorgehens und eine Verständnisfrage zu den Grenzen der Daten.
Zusammenfassung
- Zwei Hotels, 119.390 Buchungen, 37,0 % storniert: Das Projekt beantwortet vier Fragen – Stornorisiko, Saisonalität, Vertrieb, Herkunft.
- Business Intelligence beginnt mit Definitionen, nicht mit Diagrammen. Umsatz ist im Projekt der stornobereinigte Logisumsatz je Anreisemonat.
- Sechs Schritte in fester Reihenfolge: Fragen, Daten verstehen, Bereinigen, Kennzahlen, Modellieren, Berichten.
- Vier Artefakte gehören zusammen und zeigen dieselben Zahlen: Notebook, Datenbank, Power-BI-Bericht, Dashboard.
- Jedes Werkzeug hat Alternativen; die Handgriffe übertragen sich.
- Die Daten kennen keine Kapazität und keinen Nebenumsatz – Auslastung und RevPAR bleiben offen, und das gehört gesagt.