relationships between related entities. Or, the business must keep additional facts about the many-to-many relationship, such as dates or comments, and the result is that the many-to-many relationship must be replaced by an additional entity to keep these facts. You should ensure that all many-to-many relationships are fully discusssed at later modeling stages to ensure that the relationship is correctly modeled.

Validating the Design of the Logical Model

If you choose your verb phrases correctly, you should be able to “read” a relationship from the parent to the child using an “active” verb phrase. One of the previous examples read as:

A PLANE FLIGHT <transports> many PASSENGERs.

Verb phrases can also be read from the perspective of the child entity. You can often read from the child entity perspective using “passive” verb phrases. For example:

Many PASSENGERs <are transported by> a PLANE FLIGHT.

Because a data model exposes many of the business rules that describe the area being modeled, reading the relationships helps you validate that the design of the logical model is correct. Verb phrases provide a brief summary of the business rules embodied by relationships. And although they do not precisely describe the rules, they let the person looking at the model get an initial sense of how the entities are connected. It is a good practice to make sure that each verb phrase in the model results in valid statements. Reading your model back to the business is one of the primary methods of verifying that it has correctly captured the business rules.

24 ∙ Constructing a Logical Model

Data Model Example

ERwin includes a model of a database constructed for a hypothetical video store. A copy of the logical model in the MOVIES diagram appears below.

CUSTOMER

Subject Area

EMPLOYEE

Subject Area

Data Model for a Video Store

The data model of the Video Store, along with definitions of the objects presented on it, makes the following assertions:

♦A MOVIE is in stock as one or more MOVIE-COPYs. Information recorded about a MOVIE includes its name, a rating, and rental rate. Each MOVIE-COPY has its general condition recorded.

♦The store’s CUSTOMERs rent the MOVIE-COPYs. A MOVIE- RENTAL-RECORD records the particulars of the rental of a MOVIE-COPY by a CUSTOMER. The same MOVIE-COPY may, over time, be rented to many CUSTOMERs.

Constructing a Logical Model ∙ 25

♦Each MOVIE-RENTAL-RECORD also records a due date for the movie, and a status indicating whether or not it is overdue. Depending on his or her previous relationship with the store, a CUSTOMER is assigned a credit status code which indicates whether the store should accept checks or credit cards for payment, or take only cash.

♦The store’s EMPLOYEEs are involved with many MOVIE-RENTAL- RECORDs, as specified by an involvement type. There must be at least one EMPLOYEE involved with each record. Since the same EMPLOYEE might be involved with the same rental record several times on the same day, involvements are further distinguished by a time stamp.

♦An overdue charge is sometimes collected on a rental of a MOVIECOPY. OVERDUE-NOTICEs are sometimes needed to remind a CUSTOMER that a tape needs to be returned. An EMPLOYEE is sometimes listed on an OVERDUE-NOTICE.

♦The store keeps salary and address information about each of its EMPLOYEEs. It sometimes needs to look up CUSTOMERs, EMPLOYEEs, and MOVIEs by their names, rather than by their “numbers.”

This is a relatively small model, but it says a lot about the video rental store. From it, we not only can get an idea of what a database for the business should look like, but we also get a good picture of the business. There are several different types of graphical “objects” in this diagram. The entities, attributes and relationships, along with the other symbols describe our business rules. In the following chapters, you will learn more about what the different graphical objects mean and how to use ERwin to create your own logical and physical data models.

26 ∙ Constructing a Logical Model