Re: Proposal: 6NF

"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message news:1159692483.421785.264660_at_c28g2000cwb.googlegroups.com...
> Brian Selzer wrote:
>>
>> The argument JOG made focused only on recording information, not
>> retrieving
>> it. Why would anyone abandon a sound mechanism that can significantly
>> reduce the computing capacity required to answer a query?
>
> Because your argument is merely an assumption based on what some
> systems of today are capable of.
>
> Consider two possible models:
>
> 1. {i,a,b}
> 2. {i,a}, {i,b}
>
> In each relation the key is {i}. If the values i,a and b are of the
> same types in each case then there is no fundamental reason why they
> can't have the same physical representation. If the physical model is
> the same then there is no reason why one should perform significantly
> differently to the other.
>
>

There is indeed a fundamental reason. The database schemata above are not equivalent. 2 would also require a single foreign key constraint if only one of a or b is nullable, or mutual foreign keys if neither are nullable. If both a and b are nullable, then you would need:

3. {i}, {i, a}, {i, b}

and a pair of foreign key constraints referencing {i}, or if a can be null only when b is null, then you would need:

4. {i}, {i, a, b}

and a single foreign key constraint referencing {i}.

As far as performance goes, assuming that one of a or b or neither is nullable, the performance of a join depends on the cardinalities of {i, a} and {i, b}, the number of rows targeted in each, and the type of join--that is, whether it's a loop join, a merge join, or a hash join. A loop join would require a scan or an index seek for each row (presumably in the table with the smaller cardinality). A merge join would require that {i, a} and {i, b} be presorted or sorted on the fly--provided, of course, that the domain for i has a partial order defined on it. A hash join would require either (1) that a hash index be maintained, or (2) that a hash be computed on the fly during a scan. None of this extra computation would be required for {i, a, b}. I would argue then that your statement is only true if {i, a} and {i, b} are presorted (as is the case when a clustered index is defined in Sql Server), or if the cardinalities of {i, a} or {i, b} or both are small.

>>
>> Imaginary numbers are real values...that's news to me!
>>
>
> Then I would encourage you to read something about mathematics. Complex
> numbers are just as real as the reals or the integers. They are all
> values.
>
>
>> what is the empty set?
>> The absence of a value?
>
> Absolutely not. The empty set is a value. Again, I encourage you to
> read some maths.
>

The Axiom of the Empty Set states that there exists a set that does not contain another set. Since every set is a value, the empty set does not contain a value.

The empty set does not contain a value; every non-empty set contains at least one value. Doesn't that imply that the empty set indicates the absence of a value?

>
>> SQL broke a lot of things. Just because one data sublanguage is screwed
>> up
>> doesn't mean that NULLs aren't useful.
>
> If you are proposing some version of "null" that does NOT break the
> assignment principle then you should state clearly what your proposal
> is.
>

Use something similar to the empty set instead of SQL NULL. It would completely eliminate 3VL altogether.

Some operators:

Ø = Ø        is TRUE
x > Ø         is TRUE unless x = Ø or x = +infinity
x < Ø         is TRUE unless x = Ø or x = -infinity
x + Ø = x        use the empty sum (0)
x * Ø = x        use the empty product (1)

Some aggregates:

SUM use the empty sum (0) for each affected Ø (in other words, ignore Ø)
COUNT use the sum of the cardinality of the value in each affected cell (again, ignore Ø)
AVG if every affected cell is empty, then 0 else SUM/COUNT as above.

> --
> David Portas
>
Received on Mon Oct 02 2006 - 11:25:03 CEST