Re: So what's null then if it's not nothing?

paul c wrote:
> vc wrote:
> > paul c wrote:
> >
> >>vc wrote:
> >
> > [...]
> >
> >>>I am not sure, as I said before, that the data type is so terribly
> >>>important for storing data. TTM does not provide any rationale for the
> >>>must-be-supported data type.
> >>>...
> >
> > [...]
> >
> >>For one thing, the only way, without going outside the relational
> >>operators (eg. without counting returned 'rows' or checking 'return
> >>codes' or 'status codes') to find out if a relation has any true
> >>propositions .
> >
> >
> > I am not sure what you mean by the above. Could you please elaborate ?
>
> R{} = TRUE.
I do not understand the notation. Is it an empty relation, a synonym for TABLE_DUM ?

> (In TTM, there is an operator called 'IS_EMPTY' which the
> book doesn't exactly define, at least when I search through it, but Hugh
> Darwen was kind enough to confirm when I asked about it that IS_EMPTY(R)
> is equivalent to R{} being equal to TABLE_DUM

It make sense because TABLE_DUM is *defined* as {}. I still do not undertsand what R{} means.

>, and the opposite would be
> the case for TABLE_DEE which TTM sees as just a value equivalent to TRUE.)

So they stipulate that TABLE_DEE which is equal to {{}} (a set containing as its single element an empty set), should encode TRUE. A bit arbitrary, but no worse or different from say using the integer 1 for the same purpose.

All that is interesting, but how does it explains the need to store Booleans in the database or to have a separate data type for them ?

>
> >
> >
> >>is to support a value such as 'TRUE'
> >>I believe TTM
> >>effectively considers TRUE to be equivalent to a projection over zero
> >>columns of a non-empty relation. Basically, it seems to be TTM's way of
> >>being able to give an answer within the algebra that supports FOL's
> >>existential quantifier, ie. the result of the question is in fact a
> >>relation.
> >
> >
> > Could you rephrase that and provide an example ? Also, when is the
> > result of a question ( a query ?) not a relation ?
>
> When I don't have a TRUE and FALSE domain for relation values and I ask
> the question are there any rows in R, I must, for example, use some
> implementation 'count' function whose result would likely not be a
> relation

Why not ? There is no way, even in SQL, for the aggregate function result to be anything other than a row attribute. E.g. select count(*) as cnt from t1 returns one row with one attribute 'cnt'.

TTM's 'SUMMARIZE' does approximately the same.

>or I could 'SELECT' all columns 'FROM' some row of R and then
> write procedural code that checks some SQL return code and then prints
> or displays the literal 'TRUE'. By contrast, if I simply 'SELECT *no
> columns* from R', the result is 'TRUE' and it was the relational
> operators that gave the answer, not code in some host language.

There is no need to do what you've described even in SQL:

select * from t1 where (select count(*) from t2) = 0

In TTM, one'd apparently use the IS_EMPTY operator.

I still do no see much need for explicit Booleans.

>
> To some, this may seem quite trivial, but I'm interested in what is
> intrinsic to the RM and what isn't. Mainly because I imagine a day when
> some relational engine is wired directly to a display without a lot of
> mediating code between the user and the db.
>
> (I'll stop now because the more I write about this, the greater danger
> all the words will confuse me.)
>
> p
Received on Mon Dec 05 2005 - 14:44:06 CST