Re: Proposal: 6NF

paul c wrote:
> dawn wrote:
> > Cimode wrote:
> >> dawn wrote:
> >>
> >>> Given the definition of NULL that I typically use (with non-SQL based
> >>> solutions), NULL is a value and can be modeled mathematically with the
> >>> empty set. In that case, a relation tuple with a NULL is as valid
> >>> mathematically as one without. Agreed? --dawn
> >> An ultra high level density of bullshit and confusion packed in few
> >> sentences...
> >>
> >> The fact a construct can be modeled mathematically does not mean it
> >> systematically qualifies it as a value. The *ONLY* valid mathematical
> >> definition of a *value* consist of having the characteristic of being
> >> the output of a *predetermined* transformation (function).
> >
> > Define a function f such that f("F") = "Female" and f("M") = "Male" and
> > f(null) = null
> >
> > Functions like this are very common when working with 2VL languages.
> > ...
>
> No they aren't. You are talking of something other than 2VL. You won't
> get anywhere if you don't start out right.
>
> p

OK, I'm open to correction and would like to understand your point. In practice, functions like this are common in Pick (even if not specified like this). The point was to show that in fact a NULL (not an SQL NULL) can be the output of a function.

What is an accurate generalization or abstraction from Pick? What are the precise features that permit this example of a function with null in the range of a function within the dbms environment? I thought the 2VL was a key factor in null being a value rather than a non-value as it is in SQL. Thanks. --dawn Received on Sat Oct 07 2006 - 05:38:16 CEST