Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Normalisation

Re: Normalisation

From: Jon Heggland <>
Date: Sat, 9 Jul 2005 14:04:03 +0200
Message-ID: <>

In article <7DCze.140558$>, 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.

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

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?

> >>>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? Is there a difference between my previous unnest_string and the relational operators? Don't the relational operators treat "relation" like a domain?

> 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 must admit I have lost track of your argument.

Received on Sat Jul 09 2005 - 07:04:03 CDT

Original text of this message