リレーションシップクラスを使用するかしないか？

大量のデータから政府のデータベースを構築しています。現在、私はESRI Local Governmentデータモデルの標準的なアプローチに従っていますが、特定の政府のニーズや要望に合わせて修正しています。

地方自治体のデータモデルでは、ESRIが多くの関係クラスを使用していることに気付きました。私は過去にリレーションシップクラスを使用しましたが、それらを避ける傾向があります。これは、通常、フィーチャクラスとは別のテーブルにあるシェイプに関する属性が必要な理由がわからないためです。

私が集めているほとんどすべてのデータについて、この理由はまだわかりません。Parcel Fabricの場合、役立つ理由がいくつかわかりますが、それでも属性をフィーチャクラスに直接保持することが最善だと考えています。

明確にするために、リレーションシップクラスを使用して、フィーチャクラスをフィーチャクラスに参照します。この質問は、フィーチャクラスに簡単に格納できる非空間テーブルにデータを格納する理由をより具体的に示しています。

とにかくあらゆる入力の人々に感謝します！

人々が別々のテーブルにデータを整理する理由は、データベースの正規化の原則によるものです（リンクをたどると、すべての根拠があります）。とはいえ、ESRI Relationship Classesは、これらの原則をGeoDatabaseレベルで実装したものです。正直なところ、私は個人的には2つの場合にのみ使用します。

• DBで正規化されたデータがあり、ArcMap編集ツールを活用したい場合。ArcMapを使用すると、ツール内の関係を（ほぼ間違いなく）簡単にたどることができます。

• GeoDatabaseメッセージングを必要とするGeoDatabase抽象化を使用している場合（例：フィーチャリンクアノテーション、カスタムフィーチャクラスなど）。

人々は参照整合性が利点の1つであると主張するかもしれませんが、真実はSQLプロンプトで回避できるということです。編集する人と行う人も、SQLクエリまたは非Esriツールで編集します）。

全体像を考えてみてください-GISデータは、特に政府機関に関しては、ほとんどの人にとって目的の手段にすぎません。私の経験では、リレーションシップクラスは、特に外部ソースからの変更や絶えず変化する場合に、非空間データを1つ：多くのリレーションシップで空間データに組み込む必要がある場合に有用です（適切です）。私が政府機関で遭遇したいくつかの実世界の例は、これを説明するのを助けるかもしれません：

• フィーチャに関する複数の非空間レコードを保存します（たとえば、給水栓またはバルブの月次検査レコード）
• 管理していないデータソースの関連レコードを参照する（サードパーティの資産管理プログラムのデータベースからメンテナンスレコードを読み取るなど）