0

Web アプリケーションでは、さまざまな種類のエンティティをさまざまな種類の階層データにマップする機能が必要です。例として、 Vendorというエンティティーを考えてみましょう。ベンダーの各インスタンスを地理的エリアにマッピングする機能が必要です。地理的領域は、次の階層にあります。

  1. 郵便番号 - 最も詳細な地理的領域。例、EC2
  2. 地域性 - 郵便番号で形成されます。たとえば、ケンジントン。各郵便番号は、正確に 1 つの地域の一部になります。
  3. 町 - 地域で形成されます。たとえばロンドン。各地域は、正確に 1 つの町の一部になります。
  4. 地区 - 町で形成されます。たとえば、コロンビア。
  5. 州 - 地区で形成されます (一部の国では州に相当)。たとえば、サウスカロライナ州。
  6. 地域 - 州で形成されます。たとえば、東北地方。
  7. 国 - 地域で形成されます。
  8. ゾーン - 国で形成されます。例えば東南アジア。
  9. 大陸 - ゾーンで形成されます。

郵便番号、地域、町、地区、州、地域、国、ゾーン、大陸の完全なデータベースがあります。これは現在、RDBMS のテーブルとして存在します。

ユースケース:

  1. 任意のレベルでベンダーを複数の地域に関連付ける機能。たとえば、ネスレをヨーロッパ本土(ゾーン)、カリフォルニア(米国の州)、グレーター ロンドン(英国の地区) にマッピングできます。
  2. 地理の一部をマッピングから除外する機能。たとえば、NestleをCaliforniaにマッピングする場合、 San Diegoを除外したい場合があります。
  3. 地理の構成が変更された場合、地理が一部であるマッピングに変更を加える必要はありません。たとえば、郵便番号がGreater Londonに追加された場合、 Nestleとのマッピングを変更する必要はありません。
  4. ベンダーおよび地理レベルのデータベースを照会する機能。たとえば、ネスレと郵便番号のデータベースをクエリすると、カリフォルニア州ロンドン(サンディエゴの郵便番号を除く) とヨーロッパ本土のすべての郵便番号を取得する必要があります。データベースにNestleとcountriesを照会すると、 UK (グレーター ロンドンの場合はcountry )、US 、およびヨーロッパ本土のすべての国が取得されます。

さまざまな種類の階層データを使用したこのようなマッピングは多数ありますが、これは要件の 1 つにすぎません。

階層データとマッピングの保存に関する提案を探しています。RDBMSを使用するオプションについてはすでに認識しているため、RDBMSテーブルにデータとマッピングを保存することを含む回答を投稿しないでください。

4

1 に答える 1

2

「RDBMSのオプションを知っている」ので、RDBMSソリューションを探していないことは知っていますが、検討したオプションとそれらを拒否する理由については述べていません。データのメンテナンスが少なく、データの取得が簡単であるという利点がある、考慮していないRDBMSオプションがあるかもしれません。

地理的な地域を、複雑な関係を持つ単一のテーブルにグループ化することをお勧めします（隣接モデル）。これにより、ベンダーカバレッジを地理的なカバレッジレコードのリストとして説明できます。秘訣は、ベンダーのカバレッジを可能な限り高いレベルで記録することです。次に、カバレッジの除外を一覧表示することもできます。

推奨される論理モデルは次のとおりです。

論理ERD

GEOGRAPHYテーブルはネストされたセットを使用して、階層的な地理データのクエリを簡素化できます。

COVERAGE特定の領域のベンダーカバレッジを決定することは、ベンダーが関心のGEOGRAPHYあるもの（おそらく最低レベル）を持っていることを確認するのと同じくらい簡単COVERAGE EXCLUSIONですが、同じものには入っていませんGEOGRAPHY。

于 2012-05-09T11:29:58.187 に答える