Re: ORM Compound Reference Scheme Problem
Date: Fri, 7 Jun 2002 21:49:31 -0500
Message-ID: <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
>
>
Received on Sat Jun 08 2002 - 04:49:31 CEST