Datenräume, Schemata und Datenbanktabellen

Inhalt und Detailgrad werden noch geschärft

Aufbau, Beschreibungstiefe, Beispiele und inhaltlicher Detailgrad dieser Seite werden im weiteren Verlauf noch abgestimmt und vereinheitlicht.

Was ist ein Datenraum?

Ein Datenraum ist eine logische Trennungsebene innerhalb der Plattform. Er gruppiert zusammengehörige Daten eines Themenbereichs oder Projekts und trennt sie von anderen Daten — sowohl organisatorisch als auch technisch.

Wie hängen Datenraum, Schema und Tabelle zusammen?

Die drei Konzepte bauen aufeinander auf:

Ebene	Konzept	Beschreibung
Logisch	Datenraum	Fachliche Einheit, zum Beispiel „Mobilität" oder „Klima"
Technisch (Datenbank)	Schema	PostgreSQL-Schema, das dem Datenraum entspricht
Technisch (Datenbank)	Tabelle	Konkrete Datentabelle innerhalb des Schemas

Ein Datenraum wird in PostgreSQL typischerweise als eigenes Schema abgebildet. Innerhalb dieses Schemas liegen dann die Tabellen, die die eigentlichen Datensätze enthalten.

Beispiel

Ein Datenraum „Mobilität" entspricht dem Datenbankschema mobilitaet. Darin liegen Tabellen wie parkplaetze, fahrzeugzaehlungen oder sensordaten. Daten aus dem Datenraum „Klima" sind in einem separaten Schema klima abgelegt und nicht direkt zugänglich für Abfragen, die nur auf mobilitaet berechtigt sind.

Wie hängt das mit Stellio zusammen?

Wenn Daten über Stellio beziehungsweise den Kontextbroker in die Plattform geschrieben werden, entstehen die zugrunde liegenden Datenbankstrukturen nicht immer manuell, sondern häufig automatisiert. Das betrifft insbesondere Schemata und Tabellen, die im Hintergrund für die Verwaltung der Kontextdaten angelegt werden.

Für die Praxis ist wichtig:

• Stellio legt technische Strukturen in der Datenbank automatisiert an.
• Diese Strukturen orientieren sich an den in der Plattform genutzten Datenräumen und internen Organisationslogiken.
• Dadurch entstehen Schemata und Tabellen, die nicht wie frei entworfene Projekttabellen behandelt werden sollten.

Wer sich diese Daten in pgAdmin anschaut, sieht deshalb unter Umständen automatisch erzeugte Schema- und Tabellennamen, die nicht primär für die manuelle Modellierung gedacht sind, sondern aus der internen Logik von Stellio stammen.

Was bedeutet das für die Arbeit in der Datenbank?

Gerade bei von Stellio erzeugten Strukturen ist Vorsicht wichtig.

• Die Tabellen können angesehen und für Analyse- oder Prüfzwecke nachvollzogen werden.
• Direkte manuelle Änderungen an Spalten, Datentypen oder technischen Tabellenstrukturen sind dort in der Regel nicht der richtige Weg.
• Wenn sich fachliche Attribute, Typen oder Formate ändern sollen, sollte das möglichst über das Datenmodell, den Datenfluss oder die schreibende Komponente gelöst werden.

Das ist der zentrale Unterschied zu eigenen Fachtabellen: Eigene relationale Tabellen können bewusst weiterentwickelt werden. Automatisch erzeugte Kontextbroker-Strukturen sollten dagegen eher gelesen und verstanden als direkt manuell umgebaut werden.

Warum ist diese Trennung wichtig?

• Zugriffskontrolle: Berechtigungen können auf Schema-Ebene vergeben werden, sodass verschiedene Nutzer oder Dienste nur auf ihre relevanten Datenräume zugreifen.
• Übersicht: Daten bleiben thematisch geordnet, auch wenn die Plattform viele unterschiedliche Quellen verwaltet.
• Namenskonflikte vermeiden: Gleich benannte Tabellen können in verschiedenen Schemata existieren, ohne sich gegenseitig zu stören.