Re: On formal HAS-A definition

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 "attributecompatible"  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... Received on Wed May 12 2010 - 00:30:34 CEST