0

私はアーティストと曲をモデル化しようとしていますが、多くのアーティスト (デュエットなど) が Song_Performance を実行できるという問題があるため、曲の実行者を表す Artist_Group があります。

これで、Artist と Artist_Group の間に多対多の関係ができました。ここで、Artist_Group は、そのグループ内のアーティストのコレクションによって一意に識別されます。Artist_Group へのアーティストの参加を表す交差エンティティを作成できます (Artist_Group_Participation?)

同じアーティストのセットが同じグループを表すという事実を保持する Artist_Group エンティティの主キーを作成する方法がわかりません。Artist_Group エンティティの主キーがないということは、 Artist_Group_Participation エンティティの外部キー。

John Carlis と Joseph Maguire による本「Mastering Data Modeling」では、この形状について言及し、「Many-Many Collection Entity」と呼んでおり、非常にまれであると述べていますが、解決方法については述べていません。 -to-many の関係は、RDBMS に直接格納することはできません。これを表現するにはどうすればよいですか？

編集：

誰もが交差テーブルを提案しているように見えますが、それは私の問題ではありません。私は持っています。私の問題は、Artist_Group エントリに含まれるアーティストのグループが既存のグループと同じである場合、順序を無視して、Artist_Group エントリを追加できないという制約を適用することです。Artist_Group の ID を、それを構成するさまざまなアーティストの連結である varchar にすることを考えました。これにより、順序が重要な場合は問題が解決しますが、「エルトン ジョンとビリー ジョエル」の Artist_Group を使用しても追加は妨げられません。 「ビリー・ジョエルとエルトン・ジョン」のグループ。

4

5 に答える 5

1

各アーティストの ID をビットフィールドのビットに対応させることができます。したがって、エルトン ジョンが ID 12 でビリー ジョエルが ID 123 の場合、エルトン ジョンとビリー ジョエルのデュエットによって形成された「グループ」はArtist_GroupID 10633823966279326983230456482242760704 です (つまり、12 番目と 123 番目のビットが設定されています)。

交点テーブルを使用して関係を強化できます。たとえばCHECK、PostgreSQL で制約を使用すると、次のようになります。

CREATE TABLE Artist_Group_Participation (
  artist_id int not null,
  artist_group_id int not null,
  PRIMARY KEY (artist_id, artist_group_id),
  FOREIGN KEY (artist_id) REFERENCES Artists (artist_id),
  FOREIGN KEY (artist_group_id) REFERENCES Artist_Group (artist_group_id),
  CHECK (B'1'<<artist_id & artist_group_id <> 0)
);

確かに、これはハックです。Artist_Group代理キーが一意であるが情報を含まないと想定される場合、代理キーに特別な重要性が適用されます。

また、何千人ものアーティストがいて、毎日新しいアーティストがいる場合、Artist_Groupキーのデータ型の長さを常に大きくする必要があるため、扱いにくくなる可能性があります。

于 2009-05-10T05:31:13.193 に答える
1

「Artist_Group」関係のポイントが欠けていると思います。

私の考えているデータモデルは次のとおりです。

アーティスト：個人。

歌：歌そのもの。

パフォーマンス: 曲の特定のパフォーマンスまたはアレンジ。通常は 1 曲ですが、メドレーに対応するために m:n リンク テーブルを提供できます。理想的には、これは単一の実際のパフォーマンス、つまり関連する日付があるものです。

録音: パフォーマンスの特定の固定バージョン (CD など)。通常、パフォーマンスにはレコーディングが 1 つしかありませんが、別のテーブルを用意することで、グレイトフル デッド / 複数の海賊版のシナリオや、アルバムの再リリース、ラジオ プレイ、ライブ、CD バージョンなどを処理できます。

Performance_Artists: 特定のパフォーマンスからパフォーマーのリストへのリンク テーブル。それぞれについて、パフォーマンスにおける役割 (ボーカリスト、ドラマーなど) を説明する属性を持つこともできます。

共通のパフォーマンスを共有することを除いて、一連のパフォーマー間に明示的な関係はありません。したがって、レコーディングのコンテキスト外でアーティストのランダムなセットを結合しようとするテーブルは、実際の関係がないため、正確なリレーショナル モデルではありません。

一連のアーティスト間の明示的な関係 (つまり、同じバンドに属している)を表現しようとしている場合、バンドには一意性を持つ名前があり (主キーになるには十分ではありません)、バンドを格納できます。単純に Artist として、個々の Artist レコードを自己参照する Artist_Member リンク テーブルを作成します。または、別の Band テーブルと、おそらくメンバーシップの日付でアーティストを割り当てる Band_Members テーブルを持つこともできます。いずれにせよ、バンドのメンバーは時間とともに変化し、バンドの役割は曲ごとに変わることを覚えておいてください。そのため、バンドをパフォーマンスに関連付けることは、パフォーマンスを関係するアーティストに直接リンクすることの代わりになるべきではありません。

于 2009-05-10T05:36:47.267 に答える
1

Artist と Artist_Group の両方の主キーは、数値の増分 ID になります。次に、artist_id と group_id の 2 つの列を持つ Artist_Group_Participation テーブルを作成します。これらは、それぞれのテーブルの ID を参照する外部キーになります。次に、JOIN を使用してすべてを選択します。

編集：申し訳ありませんが、あなたの質問を誤解しました。私が考えることができる他の唯一の方法は、アーティストとその ID のシリアル化された配列 (PHP を使用していると仮定しますが、他の言語には同等のものがあると仮定します) を含む Artist_Group テーブルに「アーティスト」列を追加することです。次に、UNIQUE 制約を列に追加します。

于 2009-05-10T04:55:52.327 に答える
0

アーティストIDを並べ替えて連結することで、主キーを作成できると思いますか??

グループ: 3,2,6 -> 2-3-6 および 6,3,2 -> 2-3-6

于 2009-05-10T06:53:46.613 に答える
0

私は RDBMS の経験があまりありません。しかし、私は Codd の論文と CJ Date の本を読んだことがあります。

したがって、RDBMS の専門用語を使用する代わりに、より一般的な意味のある用語で説明しようとします (少なくとも私にとっては!)。

ここに行きます-

  1. 歌手名は「名-姓」ベースで標準化する必要があります

  2. 各「歌手」は、ソロで演奏した場合でも、「アーティスト グループ」テーブルにエントリが必要です。

  3. 「アーティスト グループ」の各エントリは、アルファベット順に並べられた複数の「歌手」で構成されます。特定の組み合わせが 1 回出現する必要があります。

  4. 各曲には、ソロ、デュエット、ギャングに関係なく、「アーティスト グループ」からのユニークなレコードがエントリされます。

これが意味をなすかどうかはわかりませんが、それは私の 2 セントです!

于 2009-05-10T12:22:20.687 に答える