Re: On formal HAS-A definition

On May 11, 3:46 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> 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".

Not sure if your comment refers to IS-A or HAS-A. Couple clarifications:

"Relational order is a perfect candidate for generalizations, because it has simpler definition (not requiring extra functional dependency)"

This sentence looks sloppy. Lattice order (not relational order) defined via

x ^ y = x <-> x < y

where "^" is natural join operation, is profound definition. It is strengthened by the fact that

x v y = y <-> x < y

defines the same order. Adding functional dependency condition looks like an extra complication.

My attempt onto formal HAS-A definition fails, because it follows that

x HAS-A x

for any relation x, while in the set theory x HAS-A x doesn't hold for at least some x... Received on Wed May 12 2010 - 02:10:37 CEST