データベースにテーブルを作成する、またはテーブルに列を追加するときに、列のデータ タイプを定義します。データ タイプによって次のことが決定します。
- 列に保存できる値
- その列のデータに対して使用できる操作
- 列のデータをデータベースに保存する方法
ArcGIS では、特定のデータ タイプを操作できます。[データベース接続] やクエリ レイヤーからデータベース テーブルにアクセスする場合、ArcGIS はサポートされていないデータ タイプを除外します。ArcGIS にはサポートされていないデータ タイプは表示されないため、ArcGIS からそれらを編集することはできません。同様に、ArcGIS を使用してサポートされていないデータ タイプを含むテーブルをデータベース間でコピーして貼り付ける場合、ArcGIS はサポートされているデータ タイプを使用する列のみを貼り付けます。
次のテーブルの最初の列は ArcGIS データ タイプです。2 番目の列は、ArcGIS が作成する Oracle のデータ タイプです。3 番目の列は、ArcGIS 以外で作成したテーブルを表示するときに、ArcGIS データ タイプにマップされるその他の Oracle のデータ タイプ (存在する場合) を示しています。最後の列には、必要に応じて追加情報が表示されています。
| ArcGIS データ タイプ | 作成された Oracle のデータ タイプ | 表示可能なその他の Oracle のデータ タイプ | 注意事項 |
|---|---|---|---|
BLOB | BLOB | ||
DATE | TIMESTAMP | DATE | |
DOUBLE | NUMBER(38,8) | NUMBER(p,s) | ArcGIS で指定した精度と縮尺が、データベースに作成されるデータ タイプの結果に影響を与える場合があります。詳細については、「ArcGIS フィールド データ タイプ」をご参照ください。 |
FLOAT | NUMBER(38,8) | NUMBER(p,s) | ArcGIS で指定した精度と縮尺が、データベースに作成されるデータ タイプの結果に影響を与える場合があります。詳細については、「ArcGIS フィールド データ タイプ」をご参照ください。 |
GEOMETRY | ST_GEOMETRY, NUMBER(38), or SDO_GEOMETRY | 作成される Oracle データ タイプは、フィーチャクラスを作成したときに指定したジオメトリ格納によって異なります。Compressed Binary または WKB (Well-Known Binary) (ジオデータベースのみ) の場合は NUMBER(38)、Oracle Spatial の場合は SDO_GEOMETRY、Spatial Type の場合は ST_GEOMETRY になります。 ST_Geometry をデータベース (ジオデータベースではない) で使用するには、インストールする必要があります。 | |
GLOBAL ID | CHAR or NCHAR (UUID LEN) | ジオデータベースでのみサポートされています。 テーブルの作成に指定したコンフィグレーション キーワードの UNICODE_STRING パラメーターが TRUE に設定されている場合、一意識別子フィールドは NCHAR として作成されます。 | |
GUID | CHAR or NCHAR (UUID LEN) | テーブルの作成に指定したコンフィグレーション キーワードの UNICODE_STRING パラメーターが TRUE に設定されている場合、一意識別子フィールドはジオデータベースでは NCHAR として作成されます。 | |
LONG INTEGER | NUMBER(38) | NUMBER(n) | 値 n は 5 ～ 10 の範囲内です。ArcGIS Desktop または ArcObjects で作成し、精度を 0 に設定した場合、データベースには NUMBER(38) が作成されます。そうでない場合は、指定した精度が使用されます。 |
OBJECT ID | エンタープライズ ジオデータベースに作成される NUMBER(38) 次の場合に作成される NUMBER(38) (シーケンスとトリガーを使用):
ArcGIS を使用して Oracle 12c データベースにフィーチャクラスまたはテーブルを作成する場合、または [増加 ID フィールドの追加 (Add Incrementing ID Field)] ジオプロセシング ツールを使用して、Oracle 12c データベースのテーブルに ID フィールドを追加する場合、ID として必ず NUMBER(38) が生成されます。 | ArcGIS の ObjectID タイプは、テーブル (またはフィーチャクラス) に登録された RowID 列です。1 つのテーブルにつき、1 つだけ存在します。 | |
RASTER | RASTERBLOB, BLOB, or ST_RASTER | ラスターはジオデータベースのみでサポートされます。ラスター フィールドにどのデータ タイプが使用されるかは、モザイク データセットまたはラスター データセットの作成時に指定するコンフィグレーション キーワードによって変わります。 | |
SHORT INTEGER | NUMBER(5) | NUMBER(n) | 値 n は 1 ～ 5 の範囲内です。ただし、short integer 列に格納できる値は、-32,768 ～ 32,767 の範囲に収まる値だけです。そのため、数値の精度を 5 に設定した場合でも、32,767 を超える数値または -32,768 未満の数値は、short integer 列に格納できません。 ArcGIS Desktop で作成した場合、n = 5 です。したがって、short integer を許容範囲内に収めることができます。 |
TEXT | VARCHAR2、CLOB、NVARCHAR2、NCLOB |
テキスト データ タイプ
ArcGIS を使用して作成したテーブルにテキスト フィールドを含める場合、データセットが Unicode エンコーディングを使用するように設定されていなければ、VARCHAR2 データ タイプが使用されます。テキスト フィールド サイズを 4,000 よりも大きく設定し、データベースが Unicode エンコーディングを使用するように設定されていない場合、Oracle のデータタイプは CLOB になります。
データベースが Unicode エンコーディングを使用するように設定されている場合、テキスト フィールドは NVARCHAR2 として作成されます。これは、Oracle 内のジオデータベースの場合、デフォルトの設定です。テキスト フィールド サイズを 2,000 よりも大きく設定し、データベースが Unicode エンコーディングを使用するように設定されている場合、Oracle のデータタイプは NCLOB になります。
ジオメトリ データ タイプ
表に示すように、ArcGIS は、Esri ST_Geometry、Oracle SDO_Geometry、および Compressed Binary という Oracle の 3 種類のジオメトリ データ タイプでデータを作成および操作できます。Compressed Binary ジオメトリ格納は、ジオデータベースでのみ使用できます。
ST_Geometry
以下では、ST_Geometry 空間データ タイプの概要について説明します。Oracle の実装に固有の情報については、「Oracle の ST_Geometry」をご参照ください。
ST_Geometry データ タイプはユーザー定義データ タイプ (UDT) の SQL 3 Specification を実装しているので、ランドマークの場所、道路、土地区画といった空間データを格納できる列を作成することができます。これは、ジオデータベースおよびデータベースに対して、 ISO/OGC 準拠の SQL アクセスを提供します。このジオメトリ格納は、地理フィーチャを表すオブジェクト (ポイント、ライン、ポリゴン) の格納を提供することで、データベースの機能を拡張します。このジオメトリ格納は、データベースのリソースを効率よく使用し、レプリケーションやパーティションといったデータベースの機能との互換性を維持し、空間データへの素早いアクセスを可能にします。
列を ST_Geometry タイプとして定義することはできますが、インスタンス化することができないため ST_Geometry の値は挿入しません。代わりに、サブクラスの値を挿入します。
ST_Geometry 自体は、インスタンス化されない抽象スーパークラスです。ただし、そのサブクラスはインスタンス化することができます。インスタンス化されたデータ タイプはテーブルの列として定義することができ、その他の値を挿入することができます。
次の図は、ST_Geometry データ タイプとそのサブクラスの階層を示しています。
ST_Geometry のサブクラスは、ベース ジオメトリ サブクラスと同種コレクション サブクラスの 2 つのカテゴリに分類されます。ベース ジオメトリには、ST_Point、ST_LineString、ST_Polygon が含まれ、同種コレクションには、ST_MultiPoint、ST_MultiLineString、ST_MultiPolygon が含まれます。名前が示しているように、同種コレクションはベース ジオメトリのコレクションです。同種コレクションでは、ベース ジオメトリのプロパティを共有することに加えて、独自のプロパティを持つこともできます。
各サブクラスは、その名前が示唆するジオメトリ タイプを格納します。たとえば、ST_MultiPoint はマルチポイントを格納します。以下の表に、サブクラスの一覧とそれらについての説明を示します。
| サブタイプ | 説明 |
|---|---|
| ST_Point |
|
| ST_LineString |
|
| ST_Polygon |
|
| ST_MultiPoint |
|
| ST_MultiLineString |
|
| ST_MultiPolygon |
|
SDO_Geometry
SDO_Geometry は、Oracle の拡張可能なオブジェクト リレーショナル タイプ システムを使用して実装されています。SDO_Geometry タイプは、Oracle から提供されていて、主要な 2 つのオプションがあります。
- Oracle Spatial は、Oracle Database Enterprise Edition のオプション機能です。SDO_Geometry タイプを提供し、追加の地理空間機能も提供します。
- Oracle Locator は、Oracle Spatial の機能のサブセットです。Oracle Locator は、Oracle Database Standard Edition および Enterprise Edition の標準機能として含まれています。特に、Oracle Spatial ジオメトリ タイプ (SDO_Geometry) と Oracle Spatial ジオメトリ タイプに対する SQL API を提供します。
ArcGIS は、空間データのオプションの格納方法として SDO_Geometry をサポートしています。具体的には、Oracle Spatial または Locator ジオメトリを使用して、データセットのフィーチャおよびラスターをエンタープライズ ジオデータベースまたは Oracle データベースに格納し、管理することができます。
SDO_Geometry には、ジオメトリ タイプ、空間参照 ID、補間タイプ (直線と曲線)、座標値を含め、ジオメトリに関する情報が格納されます。ジオデータベースの SDO_Geometry タイプでは、シングルおよびマルチパートのポイント、ライン、エリア ジオメトリがサポートされます。ジオメトリは、OpenGIS Simple Feature Specification によって定義されているように、座標間が線形に補間されたものと説明できます。また、ジオメトリは、円弧または両方の内挿法の組み合わせから作成できます。アプリケーション プログラムは Oracle のオブジェクト リレーショナル SQL インターフェイスを使用して、SDO_Geometry タイプのコンテンツを正しく挿入、更新、取得しなければなりません。また、各ジオメトリのコンテンツを Oracle Spatial ドキュメントに定義されているルールに準拠させる必要もあります。Oracle には、ジオメトリを挿入した後に実行できるジオメトリ整合チェック ルーチンが用意されています。また、Oracle 11.1.0.7 からは、インデックスの挿入においてジオメトリが整合チェックされます。
各 SDO_Geometry 列に関する情報は Oracle Spatial メタデータ スキーマに記録する必要がありますが、Oracle Spatial はこれを自動的に行いません (Oracle Spatial メタデータ スキーマは、USER_SDO_GEOM_METADATA ビューとしてスキーマごとに公開されます)。SDO_Geometry 列を作成するソフトウェアは、それらの列にメタデータを挿入しなければなりません。ArcGIS で作成するすべての SDO_Geometry フィーチャクラスでは、これが自動的に行われます。メタデータには、空間列の名前、空間列が含まれているテーブルの名前とその所有者、Oracle SRID (Spatial Reference Identifier)、ディメンションの数、各ディメンションの範囲、その座標許容値が含まれています。
空間インデックスはフィーチャのジオメトリの位置に基づいて、フィーチャにすばやくアクセスできるようにします。SDO_Geometry の場合は、R ツリー空間インデックスが一般に最も効率的で、最も簡単に作成できます。Oracle では、ほとんどの状況で R ツリー空間インデックスの使用を推奨しています。Oracle Spatial には、特定のテーブルに最適な空間インデックスの種類を決定するのに役立つ、Spatial Index Advisor ユーティリティが用意されています。サポートされている空間インデックスの種類、それらを作成する方法、空間インデックス手法間のトレードオフについては、『Oracle Spatial ユーザーズガイドおよびリファレンス』をご参照ください。
Oracle Spatial は SQL を 1 次フィルタリングと 2 次フィルタリングのための空間検索関数で拡張します。SQL クエリに SDO_FILTER 関数を追加すると、空間インデックスを使用した 1 次空間検索が実行されます。SDO_RELATE や SDO_CONTAINS といった空間述語は、SDO_GEOMETRY オブジェクト ペア間の 2 次リレーションシップを返します。Oracle Spatial には SDO_Geometry 値の形式を変更する空間変換関数があります。たとえば、SDO_BUFFER 関数は新しい SDO_Geometry オブジェクトの座標を、元のジオメトリから特定の距離にあるバッファー ポリゴンとして計算します。その他の空間変換関数には、SDO_DIFFERENCE と SDO_INTERSECTION などがあります。
Oracle Spatial は SRID 値を使用して、定義済みの座標参照系にアクセスします。SRID 値は SDO_Geometry オブジェクトに格納され、そのオブジェクトに格納されたジオメトリの座標参照を指定します。SDO_Geometry オブジェクトの SRID が NULL でなければ、各 SRID の詳細を含んでいるテーブルへの外部キーとなります。このテーブルは MDSYS.CS_SRS です。SDO_TRANSFORM 関数は座標参照変換を確立するために SRID を使用します。ArcGIS もこの情報を使用して空間参照を作成します。
Compressed Binary
Esri Compressed Binary 格納タイプは、バイナリ格納メカニズムを使用してフィーチャ ジオメトリを格納します。Compressed Binary フィーチャクラスは、ビジネス テーブル、フィーチャ テーブル、空間インデックス テーブルという 3 つのテーブルで構成されます。
クライアント アプリケーションはジオメトリを整合チェックした後、ジオメトリ データを圧縮してジオデータベースに送信します。ジオデータベース側では、データは Compressed Binary 形式でフィーチャ テーブル (F テーブル) に格納されます。クライアント側でジオメトリを圧縮すると、データベース サーバーの負荷が軽減され、ジオメトリの送信にかかる時間が短縮されます。データの格納に必要な領域を最大で 40% 削減することで、空間データの効率的な格納と取得が可能になります。
ビジネス テーブルには属性と空間列が含まれています。空間列は、フィーチャ テーブルと空間インデックス テーブルへのキーとなります。
ビジネス テーブルとフィーチャ テーブル間のリレーションシップは、空間列とフィーチャ ID (FID) 列で管理されます。ArcGIS によって管理されるこのキーは一意です。
ラスター データ タイプ
ラスター データセットおよびモザイク データセットのラスター列には、BLOB または ST_Raster を使用できます。
RASTERBLOB または BLOB に設定されている RASTERCOLUMN パラメーターを含むコンフィグレーション キーワードを使用して作成されているラスター データセットおよびモザイク データセットはいずれも、BLOB 列を作成します。RASTERBLOB 設定を使用すると、ビジネス テーブルに直接 BLOB が作成されます。BLOB を使用すると、サイド テーブルに BLOB 列が作成されます。Oracle の BLOB の詳細については、このトピックの「BLOB」のセクションをご参照ください。
次のサブセクションでは、ST_Raster データ タイプについて説明します。
ST_Raster
ST_Raster は、エンタープライズ ジオデータベースにインストールしてラスター データへの SQL アクセスを提供できるユーザー定義データ タイプです。
ST_Raster を使用するには、ジオデータベースで構成する必要があります。
ST_Raster オブジェクト タイプの定義方法の詳細については、「ST_Raster データ タイプ」をご参照ください。
BLOB
BLOB は Binary Large Object の略語で、DBMS (データベース管理システム) で使用されます。BLOB 列は、LONG RAW テクノロジに代わりバイナリ データを格納する技術として数年前に Oracle 社によって導入されました。
BLOB データ タイプのアーキテクチャは、BLOB 列、LOB セグメント、および LOB インデックスの 3 つの基本要素に分けられます。もしデータが 3,965 バイト未満で、この列におけるインライン格納が無効になっていない場合は、BLOB 列は LOB ロケーター (36 バイト) とバイナリ データを行内に格納します。
バイナリ データが 3,964 バイトを超えている場合は、BLOB 列のインライン格納領域は割り当てられず、LOB ロケーターは LOB セグメントに格納されたバイナリ データを参照します。
つまり、インライン格納が有効な BLOB 列に格納される値は常に 36 バイト以上 (LOB ロケーターに割り当てられる領域) となり、最大でも約 4,000 バイト (LOB ロケーターに割り当てられる領域と、インライン格納されるバイナリ データに割り当て可能な最大領域を結合した領域) になります。
LOB セグメントはチャンクに分割されます。チャンクは Oracle データ ブロック サイズの倍数にする必要があります。たとえば、データ ブロック サイズが 8K の場合、LOB セグメントは最小チャンク サイズを 8K として作成できます。LOB セグメント内に格納されるデータ長が 5,000 バイトの場合、このデータは 3,964 バイトを超えているため、データは LOB セグメントに格納され、チャンク サイズは 8K つまり 8,192 バイトとなります。このケースでは、LOB セグメント チャンクの 3,192 バイトが未使用のままになります。LONG RAW から BLOB へデータを変換すると、LOB セグメントに存在するこの未使用領域のために、必要な格納領域がさらに増加 (最大で 30%) する場合があります。データが BLOB 列のインライン格納閾値である 3,964 バイトを超える場合、この問題は避けられません。
8K チャンク サイズは I/O のベスト パフォーマンスを実現すると同時に、未使用のデータ格納領域を最小限に抑えることができます。16K チャンク サイズの場合は、8K チャンク サイズよりも多くの領域が未使用のままになる可能性があります。このため、領域の損失を避けるためには、現在は 16K のデータ ブロック サイズであるデータベースを 8K のデータ ブロック サイズで再度作成するか、それが不可能な場合は、すでに作成されている表領域に 8K のブロック サイズで LOB セグメントを作成します。これを実行するには、Oracle SGA (System Global Area) に 8K のバッファー キャッシュを割り当てる必要があります。
4K および 2K のチャンク サイズでは未使用となるデータ格納領域がさらに少なくなりますが、I/O に与える影響が大きくなるため、これらのサイズの使用はお勧めしません。
LOB インデックスは、LOB ロケーターで指定されるチャンクの数が 12 を超えた場合のみ使用されます。それ以外の場合は、最初の 12 個のチャンクが LOB ロケーターによって指定されます。
次の 3 つの図は、BLOB 列に格納されるバイナリ データの 3 つのケースを表しています。1 番目のケースでは、バイナリ データがインライン格納閾値である 3,965 バイトを下回っている (この場合は 3,000 バイト) ため、バイナリ データがインライン格納されています。インライン格納が BLOB 列で無効になっていない場合、LOB セグメントと LOB インデックスは使用されません。一般に、この場合は I/O 操作の数が減るため BLOB データのフェッチが速くなります。Oracle が LOB セグメントまたは LOB インデックスにアクセスする必要がないためです。
次の図は 2 番目のケースを示しています。このケースではバイナリ データが 3,964 バイトを超えている (この場合は 81,920 バイト) ため、インライン格納できません。このため、LOB ロケーターは LOB セグメントに格納されているバイナリ データを参照します。LOB セグメント内のバイナリ データのチャンクは 12 個を超えないため、LOB ロケーターがそのアドレスを格納します。このケースでは、LOB インデックスは使用されません。
3 番目の図では、バイナリ データが大容量 (106,496 バイト) であるため、LOB インデックスが必要です。このケースでは、バイナリ データはインライン格納サイズを超えており、格納するにはさらに LOB セグメント内に 12 個を超えるチャンクが必要になります。データがこれほど大容量な場合は、LOB ロケーターが LOB インデックスを参照して LOB セグメント内のチャンクの場所を特定します。このケースはベクター データでは非常にまれであり、ラスター データでも避けることは可能です。
BLOB 格納の設定の詳細については、「Oracle のコンフィグレーション パラメーター」をご参照ください。