Re: On formal HAS-A definition
Date: Thu, 6 May 2010 03:09:04 -0700 (PDT)
Message-ID: <05d4fbe7-96c6-46c1-b69d-14a7f30567f8_at_k29g2000yqh.googlegroups.com>
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.
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. Received on Thu May 06 2010 - 12:09:04 CEST