APR 14, 2014 3:54pm ET

Related Links

Gartner: ‘Cognizant Computing’ to Become a Force in Consumer IT
July 21, 2014
What IBM-Apple Partnership Really Means for Businesses
July 18, 2014
Companies Increasingly Look to Cloud for Mobile App Development
July 16, 2014

Web Seminars

How Intelligent Digital Self-Service with Customer Analytics Can Lower Costs and Raise Revenue
July 29, 2014
Improve Omni-channel Shopping Experience with Product Information Management
August 21, 2014
Data Design Challenge

Modifying Foreign Key Definitions

Print
Reprints
Email

When we create a one-to-many relationship between two entities, we copy the primary key from the entity on the one side (the parent entity) over as a foreign key to the entity on the many side (the child entity). We traditionally copy over all of the metadata associated with the primary key such as name, format and definition. The one exception where a foreign key can have a different name than its primary key is when there is more than one relationship from the same entity. To avoid having two or more data elements with the same name in the same entity, we "role name," meaning giving the foreign key a different name than its primary key.

Get access to this article and thousands more...

All Information Management articles are archived after 7 days. REGISTER NOW for unlimited access to all recently archived articles, as well as thousands of searchable stories. Registered Members also gain access to:

  • Full access to information-management.com including all searchable archived content
  • Exclusive E-Newsletters delivering the latest headlines to your inbox
  • Access to White Papers, Web Seminars, and Blog Discussions
  • Discounts to upcoming conferences & events
  • Uninterrupted access to all sponsored content, and MORE!

Already Registered?

Advertisement

Comments (3)
So... the consensus (no wait, the unanimous opinion) is that the meaning of any attribute in a complex relationship (not just a property or descriptor) is dependent on the table in which it finds itself used as a foreign key?

No wonder data modelers have such an aversion to the semantics of their craft!

Posted by John O | Thursday, April 24 2014 at 12:38PM ET
I wonder what John O means by "data modelers have such an aversion to the semantics of their craft". The article clearly supports the principle of matching names and definitions, thereby making the meaning (semantics) clear and accurate. This is a key aspect of data modeling -- at least when practiced well. I've certainly encountered carelessness in some models, but the modelers I work with want good semantics in their models.
Posted by David W | Wednesday, May 14 2014 at 5:03PM ET
Add Your Comments:
You must be registered to post a comment.
Not Registered?
You must be registered to post a comment. Click here to register.
Already registered? Log in here
Please note you must now log in with your email address and password.
Twitter
Facebook
LinkedIn
Login  |  My Account  |  White Papers  |  Web Seminars  |  Events |  Newsletters |  eBooks
FOLLOW US
Please note you must now log in with your email address and password.