Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation

On Apr 30, 1:56 pm, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
[Snipped]
> I'm not sure I understand you. Missing information is a problem independent
> of any implementation.
Sure but NULL is only one way to handle missing information and it is one that does not fall into 2VL required by RM.

> Why would the implementation have any impact at all
> on null elimination?
Simply because NULLS is implementation-dependent. An SQL fundamentally wrong futile hack to handle missing information.

> It's a design technique, and the system only does what
> it has been told: if the system has been told, NOT NULL, then that is what
> it enforces.
When coming to speak of NULLS and their fundamental consequence I would rather think of it as a non design than a specific design choice.

> >> The only
> >> thing lost in the process is the sense of applicability, but that can be
> >> overcome by creating a third relation with an applicability attribute and
> >> either one or two foreign key constraints, depending on whether or not
> >> the
> >> attribute always applies. With nullable attributes there's no need for a
> >> third relation, and sometimes not even a second. If an attribute always
> >> applies (a functional dependency exists), but some of the values may be
> >> absent, then a nullable attribute would be in order. If an attribute
> >> sometimes applies, but when it does, a value is always present, then a
> >> separate relation with a foreign key constraint would suffice. If an
> >> attribute sometimes applies, but even when it does, a value may be
> >> absent,
> >> then a separate relation with a foreign key constraint along with a
> >> nullable
> >> attribute would be needed. In this way it can be determined from the
> >> schema
>
> >> definition whether an attribute applies always or sometimes, and when it
> >> does apply, whether a value can be absent.
> > You lost me on that. RM is 2VL not 3VL. I do not understand what you
> > mean by nullable attributes. Are you speaking on a logical
> > perspective? physical implementation?
>
> I am speaking from a logical perspective. A nullable attribute is one that
> allows nulls. The RM includes the concept of null. This has been one of
> Date's pet peeves with Codd over the years. In December, 1986 Codd wrote an
> article in the SIGMOD RECORD, Vol. 15, No. 4 entitled "Missing Information
> (Applicable and Inapplicable) in Relational Databases." In it he talks
> about using A marks and I marks instead of null to make clear the main
> reason that a datum is missing. I think that the same thing can be
> accomplished using a single null: if the attribute participates in a
> functional dependency, then it is clear that the attribute applies for every
> tuple in the relation. If it doesn't, then due to POFN, it should be in
> another relation anyway, and the presence of a tuple in the other relation
> should indicate that the attribute is applicable for a given referenced
> tuple. This means that a null should only ever indicate that an applicable
> value is missing, eliminating the need for I marks altogether. This should
> also simplify the systematic treatment of nulls.
I am aware of that article but thank you for reminding it. It simply a negation of previous work and has been demonstrated since as wrong by Codd's disciples (Date, Darwen). The induction of NULL 3VL simply breaks the POCW (Principle of Closed World) redefining the meaning of a database as a collection of facts. I think of this tolerance as one of Codd's errors. Received on Mon Apr 30 2007 - 15:13:10 CEST