If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > Surrogate keys and 3NF

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 09-05-03, 00:06
naz naz is offline
Registered User
 
Join Date: Jul 2003
Posts: 18
Surrogate keys and 3NF

I have a table:

linkId (PK)
projectId
employeeId
dateJoined

linking a project table and an employee table and stating when each employee joined each project they joined.

Now, dateJoined is dependent on projectId and employeeId, however the surrogate key is the PK of the table. is the dateJoined <-> employeeId+projectId relationship a transitive dependency for the purpose of determining 3NF and if so, is this table to be considered denormalized?
Reply With Quote
  #2 (permalink)  
Old 09-05-03, 06:00
andrewst andrewst is offline
Moderator.
 
Join Date: Sep 2002
Location: UK
Posts: 5,171
Re: Surrogate keys and 3NF

Quote:
Originally posted by naz
I have a table:

linkId (PK)
projectId
employeeId
dateJoined

linking a project table and an employee table and stating when each employee joined each project they joined.

Now, dateJoined is dependent on projectId and employeeId, however the surrogate key is the PK of the table. is the dateJoined <-> employeeId+projectId relationship a transitive dependency for the purpose of determining 3NF and if so, is this table to be considered denormalized?
According to your definition, I would say your table has 2 candidate keys:
1: linkId
2: projectId, employeeId
Therefore, dateJoined depends directly on BOTH candidate keys, and there is no transitive dependency, the table is in 3NF.

However, I would question:

a) Why create a surrogate key when you have already identified a perfectly good natural one? Unless this linkID is going to appear as a foreign key in other tables, what benefit does it confer?

b) Is your assumption correct that "dateJoined is dependent on projectId and employeeId"? Can an employee not join a project, leave it, then join it again? In which case, dateJoined becomes part of the key (projectId, employeeId, dateJoined).
__________________
Tony Andrews
http://tinyurl.com/tonyandrews
Reply With Quote
  #3 (permalink)  
Old 09-05-03, 22:36
naz naz is offline
Registered User
 
Join Date: Jul 2003
Posts: 18
The example was highly simplified, the assumption was that an employee would only join once.

WRT to the surrogate key, I prefer use of employeeId+projectId as the PK, I was asking for purely theoretical and academic reasons.

Thankyou for your answer, it was exactly what I was after.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On