1

私の簡単な例はこれです。私は映画テーブルを持っており、映画には監督と俳優がいます。私のデータベースでは、映画には 1 人以上の監督と 1 人以上の俳優を含めることができます。また、人の情報を持つテーブル Persons があります。そのため、人は映画でさまざまな役割を持つことができます。可能な役割を持つ他のテーブル、テーブル Roles があります。

多くの場合、映画の監督や俳優を知りたいので、主に 2 つの方法でテーブルを決定します。

最初のオプション: 三項関係:

Movies(IDMovie, ...)
Persons(IDPerson, ...)
Roles(IDRol,...)
MoviesPersons(IDMovie, IDPerson, IDRol...)

この場合、三項関係を使用します。

2 番目のオプションは次のとおりです。

MoviesDirectors(IDMovie, IDPerson,...)
MoviesActors(IDMovie, IDPerson,...)

この場合、関係テーブルからロールを推測できます。

最良の選択肢はどれですか?

ありがとう。

編集: 2 つの二項関係のオプションを使用する場合、将来、サウンドトラックの作曲者が必要な場合は、新しいテーブルと関係を作成する必要がありますが、三項関係を使用する必要はありません。何もせず、ロール テーブルに新しいロールを追加するだけです。

パフォーマンスでは、1 つの三項関係ではなく 2 つの二項関係の方が優れていますか?

ありがとう。

4

1 に答える 1

1

最良の選択肢はどれですか?

あなたは自分自身の質問にほぼ答えました.データベースの構造を変更せずに将来新しいロールを追加する柔軟性が必要な場合は、三項関係が最適です.

それぞれに異なるフィールドまたは制約が必要な場合は、個別のバイナリ関係を検討します（説明からはそうではないようです）。

パフォーマンスでは、1 つの三項関係ではなく 2 つの二項関係の方が優れていますか?

3 項関係を表すテーブルはロール識別子を物理的に格納する必要があるため (ロールがテーブル名自体から推測される 2 項関係とは対照的に)、キャッシュの使用量はわずかに悪くなります。

ただし、複合 PK 内のフィールドを慎重に順序付けすることで、特定の種類のクエリに三項関係をより適したものにすることができます。たとえば、PK:{IDMovie, IDRol, IDPerson}は次のクエリを効率的にサポートできます。

  • 与えられた映画に携わったのは誰ですか? （バツ）
  • 特定の映画で特定の役割を果たしたのは誰ですか?

にインデックスを作成すると、次の{IDPerson, IDRol, IDMovie}クエリも効率的に実行できます。

  • この人が関わった映画は? （バツ）
  • 与えられた人が与えられた役割で取り組んだ映画は?

(X)別個のバイナリ リレーションシップを使用すると、各ジャンクション テーブルに対してクエリを実行する必要があります。これは確かに 2 つのテーブルだけの問題ではありませんが、テーブルの数が増えると (確かにメンテナンスやパフォーマンスの点からも) 1 つになる可能性があります。

于 2013-04-21T17:30:55.093 に答える