The object role model is a simpler approach to creating the information model that the application development team will use to create the physical database for IT solutions. It centers around a single structure called the fact type. Here are a few fact types for a simple address book application.
This is nice, and easily understood, but I like diagrams, and that is simple too. The tools I have seen allow typing fact types in a natural language manner, or by adding them graphically to a diagram like this.
Note that there are three different symbols: the oval with a solid line which represents an entity, the oval with a dashed line which represents a value, and a rectangle with two boxes which represents a fact (sometimes called a predicate). It is up to you to determine if an object is a value or an entity. There are a couple of ways to do this. One is if you can write it down, then it is a value, otherwise it is an entity. For example, you can write a person's name on paper, but can not write the person. Another way to determine this is if it has components, then it is an entity, otherwise it is a value. An address could be written down, but sometimes we want o refer to a component of the address, so we make that an entity, and the individual components of the address become values like this:
Or graphically
You get the idea. As an exercise you might want to try extending the model to allow states in different countries.
That's it. An Object-Role Model is built using simple facts. In this case, and most cases, the application development team can use binary facts (ones that reference or or two objects playing two roles). The tools I have seen allow n-ary fact types as well, but the uses for these are uncommon, and in my experience can be replaced by binary fact types. In my next post I will discuss uniqueness and mandatory fact types
Person has First Name
Person has Last Name
Person has Phone Number
Person has Address
Person has Last Name
Person has Phone Number
Person has Address
This is nice, and easily understood, but I like diagrams, and that is simple too. The tools I have seen allow typing fact types in a natural language manner, or by adding them graphically to a diagram like this.
Note that there are three different symbols: the oval with a solid line which represents an entity, the oval with a dashed line which represents a value, and a rectangle with two boxes which represents a fact (sometimes called a predicate). It is up to you to determine if an object is a value or an entity. There are a couple of ways to do this. One is if you can write it down, then it is a value, otherwise it is an entity. For example, you can write a person's name on paper, but can not write the person. Another way to determine this is if it has components, then it is an entity, otherwise it is a value. An address could be written down, but sometimes we want o refer to a component of the address, so we make that an entity, and the individual components of the address become values like this:
Address has Street Address
Address has City
Address has State
Address has Postal Code
Address has City
Address has State
Address has Postal Code
Or graphically
You get the idea. As an exercise you might want to try extending the model to allow states in different countries.
That's it. An Object-Role Model is built using simple facts. In this case, and most cases, the application development team can use binary facts (ones that reference or or two objects playing two roles). The tools I have seen allow n-ary fact types as well, but the uses for these are uncommon, and in my experience can be replaced by binary fact types. In my next post I will discuss uniqueness and mandatory fact types
Powered by Compendium Blogware
Comments for Creating an Object-Role Model - Part 1