Florian G. Pflug wrote:
> dananrg@yahoo.com wrote:
>
>> Date and Pascal hate nulls.
>
> ...the functions described by those functional dependencies are
> not required to be defined for every possible value - let's say you have
> a function dependency A -> B - meaning that whenever you know the value
> of column A, then there is _at_most_ one value for column BNormalization
> basically tells you to model that function dependency as a
> table containing fields A and B, and make A the primary key.
>
> Now, if there is no B for a specific value of A, then this table will
> just not contain a record for this value of A. But if you allow
> NULL-values, then suddently there are _two_ different ways to express
> "I don't know what B is for this A". You could either have a record with
> the A-value in question, and with B null, or you could have _no_ record
> with the A-value in question.
>
But in the former case, you affirm the existence and your knowledge of
the second A-value; in the latter case you affirm ignorance of the
second A-value. The two-column example may be useful for theoretical
discussion, but in practise likely more columns exist so that NULL can
represent incomplete data that may be determined later for a particular
row when you still need to commit the column values already known. For
instance, in response to customer demands, it may be required that a new
employee begins work on projects right away, even though we have only
basic identifying information, like say, their name. This gives us
enough to create a new employee row, start recording their labor hours
worked for billing purposes, and to cut checks for travel expenses. We
eventually need date of birth, social security number, and other
information, but as a practical matter those columns can certainly be
committed NULL initially.
Regards,
Berend Tober
860-767-0700 x118