концепция составного первичного ключа в базе данных Adventure Work

Это связано с тем, что таким образом один и тот же адрес электронной почты может использоваться несколькими людьми, а одно и то же лицо может использовать несколько адресов электронной почты, то есть это делает связь между человеком и адресом электронной почты «многие ко многим». .

Если бы нужно было просто обеспечить, чтобы адрес электронной почты принадлежал человеку, было бы достаточно сделать его внешним ключом, а столбец BusinessEntityID не допускал значения NULL.

Обновление:

Здесь задействованы 2 таблицы, Person и EmailAddress.

Каждая запись в Person обозначается BusinessEntityID. Чтобы связать запись из Person с записью в другой таблице T, достаточно включить в эту таблицу T столбец, который ссылается на BusinessEntityID. Теперь, если нам нужно было гарантировать, что все записи в T должны быть связаны с некоторой записью в Person, тогда мы поместим ограничение внешнего ключа на T.BusinessEntityID и сделаем его не допускающим значения NULL. Если вдобавок к этому мы хотели убедиться, что каждая запись в T должна быть связана с одной и только одной записью в Person, тогда мы могли бы установить ограничение уникальности для столбца T.BusinessEntityID.

Когда мы делаем 2 столбца, A и 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 | [email protected]
------------------------
1 | 2 | [email protected]
------------------------
2 | 3 | [email protected]
------------------------
2 | 4 | [email protected]
------------------------
1 | 5 | [email protected]
------------------------
2 | 6 | [email protected]
------------------------
3 | 7 | [email protected]

Данные, аналогичные приведенным выше, можно поместить в таблицы в вашем примере. Что здесь происходит?

Есть 3 объекта: Джон, Джейн и отдел продаж.

У Джона есть 2 личных адреса электронной почты. У Джейн также есть 2 личных адреса электронной почты. Кроме того, электронное письмо address [email protected] принадлежит отделу продаж, а также Джону и Джейн.

Это отношения "многие ко многим".

Кроме того, если составной ключ в EmailAddress кластеризован, ключи сохраняются в том порядке, в котором они появляются. Прочтите это для получения дополнительной информации.

Это из-за состава, один адрес электронной почты не может существовать без человека. Итак, BusinessEntityID также является первичным ключом для таблицы EmailAddress.