Re: On formal HAS-A definition

Tegiri Nenashi wrote:

> On May 11, 3:46 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>

>>Tegiri Nenashi wrote:
>>
>>>On May 6, 2:09 am, Erwin <e.sm..._at_myonline.be> wrote:
>>
>>>>On 4 mei, 23:21, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
>>
>>>>>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?
>>
>>>>My feeling is you are treading slippery territory.
>>
>>>>"Each customer has an address" can (and may likely) be modeled as two
>>>>distinct relvars, with an inclusion dependency / FK-like database
>>>>constraint / howyouwanttonameit between the two.
>>>>"Each customer has a name" is likely to be modeled as an attribute
>>>>appearing in one single relvar.  In this case, the nearest thing
>>>>resembling an inclusion dependency, is INSIDE the catalog, where it is
>>>>recorded that some attribute appears in some relvar, and where it is
>>>>the case that an inclusion dependency holds between the catalog relvar
>>>>defining the attributes and the catalog relvar defining the database
>>>>relvars.
>>
>>>>As I already stated elsewhere, my feeling is that "is-a" and "has-a"
>>>>are part of the world of informal modeling, database constraints are
>>>>part of the world of formal modeling.  Those two worlds are disjoint,
>>>>and the only connection between them is that one (informal) may act as
>>>>the input for the designer who is deciding how to define the other.
>>
>>>IMO there is a benchmark formal definition for both HAS-A and IS-A
>>>already. Both are set theory concepts:
>>>HAS-A = "element of"
>>>IS-A = "subset of"
>>>So one can just check up their defining axioms and try to carry them
>>>over to relational field. Again, the IS-A case seems easier because we
>>>already have subset relationship defined for each pair of "attribute-
>>>compatible" relations. Relational order is a perfect candidate for
>>>generalizations, because it has simpler definition (not requiring
>>>extra functional dependency). Math is about profound and simple ideas,
>>>after all.
>>
>>>I'm not that sure about the HAS-A. Certainly, one can assert that a
>>>set of attributes has an attribute, but this is quite different from
>>>saying that a relation has an attribute. In addition to that, the
>>>algebraic picture [which many of you are aware I'm promoting] tries to
>>>demote attributes from being first-class citizens of relational
>>>model...
>>
>>Perhaps it generalizes to "containment" rather than just "element of".

Doesn't everyone have a self? Received on Wed May 12 2010 - 02:12:43 CEST