
- •Contents
- •Intended Audience
- •Typographical Conventions
- •Benefits of Data Modeling
- •Data Modeling Sessions
- •Session Roles
- •Sample IDEF1X Modeling Methodology
- •Logical Models
- •The Entity Relationship Diagram
- •The Key-Based Model
- •The Fully-Attributed (FA) Model
- •Physical Models
- •The Transformation Model
- •The DBMS Model
- •Benefits of Data Modeling in ERwin
- •The Entity-Relationship Diagram
- •Defining Entities and Attributes
- •Logical Relationships
- •Many-to-Many Relationships
- •Validating the Design of the Logical Model
- •Data Model Example
- •Identifying Types of Keys
- •Selecting a Primary Key
- •Designating Alternate Key Attributes
- •Designating Inversion Entry Attributes
- •Relationships and Foreign Key Attributes
- •Dependent and Independent Entities
- •Identifying Relationships
- •Non-Identifying Relationships
- •Rolenames
- •Naming Entities and Attributes
- •Synonyms, Homonyms, and Aliases
- •Entity Definitions
- •Definition References and Circularity
- •Constructing a Business Glossary
- •Attribute Definitions
- •Rolenames
- •Definitions and Business Rules
- •Relationship Cardinality
- •Cardinality in Non-Identifying Relationships
- •Referential Integrity
- •Reading Referential Integrity Options
- •RI, Cardinality, and Identifying Relationships
- •RI, Cardinality, and Non-Identifying Relationships
- •Additional Relationship Types
- •Many-to-Many Relationships
- •N-ary Relationships
- •Recursive Relationships
- •Subtype Relationships
- •Complete Versus Incomplete Subtype Structures
- •Inclusive and Exclusive Relationships
- •When to Create a Subtype Relationship
- •Overview of the Normal Forms
- •Functional Dependence (FD)
- •Full Functional Dependence
- •First Normal Form (1NF)
- •Second Normal Form (2NF)
- •Third Normal Form (3NF)
- •Common Design Problems
- •Repeating Data Groups
- •Multiple Use of the Same Attribute
- •Multiple Occurrences of the Same Fact
- •Conflicting Facts
- •Derived Attributes
- •Missing Information
- •Unification
- •How Much Normalization Is Enough?
- •ERwin Support for Normalization
- •First Normal Form Support
- •Second and Third Normal Form Support
- •Creating a Physical Model
- •Summary of Logical and Physical Model Components
- •Denormalization
- •Classification of Dependent Entities
- •Glossary
- •Index

Relationships and Foreign Key Attributes
Rolenames
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.
Foreign Key with Rolename
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 next.
Diagram Showing Migration of an FK Attribute with a Rolename
Note: A rolename is also used to model compatibility with legacy data models in which the foreign key was often named differently than the primary key.
Designing a Key-Based Data Model 4–9