Re: ORM Compound Reference Scheme Problem
From: Chris Bruce <chris_at_mirrorcomputing_no_spam.co.uk>
Date: Fri, 14 Jun 2002 11:47:06 +0100
Message-ID: <aechlt$n11$1_at_taliesin2.netcom.net.uk>
Date: Fri, 14 Jun 2002 11:47:06 +0100
Message-ID: <aechlt$n11$1_at_taliesin2.netcom.net.uk>
Hi Scot,
If only I'd looked at the sample populations in my original posting I'd have seen that my comment below re uniqueness over the first role of the ternary was wrong!
Perhaps I'll just shift my perspective!
-- CB "CB" <chris_at_mirrorcomputing_no_spam.co.uk> wrote in message news:aeahau$bq5$1_at_paris.btinternet.com...Received on Fri Jun 14 2002 - 12:47:06 CEST
> Hi Scot,
>
> Thanks very much for your explanations.
>
> The UoD includes map coordinates, the OSGridRef I refer to being the UK
> Ordnance Survey grid reference system. It comprises two values: an Easting
> value which is an offset from the origin in a Easterly direction and an
> offset from the origin in a Northerly direction. The pair combine to give
a
> unique reference to almost any granularity you may wish for, for example
to
> a 1km square or a 10m square.
>
> My inclination is to model this as a ternary, so
>
> OSGridRef has OffsetValue of OffsetType
>
> From the above explanation of the UoD you can see that in order to get the
> full OSGridRef reference for the OSGridRef entity I need two occurrences
> from this same fact, one with an OffsetType of Easting and one with an
> Offset Type of Northing. My problem is how to show this graphically!
>
> Moving on from that to uniqueness constraints, the OSGridRef is unique.
> Therefore there'd be a uniqueness constraint over the first role of the
> ternary as proposed above. Now, as this is illegal, the ternary would
appear
> to be "illegal" or non-elementary itself. (Maybe I've started to answer my
> own question now!) There would also be a uniqueness constraint spanning
all
> three roles (as this is implied and is also true as a given
> OffsetValue/OffsetType pair can occur in many OSGridRefs). As the ternary
> fact would have this uniqueness constraint on the first role, the ternary
is
> wrong and it appears that I'm looking at this from the wrong perspective.
>
> It would seem that my answer lies in the first example you gave in your
> reply!
>
> OSGridRef has NorthingValue
> OSGridRef has EastingValue
> with an external uniquness constraint joining the second roles of each
fact
> to give the reference scheme for OSGridRef
>
> Many thanks for your time...
>
> --
> CB
>
>
> "Scot A. Becker" <scot_at_orthogonalsoftware.com> wrote in message
> news:lfeM8.3198$Pz3.54936_at_twister.kc.rr.com...
> > Hi Chris,
> >
> > I have to admit ignorance of the subject area of your model, but why are
> you
> > adverse to a compound reference scheme for OS Grid Reference? This
concept
> > is perfectly acceptable in ORM....
> >
> > That being said, generally speaking co-referencing (a.k.a. compound
> > reference) an object that plays a functional role (more on this below)
can
> > be realized in 2 other ways: a) a nested fact and b) one or more ternary
> > facts. Let's look at the general case:
> >
> > Co-referencing facts:
> > 1) A has X (this is the "functional role", it would map as an attribute
of
> > A)
> > 2) A is partially identified by B
> > 3) A is partially identified by C
> > There is an internal uniqueness constraint on the A role of all three
> facts.
> > Further, let's say that the A role is mandatory for all facts (for
> > simplicity sake).
> >
> > A has no simple reference mode, so an external uniqueness constraint
joins
> > the B and C roles of the latter facts. This UC then defines the primary
> > reference mode of A.
> >
> > Same universe of discourse (UoD), but using nesting:
> > 1) B has C, this fact has a spanning uniqueness constraint and is nested
> as
> > the object "A"
> > 2) A has X (this is the "functional role", it would map as an attribute
of
> > A), the A role is unique and mandatory
> >
> > Same UoD using a ternary:
> > 1) B has C for X, uniqueness constraint spanning B and C
> >
> > The first two options above are always equivalent. The third is
equivalent
> > assuming that the A role of the 'A has X' fact is mandatory. I can
explain
> > this further if needed, but for now I'll leave it at that.
> >
> > The third option is usually not the best design decision because you
would
> > need a ternary fact for each functional role (attribute) of A. This
> results
> > in many more tables than is optimal in most cases. However, it is
> > conceptually sound, and in an analysis/conceptual model is perfectly
> valid.
> >
> > The only other things to think about when deciding to co-reference vs.
> > nesting vs. ternary is if there are any semantic meanings expressed by
A.
> > For example, if you have to struggle to come up with a name for A, then
> the
> > ternary is the cleanest semantics. But, if A has semantic importance in
> your
> > universe of discourse, then by all means, include it.
> >
> > For example, the fact 'Movie received Rating in Country' is a ternary
that
> > could also be expressed via co-referencing or nesting. However, what
would
> > you name that co-referenced/nested object. "Country-Rating"? In this
case,
> > it is likely you would have to invent the semantics, so it is probably
> > better to leave it as a ternary.
> >
> > Also, if the semantics lean towards the expression of a relationship
> between
> > B & C, it is generally better to nest that relationship as A then to use
> > co-referencing. For example, given the facts: Student is enrolled in
> Course;
> > talking about that "Enrollment", it resulted in a Grade. In this case,
the
> > semantics intrinsically imply a relationship between Student and Course
> that
> > is of interest. So, if may be better to express this as a nested
> predicate.
> >
> > So, general cases aside, it sounds like your UoD could be easily
converted
> > to the nested case. Something like "Northing Value is combined with
> Easting
> > Value", this fact has a spanning UC and is nested as "OS Grid
Reference".
> >
> > I hope I have helped,
> > Scot.
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Scot A. Becker
> >
> > Software Consultant & Founder
> > Orthogonal Software Corporation
> > http://www.orthogonalsoftware.com
> >
> > "Chris Bruce" <chris_at_mirrorcomputing_no_spam.co.uk> wrote in message
> > news:adq61d$54o$1_at_taliesin2.netcom.net.uk...
> > > Hi All,
> > >
> > > I have a problem recording a compound reference scheme for an object
> that
> > > requires two instances of the same fact to derive the reference.
> > >
> > > For example, I want to record the OS Grid Reference for a Location and
> > wish
> > > to show/record both the component Easting and Northing values for the
> grid
> > > ref.
> > >
> > > Reference Schemes:
> > > Location(Id); OSGridRef(defined by OffsetValue of
OffsetType("Easting"),
> > > defined by OffsetValue of OffsetType("Northing"))
> > >
> > > Fact Types:
> > > Location is at OSGridRef
> > > OSGridRef is defined by OffsetValue of OffsetType
> > >
> > > Constraints:
> > > Internal uniqueness constraint over all roles of "OSGridRef is
defined
> by
> > > OffsetValue of OffsetType"
> > > Each Location has exactly one OSGridRef
> > >
> > > Sample Population:
> > > OS Reference Offset Value Offset Type
> > > (219,729) 219 Easting
> > > (219,729) 729 Northing
> > > (219,728) 219 Easting
> > > (219,728) 728 Northing
> > >
> > > In order to get the compound reference for OSGridRef I need to get the
> > > OffsetValue for OffsetType "Easting" and the OffsetValue for
OffsetType
> > > "Northing".
> > >
> > > How do I show this on the conceptual schema?
> > >
> > > I guess that the easy way out for the compound reference scheme is to
> say
> > > OSGridRef is defined by NorthingValue
> > > OSGridRef is defined by EastingValue
> > > with an external primary constraint on the pair of roles - but this
goes
> > > against the grain!
> > >
> > > Ideas? Comments?
> > >
> > > Many TIA...
> > >
> > > --
> > > CB
> > >
> > >
> >
> >
>
>