Validating the Design of the Logical Model

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 reads 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, verb phrases do provide 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 analysts and subject matter experts is one of the primary methods of verifying that it correctly captures the business rules.

3–6 ERwin Methods Guide

Data Model Example

Data Model Example

The following model of a database was constructed for a hypothetical video store. A copy of the logical model of this diagram appears below.

CUSTOMER

Subject Area

EMPLOYEE

Subject Area

Data Model of 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 a rental rate. Each MOVIECOPY 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.

■Each MOVIE-RENTAL-RECORD also records a due date for the movie and a status indicating whether or not it is overdue. Depending on a CUSTOMER’s 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 accept only cash.

Constructing a Logical Model 3–7

Data Model Example

■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 MOVIE-COPY. 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, you not only can get an idea of what a database for the business should look like, you 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.

3–8 ERwin Methods Guide

Chapter Designing a Key-Based Data

4 Model

A Key-Based Model is a data model that fully describes all of the major data structures that support a wide business area. The goal of a key-based model is to include all entities and attributes that are of interest to the business.

As its name suggests, a key-based model also includes keys. In a logical model, a key identifies unique instances within an entity. When implemented in a physical model, a key provides easy access to the underlying data.

Basically, the key-based model covers the same scope as the ERD but exposes more of the detail, including the context in which detailed implementation level models can be constructed.

Keys

Key-Based ERD Model

Designing a Key-Based Data Model 4–1