アドベンチャー作業データベースの EmailAddress テーブルが複合主キー (BusinessEntityID,EmailAddressID(Identity)) を使用する理由を知りたいのですが? 両方のフィールドのクラスターインデックスの設定に関連するものであれば、複合主キーが物理的にどのように格納されるか (どの順序でどのようにデータが挿入されるか) を教えていただければ幸いです。
2 に答える
これは、同じ電子メールアドレスを複数の人が使用できるだけでなく、同じ人が複数の電子メールアドレスを使用できるためです。つまり、人と電子メールアドレスの関係が多対多になります。 。
電子メールアドレスが個人のものであることを強制するだけでよい場合は、それを外部キーにし、列BusinessEntityID
をnull許容にしないようにするだけで十分でした。
アップデート:
ここには2つのテーブルが含まれていPerson
ますEmailAddress
。
の各レコードは。Person
で識別されますBusinessEntityID
。Person
のレコードを別のテーブルのレコードに関連付けるには、このテーブルにを参照するT
列を含めるだけで十分です。ここで、のすべてのレコードがの一部のレコードに関連付けられていることを確認する必要がある場合は、外部キー制約を設定し、それをnull許容にしないようにします。これに加えて、の各レコードがの唯一のレコードに関連付けられていることを確認したい場合は、列に一意性制約を設定できます。T
BusinessEntityID
T
Person
T.BusinessEntityID
T
Person
T.BusinessEntityID
2つの列を作成A
し、テーブルの主キーの一部を作成する場合、これら2つの列の値を合わせて、そのテーブル内のすべてのレコードに対して一意である必要があることB
をデータベースに通知します。これらの各列の値や外部キーの関係には関係ありません。
説明する:
Person (BusinessEntityID, Name) and PK is BusinessEntityID
---------------
1 | John
---------------
2 | Jane
---------------
3 | Sales Team
EmailAddress (BusinessEntityID, EmailAddressID, EmailAddress) and PK is [Business EntityID, EmailAddressID] where EmailAddress is auto-incremented
--------------
1 | 1 | john@example.com
------------------------
1 | 2 | john@contoso.com
------------------------
2 | 3 | jane@example.com
------------------------
2 | 4 | jane@contoso.com
------------------------
1 | 5 | sales@example.com
------------------------
2 | 6 | sales@example.com
------------------------
3 | 7 | sales@example.com
上記のようなデータを例のテーブルに入れることができます。今ここで何が起こっているのですか?
John、Jane、SalesTeamの3つのエンティティがあります。
ジョンには2つの個人用メールアドレスがあります。ジェーンには2つの個人用メールアドレスもあります。さらに、電子メールaddress sales@example.com
は営業チームだけでなく、ジョンとジェーンにも属しています。
これは多対多の関係です。
さらに、EmailAddressの複合キーがクラスター化されている場合、キーは表示される順序で保存されます。詳細については、これをお読みください。
これは構成上、1 つの電子メール アドレスは人なしでは存在できませんでした。したがって、BusinessEntityID は EmailAddress テーブルの主キーでもあります