Re: Proposal: 6NF

Karen Hill wrote:
> 6NF would be a database that uses no Nulls.
>
> This way, one could specify that they demand their relations in 6th
> Normalized Form, and have a database design that uses no Nulls.
>
> Those that like nulls can have thier 3NF, while the rest of us reach
> for higher standers like 6NF.

I don't think we got very far on your question, Karen (and I know I helped take it off track in one of the various directions, sorry 'bout that).

I have a question about your proposal. Is it possible to use no nulls in a database design and not have the data in some NF 1-5 (or if yours were to be 7NF since there have been other 6's, then 1-6)? E.G. Could one have the DBMS in 2NF, but not 5NF and also exclude NULLS from the design?

One thing I do not at all like about 2NF, 3NF etc is that they first require 1NF. Those who have recognized that there is no reason to exclude relation-valued attributes have had to redefine 1NF. Those working in non-1NF DBMS's still work with NFs that are related to functional dependencies. But we cannot say that the data design is in 3NF since it is not in 1NF, which is part of the def of 3NF.

As one who really likes working with lists, this numbered list of NF's seems particularly ill-suited to being a list. It might be an example of an "unordered list" (recognizing this is an oxymoron by most definitions, even if not mine -- it is logically ordered, but conceptually unordered). Perhaps we could call it NULL Normal Form or No-NULLS Normal Form.

Additionally, the use of the term NULL, without refering to it being an SQL NULL is not precise enough given the number of developers who use NULLS handily without the same downsides as with SQL. There still are complexities with DBMS's that use other models and employ NULLS with 2VL, treating them like the empty set. But I doubt there is any significant design in the non-SQL DBMS world where NULL is a possible value that do not employ them. I'm pretty sure > 99% of MV/Pick production databases have NULLs, and it is not poor design to do so. So, we can add another NF that is irrelevant to database designs using many DBMS's, but we might want to categorize these in some way.

Cheers! --dawn Received on Mon Oct 16 2006 - 04:10:39 CEST