The ORM Foundation

Hey

I wanted to create model where Commander:

- has a signature right (only he can signe papers and there could be more then one paper)

- could be chief of exercise (one to many)

- appoints chief of exercise if he himself is not that chief of exercise (could appoint many chiefs)

Chief of exercise:

- could be commander (only one)

What I was not able to show in this diagram was that they both (chief and commander) have signature rights, but only one of them can signe it. Actually I am not sure that "Commander has signature right" is elementary fact at all, but let's assume that there could be fallow on with fact "Paper has signature". So the entity could be "signature" with entity type signature right....or?

Is there any simpler way to show Commander and Cheif realationship?

V.K

I suggest that you apply CSDP step 1 as described in Terry's book from page 64 onwards.

Here is what seems to be a relevant extract from page 65:
"Universally quantified conditionals ... may be catered for by subset constraints or derivation rules."

So you could model "Commander" and "Chief of Exercise" as subtypes of "Signatory" and then put an exclusion constraint between the two subtypes.

Ken

Thank you Ken

This resolves my first dilemma.

V.K

Ken Evans:

So you could model "Commander" and "Chief of Exercise" as subtypes of "Signatory" and then put an exclusion constraint between the two subtypes.

This doesn't work because a commander can be a chief of exercise, so the subtypes cannot be exclusive. Using subtype is part of a workable approach here, but there are other things that will help as well.

 -Matt

V.K.,

There are a few things that could help you with this model.

1. You need to do some subtyping. Both Chief and Commander should share a supertype. (I used Officer).
2. You need an Exercise entity to relate to. This is suggested by two of the entity type names.
3. 'has signature right' is really a unary fact type, not a binary. Note that you can still objectifying the unary and add details about the right to sign (was granted by, granted on date, etc).
4. Your 'not' binaries are redundant, derivable, and incorrect. They are definitely not 1-1. There are many commands who did not appoint a given chief of exercise.
5. Chief of exercise is really an objectification of 'Officer leads Exercise', but you don't show the underlying relationship. There are also easier ways to do this than going directly to the objectification

If you're willing to record an officer appointing themselves, then this is can be done as shown below. This has the Commander as the signatory, but is offered as a starting point.

You can model this other ways to not record the commander appointing themselves, but I don't see much reason to. If you make the appoints fact type optional for an exercise then you can derive a fact type that the officer appoints themselves, or you can introduce another fact type for the commander to lead the exercise themselves. I don't like the derived approach here from a universe-of-discourse perspective (you want to explicitly record who is leading the exercise), and I don't like the second fact type approach because it is essentially redundant with the other fact type. So, just let the command appoint themselves.

-Matt

Thanks Matt

I tried to create model your way. Unfortunately I have three problems:

1) Under ternary you have red line connecting two ternary parts. I looked all tutorials, but could not find how to create this type on line (subset constraint I guess).

2) Between Commander-Officer you have Subtype connector. In your model it is solid. In my model it is dashed. Why is that?

3) My equality constraints are showing errors under verbalization. Maybe it is because I have not resolved my first problem yet.

But other verbalizations seems quite promising.

VK

Hey

I already found myself answer to the first question. But 2 and 3 are still unresolver.

V.K

 So now I have only two errors with equality constraints. 

Model Error: Constraint 'EqualityConstraint1' does not have enough role sequences.
Model Error: Sequence '1' of constraint 'EqualityConstraint1' in model 'ORMModel1' requires a join path.

The only visual difference what I can see is the position of mandatory role dot. But as I understood this is just a matter of visual thing.

V.K

 Well, maybe I still did something wrong, because it is not what I really wanted to create. 

For each Commander and Exercise,
that Commander appoints some Officer to lead that Exercise if and only if some Officer that is that Commander leads that Exercise.

Basically for me it means, that each officer must be commander - but it is not true. Only few of them actually could be commanders.

The next sentence doesnt make sence as well:

I went back to the initial model.

Maybe if I dont use the mandatory role dot then it is possible that commander and Chief of exercise relationship is more flexible and I don't have to show that only one of the fallowing holds.

Off-course the problem that Commander can not appoint himself as chief of exercise still persists.

V.K

V.K.

You have to be careful entering set comparison constraints (subset, equality, and exclusion) that you properly define multiple sequences. When the constraint is selected, you'll see the roles shown with two numbers in sequence.column format. Your constraints in this case should have two sequences (indicated by the first number) and two columns (indicated by the second number).

When you enter a set comparison constraint you finish a sequence with a double-click, which then starts a new sequence. In most cases, each sequence will be defined within a single fact type. If a sequence crosses fact types, then it requires a join path. The latest NORMA creates these join paths for you in basic cases; the facilities to enter more complex join paths have not been released yet.

In your case, it looks like you have entered all four rows without starting a new sequence, so you see roles 1.1,1.2,1.3,1.4 when you select the constraint. You have one sequence (you need at least two, hence the first error), and that sequence spans a non-trivial join path (hence the second error).

To activate a sequence for editing, first select the constraint, then double click a numbered role from that sequence. Control-click will remove a role from the sequence, click adds a role, control-double-click removes a role and commits the sequence, and double-click adds and commits the sequence. You will also see these instructions on the tool tip you get when the constraint editor is active and you hover over the constraint shape.

This is all covered in the NORMA tutorials as well.

-Matt

V.K.

You're making progress, but there are still some odd things here:

1. There is definitely a subtype hierarchy implied here. Any time you are tempted to use 'is' as a fact type reading, you should probably be looking for a subtype system. Subtyping systems can be very quite complex. You do not need a direct subtype as I showed, so Chief and Commander could both be subtypes of another shared supertype. Generally in a system like this you will have several layers of subtyping (Soldier is an EnlistedSoldier or an Officer, Officer is a Commander, etc)
2. With the subtypes in place as in my model, the two individual 'leads' predicates are derivable from the first.
3. All ORM fact types are elementary, so you never have 'Commanders lead Exercise' as a fact type. You simply have 'Commander leads Exercise' populated multiple times. So, Commander(s) as the name of an entity type is highly suspect. Also, the 'are' reading implies a plural fact type, which again indicates a non-elementary state and suggests the uses of a many-to-many fact type instead of the many-to-one relationship.
4. Although 'has signature right' is a valid fact type, this does not implied that the Commander signed for a given exercise. This would need to be expressed in another binary fact type between Command and Exercise. The Commander role of the new fact type would have a single column subset relationship with 'has signature right'.

-Matt

BTW, here are the verbalizations I got for the two equality constraints in my model. These will depend somewhat on sequence and column order used for entry.

For each Commander and Exercise,
  that Commander signs for that Exercise if and only if that Commander appoints some Officer to lead that Exercise.

For each Officer and Exercise,
  that Officer leads that Exercise if and only if some Commander appoints that Officer to lead that Exercise.

One thing to bear in mind about that "is a" heuristic when applying it to determining a sub-type is that it should probably be worded as "is ALWAYS a" in order to help avoid casting what are "roles" as subtypes.

So... while the following are subtypes:

Automobile is always a Vehicle

Truck is always a Vehicle

Motorcycle is always a Vehicle

 ...the following are more "role"-like:

Truck is a DeliveryVehicle

The guideline that I use in distinguishing between roles and sub-types is whether or not the sub-type is time-bounded.  So if there is really a beginning or ending date associated with it... "Truck is a DeliveryVehicle as of DateTime"... you are probably looking as a role rather than a true sub-type.

 For what it's worth...

Hi Brian,

Thanks for the additional feedback.

Terry addresses this distinction in his discussion of rigid subtypes in section 10.3 of his book. However, he does not recommend using a fact type pattern for non-rigid subtypes and a subtype pattern for rigid subtypes only. He also discusses various subtyping patterns for transitions between non-rigid subtypes.

Of course, the notion of rigidity is not limited to subtyping patterns. Fact instances are also frequently rigid in business situations. For example, in banking, the type and number of a bank account is fixed over time, as are all lines in an account ledger (you can enter a correction line, but not change the original).

All rigidity (whether for subtypes or fact types) is considered a dynamic constraint because rigidity concerns transitions between states by limiting those transitions. Since dynamic constraints are necessarily overlaid on a static structure, and can conceptually be applied to either fact type or subtype relationships in the model, the notion of rigidity is generally not something I would consider when determinining if I should model with a subtype or fact type.

From a NORMA perspective, we're currently working out final kinks in the formal aspects of using role paths (conceptually a restricted branching path through related fact types in an ORM model) to formalize fact type derivation rules, subtype derivation rules, constraint join paths, and constraints over restricted contexts. Once we've happy with our formalization we'll spend more time looking conceptually at dynamic extensions to this system while we're implementing mapping the static constructs to different implementation targets (primarily relational). We'll then add formal rigidity annotations along with the other dynamic constructs. So, we will have rigidity and other dynamic constructs in the future, but we need to nail specification and mapping of the static constructs first.

Brian, as you've been playing this game on real-world projects for a while, please jump back in here and provide additional point-of-view.

-Matt