空間データベースにとって、優れたデータベース設計はそれほど重要ではありませんか？

データベースの設計と正規化は、空間データを扱う際によく使用されると強く感じています。

100を超えるフィールドテーブルを備えたデータベースとデータベースを備えたソフトウェアでは、次の点を確認する必要があります。

空間データベースを設計するときに、正規化以外の考慮事項を考慮する正当な理由はありますか？

私は人々が例を求めていると思いますが、ここでは説明できないので、私の質問は100フィールドが問題ではなく、適切な正規化された設計よりも維持しやすいことを意味する人を対象としています。

引数は何ですか？

空間データベースは、従来のデータベースと同じように扱われるべきだと思います。彼らは本質的に同じことをしていて、高速検索のために大量のデータを保存しています。例として、PostgreSQL / PostGISでは、ジオメトリは単なる別のデータ型です。テキストまたは整数のように。SQL Server 2008でも同じ。Oracleでも同じ。「空間」部分がデータベース内の単なる別のフィールドタイプである場合、それは元のデータベースとは実際にそれと異なりますか？これは、従来のデータベース設計のルールをすべて捨てるべきだということですか？

明らかに、正規化は、従来のデータベースと同様に、あまりにも遠くまで取られる可能性があるため、ニーズに合った最適な設計を見つけることはトレードオフです。

100列のテーブルを持つ非常に非正規化された構造を作成することを計画している場合、今後何が変わる可能性があるかを自問する必要がありますか？行が大幅に増加すると、これはクエリのパフォーマンスにも影響しますか？これは将来、保守性に影響を与えるのでしょうか？

正規化された構造を作成し、ビューを使用してすべてのデータをデータベースクライアント（GISまたは他のクライアント）に公開することの何が問題になっていますか？

これらの質問はすべて、従来のデータベースと空間データベースの両方に当てはまります。あなたが通過する場合http://en.wikipedia.org/wiki/Database_normalizationあなたはそれが同様の空間データベースに適用されることがわかります。

データベースの上で使用しているソフトウェアが高度に非正規化された構造の使用を強制している場合、これは別の引数です。データベースではなくソフトウェアに制約されているため、最適なデータベース設計には選択肢がありません。

簡単な答えは、（私の意見では）データベースの設計は、空間データベースでも従来のデータベースと同じくらい重要だと思います。

これはよく見ます。これは、従来のGISの人々は調査のバックグラウンドから来ており、データベースのバックグラウンド/理解を持っていないという事実に起因すると感じています。しかし、ますます多くの組織がGISインフラストラクチャをIT部門に移行するにつれて、この変化を見ています。

GISソフトウェアレガシー

以前のArcSDEの高コストとSQL Serverの空間データ型の不足（2008年まで）、およびバージョン10までのOracleにより、多くの組織のデータをシェープファイルに格納する以外に選択肢がありませんでした（入札者が入札コストを抑えるため） 。

SQL Serverにネイティブの空間タイプが導入されたことで、ArcSDEは莫大な投資からArcGISに無料で含まれるようになり、組織の空間データの "折り込み"になりました。

ArcGISとSQL Serverを使用している組織には、以前は3つの選択肢がありました。

1. ArcSDEを購入して空間データを「適切な」SQL Serverデータベースに保存するには、2万以上の料金を支払います。
2. 空間データをシェープファイル/個人用GDBに保存し、データベース内の残りの組織データにリンクします（またはこれらの属性をDBFにエクスポートします）
3. GISベンダーを切り替えて、単一のデータベースに空間データを保存します。ただし、新しいGISソフトウェアからのみアクセス可能な形式で保存します

SQL Serverがネイティブの空間タイプを持つと、ほとんどのベンダーは独自の形式ではなくこれを使用しました。つまり、他のアプリケーションが空間データに突然アクセスできることを意味します。ESRIは、ArcSDEをArcGISに統合することでコストを削減するか、空間データをネイティブデータベース形式で保存できるようにする必要がありました。

さらに、空間ビューを作成したり、フィーチャをバックエンドデータベースに簡単にリンクしたりするオプションがなかったため、DBFに関連付けられたシェープファイルに対してArcIMSで実行されるクエリには、すべての必須フィールドと複製を含める必要がありました。

組織上の理由

最近、空間データがネイティブデータベースタイプになるまで、組織内のデータベース管理者によって長い間無視されたり分離されたりしており、GISマネージャーの責任になっていることに他の人も同意します。データベースの設計、正規化、レプリケーション、セキュリティ、およびSQLビューの概念には、非常に異なる特殊なスキルセットが必要になることが多く、習得するにつれて簡単に学ぶことはできません。

コストの理由

データモデルに費やすために多大な時間と労力が必要であることを入札で説明し、このモデルへのデータのクリーニング/インポートはしばしば不可能です。多くの場合、プロジェクトの購入者はGISの分析的観点から来ており、構造化データの重要性を見落としています。

100列のテーブルとは、複数の入力の「マスターカバレッジ」オーバーレイを構築することで得られる出力の種類を意味すると想定しています。はい、これらはArc / INFOワークフローの成果物です。しかし、防御のために、それらはOLAPの意図的に非正規化されたテーブルであると考えることもできます。データの更新ではなく、クエリ処理に主に使用されているため、非正規化形式はある程度意味があります。スタースキーマに似ていますが、ポイントはありません。OK、弱いお茶ですが、それでも何かがあると思います。

はい。新しいGIプロジェクトの設計を開始することが重要であり、将来time = moneyを節約できる場合。 http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916は、なぜそれが重要なのかについての良い概要です。