Re: Objects and Relations

On Feb 17, 8:01 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Kevin Kirkpatrick wrote:
> > 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).
>
> If you have x, y, z, deltaX, deltaY, and deltaZ you won't need
> orientation. The location of a piece is actually an interval

Yes, because Lego blocks can only be rotated about the vertical axis z by 0,90,180,270 degrees. The interval approach also brings out their symmetry under rotation by 180 degrees. Also square shaped blocks (deltaX = deltaY) are symmetric under rotation by 90 degrees. Received on Sat Feb 17 2007 - 01:00:59 CET