3

アドベンチャー作業データベースの EmailAddress テーブルが複合主キー (BusinessEntityID,EmailAddressID(Identity)) を使用する理由を知りたいのですが? 両方のフィールドのクラスターインデックスの設定に関連するものであれば、複合主キーが物理的にどのように格納されるか (どの順序でどのようにデータが挿入されるか) を教えていただければ幸いです。

ここに画像の説明を入力

4

2 に答える 2

1

これは、同じ電子メールアドレスを複数の人が使用できるだけでなく、同じ人が複数の電子メールアドレスを使用できるためです。つまり、人と電子メールアドレスの関係が多対多になります。 。

電子メールアドレスが個人のものであることを強制するだけでよい場合は、それを外部キーにし、列BusinessEntityIDをnull許容にしないようにするだけで十分でした。

アップデート:

ここには2つのテーブルが含まれていPersonますEmailAddress

の各レコードは。Personで識別されますBusinessEntityIDPersonのレコードを別のテーブルのレコードに関連付けるには、このテーブルにを参照するT列を含めるだけで十分です。ここで、のすべてのレコードがの一部のレコードに関連付けられていることを確認する必要がある場合は、外部キー制約を設定し、それをnull許容にしないようにします。これに加えて、の各レコードがの唯一のレコードに関連付けられていることを確認したい場合は、列に一意性制約を設定できます。TBusinessEntityIDT PersonT.BusinessEntityIDTPersonT.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の複合キーがクラスター化されている場合、キーは表示される順序で保存されます。詳細については、これをお読みください。

于 2013-01-30T19:43:10.207 に答える
0

これは構成上、1 つの電子メール アドレスは人なしでは存在できませんでした。したがって、BusinessEntityID は EmailAddress テーブルの主キーでもあります

于 2013-01-30T19:38:21.473 に答える