2番目のアイデア(選択用のブール属性を作成する)には多くの利点があります。
(i)ラベル付けが必要なものを明確に文書化し、
(ii)基盤となるデータセットと同じように永続的で移植性があり、
(iii)どのラベルが表示されるかを決定するシンプルで直接的なメカニズムを提供します(別のGISまたはプロットパッケージに移植可能です)。
(iv)これらのラベルの選択と他の変数との間の関係について疑問がある場合に備えて、分析を受け入れることさえできます。
(v)クライアントの選択を簡潔にエンコードすることにより、重複する情報を作成しません。
質問で賢明に示唆されているように、ここではいくつかの一般的なデータベースの構築と管理の原則が機能しています。それらの1つは、一貫性のある情報は、可能であればデータベース内で一意に表す必要があることです。(結合およびリレートを実装するためのキーとして使用される情報は、さまざまなテーブルの対応するレコードを識別する機能によって、複数の場所に表示される必要があります。)この原則には、非正規化を維持しようとした人がいるため、優れた理由があります。リレーショナルデータベースは、証明することができます:あなたは一貫してこの情報を更新したり削除したり追加すること覚えていない場合は、すべての それが表示されているテーブルでは、データベースはすぐに内部的に不整合になります。データベースは破損していて、多くの場合回復不能です。
もう1つの原則は、優れたリレーショナルデータベース設計では、各テーブルが単一の概念的な「エンティティ」、つまりデータがモデル化しているもの、またはそれらの間の関係を表す必要があるということです。クライアントが任意に見える機能の選択を指定すると、それらはテーブル内の行のサブセットを効率的に指定します。数学的には、分離の公理により、これはブールフィールドでフラグを立てることと同じです。したがって、任意のデータベース内のものの意味の「任意」のサブセットは逆に、そのようなフィールドは、任意のサブセット(又は選択)を格納するための良い方法で、ブールフィールドで表されることができます。
さらにもう1つの原則は、GISの基礎となるデータ管理機能を使用して情報を格納することを好むということです。代替案は、その場限りのものですGISの「プロジェクトファイル」内またはその他の独立した方法で情報を格納する機能に基づく方法。この典型的な例は、必要なラベルを手動で選択して配置する方法です。多くの場合、これはすばやく簡単に行えます。問題は、変更が必要な場合、または作業を再現する必要がある場合に必ず発生します。これらの状況のどちらか一方は、実際には避けられません。ラベルを手動で配置することは、RDBMSの外部に非常に楕円形で情報(つまり、機能のどのサブセットにラベルを付ける必要があるか)を保存することと同じです。つまり、どのラベルが表示され、どのラベルが表示されないかによってのみ指定される選択です。次に、これらの後続の問題をどのように解決するかを考えます。
クライアントは、同じラベルを関連するが異なるプロジェクトの一部である異なるマップに表示したいと考えています。
ラベルが他の属性に関連付けられているかどうかという疑問が生じます。
時間の経過とともにラベルにいくつかの変更を加えた後、元のバージョンに戻すように求められます。
このような場合、問題を解決するために必要な作業は膨大なものになる可能性があります。ラベル付けをもう一度やり直すか、データベーステーブルに対して手動でクロスチェックを実行するか、古いアーカイブプロジェクトファイルを見つけて復元する必要があります。代わりに、ラベルがデータベースのブールフィールドで表されている場合、作業はほとんど簡単です。