1NF, missing/unknown data, and structured values
Date: 1 May 2006 18:13:57 -0700
Message-ID: <1146532437.707440.176740_at_i39g2000cwa.googlegroups.com>
My understanding is that a table is in 1NF if
- it is a set of rows (i.e., without duplicates)
- the rows in the table all have the same type signature
- a primary key (i.e., a set of column names) exists for the table such that there is a (partial)
Can someone confirm for me that there are no other constraints on column values under 1NF? In particular, is there any reason why column values should not themselves have structure? For example, dates seem like a perfectly good type for a column, but dates are structured values from which I can project day, month, or year.
If this is so, surely other structures such as lists and various user-defined data types should also be supported, provided they support tests for (in)equality as required by the RM (so higher order types are probably out). Admittedly you'd probably need a richer language than SQL to manipulate these structure values effectively.
Taking this idea further, we could go on to define a collection of "maybe" types (to borrow from functional programming parlance) to handle situations where we have missing or inapplicable data, without the need to break the RM logic with nonsense like NULLs.
The same idea can be extended further: how about
a maybe_applicable(T) type with data constructors
applicable(X) and not_applicable. I could even
nest these types: the type
maybe_applicable(maybe_known(spouse_name))
covers
- whether spouses are applicable (e.g., children
can't be married)
- spouse names where applicable, but unknown
- spouse names where applicable and known.
I believe such an approach avoids both the problems with NULLs (they break everything) and the problem of entirely forbidding structured data in columns (normalisation can lead to a large number of tables).
Question: is this already supported in SQL and the various products out there? If so, why would anyone still use NULLs? If it is not supported, what is the reason?
Ta,
-- Ralph
Received on Tue May 02 2006 - 03:13:57 CEST