Beim Erstellen einer Tabelle oder Hinzufügen einer Spalte zur Tabelle einer Datenbank definieren Sie einen bestimmten Datentyp für die Spalte. Durch Datentypen wird Folgendes festgelegt:
- Welche Werte in der Spalte gespeichert werden können
- Welche Operationen mit den Daten in dieser Spalte ausgeführt werden dürfen
- Wie die Daten aus dieser Spalte in der Datenbank gespeichert werden
ArcGIS verwendet bestimmte Datentypen. Wenn Sie über eine Datenbankverbindung oder über einen Abfrage-Layer auf eine Datenbanktabelle zugreifen, filtert ArcGIS alle nicht unterstützten Datentypen heraus. Da nicht unterstützte Datentypen in ArcGIS nicht angezeigt werden, können Sie sie in ArcGIS nicht bearbeiten. Wenn beispielsweise ArcGIS zum Kopieren und Einfügen von Tabellen, die nicht unterstützte Datentypen enthalten, von einer Datenbank in eine andere verwendet wird, fügt ArcGIS nur die Spalten ein, deren Datentyp unterstützt wird.
Die erste Spalte der folgenden Tabelle enthält die ArcGIS-Datentypen. In der zweiten Spalte sind die von ArcGIS erstellten Oracle-Datentypen aufgeführt. In der dritten Spalte ist aufgelistet, welche weiteren Oracle-Datentypen (sofern vorhanden) dem ArcGIS-Datentyp zugeordnet werden, wenn Sie eine Tabelle anzeigen, die außerhalb von ArcGIS erstellt wurde. Die letzte Spalte enthält ggf. zusätzliche Informationen.
| ArcGIS-Datentypen | Erstellte Oracle-Datentypen | Andere Oracle-Datentypen, die angezeigt werden können | Hinweise |
|---|---|---|---|
BLOB | BLOB | ||
DATE | TIMESTAMP | DATE | |
DOUBLE | NUMBER(38,8) | NUMBER(p,s) | Die Genauigkeit und die Anzahl der Dezimalstellen, die in ArcGIS angegeben sind, können Auswirkungen auf den resultierenden Datentyp haben, der in der Datenbank erstellt wird. Weitere Informationen finden Sie unter ArcGIS-Felddatentypen. |
FLOAT | NUMBER(38,8) | NUMBER(p,s) | Die Genauigkeit und die Anzahl der Dezimalstellen, die in ArcGIS angegeben sind, können Auswirkungen auf den resultierenden Datentyp haben, der in der Datenbank erstellt wird. Weitere Informationen finden Sie unter ArcGIS-Felddatentypen. |
GEOMETRY | ST_GEOMETRY, NUMBER(38), or SDO_GEOMETRY | Der erstellte Oracle-Datentyp hängt vom Geometriespeicher ab, der beim Erstellen der Feature-Class angegeben wird. Compressed binary oder well-known binary (nur Geodatabases) = NUMBER(38); Oracle Spatial = SDO_GEOMETRY; spatial type = ST_GEOMETRY. Um den Typ "ST_Geometry" in einer Datenbank (nicht Geodatabase) verwenden zu können, müssen Sie ihn installieren. | |
GLOBAL ID | CHAR or NCHAR (UUID LEN) | Wird nur in Geodatabases unterstützt. Wenn der Parameter UNICODE_STRING des Konfigurationsschlüsselwortes, mit dem Sie die Erstellung der Tabellen festgelegt haben, auf TRUE festgelegt war, wird das Feld der eindeutigen Kennung mit dem Datentyp "NCHAR" erstellt. | |
GUID | CHAR or NCHAR (UUID LEN) | Wenn der Parameter UNICODE_STRING des Konfigurationsschlüsselworts, mit dem Sie die Erstellung der Tabellen festgelegt haben, auf TRUE gesetzt wurde, wird das eindeutige Kennungsfeld mit dem Datentyp "NCHAR" in einer Geodatabase erstellt. | |
LONG INTEGER | NUMBER(38) | NUMBER(n) | Der Wert n kann im Bereich zwischen 5 und 10 liegen. Bei der Erstellung mit ArcGIS Desktop oder ArcObjects und dem Wert "0" für die Genauigkeit wird NUMBER(38) in der Datenbank erstellt; andernfalls wird die angegebene Genauigkeit verwendet. |
OBJECT ID | NUMBER(38) bei Erstellung in einer Enterprise-Geodatabase NUMBER(38) mit Sequenz und Auslöser bei Erstellung unter folgenden Bedingungen:
NUMBER(38) wurde bei Verwendung von ArcGIS zum Erstellen einer Feature-Class oder Tabelle in einer Oracle 12c-Datenbank immer als Identität erstellt. Oder verwenden Sie das Geoverarbeitungswerkzeug Inkrementelles ID-Feld hinzufügen, um einer Tabelle ein ID-Feld in einer Oracle 12c-Datenbank hinzuzufügen. | Die ArcGIS-Typ-ObjektID ist die registrierte Zeilen-ID-Spalte für die Tabelle (oder Feature-Class). Pro Tabelle gibt es nur eine. | |
RASTER | RASTERBLOB, BLOB, or ST_RASTER | Raster werden nur in Geodatabases unterstützt. Der verwendete Datentyp für das Raster-Feld hängt vom Konfigurationsschlüsselwort ab, das beim Erstellen eines Mosaik-Datasets oder Raster-Datasets angegeben wurde. | |
SHORT INTEGER | NUMBER(5) | NUMBER(n) | Der Wert n kann im Bereich zwischen 1 und 5 liegen. In Short-Integer-Spalten können jedoch nur Werte in einem Bereich von -32.768 bis 32.767 gespeichert werden. Selbst wenn die Genauigkeit für die Zahl 5 lautet, können Sie keine Zahl über 32.767 oder unter -32.768 in einer Short-Integer-Spalte speichern. Bei der Erstellung in ArcGIS Desktop ist n = 5. Dies ermöglicht Ihnen, Short-Integer-Werte zu speichern, die in dem zulässigen Bereich liegen. |
TEXT | VARCHAR2, CLOB, NVARCHAR2 oder NCLOB |
Textdatentypen
Wenn Sie ein Textfeld zu der mit ArcGIS erstellten Tabelle hinzufügen, wird der Datentyp VARCHAR2 verwendet, sofern für die Datenbank nicht Unicode als Codierung festgelegt wurde. Wenn als Textfeldgröße mehr als 4.000 Zeichen und für die Datenbank nicht die Verwendung der Unicode-Codierung festgelegt sind, lautet der Oracle-Datentyp CLOB.
Ein Textfeld wird als NVARCHAR2-Datentyp erstellt, wenn für die Datenbank die Verwendung von Unicode festgelegt ist. (Dies ist die Standardeinstellung für Geodatabases in Oracle.) Wenn die Textfeldgröße auf mehr als 2.000 Zeichen und die Datenbank für die Verwendung der Unicode-Codierung eingestellt ist, lautet der Oracle-Datentyp "NCLOB".
Geometriedatentypen
Wie in der Tabelle angegeben, können von ArcGIS drei Geometriedatentypen in Oracle erstellt und verwendet werden: "ST_Geometry" von Esri, "SDO_Geometry" von Oracle und "Compressed Binary" (komprimierte Binärdaten). Der Geometriespeicher "Compressed Binary" kann nur in Geodatabases verwendet werden.
ST_Geometry
Nachfolgend finden Sie eine allgemeine Beschreibung des räumlichen Datentyps "ST_Geometry". Spezifische Informationen zur Oracle-Implementierung finden Sie unter "ST_Geometry" in Oracle.
Der Datentyp "ST_Geometry" implementiert die SQL 3-Spezifikation benutzerdefinierter Datentypen (UDTs) und ermöglicht es Ihnen, Spalten zu erstellen, die zum Speichern von räumlichen Daten wie der Lage eines Orientierungspunktes, einer Straße oder eines Flurstückes geeignet sind. Er stellt den International Organization for Standards (ISO)- und Open Geospatial Consortium, Inc. (OGC)-kompatiblen SQL-Zugriff (Structured Query Language) auf die Geodatabase und die Datenbank bereit. Dieser Speichertyp erweitert die Funktionen der Datenbank, indem er die Speicherung von Objekten (Punkte, Linien und Polygone) ermöglicht, die geographische Features darstellen. Er wurde für die effiziente Verwendung von Datenbankressourcen, die Kompatibilität mit Datenbank-Features, wie z. B. Replikation und Partitionierung, und den schnellen Zugriff auf räumliche Daten entwickelt.
Eine Spalte kann zwar als Typ "ST_Geometry" definiert werden, es werden jedoch keine ST_Geometry-Werte in die Spalte eingefügt, da sie nicht instanziiert werden kann. Stattdessen werden die Subclass-Werte eingefügt.
"ST_Geometry" selbst ist eine abstrakte, nicht instanziierte übergeordnete Objektklasse. Ihre Subclasses können jedoch instanziiert sein. Bei einem instanziierten Datentyp handelt es sich um einen Datentyp, der als Tabellenspalte definiert werden kann und darin eingefügte Werte seines Typs aufweisen kann.
Im folgenden Diagramm wird die Hierarchie des Datentyps "ST_Geometry-Datentyps" und seiner Subclasses veranschaulicht.
Die Subclasses von "ST_Geometry" sind in zwei Kategorien unterteilt: die Subclasses der Basisgeometrie und die Subclasses der homogenen Sammlung. Die Basisgeometrien umfassen "ST_Point", "ST_LineString" und "ST_Polygon", während die homogenen Sammlungen "ST_MultiPoint", "ST_MultiLineString" und "ST_MultiPolygon" umfassen. Wie der Name schon besagt, handelt es sich bei den homogenen Sammlungen um Sammlungen der Basisgeometrien. Homogene Sammlungen weisen neben den mit der Basisgeometrie gemeinsamen Eigenschaften auch eigene Eigenschaften auf.
Jede Subclass speichert den durch ihren Namen implizierten Geometrietyp: "ST_MultiPoint" speichert beispielsweise Multipoints. In der folgenden Tabelle finden Sie eine Liste mit den Subclasses und die dazugehörigen Beschreibungen:
| Subtype | Beschreibung |
|---|---|
| ST_Point |
|
| ST_LineString |
|
| ST_Polygon |
|
| ST_MultiPoint |
|
| ST_MultiLineString |
|
| ST_MultiPolygon |
|
SDO_Geometry
"SDO_Geometry" wird mit einem erweiterbaren objektrelationalen Typsystem von Oracle implementiert. Der Typ "SDO_Geometry" wird von Oracle mit zwei primären Optionen angeboten:
- Oracle Spatial ist ein optionales Feature der Oracle Database Enterprise Edition. Neben dem Typ "SDO_Geometry" bietet Oracle Spatial eine Reihe von zusätzlichen räumlichen Funktionen.
- Oracle Locator stellt eine Teilmenge der Oracle Spatial-Funktionen bereit. Es ist als Standard-Feature in den Oracle-Database-Editionen Standard und Enterprise enthalten. Neben anderen Funktionen stellt es den Oracle Spatial-Geometrietyp (als SDO_Geometry bezeichnet) und eine SQL-API für diesen Inhalt bereit.
ArcGIS unterstützt "SDO_Geometry" als optionale Methode zum Speichern von räumlichen Daten. Oracle Spatial- oder Locator-Geometrie kann insbesondere zum Speichern und Verwalten des Feature- und Raster-Inhalts von Datasets in Enterprise-Geodatabases oder Oracle-Datenbanken verwendet werden.
"SDO_Geometry" speichert Informationen zu einer Geometrie einschließlich des Geometrietyps, der Raumbezugs-ID, des Interpolationstyps (gerade oder gekrümmt) und der Koordinatenwerte. Der Typ "SDO_Geometry" in Geodatabases unterstützt Singlepart- und Multipart-Punkt-, -Linien- und -Flächen-Geometrie. Geometrien können als eine lineare Interpolation zwischen Koordinaten beschrieben werden, wie durch die OpenGIS Simple Feature Specification definiert ist. Geometrien können auch aus kreisförmigen Kurven oder einer Kombination aus beiden Interpolationsmethoden erstellt werden. Anwendungen sind für das ordnungsgemäße Einfügen, Aktualisieren und das Abrufen des Inhalts des Typs "SDO_Geometry" mit einer objektrelationalen SQL-Schnittstelle von Oracle zuständig. Anwendungen müssen auch sicherstellen, dass der Inhalt jeder Geometrie den in der Oracle Spatial-Dokumentation definierten Regeln entspricht. Oracle stellt Geometrieprüfroutinen bereit, die nach dem Einfügen von Geometrien ausgeführt werden können. Darüber hinaus wird, beginnend mit Oracle 11.1.0.7, Geometrie auf Indexeinfügungen überprüft.
Informationen zu jeder SDO_Geometry-Spalte sollten im Oracle Spatial-Metadatenschema aufgezeichnet werden, obwohl Oracle Spatial dies nicht automatisch macht. (Das Oracle Spatial-Metadatenschema wird für jedes Schema als die Sicht USER_SDO_GEOM_METADATA zur Verfügung gestellt.) Die Software, die SDO_Geometry-Spalten erstellt, muss die Metadaten für diese Spalten einfügen. ArcGIS erledigt dies für alle von diesem Programm erstellten SDO_Geometry-Feature-Classes. Die Metadaten enthalten den Namen der räumlichen Spalte, den Namen und den Besitzer der Tabelle, in der sie sich befinden, die Oracle Spatial-Bezugskennung (SRID), die Anzahl der Dimensionen, den Bereich jeder Dimension und die Koordinatentoleranz.
Räumliche Indizes bieten schnellen Zugriff auf Features auf Grundlage der Position ihrer Geometrie. Für SDO_Geometry sind räumliche R-Baum-Indizes im Allgemeinen die effizientesten und am einfachsten zu erstellenden, und Oracle empfiehlt ihre Verwendung in den meisten Situationen. Oracle Spatial stellt das Dienstprogramm Spatial Index Advisor bereit, um dabei zu helfen, den besten räumlichen Indextyp für eine vorhandene Tabelle zu bestimmen. Schlagen Sie außerdem in den Anweisungen "Oracle Spatial User's Guide and Reference" nach, um ausführliche Informationen zu unterstützten räumlichen Indextypen, wie sie erstellt werden und die Kompromisse zu anderen räumlichen Indexmethoden zu erhalten.
Oracle Spatial erweitert SQL durch räumliche Suchfunktionen für primäre und sekundäre Filterung. Einschließlich der Funktion SDO_FILTER in einer SQL-Abfrage führt sie eine primäre räumliche Suche durch, die den räumlichen Index verwendet. Räumliche Prädikate, wie z. B. SDO_RELATE und SDO_CONTAINS, geben sekundäre Beziehungen zwischen Paaren von SDO_Geometry-Objekten zurück. Oracle Spatial umfasst räumliche Transformationsfunktionen, die die Form eines SDO_Geometry-Wertes ändern. Die Funktion SDO_BUFFER berechnet beispielsweise die Koordinaten eines neuen SDO_Geometry-Objekts als ein Pufferpolygon bei einer gegebenen Entfernung, die die ursprüngliche Geometrie umgibt. Andere räumliche Transformationsfunktionen schließen SDO_DIFFERENCE und SDO_INTERSECTION ein.
Oracle Spatial bietet Zugriff auf eine Reihe von vordefinierten Koordinatenbezugssystemen mit einem SRID-Wert. Der im SDO_Geometry-Objekt gespeicherte SRID-Wert gibt den Koordinatenbezug für die in diesem Objekt gespeicherte Geometrie an. Wenn er nicht NULL ist, ist die SRID im SDO_Geometry-Objekt ein Fremdschlüssel für eine Tabelle, die Details zu jeder SRID enthält. Diese Tabelle ist MDSYS.CS_SRS. Die Funktion SDO_TRANSFORM legt Koordinatenbezugstransformationen mithilfe der Raumbezugs-ID fest. ArcGIS verwendet diese Informationen außerdem zum Erstellen von Raumbezügen.
Compressed Binary
Der Speichertyp "Compressed Binary" von Esri verwendet einen binären Speichermechanismus zum Speichern von Feature-Geometrie. Eine komprimierte binäre Feature-Class besteht aus drei Tabellen: die Business-Tabelle, die Feature-Tabelle und die räumliche Indextabelle.
Nach dem Überprüfen der Geometrie komprimiert die Client-Anwendung diese und sendet sie an die Geodatabase, in der sie im Compressed Binary-Format in einer Feature-Tabelle (oder F-Tabelle) gespeichert wird. Durch das Komprimieren der Geometrie auf dem Client wird der Task vom Datenbankserver entladen und die zum Senden der Geometrie benötigte Übertragungszeit reduziert. Zudem ermöglicht dies das effiziente Speichern und Abrufen räumlicher Daten, da der für die Daten benötigte Speicherplatz um bis zu 40 Prozent reduziert wird.
Die Business-Tabelle enthält Attribute und eine räumliche Spalte. Die räumliche Spalte dient als Schlüssel für die Feature-Tabelle und die räumliche Indextabelle.
Die Beziehung zwischen der Business-Tabelle und der Feature-Tabelle wird durch die gesamte räumliche Spalte und die FID-Spalte (Feature-ID) verwaltet. Dieser Schlüssel, der von ArcGIS verwaltet wird, ist eindeutig.
Raster-Datentypen
Sie können BLOB oder "ST_Raster" für die Raster-Spalten von Raster-Datasets und Mosaik-Datasets verwenden.
In mit einem Konfigurationsschlüsselwort erstellten Raster-Datasets und Mosaik-Datasets, deren Parameter "RASTERCOLUMN" auf "RASTERBLOB" oder "BLOB" gesetzt sind, werden jeweils "BLOB"-Spalten angelegt. Bei Verwendung der Einstellung "RASTERBLOB" wird die BLOB-Spalte direkt in der Business-Tabelle erstellt; bei der Verwendung von BLOB wird die BLOB-Spalte in einer eigenen Tabelle gespeichert. Weitere Informationen zu BLOBs in Oracle finden Sie im Abschnitt BLOB dieses Themas.
Im nächsten Unterabschnitt wird der Datentyp "ST_Raster" beschrieben.
ST_Raster
"ST_Raster" ist ein benutzerdefinierter Datentyp, der in Enterprise-Geodatabases installiert werden kann, um SQL-Zugriff auf Raster-Daten bereitzustellen.
Zur Verwendung von "ST_Raster" müssen Sie diesen Datentyp in der Geodatabase konfigurieren.
Ausführliche Informationen zur Definition des Objekttyps "ST_Raster" finden Sie unter Der ST_Raster-Datentyp.
BLOBs
BLOB ist ein branchenübliches Akronym, das im Zusammenhang mit Datenbankmanagementsystemen (DBMS) für große Binärobjekte (Binary Large Object) verwendet wird. BLOB-Spalten wurden vor mehreren Jahre von Oracle implementiert, um die LONG RAW-Technologie zur Speicherung von Binärdaten zu ersetzen.
Die Architektur des BLOB-Datentyps ist in drei grundlegende Komponenten unterteilt: die BLOB-Spalte, das LOB-Segment und der LOB-Index. In der BLOB-Spalte werde der LOB-Locator (36 Byte) und Binärdaten in der Zeile gespeichert, wenn diese kleiner als 3.965 Byte sind und der Speicher innerhalb der Zeile nicht für die Spalte deaktiviert wurde.
Wenn die Binärdaten 3.964 Byte überschreiten, wird der Speicherplatz innerhalb der Zeile der BLOB-Spalte nicht zugeordnet, und der LOB-Locator verweist auf die im LOB-Segment gespeicherten Binärdaten.
Daher beläuft sich ein Wert, der in einer BLOB-Spalte mit aktiviertem Speicher innerhalb der Zeile gespeichert ist, immer mindestens auf 36 Byte (der dem LOB-Locator zugewiesene Speicherplatz) und kann bis zu 4.000 Byte groß sein (der Speicherplatz, der dem LOB-Locator zugewiesen wurde, zuzüglich dem maximalen Speicherplatz für in der Zeile gespeicherte Binärdaten).
Das LOB-Segment ist in Chunks unterteilt. Chunks müssen ein Vielfaches der Oracle-Datenblockgröße sein. Wenn die Datenblockgröße beispielsweise 8K beträgt, kann das LOB-Segment mit einer minimalen Chunk-Größe von 8K erstellt werden. Beträgt die Länge der Daten, die innerhalb des LOB-Segments gespeichert sind, 5.000 Byte, werden sie im LOB-Segment gespeichert, da sie 3.964 Byte überschreiten, und die Chunk-Größe 8K bzw. 8.192 Byte beträgt. In diesem Fall werden 3.192 Byte des LOB-Segment-Chunks nicht verwendet. Bei der Übertragung von Daten von LONG RAW in BLOB kann aufgrund des nicht belegten Speicherplatzes im LOB-Segment bis zu 30 Prozent mehr Speicherplatz benötigt werden. Dies ist unvermeidlich, wenn die Daten den Schwellenwert für die Speicherung in der Zeile der BLOB-Spalte von 3.964 Byte überschreiten.
Die Chunk-Größe von 8K liefert die beste E/A-Performance, wenn möglichst wenig Speicherplatz verloren geht. Bei einer Chunk-Größe von 16K geht mehr Speicherplatz verloren als bei einer Chunk-Größe von 8K. Daher wird zur Vermeidung von Speicherplatzverluste empfohlen, eine Datenbank mit einer aktuellen Datenblockgröße von 16K mit einer Datenblockgröße von 8K erneut zu erstellen, oder, falls möglich, LOB-Segmente in Tablespaces zu erstellen, die mit einer Blockgröße von 8K erzeugt wurden. Hierzu müssen Sie in Oracle System Global Area (SGA) einen Puffer-Cache mit 8K zuordnen.
Bei Chunk-Größen von 4K und 2K geht am wenigsten Speicherplatz verloren, hierdurch können die höheren E/A-Kosten jedoch nicht kompensiert werden.
Der LOB-Index wird nur verwendet, wenn die Anzahl der im LOB-Locator enthaltenen Chunks 12 überschreitet. Andernfalls werden die ersten 12 Chunks vom LOB-Locator abgedeckt.
Die folgenden drei Abbildungen veranschaulichen die drei möglichen Speicherfälle für Binärdaten in einer BLOB-Spalte. Im ersten Fall werden 3.000 Byte Binärdaten in der Zeile gespeichert, da die Größe mit 3.000 Byte kleiner ist als der Schwellenwert für die Speicherung innerhalb der Zeile von 3.965 Byte. Wenn die Speicherung innerhalb der Zeile für die BLOB-Spalte nicht deaktiviert ist, werden das LOB-Segment und der LOB-Index nicht verwendet. In der Regel führt dies durch die geringere Anzahl von E/A-Vorgängen zu einem schnelleren Abruf der BLOB-Daten, da Oracle nicht auf das LOB-Segment oder den LOB-Index zugreifen muss.
Die nächste Abbildung veranschaulicht den zweiten Fall, in dem die Binärdaten größer als 3.964 Byte sind (in diesem Fall sind die Daten 81.920 Byte groß) und nicht in der Zeile gespeichert werden können. Daher verweist der LOB-Locator auf die Binärdaten, die im LOB-Segment gespeichert sind. Da die Binärdaten weniger als 12 Chunks im LOB-Segment beanspruchen, werden im dem LOB-Locator die zugehörigen Adressen gespeichert. In diesem Fall wird der LOB-Index nicht verwendet.
In der letzten Abbildung sind die Binärdaten so groß (106.496 Byte), dass der LOB-Index benötigt wird. In diesem Fall überschreiten die Binärdaten nicht nur den Speicher innerhalb der Zeile, sie erfordern auch mehr als 12 Chunks im LOB-Segment. Bei Daten dieser Größe verweist der LOB-Locator auf den LOB-Index, um die Position der Chunks innerhalb des SOB-Segments abzurufen. Dieser Fall tritt sehr selten bei Vektordaten ein und kann für Raster-Daten vermieden werden.
Weitere Informationen zum Festlegen von BLOB-Speicher finden Sie unter Konfigurationsparameter für Oracle.