Marshall Spight wrote:
Yes! This point is crucial and why (dawn one should desperately
avoid the conceptual squashing of sets, multisets, orderings, peruvian
monkey fish, etc., into a single catchall "list" construct.

It isn't just about the pros and cons of passing cognitive load onto
the user, its about allowing the system to be capable of maintaining
integrity and making formally correct decisions. As far as I can see,
the domain expert that Marshall specifies above can and *should be* the
system itself, as defined to it at design time when the domain was
specified.

JOG wrote:
Would that the domain expert were the system -- it would be so less
likely to change its mind. But, yes, I agree that when you store sets
or monkey fish in a list, you are bound to encounter some issues where
it would be better for the system to have the information that this is,
indeed, a set or a monkey fish and not a list.

And redesigned in subsequent projects as requirements change. So, yes,
I agree with you in theory, but I'm hedging related to practice.
--dawn

"JOG" <jog (AT) cs (DOT) nott.ac.uk> wrote:

Because:

Look at it the one way, first. If mushroom, onion needed to be
ordered, if they preferred to spread the onion over the mushroom as a
preferred practice, if one had to precede the other or else the
entity, this event, would simply be wrong, then obviously that order
must be accounted. But that's to state the obvious. It's perhaps a
contentious point, and this may be which follows. The concern was
whether or not this ought to be so constrained, whether or not it was
important to record the fact that onion followed mushroom, or if it
really didn't matter at all (which fact might also need to be stored,
rather than some other or general default). Once you decide, if you
have multiple attributes, uniquely named by precedence and role,
that's one thing. If you make these dependent in a separate table on
some named pizza recipe, then the sort would matter, as well, if you
decided that the order could not be ignored. And so on. That would
depend on the specific scheme that you use.

dawn wrote:
And there you'll continue to have the advantage over me. Theory and a
sparkling ivory tower is all I got. I tried to offload them on ebay a
while back but no takers. J.

dawn wrote:
I agree that the magnitude of the problem probably isn't huge.
But I can't help but wonder whether this is one of those
problems when, once it's solved, even those people who
were saying it wasn't a big deal will decided they could
never go back.

As far as I know, there has never been a general purpose
language with full support for the relational algebra. Once
someone has that, what might their life be like?


Yay me! :-)


And for the most part, what else are they going to use?
Can you think of a general purpose language that has
support for relations? Can you think of a general purpose
language that *doesn't* have support for lists or arrays
or some kind of native ordered collection?

There are a few languages floating around with some
higher level collections. Python, Perl, Icon. They might
have bit sets or char sets, or they might have maps.
But once you have grokked relations, the idea of going
back to even those collections is stultifying.


Right, and this is probably not very hard. But it would be even less
hard if the system just did it for you.


I can't tell you how thrilled I am to be called "ivory tower." I have
only the lousy bachelor's degree, and I work with Ph.Ds all the
time. Curse them and their knowing-a-lot-more-than-me brains!
Ha!


Yeah, well, doesn't that sound just about exactly right?

But again, once you grok relations. Once you've done
a five way hub-and-spoke join with two aggregates,
a case statement, and a rollup, you'll never go back.
In terms of bang-for-the-buck, nothing can compete
with relational operators. Natural Join is a natural
high baby.


Marshall

Brian Selzer wrote:
[snip]
When I have arbitrary sets of numbers say and I want to use those sets
in some form of manipulation I can, of course, quite happily state them
mathematically something of the nature:

x = {1, 3, 8}, y = {2, 4, 7}, z = {x, y}, etc.

This is simple assignment, and gives my sets a label, or identity if
you will, so that I may go ahead and use these descriptions in future
manipulations without referring to the sets extensionally.

Surely this is identity (an artifice of course, but valuable here
nonetheless) and set theory working in perfect harmony at the heart of
mathematics?

Now, this methodology clearly violates the information
principle-centric view of using attributes only to refer to things. Yet
it is exactly the sort of thing I want to do with the data I work with
(genetic and other bioinformatics data), in spite of the cognitive
dissonance it seems to be causing me (yes,trying to reconcile what
currently seem to be equally arguable but opposing standpoints is
hurting my head ).

Perhaps there is an obvious hole in this logic, which I'm currently
missing due to some sort of antiprocess on my part.

JOG wrote:
I think that sets and multisets can both be handled well with
relations, as can orderings if necessary. But I long for
the day when mathematicians will develop a unified model
that will handle both lists and peruvian monkey fish.

Tasty, tasty peruvian monkey fish. Mmmmmm.


Marshall

JOG wrote:
If all you're doing when you say "x = {1, 3, 8}" is declaring
x as an alias for the set, then x has no identity; it is just a
name for the extensional value. This is no different than
if you said "pi = 3.14159". I would call x a "constant",
although it is common parlance to call it a variable,
even if it cannot in any way vary. :-( The = sign would
not properly be called assignement; rather, it would
be called declaration.

If, on the other hand, x is a variable, and supports destructive
update operators, of whatever kind (reassignment, insert,
delete, etc.) then x indeed has identity.


Certainly. Note that the relational algebra has no destructive
update. Insert, delete, etc., are not algebraic operators
but imperative ones. The imperative operators can exist
side-by-side in harmony with the algebraic ones, just like
we can embed the algebra of the integers inside an
imperative language.

However it has occasionally been claimed that individual
rows in a relation have identity. That is, a relation variable
is a set of other variables. This is OOP; it is not relational.
Not that there's anything wrong with that. :-)


HTH


Marshall

"Marshall Spight" <marshall.spight (AT) gmail (DOT) com> wrote

I really didn't think I needed to state the obvious. The key is the name of
a person. For the purpose of this discussion it doesn't matter whether it's
modeled as a single attribute or two. Only the person's name and marital
status belong to the universe of discourse. Here's an attempt at precision
on the constraint: no update to the database shall be permitted that causes
the marital status of a person to change from single to divorced.

Nice dodge. Am I then to assume that you acknowledge the point?

My newsreader is Outlook Express. I wasn't attempting to reverse
attributions. Is that how it's coming out on your reader? It isn't on
mine.

Yes, I did. That's not how I'm using the term identity. I'm not referring
to pointer arithmetic, but rather what makes something unique within a given
context. In the context of a roll of quarters, each quarter has identity
with respect to all other quarters in the same roll, perhaps determined by
the distance from one end of the roll. In the context of a single database
state, each proposition has identity with respect to all other propositions
in that database state. For a relational database, the name of the
containing relation combined with a value for one of its candidate keys is
sufficient to represent that identity, but only for a single database state.
If the database definition includes a temporal constraint, then it must be
possible to correlate values from the current database state with values in
the proposed database state. This means that the identity of a proposition
must remain constant during an update, which is not possible if all
candidate keys can change.

"Marshall Spight" <marshall.spight (AT) gmail (DOT) com> wrote