On formal HAS-A definition

#21

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:

Mr. Scott wrote:
"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote in message
news:4be5b09f$0$26945$9a566e8b (AT) news (DOT) aliant.net...
Mr. Scott wrote:

"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote in message
news:4be59bfa$0$12451$9a566e8b (AT) news (DOT) aliant.net...

Mr. Scott wrote:

"Mr. Scott" <do_not_reply (AT) noone (DOT) com> wrote in message
news:Atqdnbh1eNZ_YX7WnZ2dnUVZ_g-dnZ2d (AT) giganews (DOT) com...

"Tegiri Nenashi" <tegirinenashi (AT) gmail (DOT) com> wrote in message
news:0b0623a8-7a8c-476b-8de2-78c31a36ab17 (AT) f17g2000pra (DOT) googlegroups.com...

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?
I don't think nontrivial functional dependencies have any bearing on
whether or not there is a 'has-a' relationship; instead, it is the
juxtaposition of attributes in a relation scheme under the
convention that it is not just components that are significant but
also tuples. If there is a mapping from tuples into the domain of
discourse, then it follows that the components of a tuple map to
parts of the whole that the tuple maps to.
One could argue that a trivial functional dependency from the
superkey that consists of the entire heading of a relation to any
proper subset of the heading specifies a 'has-a' relationship.

I should also point out that because 'has-a' relationships are in
essence part-whole relationships, that they are transitive. For
example, cars have tires; tires have rims; therefore, cars have rims.
Except that not all cars have tires--some are on blocks. We could just
as legitimately say that all tires have cars.
Without tires, there is no car, but it is not necessary for a car's
tires to be physically attached for them to be part of the car.
That's absurd. A car without tires remains a car just as an amputee
remains a human being.

A vehicle that never has had nor can have tires is not a car. If the car
is on blocks, then even though its tires have been removed, they're still
the car's tires. A car that is still on the assembly line also has
tires--even if they haven't yet been ordered. If someone were to ask,
"Where are that car's tires?" It would be really strange to hear an
answer like "there aren't any." Instead, one might say, "they've been
put on another car," or "they're on order," or "they've been stolen."

An amputee's limb is still his limb even though it has been removed, but
even so, having four limbs isn't essential to being a human, whereas
having tires is essential to being a car.

And yet a railcar doesn't have tires and only some subway cars have tires.
In fact, I believe the first use of car referred to conveyances on iron
wheels. But put my subjectivity aside, all that matters in db design and
usage is agreement among a db's users as to what the attributes stand for
(I believe this is both an advantage as well as a requirement and the
Information Principle encourages adherence). Some of those users might
even need to suppress their cultural biases. The subjective and
doctrinaire stuff doesn't belong here no matter important people such as
Celko try to make it sound because they have an interest in promoting
dull, lazy minds in the db population. Same goes for obscure set axioms
that would appear to prevent users from thinking of sets of people, not
just animals, unless those approaches can lead to some practical
advantage. Why theorists would argue about such meanings is beyond me.

I think you're oversimplifying. It is necessary for there to be agreement
not only on what attributes stand for, but also on what components and sets
of components stand for. The propositions represented by tuples in the
database are not logical truths but rather analytic truths, which involve
valuation and assignment under a particular interpretation.

I must admit that I should have just ignored Bob's stupid remark concerning
tires having cars, but I decided to give him the benefit of the doubt.
Unfortunately, he is very good at baiting people, and this time I fell into
his trap. Never again, though. I perceive no great loss in putting him in
the killfile. I can't remember the last time that he contributed anything
novel or worthwhile or even constructive--at least nothing that can't be
found in my copy of TTM.

#22

Snipped.

Quote:

The propositions represented by tuples in the
database are not logical truths but rather analytic truths, which involve
valuation and assignment under a particular interpretation.
I do not see the point in blurring the lines between database theory

and philosophy. Introducing subjectiveness into db design defeats its
purpose as a collective foundation for building systems.

Snipped.

#23

On May 9, 8:33 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

And yet a railcar doesn't have tires and only some subway cars have
tires.

Getting off topic but I thought all rail car wheels have tyres (made
of hard wearing steel and heated before placing on the wheel).

#24

On May 6, 2:09*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

On 4 mei, 23:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) 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...

#25

Tegiri Nenashi wrote:

Quote:

On May 6, 2:09 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

On 4 mei, 23:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) 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".

#26

On May 11, 3:46*pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

Tegiri Nenashi wrote:
On May 6, 2:09 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

On 4 mei, 23:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) 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...

#27

Tegiri Nenashi wrote:

Quote:

On May 11, 3:46 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Tegiri Nenashi wrote:

On May 6, 2:09 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

On 4 mei, 23:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) 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...

Doesn't everyone have a self?

#28

On 12 mei, 00:30, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

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.

I'm just not sure whether such formalism can be made to be of any
practical value. Precisely because you can pick any type of set just
in order to make the formalism apply.

(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, 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).).