Datenräume sinnvoll aufbauen
Ein Datenraum trennt fachlich zusammengehörige Daten und ihre Zugriffe innerhalb eines Mandanten. Der Zuschnitt sollte nicht aus der eingesetzten Technik entstehen, sondern aus gemeinsamer Nutzung, Schutzbedarf und Lebenszyklus der Daten.
Die UDSP bildet Datenräume technisch unter anderem über Stellio-Tenants, Datenraumzuordnungen und geschützte API-Zugriffe ab. Diese Seite beantwortet die praktische Frage davor: Welche Daten gehören zusammen und wann ist eine eigene Grenze sinnvoll?
Das Datenraumkonzept trennt Daten in fachlich und technisch abgegrenzte Bereiche. Ein Datenraum lässt sich wie ein Container verstehen, der für definierte Daten vorgesehen ist und eigene Ressourcen sowie Zugriffsrechte besitzt. Dadurch lassen sich Daten thematisch bündeln und Benutzer oder technische Zugänge gezielt auf einzelne Datenräume berechtigen.
Datenräume können grundsätzlich unterschiedlich zugeschnitten werden. Da ein integrierter Datenbestand genau einem maßgeblichen Datenraum zugeordnet wird und Zugriffe auf dieser Ebene begrenzt werden, benötigt der Zuschnitt jedoch eine nachvollziehbare fachliche Begründung.
Die Begriffe zuerst trennen
Mandant
Trennt eine Organisation oder einen größeren Betriebsbereich von anderen Mandanten der Plattform.
Datenraum
Bündelt Datenbestände mit gemeinsamem fachlichem Kontext und einer gemeinsamen Zugriffsgrenze innerhalb eines Mandanten.
Datenbestand
Eine konkrete Tabelle, Entity-Menge, Zeitreihe, Dateiablage oder andere technisch gespeicherte Datensammlung.
Datenprodukt
Ein verständlich beschriebener, nachvollziehbar erzeugter und für eine bestimmte Nutzung bereitgestellter Datenbestand.
Ein Mandant kann mehrere Datenräume enthalten. Ein Datenraum kann wiederum mehrere Datenbestände und Datenprodukte aufnehmen. Ein Datenraum ist damit weder ein einzelner Datensatz noch automatisch ein eigenes Projekt.
Warum Datenräume verwendet werden
- fachlich unterschiedliche Nutzungskontexte bleiben voneinander getrennt,
- Basisdaten können kontrolliert in weiteren Datenprodukten wiederverwendet werden,
- Zuständigkeit, Freigabe und Änderung lassen sich einem klar beschriebenen Bereich zuordnen,
- APIs, Metadaten und Berechtigungen erhalten eine gemeinsame fachliche Grenze und
- die Trennung innerhalb eines Mandanten wird technisch nachvollziehbar abgebildet.
Ordnen Sie einen integrierten Datenbestand genau einem maßgeblichen Datenraum zu. Wird sein Inhalt in einem anderen Kontext benötigt, entsteht dort ein nachvollziehbar abgeleitetes Datenprodukt. Vermeiden Sie unkontrollierte Kopien, bei denen Herkunft und Aktualisierung nicht mehr erkennbar sind.
Zwei bewährte Zuschnitte
Quellnaher Datenraum
Ein quellnaher Datenraum bündelt standardisierte Basisdaten, die noch eng mit ihrer Herkunft verbunden sind. Die Rohdaten werden bereinigt und vereinheitlicht, erhalten mindestens eine stabile, eindeutige ID und werden – soweit für den Zielweg vorgesehen – auf ein vereinbartes Datenmodell abgebildet. Sie sind damit wiederverwendbar, aber noch nicht auf eine einzelne Anwendung zugeschnitten.
Innerhalb eines quellnahen Datenraums können weitere Basis-Datensätze abgeleitet werden, beispielsweise eine nachvollziehbar definierte zeitliche Aggregation derselben Quelle. Herkunft und Transformation müssen dabei sichtbar bleiben.
Beispiele:
- standardisierte Daten mehrerer Parkplatzsensoren,
- übernommene Informationen einer öffentlichen Mobilitäts-API,
- harmonisierte Pegel- oder Wetterbeobachtungen.
Dieser Zuschnitt eignet sich, wenn dieselben Basisdaten in mehreren Vorhaben wiederverwendet werden sollen oder wenn für die Quelle ein eigener Zugriffs- und Lebenszyklus gilt.
Domänen-, Anwendungs- oder Use-Case-naher Datenraum
Ein fachnaher Datenraum bündelt Daten für einen gemeinsamen Nutzungskontext. Darin liegen vor allem angereicherte oder aggregierte Datenprodukte, deren Grundlagen aus mehreren quellnahen Datenräumen stammen können.
Beispiele:
- Parkraummanagement mit Sensorbelegung, Kontrollzonen und verdichteten Auslastungswerten,
- Umweltlage mit Pegel-, Niederschlags- und Warninformationen,
- kommunale Mobilitätslage mit Parken, Verkehrszählungen und ÖPNV-Daten.
Dieser Zuschnitt muss für das jeweilige Vorhaben anhand konkreter Fragen bewertet werden: Welche Nutzergruppen greifen zu? Über welche Kanäle werden Daten bereitgestellt? Welche Bestände werden regelmäßig gemeinsam verwendet? Aus welchen Quellen entstehen die abgeleiteten Ergebnisse? Er eignet sich, wenn dieselbe Zielgruppe mehrere Quellen gemeinsam nutzt oder wenn für die abgeleiteten Ergebnisse eine eigene Freigabe benötigt wird.
Für einen kleinen, klar abgegrenzten Datenbestand kann ein einzelner Datenraum ausreichen. Quellnahe und fachnahe Räume sind ein Strukturierungsmuster, keine Pflichtarchitektur. Zusätzliche Räume sind nur sinnvoll, wenn sie eine nachvollziehbare fachliche, organisatorische oder technische Grenze ausdrücken.
Den Zuschnitt in vier Schritten festlegen
Bestände benennen
Quellen, Basisdaten und abgeleitete Datenprodukte vollständig auflisten.
Gemeinsame Nutzung prüfen
Zielgruppen, Anwendungen, Schnittstellen und Überschneidungen vergleichen.
Trennung begründen
Zugriff, Schutzbedarf, Lebenszyklus und Änderungsrhythmus gegeneinander abwägen.
Raum dokumentieren
Zweck, Inhalt, Name, Zugriffsweg und zuständige Stelle nachvollziehbar festhalten.
Wann Daten zusammenbleiben können
- Sie werden von weitgehend denselben Personen und Anwendungen genutzt.
- Für sie gelten dieselben Freigabe- und Schutzanforderungen.
- Aktualisierung, Aufbewahrung und Änderung folgen einem ähnlichen Lebenszyklus.
- Gemeinsame Abfragen und Datenprodukte benötigen die Bestände regelmäßig zusammen.
Wann eine Trennung sinnvoll ist
- Der Zugriff muss für unterschiedliche Zielgruppen separat vergeben werden.
- Ein Bestand enthält vertraulichere oder anders freizugebende Inhalte.
- Quellnahe Basisdaten sollen unabhängig von einem einzelnen Anwendungsfall wiederverwendet werden.
- Abgeleitete Ergebnisse haben einen eigenen fachlichen Zweck oder Lebenszyklus.
- Eine technische Schnittstelle kann die notwendige Grenze nur auf Datenraumebene durchsetzen.
Trennen Sie Daten nicht allein deshalb, weil sie aus verschiedenen Dateien, Tabellen oder Werkzeugen stammen. Führen Sie Daten umgekehrt nicht nur deshalb zusammen, weil sie im selben Dashboard angezeigt werden.
Beispiel: Parkraumdaten strukturieren
| Ebene | Beispielhafter Datenraum | Enthaltene Daten | Begründung |
|---|---|---|---|
| quellnah | ds_parking_sources | standardisierte Belegungszustände und Stammdaten der angebundenen Sensorik | Basisdaten bleiben unabhängig von einer einzelnen Auswertung wiederverwendbar |
| fachnah | ds_parking_management | zusammengeführte Belegung, Kontrollzonen und verdichtete Auslastungswerte | Ergebnisse werden gemeinsam für Parkraummanagement und Fachanwendungen freigegeben |
Das Beispiel ist keine verbindliche Vorgabe für jeden Parkraum-Use-Case. Bestehen nur eine Quelle, eine Zielgruppe und ein gemeinsamer Lebenszyklus, kann ein einziger fachlich benannter Datenraum die verständlichere Lösung sein.
Einen Datenraum beschreiben
Halten Sie für jeden vorgesehenen Datenraum mindestens folgende Angaben fest:
| Angabe | Leitfrage | Beispiel |
|---|---|---|
| fachlicher Name | Wie wird der Bereich verständlich bezeichnet? | Parkraummanagement |
| technischer Name | Welcher stabile Bezeichner wird in Schnittstellen verwendet? | ds_parking_management |
| Zweck | Welche gemeinsame Nutzung begründet den Raum? | Parkraumlage aus mehreren Beständen bereitstellen |
| enthaltene Bestände | Welche Basisdaten und Datenprodukte gehören hinein? | Belegung, Kontrollzonen, Auslastungswerte |
| ausgeschlossene Inhalte | Was gehört ausdrücklich nicht hinein? | personenbezogene Kontrolldaten |
| Zugriffsgruppen | Welche Personenkreise oder technischen Anwendungen benötigen Zugriff? | Fachanwendung und freigegebener Integrationsflow |
| Zugriffsarten | Welche Operationen werden tatsächlich benötigt? | lesender API-Zugriff, schreibender Integrationszugang |
| Schnittstellen | Über welche Wege werden Daten genutzt? | NGSI-LD-API und freigegebene Dashboard-Datenquelle |
| Herkunft und Abhängigkeiten | Aus welchen Quellen oder anderen Datenräumen entstehen die Inhalte? | Sensorbasisdaten und Kontrollzonen |
| zuständige Stelle | Wer entscheidet über Inhalt, Änderung und Freigabe? | im Vorhaben benannte Fachstelle |
Verwenden Sie einen kurzen, stabilen technischen Namen. Das Muster ds_<bereich> macht den Verwendungszweck sichtbar, etwa ds_environment. Der Name sollte nicht von einer temporären Projektphase, einer Person oder einer konkreten Umgebung wie Test und Produktion abhängen.
Von der Festlegung zur technischen Einrichtung
Die fachliche Beschreibung wird anschließend in der Plattform technisch umgesetzt. Für den NGSI-LD-Pfad entspricht ein Datenraum einem Stellio-Tenant mit getrenntem Datenbankschema. Ein solcher Tenant kann mehrere Datensätze und Datenprodukte enthalten. Die Zugriffszuordnung und die benötigten API-Rechte begrenzen, wer den Datenraum lesen oder verändern darf.
Andere Komponenten bilden dasselbe Prinzip mit ihren eigenen Mitteln ab, beispielsweise durch GeoServer-Workspaces oder komponentenspezifische Rollen- und Gruppenmodelle. Ein Datenraum ist deshalb nicht in jedem Werkzeug dasselbe technische Objekt, bleibt aber die gemeinsame fachliche Zugriffsgrenze.
Beim veröffentlichten API-Zugriff stellt Keycloak die technische Identität bereit und APISIX schützt den vorgesehenen Pfad. Direkte Zugriffe einer bereitgestellten Anwendung, etwa auf eine Datenbank-View, werden mit den Berechtigungsmechanismen der jeweiligen Komponente begrenzt. Das Datenraumprinzip bleibt gleich, seine technische Umsetzung ist jedoch nicht in jedem Werkzeug identisch.
Die konkrete Einrichtung beschreibt Datenraum bereitstellen. Rollen und Zugriffe werden unter Rollen und Rechte verwalten zugeordnet.