Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
Date: Thu, 03 May 2007 00:09:54 GMT
Message-ID: <mL9_h.4212$H_.844_at_newssvr21.news.prodigy.net>
"Cimode" <cimode_at_hotmail.com> wrote in message news:1178130430.502230.295300_at_u30g2000hsc.googlegroups.com...
> On 2 mai, 18:16, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>> "Brian Selzer" <b..._at_selzer-software.com> wrote in message
>>
>> news:JJ0_h.6944$rO7.6898_at_newssvr25.news.prodigy.net...
>>
>>
>>
>>
>>
>> > "Jon Heggland" <jon.heggl..._at_idi.ntnu.no> wrote in message
>> >news:f19oki$v63$1_at_orkan.itea.ntnu.no...
>> >> Brian Selzer wrote:
>> >>> "Cimode" <cim..._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
> Brian, > > Don't you think you are overcomplicating things? >
I don't think so. D&D's interpretation of the model is great for dealing with individual snapshots of data. If there were no need for transition constraints, then their interpretation would be sufficient. But I perceive a need, and even D&D perceive that need: it's RM Very Strong Suggestion # 4! As I see it, there are only two ways to meet that need: (1) introducing surrogates or something akin to them, or (2) chucking the closed world assumption and its consequence, assignment--at least when it comes to database transformations. In (1) a relation is transformed into a named set of named sets of named values, so there's no problem comparing successive values. In (2) the mapping between successive values is specified by the user, so there's no problem comparing them.
I would think it should be possible to suspend the closed world interpretation only during a transformation. In fact I think it shouldn't only be possible, but necessary. Since in a closed world, if a tuple is absent, its corresponding atomic formula is false, how can the presence of that tuple in a proposed database be reconciled in the context of a transformation? Is a transformation a transition from one closed world to another? In an open world there is no doubt: the current value is what has already been recorded and the proposed value is what is now known. Received on Thu May 03 2007 - 02:09:54 CEST