Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Equality constraint in Lab4

JO3Y
2007-08-30
2013-05-28
  • JO3Y
    JO3Y
    2007-08-30

    re: Lab4 pg 24

    snippet

    LanguageVersion is of Language(name)
    LanguageVersion has VersionNr

    \snippet

    from the diagram in the ppt, I'm having trouble understanding what is the intended outcome of the equality constraint for

    |is of|    |
           \         =
           /
    |has  |    |

    Every permutation I try has a reading that kind of makes sense, but each generates errors, for example:

    1.1 1.2

    2.1 2.2
    For each LanguageVersion and Language,
    that LanguageVersion is of that Language if and only if that LanguageVersion has that VersionNr.
    Model Error: Constraint 'EqualityConstraint2' in model 'ORMModel1' has role players in column '2' with incompatible types.
    Model Error: Constraint 'EqualityConstraint2' in model 'ORMModel1' is implied by at least one constraint of the same type attached to a subset of the same roles.

    1.2|1.1

    2.2|2.1
    For each LanguageVersion and Language,
    that LanguageVersion is of that Language if and only if that LanguageVersion has that VersionNr.
    Model Error: Constraint 'EqualityConstraint2' in model 'ORMModel1' has role players in column '1' with incompatible types.

    1.1| 

    2.1|
    For each LanguageVersion,
    that LanguageVersion is of some Language if and only if that LanguageVersion has some VersionNr.
    Model Error: Constraint 'EqualityConstraint2' in Model 'ORMModel1' is implied by mandatory constraint(s).

    2.1|

    1.2|
    For each LanguageVersion,
    that LanguageVersion has some VersionNr if and only if that LanguageVersion is of some Language.
    Model Error: Constraint 'EqualityConstraint1' in Model 'ORMModel1' is implied by mandatory constraint(s).

       |1.1

       |2.1
    For each Language,
    some LanguageVersion is of that Language if and only if some LanguageVersion has that VersionNr.
    Model Error: Constraint 'EqualityConstraint1' in model 'ORMModel1' has role players with incompatible types.

    2.1|1.1

    2.2|1.2
    For each LanguageVersionNr,
    some LanguageVersion is of that Language if and only if that LanguageVersion has some VersionNr.
    Model Error: Constraint 'EqualityConstraint2' in model 'ORMModel1' has role players in column '1' with incompatible types.
    Model Error: Constraint 'EqualityConstraint2' in model 'ORMModel1' has role players in column '2' with incompatible types.

    1.1|1.2

    2.1|2.2
    For each LanguageVersion and Language,
    that LanguageVersion is of that Language if and only if that LanguageVersion has that VersionNr.
    Model Error: Constraint 'EqualityConstraint1' in model 'ORMModel1' has role players in column '2' with incompatible types.

    and so on...

    Obviously my understanding of this kind of constraint needs improvement. but I'd like to know what the purpose for the restraint is in this case.

    Thanks

     
    • Hi,

      The name 'equality constraint' may be misleading.  You might think that it's some form of test for equality of values.  What the constraint really enforces is a constraint on which roles, or role sequences must be played by an object, if that object participates in a role or role sequence in a different fact type.  For example, if you had a business rule that every person who is booked at a police station must have their fingerprints taken (and vice versa), you could use an equality constraint to enforce that linkage. If Person Able plays the role of being booked, then Able must also play the role of having fingerprints taken.  As you can see both fact types being constrained will be looking for objects of the same data type - as they are both expecting a person's name (or other ID).

      You might think this violates the 'no ifs, ands or buts' restriction on elementary facts, but this constraint is always used between two or more fact types, not within a single fact type - which must not have preconditions.

      Another snag is getting role sequences right.  With any graphical layout, it can be tricky using mouse clicks and key combinations to get the order correct.  I think you'll know when you get method right.  Try a test of the equality constraint between two unary fact types - hard to get lost there!

      Haven't had a chance to look at the PPT examples yet.  I hope my backlog of commitments will ease up by this coming week, and I can get back to working on ORM matters again.  BRN..

       
    • JO3Y
      JO3Y
      2007-08-31

      thanks Brian, your explanation regarding role sequences clarifies the matter. maybe one day the constraint should be re-named 'sequence constraint'

      for anyone who might be interested in the exercise left to the reader on the last page of Lab 4,

      I did the following tests.

      Test 1

      Thing is a real thing
      Thing is a tangible thing

      - unary roles.

      then i set the equality constraint
      1.1  is a tangible thing
      2.1  is a real thing

      which give this sensible reading:

      For each Thing,
      that Thing is a tangible thing if and only if that Thing is a real thing.

      Test 2

      now i create two fact types that share the same predicate object:

      Perp(name) is booked on Date(ymd)
      Perp is fingerprinted on Date

      i set the [Perp] [is booked on] role as mandatory and UC spanning both roles
      and UC for [Perp] [is fingerprinted on] role.

      then i add Equality constraint as follows:

      Perp is fingerprinted on (first role) |1.1|..| and
      Perp is booked on (first role)        |2.1|..|
      Note that both Date roles are empty.

      This constraint gives a sensible reading with no errors:

      For each Perp,
      that Perp is fingerprinted on some Date if and only if that Perp is booked on some Date.

      What I noticed here is that if only the [Perp] [is booked on] role is mandatory, there is no error. But if I also make [Perp] [is released on] mandatory, this creates an error on the equality constraint:

      Model Error: Constraint 'EqualityConstraint1' in Model 'ORMModel1' is implied by mandatory constraint(s).

      Test 3

      I exactly replicate the structure of "LanguageVersion" (sub) diagram in Lab 4 as follows:

      TeddyBearType(code) is named TeddyBearName(name)
      TeddyBearType has Size()

      Size is a value type

      UC:
      TeddyBearType is named
      TeddyBearType has
      (first roles)

      Mandatory:
      ... is named
      (ommitted: ... has)

      Equality Constraint:
      ... has      |1.1|..|
      ... is named |2.1|..|

      For each TeddyBearType,
      that TeddyBearType has some Size if and only if that TeddyBearType is named some TeddyBearName.

      observations:
      making mandatory the [... has] role
      creates the same "Implied by Mandatory Constraint" error.

      Removing either one or both Mandatory constraints eliminates the error.

      Conclusion:
      1. When using Equality Constraints, Mandatory constraints are unnecessary and interfere with the equality constraint, at least in models analogous to tests 2 and 3.

      2.The "LanguageVersion" subdiagram in Lab 4 has a red-herring. if you try to re-create it exactly as shown, errors are inevitable. Removing at least one of the mandatory constraints fixes the error.

      3. When I was having problems recreating that diagram, I didn't think to put the equality constraint between the first roles only, because the PPT diagram shows the constraint lines attachted to the second roles, not the first roles or spanning both roles. If you to try to set the constraint as follows:

      is of ... |..|1.1|
      has ...   |..|2.1|

      you get Model Error: Constraint 'EqualityConstraint' in model 'ORMModel1' has role players with incompatible types.

      -because one is an entity type and the other is a value type.

      I hope this post helps other newbies out there who are trying to follow along.

      Joe

       
    • JO3Y
      JO3Y
      2007-09-05

      Silly me. that was an external uniquness constraint set to preferred itentifier -- not an equality constraint. They do look very similar. All is clear to me now...

       
    • Hi,

      Good to see that you found the source of your error, and that you are willing to own up to a simple mistake.  Such mistakes are far from uncommon - for both people new to the subject, and for people that have worked with this stuff for some time.  My guess is that you found the mistake the same way I often catch mine: you've thought it through, but it just doesn't make sense the way you had it.  That is usually because you've made an error in applying some constraint, etc..., or you've smoked out some one else's error.  Either way, it a valuable realization - and not at all silly.  Modeling involves some type of reduction, distillation or simplification of a complete, or "real world" subject.  The modeling process means that small errors are multiplied, or magnified, when the model is fully populated or employed.  Precision in the use of every element in the model is critical.  The process of getting the model right - and knowing it is - are fundamental to creating useful models.  Learning from your (and other's), mistakes is essential.  Pointing out instances where symbols may be too easily confused is important as well.  BRN..