Re: ORM Compound Reference Scheme Problem

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

> >

> >

>

>