Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Objects and Relations

Re: Objects and Relations

From: David BL <davidbl_at_iinet.net.au>
Date: 14 Feb 2007 00:08:10 -0800
Message-ID: <1171440490.829836.5980@p10g2000cwp.googlegroups.com>


On Feb 14, 2:42 pm, "Keith H Duggar" <dug..._at_alum.mit.edu> wrote:
> David BL wrote:
> > I've been thinking about the following example: There is a
> > collection of Lego pieces and we want to store information
> > about how they have been connected in various configurations.
>
> You are begging the question since "Lego pieces" assumes
> entities. That is, I'm certain in your mind piece = entity.

I'm trying not to assume anything! But surely in order to state the problem, nouns will appear in the natural language sentences.

> > An interesting question is whether we try to distinguish
> > pieces that for all intensive purposes look the same.
>
> The phrase is "intents and purposes". And "look the same"
> hardly encompasses all the facts we can state (see below).
>
> > It would appear not, otherwise we will be forced to get
> > out a felt tip pen and give them unique identifiers, and
> > we don't want to do that. Therefore a particular piece is
> > only described (but not uniquely identified) by its
> > attributes (eg its colour and dimensions).
>
> You seem to have completely forgotten about /location/ in
> space even though you started by mentioning "configurations"
> which has everything to do with location.

Yes I see that. The pennies are falling!

I was assuming there happens to be no need to specify exact locations of pieces in space using (x,y,z), but we do need to represent the way pieces have been snapped together. ie we were told that in the problem specification.

Are you saying connectivity graphs (where nodes are associated with Lego pieces) is not the right way to think at all - ie to properly embrace RM?

If a large connected composite of Lego pieces is moved around in space then we need to update all the positions of the pieces and that seems inefficient. With scenegraphs we can introduce the concept of local coordinate systems. In fact the ability to define homogenous transforms as decorator nodes in the scenegraph appears to be quite useful. Is there some way of getting the equivalent of these features in a relational model?

I guess a concrete example would be a robot arm where the segments are constructed from Lego pieces and each joint is paramerterised by a joint angle. Can you outline a suitable relational model?

> And again, plenty
> of begging the question there with "piece", "them", "its",
> "identifiers". Do you see how your language and frame of
> mind is steeped in "entity" brew?

I guess. Are you suggesting that even the problem description should avoid mention of entities. Is that possible?

> > This all sounds well and good. Unfortunately I don't see
> > how we are going to store the information about what is
> > connected to what unless we identify the pieces themselves.
>
> Because you forgot about spatial location.
>
> > This is an unfortunate paradox.
>
> It's been said that just about anything is a paradox to
> someone out there.
>
> > On the one hand we need to uniquely identify the pieces in
> > order to represent the structure
>
> No we don't. "pieces" and especially piece "identity" are
> unnecessary.
>
> > and on the other hand, at some higher level we aren't at
> > all interested in the identity of the pieces.
>
> Well, we agree on that. At the moment though, you are still
> peering up to that higher ground from the entity quagmire.

I still can't help feeling it's strange to state propositions about Lego configurations and ignore/deny the fact that the pieces exist. Is it more a case of it being better for the development of the relational schema and not so much about how we interpret what is actually going on? Received on Wed Feb 14 2007 - 02:08:10 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US