mAsterdam wrote:
In MV, functions (sets) are like files with a primary key. They permit
list values for attributes as well as single values. All attributes
are ordered and the values within them are ordered and the sub-values
within them are ordered. It looks very much like a compact version of
XML with "markers" (specific ascii codes) separating records,
attributes, values, sub-values instead of metadata strewn throughout.
The other difference is that you don't go more than a couple of levels
deep in the nesting in MV compared to the possibilities for nesting in
XML. Cache' (MUMPS) has more nesting. I have never encountered a need
for it and it seems to help with conceptual simplicity not to have more
nesting available within a single file.

Yes, that is precisely the case with MV, which I think of conceptually
much like an XML database without the performance and other issues. If
the toolsets were a bit more modern (I'm still trying to figure out
what such improvements might be needed), it would much more obviously
meet the needs of today's s/w development than other tools, I think.
Cheers! --dawn

David Cressey wrote:
Yeah, ehrm well... Is this issue closed? Is there a nice solution?

In e.g. XML the basic assumption is that order has meaning, in SQL
it is that order has no meaning. Historically (XML coming from
a document heritage, SQL from experiments with relational
products) this makes sense, but I would prefer it if one could
choose wether order is meaningful/worth preserving/relevant or
not - instead of being pushed into one way of thinking or another
because of the background of the product at hand.

On 26 Feb 2006 08:19:50 -0800, "Marshall Spight"
<marshall.spight (AT) gmail (DOT) com> wrote:

It's not quite that simple. As David pointed out, a "mushroom and
onion pizza" is not necessarily different than an "onion and mushroom
pizza". But the ordering of the bits in an integer is significant,
whereas the ordering of ingredients for a pizza isn't (although I'd
definitely want to make the crust before I put the tomato sauce on
it<g>).

One of the fundamental things in RM is that the Cartesian join of two
relations is commutative. Think about the implications of this when
trying to decide what requirements a MV key would have to fulfill.

In Joe Celko's book "SQL for Smarties", there is an example of a
schema for an airline scheduling system which he uses to illustrate
DKNF (starts at the bottom of p. 35). How would someone model this in
a MV database? In this and similar threads here, when people talk
about the virtues of MV vs. RM, there is a perceived (by me) lack of
any real-world examples on the MV side that go beyond trivial things
such as stuffing lists of people's phone numbers and e-mail addresses
into one ... (hm, I almost said "column" ... I guess "field" would be
more appropriate here). It would be nice to see an example of
something that would also scale comfortably beyond twenty rows or so.

--
Bob Hairgrove
NoSpamPlease (AT) Home (DOT) com

"Bob Hairgrove" <invalid (AT) bigfoot (DOT) com> wrote

Thank you.

There is a way to implement sets as bit strings, where the bit number
indicates which element of the universal set we are talking about and a
value means inclusion for a 1 and exclusion for a zero. This is basically
how Pascal implemented sets.

And, in this notation, a pizza with onion and mushroom has the same
representation as a pizza with mushroom and onion. So, if the original
order meant something, that information has been lost.

The way Pick (and I presume most of the MV family) represent lists is
inherently ordered. And, whenever I ask Dawn, or any of the other Pickies
who dorp in form time to time whether the order in a list conveys
information or not, the answer is always the same:
"the programmer knows what the data means".

The whole reason I got involved with databases, some twenty years ago, is to
have a more formal and explicit handle on what the data means. As Marshall
has pointed out, the semantics of the data are less than totally clear even
in the RDM. But it's considerably closer to self describing data than just
"ask the programmers".

On Sun, 26 Feb 2006 20:47:05 +0100, Bob Hairgrove
<invalid (AT) bigfoot (DOT) com> wrote:

.... i.e., twenty phone nos. per person...

--
Bob Hairgrove
NoSpamPlease (AT) Home (DOT) com

Bob Hairgrove wrote:
If it is we have a list of toppings.
If it isn't we have a set of toppings.

(David was sighing about some *very* long
winding threads about this).

If it is possible to define a generic macro (or as Date calls
it 'shorthand'), which expands/rewrites the relation with a MV key
into a set of relations with only single value keys, the
commutativity is not lost in the result.

I suspect that this is easier for set-keys than for list-keys.

Disclosure: The only things I know about MV databases is from what Dawn
and some (other?) pick adepts tend to write about it in c.d.t.

In the current discussion I read for 'MV Key' simply Multiple-valued
key: an identification consisting of an arbitrary number of values.

On Sun, 26 Feb 2006 20:43:46 GMT, "David Cressey"
<dcressey (AT) verizon (DOT) net> wrote:

This is a recipe for disaster, even in small-scale systems with a
lifetime of little more than a year or so. And we haven't even begun
to talk about security issues which is one of the main advantages of
using a good RDBMS.

I was involved with the Swiss census in the year 2000 writing stored
procedures for the main database. Although Switzerland is a relatively
small country compared to many, and the data didn't quite reach
teradata dimensions, we had over 100 tables IIRC, some with 10 to 20
million rows constantly being written to and read from by over 100
client PC operators simultaneously. The data went through several
stages, beginning with the data capture (mostly scanning paper forms
with some internet input), validation against prior household data
supplied by the communities, automatic processing (nightly batch jobs)
and manual processing (PC operators) until the final stage was
reached. Conceptually, there were at least four different schemata
involved, one of which was an entirely different database (and RDBMS)
whose data was transferred at night by batch jobs.

The programmers changed several times, even before the project was
finished. But the data is still being mined today, and I would hate to
think what would happen if some newbie application programmer were
allowed to change even one table, index or constraint. When I was
writing code for the batch processes, we had to use an API in order to
perform any DML at all. No one except for the team of DBA's had direct
access to any of the tables except for read-only access. ALL writes
were done through packages. And it was a good thing, believe me (even
though I had to beg for two months for an additional index before the
powers-that-be finally let me have it).

There are performance issues that MV databases probably cannot address
.... but I can't say for myself because I never worked with one. Take
clustering or partitioned tables: what do existing MV products have to
offer here? How do they implement user access rights? Roles?
Transactions? Backup and recovery? These are important issues. The
elegant thing about a good RDBMS is the fact that almost everything
can be implemented through system tables, i.e. RM.

--
Bob Hairgrove
NoSpamPlease (AT) Home (DOT) com

After takin a swig o' Arrakan spice grog, mAsterdam <mAsterdam (AT) vrijdag (DOT) org> belched out:
Is it *always* true, in XML, that order has meaning?

I don't think that's so at all...

There may exist cases where relative order can have meaning, but there
certainly exist cases where it is irrelevant.

For instance, RFC 3733 describes an XML schema for representing
contact information (the sort of information that the WHOIS service
reports for the various sorts of organizational contacts).

In that schema, order is normally expressly NOT significant in
indicating meaning.

If an XML request for creating a contact submits the <contact:name>
before or after the <contact:country>, that is entirely irrelevant as
far as any application is concerned.

More pointedly, the domain representation, in RFC 3731, can associate
multiple nameservers with a domain.

The canonical example is:
<domain:ns>
<domain:hostObj>ns1.example.com</domain:hostObj>
<domain:hostObj>ns2.example.com</domain:hostObj>
</domain:ns>

You might perceive an ordering, there; that ordering is not a real
one. That is, in formal terms, a set of nameservers. They are NOT
ordered, as far as the DNS service is concerned.

I'm sure you can find counterexamples; what that would establish is
not that "order always has meaning" in XML, but rather that
*sometimes* the order of elements in an XML document has meaning.

In effect, you don't have the result you wish you had; in order for
order to be preserved, when it important to do so, it is vital to
expressly declare that it needs preservation. XML doesn't help as it
does not provide any way to systemically indicate that need.
--
output = ("cbbrowne" "@" "gmail.com")
http://linuxdatabases.info/info/spreadsheets.html
In MDDT, no one can hear you scream...
But everybody can hear you say "whoops!"

You asked for an example, so here goes.

Consider the following set of propositions:

Jane Harper is married.
Jane Smith is single.

And a constraint that states that single people cannot become divorced.

Now, imagine that you're the database, and that you've been presented with
the following set of values to replace the above set:

Jane Harper is married.
Jane Smith is divorced.

Do you reject the update?

The problem is that there is no way for you to know that Jane Harper in the
first set is the same person in the second set. For example, in the
original set, Jane Harper's maiden name may be Smith, and Jane Smith may
have married Paul Harper. It is impossible for you to know because that
information was not provided. Because the update is set-based (and must be,
since either update taken individually would violate the primary key
constraint), and because the only key can change, it is not possible to
enforce the transition constraint because there isn't any mechanism to
correlate the propositions in the first set with the propositions in the
second.

Also see comments inline.

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

That's the point: a non-1NF attribute is not scalar, hence the ambiguity.

I disagree, and the example above bears me out. The knowledge represented
in a database is subject to the universe of discourse, and as such only
those attributes that belong to that universe are available to the database.
The example above shows that an entity represented in a proposition in one
database state may not necessarily be the same entity represented by a
proposition in a later database state even if the attribute values are
identical.

Yes they do. Is a roll of quarters worth 25 cents? No, and to elucidate
upon my previous point, the attributes that would uniquely identify each
individual quarter may not be relevant within the universe of discourse, but
that doesn't change the fact that there are still 40 quarters.

Have you tried writing a trigger to audit changes to rows in a table that
has only natural keys in SQL Server? Then you've seen the code that's
required to prevent multi-row updates that also affect a column that is part
of the key.

That is not always possible for natural keys, or even for composite keys.

The limitation is that you can't write code to reject these updates without
also rejecting perfectly valid updates, unless you do it in the application.

But that's because in this case you can detect a pattern between the values.
That is not always possible, and besides, it requires that the system probe
the right-hand side of the assignment in order to find some means to
correlate tuples. Not only is that not practical, as the example above
shows, it is not always possible.

Yes, I do want to be using set theory. The recognition of identity does not
alter the sound theoretical foundation that the Relational Model provides.
It strengthens it, or better yet, completes it.

Obviously.

No. It is not. Every proposition in the entire database must be distinct
from every other proposition and thus has identity with respect to the
database, regardless of whether those propositions are organized into
relations, some multi-valued construct or whatever else. An identity value
is a representation of a proposition's identity with respect to the entire
database. If the database is organized into relations, then an identity
attribute is clearly a candidate key on any relation that reveals it, but
conceptually, its value must be distinct throughout the database, not
limited to the scope of a single relation.

Christopher Browne wrote:
Cheers!

No. Coming from a document background, its *basic* assumption is
that order is significant.

At http://www.w3.org/TR/xpath Chapter 5, Data Model
says: "There is an ordering, document order, defined on all the nodes in
the document corresponding to the order in which the first character of
the XML representation of each node occurs in the XML representation of
the document after expansion of general entities. "


Of course. The application can rely on the parser to extract the
attributes based on the name. However, does the a change in the order
of contacts constitute a different document? AFAIK it does.

Or: Unless special care has been taken to take it out, order in a
document has meaning.

How do you declare that it needs preservation?
I was under the impression that query results were in document
order - but please correct me if I'm wrong.