Subtype Relationships

Inclusive and Exclusive Relationships

Unlike IDEF1X, IE notation does not distinguish between complete and incomplete subtype relationships. Instead, IE notation documents whether the relationship is exclusive or inclusive.

In an exclusive subtype relationship, each instance in the supertype can relate to one and only one subtype. For example, you might model a business rule that says an employee can be either a full-time or part-time employee but not both. To create the model, you would include an EMPLOYEE supertype entity with FULL-TIME and PART-TIME subtype entities and a discriminator attribute called “employee-status.” In addition, you would constrain the value of the discriminator to show that valid values for it include “F” to denote full-time and “P” to denote part-time.

In an inclusive subtype relationship, each instance in the supertype can relate to one or more subtypes. In our example, the business rule might now state that an employee could be full-time, part-time, or both. In this example, you would constrain the value of the discriminator to show that valid values for it include “F” to denote full-time, “P” to denote part-time, and “B” to denote both full-time and part-time.

Note: In IDEF1X notation, you can represent inclusive subtypes by drawing a separate relationship between the supertype entity and each subtype entity.

Refining Model Relationships 6–21

Subtype Relationships

IDEF1X and IE Subtype Notation

The following chart illustrates subtype notation in IDEF1X and IE.

Exclusive

Subtype

Inclusive

Subtype

When to Create a Subtype Relationship

To summarize, there are three reasons to create a subtype relationship:

■First, the entities share a common set of attributes. This was the case in our previous examples.

■Second, the entities share a common set of relationships. This has not been explored but, referring back to the account structure, you could, as needed, collect any common relationships that the subtype entities had into a single relationship from the generic parent. For example, if each account type is related to many CUSTOMERs, you can include a single relationship at the ACCOUNT level, and eliminate the separate relationships from the individual subtype entities.

■Third, subtype entities should be exposed in a model if the business demands it (usually for communication or understanding purposes) even if the subtype entities have no attributes that are different, and even if they participate in no relationships distinct from other subtype entities. Remember that one of the major purposes of a model is to assist in communication of information structures, and if showing subtype entities assists communication, then show them.

6–22 ERwin Methods Guide

Chapter

7 Normalization

Normalization is the process of making a database design comply with the design rules outlined by E. F. Codd for relational databases. Following the rules for normalization, you can control and eliminate data redundancy by removing all model structures that provide multiple ways to know the same fact.

The goal of normalization is to ensure that there is only one way to know a “fact.” A useful slogan summarizing this goal is:

ONE FACT IN ONE PLACE!

To provide a basic understanding of the principles of normalization, this chapter includes a variety of examples of common design problems and normalization solutions.

Normalization 7–1