リレーショナル モデルに基づくジオデータベース格納

DBMS（データベース管理システム）は汎用性のあるシステムと考えることができます。一般的なリレーショナル データ モデルは単純で柔軟性があるために、幅広い数々の DBMS をサポートできるからです。

ジオデータベース格納モデルは DBMS モデルに基づいており、単純でありながら重要なリレーショナル データベースの一連の概念を利用しています。DBMS（およびファイル ジオデータベースのファイル システム）は、テーブルの情報を格納したり操作する際に、単純かつ正式なデータ モデルを提供します。

これには、次の重要な概念が含まれます。

• データは、テーブルに整理されます。
• テーブルには行が含まれます。
• テーブルの行はすべて同じ列を持ちます。
• 各列には、整数、小数、文字、日付などのタイプがあります。
• リレーションシップを使用して、1 つのテーブルの行を別のテーブルの行に関連付けます。各テーブルに共通している列が基準となります。
• テーブルにはリレーションの完全性に関するルールがあります。たとえば、各行は必ず同じ列を共有したり、ドメインには列に対して有効な値や範囲値が指定されるなどのルールがあります。

リレーショナル データベースに格納される ArcSDE ジオデータベースには、他にも数多くの DBMS 機能が適用されます。

• テーブルとそれらのデータ エレメントを操作するために、SQL（Structured Query Language）という一連のリレーショナル関数および演算子が用意されています。
• SQL 演算子は、整数、小数、日付、文字といった汎用性のあるリレーショナル データ タイプを操作できるよう設計されています。

たとえば、フィーチャクラスは DBMS テーブルとして格納されます。行はそれぞれ 1 つのフィーチャを表します。行の列はそれぞれ、フィーチャのさまざまな特徴やプロパティを表します。また、列の 1 つには、フィーチャ ジオメトリ（たとえば、ポイント、ライン、またはポリゴン座標）が格納されます。次の例の場合、シェープ フィールドは、フィーチャクラス テーブルの各パーセル行にポリゴン シェープを格納しています。

DBMS 内のさまざまな列タイプを使用して、テーブルにシェープ フィールドを格納します。通常、これらは、BLOB（Binary Large Object）タイプまたは、一部の DBMS でサポートされる拡張空間タイプのいずれかです。たとえば、ArcSDE がサポートするすべての DBMS（Oracle、IBM DB2、Informix、PostgreSQL、および SQL Server）では、フィーチャを格納する際に 1 つ以上の空間列タイプを使用できます。そのため、SQL（空間タイプを定義している ISO（International Organization for Standardization）や OGC（Open Geospatial Consortium, Inc.）標準に準拠）を使用して、フィーチャにアクセスできるようになります。

SQL は、テーブル内の行、列、およびタイプに対して動作します。列タイプ（数字、文字、日付、BLOB、空間タイプなど）は、SQL 演算におけるオブジェクトです。他のアプリケーション ロジックは、より複雑なオブジェクトの振舞いや完全性の制約を実装するのに対し、DBMS は、これらの単純なデータ タイプおよびテーブルを管理します。

しかし、空間タイプや空間属性の SQL サポートを DBMS に追加されても、それだけでは DBMS で GIS をサポートすることはできません。

リレーショナル DBMS における高度なオブジェクトおよび振舞いの実装

開発者はアプリケーション コードを記述して、高度なオブジェクト、振舞い、およびロジックを実装することができます。たとえば、企業では次のように従業員テーブルを実装できます。

Last Name	First Name	Hire Date	Salary
Brown	Ben	10-10-2001	$10,000.50
Jones	Betty	06-14-1998	$22,000.00
Smith	Jason	08-23-1999	$44,000.75

Employees テーブル

Employees テーブルは、行と列を含んでいる単純なリレーショナル データ テーブルです。各列のデータは、文字、日付、数字などの特定のデータ タイプに準拠しています。DBMS は、このレベルで情報を操作します。

ただし、この情報をただ DBMS テーブルに追加しても、DBMS は、給与または従業員の管理システムになりません。また、2 桁の小数位を持つ数字を格納する Dollars 列を追加しても、DBMS は会計システムになりません。高度なアプリケーション ロジックが必要です。

就業に関する業務のサポートに実装できるロジックの例としては、雇用や、昇給、退職、昇進、および福利厚生の管理の実装などが挙げられます。従業員や、その名前、給料、入社日をモデル化するビジネス オブジェクトはリレーショナル オブジェクトとして実装されません。このようなビジネス オブジェクトに振舞いや完全性を実装するには、より洗練され、特化されたアプリケーション ロジックが必要です。

同様のビジネス オブジェクトは GIS では一般的に適用されます。たとえば、トポロジ、ネットワーク、リニア リファレンス システム、ラスタ カタログ、アノテーション、テレイン、マップ レイヤなどはすべて高度なオブジェクトであり、これらのオブジェクトを使用して、GIS の振舞いを、GIS に格納される単純な空間的な表現の上に実装します。

DBMS アプリケーションと同様、テーブルに空間列タイプがあっても、それだけでは GIS アプリケーションとして十分ではありません。地理情報システムを構築するには、両方のオブジェクト（単純な DBMS リレーショナル列タイプとトポロジなどのジオデータベース アプリケーション オブジェクト）が必要です。

アプリケーション ロジックの実装方法

高度なアプリケーションには、データベース層とは異なるアプリケーション層において、テーブルの行および列タイプを操作する実装が適していることが、多くのデータベース管理システム（DBMS）の実装事例によって示されています。たとえば、広く導入されている CIS（Customer Information System/顧客情報システム）、ERP（Enterprise Resource Planning/企業資源計画）システム、会計パッケージはすべて、高度なアプリケーション ロジックをアプリケーション層で実装しています。それにより、オープン性、拡張性、柔軟性、パフォーマンスの向上およびより充実したツールセットが提供されています。

これらのシステムでは、ユーザはほとんどの操作でアプリケーション ロジックを通じてトランザクションを実行し、SQL（structured query language）を使用するのは一部の（それが適した）操作に限られます。

アプリケーション ロジックはデータ層の上に分離して配置されているので、同じロジックを DBMS、ファイル、XML、その他のデータ格納に適用することもできます。これにより、より柔軟なアーキテクチャが実現されます。たとえば、ArcGIS のジオデータベース アプリケーション ロジックは、その他の多くの空間データ ソース（CAD データ、シェープファイル、MapInfo データ、Intergraph GeoMedia ファイル、Geography Markup Language（GML）ファイルなど）の操作にも使用されます。

この高度なロジックを実装する他の方法としては、ストアド プロシージャおよびデータベース トリガもしくは拡張タイプとして DBMS にロジックを格納する方法があります。