Re: Stored fields ordered left to right

"Jonathan Leffler" <jleffler_at_earthlink.net> wrote in message news:h3sHb.8655$lo3.5808_at_newsread2.news.pas.earthlink.net... <big snip>
> One of the documented differences between mathematical relations and
> relations used in database theory is precisely this one - that the
> elements in a tuple of a mathematical relation are ordered (usually
> ordered pairs, in fact) but database theory uses unordered tuples,

Be careful not to equate Codd's database theory with all database theory. I work with alternative database theories. The primary one that I work with has, in the logical model, the concept of ordered tuples, aka mathematica relations. In fact, they are relations which are mathematical functions as well. It appears to me that relational database theory works with relations that are not, by definition, mathematical relations while at least one database theory that actually uses mathematical relations is often accused by relational theorists of not being relational. Am I the only one intrigued by this?

> where each element logically consists of the combination attribute
> name, attribute type and attribute value. Of course, in a system
> without inheritance to complicate matters, the attribute type
> associated with a given attribute name is the same for all tuples in
> the relation (but the converse is not true). The difference between
> ordered mathematical relations and the unordered database equivalent
> is clearly stated in Codd's original (1970) paper, incidentally:
>
> Accordingly, we propose that users deal, not with relations
> that are domain-ordered, but with relationships which are
> their domain-unordered counterparts.
>
> [Note the implied distinction between what users see and what the
> system manages, too.]
>
> Many practical systems store each record (physical analogue of a
> tuple) with the fields (the physical analogue of an attribute) stored
> in the same order, which makes it easier to locate a given field
> within a given record. And many systems make life still easier by
> storing the data for a given field in a constant width, so it is
> trivially possible to pre-calculate the offset into the record for a
> given attribute value.
>
> To get back to the question - if you change the premises on which your
> version of relational theory is based to state that your tuples are
> indeed ordered, then of course Date's statements no longer apply. The
> theory about which he is making statements states that tuples are
> unordered. Both are valid sets of premises, but they are different
> sets of premises, and statements made about one are not valid for the
> other.

I agree, so I'm trying to get some common language. Taking mathematical vocabulary and then changing it (and in this particular case changing relations to require that they be unordered when mathematically they are ordered !!) is more than likely to cause problems when discussing database theories (as I have seen time and again, which is why I'm trying to align my language with that of relational theorists EXCEPT THAT I AM NOT WILLING TO SACRIFICE ACCURATE MATHEMATICS, if we can avoid that)

>
> As to which set of premises is better - that is a separate discussion.
> I strongly suspect there are a rather large number of issues that
> have to be resolved when you use ordered tuples rather than unordered
> tuples. Most notably, A JOIN B is not the same a B JOIN A under the
> ordered scheme - with consequences that need to be considered very
> carefully.

Yes, you are absolutely right. In fact, the model I work with is more of a di-graph of data and instead of joins, it uses data trees (much like the web). This is accomplished with functions as well. Instead of using two different concepts -- sets/relations combined with operators, the model I work with uses functions in both cases. All work with computers can be seen in terms of functions that map one "object" to another, in fact. Both functions and objects can be stored in memory, disk or wherever. [sorry, I'm digressing]

>
> And, reverting to the final question again - no, Date's comments are
> neither irrelevant nor wrong in the system about which the comments
> were made.
>

I can see that he is not using the mathematical term "relation" but a definition that has evolved from the work of Codd and has redefined relation so that it means something different in database theory. Don't you hate it when that happens!!!??? Now I need to have a term that stands for database theory that is based on the mathematical definition of relation and distinguish that from what is currently called relational database theory that does not match the mathematical definition of relation. UGH! Please help. --dawn

> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com
> Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
>
Received on Sun Dec 28 2003 - 04:41:57 CET