in

The ORM Foundation

Get the facts!

Objectification in the latest NORMA update

Last post 04-24-2014 14:26 by Matthew Curland. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 03-22-2014 15:09

    Objectification in the latest NORMA update

    Recently I updated to the latest version of NORMA. Soon after I noticed in my older models that NORMA signals error - with regard to objectifications - in places that for sure were error-free before the last update.

    To reproduce the error, I have created

    - one entity named Item, and 

    - one fact type: 'Item directly precedes Item', in such a way that:

    - For each Item, at most one Item directly precedes that Item.

    - This association with Item provides the preferred identification scheme for ItemDirectlyPrecedesItem.

    - It is possible that some Item directly precedes more than one Item.

    Everyting was fine till that moment. Next I've tried to objectify the above fact type and here is what I've got:

    Model Error: Model 'ORMModel1' contains multiple readings with an expanded reading signature of 'item is involved in item directly precedes item'. Each reading must be unique in the model.

    Model Error: Model 'ORMModel1' contains multiple readings with an expanded reading signature of 'item directly precedes item involves item'. Each reading must be unique in the model.

    Could you please explain the meaning of that error message? Is it a bug or incorrect modeling? If so, how to avoid it?

    Best regards,

    Piotr Pikielny

    Filed under:
  • 03-22-2014 21:20 In reply to

    Re: Objectification in the latest NORMA update

    Hello Piotr,

    Starting with this release NORMA actually verifies that each expanded reading in your model correspond to exactly one fact type. By an expanded reading, I mean a reading with a normalized form (object type names are broken into pieces over camel casing, hyphens are removed, etc.). I called this expanded form a reading signature, and validate that it is unique in the model.

    So, how does this related to objectifications? When you explicitly objectify a fact type, NORMA automatically create a link fact types for each role in the objectified fact type. These link fact types establish the relationship between the objectifying entity type and each of the objectified role players, and are given default readings of <ObjectifyingEntityType> involves/is involved in <RolePlayer>. In the case where you objectify a ring fact type, you get multiple fact types with the same readings, which triggers this error.

    As with most errors, you can jump to the place to fix the error one of three ways (double-click the error in the Error List toolwindow, select the error in the Error Validation list of the highlighted object, or just double-click the shape the error is displayed on). In this case, error activation will select a role in the fact type and jump you to the Implied Fact Type Readings branch in the ORM Reading Editor tool window, which shows you the readings for the link fact type associated with the selected role. You can editor your link fact type readings here. Although the error will clear, I recommend selecting the other ring role as well and providing non-default readings. For example, in this case, you could change the readings for the first role to ItemDirectlyPrecedesItem involves preceding- Item and preceding- Item is involved in ItemDirectlyPrecedesItem and use 'following' instead of 'preceding' with the other role.

    I know this is a bit of a hassle now, but these objectified rings occur relatively rarely and do not take long to fix. The benefit of not having repeated readings in the model has long been considered an ORM metarule, but NORMA had never enforced it. The other nice benefit of this change is that you can get a shape for an existing fact type on a new diagram by typing a matching reading (with the role players, of course) into the fact editor. Previously, this created a duplicate fact type.

    -Matt 

    PS This is discussed in the first readme item (Duplicate Reading Signature Validation) for the December 2013 NORMA CTP. After installation, you can find the readme in the Documentation directory of your NORMA installation under C:\Program Files\ORM Solutions (use C:\Program Files(x86)\ORM Solutions for a 64-bit OS). I strongly advise a quick scan through the readme items when you upgrade NORMA. I've made some minor usability upgrades to this file by putting previous releases in collapsible blocks, so there is not as much noise at the top of the file.

    PPS NORMA actually does implied objectification for binary fact types with spanning uniqueness constraints and for all n-ary fact types. The structure is identical to explicit objectification, and you can see the implied fact types in the reading editor by selecting the individual roles. Although this error is actually tracked in this case, it is classified as hidden, so it does not display or serialize. It was just too invasive (and Terry complained loudly in the intermediate drop where it happened). 

  • 03-23-2014 4:52 In reply to

    Re: Objectification in the latest NORMA update

     Matt,

    Thank you for fast response.

    I should have read the last update's documentation first before writing to you.

    Piotr 

     

  • 04-24-2014 11:29 In reply to

    Re: Objectification in the latest NORMA update

    Matt,

      As you can see from the posts below (to my class forum) students are still having trouble with this problem and how to correct it.  Can you give a little more guidance?

    Postings on H6 Forum, Party Time!   2014s

    Objectified ternary error

    by Michael Schnaser - Wednesday, April 23, 2014, 9:42 PM 

    I think this is related to the quadranary question earlier. Basically, I wanted to objectify a ternary fact about a Guest introducing a Guest to another Guest and call it an Observation.. That is, there are three boxes in the fact type all leading to my Guest. When I do that, I get this error:

    Model 'ORMModel1' contains multiple readings with an expanded reading signature of 'guest is involved in guest introduces guest to guest'. Each reading must be unique in the model.

    I guess I could do it with a quadranary, but I'm curious as to what this means anyway.

    Re: Objectified ternary error

    by Guy Gaskin - Thursday, April 24, 2014, 1:34 AM 

    I saw this error message in office hours today also.

    I removed the strings specific to your model and searched on "Model contains multiple readings with an expanded reading signature of. Each reading must be unique in the model."  (pretty typical - how would search engines know about your solution-specific names after all?)  

    Found http://www.ormfoundation.org/forums/t/1129.aspx , which is pretty recent (see attached).  

    Haven't confirmed yet that this would resolve issues in HW6, but, it looks applicable.. 

    Re: Objectified ternary error

    by Michael Schnaser - Thursday, April 24, 2014, 11:52 AM

    I saw that post, but I don't know what to do with it. More specifically, here is an excerpt: 

    In this case, error activation will select a role in the fact type and jump you to the Implied Fact Type Readings branch in the ORM Reading Editor tool window, which shows you the readings for the link fact type associated with the selected role. You can editor your link fact type readings here. ......

    I don't know what to change to make the error go away - this person just says "Edit it". 

     

  • 04-24-2014 14:26 In reply to

    Re: Objectification in the latest NORMA update

    Hi Gordon,

    I'll try a further explanation, both on the background and the implementation.

    When a fact type is objectified in ORM an implicit relationship is created for that objectification between each of the role players of the objectified fact type and the objectifying entity type. NORMA automatically creates these fact types (known as link fact types) behind the scenes when you objectify a fact type, and assigns default readings to the each of the fact types following the pattern ObjectifyingEntityType involves/is involved in RolePlayerOfObjectifiedFactType. For the ternary fact type Guest introduced Guest to Guest, this produces three link fact types, one for each role, using the default generated object type for the objectifying entity type. Each of the three link fact types has the default readings (forward and reverse) GuestIntroducedGuestToGuest involves/is involved in Guest. The result is 3 new fact types with 2 readings each where each of the readings look the same.

    Jumping to a different aspect of ORM theory, it is a requirement that each typed reading be unique, where a  typed reading means the reading text with the role player names inserted for the player holds. So, if Person has PersonName and Book has Title are both in the same model, the reading text ('has') is shared, but the typed reading text is unique. The reasons for this are farely obvious: it makes it extremely difficult to navigate a model when two fact types appear to be the same but are not.

    NORMA takes the reading requirements one step further and normalizes the reading text to get a reading signature (a NORMA term, not an ORM term). This is done by stripping hyphen binding, expanding camelCased and PascalCased combined names, and standardizing casing where possible. This is done because different generation targets use different forms of these names, and we want the generated systems to be robust. Therefore, we want object type names of 'PersonName', 'person name', and 'Person name' to all be treated as different similarly when we verify the reading signatures. Therefore, NORMA normalizes GuestIntroducedGuestToGuest involves Guest to get a signature of guest introduced guest to guest involves guest, which is the text you'll see in the error message for overlapping names.

    For objectifications you'll see this error only when the same role player is used more than one role in the objectified fact type. These readings can be edited using the reading editor window by selecting a role in the objectified fact type and opening the Implied Fact Type Readings branch, where you'll see the is involved in and involves link fact types. To edit one of these readings just click the reading, wait for the editor to activate, then change the reading text (the role players are locked in this editor). If you see this error, you can navigate to the correct point in the reading editor by activating the error, which is done using any of four different gestures in the tool (double-click the shape with the error display, right click the shape and select the error in the Validation Errors submenu, click the error text in the ORM Verbalization Browser, or double-click the error in the Error List tool window).

    To fix this error, I recommend changing the reading text for each reading (forward and reverse on each role). For example, with the triple-Guest fact type, you can change the readings by putting in hyphen bound names. If we rename the objectified form of the fact type to Introduction, you can change the readings to (do the first two by selecting the first role, then the next two on the second role, then clean up the third role as well).

    introducing- Guest is involved in Introduction, Introduction involves introducing- Guest

    introduced- Guest is involved in Introduction, Introduction involves introduced- Guest

    introduced- to Guest is involved in Introduction, Introduction involves introduced- to Guest

    This will both clear up this error and give you a much better default name in the relational mapping. Prior to this edit, the Introduction table would get columns guest1, guest2, guest3. With this in place, you'll get introducingGuest, introducedGuest, introducedToGuest, which is much more readable. Note that the link fact types exist for all n-ary fact types and binary fact types with spanning uniqueness constraint even if they are not objectified, and you can clean up your column names using this technique instead of throwing role names all over the diagram. The only difference with these implicit objectifications is that you won't see the error, as you do when you explicitly objectify the fact type.

    Note that you can also individually select the link fact types in the model browser (right click the fact type, choose Select in Model Browser, expand the fact type node, then expand the Implied Fact Types node to see each one). From here you can even drag them onto your diagram and see what they look like. [Warning: there is a bug in the December 2013 release preventing the link fact type for a role with a single-column uniqueness constrant from drawing without asserting. This will be fixed in the next public drop, or pull the latest intermediate release from http://ORMSolutions.com/NORMAPreview.]

    Gordon, let me know if you have other questions. I knew there would be some pain on this fairly recent change, but I think it is much better than allowing duplicate fact type readings, which was easily done before and could cause a lot of confusion. I also improved other things related to this (reentering an existing fact type in the fact editor adds a shape for the existing fact type, and activation of link fact types selects the role and reading editor instead of the link fact type in the model browser and the fact editor). I'm hoping once modelers are used to this that it will become a normal part of the process. If there are too many students asking about it, maybe you can take a couple of minutes to demonstrate how to handle it during class?

    -Matt

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