Re: On formal HAS-A definition
Date: Sat, 8 May 2010 18:54:03 -0400
Message-ID: <OdOdnWiy4_UWdnjWnZ2dnUVZ_gWdnZ2d_at_giganews.com>
"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
news:4be5b09f$0$26945$9a566e8b_at_news.aliant.net...
> Mr. Scott wrote:
>
>> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
>> news:4be59bfa$0$12451$9a566e8b_at_news.aliant.net...
>>
>>>Mr. Scott wrote:
>>>
>>>
>>>>"Mr. Scott" <do_not_reply_at_noone.com> wrote in message
>>>>news:Atqdnbh1eNZ_YX7WnZ2dnUVZ_g-dnZ2d_at_giganews.com...
>>>>
>>>>
>>>>>"Tegiri Nenashi" <tegirinenashi_at_gmail.com> wrote in message
>>>>>news:0b0623a8-7a8c-476b-8de2-78c31a36ab17_at_f17g2000pra.googlegroups.com...
>>>>>
>>>>>
>>>>>>Again, I didn't research literature, but here is my shot: the HAS-A is
>>>>>>an inclusion dependency. Example:
>>>>>>
>>>>>>Dept = [DeptNo DeptName]
>>>>>> 10 Accounting
>>>>>> 20 Research
>>>>>>;
>>>>>>
>>>>>>Emp = [DeptNo EmpName]
>>>>>> 10 King
>>>>>> 10 Smith
>>>>>>;
>>>>>>
>>>>>>Formally:
>>>>>>
>>>>>>Emp v (Dept ^ []) < Dept v (Emp ^ []).
>>>>>>
>>>>>>I suppose HAS-A shares many unconvenient properties with set
>>>>>>membership, for example, it is not transitive. Consider
>>>>>>
>>>>>>Accounts = [EmpName Institution]
>>>>>> Smith BoFA
>>>>>> Smith WellsFargo
>>>>>>;
>>>>>>
>>>>>>the it is not the case that "Dept HAS-A Accounts". Again, the naming
>>>>>>problem raises its ugly head: why would the first attributes be called
>>>>>>"EmpName" rather than "PersonName"?
>>>>>>
>>>>>>More important: is this correct formalization? Specifically, shouldn't
>>>>>>functional dependency
>>>>>>
>>>>>>Dept # DeptNo < Dept # DeptName
>>>>>>
>>>>>>be a part of HAS-A constraint definition?
>>>>>
>>>>>I don't think nontrivial functional dependencies have any bearing on
>>>>>whether or not there is a 'has-a' relationship; instead, it is the
>>>>>juxtaposition of attributes in a relation scheme under the convention
>>>>>that it is not just components that are significant but also tuples.
>>>>>If there is a mapping from tuples into the domain of discourse, then it
>>>>>follows that the components of a tuple map to parts of the whole that
>>>>>the tuple maps to.
>>>>
>>>>One could argue that a trivial functional dependency from the superkey
>>>>that consists of the entire heading of a relation to any proper subset
>>>>of the heading specifies a 'has-a' relationship.
>>>>
>>>>I should also point out that because 'has-a' relationships are in
>>>>essence part-whole relationships, that they are transitive. For
>>>>example, cars have tires; tires have rims; therefore, cars have rims.
>>>
>>>Except that not all cars have tires--some are on blocks. We could just as
>>>legitimately say that all tires have cars.
>>
>> Without tires, there is no car, but it is not necessary for a car's tires
>> to be physically attached for them to be part of the car.
>
> That's absurd. A car without tires remains a car just as an amputee
> remains a human being.
A vehicle that never has had nor can have tires is not a car. If the car is
on blocks, then even though its tires have been removed, they're still the
car's tires. A car that is still on the assembly line also has tires--even
if they haven't yet been ordered. If someone were to ask, "Where are that
car's tires?" It would be really strange to hear an answer like "there
aren't any." Instead, one might say, "they've been put on another car," or
"they're on order," or "they've been stolen."
An amputee's limb is still his limb even though it has been removed, but
even so, having four limbs isn't essential to being a human, whereas having
tires is essential to being a car.