Sometimes the existence of a record in one table is dependent upon the existence of another record in a related table. For example, a Person table may be related to a Car table (one-to-many). A car may exist in the Car table independent of any entry in the Person table. In other words, a car record does not require a related person – a physical object exists on its own. Likewise, a person record could exist without an associated car (the person might not own a car). These two tables are independent, even though a relationship/association exists between them.

Some tables are not independent. Take Customer and Policy tables – if each policy record must have a person to whom the policy is “attached,” we say the Policy table is dependent upon the Customer table. A person may or may not have a policy, but each policy must have a person.

Dependency normally comes into play when records are being removed from a table. In the first example, removing a person record has no effect on the associated car record. Although the person may no longer function as the car’s owner, the car itself continues to exist. A car doesn’t automatically vanish just because a person dies. On the other hand, removing a person should remove all associated policies. A person who switches insurance companies (and is deleted from its database) can expect his previous company to cancel and delete his old policies, too.

A Dependent table normally contains as part of its primary key the foreign key of the independent table. Since a Corticon Vocabulary represents a foreign key relationship as a Join Expression in the association mapping (see Mapping EDC database relationships to Vocabulary Associations), a dependent entity will have a composite key with the association name participating in the key.

As we can see in the following figure, the composite key contains both id, which is the application identity for the Policy entity and policy_owner, which is the association between Customer and Policy entities. This indicates that Policy is a dependent table, and that removing a Customer record will also remove all associated policy records.

Figure 1. Primary Key of a Dependent Table Includes the Role Name