3

次の例に示すように、is-a 関係を表す明確な方法があるかどうか疑問に思っていました。

このDBには、映画、ゲーム番組、ドラマの3種類の番組の録画時間が格納されています。オブジェクト指向の意味では、これらのそれぞれがプログラムです。これらのサブクラスには、それぞれ異なるプロパティがあります。テーブルは次のとおりです (fk プレフィックスは外部キーを示します)。

ムービー
ID
名
fkDirector

gameShow
ID
名
fkHost
fkContestant

ドラマ
ID
名

OO 用語では、レコード テーブルは次のようになります。

record
id
fkProgram
startTime
endTime

通常の形式に違反せずにこれを行う唯一の方法は、 recordMovie、recordGameShow、およびrecordDramaという 3 つのレコード テーブルを用意することです。

データベースの正規化の原則に違反することなく、これらのテーブルを 1 つに統合する方法はありますか?

アイデアを説明するために、いくつかの動作しない例を次に示します。

番組
ID
fkMovie
fkGameShow
fkDrama

このテーブルには null が含まれるため、第 1 正規形に違反します。行ごとに、3 つのエントリのうちの 1 つだけが非 null になります。

program
id
fkSpecific ← fkMovie または fkGameShow または fkDrama
fkType ← 調べるテーブルを示します

ここでは、fkSpecific が 3 つのテーブルのいずれかを指す可能性があるため、参照整合性を強制することはできません。

ここにテーブルを 1 つではなく 3 つ持つことによるオーバーヘッドを節約しようとしています。おそらく、これは単に RDB には当てはまりません。

4

6 に答える 6

2

はい、それは次のような1つのテーブルでなければなりません

Programs:
   id,
   name,
   type_id,
   length,
   etc...

タイプに関連付けられた他のビットのデータがある場合は、プログラムのタイプの参照テーブルを使用します。

ProgramType
   type_id,
   type_name,
   etc...

そのように。

于 2008-09-24T21:55:59.687 に答える
2

すべてのデータを 1 つのテーブルに格納する必要があるのはなぜですか? それらは明らかに異なるエンティティです。補助のrecordMovie、recordGameShow、およびRecordDramaを使用した、メインのRecordテーブルのアイデア。

補助テーブルとメイン テーブルの間に「is-a」関係を適用するには、これらすべてのテーブルで Record.id を外部キーとして宣言し、一意になるように制約を追加する必要があります。これらのテーブルをメインのテーブルの拡張に変換する 1 対 1 の関係。

また、レコードの種類 (映画、ゲーム番組、ドラマなど) を示すために、メインの Record テーブルに新しいフィールドを追加する必要があります。これは、さらに別のテーブルへの外部キー参照 (RecordTypes?) または文字列 (受け入れることができる値に対して定義された制約付き) のいずれかです。

于 2008-09-24T23:02:06.830 に答える
2

「一般化専門化リレーショナル モデリング」で Google 検索を行います。

「gen-spec」モデルは、「is-a」関係と同じパターンに従います。

たとえば、自動車は特殊車両です。トラックは別の種類の特殊車両です。オートバイは、特殊車両の 3 番目の種類です。

たくさんの記事が見つかるはずです。

興味深いことに、「gen-spec」で Google 検索を行うと、トップ リンクの 1 つが Smalltalk での gen-spec モデリングの説明へのリンクになります。

于 2009-02-08T05:44:35.997 に答える
1

これは、これまで多くの人が直面していた非常に標準的な問題であり、考えられるすべてのアプローチは、おそらく一度は行われたことがあるでしょう。

Google で簡単に検索すると、それぞれの長所と短所についてかなり適切な説明が得られます。

于 2008-09-24T21:57:33.180 に答える
0

これらは両方とも、この主題に関する優れた記事です:
http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/
http://www.agiledata.org/essays/mappingObjects.html

これが私がやることになることです。私のプログラムテーブルは次のようになります。

プログラム
ID

次に、各サブクラス (drama、gameshow、および movie) に fkProgram を追加します。このようにして、Program テーブルはサブクラス間の中間テーブルになります。Program テーブルへの外部キーを使用して、任意のサブクラスのインスタンスを参照できます。これにより、通常のフォームに違反することなく、単一のレコード テーブルを持つことができます。

映画
ID fk 番組 名
fkDirector


レコード
ID
fkProgram
startTime
endTime

于 2008-09-25T14:43:47.893 に答える
0

私の最初のアイデアは、映画、ショー、ドラマに 1 つのプログラム テーブルを使用することでもありました。次に、ProgramType テーブルを追加し、親投稿と同じように外部キーを使用します。

fkDirector、fkMovie などの他の列を追加できます。次に、ProgramType が映画の場合は fkDirector を null にできない、または番組の場合は fkHost を null にできないという制約を追加します。

これにより、開始日と終了日の間に記録されたすべての映画/番組/... を簡単に検索できます。また、すべてのデータが入力され、参照が正しいことを確認してください。

誰でも良いアイデアがありますか？

于 2008-09-24T22:07:04.777 に答える