Object Role Modeling (ORM)

Another method for conceptual modeling, called Object Role Modeling (ORM), has been around since the seventies, but is still relatively unknown to most people. It can be of great use to you in your work, however. While the class diagrams of UML are used primarily for the design of classes and the relationships between them, ORM is used as a tool for information and rules analysis. You use it to analyze and document the information you handle in your system.

In ORM, the application world is represented as a set of objects that perform different roles. You could call ORM fact-based modeling because the relevant data is verbalized as elementary facts. You cannot split these facts into smaller facts without losing information.

The objects in ORM are shown as ovals, as you can see in Figure 1-23. The objects are connected by predicates. These appear as sequence boxes in the figure. Each of these boxes corresponds to a role in the relationship. A predicate is only a sentence with object holes in it. If you include the object types with the predicate, you have a fact type. Let us take an example: "SalesClerk created SalesCampaign."

In our model here, each predicate has two roles; the fact type "SalesClerk created SalesCampaign" has one role played by SalesClerk (creating) and another role played by SalesCampaign (being created). In ORM, you can have any number of roles in a predicate. An example with three roles, known as a ternary predicate, would be "ConferenceRoom at Timeslot is booked for Activity."

A fact type may itself be treated as an object type. That way it can also play arole. Take a look at the following fact type: "SalesClerk reviewed SalesCampaign." This can be objectified as "Review," which can participate in the fact type "Review assigned Rating."

An ORM model can include business rules like constraint or deviation rules. A uniqueness constraint is represented as an arrow-tipped bar over a role. This indicates that each object playing that role only does so once. For example, one SalesClerk has only one Lastname.

A dot on a role connector means that the role is mandatory. In this example, you can see that a SalesClerk must have a Lastname and that a SalesCampaign must have a CampaignTitle.

In Figure 1-23, we also have a constraint on Rating. Rating can only have a value between 1 and 10, which is represented by {1..10}.

To show an inclusive-or constraint, you use a circled dot. In our example, this indicates that a SalesClerk must play at least one role, but can play the other, or both, as well. We also have a circled X in our model, which is used here to show that a SalesClerk cannot review the same SalesCampaign he or she created. Verbalizing this results in the following:

• No SalesClerk created and reviewed the same SalesCampaign.

• Each SalesClerk has some Phonenr or has some Email.

From our ORM model, we can generate a database class diagram (see Figure 1-24). The ORM model describes the world in terms of sentences (and rather simple ones as well), whereas a relational database schema describes the same in terms of tables and columns (or attributes).

ORM uniqueness is, of course, mapped to primary key constraints in the database. In this example, our mandatory role constraints are enforced by making columns mandatory, which we show by making them bold and adding foreign key constraints.

As you can see in Figure 1-24, our eight fact types in the ORM model map to four normalized tables in the end.