RI, Cardinality, and Non-Identifying Relationships

If the business decides that PROJECT-EMPLOYEEs are not existence or identification-dependent on PROJECT, you can change the relationship between PROJECT and PROJECT-EMPLOYEE to optional, non-identifying. In this type of relationship, the referential integrity options are very different.

Referential Integrity for a Non-Identifying Relationship

Because a foreign key contributed across a non-identifying relationship is allowed to be NULL, one of the referential integrity options you could specify for PARENT DELETE is "set null." Set null indicates that if an instance of PROJECT is deleted, then any foreign key inherited from PROJECT in a related instance in PROJECT-EMPLOYEE should be set to NULL. The delete does not cascade as in our previous example, and it is not prohibited (as in restrict). The advantage of this approach is that you can preserve the information about the PROJECT-EMPLOYEE while effectively breaking the connection between the PROJECT-EMPLOYEE and PROJECT.

Decisions to use cascade or set null reflect business decisions about maintaining the “historical” knowledge of relationships represented by the foreign keys.

Refining Model Relationships ∙ 55

Additional Relationship Types

Relationships define whether the child entity is dependent or independent of the parent entity and how many instances are related in parent and child entities. As you develop a logical model, you may find relationships that do not fall into the standard, one-to-many relationships discussed in previous chapters. These relationships include:

♦Many-to-many relationships. A relationship where one entity <owns> many instances of a second entity, and the second entity also <owns> many instances of the first entity. For example, an EMPLOYEE <has> one or more JOB TITLEs, and a JOB TITLE <is applied to> one or more EMPLOYEEs.

♦N-ary relationships. A simple one-to-many relationship between two entities is termed binary. When a one-to-many relationship exists between two or more parents and a single child entity it is termed an n-ary relationship.

♦Recursive relationships. Entities that have a relationship to themselves take part in recursive relationships. For example, for the EMPLOYEE entity, you could include a relationship to show that One EMPLOYEE <manages> one or more EMPLOYEEs. This type of relationship is also used for bill-of-materials structures, to show relationships between parts.

♦Subtype relationships. Related entities are grouped together so that all common attributes appear in a single entity, but all attributes that are not in-common appear in separate, related entities. For example, the EMPLOYEE entity could be subtyped into FULL-TIME and PART-TIME.

Each of these relationship types is discussed more fully later in this chapter.

56 ∙ Refining Model Relationships