The ORM Foundation

Hi,

I'm hoping someone with more experience with ORM than me, and/or a better grasp of logic, can help with the following scenario (which is part of an ORM model with the Objects' and Facts' text changed - hence some of the Facts may appear a little strange).

I have a Cat Show where people may show their cats.  Each Person must sponsor a Pennant.  The constraint that I want to show in the model is: the Colour of the Pennant sponsored by a Cat's Person must be the same Colour as the Collar worn by that Cat.  A diagram is attached.

I have tried a number of variations of the constraint, and although the verbalisations of some are along the lines I'm after; to me, none are clear enough to accurately describe the desired constraint.  For examples, I can get:

"For each Colour, that Colour describes some Pennant if and only if that Colour describes some Collar." [1]; or

 "For each Colour and Person, that Colour describes some Pennant if and only if that Colour describes some Collar." [2a]; or
"For each Colour and Cat, that Colour describes some Pennant if and only if that Colour describes some Collar." [2b]; or

"For each Colour and Cat and Person, that Colour describes some Pennant if and only if that Colour describes some Collar." [3].

[2b] appears the most succinct, but I don't know whether it is correct and sufficient.  Thoughts, anyone?

Thanks, Peter

ps If the picture doesn't appear after this is posted, can someone tell me how to include a picture? (I've tried paste from Word and paste from clipboard and "Insert/edit image" button, and can't see any results.

Hi Peter,

PeterC:

ps If the picture doesn't appear after this is posted, can someone tell me how to include a picture? (I've tried paste from Word and paste from clipboard and "Insert/edit image" button, and can't see any results.

You are right, it will help a lot if you can show your picture.
This is the recommended way to do it:

1: Make a file of your image. (I use Snagit to create a .png)
2: Position your cursor where you want the image to display. (You can only upload one image per post. If you want to show more than one image, first make a mosaic in a Word table, post your images into the cells and then make a .png of that)  
3: Click on the "options" tab at the top of the "Reply..." window.
4: Choose the File attachment "Add/Update" button and browse to the .png file on your computer.
5: Click on save

Ken

PS: You can also paste direct from word using the button with the "W" on it that is just to the left of the "html" option.

The missing image:

Peter,

This is known as a join equality constraint, which is not currently something we support. The verbalizations are incomplete, as is the input data. The basic idea is that if roles within a sequence are in different fact types, then you need a path joining the roles together to form a valid constraint.

We are actively working on specifications for join paths, subtype derivation rules, fact type derivation rules, constraints restricted to role player subsets, and other forms of advanced constraints. Development should begin soon.

The correct starting pattern is 2a, with joins specified over the Pennant object type for one sequence and the Cat and Collar objects for the second sequence.

Sorry I can't be of more help at this time, but at least we're working on a solution.

-Matt

Thanks, Matt and Ken.

So for now I should be using Notes to describe such rules and constraints?

Peter

 Peter,

An interesting scenario! Yes, the verbalization on join constraints is not yet implemented. Perhaps there is another way to model it?

 In this diagram, I've introduced the notion of an 'Entry'  - not sure if that would make sense in your universe of discourse. Hopefully, this still covers what is needed. The verbalization on the equality constraint now comes out to be:

For each Entry and Colour,
that Entry has sponsored some Pennant that is ofthat Colour if and only if that Entry requires use of some Collar that is ofthat Colour.

 - Orion

Careful, Orion. You've introduced non-elementary asserted facttypes into the model. 'Pennant has Colour' is already functional.

You can do something similar with a derived fact type, but the fact type derivation rules are closely related to the same technology needed to do the join paths. In fact, creating a derived fact type often makes this type of constraint easier to express, but multi-role derived fact types should not replace their elementary counterparts.

 -Matt

 Ah, that's right!

"Entry has Pennant that is of Colour" probably is not an elementary fact type!  When building that diagram, I made the assumption that a pennant might be reused in the next cat show. The constraint over the Pennant and Colour roles was meant to keep the pennants colour from changing from one show to the next, but that would actually mask a more elementary fact:  'pennant is (always) of colour'

 This makes more sense with collars. I envision a closet somewhere with several cat collars, each of a certain colour and id number on them. When a cat show comes along, and a person sponsors a pennant, a collar of the appropriate colour is picked out to be used in this year's show.

 So I suppose the questions are:  Are pennants, as known by their id, always the same colour? Are collars always the same colour?

 Below is my revised diagram, which may be less desirable than the original was; it no longer has a direct link between person and pennant, or between cat and collar.

  - Orion

Thanks, Orion, for your thoughts.

The cat show problem does not exist per se - it is a piece of a model that is commercial-in-confidence, and so I changed the names of objects and facts.  In this case I chose cats, collars, and colours because it had a nice lilt to it.

What you have done is to look at the model from a different perspective to get around a current limitation in NORMA; a perspective that may actually be valid for the cat show, but unfortunately is not for the real model.  But you have nicely reminded me that it always pays to look at what is being modelled and to question whether the concepts are correctly understood.

I am loathe to distort my concept model to accommodate limitations of the tool.  (In the implementation, yes, there is no option, but not the concepts.)  So I am hoping that this work that Matt and co are working on will be available sooner than later.

Thanks again, Peter

 Peter,

 The join constraints you have are similar to ones that exist in the Population section of my ORM metamodel, see

http://dataconstellation.com/ActiveFacts/examples/images/Metamodel/Populations.png

The CQL for these constraints is visible in the external constraints at the bottom of

http://dataconstellation.com/ActiveFacts/examples/CQL/Metamodel.cql

Note that the objectification joins there are using an hacky implicit syntax, in that one of the joins is over the concept Role, which is the implicitly joined to the objectification of the stated fact type "FactType has Ordinal role". This is changing to an explicit syntax for objectification join, which would make this equality constraint read like this:

RoleValue fulfils Fact and Fact is of FactType
	if and only if
	RoleValue is of Role (where FactType has Ordinal role);

Despite the hack, this CQL file and the NORMA original generate the same SQL and Ruby artefacts, as well as re-generating the identical CQL, which at least says it's consistent (even though I do nothing with these constraints yet).

Note that it's my observation that most of my models require a number of constraints that traverse several joins, and these cannot currently be expressed in NORMA, though they can (with some limits) be expressed in CQL.

Hey Matthew

What did you mean by that:'Pennant has Colour' is already functional"?

Sentence has only two entities so it could not be nothing less or more then elementary...or. For example "Cat has name", "Cat is black" etc are for me elementary, beacause I can not split them into smaller one without losing information. Off-course since english is not my native language I could misunderstand the meanings.

V.K

V.K.

Stating that the fact type is functional means that n-1 of the roles determine the other role. This follows the strict mathematical definition of a function, where each set of input values gives exactly one output value. For a binary fact type, this means that the role player of a role with a single-role uniqueness constraint functionally determines the opposite role player. So, given a 'Pennant', 'Colour' is known with no additional information, so PennantColor=functionOf(Pennant).

The functional relationship was also the basis of my observation that the ternary shown in the original model was not elementary. The proposed model stated that Colour was depended on Entry and Pennant, when in fact the Entry portion of the uniqueness constraint is not needed to determine Colour. Also note the overlap here between ORM, the mathematical definition of functional, and database normalization theory, where the table mapped from the ternary fact type violates second normal form because an attribute (colour) depends on part of a key (pennant in {pennant,entry}).

The extension to n-ary (ternary and higher) fact types is clear: if a uniqueness constraint covers n-1 roles, then the value of the role not in the uniqueness constraint is functionally determined by the unique roles.

-Matt

Peter,

If you still have your cat model, you might want to try opening it again with the latest NORMA version.

It looks like all of your join paths will have automatic join path generation support, so we'll generate join paths in the model, and these will verbalize with no missing parts.

Note that the tool has internal verbalization and definition support for much more complex join paths now, and we have an editor that is not yet public for editing these paths (along with fact type and subtype derivation rules). The only thing not in place at this point is a licensing mechanism for the path editors and dynamic validation for the paths. The automatic paths will always be valid, so we did not need the validation engine in place before releasing this much of the code. You'll see additional support for advanced paths (splits and conditionals in addition to a direct join path) as we put the final pieces in place for public consumption.

-Matt