Naming and Defining Entities and Attributes › Rolenames

Rolenames

When a foreign key is contributed to a child entity through a relationship, you may need to write a new or enhanced definition for the foreign key attributes that explains their usage in the child entity and can assign a rolename to the definition. This is certainly the case when the same attribute is contributed to the same entity more than once. These duplicated attributes may appear to be identical, but because they serve two different purposes, they cannot have the same definition.

Consider the following example shown in the figure below. Here you see a FOREIGN-EXCHANGE-TRADE with two relationships to CURRENCY.

The key of CURRENCY is “currency-code,” (the identifier of a valid CURRENCY that you are interested in tracking). 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 called “bought-currency-code” and the identifier of the one that is sold is called “sold-currency-code.” These rolenames show that these attributes are not the same thing as “currency-code.”

It would be somewhat silly to trade a CURRENCY for the same CURRENCY at the same time and exchange rate. So for a given transaction (instance of FOREIGN-EXCHANGE-TRADE) “bought-currency-code” and “sold-currency-code” must be different. By giving different definitions to the two rolenames, you can capture the difference between the two currency codes.

The definitions and validations of the bought and sold codes are based on “currency-code.” “Currency-code” is called a base attribute.

The IDEF1X standard dictates that if two attributes with the same name migrate from the same base attribute to an entity, then 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 automatically unified as well. If you do not want to unify migrated attributes, you can rolename the attributes at the same time that you name the relationship, in the Relationship Editor.