Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It is because this way, the same e-mail address can be used by multiple Persons as well as the same Person can use multiple e-mail addresses, i.e., it makes the relationship between person and e-mail address many-to-many.</p> <p>If the need was merely to enforce that the e-mail address should belong to a person, it would have been enough to make it a foreign key and the column <code>BusinessEntityID</code> not nullable.</p> <p><strong>Update:</strong></p> <p>There are 2 tables involved here, <code>Person</code> and <code>EmailAddress</code>.</p> <p>Each record in <code>Person</code> is identified by a <code>BusinessEntityID</code>. To associate a record from <code>Person</code> with a record in another table <code>T</code>, it is enough to include a column in this table <code>T</code> that refers to <code>BusinessEntityID</code>. Now, if we needed to ensure that all records in <code>T</code> <em>must</em> be associated with some record in <code>Person</code>, then we would place a foreign key constraint on <code>T.BusinessEntityID</code> and make it not nullable. If on top of this, we wanted to ensure that each record in <code>T</code> must be associated with one and only one record in <code>Person</code>, then we could place a uniqueness constraint on the column <code>T.BusinessEntityID</code>.</p> <p>When we make 2 columns, <code>A</code> and <code>B</code> part of the primary key of a table, we are telling the database that the values of these two columns <strong>together</strong> must be unique for all records in that table. It has no bearing on the values in each of those columns and any foreign key relationships.</p> <p>To illustrate:</p> <pre><code>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 </code></pre> <p>Data similar to the above is possible to put in the tables in your example. Now what is happening here?</p> <p>There are 3 entities, John, Jane and Sales Team.</p> <p>John has 2 personal e-mail addresses. Jane also has 2 personal e-mail addresses. In addition, the e-mail <code>address sales@example.com</code> belongs to the Sales Team but also to John and Jane.</p> <p>This is a many-to-many relationship.</p> <p>Additonally, if the composite key in EmailAddress is clustered, the keys are stored in the order in which they appear. Read <a href="https://stackoverflow.com/questions/389348/should-a-composite-primary-key-be-clustered-in-sql-server">this</a> for more information.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload