The ORM Foundation

First, as a point of order, if I have an actual MODELING question, as compared to a SOFTWARE question, should I be posting it here, or in another forum?

Second, I'd like some advice with an equality constraint. I've read through the big brown book on this topic, but really am struggling with this. In the attached diagram, I have a PayItemType and a PayItemPrototype. The PayItemType is derived from the PayItemPrototype. Each of these MUST have a PayItemTypeCategory.

The part I'm struggling with is this: the PayItemTypeCategory of each PayItemType MUST match the PayItemTypeCategory of the PayItemPrototype from which it was derived. I cannot for the life of me figure out how to represent this. As you can see, I've attempted to insert an equality constraint, but NORMA complains:

Error 1 Constraint 'EqualityConstraint1' in model 'ORMModel3' has role players in column '1' with incompatible types. 

Error 2 Constraint 'EqualityConstraint1' in model 'ORMModel3' has role players in column '12 with incompatible types. 

Thoughts? Suggestions?

Thanks,

Steve

No problem with posting modeling questions here.

Regarding your "equality constraint" problem.
I don't know much about your UoD but from the terms you are using I infer that it includes something called a "PayItem".
So some facts might be something like:

Prototype(.id) has Property1()
Prototype(.id) has Property2()
Prototype(.id) has Property3()
Prototype(.id) is of Type() 

Note: Draw Payitem(.id) as a subtype of Prototype(.id) , then

PayItem(.id) is paid on Date(date)
Payitem(.id) is for Amount(currency)
and so on...

When you generate the tables, you will find that each "Payitem instance" will have a "Type" column.

In summary, I suspect the problem may be related to the point that you may not yet have got the hang of specifying your models in terms of "elementary facts". FYI, it took me several years to fully internalise the notion of elementary (aka atomic) facts.

But there again, I'm making guesses about your situation which may not be as I have guessed. 

Hope this helps

Ken

Steve,

You need to transpose the rows/columns of your equality constraint. The set comparison constraints (equality,exclusion,subset) require compatible columns, while the editor enters one row at a time. So, use the following gesture to add the equality constraint:

1. Click the equality constraint on the toolbox
2. Click the design surface to add the equality constraint and activate the editor for the first row. Note that if you drag off the toolbox instead of using the click-click gesture, then you'll need to double-click the new shape to activate the editor.
3. Click the top constraint in 'PayItemPrototype is the origin of PayItemType'
4. Double-click the second constraint to commit the first row of the constraint and activate an editor for the second row.
5. Click the left role of 'PayItemPrototype is categorized as PayItemCategory'.
6. Double-click the left role of 'PayItemType is categorized as PayItemCategory'.
7. Press escape or click on the diagram surface to cancel the editor for the next row (which you're not adding).

You will now have an equality constraint without errors.

Note that the second role sequence of the equality constraint contains roles from multiple fact types, so a join path is required to relate the two roles in the path. In this case, the join path is trivial because the opposite role players share an object type. If you open the .orm file as xml, you'll see additional join path xml for the sequence row sequence. Join paths are currently a work in progress, and we have not yet publicly introduced the path editor we've been using internally for several months now. This will allow formal entry of join paths, fact type derivation rules, subtype derivation rules, and restricted constraints (constraints that apply under tighter conditions than 'all role players'). We'll introduce the editor when the verbalization and dynamic validation are complete (in about a month). DDL and other artifact generation for these constructs will follow as the year progresses.

Although the join path in this case is implicit and currently in the model, it is not verbalize, so the verbalization for this equality constraint is currently incomplete:

For each PayItemPrototype and PayItemType,
   that PayItemPrototype is the origin of that PayItemType if and only if that PayItemPrototype is categorized as some PayItemCategory.

does not relate the multiple fact types in the second role sequence and should be

For each PayItemPrototype and PayItemType,
   that PayItemPrototype is the origin of that PayItemType if and only if that PayItemPrototype is categorized as some PayItemCategory and that PayItemType is categorized as that PayItemCategory.

Although some verbalizations with join paths will be close, none of them will be correct until I'm done integrating the join paths into the constraint verbalization. If an implicit join path cannot be automatically generated, then you will see a 'join path required' error in the current tool, but you won't be able to do anything about it.

-Matt

Thanks very much folks, this was very helpful!

Of course, in working through the model some more, and getting to more atomic terms, I ended up not needing the constraint after all, but it was still helpful. :D

Steve