Rolenames

When a foreign key is contributed to a child entity through a relationship, you can write a new or enhanced definition for the foreign key attributes. The definition explains the foreign key attribute usage in the child entity. Assign a rolename to the definition, especially when the same attribute is contributed to the same entity more than once. Duplicated attributes can appear identical, but because they serve two different purposes, they cannot have the same definition.

Consider the following example where FOREIGN EXCHANGE TRADE has two relationships to CURRENCY.

The key of CURRENCY is �currency code,� which is the identifier of a valid CURRENCY that you want to track. You can see from the relationships that one CURRENCY is �bought by� and one is �sold by� a FOREIGN EXCHANGE TRADE.

You also see that the identifier of the CURRENCY (the �currency code�) is used to identify each of the two CURRENCYs. The identifier of the one that is bought is named �bought currency code.� The identifier of the one that is sold is named �sold currency code.� The rolenames show that the attributes are not the same thing as �currency code.�

Trading a CURRENCY for the same CURRENCY at the same time and exchange rate is not logical. For a given transaction, such as the instance of FOREIGN EXCHANGE TRADE, "bought currency code� and �sold currency code� must be different. Providing different definitions to the two rolenames captures the difference between the two currency codes.

Attribute/Rolename	Attribute Definition
currency code	The unique identifier of a CURRENCY.
bought currency code	The identifier (�currency code�) of the CURRENCY bought by (purchased by) the FOREIGN EXCHANGE TRADE.
sold currency code	The identifier (�currency code�) of the CURRENCY sold by the FOREIGN EXCHANGE TRADE.

The definitions and validations of the bought and sold codes are based on �currency code.� �currency code� is known as a base attribute.

IDEF1X standard dictates that if two attributes with the same name migrate from the same base attribute to an entity, the attributes must be unified. The result of unification is a single attribute migrated through two relationships. Because of the IDEF1X standard, foreign key attributes are also automatically unified. If you do not want to unify migrated attributes, you can rolename the attributes when you name the relationship, in the Relationship Editor.