Re: Objects and Relations
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 16 Feb 2007 23:07:11 GMT
Message-ID: <zOqBh.7420$R71.110825_at_ursa-nb00s0.nbnet.nb.ca>
>> 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).
Date: Fri, 16 Feb 2007 23:07:11 GMT
Message-ID: <zOqBh.7420$R71.110825_at_ursa-nb00s0.nbnet.nb.ca>
Bob Badour 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.
But what do we do about the wheels? Received on Sat Feb 17 2007 - 00:07:11 CET