以下で詳しく説明するように、音楽アーティストの描写を含むビジネスコンテキストのエンティティ関係図（ERD）を設計する必要があります。
アンアーティストが持っている名前を、とでなければならないのいずれかのグループ やソロパフォーマー（両方ではありません）。
A グループは、一人の以上で構成されソロパフォーマーと有するメンバーの数（数から計算されるべきであるソロ出演構成するグループ）。
A ソロパフォーマーは、かもしれ加盟多くの団体、あるいは全くのグループと1つの以上プレイしてもよい楽器を。
このようなシナリオを表すERDを構築する方法は？「または」の部分と混同しています。
回答:
混乱しているシナリオの一部は、スーパータイプ-サブタイプ1構造と呼ばれる古典的な構造でモデル化できます。
（1）関連する予備的なアイデアを紹介し、（2）検討中のビジネスコンテキストを概念レベルでどのように描写するかを詳しく説明し、（3）追加の関連資料を提供します（例：SQLによる対応する論理レベルの表現） -DDL宣言-以下のとおり。
この性質の構造は、特定のビジネス環境で、エンティティタイプのクラスターがあり、その中にスーパータイプが1つ以上のプロパティ（または属性）を持ち、クラスター内の他のエンティティタイプと共有されている場合に発生します。 、サブタイプ。次に、すべてのサブタイプには、それ自体にのみ適用できる特定のプロパティセットがあります。
スーパータイプ-サブタイプのクラスターには、次の2種類があります。
独占。スーパーエンティティタイプのインスタンスが常に対応するサブタイプを1つだけ持つ必要がある場合に発生します。したがって、問題の潜在的なサブタイプの出現は相互に排他的です。これは、シナリオに関係する種類です。
排他的なスーパータイプサブタイプが発生する典型的なケースは、この一連の投稿で検討されている状況のように、組織と個人の両方が法的当事者と見なされるビジネスドメインです。
排他的ではありません。スーパータイプインスタンスが複数のサブタイプオカレンスによって補完される可能性がある場合に表示されます。各サブタイプオカレンスは、異なるカテゴリであることが強制されます。
この種のスーパータイプ-サブタイプの例は、これらの投稿で扱われています。
注：リレーショナル、ネットワーク、階層など、特定のデータ管理理論フレームワークに属さないスーパータイプ-サブタイプ構造（概念的な特性の要素）は、概念的な要素を表す特定の構造を提供します。
スーパータイプサブタイプクラスターはオブジェクト指向アプリケーションプログラミング（OOP）の継承とポリモーフィズムにある程度類似しているものの、目的が異なるため実際には異なるデバイスであることを指摘することもできます。データベースの概念モデル（実際の側面を表す必要がある）では、情報要件を記述するために構造的特徴を扱いますが、OOPポリモーフィズムと継承では、とりわけ、（a）スケッチと（b）計算特性と動作特性を実装します、アプリケーションプログラムの設計とプログラミングに明確に属する側面。
それとは別に、個々のOOP クラス（アプリケーションプログラムコンポーネント）は、必ずしも手元のデータベースの概念レベルに属する個々のエンティティタイプの構造を「ミラーリング」する必要はありません。この点で、アプリケーションプログラマは通常、たとえば、2つ（またはそれ以上）の異なる概念レベルのエンティティタイプのすべてのプロパティを「組み合わせた」単一のクラスを作成できます。このようなクラスには、計算されたプロパティも含まれます。
エンティティ関係構造を使用して、スーパータイプ-サブタイプ構造を持つ概念モデルを表す
エンティティリレーションシップダイアグラム（簡潔にするためにERD）を要求しましたが、並外れたモデリングプラットフォームでしたが、元の方法（Dr. Peter Pin-Shan Chen 2によって導入されたもの）は、次のようなシナリオを表すのに十分な構成を提供しませんでした適切なデータベースの概念モデルが必要とする精度で議論されました。
その結果、前述の方法にいくつかの拡張を加える必要がありました。この状況では、初期の描画手法を新しい表現特性で強化したエンティティ関係図（EERD）の作成を支援するアプローチの開発に結果がもたらされました。。これらの特徴の1つは、正確には、スーパータイプとサブタイプの構造を表す可能性です。
図1に示す図はEERD（Ramez A. ElmasriおよびShamkant B. Navathe 3によって提案されたものと同様の記号を使用し、スーパークラス/サブクラスなどの構造を参照します）です。仕様。DropboxからダウンロードできるPDFとしても利用できます。
上記の図からわかるように、GroupとSoloPerformerはスーパーエンティティタイプの排他的なサブタイプとして表示されますArtist。
EERDの説明を始めるには、あなたの文が
関連する互いに素と完全手でスーパータイプ・サブタイプクラスタの観点。
バラバラ
分離機能は特に重要です。というのも、ここで、あなたが言及した「または部分」が作用するのは、Artistが1つのサブタイプインスタンスまたは他のいずれかである必要があるためです。切り離されたルールの名前を受け取る構成体、文字「d」を含む円。
スーパータイプがその可能なサブタイプの1つ以上で補足される場合、この点は、「o」という文字が付いたラベルを持つ小さな円で表す必要があります。これは、オーバーラップルールと呼ばれます。
Discriminatorプロパティ
また、このスーパータイプとサブタイプの関連の不整合係数の範囲内ではArtist.Type、この配置で非常に関連性の高いタスクを実行するため、プロパティに細心の注意を払う価値があります。これは、サブタイプ識別子として機能します。これは、の特定のインスタンスが関係するサブタイプの排他的な種類を示すプロパティであるため、このように名前が付けられていますArtist。
非排他的クラスターの場合、特定のスーパータイプが複数のサブタイプを補数として持つことができるため（上記で説明したように）、弁別子プロパティを使用する必要はありません。
総合的な専門化ルールと完全性
すべてArtistが常に補助的なサブタイプのインスタンスを持つ必要があることを規定する要件は、このクラスターの完全性特性と関係があります。これは、（a）スーパータイプと（b）結合されていないルールコンストラクトを接続する二重線記号によって示される、完全な特殊化ルールによって示さArtistれます。
グループとソロパフォーマーの関連付け
文章を評価する
そして
両方のサブタイプが多対多（M：N）の関連付け（または関係）に関係していることがわかりますGroup-SoloPerformer。
で実施される場合、リレーショナルとしてデータベースベース・テーブル、このコンポーネントは非常に有用であろう導出合計（の計算を実行するために、IE）NumberのSoloPerformers具体的なまでそのメイクをGroup（あなたが指定したことを要件の一つ）。
ソロパフォーマーとインストゥルメントの関連付け
規定
それを同時に推論することを許可します
したがって、これはM：N関連付けのもう1つの例であり、SoloPerformer-Instrumentそれを公開するために指定された菱形の図形を使用しました。
スーパータイプとサブタイプの構造の範囲を説明するために、次の2つのリソースを追加します。
図2に示されているIDEF1X 4図（およびDropboxからPDFとしてダウンロードすることもできます）。これは、問題のビジネスドメインに関するこの種の図の表現力を示しています。そして
SQLデータベース管理システムによって、議論中の完全なシナリオを管理する方法を例示するそれぞれの説明的なDDL論理構造。
IDEF1X情報モデリング技術は確かにスーパータイプ-サブタイプ構造を描写する機能を提供しますが、制限があります。正確なクラスターが排他的であるか非包括的であるかを示す視覚的メカニズムを提供しません（その「ネイティブ」シンボルは通信のみが可能です）すべての可能なサブエンティティタイプの重要性の完全または不完全な識別）。さいわい、情報工学（IE）表記を使用して、IDEF1X標準の記述力を利用しながら、この最も重要な側面をより正確に示すことができます。
この手法では、質問の主な機能は「分類関係」と呼ばれ、スーパータイプは「汎用エンティティ」と呼ばれ、サブタイプは「カテゴリエンティティ」の名前を受け取ります。しかし、私は長期適用続けるスーパータイプサブタイプ（1）それは博士エドガーフランクコッド、リレーショナルモデルの発信、（2）によって使用されたので、それはより広く知られており、この記事では（3）IE表記であります「ネイティブ」の代わりに使用されます。
外部キーとスーパータイプサブタイプクラスター
示されているように、IDEF1Xにはさらなる利点があります。外部キー（FK）の定義を示す手段であり、開業医がリレーショナルデータベースでスーパータイプとサブタイプの関連付けを表す場合に最も重要な要素です。
関連のこのようなソートを描写するために、スーパータイプの主キー（PK）性質、すなわちArtist.ArtistNumber、しなければならない移行するGroupとSoloPerformer、それが2人の異なる割り当てられているが、ロール名5,6、GroupNumberおよびSoloPerformerNumber強調のために、それぞれ意味は、各サブエンティティタイプのコンテキストでプロパティによって搬送されました。
PKとして特徴付けられることとは別に、Group.GroupNumberand SoloPerformer.SoloPerformerNumberプロパティは同時にArtist.ArtistNumber、スーパータイプPKプロパティを参照するFOREIGN KEY（FK）として表されます。
すべてのためだから、SoloPerformerおよびGroup発生がある存在に依存正確にArtistインスタンス、これらのエンティティタイプはに関与している特定の関連付け前の段落で描写PK特性移行プロセスの方法によって有効になります。
外部キーと連想エンティティタイプ
IDEF1Xの図は、2つのPKの構成FKS例示するためにも役立つ連想エンティティタイプ、すなわち、関連性を、GroupMemberそしてSoloPerformerInstrument、1つ目は2つのサブタイプを接続し、2つ目はサブタイプを独立したエンティティタイプにリンクしますInstrument。
前に説明したように、スーパータイプ-サブタイプ構造は、情報要件に関する特定の種類のビジネスドメイン固有の概念を表現する手段であり、特定の要件によって提供されるものに対応する必要のある別個の構造によってデータベースで表すことができます。理論的パラダイム（リレーショナル、ネットワーク、階層など）に続いて、設計者が使用するデータベース管理システム。
リレーショナルパラダイムの複数の利点の1つは、自然な構造で情報を表現できることです。リレーショナル理論で提案されているシステムの最も一般的な近似は、さまざまなSQLデータベース管理システムです。
それで、最後に、いくつかのサンプルDDLステートメントを以下に示します。（a）ベーステーブルスキーマと（b）関連する制約の一部を含みます。これらは、抽象化の論理レベルで、上記で扱われた概念モデリングの演習を表します。
--
--
CREATE TABLE Artist ( -- Stands for the supertype.
ArtistNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
Type CHAR(1) NOT NULL, -- Holds the discriminator values.
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Artist_PK PRIMARY KEY (ArtistNumber),
CONSTRAINT Artist_AK UNIQUE (Name), -- ALTERNATE KEY.
CONSTRAINT Artist_Type_CK CHECK (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);
CREATE TABLE MyGroup ( -- Represents one subtype.
GroupNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
FormationDate DATE NOT NULL,
--
CONSTRAINT MyGroup_PK PRIMARY KEY (GroupNumber),
CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
SoloPerformerNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
BirthDate DATE NOT NULL,
--
CONSTRAINT SoloPerformer_PK PRIMARY KEY (SoloPerformerNumber),
CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
MemberNumber INT NOT NULL,
GroupNumber INT NOT NULL,
JoinedDate DATE NOT NULL,
--
CONSTRAINT GroupMember_PK PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT GroupMemberToMyGroup_FK FOREIGN KEY (GroupNumber)
REFERENCES MyGroup (GroupNumber)
);
CREATE TABLE Instrument ( -- Represents an independent entity type.
InstrumentNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
--
CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
CONSTRAINT Instrument_AK UNIQUE (Name) -- ALTERNATE KEY.
);
CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
SoloPerformerNumber INT NOT NULL,
InstrumentNumber INT NOT NULL,
CreatedDate DATE NOT NULL,
--
CONSTRAINT SoloPerformerInstrument_PK PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT SoloPerformerInstrumentToInstrument_FK FOREIGN KEY (InstrumentNumber)
REFERENCES Instrument (InstrumentNumber)
);
--
--データの整合性と一貫性に関する考慮事項
前述のすべてに同意して、設計者は各「スーパータイプ」行が常に付随する「サブタイプ」の対応物によって補完されることを保証し、次に、「サブタイプ」行が値と互換性があることを確認する必要があります。スーパータイプの「弁別子」列に含まれています。
（リレーショナルフレームワークが提案するように）上記の状況を宣言的に強制することは非常に実用的で洗練された方法ですが、悲しいことに、主要なSQLプラットフォームのいずれも（私が知る限り）そのための適切なメカニズムを提供していません。したがって、これらの条件が常にデータベースで満たされるように、ACID TRANSACTIONSを使用することは非常に便利です（他のオプションはTRIGGERSを使用することですが、乱雑になる傾向があります）。
データ導出に関する考慮事項
リレーショナルモデルの主要な側面の1つは、データの派生をデータ管理における最重要要素と見なすことです。それに応じて、（a）ベースリレーション-または上記のDDLステートメントに示されているSQLのベーステーブル- および（b）派生リレーション-SQLの派生テーブル、つまり、さらに活用するためのビューとして修正されました。
したがって、「完全な」グループデータポイントを収集するビューを宣言できます。
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;そして、「完全な」SoloPerformerの情報を組み合わせた他のビュー：
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;このようにして、非常に同じ論理レベルのデバイス、つまりリレーションまたはテーブル（ベースまたは派生）を介してすべての重要なデータを「宣言的に」操作することは非常に簡単です。明らかに、リレーショナルデータベースで表される概念エンティティタイプがより多くの関心のあるプロパティを持っている場合、ビューの使用はより効果的ですが、現在のシナリオで説明する価値がある可能性があります。
1 コッド、EF（1979年12月）。データベースリレーショナルモデルを拡張して、データベースシステムでのより意味のあるACMトランザクションを収集する、第4巻、第4号（ページ397-434）。ニューヨーク、ニューヨーク、アメリカ。
2 陳、PP（1976年3月）。エンティティリレーションシップモデル—データの統一されたビューに向けて、データベースシステムでのACMトランザクション-特集：超大規模データベースに関する国際会議の論文：1975年9月22〜24日、マサチューセッツ州フラミンガム、第1巻第1号（pp 。9-36）。ニューヨーク、ニューヨーク、アメリカ。
3 Elmasri、R＆Navathe、SB（2003）。データベースシステムの基礎、第4版。Addison-Wesley Longman Publishing Co.、Inc.マサチューセッツ州ボストン、米国。
4米国国立標準技術研究所（米国）[NIST]（1993年12月）。情報モデリングの統合定義（IDEF1X）、連邦情報処理標準出版物、ボリューム184。米国。
5コッド、EF（1970年6月）。大きな共有データバンクのデータのリレーショナル・モデルA、ACMのコミュニケーション、第13巻第6号（頁377-387）。ニューヨーク、ニューヨーク、アメリカ。
6参照4を参照
MDCCL の回答は魅力的で、教育的で、おそらく正しいです（私の給与水準を超えていますが）。
対照的に、私は質問を再解釈して、可能な限り最も簡単な解決策の基本に戻りました。たぶん私は浮気をしていて、質問に本当に答えていません…しかし、とにかくここに行きます。
質問を読んだり、もう一度読んだりすると混乱しました。「アーティスト」という言葉を見たとき、私は個人のことを考え続けました。音楽レコードのアルバムはタイトルやアーティストなどの個々のことかどうかを「アーティスト」持っているようしかし、いや、それは、「芸術的なブランドのラベル」の意味で意味だジョニー・キャッシュなどのグループキュアを。
現在プリンスとして知られているアーティストを例に考えてみましょう。彼はアルバムを次のように公開しています。
これらの4つすべてが「アーティスト」のインスタンスになります。特に、ウェンディメルボインとリサコールマンの2人の女性が彼のバンドThe Revolutionにありましたが、New Power Generationではなく、Wendy＆Lisaのブランドでキャリアを続けました。
したがって、私たちはウェンディとリサとの「アーティスト」のさらに別のインスタンスを持ち、メルヴォインとコールマンの個人はそれぞれ「アーティスト」ではなくパフォーマーになります。これらの個々の女性は、2人の「アーティスト」（（1）Prince＆The Revolution、（2）Wendy＆Lisa）にパフォーマーとして割り当てられます。
次の図は、このサンプルデータをコンパクトに示すための不器用な試みです。2つの異なるバンド（アーティスト）に属する2人の下線付きの女性（演奏者）を示します。また、4つのバンド（アーティスト）に属しているが、最後のバンド（アーティスト）には属していないイタリック体の男性、プリンスを示しています。
それがビジネスドメインを表す場合、次のテーブルデザイン（およびERD）を提案します。
基本的に、私たちは一対多の関係を持っています：
「グループ」と「SoloPerformer」について：
ビジネスロジックの一部がソロアイテムとグループアイテムのアーティストアイテムを区別することである場合、SQLで、行が1つしかないメンバーシップテーブルがあるアーティスト行と複数のメンバーシップテーブルがあるクエリを実行できます。しかし実際には、次の方法でこの情報を非正規化することはおそらく意味があります。
質問の目的が、データベース構造（またはERD）内でこのソロとグループの区別を強制することであった場合、私は失敗しました。しかし、どちらにしても、この回答が興味深く有用なものになることを願っています。
MDCCLからの回答は、EERDレベルで示されているスーパークラス/サブクラスまたは一般化/特殊化の背後にある概念のすばらしい要約です。
この回答は、定義された列を持つ定義されたテーブルに基づいて、EERDをリレーショナル設計に変えるときが来たときに知っておく価値のある3つの設計パターンまたは手法を指摘することを目的としています。
ここに3つあります：
最初の2つは代替です。1つは、ほとんどすべてのデータがスーパークラスに関連する単純なケースに適しています。2番目の方法はより複雑ですが、多くのデータが複数のサブクラスに関連している場合は、うまく機能する可能性があります。「継承」という言葉は、オブジェクトモデルで継承が提供するものと同じ表現力の一部をデザインが提供することを示すために使用されます。
共有主キーは、サブクラステーブル内のエントリが、スーパークラステーブル内の対応するエントリのIDを「継承」することにより、IDを取得できる手法です。
SOでは、これらの名前のタグが3つあります。各タグの下の[情報]タブには説明があり、タグの下にグループ化された多くの質問があります。
これらのテクニックを紹介するWebサイトもたくさんあります。マーティン・ファウラーのものをお勧めします。私は彼がそれを提示する方法が好きです。ここにいくつかのウェブページがあります：