On formal HAS-A definition

#11

"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote

Quote:

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.

#12

On May 8, 2:12*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Quote:

Nilone *wrote:
It looks to me like tuples are being equated with entities.

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

What do you mean? I'm thinking:

- E/R model entities and attributes are elements of domains
- E/R model relationships are relations over domains
- Tuples are the elements of relations over domains of entities
- IS-A is an isomorphism between domains of entities
- HAS-A is a monomorphism between domains of entities

So when it looks like an entities are equated with tuples, I wonder
why. I believe it's a mistake to do so, but perhaps I'm missing
something.

Quote:

A relation is not a domain.

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

My apologies for jumping to conclusions. I would like to understand
the IS-A you're discussing. I'll continue reading.

#13

Mr. Scott wrote:

Quote:

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

#14

Nilone wrote:

Quote:

On May 8, 2:12 pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Nilone wrote:

A relation is not a domain.

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

My apologies for jumping to conclusions. I would like to understand
the IS-A you're discussing. I'll continue reading.

This is where Clinton becomes vitally important.

#15

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

Quote:

This is where Clinton becomes vitally important.

I'm pleased to see a direct reply from you, Bob. Does that mean I'm
not killfiled anymore? I was hoping that one day my vociferous
ignorance and flippant attitude could be forgiven if I studied
hard.

#16

Nilone wrote:

Quote:

On May 8, 8:44 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

This is where Clinton becomes vitally important.

I'm pleased to see a direct reply from you, Bob. Does that mean I'm
not killfiled anymore? I was hoping that one day my vociferous
ignorance and flippant attitude could be forgiven if I studied
hard.

I was having usenet problems a few weeks ago. In the process of getting
things to work, I unsubscribed and resubscribed to c.d.t.

I guess I lost all my filters and didn't realise it.

That explains why I suddenly see so much nonsense again. Now that I'm
aware of it, I will be more vigilant and less forgiving of stupidity.

#17

"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote

Quote:

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.

#18

Mr. Scott wrote:

Quote:

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

#19

Mr. Scott wrote:

Quote:

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

You are a complete fucking idiot.

#20

"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> 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.

You are a complete fucking idiot.

Plonk!