Re: On formal HAS-A definition
Date: Tue, 11 May 2010 20:46:37 -0300
Message-ID: <4be9ec62$0$12463$9a566e8b_at_news.aliant.net>
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". Received on Wed May 12 2010 - 01:46:37 CEST