Re: On formal HAS-A definition
Date: Thu, 6 May 2010 03:09:04 -0700 (PDT)
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
> 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. Received on Thu May 06 2010 - 05:09:04 CDT