Last time I discussed the basics of an Object-Role Model. The model we created, however, was simplistic, and didn't give us a way to say that a Person must have exactly one name, or that a person might have more than one phone number. These things are handled by constraints placed on the roles. The application development team has a fairly extensive set of constraints at it's disposal when creating an ORM. I will talk about the most common of these this time.
Internal Constraints are those that apply completely to roles within a single fact type. Let's go back to the Person model we developed last time (slightly modified).
We can attach an internal mandatory constraint to the Person role in the Person has Name fact. This is somewhat counter-intuitive, but constraints apply to the other role in the fact. I attach the mandatory constraint to the Person role in the Person has Name fact. That means that each person must have some name. If I attached the mandatory constraint to the name role, it would mean that for each name, some person must have that name. Another way to say it is that a constraint goes on the controlling or primary role.
This is what this constraint will look line on the diagram:
We can also attach uniqueness constraints to roles. As with the mandatory constraint, the uniqueness constraint applies to the other role. So to say that a Person may have at most one Name, we will attach a uniqueness constraint to the Person role of the Person has name fact.
The uniqueness constraint will look like this on the diagram:
When combined, these two constraints mean that a person has exactly one name:
What about that phone number? I have multiple phone numbers, my home phone, my cell phone, and a couple of work phones. In addition, my home phone and my work phone numbers could be claimed by other people as well, and some people may not even have a phone number, or it is unlisted and we don't know it. In this case, the Person has Phone Number fact type has no mandatory constraints, and it takes both the person and the phone number to make a unique fact. As an aside here, up until now, I have been using fact type and fact rather interchangeably, but that is not strictly correct. The fact type is an abstraction of the real facts, thus Person has Phone Number is a fact type, and Mark has Phone Number 123-4567 is a fact. The point here is it takes both the person Mark and the Phone Number 123-4567 to make a unique fact, so to add the uniqueness constraint we would add it against both roles simultaneously.
This, for the application development team, is a many-to-many relationship, and looks like this on the diagram:
I will show one final combination today. For the sake of example, suppose that I could only have a single e-mail address, and every e-mail address could only be used by a single person, not reality I know, but what you would have is a one-to-one relationship. In that case you could say it like this: Each person has at most one e-mail address, and each e-mail address is used by at most one person. There are two internal uniqueness constraints here one for the person role, and one for the e-mail address role of the Person has E-mail Address fact type.
These constraints would look like this on the diagram:
As you can see, with just binary fact types and a couple internal constraint types (mandatory and uniqueness), the application development team can model nearly everything that can be modeled on an ER diagram. And you have natural language descriptions of the model that are readable by the business users the solution is being developed for. But wait there's more. I will tell you about external constraints, and reference modes next time.
Internal Constraints are those that apply completely to roles within a single fact type. Let's go back to the Person model we developed last time (slightly modified).
Person has Name
Person has Phone Number
Person has Address
Person has E-mail Address
Person has Phone Number
Person has Address
Person has E-mail Address
We can attach an internal mandatory constraint to the Person role in the Person has Name fact. This is somewhat counter-intuitive, but constraints apply to the other role in the fact. I attach the mandatory constraint to the Person role in the Person has Name fact. That means that each person must have some name. If I attached the mandatory constraint to the name role, it would mean that for each name, some person must have that name. Another way to say it is that a constraint goes on the controlling or primary role.
This is what this constraint will look line on the diagram:
We can also attach uniqueness constraints to roles. As with the mandatory constraint, the uniqueness constraint applies to the other role. So to say that a Person may have at most one Name, we will attach a uniqueness constraint to the Person role of the Person has name fact.
The uniqueness constraint will look like this on the diagram:
When combined, these two constraints mean that a person has exactly one name:
What about that phone number? I have multiple phone numbers, my home phone, my cell phone, and a couple of work phones. In addition, my home phone and my work phone numbers could be claimed by other people as well, and some people may not even have a phone number, or it is unlisted and we don't know it. In this case, the Person has Phone Number fact type has no mandatory constraints, and it takes both the person and the phone number to make a unique fact. As an aside here, up until now, I have been using fact type and fact rather interchangeably, but that is not strictly correct. The fact type is an abstraction of the real facts, thus Person has Phone Number is a fact type, and Mark has Phone Number 123-4567 is a fact. The point here is it takes both the person Mark and the Phone Number 123-4567 to make a unique fact, so to add the uniqueness constraint we would add it against both roles simultaneously.
This, for the application development team, is a many-to-many relationship, and looks like this on the diagram:
I will show one final combination today. For the sake of example, suppose that I could only have a single e-mail address, and every e-mail address could only be used by a single person, not reality I know, but what you would have is a one-to-one relationship. In that case you could say it like this: Each person has at most one e-mail address, and each e-mail address is used by at most one person. There are two internal uniqueness constraints here one for the person role, and one for the e-mail address role of the Person has E-mail Address fact type.
These constraints would look like this on the diagram:
As you can see, with just binary fact types and a couple internal constraint types (mandatory and uniqueness), the application development team can model nearly everything that can be modeled on an ER diagram. And you have natural language descriptions of the model that are readable by the business users the solution is being developed for. But wait there's more. I will tell you about external constraints, and reference modes next time.
Powered by Compendium Blogware
Comments for Creating an Object-Role Model - Part 2 - Internal Constraints