1. 1 Objectification Terry Halpin Northface University, USA terry.halpin@northface.edu www.orm.net www.northface.edu © 2005, T. A. Halpin & Northface University

2. 2 Contents  Objectification in ORM, UML, and ER  Two Kinds of Nominalization  Objectification and Composite Reference Schemes  Objectification of Unary Facts  Objectification of Fact Types with Non-spanning UCs  Propositional Nominalization and Communication Acts  Conclusion

3. 3 Objectification in ORM, UML, and ER Roughly speaking, objectification (a.k.a. nesting), treats a relationship instance as an object in its own right, so it may be talked about like any other object. ORM example (ORM 2 notation):

4. 4 UML usually calls this reification, allowing association instances to be objectified as instances of an association class. Unfortunately the name of the association class must match the name of the association (whether displayed or not). UML example, augmented by non-standard notation for preferred identification scheme “{P}” :

5. 5 Industrial Entity Relationship Modeling (ER) (e.g. IE, IDEF1X, Barker ER) does not support objectification at all. Some academic versions of ER do support objectification, typically with restrictions (e.g. objectified relationships may have attributes but not play in other relationships) Example in Elmasri-Navathe ER notation (unable to specify attribute optionality):

6. 6 Two Kinds of Nominalization Nominalization replaces a declarative sentence by a noun phrase, enabling the nominalized object to be referenced like any other object. Two basic kinds of nominalization may be distinguished: Circumstantial -- nominalized object is a state of affairs/event/activity Propositional -- nominalized object is a proposition Elvis sang the song ‘Hound Dog’. -- original proposition Elvis’s singing of the song ‘Hound Dog’ is popular. -- actual state of affairs That Elvis sang the song ‘Hound Dog’ is well known. -- true proposition That Elvis sang the song ‘Hound Dog’ is debatable. -- false proposition

7. 7 It’s snowing outside. -- original proposition It’s true that it’s snowing outside. -- proposition That snowing is beautiful. -- state of affairs In ordinary speech, “fact” (i.e. fact instance) often means “true proposition”. ORM uses “fact” in the weaker sense of “proposition taken to be true” (epistemic commitment by users in the business being modeled)

8. 8 Consider an object instance resulting from the objectification to Playing, e.g. Australia’s playing of cricket. Is this object a state of affairs/event/activity or is it a proposition? Australia’s playing of cricket is at rank 1. Makes sense if playing is an activity, but not if it’s a proposition. Australia’s playing of cricket is true.-- Nonsense.

9. 9 This is typical of objectification examples in information models. “Objectified relationships” are typically states of affairs in 1:1 correspondence with the relationships (facts in the ORM sense) that they objectify, but are not identical with those facts. So we reject this aspect of the UML metamodel, where AssociationClass is a subclass of Association and Class.

10. 10 Objectification and Composite Reference Schemes To facilitate conceptual declaration of business rules (constraints or derivation rules) and queries on information models ORM includes (implicitly or explicitly) link fact types to support navigation between the objectification result and the objects in the fact being objectified.

11. 11 If needed, default readings are assigned for link predicates, e.g. The modeler may assign better readings, e.g.

12. 12 ORM 2 supports multiple predicate readings and role names whose screen or print display may be suppressed individually. ORM 2 allows rules and navigation paths to be declared in relational style -- using predicate names attribute style -- using role names mixed style -- using both

13. 13 ORM 2 allows objectification to be displayed in this way but interprets this as shorthand for: Asserting the equality constraint is the critical step in treating this as objectification.

14. 14 ORM 2 allows role sequences participating in constraints to be disambiguated by role sequence numbers whose display may be toggled on/off.

15. 15 This model may be arrived at in different ways, e.g. (1) Start with the fact type Country plays Sport, then objectify it as Playing. (2) Start with the fact types Playing is by Country and Playing is of Sport, then define Country plays Sport as fully derived from them. (3) Start with the 3 fact types Country plays Sport, Playing is by Country, and Playing is of Sport, then assert the equality constraint.

16. 16 These 3 ways may be formalized as equivalences thus: E1:  x [Playing x   y:Country  z:Sport (x is by y & x is of z & y plays z)] E2:  x:Country  y:Sport [x plays y   z:Playing (z is by x & z is of y)] E3:  x:Country  y:Sport  z:Playing [x plays y  (z is by x & z is of y)] Regardless of which way is used to arrive at the model, the same basic structure is used to capture the model in the metamodel, and the same basic mapping procedures are used to transform it to implementation targets (e.g. Rmap, Omap, Xmap) -- under development ORM 2 includes a formal, high level textual language for all its graphical rules as well as additional business rules e.g. the derivation rule E2 may be rendered as: Country plays Sport iff some Playing is by Country and is of Sport.

17. 17 Objectification of Unary Facts ORM previously forbad objectification of unary facts. For ORM 2, we removed this restriction, by extending the previous analysis to objectified types with simple reference schemes. Consider the unary fact: The President named ‘Abraham Lincoln’ died. We may objectify this event using the nominalization “that death”, and declare the following additional fact: That death occurred in the Country with country code ‘US’.

18. 18 The schema is interpreted as shorthand for:

19. 19 The earlier analysis for objectification may now be generalized by allowing the arity to be unrestricted (1 or more) and the reference scheme to be simple or composite. The result of objectifying a relationship type may be viewed as an entity type that has a reference scheme whose reference projection bears an equality constraint to the fact type being objectified.

20. 20 FCO-IM also supports objectification of unaries, but in a very different way and for a different purpose. FCO-IM uses defines non-lexical objects as objectifications of roles played by lexical objects, e.g. While this approach is interesting, and is supported by two Dutch tools (CaseTalk and Infagon), this seems to conflate reference with referent, and to make it awkward to deal with multiple inheritance, context-dependent reference, and changes to reference schemes.

21. 21 Objectification of Fact Types with Non-spanning UCs Previously, ORM allowed an association to be objectified only if either it has just one uniqueness constraint, and this spans all its roles, or it is a binary 1:1 association. This restriction forbids objectification of 2 kinds of associations: An n:1 (or 1:n) binary association; A ternary or longer association whose longest uniqueness constraint spans exactly n-1 roles. The above cases are allowed in UML, and those academic versions of ER that support objectification. ORM 2 allows these cases, subject to modeling guidelines.

22. 22 Usually, objectifying an n:1 association is just bad modeling, e.g. consider this Elmasri-Navathe ER example 1 : It’s simpler to remodel the departure time as an attribute of just LegInstance. 1 Example from Elmasri, R. & Navathe, S. 1989, Fundamentals of Database Systems, Benjamin/Cummings Publishing, Figure 3.18, p. 63.

23. 23 To support this kind of example in ORM 2 (whether or not it is the best way to model) we interpret the schema thus: The 1:1 nature of the left-hand link fact type avoids denormalization on Rmapping.

24. 24 For objectification, mandatory constraints are needed on all link roles of the objectified type. e.g. if we remove a mandatory role constraint as shown below, Birth is no longer an objectification of GovtHead was born in Country.

25. 25 The main case where it makes sense to objectify associations with non-spanning uniqueness constraints, is when the UC(s) may evolve over time (e.g. from non-spanning to spanning) and we wish to minimize the impact of such changes to the model. A set of modeling guidelines, which also covers other cases is presented on the next slide.

26. 26 Modeling heuristic. 1 A fact type may be objectified only if: (a) it has only a spanning uniqueness constraint; or (b) its uniqueness constraint pattern is likely to evolve over time, e.g. from n:1 to m:n, or m:n:1 to m:n:p; or (c) it has at least two uniqueness constraints spanning n-1 roles (n > 1), and there is no obvious choice as to which of the n-1 role uniqueness constraints is the best basis for a smaller objectification based on a spanning uniqueness constraint; or (d) the objectification significantly improves the display of semantic affinity between fact types attached to the objectified type. 1 For further discussion, see Halpin, T. 2003, ’Uniqueness Constraints on Objectified Associations’, Journal of Conceptual Modeling, October 2003. Online at: http://www.orm.net/pdf/JCM2003Oct.pdf.http://www.orm.net/pdf/JCM2003Oct.pdf

27. 27 Propositional Nominalization and Communication Acts The Business Rules Team submission to the OMG RFP on Business Semantics for Business Rules includes business rules that may be treated directly as cases of propositional nominalization, e.g. If a waiter earns an amount of money as a tip from serving a meal, the waiter must report that fact. Rather than introducing a second kind of objectification into ORM 2 to deal directly with propositional nominalization, we recommend recasting such cases in terms of circumstantial nominalization (e.g. as shown on the next slide).

28. 28 If a waiter earns an amount of money as a tip from serving a meal, the waiter must report that fact.

29. 29 As regards modeling of communication acts, when it is of interest to model these acts, they are best modeled directly like any other business domain objects. e.g. in a genealogy model we might be interested in not just descriptions of states of affairs, but assertion acts made by researchers about states of affairs. Such a model might include fact types such as: AssertionAct reported Proposition; AssertionAct was made by Researcher with ConfidenceLevel; etc. These comments relate to the information model only. For modeling communication processes, the information model should be supplemented by other kinds of model (e.g. interaction or workflow models) that provide a more intuitive and direct way of understanding essential business processes/services.

30. 30 Conclusion For information modeling, objectification may be restricted to circumstantial nominalization, where the nominalized object is a state of affairs (event, activity …) rather than a proposition. Objectification of facts (unary, binary, or longer) may then be interpreted in terms of entities whose reference schemes are constrained by equality constraints involving reference projections from linking predicates. Objectification of facts with non-spanning uniqueness constraints should be permitted, but subject to proposed modeling guidelines. Communication acts may be included as domain entities in information models, but some communication aspects are best specified with other kinds of model (e.g. interaction or workflow diagrams).

31. 31 www.orm.net -- my ORM website www.brcommunity.com/-- Business Rules Journal: article series on Verbalizing Business Rules www.inConcept.com -- Journal of Conceptual Modeling, … www.ORMcentral.com -- ORM tool COM API details, … www.objectrolemodeling.com/-- orthogonal toolbox, … www.omg.org/uml -- UML specification Halpin, T. A. 2001, Information Modeling and Relational Database Design, Morgan Kaufmann. Halpin, T. A. et al. 2003, Database Modeling with Microsoft Visio for Enterprise Architects, Morgan Kaufmann. Further resources