Datenbank-Funktionen

Die VCDB v5 enthält eine Reihe von Datenbank-Funktionen, die während des Aufsetzens der Datenbank automatisch installiert werden. Diese Funktionen führen verschiedene Datenbankoperationen aus, wie z. B. das Löschen oder Terminieren von Stadtobjekten, das Berechnen ihrer Envelopes und das Setzen des Koordinatenreferenzsystems (CRS) für die VCDB-Instanz. Darüber hinaus sind weitere Hilfs- und Utility-Funktionen enthalten. Die Funktionen können zur Automatisierung von Prozessen und Workflows genutzt und in Drittsoftware integriert werden.

Für PostgreSQL sind die Funktionen in PL/pgSQL implementiert und befinden sich in den Schemas citydb_pkg und vcdb_pkg. Da beide Schemas während des Aufsetzens der Datenbank automatisch zum search_path der Datenbank hinzugefügt werden, können die Funktionen aufgerufen werden, ohne das Schema explizit als Präfix angeben zu müssen.

Löschfunktionen

Die Löschfunktionen ermöglichen das Entfernen einzelner oder mehrerer Stadtobjekte, wobei referenzielle Integritätsregeln zwischen den Datenbanktabellen automatisch berücksichtigt werden. Sie dienen als Low-Level-API und bieten dedizierte Löschfunktionen für verschiedene Tabellen des relationalen Schemas der VCDB v5 — von einzelnen Geometrien in der GEOMETRY_DATA Tabelle (delete_geometry_data Funktion) bis hin zu kompletten Features in der FEATURE Tabelle, einschließlich ihrer Attribute, Geometrien und Appearances (delete_feature Funktion). Die Löschfunktionen ermöglichen es Anwendern, auf ihrer Basis komplexere Löschoperationen zu entwickeln, ohne ihre Kernfunktionalität erneut implementieren zu müssen.

Die verfügbaren Löschfunktionen sind in der folgenden Tabelle aufgeführt.

Funktion Rückgabetyp Beschreibung

Funktion	Rückgabetyp	Beschreibung
`cleanup_schema` `(schema_name TEXT)`	`void`	Leert alle Datentabellen
`delete_feature` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `FEATURE` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_property` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `PROPERTY` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_geometry_data` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `GEOMETRY_DATA` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_implicit_geometry` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `IMPLICIT_GEOMETRY` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_appearance` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `APPEARANCE` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_surface_data` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `SURFACE_DATA` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_tex_image` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `TEX_IMAGE` Tabelle basierend auf einer `id` oder einem `id` Array
`delete_address` `(pid bigint, schema_name TEXT)` oder `(pid_array bigint[], schema_name TEXT)`	`BIGINT` oder `SETOF BIGINT`	Löscht Einträge aus der `ADDRESS` Tabelle basierend auf einer id oder einem id Array

cleanup_schema
(schema_name TEXT)

void

Leert alle Datentabellen

delete_feature
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der FEATURE Tabelle basierend auf einer id oder einem id Array

delete_property
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der PROPERTY Tabelle basierend auf einer id oder einem id Array

delete_geometry_data
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der GEOMETRY_DATA Tabelle basierend auf einer id oder einem id Array

delete_implicit_geometry
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der IMPLICIT_GEOMETRY Tabelle basierend auf einer id oder einem id Array

delete_appearance
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der APPEARANCE Tabelle basierend auf einer id oder einem id Array

delete_surface_data
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der SURFACE_DATA Tabelle basierend auf einer id oder einem id Array

delete_tex_image
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der TEX_IMAGE Tabelle basierend auf einer id oder einem id Array

delete_address
(pid bigint, schema_name TEXT) oder
(pid_array bigint[], schema_name TEXT)

BIGINT oder
SETOF BIGINT

Löscht Einträge aus der ADDRESS Tabelle basierend auf einer id oder einem id Array

Die Löschfunktionen liegen in zwei Varianten vor:

Löschen einzelner Einträge: Die erste Variante akzeptiert die id (Primärschlüssel) eines einzelnen Eintrags, der gelöscht werden soll, und gibt die id als Ausgabewert zurück, sofern das Löschen erfolgreich war. Falls NULL zurückgegeben wird, wurde der Eintrag entweder bereits gelöscht wurde oder es ist ein Fehler während des Löschvorgangs aufgetreten.
Löschen mehrerer Einträge: Die zweite Variante akzeptiert ein Array von id Werten und gibt die id-Werte der erfolgreich gelöschten Einträge als SETOF BIGINT zurück. Auf diese Weise lassen sich mehrere Einträge in einem Schritt löschen.

Alle Funktionen besitzen einen optionalen Parameter schema_name, mit dem sich die Funktionen auf unterschiedliche Datenbank-Schemas innerhalb der PostgreSQL-Datenbank anwendenden lassen. Das angegebene Schema muss natürlich eine gültige VCDB v5 Instanz enthalten. Weitere Information finden Sie unten.

Das folgende Beispiel zeigt, wie Features sehr einfach auf Basis einer SQL-Abfrage gelöscht werden können:

-- lösche ein einzelnes Feature über seine id
SELECT delete_feature(id) FROM feature WHERE ... ;

-- lösche mehrere Features anhand eines id-Arrays
SELECT delete_feature(array_agg(id)) FROM feature WHERE ... ;

Die Löschfunktionen mit id-Array erfordern weniger DELETE Statements auf der Datenbank und können daher oftmals schneller ausgeführt werden als das wiederholte Ausführen der Löschfunktion für jede einzelne id. Das muss jedoch nicht immer der Fall sein und hängt auch vom Verhältnis der zu löschenden Einträge zur Gesamtanzahl aller Einträge in der Tabelle ab. Enthält das id-Array beispielsweise sehr viele Einträge und deckt damit einen Großteil der Tabelle ab, kann es effizienter sein, die Löschfunktion für jede einzelne id aufzurufen oder das Löschen in kleineren Batches durchzuführen.

Das Beispiel unten zeigt die Definition einer eigenen Löschfunktion, die die vordefinierte delete_feature Funktion nutzt, um alle Gebäude in der VCDB zu löschen:

-- Beispiel-Funktion zum Löschen aller Gebäude
DO $$
DECLARE
  rec RECORD;
BEGIN
  FOR rec IN SELECT * FROM feature where objectclass_id = 901 LOOP
    -- führe die delete_feature Funktion für jede einzelne id aus
    PERFORM delete_feature(rec.id);
  END LOOP;
END $$;

Beim Löschen eines Features werden alle seine "enthaltenen" (contained) Subfeatures, die als Teil dieses Features betrachtet werden, ebenfalls gelöscht. Features, die nur "in Beziehung stehen" (related) aber nicht als Bestandteil des Features gelten, werden nicht gelöscht. Die Unterscheidung zwischen contained und related basiert auf der Auswertung der Spalte val_relation_type in der PROPERTY Tabelle, wie hier beschrieben.

Die cleanup_schema Funktion erfüllt einen speziellen Zweck: Sie leert alle Datenbanktabellen mit nur einem Funktionsaufruf. Dies ist der komfortabelste und schnellste Weg, um den gesamten Inhalt einer VCDB v5 Instanz zu löschen. Seien Sie jedoch vorsichtig bei der Verwendung dieser Funktion, da sie nicht rückgängig gemacht werden kann.

Terminate-Funktionen

Die Löschfunktionen löschen Stadtobjekte physisch aus der VCDB-Instanz und helfen dabei, die Datenbank schlank zu halten, indem nur die aktuellsten Versionen der Stadtobjekte gespeichert bleiben. In manchen Fällen ist es jedoch erforderlich, die Objekt-Historie beizubehalten und veraltete Versionen nicht zu löschen. Für solche Anwendungsfälle stellt die VCDB zusätzliche Terminate-Funktionen bereit. Diese Funktionen löschen Features nicht physisch, sondern markieren sie stattdessen als "terminiert", indem sie den Wert der Spalte terminate_date auf den Zeitstempel der Operation setzen. Zusammen mit dem creation_date kann damit die Lebensdauer eines Features in der Datenbank nachvollzogen werden. So lassen sich mehrere historische Versionen eines Features parallel zu seiner aktuellsten Version speichern.

Funktion Rückgabetyp Beschreibung

Funktion	Rückgabetyp	Beschreibung
`terminate_feature` `(pid bigint, schema_name TEXT, metadata JSON, cascade BOOLEAN)` oder `(pid_array bigint[], schema_name TEXT, metadata JSON, cascade BOOLEAN)`	`BIGINT` oder `SETOF BIGINT`	Terminiert Features in der `FEATURE` Tabelle basierend auf einer `id` oder einem `id` Array

terminate_feature
(pid bigint, schema_name TEXT, metadata JSON, cascade BOOLEAN) oder
(pid_array bigint[], schema_name TEXT, metadata JSON, cascade BOOLEAN)

BIGINT oder
SETOF BIGINT

Terminiert Features in der FEATURE Tabelle basierend auf einer id oder einem id Array

Da die Spalten creation_date und termination_date ausschließlich in der Tabelle FEATURE vorkommen, gib es nur die terminate_feature Funktion zum Terminieren von Features. Wie die Löschfunktionen akzeptiert diese Funktion entweder eine einzelne id oder ein id Array und gibt die id Werte der erfolgreich terminierten Features zurück (siehe oben).

Die FEATURE Tabelle enthält zusätzliche Metadaten-Spalten wie last_modification_date, lineage, reason_for_update und updating_person (siehe hier für weitere Informationen). Die Terminate-Funktionen erlauben es, die Werte dieser Spalten für das terminierte Feature zu aktualisieren. Hierzu kann ein JSON-Objekt als metadata Parameter übergeben werden, in dem jeder Schlüssel einem Spaltennamen entspricht und den neuen Wert enthält, der in der Spalte gespeichert werden soll. Wird das gesamte JSON-Objekt oder einzelne Einträge darin weggelassen, bleiben die aktuellen Werte in den Metadaten-Spalten erhalten – mit Ausnahme von last_modification_date, das immer auf denselben Zeitstempel wie termination_date gesetzt wird.

Der letzte Parameter cascade legt fest, ob "enthaltene" (contained) Subfeatures ebenfalls terminiert werden sollen (Default: true). Das Terminieren aller Subfeatures kann deutlich mehr Zeit in Anspruch nehmen, als wenn nur das Feature selbst terminiert wird. Es muss daher geprüft werden, ob eine kaskadierende Ausführung für die angedachten Anwendungsfälle und Szenarien erforderlich ist.

Das folgende Beispiel zeigt die Terminierung eines einzelnen Features anhand seiner id.

SELECT terminate_feature(
    2060316,
    '{
        "reason_for_update": "test reason",
        "updating_peron": "test person",
        "lineage": "test lineage"
    }'::json,
    FALSE
);

Wenn Features in der Datenbank terminiert werden, muss sichergestellt werden, dass die eingesetzten Software-Tools das termination_date auch korrekt auswerten. Nur so kann garantiert werden, dass die Tools beim Export oder Prozessieren von Features die korrekte Version des Features verwenden. Das im Lieferumfang der VCDB v5 enthaltene vcdb-tool unterstützt Objekt-Historien auf Basis von creation_date und termination_date vollständig.

Envelope-Funktionen

Das citydb_pkg Paket bietet Funktionen zur Berechnung der 3D-Bounding-Box von Features und impliziten Geometrien bereit. Darüber hinaus sind zusätzliche Hilfsfunktionen enthalten, die von diesen Funktionen verwendet werden.

Funktion Rückgabetyp Beschreibung

Funktion	Rückgabetyp	Beschreibung
`get_feature_envelope` `(fid BIGINT, schema_name TEXT, compute_envelope INTEGER, set_envelope INTEGER)`	`GEOMETRY`	Gibt die Envelope-Geometrie eines Features zurück
`get_implicit_geometry_envelope` `(gid BIGINT, ref_pt GEOMETRY, matrix JSON, schema_name TEXT)`	`GEOMETRY`	Gibt die Envelope-Geometrie einer impliziten Geometrie zurück
`get_envelope` `(geom GEOMETRY, schema_name TEXT)`	`GEOMETRY`	Berechnet die Envelope-Geometrie für eine Geometrie

get_feature_envelope
(fid BIGINT, schema_name TEXT, compute_envelope INTEGER, set_envelope INTEGER)

GEOMETRY

Gibt die Envelope-Geometrie eines Features zurück

get_implicit_geometry_envelope
(gid BIGINT, ref_pt GEOMETRY, matrix JSON, schema_name TEXT)

GEOMETRY

Gibt die Envelope-Geometrie einer impliziten Geometrie zurück

get_envelope
(geom GEOMETRY, schema_name TEXT)

GEOMETRY

Berechnet die Envelope-Geometrie für eine Geometrie

Die Funktion get_feature_envelope gibt den Envelope eines Features zurück. Als Eingabe muss die id (Primärschlüssel) des Features übergeben werden. Wenn der Parameter compute_envelope auf 0 gesetzt wird (Standard), wird die aktuell in der FEATURE Tabelle gespeicherte Envelope-Geometrie zurückgegeben. Wird der Parameter auf 1 gesetzt – oder falls der gespeicherte Wert in der FEATURE Tabelle NULL ist – wird der Envelope neu berechnet. Dabei werden alle Geometrien des Features und seiner "enthaltenen" (contained) Subfeatures über alle LoDs hinweg ausgewertet, einschließlich impliziter Geometrien. Das Ergebnis ist das minimale 3D-Rechteck, das das Feature vollständig umschließt. Diese Geometrie kann direkt als Wert für die Spalte envelope der FEATURE Tabelle verwendet werden.

Die get_feature_envelope Funktion bietet zwei weitere optionale Parameter: Der set_envelope Parameter gibt an, ob die berechnete Envelope-Geometrie automatisch in die envelope Spalte des Features und seiner Subfeatures geschrieben werden soll (1 = ja, 0 = nein; Standard: 0). Der schema_name Parameter legt das Datenbankschema fest, in dem die Operation ausgeführt werden soll (siehe unten).

Der Envelope impliziter Geometrien kann mit der get_implicit_geometry_envelope Funktion berechnet werden. Sie benötigt die folgenden Eingaben: die id (Primärschlüssel) der Template-Geometrie in der GEOMETRY_DATA Tabelle, eine PostGIS POINT Geometrie, die den Punkt mit Realwelt-Koordinaten angibt, an welchem das Template platziert werden soll (ref_pt), und eine 3x4 Matrix im Row-Major-Format (JSON Double-Array), die Rotation, Skalierung und Translation für das Template definiert (matrix).

Die Werte für ref_pt und matrix entsprechen dem Format, das auch in der PROPERTY Tabelle verwendet wird (siehe hier). Daher können die Werte aus der PROPERTY Tabelle direkt als Eingabeparameter verwendet werden.

Die weitere get_envelope Funktion wird von den oben genannten Funktionen intern verwendet. Sie kann jedoch auch eigenständig aufgerufen werden, um den Envelope für eine einzelne Geometrien zu berechnen. Das Ergebnis kann wiederum direkt für die envelope Spalte der FEATURE Tabelle genutzt werden.

CRS-Funktionen

Das citydb_pkg Paket stellt Funktionen für CRS-Operationen auf einer VCDB-Instanz bereit.

Funktion Rückgabetyp Beschreibung

Funktion	Rückgabetyp	Beschreibung
`change_schema_srid` `(target_srid INTEGER, target_srs_name TEXT, schema_name TEXT, transform INTEGER)`	`SETOF VOID`	Aktualisiert das Koordinatenreferenzsystem für ein Datenbankschema
`change_column_srid` `(table_name TEXT, column_name TEXT, dim INTEGER, target_srid INTEGER, schema_name TEXT, transform INTEGER, geom_type TEXT)`	`SETOF VOID`	Aktualisiert das Koordinatenreferenzsystem für eine einzelne Geometriespalte
`check_srid` `(srid INTEGER)`	`INTEGER`	Prüft, ob die angegebene `SRID` gültig ist
`get_coord_ref_sys_info` `(srid INTEGER)`	`RECORD`	Gibt den Namen, den Typ und die WKT-Darstellung für das angegebene CRS zurück
`is_coord_ref_sys_3d` `(srid INTEGER)`	`INTEGER`	Prüft, ob das angegebene CRS ein echtes 3D-Referenzsystem ist
`is_db_coord_ref_sys_3d` `(schema_name TEXT)`	`INTEGER`	Prüft, ob das CRS der VCDB ein echtes 3D-Referenzsystem ist

change_schema_srid
(target_srid INTEGER, target_srs_name TEXT, schema_name TEXT, transform INTEGER)

SETOF VOID

Aktualisiert das Koordinatenreferenzsystem für ein Datenbankschema

change_column_srid
(table_name TEXT, column_name TEXT, dim INTEGER, target_srid INTEGER, schema_name TEXT, transform INTEGER, geom_type TEXT)

SETOF VOID

Aktualisiert das Koordinatenreferenzsystem für eine einzelne Geometriespalte

check_srid
(srid INTEGER)

INTEGER

Prüft, ob die angegebene SRID gültig ist

get_coord_ref_sys_info
(srid INTEGER)

RECORD

Gibt den Namen, den Typ und die WKT-Darstellung für das angegebene CRS zurück

is_coord_ref_sys_3d
(srid INTEGER)

INTEGER

Prüft, ob das angegebene CRS ein echtes 3D-Referenzsystem ist

is_db_coord_ref_sys_3d
(schema_name TEXT)

INTEGER

Prüft, ob das CRS der VCDB ein echtes 3D-Referenzsystem ist

Die Hauptfunktion change_schema_srid ändert das CRS für alle Geometriespalten innerhalb eines VCDB Schemas (Standard: citydb). Sie erwartet die SRID (Spatial Reference ID) des neuen CRS und dessen OGC-konformen Namen als Eingabewerte.

Die Funktion kann in zwei Varianten ausgeführt werden, die durch den Wert des transform Parameters festgelegt werden:

Nur Metadaten aktualisieren: Die SRID wird in den Datenbankmetadaten angepasst, ohne eine Transformation der Koordinaten durchzuführen (transform = 0, Standard).
Koordinaten transformieren: Die Koordinaten der in der Datenbank gespeicherten Geometrien werden zusätzlich in das neue CRS transformiert (transform = 1).

Beide Varianten sind für unterschiedliche Szenarien sinnvoll. Wurde beispielsweise die VCDB v5 mit einer falschen SRID aufgesetzt, die nicht dem CRS der importierten Geometrien entspricht, dann genügt es, mit der ersten Variante nur die Metadaten zu aktualisieren, da die Koordinaten bereits im richtigen CRS vorliegen. Wenn die Geometrien in der VCDB jedoch zum aktuellen CRS passen, aber in ein neues CRS überführt werden müssen, ist die zweite Variante erforderlich, um die Koordinaten entsprechend umzurechnen.

Abschließenden aktualisiert change_schema_srid automatisch die Metadaten in der DATABASE_SRS Tabelle mit den neuen Werten.

Unabhängig von der gewählten Ausführungsvariante werden beim Ändern des CRS immer alle räumlichen Indizes auf den Geometriespalten gelöscht und neu erstellt, damit sie mit der neuen SRID konsistent sind. Abhängig von der jeweiligen Tabellengröße kann der Prozess daher sehr zeitaufwändig sein.

Hilfsfunktionen

Die Pakete citydb_pkg und vcdb_pkg stellen auch verschiedene Hilfsfunktionen bereit, die nachfolgend aufgeführt sind.

Funktion Rückgabetyp Beschreibung

Funktion	Rückgabetyp	Beschreibung
`citydb_version` `(OUT version TEXT, OUT major_version INTEGER, OUT minor_version INTEGER, OUT minor_revision INTEGER)`	`RECORD`	Gibt die Version der 3DCityDB-Instanz zurück
`vcdb_version` `(OUT version TEXT, OUT major_version INTEGER, OUT minor_version INTEGER, OUT minor_revision INTEGER)`	`RECORD`	Gibt die Version der VCDB-Instanz zurück
`db_metadata` `(schema_name TEXT, OUT srid INTEGER, OUT srs_name TEXT, OUT coord_ref_sys_name TEXT, OUT coord_ref_sys_kind TEXT, OUT wktext TEXT, OUT versioning TEXT)`	`RECORD`	Gibt Metadaten zur VCDB-Instanz zurück
`db_properties`()	`TABLE` `(id TEXT, name TEXT, value TEXT)`	Listet Datenbankeigenschaften wie aktivierte Erweiterungen oder für die VCDB relevante Optionen als Name-Wert-Paare auf.
`get_seq_values` `(seq_name TEXT, seq_count BIGINT)`	`SETOF BIGINT`	Gibt `n` Werte aus der angegebenen Datenbanksequenz zurück
`get_child_objectclass_ids` `(class_id INTEGER, schema_name TEXT, skip_abstract INTEGER)`	`SETOF INTEGER`	Gibt die `id` Werte aller transitiven Subklassen der angegebenen Objektklasse zurück
`get_current_schema`()	`TEXT`	Gibt den Namen des aktiven VCDB Schemas auf Bases des aktuellen `search_path` zurück
`set_current_schema` `(schema_name TEXT, local BOOLEAN)`	`SETOF VOID`	Setzt das aktive VCDB Schema auf den angegebenen Namen durch Anpassung des `search_path`
`schema_exists` `(schema_name TEXT)`	`INTEGER`	Prüft, on das angegebene Schema ein VCDB Schema ist

citydb_version
(OUT version TEXT, OUT major_version INTEGER, OUT minor_version INTEGER, OUT minor_revision INTEGER)

RECORD

Gibt die Version der 3DCityDB-Instanz zurück

vcdb_version
(OUT version TEXT, OUT major_version INTEGER, OUT minor_version INTEGER, OUT minor_revision INTEGER)

RECORD

Gibt die Version der VCDB-Instanz zurück

db_metadata
(schema_name TEXT, OUT srid INTEGER, OUT srs_name TEXT, OUT coord_ref_sys_name TEXT, OUT coord_ref_sys_kind TEXT, OUT wktext TEXT, OUT versioning TEXT)

RECORD

Gibt Metadaten zur VCDB-Instanz zurück

db_properties()

TABLE
(id TEXT, name TEXT, value TEXT)

Listet Datenbankeigenschaften wie aktivierte Erweiterungen oder für die VCDB relevante Optionen als Name-Wert-Paare auf.

get_seq_values
(seq_name TEXT, seq_count BIGINT)

SETOF BIGINT

Gibt n Werte aus der angegebenen Datenbanksequenz zurück

get_child_objectclass_ids
(class_id INTEGER, schema_name TEXT, skip_abstract INTEGER)

SETOF INTEGER

Gibt die id Werte aller transitiven Subklassen der angegebenen Objektklasse zurück

get_current_schema()

TEXT

Gibt den Namen des aktiven VCDB Schemas auf Bases des aktuellen search_path zurück

set_current_schema
(schema_name TEXT, local BOOLEAN)

SETOF VOID

Setzt das aktive VCDB Schema auf den angegebenen Namen durch Anpassung des search_path

schema_exists
(schema_name TEXT)

INTEGER

Prüft, on das angegebene Schema ein VCDB Schema ist

Die Funktionen get_current_schema und set_current_schema vereinfachen die Verwaltung des aktiven VCDB Schemas. Während get_current_schema das aktuell im search_path gesetzte Schema zurückgibt, setzt set_current_schema es auf den angegebenen Namen. Der Parameter local steuert dabei den Geltungsbereich der Änderung: Ist er auf true gesetzt (Standard), gilt die Änderung nur für die aktuelle Transaktion; bei false gilt sie für die gesamte Session, bis sie explizit überschrieben wird. Darüber hinaus fügt set_current_schema automatisch erforderliche Schemas wie citydb_pkg, vcdb_pkg und public zum search_path hinzu.

Mit der Funktion schema_exists kann geprüft werden, ob es sich bei dem angegebenen Schema um ein gültiges VCDB Datenschema handelt.

Funktionen auf verschiedene Schemas anwenden

Die VCDB unterstützt die Nutzung mehrerer Datenschemas innerhalb derselben PostgreSQL-Datenbank. Das Standardschema heißt citydb, während zusätzliche Schemas vom Benutzer frei benannt werden können. Ein Datenbank-Skript zur Erstellung weiterer Datenschemas ist im VCDB Softwarepaket enthalten und hier dokumentiert.

Die meisten in diesem Kapitel beschriebenen Datenbank-Funktionen akzeptieren einen optionalen Parameter schema_name, um das Zielschema zu definieren. Wird dieser Parameter angegeben, setzt die Funktion temporär den search_path der Datenbank auf das angegebene Schema und macht es damit für diese Operation zum aktiven Schema. Diese Änderung des search_path gilt nur für die Dauer der aktuellen Transaktion – jeodch nicht für die gesamte Session. So bleibt jede Änderung des search_path isoliert und beeinflusst keine anderen Operationen außerhalb der Transaktion, was unbeabsichtigte Nebeneffekte verhindert.

Wenn schema_name nicht gesetzt wird, verwendet die Funktion das aktuell im search_path gesetzte Schema. Damit können Benutzer den search_path sehr flexibel vor dem Aufruf von VCDB Datenbank-Funktionen entsprechend den eigenen Anforderungen konfigurieren.

Beim Einrichten einer VCDB Instanz ist das Standardschema immer citydb. Wenn Sie nicht mit mehreren Schemas arbeiten, können Sie den Parameter schema_name beim Funktionsaufruf einfach weglassen — die Funktionen arbeiten dann automatisch auf dem citydb Schema. Für die meisten Nutzer ist dies der empfohlene Weg, die Datenbankfunktionen zu verwenden.

Die Hilfsfunktionen get_current_schema und set_current_schema (siehe oben) sind besonders nützlich, wenn der search_path nicht manuell angepasst werden soll.