Das Geodatabase-Speichermodell basiert auf den Grundprinzipien relationaler Datenbanken

Ein Datenbankmanagementsystem (DBMS) kann als offen bezeichnet werden, da es aufgrund der Einfachheit und Flexibilität des relationalen Datenmodells zahlreiche Anwendungen unterstützt.

Das Geodatabase-Speichermodell basiert auf DBMS-Prinzipien und auf einer Reihe von einfachen, jedoch äußerst wichtigen relationalen Datenbankkonzepten. Das DBMS (wie auch das Dateisystem bei File-Geodatabases) bietet ein einfaches, formales Datenmodell zum Speichern von und Arbeiten mit Informationen in Tabellen.

Zu den wichtigsten Konzepten gehören folgende:

• Daten werden in Tabellen organisiert.
• Tabellen enthalten Zeilen.
• Alle Zeilen in einer Tabelle verfügen über dieselben Spalten.
• Jeder Spalte ist ein Typ zugewiesen, z. B. Ganzzahl, Dezimalzahl, Zeichen, Datum usw.
• Mit Beziehungen werden Zeilen in einer Tabelle mit Zeilen in einer anderen Tabelle verknüpft. Die Basis hierfür bildet eine gemeinsame Spalte, über die beide Tabellen verfügen.
• Es gelten Regeln für die relationale Integrität in Tabellen. Beispiel: Alle Zeilen verfügen über dieselben Spalten, die gültigen Werte oder Wertebereiche für eine Spalte werden in Domänen aufgelistet, usw.

Für ArcSDE-Geodatabases, die in relationalen Datenbanken gespeichert sind, wird eine Reihe von zusätzlichen DBMS-Funktionen unterstützt:

• SQL (Structured Query Language), eine Reihe relationaler Funktionen und Operatoren, ist für die Bearbeitung der Tabellen und deren Datenelemente verfügbar.
• SQL-Operatoren sind für die Verwendung mit relationalen Datentypen konzipiert, z. B. Ganzzahl, Dezimalzahl, Zeichen, Datum usw.

Feature-Classes können z. B. als DBMS-Tabelle gespeichert werden. Jede Zeile steht für ein Feature. Die Spalten in jeder Zeile stehen für verschiedene Eigenschaften des Features, wobei eine der Spalten die Feature-Geometrie enthält (z. B. Punkt-, Linien- oder Polygonkoordinaten). Im folgenden Beispiel enthält das Feld "Shape" ein Polygon-Shape für jede Flurstückzeile in der Feature-Class-Tabelle.

Für das Feld "Shape" in der DBMS-Tabelle können verschiedene Spaltentypen verwendet werden. In der Regel wird der Typ Binary Large Object (BLOB) oder ein erweiterter räumlicher Typ verwendet, der in einigen DBMS unterstützt wird. Beispielsweise ist mindestens ein räumlicher Spaltentyp zur Speicherung von Features für alle DBMS-Systeme verfügbar, die ArcSDE unterstützt: Oracle, IBM DB2, Informix, PostgreSQL und SQL Server. Dadurch wird der Zugriff auf Features per SQL unterstützt, die den ISO- und OGC-Standards (International Organization for Standardization/Open Geospatial Consortium, Inc. [OGC]) für räumliche Typen entspricht.

SQL kann für Zeilen, Spalten und Typen in Tabellen verwendet werden. Die Spaltentypen (Zahl, Zeichen, Datum, BLOB, räumliche Typen usw.) sind Objekte in der SQL-Struktur. Diese einfachen Datentypen und Tabellen werden im DBMS verwaltet, und komplexere Objektverhalten sowie Integritätseinschränkungen werden durch zusätzliche Anwendungslogik bereitgestellt.

Das Hinzufügen von räumlichen Typen und SQL-Unterstützung für räumliche Attribute in einem DBMS ist allein jedoch nicht ausreichend, um ein GIS zu unterstützen.

Implementieren von komplexeren Objekten und Verhalten in relationalen DBMS-Systemen

Entwickler, die komplexere Objekte mit Verhalten und Logik implementieren möchten, schreiben zu diesem Zweck Anwendungs-Code. Ein Unternehmen kann eine Mitarbeitertabelle z. B. wie folgt implementieren:

Nachname	Vorname	Einstellungsdatum	Gehalt
Braun	Bernhard	10-10-2001	$10.000,50
Jansen	Birgit	06-14-1998	$22.000,00
Schmidt	Johannes	08-23-1999	$44.000,75

Mitarbeitertabelle

Bei der Mitarbeitertabelle handelt es sich um eine einfache relationale Datentabelle mit Zeilen und Spalten. Den Daten in jeder Spalte ist ein bestimmter Datentyp zugewiesen, z. B. Zeichen, Datum oder Zahl. Die Informationen werden in DBMS auf dieser Ebene verarbeitet.

Allein durch das Hinzufügen der Informationen zu einer DBMS-Tabelle wird das DBMS jedoch noch nicht zu einem System zur Verwaltung von Lohnbuchhaltung oder Personal. Durch das Hinzufügen einer Spalte mit dem Namen "Euro", die Zahlen mit zwei Dezimalstellen enthält, wird das DBMS nicht automatisch zu einem Abrechnungssystem. Hier ist komplexere Anwendungslogik erforderlich.

So können Sie beispielsweise Anwendungslogik hinzufügen, um Mitarbeiteraktivitäten zu unterstützen, wie Einstellungen, Gehaltserhöhungen, Kündigungen, Beförderung und Bonusmanagement. Die für die Mitarbeiter und ihre Namen, Gehälter und Einstellungsdaten modellierten Objekte werden nicht als relationale Objekte implementiert. Zur Implementierung von Verhalten und Integrität für diese Objekte ist eine komplexere und präzisere Anwendungslogik erforderlich.

Ähnliche Objekte werden im GIS universell eingesetzt. Topologien, Netzwerke, lineare Referenzierungssysteme, Raster-Kataloge, Annotations, Terrains, Karten-Layer usw. sind Beispiele für die erweiterten Objekte, die verwendet werden, um die im DBMS gespeicherten einfachen räumlichen Repräsentationen mit GIS-Verhalten zu optimieren.

Wie auch bei anderen DBMS-Anwendungen reichen bei GIS-Anwendungen Tabellen mit räumlichen Spaltentypen allein nicht aus. Beide Objektsammlungen (die einfachen relationalen Spaltentypen im DBMS und die Geodatabase-Anwendungsobjekte wie Topologien) sind zur Erstellung von geographischen Informationssystemen erforderlich.

Implementierung der Anwendungslogik

Bei vielen Implementierungen von Datenbankmanagementsystemen (DBMS) hat sich deutlich gezeigt, dass die Verwendung einer separaten Anwendungsschicht für Zeilen- und Spaltentypen in Tabellen für fortschrittliche Anwendungen geeignet ist. Bei allen gängigen Kundeninformationssystemen (CIS), Enterprise Resource Planning-Systemen (ERP) und Abrechnungssystemen wird fortschrittliche Anwendungslogik in einer Anwendungsschicht implementiert, wodurch eine größere Offenheit und Erweiterbarkeit, höhere Performance und Flexibilität und eine größere Auswahl an Werkzeugen erzielt wird.

Die Benutzerinteraktion und die Ausführung von Transaktionen in diesen Systemen können bei fast allen Vorgängen über die Anwendungslogik erfolgen. SQL (Structured Query Language) muss nur für bestimmte Aktivitäten verwendet werden.

Des Weiteren kann durch die Trennung der Anwendungslogik von der Datenschicht dieselbe Logik auch auf DBMS-Systeme, Dateien, XML (Extensible Markup Language) und andere Speicheralternativen angewendet werden. Dadurch erhält die Architektur eine noch größere Offenheit. Die Geodatabase-Anwendungslogik in ArcGIS wird z. B. auch zum Lesen und Bearbeiten von geographischen Daten aus allen anderen Quellen verwendet – CAD-Daten, Shapefiles, MapInfo-Daten, Intergraph GeoMedia-Dateien und GML-Dateien (Geography Markup Language).

Andere Möglichkeiten zum Implementieren dieser komplexen Logik sind beispielsweise gespeicherte Prozeduren und Datenbank-Trigger im DBMS oder erweiterte Typen im DBMS.