Re: On formal HAS-A definition

From: Mr. Scott <do_not_reply_at_noone.com>
Date: Fri, 7 May 2010 07:43:30 -0400
Message-ID: <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. Received on Fri May 07 2010 - 13:43:30 CEST

Original text of this message