The ORM Foundation

I apologise in advance if this topic is not in the right place. 

I am using NORMA for VS2008, downloaded on 19 March '09.

NORMA lets me model (for examples only) "A Bat is a subtype of Mammal and a subtype of Creatures_That_Fly" but it does not let me model "A Specimen is a type of Animal XOR a type of Vegetable XOR a type of Mineral". The error message I get when I try to model it is: "Direct supertypes of ObjectType 'Specimen' in model 'myModel' must be overlapping without transitive implication or mutual exclusion."

a) What does this error message mean?  (When I point at it in the Verbalization Browser my cursor changes to a pointing finger but I haven't yet worked out how to get it to explain it to me [unlike Visiomodeler which had a great jump to an exclamation]; and in the Error List window, the Right-Click "Show Error Help" does nothing.)

b) When I was taught OOA/OOD (20 years ago) mutually exclusive supertypes were allowed. Is this proven to be a bad construct, or is this a limitation applied because of dealing with identifiers?

Thanks for your help

Peter

Hi Peter,
The problem you have encountered relates to set theory. NORMA uses set theory and thus NORMA will give an error message if you try to create a ORM construct that contravenes set theory.

In your first example "

PeterC:

A Bat is a subtype of Mammal and a subtype of Creatures_That_Fly"

What you are saying (by implication) is that "Some Mammals are creatures that fly"
In other words, "Mammal" and "Creatures that Fly" are "overlapping"
It is also true that "Mammals" and "Creatures that Fly" are NOT mutually exclusive. 

The term "overlapping" in the error message is from set theory - see the explanation on pages 214 and 215 of Terry's 2008 book

The problem with your second example is that it violates the rules of set theory.
For example when you state that "Specimen" is a subtype of "Animal",
you are also saying that [All "Specimens" are "Animals"].
An alternative way of saying this is that
[The set of things called "Specimens" does not have any member that is NOT a member of the set of things called "Animals"]

Now if you specify that "Animal" ,  "Vegetable" and "Mineral" represent mutually exlusive sets of things, then by trying to make "Specimen" a subset of two or more of these mutually exclusive sets then you are in effect trying to make two mutually exclusive statements; specifically:

1: The set of things called "Specimens" does not have any member that is not a member of the set of things called "Animals"
2: The set of things called "Specimens" does have a member that is not a member of the set of things called "Animals"

Clearly only one of these statements can be true.

You will find more detail of these points on pages 214 and 242 of Terry's 2008 book.

Hope this helps.
Ken

Hi, As Ken explains, types are sets. Hence, they are treated different to those of OO approaches. For example, here, "Each subtype graph must stem from exactly one primitive entity type (...) that is the common supertype, or root node (or top) of that graph." [taken from Terry's Book, pag. 243]. Adding a common supertype to the types Animal, Vegetable and Mineral, would solve the error, though, in your situation, I would model these entities as subtypes of Specimen. However, I'm a little confused about the constraints applied to common subtypes. In the same page of the book it is said "a common subtype is at most the intersection of its supertypes", but if we apply an exclusion constraint we'll get the union of the differences. I would appreciate any clarification on it. Regards, Josue

On Terry's statement: 

If two (or more) supertypes are mutually exclusive, then you will get a validation error if you make a single entity a direct or indirect subtype of both of the nodes. In this case, with the exclusion of the supertypes, any entity that is a subtype of both would be the empty set, which is indeed the intersection of the supertypes (which, being mutually exclusive, do not intersect). The notion of 'the union of disjoint subtypes' applies to the shared supertype, not the subtypes.

On the general modeling pattern:

In addition to the set information, subtypes also have an instance relationship which forms a one-to-one relationship between the subtype instance and supertype instance, with the subtype role mandatory. The readings on this relationship are 'is' in both directions. Considering the original assertion that 'Specimen is a subtype of Animal', you can see the three constraints if you expand the 'Fact Types/SpecimenIsASubtypeOfAnimal/Internal Constraints' node in the 'ORM Model Browser'. The three constraints verbalize as below (with comments added for your model):

• Each Specimen is at most one Animal. (this is OK)
• Each Animal is at most one Specimen. (suspect because you probably want to allow multiple specimens of the same type of animal, AnimalInstance 'Peter' is a specimen of Animal 'Human', AnimalInstance 'Matt' is a specimen of Animal 'Human')
• Each Specimen is some Animal. (suspect because you also want to allow Vegetable and Mineral specimens)

So, of the three constraints on the subtype, two of them contradict what you want your model to represent. The distinction between the Animal type and AnimalInstance is also extremely important. A Specimen is an instance of an Animal type, it is not the animal itself. You want Specimen 'xInstance' is of type Animal 'x', not Specimen 'x' is Animal 'x'. The second 'is' reading is what you get with the subtype assertion, but I think the 'is of type' reading is what you actually want.

So, in your model, you want three FactTypes (Specimen is of type Animal, Specimen is of type Vegetable, Specimen is of type Mineral) with a uniqueness constraint on the Specimen side for all three FactTypes and an exclusive or constraint across the three Specimen roles. Alternately, you'll need a shared supertype for Animal/Vegetable/Mineral. However, even with the shared supertype, I do not think that making Specimen a subtype is the correct model because of the conceptual difference between 'is' and 'is of type'.

On the error hyperlink issue:

Many of the validation errors have actions associated with them to fix the error. For example, if a ValueType does not have a DataType specified then the action is to select the ValueType, activate the Properties Window, select the 'DataType' property, and open the dropdown. If an error has an action, then the action can be activated in several ways:

1. Double-click the error in the Error List (available on the View menu). This selects the element with the error and activates the action if one is available.
2. Select the error in the 'Validation Errors' submenu on the context menu for a selected shape
3. Double-click a shape with an error display. This activates the first error in the 'Validation Errors' list that has an associated action
4. Click the hyperlink on the error display in the Verbalization Browser. This has the same actions as 1, and can possible change your shape selection (if you have the element selected in the Model Browser, for example). However, an action is not always available for the error.

There is no automatic action to fix the error you're seeing, and you most likely already have a shape selected to see the verbalization, so it looks like it does nothing. You definitely bring up a good point, though, namely that we should provide information on how to fix an error if no default action is available, and integrated help system topics need to be provided across the NORMA plugin (we do install a help file, but there are no context-sensitive topics).

 -Matt

but the error arise even in the case the supertypes aren't mutually exclusive. The only way I have found to avoid it is adding a common root supertype. On the other hand, when a root supertype is added the exclusion constraint goes to be valid. I'm interpreting the constraint as a way of restricting the population of the common subtype. Consider the example given in page 243 of Halpin's book about Female Australian. If we add an exclusion constraint that spans the subtypes Australian an Female, it is expected that only Male Australian and Female Not Australian could populate the common subtype (Female Australian), but the common subtype can still be populated with some individuals. The readings of the supertype-subtype instance relationships would be ('Female Australian' is replaced by 'Male Australian and Female Not Australian'): Each 'Male Australian and Female Not Australian' is at most one 'Australian'. (OK) Each 'Australian' is at most one 'Male Australian and Female Not Australian'. (OK) Each 'Male Australian and Female Not Australian' is some 'Australian'. (OK) Please, correct me if I'm not seeing something here. Josue

Is there an easy way of adding format to post messages? Thanks,

Josue Portal:

Is there an easy way of adding format to post messages? Thanks,

If you just type into the "post" window then there is built in formatting. (use the icons for bold, bullets and so on)

Alternatively, you can prepare your response in Word and then paste it using the "Paste from Word" icon. (The yellow folder with the "W" on it.)

Ken

 

From my reading, 'Male Australian and Female Not Australian' is always an empty set because one Person cannot be both a 'Male Australian' and a 'Female Not Australian'. Therefore, while your substitution statements above are OK, they are applied to a set that is always empty, so the statements have little meaning. Any statement applied to an element in the empty set is in fact trivially true (see the truth table for the logical implication operator). 'If a is an element of the empty set, then the sky is green' is a true assertion.

I think an issue here may be the radical difference between the terms 'or' and 'and' as they are applied in common English versus logic and programming contexts. In common English, the set of 'boys and girls' is equivalent to the set of 'boys or girls' in set theory, where 'or' means union and 'and' means intersection.

If you change your statements to the logical form 'Male Australian or Female Not Australian' to get the union of the sets, breaking the statement Each 'Male Australian or Female Not Australian' is some 'Australian' means that all females are Australian, which is not what you're trying to say.

I think the fundamental issue here is that you're viewing 'Female Australian' as the union of the set Female and the set Australian, when in fact the two supertype relationship imply the intersection of these two sets, not the union.

The first sentence on page 244 states. Subtype graphs have only one root, since primitive entity types are mututally exclusive. The implied mutual exclusion of all non-subtype entity types, combined with the intersection semantics of a subtype with multiple supertypes, is the fundamental reason that all subtype graphs need an explicit shared supertype. If there is no shared supertype, then the subtype will always be the empty set and is, hence, pointless to talk about.

-Matt

Now I can see it. I think.

My problem was to ignore that a common subtype is, by definition, (at most) the intersection of its supertypes, since a very hasty reading of the related topic in Halpin's book and despite of Matt attempts to make me reason.

Regarding the exclusion constraint, Is there any reason for allowing it to be inserted between the subtyping relationships of a common subtype? In this case, there's no validation error in NORMA.

Regards, Josue

 

You're right, we don't validate that exclusion case, but we should definitely recognize it as a contradiction because, with all constraints enforced, there would be no way to populate the resulting set. The other cases (specifying completeness and exclusive on the subtypes insteads of the supertypes) is the more common pattern, and validating that was fundamental to allowing the partition option offered in the relational mapping extension. The partitioned supertype case also does not verbalize well, so we clearly need to do some work in this area.

The ORM/set theory notion of subtyping is definitely different than the OO approach, which allows multiple polymorphic views to be implemented by any object. ORM does allow both specialization (via introduction a subtype) and generalization (via introduction of a shared supertype) through subtyping relationships, but the shared supertype blocks the free-for-all multiple inheritance subtyping offered in OO systems.

Another discussion ('How to create ValueType Group', in User/User Experience) discusses the wish to add the same set of FactTypes to multiple entity types without forcing a shared supertype. This notion is something we're considering under the concept of 'abstract supertype'. In this case, all of the relationships would be moved down to the subtypes. While this may be a useful shorthand notation, there are a number of technical issues that need resolving (what does it mean to reference an abstract type, and how does this map to other targets, etc). From an OO perspective, the closest analog would be the idea of 'duck typing' common to dynamic languages, where different object types are loosely related because they look, swim, and quack the same, even though they are not of the same type. [Don't hold your breath waiting for this feature, there are a lot of issues to work through, and there is no guarantee we will do it.]

Good luck with your project,

-Matt

Thanks All for helping me understand where ORM super/sub types fit into my OO thinking!

For what I'm working on, the target is a relational database, so set theory is good.  (Sounds like I'll need to get ahold of this book.)

While I was sorting out in my mind the implications of the discussion, Matt has mentioned something that I think is a valuable part of OO and would be great in ORM, ie the abstract supertype.  If we look at the example of 'Bat', 'Mammal', and 'Flying critter': 'Bat' is a subtype of 'Mammal' and it makes sense that 'Mammal' is the primary supertype of 'Bat'.  However, there is another object of interest, the 'Flying critter'.  A 'Flying critter' can be a supertype of 'Bat', 'Gull' (a subtype of 'Bird'), and 'Bee' (a subtype of 'Insect').  The 'Flying critter' has FactTypes that are common to: 'Bat' but not 'Dog', 'Gull' but not 'Penguin', and 'Bee' but not 'Ant'.  In my mind, the 'Flying critter' is an abstract supertype because all members are already in their mutually exclusive, sets.  In other words, the abstract supertype represents a concept or a commonality that can be shared by members of sets that may be mutually exclusive.  (As probably not a very good example: In a library, do we file Halpin's book under Mathematics or Computer Science - it only has one Dewey Number but both disciplines wouldn't mind having it.) 

If I understand Matt correctly, diagrammatically the abstract supertype will appear in its own right with its own FactTypes, but in implementation (in a relational database), its FactTypes would be replicated to each subtype's table?  (As opposed to an abstract entity's own table that consists of a set of foreign keys to the respective subtypes' tables (of which all but one would be NULL for each row) plus the FactTypes.)

Am I making sense or have I confused myself?

Peter

Yes, that's the basic idea. Certainly, any functional role (uniqueness constraint on the near role) ends up replicated into each subtype's implementation, similar to a Partitioned table in the relational mapping. There are several big questions here (constraints replicate along with the FactTypes, and constraint names are supposed to be unique)

The main issue is with non-functional roles (references to the abstract type, or things attached to it, join tables, etc). As you point out, these now become xor relationships with multiple columns. Either we add validation to block inappropriate facttypes and constraint (very difficult and hard for the user to predict as the FactTypes may not be directly connected to the abstract supertype), or we let the mapping layers deal with the issue.

So, while this type of macro expansion may reduce diagram clutter in a number of user scenarios, it also blurs the meaning of some of the ORM constructs when they are applied to an abstract supertype and related FactTypes. If we can define a clean mapping between the macro (abstract supertype) and expanded (non-abstract relationships only) forms at the ORM level then we might consider proceeding with it. While this might be easy to draw, it is completely non trivial to implement.

-Matt

Thanks. 

So in my example model (not my real project which is way more complex), as a work around, I change 'Bat is a Flying_critter' to 'Bat has a Capacity_to_fly'.  That is, I change the relationship from hierarchy/inheritance to component.  Which means I cannot define an EntityType that represents the set of critters that fly?  If this is true, then my Conceptual Model is no longer Conceptual because I have to decide in advance (design) which sets define hiearchies and which sets are decomposed to components? 

I guess I can live with this because I am not aware of an alternative tool that competes with ORM let alone one that I can afford.

Peter

PeterC:

I change the relationship from hierarchy/inheritance to component

 Even in the design of object-oriented systems, modern experience has produced a view that it's often much more productive to build objects by composition and aggregation rather than inheritance. Inheritance has its place, but has often been overused.

Regarding affordable software tools, please also consider using ActiveFacts, which is now quite powerful despite not producing ORM2 diagrams. The CQL language it implements is essentially ORM-as-plain-text. You can't get cheaper than free either; ActiveFacts is open source. More details at my website http://dataconstellation.com