In our natural, speaking language, we use statements of fact or, in logic, propositions about entities of interest, asserted to be true. The idea behind Object Role Modeling (ORM) is that you simply write down all the facts. The tool then converts those facts to a conceptual ORM diagram and produces logical and physical diagrams out of that ORM diagram. ORM pictures the world in terms of objects that play roles. Data elements are not combined into tables a priori. Descriptions of data-element relationships serve as input to a table-building algorithm. ORM thereby incorporates normalization the methodology.In ORM, you distinguish between two object types: entity and value objects. You can easily distinguish them. Value types are identified solely by their values. For example, name is identified by the value “Jenny” or “Jim” or whatever the name is. You identify entity object types by their associated value types. Entity types are abstract. You cannot write a customer in a table unless you identify a concrete customer through associated value objects like customer identification, customer name or similar. You can imagine that value types map to attributes and entity types map to entities. This is more or less true; value types can never translate to entities. However, entity types can be absorbed as attributes into major entity types. For example, you could define an entity type “Sex” with associated value object “Sex Value”, possible values “Male” and “Female”. The only role of this entity object would be to denote sex of a customer. In this case, the tool should absorb the entity object to an attribute of the final entity “Customers”.
Every entity type needs a unique reference schema. You have to be able to find out a concrete instance of the “Customers” entity type, i.e. a concrete customer. You can have multiple unique reference schemas. You define one of the unique reference schemas as the primary reference schema. Of course, this is going to map to the primary key of a table.
ORM verbalizes the relevant data as elementary facts. ORM modeling is actually writing down the facts. In ORM, you represent an entity object as an ellipse with solid border and a value object as a dotted or dashed ellipse. Relationships between objects (i.e., roles the objects play) are represented by lines and subdivided boxes that establish connections. For example, I have two elementary facts here:
- Customers are identified by CustomerId, or, turned around, CustomerId identifies Customers.
- Customers have CustomerName, or, turned around, CustomerName names Customers.
Here is an ORM model that shows these two facts:
When you translate this model to an Entity-Relationship (ER) model, you get:
As you can see, the ORM model is very detailed. This is why it enables you to document nearly all possible business rules, and this is why ORM is extremely useful for conceptual modeling. You can collapse the model here and there. First thing you can do is you can collapse the primary reference schema association between an entity and a value object in a named ellipse. For example, the following ORM model is equivalent to the first ORM model:
I hope by now you already became curious how you can make an ORM model. I guess you know how you can create an ER diagram in MS Visio or any other modeling tool. For Object-Role Modeling, you need the Enterprise Architect edition of Visio. Note it ships with Visual Studio, not with Office like Professional edition. In addition, you can use the NORMA open-source plug-in to Microsoft’s Visual Studio.NET 2005. NORMA requires at least the standard version of Visual Studio 2005. It is in pre-beta stage (therefore, I would suggest you to test it in a virtual machine). You can find the description and the download link for NORMA in the ORM.NET site, the official site for conceptual modeling by Dr. Terry Halpin.
To help you to make a jumpstart to ORM, I used Wink (http://www.debugmode.com/wink/) to record this short clip (.swf file, you need Macromedia Flash Player to see it) showing how you can create a simple ORM model. You will find it here.
Besides projects, I spend about half of the time on training and mentoring. I am the founder of the Slovenian SQL Server and .NET Users Group. and the main author or coauthor of eleven books about databases and SQL Server. I also developed many courses and seminars for SolidQ.
Latest posts by Dejan Sarka (see all)
- Python for SQL Server Specialists Part 4: Python and SQL Server - April 24, 2018
- Python for SQL Server Specialists Part 3: Graphs and Machine Learning - April 11, 2018
- Python for SQL Server Specialists Part 2: Working with Data - March 22, 2018