Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambrium.nl!feed.tweaknews.nl!postnews.google.com!g17g2000prg.googlegroups.com!not-for-mail From: JOG Newsgroups: comp.databases.theory Subject: Re: Modeling question... Date: Tue, 11 Nov 2008 08:58:30 -0800 (PST) Organization: http://groups.google.com Lines: 159 Message-ID: <14677dbe-47d1-4f7d-9b70-edeccd7c9611@g17g2000prg.googlegroups.com> References: <96e644dc-2063-44ea-9d41-ce27970927e0@l64g2000hse.googlegroups.com> <2c386a22-5abc-4a95-8723-8461e04b9022@17g2000hsk.googlegroups.com> <3ae3b821-834b-43da-bf09-dd45719df152@c60g2000hsf.googlegroups.com> <3f450497-2483-4775-afd0-b7d5fa955745@d1g2000hsg.googlegroups.com> <83cea90f-78af-4113-a02d-55649d31a9b2@v30g2000hsa.googlegroups.com> <7b86525e-0e78-486b-a677-ca3a80daf5e3@p58g2000hsb.googlegroups.com> <8d9f2fb3-8981-4e78-aef9-50b5b6e04ee6@a17g2000prm.googlegroups.com> NNTP-Posting-Host: 128.243.220.22 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1226422710 32396 127.0.0.1 (11 Nov 2008 16:58:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 11 Nov 2008 16:58:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g17g2000prg.googlegroups.com; posting-host=128.243.220.22; posting-account=H0ckjQoAAADRgkguzQRGVwl65wXgA5te User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3,gzip(gfe),gzip(gfe) X-HTTP-Via: 1.1 cache2.nottingham.ac.uk:3128 (squid/2.5.STABLE3) Xref: news.cambrium.nl On Oct 30, 2:03=A0pm, 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 predica= te > > > > > > 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 th= is > > > > 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. =A0 For example, consider tri- > > > surface as a value-type. =A0A 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. =A0It seems appropriate to introduce abstract identifiers for > > > the vertices in order that they may be shared. > > > This is evidently a relational solution. =A0However unlike typical us= es 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. =A0I presume it is inferred from the integrity > constraints. =A0Is 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?). >=A0Does 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. =A0 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. =A0The 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. =A0The obvious > solution seems to be to reference a single shared geometry for a wheel > - hence the need for an abstract identifier. =A0Are you suggesting that > an alternative is to instead use an integrity constraint! =A0 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? =A0I 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. =A0Note as well that th= is > > > 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 whe= n > > > it is useful to express the concept of "common sub-expressions" withi= n > > > nested value-types. =A0Note that scene graphs are typically thought o= f > > > 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) updat= e > > > anomalies. =A0 The existing normalisation theory in the literature se= ems > > > 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).