Re: Base Normal Form

David Cressey wrote:

> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message 
> news:shgye.137258$4T6.7275581_at_phobos.telenet-ops.be...
> 

>>> I'd like to suggest a new Normal Form definition, one that I'm
>>> calling Base Normal Form, for lack of a better term.

> 
> Thanks, Jan.
> 
> I guess I'll stick with "Base Normal Form" for now.  Are UNF and NFNF
> defined on tables or on relations?

Hmm, good point, on relations. So they are actually not the same as your concept.

>>> I haven't defined candidate key, but I would want the definition
>>> to be compatible with the definition of candidate key as used in
>>> BCNF.

> 
> What's the difference between calling a table a list of tuples, and
> calling a table an array of tuples?

Nothing, really. Although for me an 'array' has some associations with a particular kind of implementation.

>> Note that this definition is sloppy in the usual way where we
>> ignore the fact that a candidate key is not so much a property of a
>> single relation but rather of the set of all relations that are
>> valid for a certain relvar.
>
> I'm hazy on the distinction between a relation and a relvar.

A relation is a particular set of tuples, say, the contents of the Employees table at this moment. The relvar would in that case be more abstract notion of the Employees table. People will often use the term relation for both things.

>> I wouldn't skip 3NF. The difference between BCNF and 3NF is an
>> important one and the decision to go beyond 3NF should be an
>> informed one.

> 
> Can you say some more about this?  What are the consequences of
> taking a step between 3NF and BCNF?

You might no longer be dependency preserving. That means that some of the constraints can no longer be represented as key constraints and foreign key constraints.

• Jan Hidders