Re: Normalisation

In article <42cc2cf1$0$2892$ed2e19e4_at_ptn-nntp-reader04.plus.net>, paul_at_test.com says...
> The inner structure of sets or strings is hidden from the relational
> operators, so why make an exception for a relation-valued domain?

I don't, really. I should have been clearer about this: I don't support nested relational algebra, or "mixing of levels". The inner structure of a relational-valued attribute should be no more and no less hidden from relational operators than that of a set-valued or string-valued attribute. But if we allow sets, we should allow relations.

I think Date's GROUP (nest) operator is very hard to argue against---it cannot be said to violate encapsulation in any way. It is just the observation that with the operator

EXTEND relation ADD expression AS attrname

, "expression" can be an expression of any type. The UNGROUP (unnest) is not quite as simple, so I am more skeptical to it, but disallowing it does not impact the discussion at hand.

> If you think about the mapping from predicate logic to the relational
> model, a "nested" relation in the way you propose corresponds to
> second-order logic.
>
> First order logic basically means that the arguments to your
> propositions can't themselves be propositions.
>
> But this is the crucial bit I think: they can be values (strings) that
> can be interpreted as propositions by some other structure.

Then the crucial bit is not whether relation-valued attributes can occur, but whether they are interpreted as (sets of) propositions by the "classic" relational operators. And this is in fact the difference between Date's approach and the NFNF approach, I think.

> For example consider the statement:
>
> "Fred has employee_id 123 and the following set of
> statements are true: {'Fred has phone number 2345',
> 'Fred has phone number 3456' }"
>
> from the nested viewpoint, the relational part of the DBMS natively
> understands the second-order reference to the propositions referred to
> inside the outer proposition.

This is the NFNF approach, I presume.

> from the atomic viewpoint, the information about the phone numbers is
> just a meaningless domain value to the relational part of the DBMS - it
> needs the type engine to make sense of it.

This is Date's approach.

I think we agree; the only point of disagreement would be whether the UNGROUP operator "understands" the propositions it is ungrouping.

I'd say it doesn't (it doesn't *have to*, at least). You could define an unnesting operator that works on sets or strings---which the "relational part of the DBMS" does *not* understand---that would be isomorph to UNGROUP. Therefore, "understanding" is not required for UNGROUP, and the relational part of the DBMS can just ignore it.

-- 
Jon