2012-05-09 16 views
0

Webアプリケーションのさまざまなタイプの階層データにさまざまな種類のエンティティをマップする機能が必要です。一例として、ベンダと呼ばれるエンティティを考えます。ベンダーの各インスタンスを地理的エリアにマッピングする能力が必要です。地理的エリアは次の階層にあります。階層データを格納するための可能なオプション

  1. 郵便番号 - 最も細かい地域です。例、EC2
  2. 地域 - ポストコードで形成されています。例、ケンジントンそれぞれのポストコードは正確に1つの地域の一部になります。
  3. 町は地方で構成されています。ロンドンの例。それぞれの地域はちょうど1つの町の一部になります。
  4. 地区 - 町から成っています。例、コロンビア。
  5. 州 - 州によって構成されます(一部の国では州に相当)。例えば、サウスカロライナ州。
  6. 地域 - 地方で構成されています。例えば、東北地方。
  7. 国 - 地域で構成されます。
  8. ゾーン - 国で構成されます。東南アジアの例。
  9. 大陸 - ゾーンで形成されます。

私たちは、郵便番号、地方、町、地区、地方、地域、国、ゾーン、大陸の完全なデータベースを持っています。これは現在、RDBMSのテーブルとして存在します。

当社の使用事例:任意のレベルで、複数の地域でベンダーを関連付ける

  1. 能力。例えば、我々は本土ヨーロッパ(ゾーン)、カリフォルニア(米国の州)とグレーターロンドン(UKで地区)にネスレをマッピングすることができます。
  2. マッピングから地理の一部を除外する能力。たとえば、Nestleカリフォルニアにマッピングする場合、サンディエゴを除外したい場合があります。
  3. 地理の構成が変更された場合、その地理が一部であるマッピングに変更を加える必要はありません。たとえば、グレーターロンドンに郵便番号が追加された場合、Nestleのマッピングに変更を加える必要はありません。
  4. ベンダーと地理レベルのデータベースを照会する能力。我々はネスレポストコード用のデータベースを照会場合たとえば、私たちはと本土ヨーロッパグレーターロンドンカリフォルニアサンディエゴマイナスポストコード)のためのすべてのPOSTコードを取得する必要があります。我々はネスレをデータベースに照会した場合、当社は、米国本土ヨーロッパのすべての国(グレーターロンドンのために国)英国を取得する必要があります。

多くの異なるタイプの階層データを持つマッピングが多数ありますが、これは要件の1つに過ぎません。

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

+0

データベースソリューションを探していない場合は、この質問にdatabase-designというタグを付ける必要がありますか? –

+0

私はRDBMSベースのソリューションを探していません。 Neo4j、RedisなどのNoSQLデータベースや階層データベースを含む他のデータベースソリューションがあります。 – manish

+0

十分に公正な:-) –

答えて

2

"RDBMSのオプションを知っている"ので、あなたはRDBMSソリューションを探しているわけではないことを知っていますが、あなたがどのようなオプションを検討したのか、なぜ却下するのかは述べていません。私は、あなたが考慮していないRDBMSオプションがあるかもしれないと信じています。これは、低いデータ保守とデータ検索の容易さという利点があります。

地理的な領域を、インボリュート関係(adjacency model)の1つのテーブルにグループ化することをお勧めします。これにより、ベンダーカバレッジを地理的カバレッジレコードのリストとして記述することができます。このトリックは、可能な限り高いレベルでベンダーのカバレッジを記録することです。また、カバレッジに除外項目をリストすることもできます。 GEOGRAPHY表は、階層地理データのクエリを簡素化するためにnested setsを使用することができ

Logical ERD

:ここ

が示唆論理モデルです。特定の領域の

決定ベンダーカバレッジはまた、同じGEOGRAPHYためCOVERAGE EXCLUSIONにないながらベンダーが(おそらく最も低いレベルで)関心のGEOGRAPHYためCOVERAGEを有していることを確認するのと同じくらい簡単であろう。

関連する問題