In IDEF1X notation, the type of the relationship that connects two entities enforces the concept of dependent and independent entities. If you want a foreign key to migrate to the key area of the child entity (and create a dependent entity as a result), you can create an identifying relationship between the parent and child entities. A solid line connecting the entities indicates an identifying relationship. In IDEF1X notation, the line includes a dot on the end nearest to the child entity, as shown in the following figure:
In IE notation, the line includes a crow's foot at the end of the relationship nearest to the child entity:
Note: Standard IE notation does not include rounded corners on entities. This is an IDEF1X symbol that is included in IE notation to ensure compatibility between methods.
As you may find, there are advantages to contributing keys to a child entity through identifying relationships in that it tends to make some physical system queries more straightforward, but there are also many disadvantages. Some advanced relational theory suggests that contribution of keys should not occur in this way. Instead, each entity should be identified not only by its own primary key, but also by a logical handle or surrogate key, never to be seen by the user of the system. There is a strong argument for this in theory and those who are interested are urged to review the work of E. F. Codd and C. J. Date in this area.
A non-identifying relationship also connects a parent entity to a child entity. But, when a non-identifying relationship connects two entities, the foreign key migrates to the non-key area of the child entity (below the line).
A dashed line connecting the entities indicates a non-identifying relationship. If you connect the TEAM and PLAYER entities in a non-identifying relationship, the "team-id" migrates to the non-key as shown in the figure below:
Since the migrated keys in a non-identifying relationship are not part of the primary key of the child, non-identifying relationships do not result in any identification dependency. In this case, PLAYER is considered an independent entity, just like TEAM.
However, the relationship can reflect existence dependency if the business rule for the relationship specifies that the foreign key cannot be NULL (missing). If the foreign key must exist, this implies that an instance in the child entity can only exist if an associated parent instance also exists.
Note: Identifying and non-identifying relationships are not a feature of the IE methodology. However, this information is included in your diagram in the form of a solid or dashed relationship line to ensure compatibility between IE and IDEF1X methods.
When foreign keys migrate from the parent entity in a relationship to the child entity, they are serving double-duty in the model in terms of stated business rules. To understand both roles, it is sometimes helpful to rename the migrated key to show the role it plays in the child entity. This name assigned to a foreign key attribute is called a rolename. In effect, a rolename declares a new attribute, whose name is intended to describe the business statement embodied by the relationship that contributes the foreign key.
The foreign key attribute of "player-team-id.team-id" in the PLAYER entity shows the syntax for defining and displaying a rolename. The first half (before the period) is the rolename. The second half is the original name of the foreign key, sometimes called the base name.
Once assigned to a foreign key, a rolename migrates across a relationship just like any other foreign key. For example, suppose that you extend the example to show which PLAYERs have scored in various games throughout the season. The "player-team-id" rolename migrates to the SCORING PLAY entity (along with any other primary key attributes in the parent entity), as shown in the figure below:
Note: A rolename is also used to model compatibility with legacy data models where the foreign key often had a different name from the primary key.
| Copyright © 2009 CA. All rights reserved. | Email CA about this topic |