Tabellendaten prüfen
Kontrollieren Sie einen integrierten Tabellenbestand zuerst direkt in HYPERSENSUS. Wechseln Sie nur für eine ausdrücklich erlaubte, weitergehende Leseabfrage zu pgAdmin.
Diese Anleitung passt, wenn ein Datenfluss eine Tabelle oder View in der für HYPERSENSUS konfigurierten Mandanten-Datenbank aktualisieren sollte. Geprüft wird das konkrete Ergebnis dieses Laufs: Ist der erwartete Datensatz vorhanden, besitzt er den richtigen fachlichen Zeitpunkt und wurden die vorgesehenen Felder plausibel übernommen? Andere PostgreSQL-Datenbanken erscheinen dort nicht automatisch.
Zieltabelle bestimmen
Schema, Tabelle oder View und den erwarteten Datensatz aus dem Datenfluss übernehmen.
Bestand öffnen
Den freigegebenen Tabellenbestand über Suche und Datenansicht öffnen.
Datensatz vergleichen
Kennung, Zeitstempel und gemappte Fachwerte mit der Testeingabe abgleichen.
Optional SQL verwenden
Nur mit erlaubtem Lesezugang eine begrenzte Abfrage in pgAdmin ausführen.
Vor der Prüfung
Tabelle oder View bekannt
Schema und Objektname stammen aus der Konfiguration oder Übergabe des geprüften Datenflusses.
Testdatensatz erkennbar
Eine stabile Objekt-, Stations- oder Quellkennung macht genau den eingespeisten Datensatz auffindbar.
Fachzeit bekannt
Der erwartete Mess- oder Gültigkeitszeitpunkt kann vom technischen Eingangszeitpunkt unterschieden werden.
Zielfelder bekannt
Für die Prüfung ist bekannt, welche Quellwerte in welchen Tabellenspalten ankommen sollen.
Tabelle in HYPERSENSUS prüfen
- Öffnen Sie in HYPERSENSUS Daten → Datenbanken.
- Suchen Sie nach dem erwarteten Schema oder Tabellennamen und öffnen Sie den vereinbarten Bestand.
- Suchen Sie nach der eindeutigen Kennung des Testdatensatzes.
- Vergleichen Sie in den angezeigten Zeilen die fachliche Zeit mit dem erwarteten Testzeitpunkt.
- Prüfen Sie den passenden Datensatz gegen die Eingabe des Datenflusses: Kennung, Zeitpunkt, Wert, Einheit und Herkunft.
Die Sortierung in HYPERSENSUS ordnet die aktuell geladenen Zeilen und weist nicht zuverlässig den global neuesten Datensatz eines großen Bestands nach. Reicht die Suche nach Kennung und bekanntem Zeitpunkt nicht aus, verwenden Sie mit einem ausdrücklich freigegebenen Lesezugang eine begrenzte SQL-Abfrage in pgAdmin.
Beispiel: verarbeitete Verkehrszählung prüfen
Das PostgreSQL-Ziel aus Daten speichern schreibt nach public.traffic_counts_curated. Liegt diese Tabelle in der für HYPERSENSUS konfigurierten Mandanten-Datenbank, suchen Sie dort nach traffic_counts_curated und vergleichen den Testdatensatz:
| Spalte | Erwarteter Wert |
|---|---|
counting_station_id | zaehlstelle-017 |
observed_at | 2026-08-19T08:00:00Z |
vehicle_count | 126 |
Ist die Zieldatenbank nicht an HYPERSENSUS angebunden, verwenden Sie den ausdrücklich dafür freigegebenen lesenden SQL-Zugang. Das Ergebnis muss unabhängig vom Werkzeug dieselbe Zeile nachweisen.
Weiteres Beispiel: Pegelstände prüfen
Bei der Referenzimplementierung Pegelstände suchen Sie nach dem Schema mtds_environment und der Tabelle etwaterobserved. Für einen bekannten Messwert sind insbesondere diese Spalten relevant:
| Spalte | Konkrete Prüfung |
|---|---|
entity_id | Gehört der Datensatz zur erwarteten Messstelle? |
dateobserved | Entspricht der fachliche Messzeitpunkt der Quelle? |
waterlevel | Wurde der Pegelwert vollständig und als Zahl übernommen? |
source | Ist die tatsächliche Datenquelle nachvollziehbar? |
Eine Tabelle kann erreichbar sein und trotzdem nur alte Daten enthalten. Vergleichen Sie deshalb immer einen konkreten Testdatensatz und dessen fachlichen Zeitpunkt. Erst dieser Vergleich weist nach, dass der geprüfte Datenlauf sein Ziel aktualisiert hat.
Nur bei Bedarf lesend in pgAdmin prüfen
HYPERSENSUS reicht für die Prüfung einzelner Datensätze und sichtbarer Spalten in der angebundenen Mandanten-Datenbank meist aus. Verwenden Sie pgAdmin nur, wenn Ihnen für diese Fachdatenbank ausdrücklich ein lesender Zugang bereitgestellt wurde und eine begrenzte SQL-Abfrage einen konkreten zusätzlichen Nachweis liefert – etwa mehrere Messstellen, Nullwerte oder den jüngsten Lieferstand gemeinsam zu vergleichen.
Ist das freigegebene Verbindungsprofil noch nicht im persönlichen pgAdmin-Konto hinterlegt, folgen Sie der Anleitung Datenbank in pgAdmin registrieren. Die Anmeldung an pgAdmin gewährt für sich genommen noch keine Datenbankrechte.
Für die Verkehrszählung weist diese Abfrage genau den verarbeiteten Testdatensatz nach:
SELECT
counting_station_id,
observed_at,
vehicle_count
FROM public.traffic_counts_curated
WHERE counting_station_id = 'zaehlstelle-017'
AND observed_at = TIMESTAMPTZ '2026-08-19T08:00:00Z';
Die Abfrage muss genau eine Zeile mit vehicle_count = 126 liefern. Keine Zeile bedeutet, dass der getestete Lauf dieses Ziel nicht geschrieben hat; mehrere Zeilen weisen auf einen fehlenden oder ungeeigneten Eindeutigkeitsschlüssel hin.
Für den Pegelbestand zeigt diese Abfrage die 20 jüngsten gespeicherten Messwerte:
SELECT
entity_id,
dateobserved,
waterlevel::double precision AS waterlevel,
source
FROM mtds_environment.etwaterobserved
WHERE dateobserved IS NOT NULL
ORDER BY dateobserved DESC
LIMIT 20;
Vergleichen Sie die passende Zeile mit der Testeingabe. Der Cast auf double precision macht zugleich sichtbar, ob waterlevel als numerischer Wert auswertbar ist. Verändern Sie die Abfrage für andere Bestände nur anhand der dokumentierten Schema-, Tabellen- und Spaltennamen.
Direkte Tabellenzugriffe auf interne Datenbanken von Stellio, FROST, CKAN, Keycloak oder anderen Komponenten gehören nicht zu diesem Arbeitsweg. Prüfen Sie deren Daten über die jeweilige Fach-API. Führen Sie in pgAdmin keine Schreib-, Schema- oder Rechteänderungen aus.