The ORM Foundation

Get the facts!

ppt P07: Reduction Transformations in ORM

Downloads: 51 File Size: 789kB
Posted By: admin Views: 2,631
Date Added: Mon, Dec 3 2007

Abstract. This is a presentation of a paper that proposes extensions to the Object-Role Modeling approach to support schema transformations that eliminate unneeded columns that may arise from standard relational mapping procedures. A “unique where true” variant of the external uniqueness constraint is introduced to allow roles spanned by such constraints to occur in unary fact types. This constraint is exploited to enable graphic portrayal of a new corollary to a schema transformation pattern that occurs in many business domains. An alternative transformation is introduced to optimize the same pattern, and then generalized to cater for more complex cases. The relational mapping algorithm is extended to cater for the new results, with the option of retaining the original patterns for conceptual discussion, with the transforms being applied internally in a preprocessing phase. The procedures are being implemented in NORMA, an open-source tool supporting the ORM 2 version of fact-oriented modeling.

Authors: Terry Halpin, Andy Carver,, and Kevin M. Owen (Neumont University, Utah, USA)   (terry,andy,kevin)

The original paper is available from Springer-Verlag Lecture Notes in Computer Science : LNCS 4805 , November 2007   




VictorMorgante said:

The 'Unique-where-true Constraints' are labeled as 'seems preferable'. I'd prefer that they be labeled as what they are 'a suggested extension to ORM'. I see no added value in the proposed syntax (Unique [and Mandatory] Where True)...given that not only does it edge toward presupposition of the physical design (at the analysis stage) which is contra to the precepts of analysis, but that the same result can be achieved using other syntactic constructs within ORM as it stands (and following an unbiased approach to analysis). i.e. Leave the design phase to the designers, leave ORM pure in its approach to analysis OR (more simply put) let's not adulterate ORM by implementing constructs that try to influence the physical model through the constructs of analysis when ORM (as it stands) does not do this, and has all the symbols and constructs to serve the same 'analytical' purpose.
Thu, Dec 13 2007 22:31

VictorMorgante said:

For further discussion on this, Ken Evans' survey#1 ("Is data modeling a descriptive process or a design process?") on this site (see the Survey section) addresses the very issue fundamental to my original objection to the proposed "unique-where-true constraint" extension to ORM. On thinking it over, I recant my comments above, because it is indeed very difficult to stick strickly to 'description' when modeling real work applications. Perhaps the trick is to use 'color' within a software modeling tool to differentiate between what is 'description' and what is 'design'.
Thu, Mar 27 2008 4:52
© 2008-2020 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service