We never "need" RVA's.

Recursive type declarations work just fine without any problems.
Recursive value declarations would not. You seem to keep thinking
recursive type declarations have the same problems as recursive value
declarations. They don't.

R = { A int, B typeof R } -- works
R = { 1, valueof(R) } -- blowed up real good

Oops.  I meant a list of sets.

Roy

Ahh, good.  I've waited since 2003 for someone in this newsgroup to tell
whether the toppings on a pizza are a set or a list.  Until your answer,
just now,  no one really rose to the challenge.  Thanks!

Your answer raises the question of whether in a pizzeria like Domino's,  the
order of toppings stated by the client should be preserved in the order, so
that the chef can honor the customer's wishes,  or whether it should be
retained as a set,  and let the chef exercise judgement (or conform to
standards) with regard to the order that the toppings are added.

This is pretty far afield of database theory.  However,  participants in the
newsgroup expend a great deal of effort discussing whether list processing
systems like Lisp are suitable for representing sets,  and also whether set
processing systems like SQL are suitable for representing lists  (or trees,
by extension).

It's clear that a set can be stored in a list,  by simply allowing order in
the list to be an arbitrary and capricious feature added to the
representation.  It's likewise clear that a list can be stored in a set of
tuples,  simply be adding an attribute that determines order in the list.
Nevertheless,  the boundless energy of the participants continues to raise
this issue, from time to time.

If the predicate is something like "The kitchen is currently cooking <order>
pizzas with <toppings>", where <order> is a count.  (i.e. someone has
ordered just a crust--my son would, and someone else has ordered a proper
pizza.)  I could no doubt invent other possible interpretations.  My
question is, what predicate did you intend me to use when answering your
question?

Roy

You are presenting us with some data,  and then asking what it means.  Why
not tell us what it means,  and then maybe one if can figure out if the
representation is a useful one.

Also,  how does the example you gave us differ from:

Lastly,  I regard tomato suace and cheese as an essential part of the pizza,
and not a "topping" as such.  I realize that this is quite subjective.  But
I claim that, if you order a pizza with no toppings from Domino's,  that
this is what you will get:  crust, tomato sauce, and cheese.

I guess I could smell it from several newsgroups away, David, 'cause I
love pizza (discussions), especially those with the cheese on the
bottom like they make in Chicago, and then there are those colorful
cars that also tickle my fancy.

I'll go back now to designing keyword attributes and other weak
properties as multivalues, modeling data in Non-First-Normal Form
(given that First Normal Form refers to the form formerly known as
1NF).  cheers!.  --dawn

Incidentally, Edsger Dijkstra recommended practising computing science
in a second language.

Quoth paul c:

It would be in the "KEYS" relvar, but not in the "KEYATTRIBUTES" relvar,
I think... though it makes little sense to discuss this without
specifying the design completely.

Neater, definitely. (I'm not sure what you mean by "exact".) But wasn't
your argument that RVAs are messy because of (perceived) possibility of
inconsistency? Anyway, the structural design is neater, but the
constraint to ensure that the key attributes are in fact attributes in
the key's relvar, might be more complicated.

...

Sorry, let me take that back, I think I should have said intersection,
not cartesian product.

Oops.  That was silly.  I should have said cartesian product.

I was treating mv-relations as formally different from sv-relations.
D&D's definitions only apply to sv-relations.

The interpretation I() maps an mv-relation to an sv-relation.  For
each mv-tuple, we take the cartesian product of the sets of values for
each attribute to yield a set of corresponding sv-tuples.

Definition:  Let r' = I(r).  Then

   attribs(r') = attribs(r)
   tuples(r') =
       { t' |  exists t in r and
               for all a in attribs(r), t'(a) is an element of t(a)
       }

If r1,r2 are sv-relations then the attributes map to single values
which are sets, and then I agree that r1 |x| r2 would be empty.

If r1,r2 are mv-relations then the attributes map to multiple values
which are again represented using sets.  However mv-relations have
different semantics, a different join operator and r1 |x| r2 is not
empty.

On another note, I've been thinking of an interesting partial ordering
on mv-tuples that is associated with information redundancy :

   t1 <= t2  if
       attribs(t1) is a subset of attribs(t2)  and
       for each attrib a in attribs(t1),  t1(a) is a subset of t2(a)

t1 <= t2 means that t1 is (information) redundant with respect to t2.

It seems to me that missing values should be treated merely as fewer
propositions in the context of a 2vl.

This provides a clue for how to define intersection, union and
difference operators on mv-relations.

I'm thinking of the following...

Intersection
--------------

Let t1,t2 be mv-tuples.  Then t = (t1 intersect t2) is defined as
follows

   attribs(t) = (attribs(t1) intersect attribs(t2))
   for each a in attribs(t),  t(a) = ( t1(a) intersect t2(a) )

This can be regarded as the largest amount of information consistent
with

   t1 => (t1 intersect t2)   and
   t2 => (t1 intersect t2)

Now an mv-relation is a union of mv-tuples, and evidently the union of
all the information expressed by the mv-tuples.  By the distributive
laws (on union and intersection) it makes sense to define

   r1 intersect r2 = { t1 intersect t2 | t1 in r1 and t2 in r2 }

I think it should be possible to prove

   I(r1 intersect r2) = I(r1) intersect I(r2).

Union
-----

Let t1,t2 be mv-tuples. (t1 union t2) could be defined as the smallest
amount of information consistent with

   (t1 union t2) => t1  and
   (t1 union t2) => t2

However that won't in general be reducible to a single tuple, so the
analogy with the intersection case breaks down.

Definition:  Let attribs(t) be a subset of X.  Let t' = extend(t,X)
represent the extension of t onto X by defining

for all a in attribs(t),  t'(a) = t(a)
for all a in  X\attribs(t),  t'(a) = {}

Note that extending a tuple with empty sets doesn't change the
information content.  More formally

   extend(t,X) <=> t

Definition:  r = r1 union r2 satisfies

   attribs(r) = attribs(r1) union attribs(r2)
   tuples(r) =
       { extend(t1,attribs(r)) | t1 in r1 } union
       { extend(t2,attribs(r)) | t2 in r2 }

I think it should be possible to prove

   I(r1 union r2) = I(r1) union I(r2).

Note the nice feature that this union operator is defined on all mv-
relations - ie r1,r2 don't need to be "union compatible".

Difference
----------

The analogy with intersection doesn't carry over for a simple
definition of r1\r2 in terms of t1\t2.  I'm not surprised that it gets
more complex here because negation in the presence of missing
information is tricky!  I think it should relate back to the idea of
"negation as failure&q