>>> My peculiar view doesn't require me to ask "what is the predicate of
>>> such and such a relation". This will sound ridiculous to most people
>>> I think because one would ask "well, what good is a database whose
>>> predicates we don't know?". OTOH, one aspect that for me defines a
>>> relational engine is precisely that it must not circumscribe even in
>>> the most indirect of ways what predicate a particular relation has,
>>> its whole value is in being to manipulate relations without knowing
>>> that - otherwise it would be an application!
>>
>>
>> Well, in that regard, it's already done -- in DEE ad DUM, no? And I
>> think it's correct - but somewhat confusing - if you want other names
>> for those relation values.

> > > (For a few years, I had trouble remembering which of DEE and DUM had a > tuple and which didn't. Now whenever I forget, I just type the table > names into google and up pops dbdebunk. I'm still not sure whether > relations called TRUE and FALSE would cause confusion with the REAL TRUE > and FALSE.)> >

>>
>> It almost seems as though you want to declare an analogue for DUM,
>> syntax-check some expressions, and add attributes to your relation
>> with the confidence that your expressions are still correct.
>>

> > Not exactly how I thought of it, but I think that's fair, after all, one > can add attributes, subject to one's external conception, to relation > definitions that don't have empty headings, in fact not that the > observation is of any use, that seems to be what happens when one > defines a relation with one attribute.

I suggest an empty candidate key in a relation with any number of
attributes is closer.
Received on Thu Jun 29 2006 - 16:41:55 CDT