1

ワインやその他のアルコール飲料のディーラーのウェブサイトを開発しています。明らかに、各ワインは、ワイン テーブルでモデル化する必要がある国で作られています。しかし多くの場合、ワインには地域 (ラングドック、リオハ、ブーゴーニュなど) もあり、これらの地域はもちろん国と親子関係にあります。次のオプションがあります。

-ワインテーブルに地域への参照のみを与える問題は、一部のワイン/ウイスキーが地域を言及せず、国のみを言及することです

-国と地域のテーブルへの 2 つの個別の FK 参照をワイン テーブルに与えます。これにより、国と地域がすでに関連付けられているため、循環参照と冗長性の問題が発生します。

- Location テーブルと、Wine テーブルから Location テーブルへの単一の FK 参照を使用する。Location テーブルは、実際には地域または国 (場合によっては都市) であるため、フィールド「location_type」と、独自の PK を参照する親 FK フィールドがあります。最上位の国エントリの場合、親 ID は null です。これは私がインターネットのどこかで見つけた例です。ただし、クエリはより複雑になります。

これは既知の問題ですか? 何か提案はありますか? ティア、クラース

4

3 に答える 3

1

このドメインのアプリケーションにも取り組んでいます。ワインによくあることですが、サブリージョンやアペラシオンの概念もあるので、たとえばフランス-ブルゴーニュ-コートドールのワインを飲むことができます。国、地域、および小地域へのFK参照がある、あなたが説明した2番目のオプションを使用しました。国フィールドのみが必要であり、他のフィールドはnull可能です。このモデルでは、参照整合性に関する潜在的な問題が複雑になりますが、これらのフィールドに基づく効果的なクエリが大幅に容易になります。これは、そもそもこの情報を取得するポイントの一種です。

于 2012-04-19T16:22:40.743 に答える
0

厳密なエンティティー関係ではなく、次元分析の観点からこれを見たいと思うかもしれません。つまり、非正規化の but はまさにあなたが探しているものかもしれません。次元データ ウェアハウスに関する Ralph Kimball の本は、この種の問題を解決することが多いため、お勧めします。

あなたの場合、最も低い粒度で、関心のあるすべてのフィールドを含む「場所」ディメンションを作成するだけです。

  • 領域
  • 国
  • サブカントリー

2つの明らかなものです。丘の中腹、都市などもあるかもしれません。

例を挙げると、次の行があります。

  1. バローロ/イタリア/ピエモンテ
  2. NULL/イタリア/ピエモンテ
  3. NULL/イタリア/NULL

ワインはこのテーブルに接続されます。

ここで、このテーブルのメンテナンスの問題があります。しかし、ワインと公式地域の世界はよく知られており、非常にゆっくりと変化しているため、これは問題ではないと思います.

于 2012-04-19T18:09:26.940 に答える
0

場所ディメンションの作成に関する良い点。このタイプのモデルは、より効果的に分析に対応しますが、トランザクション システムの場合はより複雑になります。これは、CRUD タイプのトランザクションを処理するためにモデルを最適化しているのか、それとも集約されたデータ分析のためにモデルを最適化しているのかという問題になります。

全体として、Klaus は、データ ウェアハウスのような分析ベースのアプリケーションではなく、基本的なクエリを使用するトランザクション システムのモデリングを検討していると思います。

于 2012-04-20T23:12:31.520 に答える