以下の要件をモデル化する適切な方法を見つけようとしています。
これは大きな考えのほんの一部ですが、モデルを拡張する際に混乱を引き起こしています。最初のモデルでBandMemberをバンドに関連付ける方法がわからないため、図2またはその他のオプションが必要になると思います。
ご意見をいただければ幸いです。
最初に、制限を理解するためのいくつかの注意事項があります。使用または保存されているすべてのデータは、一緒に検討/モデル化する必要があります。例えば。とにかく、「モデルの拡張で混乱を引き起こす」ことに気づきました。私の側から見ると、Parties（サブタイプ）が他のエンティティとどのように関連しているかわからないため、完全に正しい答えを提供することはできません（変更されません）。
2つのトランシェでデータを提供しているため、答えは2つのトランシェになり、2番目のトランシェでは最初のモデルを変更する必要があります。苦情ではなく、事前にアドバイスするだけです。すべてのデータを前もって見れば回避できるからです。
（a）データをモデル化し、（b）概念的、論理的、そして物理的の科学（30年以上にわたって文書化されている）を経験する必要性を理解することは本当に素晴らしいことです。それはまさに私がしていることです。正式なプロセスによって節約される時間と労力を想像することはできません。
リレーションモデリングは、1980年代の業界の巨人であるEFコッド博士とRブラウンの仕事であることに言及する必要があります。方法論は彼らの仕事に基づいています。IDEF1Xは1993年にNIST標準になりました。データモデリングの質問に答えるとき、私は本を書いたような個人的な方法を提供していません。私は巨人の肩の上に立っています。
私はEFコッド博士によるリレーショナルモデルを順守しています。
私は伊達の仕事を拒否します。ダーウェン; フェイギン; など、リレーショナルモデルと矛盾するため、反リレーショナルです。
ERD（P Chen）は、比較すると、プレリレーショナル、プレIDEF1X、およびプリミティブです。識別子の概念がなく、リレーショナルキーを処理できません。ERDがまだ「リレーショナル」として教えられており、IDEF1Xが抑制されていることは驚異的です。30年間。
これとは別に、サブタイプが実装されている場合でも、非常に限られた方法で実装されます。サブタイプには、スーパータイプの役割を変更する効果があります。それの正しい実装は確かに非常にまれです、私はこれをどこにも見たことがありません（もちろん、顧客のための私自身のデータベース実装といくつかのハイエンドサプライヤーを除いて）。
ポイントは、それは「複雑」に見えるかもしれませんが、そうではなく、実際には非常に単純です。
これは、KenDownsとChrisBehrensが、Martin Fowlerなどのドワーフによってアドバイスされた単純なアプローチのために、モデル化された単純さ（高度に拡張可能）とモデル化されていない実装（不正確で拡張不可能）を混同する場所です。違法ではありません。人々は自分の知っていることに執着し、それを擁護することを理解しています。
各サブタイプは、それ自体で完全に有効なエンティティ（物理のテーブル、その段階に到達したとき）でもあり、それ自体で立つことができることに注意してください。
これらのサブタイプとの関係がある下位レベルまたはトランザクションテーブルまたは関数テーブルの場合、トリックは正しいサブタイプ（ロール）を使用することです。よくある間違いは、それらがを使用Partyし、次にサブタイプまたはロールの意味を使用し、正しい参照整合性が失われることです。
個別にすべてのRoleNamesはから派生しますが、それは正しいRoleの代わりにParty使用する正当な理由ではありません。Party
ここであなたはデータを本当によく理解していますが、（誰もあなたにこれを教えていませんし）あなたは役割とサブタイプを混乱させました。
BandMemberでFanはありませんParties。それらは、Persons最初です（そして、2番目です）PersonParty
これらの点を明確にするために、この概念レベルでは、エンティティだけでなく、エンティティと識別子（属性ではない）を操作する必要があります。したがって、私もそれを提供しました。
モデルを提示する前にこれらを指摘します。これは、将来のモデルの緩和を目的として、リレーショナルデータベースをモデル化するための標準的な方法論であるIDEF1Xの学習に真剣に関心があるように思われるためです。SOやその他のウェブサイトは、正式なインタラクティブ教育には適していませんが、ベストショットを提供します。
モデル（1）では、Band独立することはできません（四角い角）：依存していると識別されるためParty; Party;のサブタイプです。そしてそれは同じ識別子を持っています。
欠落しているカーディナリティは重要です。それを入れると、実際にモデルを解決するのに役立ちます。私はIDEF1X（円）とIEEE（カラスの足）に夢中になっているわけではありませんが、常にそれらを入れて、モデルが進むにつれてそれらを変更し続けます。
Bandで構成されていることを示していません。など。
。プログラミングは段階的に進行できますが（定義が安定すると）、モデリングは進行しません。例えば。エンティティをモデル化することはできませんが、リレーションをモデル化することはできません。関係はありますが、カーディナリティはありません。それが彼らが異なる科学であり、プログラマーが優れたモデラーを作らない理由であり、逆もまた同様です。
。 Membersこの段階では、ルールも非常に重要です。実際、モデリングとはルールのモデリングです。したがって、ルールの修正または調整は、モデリングプロセスの一部です。
ファンはどのバンドのファンでもかまいませんし、まったく合理的ではありません。aPersonがまったくない場合、それらは一般のメンバーであり、いずれとも関係がありませんBand。普通のPerson。
AFanは少なくとも1つのと関係がありBandます。実際、aとの関係を持つことBandは、その領域から外れ、詳細または特定のファンオブバンドの詳細のPerson保存を引き起こすものです。Fan
次のようなエンティティがある場合Fan with no Band（つまりFan、モデルごとに個別に詳細を保存している場合）、アドバイスしてください。モデルを変更します（紙は安いです！）。
この段階では、動詞句も重要です。上記のルールとカーディナリティに関する私のポイント以上に、これはモデリングプロセスの一部であり、モデルが進むにつれて変更/変調する必要があります。動詞句を正しく取得することがどれほど重要であるかを信じられないでしょう。それらを入れることは、サブタイプとロールを明確にするのに役立つかもしれません。これは、すべてのデータモデラーが心から知っている定義です。
エンティティはモデル内の名詞です
関係は動詞、名詞間で行われるアクションです
動詞句はそれらのアクションを定義します（それがそれらが正確に動詞句と呼ばれる理由です、それは面白い名前ではありません）。
IDEF1X表記法のドキュメントで説明されているように、連想テーブルの場合は、連想の反対側の親に、それらを「介して」動詞句を読みます。
APersonは1対多Bandsになり、したがって、Member
ABandは1対多で構成されてPeopleいます。Members
PersonひいきにしてBand、彼らを（テーブルに列を持っているFanだけではない）にしますPersonFan
Aは、誰にBand依存しますPeopleFans
最短で最も意味のある動詞句を考え出す。単純な単語を使用しないこと（「含む」は避けるべきです）は、モデラーにとっての課題です。私が提供した動詞句を自由に改善してください。
これが、IDEF1Xのエンティティレベルとキーレベルでのパーティデータモデルです。
リレーショナルデータベースのモデリングの標準に慣れていない読者は、私のIDEF1X表記法が役立つと思うかもしれません。
私が行ったのは、サブタイプを解決することだけです。役割; 上記で特定された関係のカーディナリティ。
サブタイプとロールの関連性は、2番目のトランシェまたはトランザクションエンティティを評価するときに、より明確になります（あなたが述べたように、ここでは識別エンティティのみがあります）。
識別子。これは、モデルを明確にするためだけでなく、使用されているIDEF1X識別子とそれらが展開する能力の良い例であるため、詳しく説明する価値があります。あなたはすでにあなたがそれを理解していることをあなたのモデルで示しました（実線）、私はそれに完全な扱いをしているだけです。
PersonおよびBandはのサブタイプですParty。それらはの役割でもありPartyます。したがって、 （それがそうであるとしても）ではなく、その時点から下に向かってを使用PersonIdします。BandIdPartyIdPartyId
Personがの役割を演じるときは、 （つまり、である）Memberを使用します。MemberIdPersonIdPartyId
Personがの役割を演じるときは、 （つまり、である）Fanを使用します。FanIdPersonIdPartyId
Fansのリストを作成していたとしましょう。Bandクエリはに集中していFanます。Idすべてのテーブルにこれらの代理キーがある場合は、強制的に参加してからPerson参加しPartyます。ただし、お持ちのRelational Identifiersを使用すると、次の場所に直接アクセスできますParty。
SELECT ...,
Name -- Party.Name
...
FROM Party
JOIN Fan
ON PartyId = FanId
Band中間の表をスキップします。はい、真実です。正規化されたリレーショナルデータベースは、必要な結合とリソース（処理、キャッシュ、ディスクI / O）が少なくて済みます。これが、パフォーマンスが大幅に向上する理由の1つです。神話には科学的根拠がありません。
評価して具体的な質問をしてください。
サブタイプの一般的な扱い、および本物のSQLプラットフォームの実装の詳細については、私のサブタイプドキュメントを参照してください。
これはあなたが思っているよりも簡単だと思います。BandとPersonの2つのオブジェクトがあり、ファンまたはメンバーとして2つの異なる方法で接続できます。これは、外部キーなどを含まないクイックデータベーススクリプトです。
CREATE TABLE [dbo].[XREFBandMembers](
[MemberID] [int] NOT NULL,
[BandId] [int] NOT NULL,
CONSTRAINT [PK_XREFBandMembers] PRIMARY KEY CLUSTERED
(
[MemberID] ASC,
[BandId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[XREFBandFans](
[FanId] [int] NOT NULL,
[BandId] [int] NOT NULL,
CONSTRAINT [PK_XREFBandFans] PRIMARY KEY CLUSTERED
(
[FanId] ASC,
[BandId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[People](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Name] [nvarchar](100) NOT NULL,
CONSTRAINT [PK_People] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Bands](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Name] [nvarchar](50) NOT NULL,
CONSTRAINT [PK_Bands] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
関係固有の属性については、XREFテーブルに配置できます。たとえば、FanClubMembershipNumberはXREFBandFansにあります。