0

プレゼントがあるシステムをモデル化しています。それらのプレゼントは、あなたが提供するプレゼントまたは受け取るプレゼントです。また、これらのプレゼントは、1 つまたは複数の場合があり、最後に、おもちゃ、食べ物、旅行、またはその他のようなタイプにすることもできます。

だから、私は考えました：

Presents --> Toys --> Offer   --> Single
         |        |           --> Multiple
         |        --> Receive --> Single
         |                    --> Multiple
         --> Food --> Offer   --> Single
         |        |           --> Multiple
         |        --> Receive --> ...
         --> Trip --> ..
         --> Other --> ..

これが私のシステムに対する唯一の解決策であることがわかりました。すべての「リーフ」は異なるテーブルに実装されます。これは、すべての「リーフ」が異なるモデルを持つことができるため、場合によってはもう 1 つの属性になるためです。場合によってはそれ以上になります。したがって、Present クラスのモデルは、3 つの要因に応じてその属性が変化する三重継承です。

問題は、私が言いたいことを知っていれば、このソリューションは非常に醜いことがわかったということです。だからこそ、この件について皆さんの意見をお聞きしたいのです。

前もって感謝します。ジョアン

4

2 に答える 2

1

詳細を知らずに推測することしかできませんが、いくつかの仮定を立てます。

  1. 概念があります: プレゼント、おもちゃ、食べ物、旅行、その他、申し出、受け取る、単一、複数。
  2. これらの各概念には、安定した一連の属性があります。
  3. 現在、16 個のテーブルがあり、それぞれが異なる構造になっています。

モデルは、安定した属性のグループごとに 1 つの 10 個のテーブルと、それらをまとめる 1 つのリンク テーブルで記述できます。

リンク テーブルにはスパース列が必要です。つまり、(toys、food、trip、other) の 4 つの参照列のうち 3 つが null になるため、これは正規化されていませんが、データ ウェアハウス スキーマに少し似ています。

ファクト テーブルは次のようになります (列の種類を省略しています)。

gift_id not null, //primary key
present_id not null, // always have one of these
toy_id null, //refers to a row in the toy table
food_id null, // refers to a row in the food table...and so on below
trip_id null,
other_id null,
offer_id null,
receive_id null,
single_id null,
multiple_id null

新しい種類のものが必要になると、このファクト テーブルに追加の列が必要になる可能性があるという点で、まだ少し不快ですが、null 許容の列を追加することは非常に安全です。

于 2012-09-18T14:07:34.680 に答える