1/26 Recent Enhancements to ORM Terry Halpin 1 and Matthew Curland 2 1 INTI International University, Malaysia 2 ORM Solutions, USA

2/26 Contents Constraints on Supertype Link Roles Inclusive-Or Constraints on Roles Hosted by Different Types Independent Object Types Revisited Additional Uniqueness and Frequency Constraints Conclusion

3/26 Constraints on Supertype Link Roles Inclusive-or, exclusion, and exclusive-or constraints displayed between ORM subtyping relationships are treated as constraints on the roles hosted by the supertypes in the implied, instance-level identity relationships between subtype members and supertype members, e.g. We now also allow constraints to apply between the supertype link roles and ordinary fact type roles.

Verbalization: If some Employee is some Executive then that Employee uses some CompanyCar. 4/26 Restricted, simple mandatory role constraints apply only to a subset of the role’s population. Formerly, these were declared textually, e.g. suppose that use of a company car is optional for employees in general but mandatory for executives. We can now declare this constraint graphically.

Some metamodel examples: Each EntityType hosts some Role. 5/26 For each QuantityKind, exactly one of the following holds: that QuantityKind is of some RootQuantityKind; that QuantityKind is some RootQuantityKind.

6/26 Inclusive-Or Constraints on Roles Hosted by Different Types An inclusive-or constraint typically applies to roles hosted by the same object type. We now allow such constraints on roles hosted by any compatible object types. Semantics: For each state of the model, each instance in the population of the minimal common supertype of the types hosting the constrained roles must play at least one of the constrained roles. Typically, the minimal common supertype is the root of the subtype graph. For a one person company this inclusive-or constraint can apply only if we allow self-management.

7/26 Current verbalization in NORMA: For each Employee, that Employee reports to some Manager or some Manager who is that Employee manages some Employee. Future verbalization: Each Employee reports to some Manager or is some Manager who manages some Employee.

8/26 Verbalization in NORMA: For each Employee, some Manager manages that Employee or some Manager who is that Employee manages some Employee. Same model, except only the inverse predicate reading is available.

9/26 A more realistic example where each constrained role is directly hosted by the same object type, with one role ordinary and the other a supertype link role: Verbalization in NORMA: Each Employee reports to some Manager or is some Manager.

10/26 Same example, but with only the inverse predicate reading available: Verbalization in NORMA: For each Employee, some Manager manages that Employee or that Employee is some Manager.

11/26 Independent Object Types Revisited A referential role of an entity type is a role hosted by that entity type in an existential fact type (aka reference type) for that entity type. A non-referential role of an object type is a role hosted by that object type, but is not referential for that object type. All roles hosted by a value type are non-referential. E.g. roles with gold fill below are referential; roles with white fill are non-referential

Implied identity link roles of subtypes are non-referential even if the subtyping link is on a path to the subtype’s preferred reference scheme. An assertable role is a role in a fact type that is either asserted or semiderived. If an object type hosts an assertable role, some of its instances may be asserted to play that role. If the fact type is asserted, all instances in the object’s type’s population may be asserted to play the role. Roles in derived fact types are not assertable. An independent object type is a primitive, domain object type that may include instances that are simply asserted to exist, without playing any assertable, non- referential roles (instances of it may exist independently of playing any such role). E.g. 12/26

13/26 Some consequences of the new definition for independent types: (1) No data type can be an independent object type. (2) An object type that hosts no assertable, non-referential role is implicitly independent. E.g. here Room is implicitly independent if it hosts no other role A non-independent object type is an object type that is not independent. In this case, the disjunction of its assertable, non-referential roles is non-empty and is implied to be mandatory. The next two slides illustrate the different semantics for relational mapping of semiderived fact types depending on whether Person is independent. The key difference is that for independent types the relational schema must enable recording of Person instances that play no other roles.

14/26 Person is non-independent so the following inclusive-or constraint is implied. If desired, a Person view could be declared as a union.

15/26 Person is independent. Hence William may be asserted without playing any assertable, non-referential roles. The default setting for false/unknown depends on the closed/open world semantics setting for the semiderived fact type. The semiderived column may be implemented using a trigger or stored procedure.

16/26 Additional Uniqueness and Frequency Constraints External uniqueness constraints may be used to support an entity type’s composite reference schemes (either preferred reference or secondary reference) that involve two or more mandatory functional relationships, e.g. External uniqueness constraints may be also be used with functional relationships, some or all of which are optional, thus providing a way to refer to just some instances of an entity type, e.g.

Join Semantics for External Uniqueness Constraints r 1 r 2 r 3 r 4 P1P1 P2P2 r 1 P 1 r 2 P 1 r 3 P 2 r 4 P 2 r 4 name This external uniqueness constraint has inner join semantics All roles (named or unnamed) may be referenced by their roleId. Role names are optional in ORM, but within the same predicate, role names must be distinct. Hence, named roles may also be referenced by the combination of their name and predicate. P 1 left outer join P 2 inner join : 17/26

All courses may be referenced by their courseCode. Some courses might not offered by a department (e.g. a course by a visitor), but courses offered by the same department must have distinct titles. Each course may also be referenced by exactly one of the following patterns: courseTitle and its department courseTitle where the course has no department This external uniqueness constraint has outer join semantics (with the added proviso that nulls are treated as actual values). This is indicated by the “o” in the bar. C4 Mechanics ? } violates constraint 18/26

External uniqueness constraints with outer join semantics may be used for the preferred reference scheme. In this case, a double-bar through “o” is used. If at least one referencing relationship is optional for its entity type, an external uniqueness constraint with inner join semantics cannot be used for the preferred reference scheme since it can reference only some instances of the entity type. Reference schemes involving a disjunction of two or more patterns are known as disjunctive reference schemes. 19/26

The general, weakest pattern allowed for disjunctive reference (n > 1). If used for preferred reference, use a double-bar.  y 1..y n  0..1 x (xR 1 y 1 & … & xR n y n ) &  y  0..1 x [xR 1 y & ~  z(xR 2 z …  xR n z)] & … &  y 1..y n-1  0..1 x (xR 1 y 1 & … & xR n-1 y n-1 & ~  z xR n z ) Inner join part. The outer join part covers all patterns with one or more absent components E.g.  ct:CourseTitle,d:Department  0..1 c:Course (c hasCourseTitle ct & c isOfferedBy d) &  ct:CourseTitle  0..1 c:Course [c hasCourseTitle ct & ~  d:Department c isOfferedBy d] 20/26

Simplified version of a model for botanical naming. Some plant kinds are identified purely by their genus, e.g. Agrostis. Some are identified by combining genus and species name, e.g. Acacia interior. Others are identified by combining genus, species name and infraspecies (itself identified by combining rank and infraname), e.g. Eucalyptus fibrosa ssp. nubila. 21/26

A uniqueness constraint with a double-bar, one bar of which is solid and one dotted, may be used to reference just some instances of the relevant entity type. A disjunctive reference scheme for the entity type may then be provided by two or more such partial, preferred reference relationships, e.g. This allows a country to have two top politicians, e.g. The TopPolitican who is prime minister of India The TopPolitican who is president of India Pranab Mukerjee Manmohan Singh For each Country, at most one TopPolitician is president of that Country, and at most one TopPolitician is prime minister of that Country. These associations with Country provide the preferred identification scheme for TopPolitician. 22/26

In this example, some famous persons may be identified by just a popular name, e.g. ‘Confucius’ (instead of ‘Kong Qui’). Some may be identified by just their family name, e.g. ‘Einstein’ Others may be identified by combining their family name with a given name, e.g. ‘Marie Curie’, ‘Pierre Curie’ 23/26

24/26 We now support external uniqueness constraints on unary and n -ary fact types, not just binary fact types, e.g. For each Performer and Date, there is at most one Concert such that that Concert features that Performer in some Position and is on that Date. For each Country, at most one Politician is a government head and serves on the government of that Country. A “unique-where-true” constraint

25/26 We now support external frequency constraints on unary and n -ary fact types, not just binary fact types, e.g. For each Country, there are at most 2 instances of Politician such that that Politician is a co-regent and serves on the government of that Country. A “frequency-applies-where-true” constraint.

26/26 Conclusion All the enhancements discussed have been implemented in NORMA, except for the additional flavors of external uniqueness constraints relating to disjunctive reference, which we plan to soon support. Future plans include: Extend NORMA’s relational mapping procedure to cater for the enhancements. Refine constraint verbalization to support pluralization, e.g. “at most 2 instances of Politician” ⇨ “at most 2 Politicians”. Implement verbalizations in languages other than English.