Wo die Datenbank läuft

Die Datenbank hotel liegt auf einer selbst gehosteten Supabase-Instanz: Supabase bündelt PostgreSQL mit Verwaltungswerkzeugen und läuft hier als Container auf einem Server der Hochschule (PostgreSQL 17.6). Für dieses Projekt zählt nur der Datenbankteil – die Verbindung geht direkt an PostgreSQL, Port 5433, ohne die REST-Schnittstelle, die Supabase sonst anbietet.

AngabeWertWas es ist
Hostsupabase.butscher.cloudder Server, öffentlich erreichbar
Port5433nicht der PostgreSQL-Standard 5432 – der ist auf dem Server anders belegt
Datenbankhoteleine eigene Datenbank nur für dieses Projekt
Schemahotel_bider Namensraum mit den neun Tabellen
Benutzerstudi_hoteldie Leserolle für Studierende
Kennwortthwsbewusst öffentlich, siehe Abschnitt Sicherheit
SSLausdie Instanz hat kein Zertifikat für den Datenbankport

Drei Schichten, die man auseinanderhalten muss

  • Server – die Maschine mit Docker darauf. Betreibt mehrere Fallstudien.
  • Datenbank – hotel ist eine von mehreren Datenbanken in derselben PostgreSQL-Instanz. Die Rolle darf nur diese eine öffnen.
  • Schema – hotel_bi ist der Ordner innerhalb der Datenbank, in dem die Tabellen liegen. Der Suchpfad der Rolle zeigt darauf; deshalb genügt fact_bookings statt hotel_bi.fact_bookings.

Die Rolle studi_hotel

In PostgreSQL ist ein Benutzer eine Rolle mit Anmelderecht. Rechte werden je Datenbank, Schema und Tabelle vergeben; was nicht ausdrücklich erlaubt ist, ist verboten. Die Rolle studi_hotel hat genau vier Rechte und vier Einstellungen – sie stehen in sql/03_rolle_studi_hotel.sql.

DarfDarf nicht
sich an hotel anmelden (CONNECT)eine andere Datenbank der Instanz öffnen
alle Tabellen in hotel_bi lesen (SELECT)Zeilen einfügen, ändern, löschen
Abfragen bis zehn Minuten LaufzeitTabellen, Sichten oder Indizes anlegen
Ergebnisse auf den eigenen Rechner ziehen (\copy)Dateien auf dem Server schreiben (COPY … TO '/pfad')

Schreibversuche scheitern doppelt: Erst sagt default_transaction_read_only, dass die Sitzung nur liest; wer das in seiner Sitzung abschaltet, scheitert an den fehlenden Rechten. Zwei Schlösser, ein Schlüssel fehlt. So kann niemand die Daten für alle anderen verändern – auch nicht aus Versehen.

Verbinden – vier Wege

Alle Werkzeuge brauchen dieselben sechs Angaben, nur die Form unterscheidet sich: eine Kommandozeile, eine Verbindungs-URL, ein Formular. Wer eine Form kennt, kann alle.

DBeaver – Connect to a databaseCommunity 25
Main
Driver properties
SSH
SSL
Connect by● Host   ○ URL
Hostsupabase.butscher.cloud 1
Port5433 2
Databasehotel
AuthenticationDatabase Native
Usernamestudi_hotel
Password•••• 3
Test Connection … Finish 4
Connected · PostgreSQL 17.6 · Driver PostgreSQL JDBC

Nachbildung der Oberfläche, Stand 09/2026 – Beschriftungen wie im Original.

  1. 1Host ohne https:// und ohne Port – nur der Name.
  2. 2Der Port 5433. DBeaver trägt 5432 vor; wer das übersieht, bekommt „Connection refused“.
  3. 3Das Kennwort thws. „Save password“ ist hier unbedenklich – die Rolle kann nichts verändern.
  4. 4Test Connection zuerst. Beim ersten Mal lädt DBeaver den PostgreSQL-Treiber nach – das ist normal und dauert einige Sekunden.

Der vierte Weg – Power BI Desktop – bekommt in Lab 07 einen eigenen Abschnitt; die Angaben sind dieselben, dazu kommt die Wahl Import und die Bestätigung, dass unverschlüsselt verbunden wird.

Fehlermeldungen lesen

PostgreSQL sagt genau, was fehlt – wenn man die Meldung liest, statt sie wegzuklicken. Die sechs häufigsten im Kurs, wörtlich:

MeldungUrsacheAbhilfe
connection to server at "supabase.butscher.cloud", port 5432 failed: Connection refusedfalscher Port – 5432 statt 5433Port auf 5433 setzen
FATAL: password authentication failed for user "studi_hotel"Kennwort oder Benutzername falsch geschriebenstudi_hotel / thws, keine Leerzeichen
FATAL: permission denied for database "postgres"eine andere Datenbank gewählt als hotelDatenbank auf hotel setzen
ERROR: relation "fact_bookings" does not existSuchpfad zeigt nicht auf hotel_bi (anderes Werkzeug, anderer Benutzer)hotel_bi.fact_bookings schreiben oder SET search_path TO hotel_bi
ERROR: cannot execute INSERT in a read-only transactionSchreibversuch mit der Leserollekeine – das ist Absicht; eigene Tabellen gehören in eine eigene Datenbank
ERROR: canceling statement due to statement timeoutAbfrage lief länger als zehn MinutenAbfrage eingrenzen (WHERE, LIMIT) oder mit Aggregation statt Einzelzeilen

Power BI und Tableau zeigen bei SSL-Zwang eine eigene Meldung: „The server does not support SSL“ oder ähnlich. Ursache ist das Häkchen Verbindung verschlüsseln bzw. SSL erforderlich – abwählen, dann fragt Power BI, ob es unverschlüsselt verbinden soll: ja.

Daten herunterladen

Das Leserecht genügt, um jede Tabelle vollständig auf den eigenen Rechner zu holen; die Faktentabelle mit 119.390 Zeilen dauert wenige Sekunden. Der Unterschied, den man kennen muss: \copy (mit Backslash) läuft in psql auf dem eigenen Rechner und schreibt die Datei dort – COPY … TO '/pfad' (ohne Backslash) würde auf dem Server schreiben und ist der Rolle verwehrt.

WerkzeugVorgehen
psql\copy (SELECT * FROM fact_bookings) TO 'fact_bookings.csv' CSV HEADER
DBeaverRechtsklick auf die Tabelle → Export Data → CSV oder Excel
Pythonpd.read_sql("SELECT * FROM fact_bookings", engine).to_csv("fact_bookings.csv", index=False)
Power BI, Tableauder Import-Modus holt ohnehin alle Zeilen in die eigene Datei
ohne Datenbankdieselben neun CSV-Dateien liegen im Repository unter data/

Sicherheit: was hier gilt und was nicht

Ein Kennwort im Repository, eine unverschlüsselte Verbindung, ein öffentlich erreichbarer Port – jedes davon wäre in einem Unternehmen ein Vorfall. Hier ist es vertretbar, und der Grund ist die Kombination aus drei Umständen. Fehlt einer, gilt die Abwägung nicht mehr.

Die Daten sind öffentlich

Der Datensatz liegt unter CC BY 4.0 auf Kaggle und GitHub. Wer die Datenbank liest, erfährt nichts, was er nicht auch ohne sie erfahren könnte. Personenbezug gibt es nicht.

Die Rolle kann nichts verändern

Nur lesen, nur diese Datenbank, nur zehn Minuten je Abfrage. Wer das Kennwort kennt, kann Zahlen nachschlagen – sonst nichts. Das Betreiberkonto mit Schreibrecht hat ein anderes Kennwort, das nirgends steht.

Das Kennwort gilt nur hier

Unverschlüsselt heißt: Das Kennwort geht im Klartext durchs Netz. Deshalb ist es eines, das nirgendwo sonst gilt. Die Regel für alles andere: Ein Kennwort, das man auch anderswo verwendet, geht nie über eine unverschlüsselte Verbindung – und nie in ein Repository.

Übertragbar ist die Methode, nicht die Entscheidung. Für Daten aus einem Praxisprojekt heißt dieselbe Methode: Kennwort ins Secrets-Panel oder in eine .env-Datei, SSL an, Rolle mit Ablaufdatum, Zugang nur für Beteiligte. Das Projekt zeigt in .env.example, wie die Betreiberverbindung aussieht – ohne Kennwort.

Abfragen im Browser

Dieselbe Datenbank, dieselben Tabellen, derselbe Suchpfad – nur läuft PostgreSQL hier in Ihrem Browser. Was hier funktioniert, funktioniert genauso in psql, DBeaver oder Python gegen den Server. Nur eines ist anders: Hier dürfen Sie schreiben, weil es nur Ihre Kopie trifft; auf dem Server kommt die Meldung aus der Tabelle oben.

Übungen

Fünf Übungen: eine Checkliste für die echte Verbindung mit DBeaver oder psql, Verständnisfragen zu Rechten und Sicherheit, eine Zuordnung von Fehlermeldungen zu Ursachen und zwei Abfragen – eine an den Katalog der Datenbank, eine als Kontrollrechnung aus dem Notebook.

Zusammenfassung