Erwin wrote:

I think the correct phraseology is: That depends on the meaning has has.

On Tue, 11 May 2010 21:12:43 -0300, Bob Badour
<bbadour (AT) pei (DOT) sympatico.ca> wrote:

[snip]

No. 1) I *am* a self. 2) I do not have any employees, keep
slaves, etc.

Sincerely,

Gene Wirchenko

Gene Wirchenko wrote:

In other words, both operations have the same identity element.

On May 11, 5:19*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Nope, if we aspire to cast HAS-A after set membership, then
transitivity has to be sacrificed.

If you exclude heading from relation, then how do you represent an
empty relation? There is only one empty set, but multiple empty
relations!

I lost you there. The best course of actions in such circumstances to
support your idea with an example.

On May 12, 12:30*am, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
I consider x IS-A y as a relation named y with a unique constraint on
x. Your thoughts?

I consider x HAS-A y as a relation which includes attributes x and y.
A unique constraint on y denotes aggregation, the lack of it
association.

I know you often talk of relational lattices, which I still don't
comprehend, nor do I understand what you mean here. I would like to,
if you care to promote your view to me.

On 12 mei, 06:14, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
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.

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.

On May 12, 4:31*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Page#, please? In foreword Date & Darwen say that there is only one
empty relation (when ignoring types). This indicates that by "empty
relation" they meant something else, I suspect R00 (aka DUM). I
thought standard definition for an empty relation requires it to have
empty set of tuples only (with no constraint on the header).

BTW, here is algebraic characterization of an empty relation x

x < R00

that is

x ^ R00 = x

I support it. Here is algebraic characterization (Fundamental
Decomposition Identity)

x = (x ^ R00) v (x ^ R11)

We can interpret relation x as being [generalized] union of the two
parts: the header -- x ^ R00 -- that is relation with empty content,
and the body -- x ^ R11 -- which lost all information about
attributes.

To lighten up FDI within a more familiar context, here is Boolean
Algebra identity (which name escaped me at the moment)

x = (x ^ y) v (x ^ -y)

Given that R00 and R11 are "inverse complements" of each other, that
is

R11 = R00`' = R00'`

one can expect that Generalized FDI in the form:

x = (x ^ y) v (x ^ y'`)

and

x = (x ^ y) v (x ^ y`')

and indeed one of them is RL identity (and, curiously, the other one
is not!)

So how exactly is it done for an empty relation? There is no tuples!

On May 12, 12:53*am, Nilone <rea... (AT) gmail (DOT) com> wrote:
I'm lost. Example, please?

Well, I was impressed by Smith&Smith "Aggregation and Generalization"
paper a while while ago, but since the rise of UML avoid using these
terms. Again, example, please.

Well, how about "Gentle introduction to relational lattice"? Better
yet, you appears to have solid programming background, so I assume
downloading http://qbql.googlecode.com/svn/trunk/dist/qbql.jar
or even checking in QBQL project in Eclipse wouldn't be a problem?

On 12 mei, 18:12, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
Eurhm, page 1 to 330, I would say. The book consistently references
the empty relation as FI (you know, the circle with the "forward
slash" intersecting it), untyped.

On page 95, bottom paragraph of the section discussing "the definition
of a table", we find for example :

"Even the empty set is a table. In fact, under Definition 5-1 (...),
the empty set is a table over any set. ..."

(Between brackets : the choice of the term "table" here is because the
intended audience of the book is, first and foremost, SQL
practitioners. I'm quite sure that the authors knew what the better
term is.)



I suspect that the "multiple typed empty relations versus one single
empty relation for all (relation) types" relates closely to whether
the intent is to define a data manipulation language. D&D have that
intent, so they need assignment, so they need to address/resolve the
issues caused by "one single empty relation for all types". AM4DP
does not have that intent (its prime intent is to define a database
design specification language that has solid foundations in maths), so
they don't run into things such as 'assignment' and 'compile-time type
checking' and such. So they can cleanly get away with the "one single
empty relation for all relation types" position.



I don't know. It is not my preferred point of view either. I suspect
proponents of this point of view would address this problem by saying
that the empty relation does not have any particular heading/type.
Once again, I suspect whether one can get away with that position
depends on the intended goal to achieve.

On May 12, 11:54*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
This is shocking revelation to me. I failed to imagine somebody would
ever consider the two relations

PersonSalary = [name salary];

and

PersonName = [name];

to be identical. An informal argument is that any nonempty relation
carries over information about the header (attribute set), and empty
relation loses it. This is very unnatural break of continuity from
mathematical perspective. I'm pretty sure if somebody would ever come
with axiomatization of their table algebra, it would have weird
properties. For one thing, if I add it to RL axioms:

x ^ y = y ^ x.
(x ^ y) ^ z = x ^ (y ^ z).
x ^ (x v y) = x.
x v y = y v x.
(x v y) v z = x v (y v z).
x v (x ^ y) = x.

x ^ (y v z) = (x ^ (z v (R00 ^ y))) v (x ^ (y v (R00 ^ z))).

x ^ R00 = y ^ R00.

then it immediately derives distributivity of ^ over v. There
certainly is a counterexample for distributivity with all three
relations being nonempty:

z = [p q r]
0 a 0
0 c 0
1 a 0
;
y = [q]
a
;
x = [p]
1
;

Now I that you are kindly explained this passage, I'll venture off,
because they start with the false premise that there is a single empty
relation.