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

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:JJ0_h.6944$rO7.6898_at_newssvr25.news.prodigy.net...
>
> "Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message
> news:f19oki$v63$1_at_orkan.itea.ntnu.no...
>> Brian Selzer wrote:
>>> "Cimode" <cimode_at_hotmail.com> wrote in message
>>> news:1178044184.315215.167590_at_p77g2000hsh.googlegroups.com...
>>>> What is a *database value* ? What do you mean that a database
>>>> (collection of facts) is one single value? Do you mean a relation
>>>> value? (the database being perceived as one single complex relation?)
>>>>
>>>
>>> The term "database" is pretty loaded. Most of the time a database is a
>>> value, a set of relations conforming to a particular schema--a
>>> representation of a collection of facts at a particular instant. In the
>>> context of modification, on the other hand, a database is a mutable
>>> entity
>>> whose state transitions from value to value as a result of a series of
>>> events. I use the phrases "database value" and "database state" to
>>> forestall any confusion.
>>>
>>> A set is a value. A database (in the first sense) is a set of named
>>> sets
>>> (relations) of sets (tuples) of named values (attribute values) that
>>> conforms to a particular schema. Therefore it is a single value.
>>
>> Or, if you want to simplify the above by avoiding "state" and "mutable",
>> you could say (as D&D do) that a database is a variable---a
>> dbvar---which has a db value. Which is a tuple.
>
> I think not. A variable permits assignment. You can't compare the value
> being replaced with the value being assigned because (1) the values belong
> to different frames of reference, and (2) a relation is a named set of
> sets, not a named set of named sets. The different frames of reference
> prevent the use of even logical identity. As a consequence, either a
> mapping between the elements in each relation in each value must be
> specified during the transformation, which is not possible with
> assignment, or a mapping must be interpretable from the content of each
> relation, which is only possible if at least one determinant in each tuple
> of each relation is invariant (able to survive any transformation). Once
> that mapping has been established, logical identity can again be used
> because domains are invariant. (Even though domains are invariant, the
> combinations of values from those domains aren't. The mapping, when
> combined with the invariant domains and names, provides a frame of
> reference under which each pair of elements can be compared.) Since key
> updates have been part of the model since its inception, and since
> surrogates aren't, assignment would permit certain constraints to be
> bypassed--a clear violation of one of Codd's rules.
>

Clarification. In a closed world, the assignment itself provides a frame of reference for comparison, so it *can* be determined whether or not the values are identical, or whether or not one or more corresponding relations within each value are identical. As often is the case, I'm wrong: logical identity can be used. On the other hand, it can only be determined that a tuple in a relation in one value is identical to a tuple in a relation in the other. If a relation in the replaced value is neither a superset nor a subset of the relation with the same name in the assigned value, and if more than one element is different, then a mapping is required for comparison. And again, since key updates have been part of the model since its inception, and since surrogates aren't, assignment would permit certain constraints to be bypassed--a clear violation of one of Codd's rules.

>> --
>> Jon
>
>
Received on Wed May 02 2007 - 18:16:23 CEST