Re: Guessing?

"David BL" <davidbl_at_iinet.net.au> wrote in message news:6cf3baa1-33b5-4dcd-bac7-1f7d1215eb14_at_u36g2000prf.googlegroups.com...
> On May 26, 1:15 am, paul c <toledoby..._at_ac.ooyah> wrote:
>> Thanks to Brian S for reminding about Codd's book. On the question of
>> view updateability, I'm interested in comments about this quote from
>> page 294:
>>
>>
>>
>>
>>
>>
>>
>> > Now for a second example, this one involving union and a view based
>> > on two relations, not just one as in the first example. Suppose that
>> > two of
>> > the base relations in the database are SE and SW, where SE provides the
>> > identification and immediate properties of suppliers east of the
>> > Mississippi
>> > River, while SW provides similar information about suppliers west of
>> > the
>> > Mississippi. Suppose also that SE and SW are union-compatible and that
>> > neither SE nor SW contains a column that indicates directly by its
>> > values
>> > whether the supplier is east or west of the Mississippi.
>>
>> > Base: SE ( S# SNAME CITY STATE... )
>> > SBase: W ( S# SNAME CITY STATE... )
>>
>> > Now, suppose that a view S is created as the union of SE and SW.
>> > Suppose also that a user is authorized to enter a new row into the view
>> > S.
>> > Such a request must be reflected in some change applied to the base
>> > relations,
>> > which are the only relations that reflect the true state of the
>> > database. How
>> > does the DBMS decide which of the two base relations SE and SW is to be
>> > the recipient of this row? Even if two of the immediate properties of
>> > suppliers
>> > recorded in SE and SW are the city and state in which each supplier is
>> > located, it is not appropriate to assume that the DBMS or the database
>> > has
>> > any knowledge about geography, and in particular about which cities and
>> > states are on which side of the river.
>>
>> > It is worth noting that, in this second example, the view S is actually
>> > the disjoint union of SE and SW, a reasonably simple case; still,
>> > however,
>> > entry of new rows into the view is not admissible. Nevertheless,
>> > whatever
>> > it does, the DBMS would be guessing the user's or program's intent, and
>> > such behavior is unacceptable in managing a shared database.
>>
>> I'm fastening particularly on where he says it is unacceptable for the
>> DBMS to "guess" at intent. I'm inclined to call his attitude mystical.
>> If the DBMS is ordered to insert the tuple and no information it has
>> been given, such as constraints, countermands that, and it has a
>> consistent method for doing so, why the dickens shouldn't it?
>>
>> It is just as much a guess for the DBMS to give the impression that the
>> request/order is ambiguous (a word Codd uses earlier on). In this case,
>> it just doesn't know, ie., hasn't been told and should keep its
>> figurative mouth shut!
>>
>> (My attitude about such inserts is for the DBMS to use its UNION feature
>> to all base relations in the definition, then apply any defined
>> constraints to the results. In the purest implementation some results
>> might be seen by programmers as inconvenient, for example where a
>> primary key was involved and the request implied a contradiction, the
>> result might be an empty relation, so an implementation might support
>> the raising of exceptions for convenience, but this is outside the RDM's
>> scope.)
>>
>> Rather than guessing, I think he is really talking about the Information
>> Principle, which is an idea that concerns designers, not DBMS
>> implementations.
>
>
> It seems to me that every base relvar will in practice have some
> defined intensional definition outside the RM formalism and
> inaccessible to the DBMS.

I thought the intension of a relation states what can be while the extension states what is: wouldn't that place the intensional definition inside the RM formalism? I understand what you're driving at, though, but I think it is indeed a part of the RM formalism. Let me explain. Suppose you have predicate symbols P and Q. Isn't it true that under a first order logic interpretation, not only constant symbols are assigned meaning, but also predicate symbols? Isn't one of the assumptions under which the Relational Model operates the Unique Name Assumption? Wouldn't that assumption apply with equal force to predicate symbols as it does to constant symbols? What I mean by that is that it should not be possible for two predicate symbols to be assigned exactly the same meaning in the same way that it should not be possible for two constant symbols to be assigned exactly the same meaning. Now, a predicate can be a conjunction of other predicates, and the components of that conjunction can appear in other predicates, but if two predicates are composed of the exact same components, then they are really just one, and the Unique Name Assumption would require that only one predicate symbol be used to represent that particular conjunction of components. Bottom line: the name assigned to a relation is significant because it is a symbol for a distinct predicate.

> .... That would suggest that the DBMS should
> only permit updates to derived relvars that map uniquely to associated
> updates to the base relvars. Without any need to anthropomorphize the
> DBMS, it is mathematically well defined whether there are alternative
> base relvar updates that are consistent with the derived relvar
> update. In such a case the DBMS should indicate an ambiguity error.
>
> In the example from Codd, I think it is incompatible with the
> Interchangeability Principle. The problem is that the database schema
> doesn't allow for missing information about whether a given supplier
> is east or west of the Mississippi. Since the DB cannot represent
> that kind of partial information it cannot support updates from a view
> (ie derived relvar) with the missing information. The problem is
> analogous to attempting insertions to a derived relvar that has
> projected away an attribute.
>
>
Received on Fri May 30 2008 - 15:14:54 CEST