What About ORM?

We read Warren Keuffel's article with great interest. (See "Battle of the Modeling Techniques," DBMS, August, 1996.) Here are a couple of corrections and notes.

First, Figure 1 of the article has one building for each employee; this might be prohibitively expensive for the employee's company, depending, of course, on the number of employees.

We noticed that there was not an ORM model for the example model. If one had been done, and the nine steps of the Conceptual Schema Design Procedure had been applied, then the correct ER model would have been built.

The error in Figure 1 occurs more often than it should, which is exactly why the rigor and quality checks required by ORM should be applied. We find it hard to believe that a company would consider quality and rigor to be confining. One of the objectives of modeling is to provide rigor and quality checks before building the physical system. Surely any of us would question flying in a plane or driving a car that had not been modeled with rigor and quality checks.

A second and third instance should be applied to Keuffel's example:

Fact: Employee works in Building.
Employee with number 1234 works in Building with number 1.
Employee with number 5555 works in Building with number 1.
Employee with number 4658 works in Building with number 2.

Note that we are compelled to correct the above examples because the article implies that a Building has a reference scheme of BuildingID. Therefore, we must reveal the following fact type:

Fact: Building is known by Building_Name.
Building with number 1 is known by Building_Name of "Administration."
Building with number 2 is known by Building_Name of "Music."
Building with number 3 is known by Building_Name of "Computer Science."

Now we know that an employee works in a building with an ID, and a building with a number is known by a name. This lets us document the notion that a building may exist without any employees, because the Computer Science building is allowed to exist without any employees in our sample data. Figure 1 in the article also states that an employee must work in one and only one building.

Based on the above examples and others, it would have been plainly obvious that "Employees work in one and only one Building," at least in this Universe of Discourse, and that "Buildings may be the workplace for zero or more Employees." Rigor and quality checks are needed by businesses hoping to capture the essence of their business in a technology-independent model that is understandable by businesspeople and is also transferable into the technology of the day.

We second Keuffel's statement that when the ORM quality checks are applied, "the resulting data models possess much more integrity than do models constructed without a semantic analysis component."

We created a logical model for the above ORM. In it, we made a correction between the building and employee relationship; it should be non-identifying with a cardinality of "One-to-zero-or-more." Also, both relationships are non-identifying. Figure 1 in the article shows the relationships to be identifying, which is not correct. DepartmentID is not used as part of the primary key for Employee.

Also, there is a contradiction in the EasyCASE depiction of this model in Figure 1. The model uses an identifying relationship from Department to Employee, which means that the Employee entity should be depicted as a dependent entity. Same thing for the relationship from Employee to Building. However, both are depicted as independent entities. The correct mapping is that all of the entities are independent and all of the relationships are non-identifying.

There are abstraction and view mechanisms for ORM that enable the modeler to "hide unwanted detail or to view the same aspects in a different way and hence enable them to focus on the relevant aspects of the global model, and to re-present various aspects from a different perspective." Terry Halpin has written a great deal on this subject, and it is definitely a part of the ORM methodology.

Next, the exploration of object relationships does not require the analyst to complete all nine steps of the CSDP immediately. In practice, it is common to model facts as quickly as possible and then refine the model over time. Keuffel's article seems to imply that all nine steps are done for each fact immediately upon discovery. As with any modeling technique, multiple "refining" passes are done. We are sure that Keuffel would agree with this; we just want to be sure that it is stated.

Also, ER and NIAM came into being at roughly the same time, not ten years apart. In fact, the ORM framework developed by Falkenburg actually predated ER.

Finally, ORM is taught along with SQL to 16- and 17-year-olds in Queensland, Australia. These high school students are able to enter the university with credit in ORM. (This level of study is typically available in U.S. graduate studies.) Because students of this age can create and prove they have solid models, the rigor and quality checks seem to be time well spent. In practice, the use of a consistent and repeatable methodology that is found in ORM establishes a model of high quality. This proves to be a time saver at the start of a project and certainly over the entire life cycle of the system.

All of us must apply the best practices to understanding business systems and other classes of systems. We challenge the readers of DBMS to take a closer look at ORM and discover a "provably correct" methodology. Thank you to DBMS and Warren Keuffel for the article on these three modeling methodologies. We look forward to many more informative articles concerning Object Role Modeling in the future.

Dick Barden
3M (Now an officer of InConcept)
Minneapolis-St.Paul, Minn.

Necito dela Cruz
Coopers & Lybrand (Now an officer of InConcept)
Minneapolis-St.Paul, Minn.

Pat Hallock
InConcept
Minneapolis-St.Paul, Minn.

Warren Keuffel Responds:

One of the difficulties in comparing methods in a magazine article is that inevitably some concepts do not get explained as thoroughly as they should be. Accordingly, I'm pleased that Dick, Necito, and Pat took the time to craft a detailed and thorough commentary.

First, they are correct that I goofed by inadvertently modeling one building for each employee. This was obviously not my intent. The relationship lines should have been drawn as solid lines.

Second, I based the method development chronology on the publication dates of the seminal books for each method.

Third, no ORM model was provided because my copy of Asymetrix InfoModeler crashed repeatedly when I tried to run it under Windows 3.11 and Windows 95. I was unable to get the problem resolved before my deadline.

Finally, I agree with Dick, Necito, and Pat that ORM deserves to become more widely practiced, but just as semantic object modeling is perceived as Wall Data's proprietary method, ORM is perceived as Asymetrix' proprietary method. If more vendors offered ORM tools, its popularity would undoubtedly increase.

- Warren Keuffel