title: Foreign keys in composite key
body: <p>Suppose I have a table, Document, that looks something like this:</p>
  
  <pre><code> _______________________
  |        Document       |
  |-----------------------|
  | DocumentId int PK     |
  | (add't fields)        |
  |_______________________|
  </code></pre>
  
  <p>Now suppose I have a second table:</p>
  
  <pre><code> _______________________
  |    DocumentVersion    |
  |-----------------------|
  | DocumentId int PK, FK |
  | VersionId int PK      |
  | (add't fields)        |
  |_______________________|
  </code></pre>
  
  <p>Finally, suppose I wish to create a third table that references DocumentVersion, perhaps an audit of users that have accessed each version (assume a User table exists):</p>
  
  <pre><code> _______________________
  |   VersionAccessLog    |
  |-----------------------|
  | DocumentId int PK, FK |
  | VersionId int PK, FK  |
  | UserId int PK, FK     |
  | AccessTime DateTime PK|
  |_______________________|
  </code></pre>
  
  <p>Maybe not the best example but hopefully enough to illustrate my question.</p>
  
  <p>Focusing on <strong>VersionAccessLog</strong>, we have:</p>
  
  <ul>
  <li>PK(DocumentId, VersionId, UserId, AccessTime)</li>
  <li>FK(DocumentId, VersionId) REFERENCES DocumentVersion</li>
  <li>FK(userId) REFERENCES User</li>
  </ul>
  
  <p>Now my question is, should I also in VersionAccessLog create a <strong>FK(DocumentId)</strong>?  At first glance, the key seems superfluous-- referential integrity is enforced by the FK to DocumentVersion.  However, from a relational algebra standpoint, <strong>should this key exist or not?</strong>  From a practical standpoint (assume SQL Server 2012 if necessary), <strong>are there any performance implications of including or excluding the key?</strong></p>