1

概念エンティティの 2 つのセットがあるとします。

  • 複数のForwardPriceEntriesを持つMarketPriceDataSet
  • 複数のPoolPriceForecastEntryを持つPoolPriceForecastDataSet

両方の異なる子オブジェクトには、ほぼ同じフィールドがあります。

ForwardPriceEntry は

  • 開始日
  • 終了日
  • SimulationItemId
  • 前売り価格
  • MarketPriceDataSetId (親テーブルへの外部キー)

PoolPriceForecastEntry には

  • 開始日
  • 終了日
  • SimulationItemId
  • 予測プール価格
  • PoolPriceForecastDataSetId (親テーブルへの外部キー)

それらを個別のテーブルとしてモデル化した場合、唯一の違いは外部キーと価格フィールドの名前です。

ほぼ同一の 2 つのテーブルを 1 つにマージする必要があるかどうかについては、議論がありました。

これをモデル化するために私が考えたオプションは次のとおりです。

  • それらを2つの独立した別々のテーブルとして保持するだけです
  • 追加の「タイプ」フィールドと、いずれかの親テーブルへの外部キーに等しいparent_idを使用して、1つのテーブルに両方のセットを配置します。これにより、参照整合性チェックが犠牲になります。
  • 追加の「タイプ」フィールドを使用して 1 つのテーブルに両方のセットを配置し、テーブルを結合する複雑なシーケンスを作成して、参照整合性を維持します。

私は何をすべきだと思いますか、なぜですか？

関連する場合と関連しない場合があるその他の情報:

  • 2 つのデータ セットは大まかに関連しています。それぞれの 1 つのセットがバッチ処理のためにメモリに読み込まれ、場合によっては ForwardPriceEntries からコピーすることによって PoolPriceForecastEntries のセットが生成されます。

  • MarketPriceDataSetとPoolPriceForecastDataSetには異なるフィールドがあります。それらを 1 つのテーブルにマージすることは可能ですが、エントリの半分に意味のないフィールドが含まれることになります。

4

4 に答える 4

3

Very often, in the situation you described, the subject being modeled fits a pattern called "generalization specialization". The fact that two prior answers discuss subtypes supports this. An object model tends to deal with gen-spec by using subtypes and inheritance.

The relational model can also deal with gen-spec, but it's a little more intricate and is not usally taught in database primers. What you do is have several tables, one for each subtype, holding a key and non key attributes that are peculiar to the subtype. Data that is relevant to the supertype, and inherited by all the subtypes, is generally consolidated into a single table.

There is a trick you can play with the keys to these tables that cuts down on both storage and processing. In the subtype tables, use the foreign key back to the supertype entry as the primary key to the subtype table. It's guaranteed to exist, and it's guaranteed to be unique. Why bother to invent yet another key?

If you search on "generalization specialization relational modeling" you'll get about a dozen articles on the subject. some of them are quite good. You can also follow the tag:

于 2010-03-19T12:38:47.803 に答える
3

「2 つのほぼ同一のテーブルを 1 つに統合するかどうかについては、議論がありました。」

ありますか？

データベースの設計では、述語が異なる場合、テーブルは分離したままにする必要があります。つまり、テーブル内の行に付けられた意味が異なる場合です。列のセットがほぼ等しいか完全に等しいかは重要ではありません。

于 2010-03-19T19:43:09.113 に答える
1

エンティティは非常に多くの属性を共有しているため、サブタイプと考えることができます。

論理的には、PriceEntry のスーパータイプと、ForwardPriceEntry および PoolPriceForecastEntry のサブタイプがあります。答えるべき質問の 1 つは、価格がスーパータイプに共通であるかどうかです。だと思います。

問題は、サブタイプを物理的に実装する方法です。次の 3 つの方法があります。

  1. サブタイプごとにテーブルを作成する (ロールダウン)
  2. すべての属性を含む 1 つのテーブルを作成する (ロールアップ)
  3. 各サブタイプ (ID) に対して 1 つのスーパータイプ テーブルとサブタイプ テーブルを作成します。

これらのアプローチにはそれぞれ長所と短所があります。各アプローチの長所と短所の説明については、サブタイプを使用した物理的な取得 を参照してください。

この場合、サブタイプは非常に多くの属性を共有するため、ロールアップ アプローチを使用して 1 つのテーブルを作成できます。

PriceEntry テーブルは次のようになります。

PriceEntryId (PK)
PriceEntryTypeCode (NN)
StartDate (NN)
EndDate 
SimulationItemId (NN)
Price (NN)
MarketPriceDataSetId (FK)
PoolPriceForecastDataSetId (FK)

MarketPrice 列と PoolForecast 列に FK を引き続き適用できます。また、テーブル レベルのチェック制約を追加して、少なくとも 1 つの FK が入力されるようにすることもできます。


ただし、2 つのサブタイプ間で異なる属性は 1 つだけであるため、長所と短所の多くは 1 つの方向を強く指しているわけではありません。したがって、最終的には、データ モデルを理解しやすく使いやすいものにすることを選択するでしょう。私にとって、2 つのテーブル (ロールダウン) アプローチはバランスが取れています。概念的には、ロールアップよりも理解しやすく、開発時には ID よりも使いやすい (結合や複数の挿入/更新がない)。

于 2010-03-19T06:27:52.983 に答える
0

2 つのサブタイプのデータをほぼ同じ方法で使用する場合は、5 つのフィールドすべてを格納する単一のテーブルにすべてのデータを配置することをお勧めします...

  • 開始日
  • 終了日
  • SimulationItemId
  • 前売り価格
  • MarketPriceDataSetId (親テーブルへの外部キー)

...そして、特定の行がサポートしている親エンティティを保留するForwardPriceまたはForecastPoolPricedependingフィールドにnullを配置します。各行の null のスペース コストは事実上存在せず、テーブルでの圧縮の成功率は非常に高くなりますが、インデックス作成と読み取りのパフォーマンスは印象的です。

于 2010-03-19T03:48:12.980 に答える