Re: Objects and Relations

On Feb 14, 6:46 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> On Feb 15, 12:36 am, "Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com>
> wrote:
>
>
>
>
>
> > On Feb 14, 7:12 am, "Cimode" <cim..._at_hotmail.com> wrote:
>
> > > [Snipped crap from Keith Duggar]
>
> > > > Nevertheless, for the benefit of other readers if nothing else, let me
> > > > state that Keith has hit the nail on the head.
>
> > > No. Keith has just once shown more misunderstanding of RM and
> > > arrogance.
>
> > > > 1) Lego blocks are /not/ the same. They always have a different
> > > > location attribute.
>
> > > BS. LegoBlock are indeed the same if they are to be a relation.
>
> > > Stating that location attribute is a primary natural key for a
> > > LegoBlock is arbitrary and does not reflect the reality of
> > > LegoBlocks. Imagine a M:N cardinality between LegoBlock and Location
> > > Entity. In that case LocationEntity has a natural identifier (X, Y,
> > > Z). The natural identifier of a lego block could be a combination of
> > > its shape, color but certainly not its location.
>
> > > > 2) Hence their x,y,z position attribute always identifies them.
>
> > > False.
>
> > > > 3) However this identifer is very hard to record and keep track of,
> > > > even though it exists.
>
> > > In the mind of people which pointer's obsessed maybe...
> > > There is nothing complex about the identifier of a location is a
> > > concatenation of XYZ and a referential.
>
> > > > 4) So we represent it with a surrogate identifer (which is hence just
> > > > an 'untrackable' attribute or, as others refer to it, an unfamiliar
> > > > attribute).
>
> > > In other words, Surrogate identifier has only the advantage of being
> > > *familiar*.
>
> > > > 5) OID's are hence not needed, and everything is just a value, as it
> > > > should be.
>
> > > OID = Implementation of Surrogate Key IF AND ONLY IF
> > > --> unicity contraint has been implemented on the implementation of
> > > the natural key
> > > --> unicity constraint implemented on the OID
> > > --> contraint of cardinality implemented 1:1 between the
> > > implementation of the natural key and the OID....
>
> > > In other words, almost never happens...
>
> > > > 6) When I finally understood this (and it was a hard mental slog to
> > > > shake off my OO mindset) I found it quite revelationary to my
> > > > perspective on data management.
>
> > > Guess we all went through this at some point in time...
>
> > > [rest snipped]
>
> > I have to agree with Cimode - Keith's contribution seemed a little...
> > off. Assuming lego blocks are of the simple cuboid variety with
> > standard male and female connectors, a configuration can be expressed
> > as tuples in the following relation (asterisks indicate the natural
> > key columns):
>
> > CONNECTION (male_color*, male_thickness*, male_num_cols*,
> > male_num_rows*, male_column*, male_row*, female_color*,
> > female_thickness*, female_num_cols*, female_num_rows*, female_column*,
> > female_row* , rotational_angle)
>
> How can this work? There is nothing to distinguish the individual
> Lego blocks. Your key for a connection only makes use of the /type/
> of Lego block (parameterised by colour and shape).
>
>
Damnit - for the third time in as many days, I will try to send a response. This time I'll type in notepad first, ensuring that it will work.

Anyway, I see I've treated the problem quite poorly; in fact one cannot express a configuration without reference to individual Lego blocks. I apologize for the confusion, and moreso to Kieth for dismissing what was, in retrospect, a valid point.

However, there is still no need to model individual Lego blocks as real-world distinct entities (e.g. with a global Block_Id uniquely assigned to pieces across all configurations); one merely needs to identify Lego blocks according to their role within a configuration. This can be done with a compound surrogate key, e.g. arbitrarily numbering pieces within each configuration; or with a meaningful natural key, such as the x, y, z distance (in integral "standard Lego units") of the leftmost, foremost, bottommost corner of each piece from intersection of the leftmost, foremost, and bottommost edge of the overall configuration.

I believe a full configuration could than be specified as:

Config_pieces (config_name*, x*, y*, z*, color, width, depth, height, orientation).

>
>
>
> > Of course, this is not a complete schema - depending on application
> > needs, one might add other base relations to enforce entegrity and
> > store other information; for instance:
> > LEGO_BLOCK (color*, thickness*, num_cols*, num_rows*, price,
> > inventory, ...)
> > COLOR (color*)
>
> > But the point is that there is NO need for "lego block entity"
> > identifiers (which makes sense: an entity id might give the impression
> > that instantiating a new red 2x3x3 LegoBlock object with OID #254 and
> > swapping it out for an existing red 2x3x3 LegoBlock object with OID
> > #120 somehow changes the configuration).- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Received on Fri Feb 16 2007 - 15:23:29 CET