A
Date: Sun, 10 Jul 2005 08:43:34 GMT
Message-ID: <Wc5Ae.141446$fP5.7357492_at_phobos.telenet-ops.be>
Jon Heggland wrote:
> In article <7DCze.140558$Jn.7313539_at_phobos.telenet-ops.be>,
> jan.hidders_at_REMOVETHIS.pandora.be says...
>
>>In some sense you might say >>that is is "too large" to be a set. The collection of all relations has >>the same problem.
>
> I'm skeptical to this, but if it is too difficult to explain (or to give
> an example of a problem), I'll let it be for the moment.
I'll give another hint. Since unary relations are similar to sets you can get Cantor's paradox.
> In that case, I redefine my unnest_string so that IN is a RELATION { K :
> INTEGER, A : STRING }, OUT is a RELATION { K : INTEGER, B : CHARACTER },
> and the attribute name argument is not needed.
>
> Now, my operator is perfectly fine, isn't it? But has STRING now become
> non-atomic?
I think the definition is quite clear on that.
>>>>>Should I be forbidden from treating "relation" as a (generic) domain >>>>>when defining this operator? Why? >>>> >>>>Because by definition it isn't, and redefining the notion of domain such >>>>that it is, is not that easy without either running into paradoxes or >>>>getting a notion which it is almost impossible to reason about. >>> >>>Can you give me any examples of trouble arising from this? And an >>>explanation why the relational operators do not run into paradoxes? Or >>>do they? >> >>They are not functions defined over domains.
>
> That much is obvious, given your definitions above. But wasn't your
> point that this leads to problems and paradoxes?
No, redefining the notion of domain would.
> Is there a difference
> between my previous unnest_string and the relational operators? Don't
> the relational operators treat "relation" like a domain?
That depends on how you define them. If you view the selection with a certain predicate as a single operation then the answer is 'no'. If you define or each relation type a different select then the answer is 'yes'.
>>Note that my remark that >>started this was that the nest operation cannot be defined as a function >>*over* *domains*. If you drop the latter restriction you can define them >>without a problem.
>
> Without a problem? Except the problems of making string non-atomic and
> leading to Russelian paradoxes, or without *any* problem?
I wouldn't call non-atomicity a problem in the sense that paradoxes are a problem. You may or you may not want to be in 1NF, but a formal system with contradictions is useless.
- Jan Hidders