Re: Modeling question...

From: JOG <>
Date: Tue, 11 Nov 2008 08:58:30 -0800 (PST)
Message-ID: <>

On Oct 30, 2:03 pm, David BL <> wrote:
> On Oct 30, 7:41 pm, JOG <> wrote:
> > On Oct 30, 1:51 am, David BL <> wrote:
> > > On Oct 29, 8:39 pm, JOG <> wrote:
> > > > On Oct 29, 2:37 am, David BL <> wrote:
> > > > > On Oct 29, 9:13 am, JOG <> wrote:
> > > > > > The RM handles facts as naturally as stating them in predicate logic.
> > > > > > And why would one ever model things other than facts in predicate
> > > > > > logic?
> > > > > Exactly!
> > > > Then may I suggest that your argument is not with the RM, but with the
> > > > use of predicate logic to model equations, engines, etc. And yet this
> > > > to me seems trivially true - if I was modelling a human in an art
> > > > class I'd use clay, not predicate logic.
> > > I don't think it's quite so trivial.   For example, consider tri-
> > > surface as a value-type.  A simple type decomposition as a set of
> > > triangles where each triangle is independently defined by 3 vertices
> > > doesn't express the constraint that the triangles tend to meet each
> > > other.  It seems appropriate to introduce abstract identifiers for
> > > the vertices in order that they may be shared.
> > > This is evidently a relational solution.  However unlike typical uses of the RM there
> > > doesn't appear to be some external UoD to which the tuples,
> > > interpreted as propositions can be related.
> > I use Oracle Spatial to do exactly this sort of thing day in day out
> > in a geospatial domain, and no abstract identifers are introduced. The
> > coordinates of any vertex are used. That is what identifies them -
> > that is what is used (note that these coordinates can happily be
> > relative). Constraints to maintain adjacency use the spatial operators
> > offered by SDO_RELATE. It is very good.
> > I karate chop your example to pieces! Haiii-ya.
> Please forgive my ignorance - I'm not familiar with Oracle Spatial.

First apologies for the delay in response. I have been distracted by TTM.
> Are you suggesting that for a tri-surface all that is needed is a
> single relation for the triangles,

No, I meant I work with the polygon (SDO_GEOM) object types which Oracle Spatial makes available. Tri-surfaces are a different kettle of fish no doubt.

> and when for example you want to
> change what is conceptually a shared vertex (and so which is
> understood to impact multiple triangles), it is assumed that all
> vertex values that appear in the relation with that same value (ie
> coords) are indeed logically shared and therefore are all
> automatically updated by the DBMS at the same time?
> If so it is not
> clear to me how and when the DBMS knows that such an elaborate update
> policy is required.  I presume it is inferred from the integrity
> constraints.  Is that right?

That seems a likely method for checking constraints between polygon instances. However, I think it is symptomatic of a design flaw if one is trying to model these tri-surface jib jobs (which I assume, are continuous 3d surfaces made up of triangles, as are used in graphic models, reaching back to the old days of elite?).

> Does the DBMS provide such a facility in
> a generic way?

No. One would add the check as a constraint. However, it would be very inefficient I imagine - I could see objections to this that you might respond with (With a typed approach however the situation is inevitable, because a geometry instance encapsualtes/hides away its identifying qualities (being an object). This means they are not exposed to the RA.

> This reminds me of the idea that one can change the key of a tuple in
> a relation and have the DBMS automatically update all foreign key
> references across the entire database.
> Anyway, I think there are data entry applications where the concept of
> "shared values" needs to be under user control.   For example in the
> data entry of a CAD drawing of a car the user may or may not want all
> the wheels to share the same geometry.  The problem with simple copy
> and paste (and no logical sharing) is that any future edits to the
> wheel geometry need to be repeated on every copy.  The obvious
> solution seems to be to reference a single shared geometry for a wheel
> - hence the need for an abstract identifier.  Are you suggesting that
> an alternative is to instead use an integrity constraint!   If so how
> can you specify which geometries are logically tied and which are not
> (ie even though they just happen to be equivalent in value at that
> moment in time)? Doesn't that require abstract identifiers of some
> sort anyway?  I can't imagine that values that happen to be the same
> are always assumed to be shared, because then it would be impossible
> for a user to copy and paste a value in order to create a copy that
> will subsequently diverge.

One of the other reasons that my reply took time, was that I have thought reasonably hard about the issues you have raised and come to conclude that you are right. At least right in the sense that I now concur that RM can't cope with the example without adding RVA's or inventing artificial identifiers. And both approaches are hack jobs as far as I'm concerned.

On analysis, I think that you have tangentially identified a serious issue with the RM (and not a case for recursive types per se - this is an attempt to solve the issue, rather than describing the cause, and care should be taken not to conflate the two). I will post when I get more time if you are interested in my thought process, but it has clarified some nagging concerns I have had concerning the universal application of 1NF.

Either way I have found the tri-surface and illuminating example. Regards, Jim.

> > > Rather it seems that a particular tri-surface /value/ has introduced a local and private
> > > namespace in order to privately apply the RM.  Note as well that this
> > > is not like an RVA (where we think of only a single relation as a
> > > value) because a tri-surface value is associated with /two/ relations
> > > - one for the vertices and another for the triangles.
> > > I have wondered whether abstract identifiers are needed precisely when
> > > it is useful to express the concept of "common sub-expressions" within
> > > nested value-types.  Note that scene graphs are typically thought of
> > > as DAGs not trees for precisely this reason.
> > > I think there is an interesting interplay between 1) degrees of
> > > freedom (or entropy or storage space if you like) in the encoding of a
> > > value, 2) abstract identifiers, 2) integrity constraints and 4) update
> > > anomalies.   The existing normalisation theory in the literature seems
> > > relevant but doesn't seem to me to account for recursive type
> > > definitions and abstract identifiers.
> > I am yet to be convinced of the need for abstract identifers (or
> > invention of recursive types) from the examples offered so far.. the
> > wff is the most interesting, but I am currently questioning the sense
> > or utility of decomposing an equation in such a manner /at the logical
> > level/ (as opposed to the physical).
Received on Tue Nov 11 2008 - 17:58:30 CET

Original text of this message