The ORM Foundation

Our use of ORM to help business and technical teams share a common language of concepts is taking off. ORM does just what I need it to do--help us focus on the concepts and not the details. I have run into a situation over and over, and I have never been able to model it satisfactorily. I usually end up adding a business rule note instead. Here is an example of where I think I need to show consistency constraints but am unsure how to do so. I have simplified this example, so please take it at face value and excuse my clumsy prose notation. Simplest (and not very robust) example: Company employs/works for Person. CompanyPerson is many to many. Company operates at/is for Address. CompanyAddress is many to many. Person is assigned to Address. PersonAddress is many to one. Consistency constraints are needed to enforce the idea that a Person must be assigned to an Address that is for the Company the Person works for. In this case, I believe I could show that the Addresses filling "Person is assigned to Address" must be a subset of the Addresses filling "Address is for Company". In a slightly more complex example, I objectify "Company employs Person" as "Employment", and objectify "Company has Address" as "Location". I then remove "Person is assigned Address" and replace it with "Employment occurs at Location", a relationship between the two objectified relationships. This new construct is arguably clearer and more obvious, but not the focus of this post. I still need to denote the following constraint: Employment and Location must be related to the same Company. How do I show this or even describe it? "If a Company employs a Person ('Employment"), and that Company operates at an Address ("Location"), then ...?" This is where I get stuck. I don't know how to visual show it on the diagram and don't know how to describe it in words as a business rule. One more case. Company has Department. Department has Employee. Company has Campus. Campus has Building. Employee works in Building. The constraint I wish to express is that "if an Employee works in a Building on a Campus for a Company, then that Company has the Department that has that Employee". This is similar to the first case except that now the consistency is enforced across multiple topological hops in the diagram. How do I show this? I hope my examples adequately represent the modeling scenarios I consistently see. So far, I have either left out the consistency constraint for clarity, included a verbose and quirky business rule, or tried to show (most likely incorrectly) the actual constraint. I would appreciate others' experience with these modeling situations.

Hi Roger,

Yes, you describe a requirement that is common to many organizations.

It would help a lot if you could post the object-role model on which you are working.
One way is to make a .png or .jpg picture from NORMA and use the "File Attachment add/update option to upload the file.

Can you do this?

Ken

Here is an example

Sorry the formatting was lost on my original post--not sure why. I am attaching two JPGs in two messages. The first illustrates three examples where consistency constraints are (in my opinion) progressively harder to illustrate. The second image is the same idea, but now with objectified relationships.

The second example...

Hi Roger

The constraints you need are called join-subset constraints. These are discussed in Section 10.1 of "The Big Brown Book".

I've tried to attach a diagram for the "Employee works in Building" example, but it doesn't appear in my Post window. If you can see the diagram, then notice that  I've added a subset constraint from the works-in predicate to the Employee and Building roles in the relevant role path. This could be verbalized as: "If an Employee works in a Building then that Employee works for a Department that is of a Company that has a Campus that has that Building". However, in the public domain version of NORMA, I don't think that you can actually specify the role path (even though in this example there's only one possibility).

For the first (no objectification) example you cited involving persons and addresses, you could similarly run a subset constraint from "Person is assigned to Address" to the Person and Address roles in the path "Person works for Company that operates at Address". By the way, should "Person is assigned to Address" be n:1 (as you say) or m:n? Your attempt to objectify this is incorrect, because Employment should be directly related to Address, not Location (and you still need a subset constraint).

Cheers

Terry

I read Section 10.1 again and saw diagrams 10.4(a) and 10.5(a). I think I understand the idea captured in these diagrams now. The highlighting was very helpful in explaining the concepts. I also did not realize that it made sense to connect either end of the subset constraint to multiple roles at the same time. Again, the highlighting in the figures helped me get that idea.

The first diagrams I just made up on the spot, so they aren't particularly rigorous nor do they reflect real situations I am trying to model. No worries there.

I did try to apply the subset constraint to the second diagram (which is from an actual diagram). I ended up with the attached diagram. Regarding the subset constraint, I like the origination at the Legal Entity's Role in "Legal Entity employs Person". I also like the origination at Location in "Persona is located at Location". Location, however, is really "Legal Entity operates at Address", which seems a little odd. Ending the subset on "Legal Entity operates at Address", then gives this attempt at a reading:

"If a Legal Entity employs a Person as Persona, and that Persona is located at a Location, then that Legal Entity must operate at an Address as that Location."

Here I have used the phrase "as" to substitute the objectified relationship's reading. Is there another convention for that?

Incidentally, I did recast "Legal Entity employs Person" to "Legal Entity employs Person at Location", but I didn't like the implications of that formulation. Right now I show that Persona has exactly one Location, but that may be relaxed in the future to be optional (working with the business on that).

Hi Roger,

The main issue with this subset constraint is not the join path, which is trivial in this case and will be filled in by NORMA. The issue is that your roles aren't compatible, which needs to happen as a prerequisite for any join path. The subset sequence (sequence 2 in NORMA) has LegalEntity and Address roles, whereas the superset sequence has LegalEntity and Location roles. Basically, the subset constraints need to attach to roles in the objectification-implied link fact types to be compatible (see page 442 in Terry's BBB for information on link fact types). Unfortunately, at this point NORMA does not have a facility to display shapes for these implied fact types, so the only alternative is to use the expanded coreferenced form of the objectification. This gives you the attached model, and a subset constraint verbalized as If some Persona is located at some Location then that Location hosts some LegalEntity that employs that Persona.

-Matt

As a follow on this, this is a preview of the next NORMA release, which will allow you to drag the implied fact types out of the model browser and apply the constraints directly. This should make it much easier to apply this type of constraint to the model. The implied fact types are shown with a dash pattern.

-Matt

I like this new implied fact type notation. Regarding the issue at hand, I have put many miles under my feet from the clues already posted, especially now that I finally get how to apply join constraints using the subset indicator.

Since I am using the Visio stencil (on purpose since I share my models with many peers), I hope there will be a similar update to the Visio Stencil to reflect implied fact types, and some accompanying documentation to explain their use to the slow ones like me.

Thanks to all who helped me understand how to make some progress in this very important model for my company.

Hi Roger,

Terry has brought to my attention your request regarding the ORM2_Draw2 Visio stencil. I've just uploaded a new version (11) that adds a "link binary" fact type shape. Also I added a couple of paragraphs to the readme file, in the section on "Use of the new features", regarding this shape and its use.

Best regards,

Andy Carver

Thank you for posting the new stencil. I took a look at the readme regarding link fact types, and I re-read the referenced section in "the book" (pg. 440 an on). I think I understand the value of using link fact types to illustrate consistency constraints that would be problematic without this longhand notation.

Using dashes to indicate a link fact type will take a little getting used to, as will their use overall, but I think it is a useful addition. I will start another post regarding a couple of other ideas. Thanks again. Roger Cass