Re: On formal HAS-A definition

On 12 mei, 06:14, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
> On May 11, 5:19 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
>
>
>
>
> > On 12 mei, 00:30, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
>
> > > 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"
> > > ...
> > > 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.
>
> > A relation has a body and a heading.  So a relation can be viewed as a
> > set of two members, after which your formalism can be made to apply.
> > And a heading is a set of attribute declarations.  So under the
> > assumption of "has-a" being transitive, I have indeed made a relation
> > "have an" attribute in the formal sense you spoke of.
>
> Nope, if we aspire to cast HAS-A after set membership, then
> transitivity has to be sacrificed.
>
> > (PS - second problem, now that I'm on it : what if you disagree with
> > the body-heading view of a relation, and want to insist that a
> > relation _IS_ a set of tuples, i.e. it does _NOT_ "have" a heading in
> > the foregoing sense,
>
> If you exclude heading from relation, then how do you represent an
> empty relation? There is only one empty set, but multiple empty
> relations!

There is no universal agreement on that. See for example "Applied mathematics for database professionals", which builds on the work from the authors' tutor, Bert De Brock.

> > but rather the heading that it "has" is just a
> > function of the body (e.g. projecting away the values from each member
> > of the body to retain only the attribute names and the attribute
> > types) ?  Then the "having" of something (e.g. an attribute) can also
> > be a consequence of a function being applied to something else (the
> > body).  In other words the "having" of something also applies if the
> > "RHS" of your 'element-of' formal concept is in fact any arbitrary
> > function applied to some set (just so long as that arbitrary function
> > yields another set).).
>
> I lost you there. The best course of actions in such circumstances to
> support your idea with an example

A body is a set of tuples. Tuples themselves are a set of ordered triples (attributename, typename, value). For a body to conform to the prescriptions of the RM, it is required that in each tuple appearing in the body, the set of attributename/typename pairs that appear in the tuple is the same. That set of attributename/typename pairs is the heading.

Now there is a view of relations that a relation 'has' both a body and a heading, and that the body 'must conform to' the "other component" of the relation, i.e. the heading.

There is another view of relations in that a relation does not 'have' a heading as such. With the consequence that "obtaining the heading" can only be achieved by "actually doing the heading extraction operation" on the body. That "heading extraction operation" consisting of taking each tuple, taking each attribute of such a tuple, "projecting away" the value from that attribute, retaining only {attributename typename}, adding that set to a pair to form the "tuple type" of the tuple under inspection, adding the tuple type so obtained to some set (the set of tuple types found in the body), and at the end verifying that that set is a singleton (and for the nitpickers : all of this is modulo type inheritance issues).

Doing that really is "applying some function to the body", no ?

But actually, I don't think it matters much any more because of your statement about having to accept non-transitivity. Received on Wed May 12 2010 - 13:31:36 CEST