The ORM Foundation

Get the facts!

ORM models and OO

Last post Mon, May 25 2009 4:40 by Anonymous. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • Mon, Apr 6 2009 1:33

    • PeterC
    • Top 25 Contributor
    • Joined on Fri, Aug 22 2008
    • Sydney, Australia
    • Posts 22

    ORM models and OO


    In my mind, the conceptual model in ORM is modelling the "problem space", not the "solution space".  Because ORM is aimed at being able to generate a (pure, i.e. 5NF?) relational database solution, this means that there are certain OO constructs, such as mutually exclusive supertypes, that are not supported.

    Statement: When I want to conceptually model my "problem space", I may be limited in what I can model because there may be constructs (if that is the correct term) that I need that are not available.

    Q1.  Is the above Statement true or am I only limited on the form my model can take, not what I can model?

    Q2.  Has an analysis been done on the gap between <what ORM would be like if it supported OO> and <what it needs to support the relational paradigm>?

    Q3.  Just as there are constructs in ORM (such as some types of constraints) that do not automatically translate to DDL statements but must be manually written as procedures or code, is it reasonable to have ORM constructs that support OO - knowing that the constructs must be implemented either in code or perhaps in less than 3NF?

    The reason I raise these questions is that given a "problem", I want to be able to model it free of the solution; and the constructs used in the model may (or may not) indicate whether an OO and/or relational solution is feasible or preferable.

    Thanks, Peter

  • Mon, Apr 6 2009 6:42 In reply to

    • Ken Evans
    • Top 10 Contributor
    • Joined on Sun, Nov 18 2007
    • Stickford, UK
    • Posts 804

    Re: ORM models and OO

    Hi Peter,
    I agree that ORM is about modeling the "problem space". The term more normally used is the "Universe of Discourse".
    However, there are some problems with your assertion

    Because ORM is aimed at being able to generate a (pure, i.e. 5NF?) relational database solution, this means that there are certain OO constructs, such as mutually exclusive supertypes, that are not supported.

    What is ORM "aimed at"?
    Its true that you can generate a 5NF relational schema from an object-role model. However, I wouldn't go so far as to say that "ORM is aimed at" doing that. ORM can do it because ORM uses many of the logical principles that are also used by the relational model. 

    ORM does not support mutually exclusive supertypes.
     Well, I see this as a consequence of logic not as a consequence of ORM. There is an example on page 243 of the Big Brown Book which uses the case of a "Female Australian". The sets of "Female" and the set of "Australian" overlap. However, both of these sets have members that are also members of the set "Persons". (the supertype) 

    What's the problem? I'm wondering if the real problem here is that OO allows you "say" things that are not logical.
    In natural language you can say things that are meaningless.
    For example you can say "His wife is not married". This assertion is gramattically correct but it is meaningless.

    After some thought, I have not been able to come up with an example of a "mutually exlusive supertype".
    Can you give an example?

    So, I'm wondering if, as in natural language, OO allows you to use "constructs" that are in truth meaningless.
    I'm not an OO expert, so maybe this is due to my lack of understanding of the principles on which OO is based.


  • Fri, May 22 2009 3:49 In reply to

    Re: ORM models and OO

    there are certain OO constructs, such as mutually exclusive supertypes, that are not supported

    Peter, I think that the basis for inclusion or exclusion of features from ORM is that it is based in the semantics derived from mathematical logic. Although various people have tried to produce similar logical foundations for OO, not all of what is considered to be OO can be founded in that way, and the formal semantics that have been proffered have never been agreed as complete, correct or sufficient by any substantial majority of the OO community.

    I've been using object orientation since well before it had that name, and I'm not even sure when I would use mutually exclusive supertypes. I don't think that concept has a logical meaning, that is, a meaning within the logical (formal, mathematical) definition of supertype. Mutual exclusion occurs with respect to subtypes, as supported by ORM. I'd like to see a convincing example of mutually exclusive supertypes!

    A further rationale behind the inclusion or exclusion of features in ORM is the principle of necessity; if all models that might use the feature can already be adequately expressed without it, that feature is excluded. This principle isn't universally accepted - there are those in the community who would favour more "sugar on top", but I take the position (supporting Dr Halpin) that the core metamodel must be as simple as possible, and that extra kinds of diagram elements will make it even harder to read an ORM diagram correctly.

  • Mon, May 25 2009 3:17 In reply to

    • PeterC
    • Top 25 Contributor
    • Joined on Fri, Aug 22 2008
    • Sydney, Australia
    • Posts 22

    Re: ORM models and OO

    Thanks Ken and Heath.

    I’ve spent quite a bit of time ruminating on what you said, Ken; and Heath’s response really helped.

    Thanks for the clarifications on terminology and the “aim” (or rather not) of ORM.

    If I understand both of you correctly, if I can’t model my Universe of Discourse with ORM then either I haven’t understood my “problem” correctly or I’ve identified a shortcoming in ORM (something the OO community thinks might be the case?)?

    I think I’m starting to understand the different concepts between ORM, OO, and the relational paradigm.  So it appears that Q2 is not correctly stated, perhaps it should be:

    Q2 What does OOA (and OOD?) offer that ORM can’t supply and isn’t “sugar on top”? 
    What I’m thinking of are things like abstract classes (for collections and queues, etc) so that I can define it once and then use it repeatedly (or is this sugar?), and being able to define alternate sets (for example, I may have an ObjectType that defines Mammals and another for Machines, but in the same model I may want to define an ObjectType that represents all FlyingThings, such as Bats and Planes – and I would preferably want to be able to do this without having to define a supertype that encompasses everything).

    As far as mutually exclusive supertypes go, this appears to be a bit of a furphy, in that it has distracted from the main issue.  (I’ve reviewed a number of examples I had, and I could resolve them with multiple inheritance – so I think I can ignore this particular “feature” until I come across a good example.)


  • Mon, May 25 2009 4:40 In reply to

    Re: ORM models and OO

    or I’ve identified a shortcoming in ORM (something the OO community thinks might be the case?)?

    I haven't heard this argued. ORM provides different abstractions from OO, but the differences are in degree of succinctness, not in the scope of things (actualities, as opposed to abstractions) that can be described. OO however provides some hints at the kinds of operations that might need to be efficient, such as in the queue example below.

    the different concepts between ORM, ...and the relational paradigm

    ORM and the relational paradigm are built respectively on logic and set theory, and thus are two sides of the one coin. ORM is however more powerful because it insists on elementarity, which is almost isomorphic to relational sixth normal form, and on verbalisation, which allows us to discover and verify models that match our natural understanding of a problem domain. In the process, it elicits enough structural constraints (uniqueness) that an efficient database design can be automatically constructed, where a 6NF relational schema would not be effective.

    things like abstract classes (for collections and queues, etc)

    When I don't have any ordering requirement in a collection of things, I don't need to specify how those things should be arranged.

    When I have an ordered collection of things, I use the Ordinal value type: "Person is in Ordinal place". To insert concept instances in here, we see how natural the verbalisation is: "John is in third place". The ability of a queue to remove the person who's in first place and re-number all the subsequent entries is an implementation detail; ORM does not attempt to address that issue.

    Here's where OO can inject an implementation detail into the semantic model, by requesting a specific data structure that can do that renumbering efficiently - the queue. However, since not every queue implementation will have the same profile of efficient versus inefficient operations as every other implementation, it would be preferable not to specify a class of data structure, rather to provide a way to indicate the types of performance envelope expected for different classes of operations. This would allow proper performance prediction, analysis and management of user expectations. Because OO tends to take more shortcuts in this respect, the success of an OO project (its ability to meet expectations) is dependent on hidden implementation details that cannot always be known. I personally can recount actual cases where such oversights have cost millions of dollars and postponed or prevented project success for years.

    Furthermore, I would argue that injecting operational and implementation details into a semantic model is often:

    • Confusing, by diverting attention from what and why (more on this below), and
    • Wrong, the injection happens at a time during modeling at a time when the actual requirements cannot be known,
    • Unnecessary, because in most cases data structures exist or can be adaptively applied after the performance is shown to be inadequate - provided that the underlying algorithm is expressed in terms of things in the real world. In the case of a relational database, that can be as simple as adding an index.

    The software industry will continue to fail until it stops jumping to solutions (answering the how question) until after it has satisfactory answers to the ones the business is concerned with, which are what and why. It's in the nature of engineers to want to always know how - these are people who like me have spent their youths taking things apart to find that out - but our selection and training of such people must be changed to teach them when to ask each type of question.

    Your FlyingThings category is unnecessary, and should be modelled using a AbilityToFly or FlightCapability object, such that any number of categories of creature (and things too!) can have that ability.



Page 1 of 1 (5 items)
© 2008-2022 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service