| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Normalisation
Jon Heggland wrote:
> In article <Ezeze.139544$p21.7384199_at_phobos.telenet-ops.be>,
> jan.hidders_at_REMOVETHIS.pandora.be says...
>
>>>>Ah, but now you are using the domain or relations, right? There is a >>>>problem with that domain. It doesn't exist. The collection of all >>>>relations is a proper class, and not a set, but domains have to be sets. >>> >>>You'll have to educate me on the difference between "proper class" and >>>"domain", I'm afraid. The term "class" is used for so many slightly >>>different things. >> >>http://en.wikipedia.org/wiki/Class_(set_theory)
That's not so easy to explain, but I'll give a hint. Do you know about Russel's paradox? The contradiction that appears when you assume the existense of the set of all sets? A solution to that paradox is to accept that it is actually not a set, at least not in the sense that all the usual axioms of set theory apply to it. In some sense you might say that is is "too large" to be a set. The collection of all relations has the same problem. For more explanation you can probably ask any mathematician at your institute.
> Are you saying that the "domain of sets" is not a domain either?
Indeed.
> And that relation-valued and set-valued attributes are contradictions in
> terms, since relation and set are not domains?
No. For example the set of all sets of integers is a set and perfectly valid as a domain. The same for the set of relations that all belong to a certain relation type. Usually if you apply a strict typing regime there is no problem.
>>>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.
They are not functions defined over domains. 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.
![]() |
![]() |