Introducing Object Role Modeling

Object role modeling (ORM) is a method of creating data models conceptually. Using English-like syntax, you can define a problem or a model that a process follows. Using the definitions that you determine make up the process, you can create a physical data model from the conceptual definitions.

In real life, everything is an object, and objects do things or play roles. Based on this conceptual way of looking at a problem, you can create sentences about the relationships between the objects and roles and how they interact with each other. After you figure out how the roles and objects are related, you can determine what a physical data model should look like.

To look at an everyday process in a conceptual manner, you could create a data model of what you do when you go grocery shopping. Thinking in terms of objects and roles, you would be a Shopper object. Your role as a Shopper is to Buy Products at a Store. A Store is also an object and its role is as a Seller of things. At the Store there are products, which are brought to the store by Shippers. Those Shippers get their Products from Manufacturers.

Therefore, by breaking down what happens when you go to the store, you can start to create a data model that might be used in a purchasing system or e-commerce application. Your model has buyers, sellers, products, manufacturers, and a lot more if you keep going with the conceptual idea.

When creating a model, you use the notions of objects and roles, and then you state facts about those how those objects and roles interact. A fact in the shopping case would be “shoppers buy products.” This is plain English that anyone can understand.

You might be thinking that creating a few tables for a purchasing system isn't such a difficult thing to do. That might be true if you've done it before. However, in many cases, you must understand what a user will be doing in a process to dictate what the data model should look like. But in all cases, having the model available to others can give them a quick insight into what the final application actually will be doing, all by starting out with a conceptual view of a process.

At the end of the modeling process, the ORM tools in Visio create a fully normalized data structure in a database using the objects, roles, and facts that you define. If the requirements change or the model is incorrect, you can both modify the data model in Visio and update the database, or you can update the database and reverse-engineer the database back down to a data model in Visio.

This is a hugely powerful function of Visio. Consider an application that's been around for years, and everyone in the company knows it needs to be rewritten. There's nothing worse than just going headfirst into SQL Server or Oracle and deciding how to change data structures. Using Visio, you can reverse-engineer the existing database into a data model. When the model is in Visio, you can modify the objects, roles, and facts to create a new, well-formed data model based on current requirements. This not only assists in the process of getting the database fixed, but it forces you to understand the business problem at hand in a nontechnical manner.

To understand how you can use this conceptual view of a process to create a data model, you'll go through the creation of an ORM data model using Visio and then build that model into a normalized database.