Re: Operationalize orthogonality

Pickie wrote:
> ...
> Your statement about order, viz. that "...you could choose to express
> it with a relation" is just about the same as the one in Tony's with
> which I have trouble. Is this use of the word "relation" the same as
> that in the relational model; that is, the thing Date calls a relvar?
> If it is, I have the same problem understanding just how this can be
> done.
> ...

Personally, I'm content to leave ordering to what I think of as domain code that a dbms uses (some people might object and say I'm really talking about data type implementation). I guess I'm talking about a domain or type that supports at least one "less than" or "greater than" operator. I would keep relvars out of it unless I actually wanted to use relational operators to implement a data type (and that would assume I had a compiler for my dbms that was pretty sophisticated, being able to manipulate set intensions and so forth). I must note that I'm a bit of a troglodyte when it comes to understanding all of the type theory that Date (and Darwen) propose.

But if one wanted to use relational ops to determine some order that couldn't be determined by a particular machine's bit representation, say lexigraphic order (typical dictionary order) then one could define a relation with two attributes, one having ascending or descending ordering values according to the machine's bit organization and another that had the values in one's chosen alphabet, and assign it to a relvar, eg.:

Order Value
----- -----

1     a
1     A
2     b
2     B

but this wouldn't necessarily be portable among different machines, so if one's English lexicographic alphabet had 52 symbols one could make a much bigger relvar and assuming an equality operator was built-in (if not then two relvars would be needed, if so then I imagine it would obey D&D's rm prescription #8 or some other coherent definition) that might look like this:

Value LessThanValue
----- -------------

z     a
z     A
z     b
...
b     a
b     A

Both would be tedious solutions and no matter how smart the compiler they seem like a waste of energy to me. My point was actually two points: 1) an rm implementation doesn't seem to need order for itself, just some applications seem to need it and 2) whatever code implements ordering for applications ought to give results as if one of those tedious implementations were used.

I'm by no means saying categorically that there is no other relational alternative to the relvars above, just that they are ones that occur to me, in order (ha, ha) to back up what I said before. Also, that I'm responding in context only - I know lots of languages have various folding operators or functions to shortcut lexigraphic ordering.

p

ps: I certainly wouldn't be offended if somebody attaches more importance to bit strings than I do, when I used to write machine language they were very important to me and sometimes with C they still are to me. I knew one cross-platform product where the Unix and Windows machines all used EBCDIC internally just because the reference implementation had been written for MVS. They went to a lot of trouble going back and forth from that to ASCII, sometimes several times for one query because certain components had both internal and external interfaces. (Thankfully I'm out of that nonsense now but when it comes to bits I am newly bugged about how Microsoft and Intel seem to prevent the address segmentation feature for dbms impl'ns. At one time this feature was purely for Intel business reasons, not for users' benefit. Now that much bigger memories are generally available they seem not to have realized how it could be used for a completely different reason which would benefit users.) Received on Thu Jun 08 2006 - 04:48:21 CEST