Re: By The Dawn's Normal Light

From: Paul <paul_at_test.com>
Date: Fri, 22 Oct 2004 17:38:36 +0100
Message-ID: <41793790$0$48009$ed2e19e4_at_ptn-nntp-reader04.plus.net>


Alfredo Novoa wrote:

>> "A Relation is in first normal form if and only if none of the 
>> domains of its attributes permit compound or multivalued values 
>> *from the point of view of the relational engine*."

>
>> But from the point of view of the relational engine, a string is 
>> atomic: there is no way for the relational operators to break it
>> down into smaller pieces.

>
> But the relational engine has access to the type operators
>
> select * from a where b like 'Z%';
>
> select * from x where a[1][2] = 5;

It has access to them, but they are distinct from the core relational operators. It's as though it were:

SELECT * FROM a WHERE Like(b, 'Z%') = TRUE SELECT * FROM x WHERE f(a,1,2) = 5

where Like() and f() are some type operators.

Strictly speaking, I'd say we should also be able to push the equality operator into the type engine rather than the relational engine. Assuming WHERE clauses would support boolean values. For example, how does the relational engine know that 2/4 = 1/2 in the domains of rational numbers? It doesn't: it has to ask the type engine.

If you had relation-valued domains in the sense that some people suggest, the relational engine would be able to "get inside" values without needing the type operators.

>> So this way you don't really need a definition of compound or 
>> multi-valued, you just need to know that to the relational engine 
>> the values are "black boxes" or "atoms" that can't be subdivided in
>>  any way.

>
> This is not true, the type operators are a fundamental part of the
> "relational engine"

Certainly, but I'm suggesting there are clear and useful dividing lines between the work done by the "type engine" and the work done by the "relational engine".

At the very extreme end, you could have a database with only one type, and only one type operator: the test for equality. Maybe not practically useful, but worth thinking about.

> 1NF is superfluous, a relation is always in 1NF

Yes, by the standard definition of "relation" maybe. But the original message in this thread defined a relation as a table with no duplicate rows. And I guess implicitly a table was defined as a bag/multi-set of tuples of the same type.

I guess the 1NF requirement that values be atomic is really a requirement of the RDBMS itself rather than the table though.

Paul. Received on Fri Oct 22 2004 - 18:38:36 CEST

Original text of this message