Re: relations aren't types?

Jonathan Leffler wrote:

> Marshall Spight wrote:
>
>> "Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote:
>>
>>> My understanding is that in the scope of relational databases,
>>> atomicity is defined in terms of whether the relational operators
>>> can "see" the value or not without the help of "non-relational",
>>> or scalar operators.
>>
>>
>> Interesting. I wonder if that's definition Bob is using, thus causing
>> our disconnect about atomicity. Where did you get this definition,
>> may I ask?
>
>
> Obviously, I can't answer for Lauri, but...
>
> It strikes me as being a good statement of an atomic type, and one
> that can be derived from the writings of Date (and Darwen). I've not
> seen it in quite that form before - which might mean Lauri has found a
> new way of stating what atomicity means, or it might mean I've not
> read the relevant book or paper.

Yes, it is perhaps my naive way of stating what I have understood from their writings. I think it is, if not 100% correct, at least some kind of rule of thumb and a guide for making desing decisions in practice. How much do you want to operate on the value with relational operators? Or do you want to, or need to, use scalar operators?

> One point that has often bugged me is the assumption that arithmetic
> is part of the relational model. It's usually expressed in terms of
> 'but of course a real DBMS would provide an arithmetic capability'.
> Binary infix operators such as '+' and '||' (for addition and string
> concatenation respectively) are not relational; they are
> non-relational scalar operators defined on some types. In the case of
> '+', it is polymorphic in that if you distinguish between integers and
> floating point numbers, then there are usually at least two versions
> of the operator - one for two integer values and one for two floating
> point values, plus usually a conversion operator that converts an
> integer to a floating point value when the types of the operands
> differ. Even equality is a non-relational operator; it takes two
> values (nominally of the same type, or two values coerced to the same
> type) and returns a boolean, and the relational model uses that
> boolean result. One (probably obscure and not necessarily valuable)
> way of looking at it is that the only type that the model must support
> is the boolean type -- all the others are optional.

TTM (The Third Manifesto, 2ed) states on page 103:

"Scalar types can be either user- or system-defined ("builtin"). We require that at least one builtin scalar type be supported, namely the -absolutely fundamental! - type *truth value* (referred to in Tutorial D as BOOLEAN); for definiteness, we assume that support for that type includes (though is not limited to) the operators NOT, AND, and OR and the literals TRUE and FALSE".

So your observation about boolean is in line with TTM, and contrary to what you state, not obscure or unvaluable at all!

regards,
Lauri Pietarinen Received on Wed Dec 31 2003 - 07:59:35 CET