Zum Hauptinhalt springen
Administration · Datenbanken

Datenbank-View bereitstellen

Eine View übersetzt einen vorhandenen Datenbestand in ein stabiles, zweckgebundenes Lesemodell. Diese Anleitung zeigt die Erstellung im pgAdmin Query Tool, die Rechtevergabe und die Übergabe an Grafana, Superset oder GeoServer.

Eine Anwendung greift nicht direkt auf eine operative Ursprungstabelle zu, sondern auf eine verständlich benannte View mit den benötigten Spalten und Zeilen. Die vorgesehene Datenbankrolle darf die View lesen, erhält dadurch aber keine pauschalen Rechte auf das zugrunde liegende Schema.

Zweck

Ausgabe festlegen

Zielanwendung, benötigte Felder, Filter und verantwortliche Stelle sind geklärt.

SQL

View anlegen

Eine nachvollziehbare SELECT-Abfrage wird im pgAdmin Query Tool als View gespeichert.

Rechte

Leserolle freigeben

Nur die vorgesehene Anwendungsrolle erhält USAGE am Schema und SELECT auf der View.

Abnahme

In Anwendung prüfen

Ergebnis, Berechtigung und fachliche Bedeutung werden aus Sicht der Zielanwendung getestet.

Wann eine View der richtige Weg ist​

Dashboards

Grafana

Zeit, Kennzahl, Kategorie und Einheit werden in einer stabilen Struktur für Dashboard-Abfragen bereitgestellt.

Grafana vorbereiten
Analysen

Superset

Die View bildet ein verständliches Dataset und verbirgt technische Hilfsspalten oder nicht freigegebene Inhalte.

Superset vorbereiten
Geodienste

GeoServer

Eine View kann Attribute filtern, Tabellen verbinden und eine klar definierte Geometrie als Layerquelle bereitstellen.

WFS-Layer freigeben
Integrationen

Weitere Leser

Auch Exporte oder Integrationsflows erhalten so ein dokumentiertes Datenmodell anstelle eines direkten Tabellenzugriffs.

Eine normale View speichert keine Kopie der Daten. PostgreSQL führt ihre zugrunde liegende Abfrage bei jeder Verwendung erneut aus. Für vorberechnete, bewusst aktualisierte Ergebnisse wäre stattdessen eine materialisierte View zu planen.

Voraussetzungen​

  • eine in pgAdmin registrierte PostgreSQL-Datenbank,
  • ein freigegebenes Zielschema, beispielsweise reporting,
  • eine Datenbankrolle, die dort eine View anlegen darf,
  • die vorgesehene Leserolle der Zielanwendung und
  • eine fachlich geprüfte SELECT-Abfrage.
Keine Views in Komponentendatenbanken anlegen

Datenbanken von Stellio, FROST, CKAN, Keycloak und anderen Plattformdiensten werden durch die jeweilige Anwendung geführt. Eigene Views gehören in einen freigegebenen Fachdatenbestand oder ein ausdrücklich dafür vorgesehenes Schema. Änderungen an internen Komponentenschemata können Updates und Datenmigrationen beeinträchtigen.

1. Ausgabe zuerst als Abfrage prüfen​

  1. Wählen Sie in pgAdmin die richtige Datenbank aus.
  2. Öffnen Sie über Tools → Query Tool den SQL-Editor.
  3. Entwickeln und prüfen Sie zunächst nur die SELECT-Abfrage.
  4. Begrenzen Sie den ersten Test mit LIMIT und kontrollieren Sie Spaltennamen, Datentypen, Einheiten, Zeitbezug und Filterwirkung.

Ein mögliches Lesemodell für ein Dashboard sieht beispielsweise so aus:

SELECT
    measured_at AS time,
    station_id,
    pollutant,
    measured_value AS value,
    unit
FROM fachdata.air_quality_measurements
WHERE quality_status = 'validated'
ORDER BY measured_at;

Verwenden Sie in einer dauerhaft bereitgestellten View kein SELECT *. Eine explizite Spaltenliste verhindert, dass später ergänzte oder vertrauliche Spalten unbeabsichtigt in Anwendungen erscheinen.

2. View im vorgesehenen Schema anlegen​

Entfernen Sie nach der fachlichen Prüfung das vorübergehende LIMIT und speichern Sie die Abfrage als View:

CREATE VIEW reporting.v_air_quality_dashboard AS
SELECT
    measured_at AS time,
    station_id,
    pollutant,
    measured_value AS value,
    unit
FROM fachdata.air_quality_measurements
WHERE quality_status = 'validated';

COMMENT ON VIEW reporting.v_air_quality_dashboard IS
    'Validierte Luftqualitaetsmessungen fuer fachliche Dashboards';

Führen Sie das Skript über Execute script aus und prüfen Sie die Rückmeldung unter Messages. Aktualisieren Sie anschließend den pgAdmin-Browser. Die View erscheint unter Schemas → reporting → Views.

View-Definitionen gehören in die Änderungsdokumentation

Das Query Tool speichert ein ausgeführtes Skript nicht als versionierte Plattformkonfiguration. Legen Sie die freigegebene SQL-Definition deshalb zusätzlich im vereinbarten Git-Repository oder Datenbank-Migrationsprozess ab. So lassen sich Änderung, Review und Wiederherstellung nachvollziehen.

3. Leserechte gezielt vergeben​

Die Leserolle benötigt Zugriff auf das Zielschema und die View. Sie benötigt im üblichen View-Modell keinen direkten Lesezugriff auf die Ursprungstabelle:

REVOKE ALL ON reporting.v_air_quality_dashboard FROM PUBLIC;

GRANT USAGE ON SCHEMA reporting TO grafana_reader;
GRANT SELECT ON reporting.v_air_quality_dashboard TO grafana_reader;

Ersetzen Sie grafana_reader durch die tatsächlich bereitgestellte Datenbankrolle. Erzeugen Sie in dieser Anleitung keine neue Login-Rolle und hinterlegen Sie keine Passwörter im SQL-Skript. Rollen und Zugangsdaten werden über den abgestimmten Bereitstellungs- und Secret-Prozess verwaltet.

Die View-Eigentümerschaft ist sicherheitsrelevant

PostgreSQL prüft den Zugriff auf die zugrunde liegenden Tabellen bei einer normalen View standardmäßig mit den Rechten des View-Eigentümers. Genau dadurch kann eine Leserolle nur die freigegebene View sehen. Der Eigentümer muss daher eine kontrollierte technische Rolle sein, und die View darf ausschließlich die freigegebenen Spalten und Zeilen liefern. Zeilenbezogene Sicherheitsmodelle oder security_invoker-Views müssen separat mit dem Datenbankbetrieb entworfen und getestet werden.

4. Daten und Sperrwirkung abnehmen​

Prüfen Sie die View zunächst mit einer begrenzten Abfrage:

SELECT *
FROM reporting.v_air_quality_dashboard
ORDER BY time DESC
LIMIT 20;

Die eigentliche Abnahme erfolgt anschließend mit der Leserolle der Zielanwendung:

  • Die View lässt sich lesen.
  • Nicht freigegebene Spalten und Zeilen sind nicht enthalten.
  • Ein direkter Zugriff auf die Ursprungstabelle bleibt gesperrt.
  • Schreiboperationen auf der View sind nicht freigegeben.
  • Abfragezeit und Datenmenge sind für die vorgesehene Nutzung vertretbar.

Testen Sie zum Abschluss die echte Verbindung aus Grafana, Superset oder GeoServer. Ein erfolgreicher Test mit der administrativen Eigentümerrolle beweist nicht, dass die Anwendungsrolle korrekt eingerichtet ist.

5. View an die Anwendung übergeben​

  • Grafana: Verwenden Sie in Panels den vollständig qualifizierten Namen reporting.v_air_quality_dashboard. Die Datenquelle muss sich mit der freigegebenen Leserolle verbinden.
  • Superset: Registrieren Sie die View als Dataset und prüfen Sie anschließend Datentypen, Zeitspalten und Dataset-Rechte.
  • GeoServer: Wählen Sie die View im bestehenden PostGIS-Store aus und veröffentlichen Sie sie als Layer. Für WFS werden zusätzlich eine eindeutige Zeilenkennung, eine Geometriespalte und ein korrektes CRS benötigt.

Dokumentieren Sie Viewname, Zweck, Eigentümer, Leserolle, Quelldaten, Filter, abhängige Anwendungen und den Ablageort der SQL-Definition.

Änderungen kontrolliert durchführen​

Verwenden Sie CREATE OR REPLACE VIEW nur nach Prüfung der abhängigen Anwendungen. PostgreSQL erlaubt dabei nicht jede beliebige Änderung an Namen, Reihenfolge und Typen bestehender Spalten. Bei inkompatiblen Änderungen sind eine neue View-Version und eine abgestimmte Migration meist sicherer, beispielsweise von v_air_quality_dashboard_v1 auf v_air_quality_dashboard_v2.

Referenzen​