On formal HAS-A definition

#1

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?

#2

On 4 mei, 23:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

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.

#3

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.

This disagrees with my definition, once again by dropping one or
more constraints. In my definition, every part has exactly one whole.
In yours, every part has at least one whole. Also, you are comparing
all columns of the tables. but comparing the primary keys should suffice
I think. This may be a matter of taste.

Quote:

Example:

Dept = [DeptNo DeptName]
* * * * 10 * * Accounting
* * * * 20 * * Research
;

Emp = [DeptNo EmpName]
* * * *10 * * King
* * * *10 * * Smith

If King is also in dept. 20, do we still have a has-a?
I say: it depends on what you mean by has-a, but usually
we mean composition rather than aggregation, and this is
a violation of composition.

Quote:

Formally:

Emp v (Dept ^ []) < Dept v (Emp ^ []).

This is really strange. Usually Emp has attributes that
Dept doesn't have.

Quote:

I suppose HAS-A shares many unconvenient properties with set
membership, for example, it is not transitive.

I don't think I'm bothered by that fact. Belief in strong typing
tends to do that to you. An employee just isn't a department
so why would an employee ever need to pose as one?

Quote:

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"?

Yes, there is something to be said for HAS-A and IS-A notions that
allow attribute renaming. If only to allow recursive HAS-A and IS-A
(e.g. ancestor as the transitive closure of parent).

Quote:

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.

This is neither aggregation (in the weak entity sense)
nor composition (in the cardinality sense).

[...]

Quote:

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.

They are not with my (e.g. Silberschatz et al.'s) definitions.

Quote:

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.

They are not disjoint at all. They are both perfectly formalizable,
one being more specific than the other.

--
Reinier

#4

On May 7, 1:38*am, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Quote:

I don't think I'm bothered by that fact. *Belief in strong typing
tends to do that to you. *An employee just isn't a department
so why would an employee ever need to pose as one?

It looks to me like tuples are being equated with entities.

Quote:

This is neither aggregation (in the weak entity sense)
nor composition (in the cardinality sense).

Yep, there's the entity.

A relation is not a domain.

#5

On 7 mei, 01:38, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Quote:

On 4 mei, 23:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

"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.

This is neither aggregation (in the weak entity sense)
nor composition (in the cardinality sense).

I think what this tells me is that it proves that in the real world,
there exist certain kinds of has-a relationships that do not match any
of those formal definitions you refer to, meaning in other words that
those definitions are insufficient to model the real world.

Quote:

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.

They are not with my (e.g. Silberschatz et al.'s) definitions.

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.

They are not disjoint at all. *They are both perfectly formalizable,
one being more specific than the other.

Formalize what is informal and it is no longer informal.

Being less specific is precisely what I mean by "informal".

#6

"Tegiri Nenashi" <tegirinenashi (AT) gmail (DOT) com> wrote

Quote:

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.

#7

Nilone wrote:

Quote:

On May 7, 1:38*am, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
I don't think I'm bothered by that fact. *Belief in strong typing
tends to do that to you. *An employee just isn't a department
so why would an employee ever need to pose as one?

It looks to me like tuples are being equated with entities.

When justifying the definition of IS-A in the E/R-model: yes.

Quote:

This is neither aggregation (in the weak entity sense)
nor composition (in the cardinality sense).

Yep, there's the entity.

It's a little difficult to talk about identity 'is a')
without talking about entity ('is').

Quote:

A relation is not a domain.

THat is irrelevant for the IS-A I'm discussing.

--
Reinier

#8

Reinier Post wrote:

[...]

Quote:

It's a little difficult to talk about identity 'is a')
without talking about entity ('is').

This didn't come out right. I don't mean to say that
'is a' is identity, but I do think that both become
meaningless terms if they don't take entities as subjects,
so they presuppose entities.

--
Reinier

#9

"Mr. Scott" <do_not_reply (AT) noone (DOT) com> wrote

Quote:

"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.

#10

Mr. Scott wrote:

Quote:

"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.