web-dev-qa-db-ja.com

各音楽アーティストがグループまたはソロのパフォーマーであるシナリオのモデリング

以下で詳しく説明するように、音楽アーティストの描写を含むビジネスコンテキストのエンティティ関係図（ERD）を設計する必要があります。

シナリオの説明

  • ArtistにはNameがあり、 aGroupor aSolo Performer（両方ではない）。

  • Groupは1人以上Solo Performersで構成され、 メンバー数（ソロパフォーマーの数から計算する必要がありますGroup）を構成しています。

  • ソロパフォーマーは、メンバーの多くのGroupsまたはなしGroupで、1つ以上を再生できますInstruments。

質問

このようなシナリオを表すERDを構築するにはどうすればよいですか？ 「または」の部分と混同しています。

database-designerddatabase-diagramssubtypesmany-to-many
12
Boshir

回答 MDCCLは魅力的で、教育的で、おそらく正しいです（私の給与水準を超えていますが）。

対照的に、私は質問を再解釈し、最も簡単な可能な解決策の基本に戻りました。たぶん、私は浮気をしていて、本当に質問に答えていません…しかし、とにかくここに行きます。

質問を読んだり、もう一度読んだりすると混乱しました。 「アーティスト」という言葉を見たとき、私は個人のことを考え続けました。しかし、いいえ、それは「アーティストブランドのラベル付け」という意味です。たとえば、音楽レコードアルバムにはタイトルと「アーティスト」があり、アーティストが個人であるかどうかは関係ありません Johnny Cash または The Cure のようなグループ。

Prince として現在知られているアーティストを例に考えてみましょう。彼はアルバムを次のように公開しています。

これらの4つはすべて「アーティスト」のインスタンスになります。特に、彼のバンドには2人の女性、ウェンディメルボインとリサコールマンがいましたThe RevolutionではなくNew Power Generation、ブランドの下でキャリアを続けるために出発した Wendy＆Lisa 。

したがって、Wendy＆Lisaを持つ「アーティスト」のさらに別のインスタンスがあり、メルヴォインとコールマンの個人はそれぞれ「アーティスト」ではなくパフォーマーになります。それらの個々の女性は、2人の「アーティスト」にパフォーマーとして割り当てられます（（1）Prince＆The Revolution、（2）ウェンディとリサ）。

次の図は、このサンプルデータをコンパクトに示すための不器用な試みです。 2つの異なるバンド（アーティスト）に属する2つの下線付きの女性（演奏者）を示します。また、4つのバンド（アーティスト）に属しているイタリック体の男性Princeを示していますが、最後のバンド（アーティスト）に属しているnotです。

enter image description here

それがビジネスドメインを表す場合、次のテーブルデザイン（およびERD）を提案します。

Table design diagram of Artist, Membership, Performer, Player, Instrument

基本的には、一対多の関係があります。

  • Artist（ソロまたはバンド）は、割り当てられた1人以上のパフォーマーです。また、Performerは、1つ以上の「アーティスト」/バンドのメンバーになることができます。
  • パフォーマーは1つ以上の楽器を演奏できます。また、各インストゥルメントには、演奏可能なものとしてリストされている多くのパフォーマーを含めることができます。

「グループ」と「SoloPerformer」について：

  • 「ソロ」は、「アーティスト」が1人だけ割り当てられた「アーティスト」です。
    （Membershipテーブルの1つの子レコードのみに、そのアーティストのIDが外部キーとして割り当てられています。）
  • 「グループ」とは、複数の「パフォーマー」が割り当てられた「アーティスト」です。
    （Membershipテーブルの2つ以上の子レコードには、そのアーティストのIDが外部キーとして割り当てられています。）

ビジネスロジックの一部がソロアイテムとグループアイテムのアーティストアイテムを区別することである場合、SQLで、行が1つしかないメンバーシップテーブルがあるアーティスト行と複数のメンバーシップテーブルがあるクエリを実行できます。しかし実際には、次の方法でこの情報を非正規化することはおそらく意味があります。

  • Artistテーブルに「Solo/Group」ブールを追加し、…
  • アプリでこの単一または複数のメンバーシップを適用します。

質問の目的が、データベース構造（またはERD）内でこのソロとグループの区別を強制することであった場合、私は失敗しました。しかし、いずれにしても、この回答が興味深く有用なものになることを願っています。

4
Basil Bourque

MDCCLからの回答は、EERDレベルで示されているスーパークラス/サブクラスまたは一般化/特殊化の背後にある概念のすばらしい要約です。

この回答は、定義された列を持つ定義されたテーブルに基づいて、EERDをリレーショナル設計に変えるときが来たときに知っておく価値のある3つの設計パターンまたは手法を指摘することを目的としています。

ここに3つあります：

  • 単一クラスの継承
  • クラステーブルの継承
  • 共有主キー

最初の2つは代替です。1つは、ほとんどすべてのデータがスーパークラスに関連する単純なケースに適しています。 2番目の方法はより複雑ですが、多くのデータが複数のサブクラスに関連している場合は、うまく機能する可能性があります。 「継承」という言葉は、オブジェクトモデルで継承が提供するものと同じ表現力の一部をデザインが提供することを示すために使用されます。

共有主キーは、スーパークラステーブルの対応するエントリのIDを「継承」することにより、サブクラステーブルのエントリがIDを取得できる手法です。

SOでは、これらの名前のタグが3つあります。各タグの下の[情報]タブには説明があり、タグの下にグループ化された多くの質問があります。

これらのテクニックを紹介するWebサイトもたくさんあります。マーティン・ファウラーのものをお勧めします。私は彼がそれを提示する方法が好きです。ここにいくつかのウェブページがあります：

単一テーブルの継承クラステーブルの継承

2
Walter Mitty