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

vc wrote:
> paul c wrote:
>

>>vc wrote:
>>
>>>paul c wrote:
>>>
>>>
>>>>vc wrote:
>>> .........
>>>I am not sure what you mean by the above.  Could you please elaborate ?
>>
>>R{} = TRUE.

'R' stands for some relation or more exactly in TTM, a variable that has the value of a that relation. The braces '{' and '}' are TTM notation for projection. In this case, no attribute names are specified, so the projection is over the empty set of attributes. By TTM's definition, all relation headings contain at least the empty set of attributes.

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

Given the number of blunders I've made over TTM, I should be the last person to explain this. I tried to explain R{} above. As for TABLE_DUM, I'd say it can stand for *any* relation that has had all of its attributes projected away (TTM also defines a <REMOVE> operator that is complementary) and which is empty (eg. empty before the projection).   TABLE_DUM has no columns and no rows, which is equivalent to FALSE and TABLE_DEE also has no columns and exactly one row which is equivalent to TRUE. The value of table (if I may use that word here) EMP might be :

EMP#
1
2

whereas trying to write out the extension of DEE or DUM is a little harder without graphics, but here's my attempt at DEE

<empty set>
TRUE What I'm doing here is pretty crude and something of a distortion, I believe, of TTM's intent because plenty is unsaid, for example, the fact that TTM prohibits 'row' ('tuple-level') operators. So without better notation, and maybe not even then, I must keep the above attempts at writing down relation values in my head and think of them as extension values that are indivisible as far as headings or rows are concerned. That's the best I can do, but I know there are people on this list who have a firmer grasp of TTM than I do and probably better ways of expressing it.

>

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

Again, the matched braces in TTM just signify an operation. One must put a relvar name in front of them, or use a type generator before they are 'equal' to anything. Remember I'm not the gospel here, somebody with better knowledge and writing skill will I hope write it better.

>
>
> 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 ?
>

As far as TTM is concerned, I believe it doesn't claim any "need to store Booleans in the database". But I believe it does claim even if not a lot of rationale is given in TTM itself, that they are a logical upshot of the basic RM definition, namely that a heading is a set.

>

>>>
>>>>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

In a way, if we try to figure out semantics from syntax, maybe you've got me there. But I'd say that if select count(*) is a relation, it is in fact a different relation than t1 (if it is even a relation, which I'm not sure of - I thought it is a non-relation value, maybe the SQL experts know otherwise). You could say that t1{} is also a different relation from t1, but I'd say that it muddies the waters less than the sql result, because for one thing it is definitely a relation and for another I can see by looking at it that it concerns t1. I'm probably muddying the waters myself. Let me try again - I say that t1{} is a relation, so we have got a relational result, whereas select count(*), whatever it is, is not a relation, so we have not got a relational result. I'll give up at this point!

>
> TTM's 'SUMMARIZE' does approximately the same.

I admit I haven't paid much attention to SUMMARIZE as I'm still grappling with more basic stuff

>
>

>>

Even if they weren't a logical consequence of the RM's definition, wouldn't you still need them in any language such as Tutorial D that aims to be 'computationally complete', just like you do in practically any other non-assembly language, if only to know if a comparison is true or false?

thanks,
p Received on Mon Dec 05 2005 - 22:55:02 CET