in

The ORM Foundation

Get the facts!

Equality constraints (again)

Last post Thu, Mar 11 2010 19:32 by Matthew Curland. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • Tue, Jan 26 2010 17:33

    Equality constraints (again)

    OK, o' knowledgeable people out there, I'm really struggling with equality constraints when they require join paths. I have another scenario which seems to need one, and I can't for the life of me figure it out. I've read through the Big Brown Book sections on join constraints, and frankly, I'm still a little bit of a novice on this, and I'm struggling.

    In the example below, the constraint that I am trying to implement is something like this:

     http://www.battisti.us/stuff/example.jpg

    Each ContractItem within a Contract with a ServiceProvider must be for some ServicePackageOffered offered by a ServiceProvider, which must be offered by the same ServiceProvider with whom the Contract is made.

    Any suggestions on a) how to construct this constraint, and b) why the heck this is so confusing? :)

    Thanks!

    Steve

  • Tue, Jan 26 2010 20:07 In reply to

    Re: Equality constraints (again)

    Steve,

    I'm not surprised you're struggling. As indicated in the somewhat wordy details at the end of my previous response (https://www.ormfoundation.org/forums/p/666/1983.aspx#1983), the join path support in NORMA is still in its early stages. I'll make the editor to do this publicly available when the verbalization and validation for the paths are done. The reason I need all verbalization and validation in place is that join paths are an advanced feature that are inherently non-trivial to conceptualize and implement, so I need the verbalization feedback loop solid before I let this out the door.

    For this case, the two role sequences for the equality constraint should cover (role to select marked with <>) {{1.1=<ContractItem> is part of Contract, 1.2=Contractee contracts with <ServiceProvider>},{2.1=<ContractItem> is for ServicePackageOffered, 2.2=ServicePackage is offered by <ServiceProvider>}}. This will give you compatible role players for your two columns. The implementation you have will show two validation errors at this point indicating that you need a join path. There is nothing you can do to fix these errors without the additional editors I'm working on. You can, however, turn off display of the error with ErrorDisplay dialog that is available through the Properties Window with a diagram selection (Inside 'Constraint Structure Errors', uncheck 'Join Required for Multiple Fact Types').

    Both join paths in this case are also complicated by the fact that they involve the link fact types that are implied between the objectifying entity type and the role players of the objectified fact type. These fact types are automatically generated with the objectification and can be seen with in the Model Browser or the Reading Editor window. To see/change readings for these implied fact types, select a role in the objectified fact type and open the 'Implied Fact Type Readings' branch in the Reading Editor. In this case, I should be able to jump across the objectification and add an automatic join path, so the errors may be self healing in later versions (not done at this point, although similar patterns with uniqueness constraints do automatically traverse the join path in the pre-release code).

    With the join paths in place, the verbalization will look something like this (additions underlined):

    For each ContractItem and ServiceProvider,
        that ContractItem is part of some Contract that involves some ServiceProvider if and only if that ContractItem is for some ServicePackageOffered that involves that ServiceProvider.

    Please be patient with join paths, and wait for the editors that you don't have yet.

    -Matt

    PS We're also considering some alternate verbalizations to emphasize the objectification relationship instead of using the default readings on the join fact types. This would give something like:

    For each ContractItem and ServiceProvider,
        that ContractItem is part of some Contract that objectifies 'some Contractee contracts with some ServiceProvider' if and only if that ContractItem is for some ServicePackageOffered that objectifies 'that ServiceProvider offers some ServicePackage'.

    I'm not sure I like this second form, especially since the objectified fact type is often implied in the name of the objectifying entity type and this makes it more wordy, but it is something to consider as user option.

  • Wed, Jan 27 2010 8:24 In reply to

    Re: Equality constraints (again)

    Matt,

    Thanks again. I think I misunderstood what you posted earlier somehow, so this really clarified things for me!

    Steve

  • Thu, Mar 11 2010 19:32 In reply to

    Re: Equality constraints (again)

    Steve,

    Happy to clarify.

    Note that the constraint being discussed here is one that we generate an automatic join path for in the latest NORMA release. If you open this model again you should see the correct verbalization.

    -Matt

Page 1 of 1 (4 items)
© 2008-2024 ------- Terms of Service