Part 3 of a Continuing Series
In many ways, architects and database modelers perform very similar roles. Both meet with end users to ascertain their needs and then design a solution. In the case of an architect, the design specifications are called a blueprint. In the case of a database modeler, the design is called a data model.

However, while architects and builders long ago agreed on one universal standard, the IT industry has not been as lucky. Unfortunately, there are numerous data modeling notations including CASE*Method, Chen, IDEF1X, object-role modeling (ORM) and others. While each notation has its pros and cons, they all accomplish the same goal. They display a graphical model of a database.

Car Rental Database

Since each notation is capable of modeling a given database but in a different manner, this article will show how IDEF1X, Chen and PowerDesigner all model the same database. This will allow you to compare and contrast the three notations and understand the major syntactical differences.

The database to be modeled is for a car rental agency interested in tracking the rental of its vehicles. The database will need to track customers, vehicles, agents and the rental agreements. The attributes for each entity can be seen in Figure 1, Figure 2 or Figure 3. In terms of relationships, a rental agreement must specify one and only one customer, one and only one vehicle, and can optionally specify an agent.

IDEF1X

In order to standardize notation for its projects, the U.S. Air Force developed the IDEF1X notation. Since its development, the notation has gained popularity and is a requirement for many U.S. government projects and serves as the basis for ERWin.

The IDEF1X notation displays entities as rectangles with either squared or rounded corners. If the corners of the entity are rounded, the entity is a dependent one. That is, the primary key of the entity includes at least one foreign key. In contrast, independent entities use squared corners. As in many other notations, relationships are shown as lines between the entities. Solid lines are used for identifying relationships (i.e., the relationship is part of the primary key of the entity), while dashed lines show non-identifying relationships. For example, Figure 1 shows that each entity is an independent one (i.e., squared corners) since the primary key of each entity does not include a foreign key. In addition, each relationship is non-identifying since dashed lines are used.

Cardinality and optionality in IDEF1X are noted by the use of solid circles, open diamonds and the characters "P," "Z" and "1" on each end of the relationship line. If one end of the line does not have one of these special characters, the relationship is interpreted to mean "one and only one." For example, RENTAL AGREEMENT can include one and only one CUSTOMER and each CUSTOMER can be in zero, one or more RENTAL AGREEMENTS. If the letter "P" was displayed next to the solid circle, each CUSTOMER would need to be in at least one RENTAL AGREEMENT (i.e., one or more). Specifying an optional one-to-one relationship is done via an open diamond or the letter "Z." For example, in Figure 1, the AGENT-RENTAL AGREEMENT relationship shows that each rental agreement can specify zero or one AGENT.

Chen

In the middle of the 1970s, Peter Chen invented entity-relationship modeling and developed a notation that relies on rectangles, circles and diamonds. The notation is fairly simple and shows entities as rectangular boxes, just like the other two notations shown here. However, rather than list the attributes inside of the entity box, Chen places them in circles connected to the entity. For example, in Figure 2, you can see that the VEHICLE entity has five attributes: VIN number, make, model, color and YTD revenue.

In contrast to IDEF1X and PowerDesigner, the Chen notation models relationships as diamonds. Figure 2 shows that VEHICLE, CUSTOMER and AGENT are all related to the RENTAL AGREEMENT entity. The cardinality and optionality of the relationship is specified on the entity side of the relationship. Rather than use circles or crow's feet, the Chen notation simply specifies the minimum and maximum cardinality. For example, the relationship between VEHICLE and RENTAL AGREEMENT can be read as, "Each VEHICLE must be in zero or more RENTAL AGREEMENTS, and each RENTAL AGREEMENT must specify one and only one VEHICLE." Likewise, the AGENT-RENTAL AGREEMENT relationship shows that the specification of an AGENT is optional since the cardinality on the RENTAL AGREEMENT side is "(0,) 1."

PowerDesigner

Sybase's PowerDesigner product, formerly known as S-Designor, uses a notation that has features of both the James Martin notation and IDEF1X. Like IDEF1X, PowerDesigner displays entities as rectangles with attributes listed inside. However, unlike IDEF1X, PowerDesigner does not differentiate between dependent and independent entities. In addition, PowerDesigner places the entity name inside of the box. The primary keys are underlined and appear with all of the other attributes.

Relationships are shown with solid lines connecting the two related entities. The relationship line is typically annotated with a verb phrase that describes the relationship. Cardinality and optionality are specified at each end of the relationship line with open circles, crow's feet and/or tick marks. For example, the tick mark on the VEHICLE side of the VEHICLE-RENTAL AGREEMENT relationship means that a rental agreement can specify one and only one vehicle. The open circle and crow's foot on the same relationship line documents that a vehicle will be involved in zero or more rental agreements. Likewise, the tick mark and open circle on the AGENT side of the AGENT-RENTAL AGREEMENT relationship means that an agent is optional (i.e., zero or one) on rental agreements.

Conclusion

Regardless of whether lines are solid or dashed, attributes are displayed inside or outside the entity, or cardinality is modeled with crow's feet or solid circles, each notation is able to accurately and successfully model the car rental database. In many ways, the notation is superfluous as long as the notation is able to model your needs. Therefore, the next time two developers are at the water cooler arguing the relative merits of IDEF1X vs. Chen vs. ORM and end up demanding your opinion, just respond by asking them, "Which language is better? English, Mandarin or Greek? "

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access