The ORM Foundation

Questions about combining Rings and Subtypes in nORMa

The figure below is a simple model created for testing only (using the 04/08 drop - build 1290). The model shows no errors.
(Editors Note: click on the diagram to see all of it.) 

The first questions concern the legitimacy of this structure as an ORM implementation of a business rule.   Given the model as shown, which (if either), of the following UofD business rules are implemented, fully or in part?

• a) A manager is someone who supervises other employees.
• b) Only managers supervise other employees.

I think some additional constraint is required to implement "Rule b"; have a suggestion?

A related question: is it legitimate to combine Ring Fact Types with Subtypes in this way?

Assuming it is legitimate (and assuming it is the best way to model an actual domain - wholly unfounded assumption), shouldn't this be easier to construct in nORMa?  Selecting the Objectified Predicate always brings up the base Fact Type - rather than the OP name, in the Fact Editor.  The only way I could add the rule about KeySets, was to create a unconnected Fact Type like "Temp is issued KeySet(.id)" then delete the Temp object and connect the first role to "Manager."  Once done, it looks Ok in the Object Browser.

 The second figure include is of the Employee table from the Relational View (I didn't include the whole RV, because other unrelated pages in this test project obscure the issue).  Here giving meaningful names to the roles in the Ring Fact Type provides the only indication of instances of Employee that manage/is managed (but note that the term "Manager" is not seen in this or any other table).

Comments welcome,

BRN..

Hi Brian,

Can't see the diagram !
Ken

Hi Ken,

I can't see them either.  There should have been two .pngs.  I had them in a docx that I Word-pasted.  I also tried adding them with insert image option.  Must have mixed up something.

I suggest you zap the OP and these replies; and I'll repost it another time - nothing there that won't keep (and I still have the docx).

BRN..

Hi Brian,

Send me the .orm file and the .docx (or post them to the NORMA library) and I'll edit your post and put the images in.

Ken

Hi Brian,
I have added a pdf file to your original post and pointed to it in the text.

Ken

 Brian,

 Your model is semantically invalid because you have objectified the "Manages" relationship as "Manager". The Manages fact type is not a Manager or a subtype of Employee. You need to separate these two things into a Manager subtype, and a Manages fact type.

The ring constraint then works nicely, but if you want to require that every employee except the CEO has a manager, then you also need to add a further subtype (or unary role) for CEO, and place an exclusive-or constraint over the subordinate&CEO role pair.

Hi Clifford,

Thanks for your contribution. As a suggestion, if you added a diagram to your post, this would help people who don't understand ORM as well as you do to more easily understand your point.

You can add a diagram by firstly creating a .png file and then uploading it using the "Add/Update" button on the reply options tab as shown below.

Ken

Ahh, thanks Ken, I looked for a place I could upload a nORMa file, but didn't find it. I'll do that now. 

Well, I tried, but the Options pane doesn't contain the upload buttons in this forum as it does in others. Do you need to enable this feature for each forum, Ken? 

Curious!
I just checked all the permissions and all seems to be OK.

Please click the "more options" button which you should see at the bottom of the topic list in a forum and tell me what you see.   

Just to make sure: you must first click on the "reply" button and then you should see the upload option as I showed it in the earlier post.  

The attachment shows how I model the Manager-Employee relationship. I couldn't add it by editing my previous response. The CQL for this is as follows (note the unverbalised external mandatory-exclusion constraint):

vocabulary EmployeeManagerCEO;

/*
 * Value Types
 */
PersonName is defined as VariableLengthText();

/*
 * Entity Types
 */
Person is identified by PersonName where
    Person has exactly one PersonName,
    PersonName is of at most one Person;

Employee is a kind of Person;
Employee is manager;

Manager is a kind of Employee;
Employee is managed by at most one Manager [acyclic],
    Manager manages at least one Employee;
Manager is CEO;

CEO is a kind of Manager;

/*
Constraints:
    REVISIT: mandatory exclusion over (Employee) in 'Employee is managed by Manager', (Manager) in 'Manager is CEO'
 */
 

 Hi Clifford,

Yes, you caught a poor choice of terms, on my part - an objectification of "supervises" would be something like instances of supervision (not something worth tracking; and not a subtype of Employee).  I'm glad you caught that, and also that you provided a more reasonable example for using Ring and Subtype constraints.  I created my example, not to solve a real problem, but only to test that release of nORMa.  I'd just try stuff to see what would blow up; and was a bit surprised that the Ring and Subtype combination didn't raise a error.  I should have made sure the example was semantically valid; as that makes for a better example and one easier to validate.

I'll try to revise that example, so that it fits the same form, but makes more sense.  Your example shows using the Ring after establishing the Subtype - something that hadn't occurred to me. I'll try to revise my example, and work it both ways.  My guess is that it will resolve the same either way; but will want to check on which way is more expressive, and which would be easier to modify (as underlying business rules change).  I'll also push both through to a DB, to check on practical implications.

You'll noticed I named the roles in the RC in my example.  I started doing that after I found that physical DB creation would crash without the distinction.  I don't think I've tried not naming RC roles with later releases, but should.  Pushing through to a DB doesn't prove or disprove a point in ORM theory; but it can point out practical limitations.

At least you revived a dormant thread, and helped answer a question about combining constraints.  Thanks,

BRN..