Re: How to normalize this?
Date: Wed, 1 May 2013 22:54:25 +0200
Message-ID: <51818101$0$597$e4fe514c_at_dreader34.news.xs4all.nl>
On 2013-05-01 20:17:59 +0000, James K. Lowden said:
> On Wed, 1 May 2013 11:20:47 +0200
> Jan Hidders <hidders_at_gmail.com> wrote:
>
>> On 2013-04-30 22:17:44 +0000, Erwin said: >> >>> It's often bothered me that normalization theory/procedure seems to >>> quietly ignore the notion of "nullability or not" of any of the >>> attributes in the "initial table design" ... >> >> Nullability doesn't really matter for normalization. From a >> redundancy point of view null is just another value.
>
> I guess I don't know what a "redundancy point of view is", but
>
> 1. Null is not a value. Null is a mark noting that the value is
> missing. I don't see how a non-value becomes a value depending on
> one's point of view.
Strictly speaking it doesn't. But normalization theory does not care about whether you have values or markers in your fields. Definitions for redundancy, update anomalies, etc. stay the same.
> 2. Null is not "just another" value. A nullable column by definition
> has an optional relationship to the key. Any nullable column can be
> placed in a separate table with an FK relationship of 0:1 or 0:N
> cardinality.
Note that theoretically speaking that is also true for non-nullable columns: you can als there create an information-equivalent schema that way, even including the 0 lower bound for the FK relationship.
> AFAIK functional dependency analysis does not entertain nulls or
> address missing information. The database designer should pay attention
> to them, though, because they indicate the potential of more than one
> kind of relation in a single table.
True. That's actually a pretty good description of what normalization is about: detecting whether more than one kind of relation is combined into a relation and whether that is problematic or not.
- Jan Hidders