Re: compound propositions
Date: Wed, 17 Mar 2010 16:28:08 GMT
David BL wrote:
> On Mar 17, 1:18 am, paul c <toledobythe..._at_oohay.ac> wrote:
>> The only comment I have right now is that I don't think >> databases have base relations! Whether a relation is base seems to >> depend on a particular usage, such as within an algebraic expression. So >> a relation might be 'base' in one program and not in another even >> though both involve the same database.
> I wonder whether this might be connected with the issue of how to deal
> with partial information, the view update problem, and the CWA.
> Consider the following 3 predicates:
> P1(S) = Supplier S is on the northside
> P2(S) = Supplier S is on the southside
> P3(S) = S is a supplier
> Assuming the CWA, we require P3 = P1 or P2. Rather than think of P3
> as derived, let P1, P2, P3 be represented using base relations R1, R2,
> R3. Then P3 = P1 or P2 becomes an *integrity constraint* - i.e. R3 =
> R1 union R2.
> It is not permissible to insert a tuple into R3, without adding a
> tuple into either R1 or R2 at the same time (but we cannot know which
> because of ambiguity). A transaction is aborted if it fails to meet
> the integrity constraint. The ambiguity doesn't occur when inserting
> a tuple into R1 or R2, but nevertheless it is necessary to also insert
> a tuple into R3 or else the transaction will fail. So what does
> treating R3 as a base relation buy you? Nothing good that I can see.
> Now consider instead that we allow for partial information. Consider
> the predicates as follows:
> P1'(S) = It is known that supplier S is on the northside
> P2'(S) = It is known that supplier S is on the southside
> P3'(S) = It is known that S is a supplier
> Let's assume the following
> P1'(S) => P1(S)
> P2'(S) => P2(S)
> P3'(S) => P3(S)
> P1'(S) => P3'(S)
> P2'(S) => P3'(S)
> Note that we don't require P3' = P1' or P2'. Therefore we have a
> very different integrity constraint from before:
> R1' is subset of R3'
> R2' is subset of R3'
> Transactions can meet this constraint by following these rules:
> 1. Insert tuple into R1' => insert tuple into R3'
> 2. Insert tuple into R2' => insert tuple into R3'
> In contrast to before, it is allowable to insert a tuple into R3'
> without inserting a corresponding tuple into either R1' or R2'.
My attitude is that 'partial information' is too nebulous a term to be useful because it amounts to the same thing as 'missing information'. If we can't be bothered to record (eg., provide a suitable attribute) or otherwise stipulate that a supplier is on the northside or wherever, we shouldn't expect a dbms to respect the stipulation, because that information is not available to its operators.
Eg., the typical algebra doesn't operate on relation names, only relation values. As far as a relational dbms is concerned the inclusion of 'northside' or 'southside' in some unrecorded predicate is irrelevant. A better label for partial information would be 'non-existent information', which might help to underline its irrelevance.
Some people talk about relation or relvar names having no meaning, then in the next breath assume that two names (such as R1 and R2 above) must have different predicates. I presume the reason is that if R1 and R2 had different values they would contradict each other unless the predicates were different. That seems like meaning to me but it is a meaning that can't be respected in the results of an algebra that doesn't operate on relation names. The argument against certain view updates seems to be based on this whereas I would say the very lack of attributes to describe such information means there is no ambiguity at all within an algebra.
I don't want to get into the view updating discussion again because I've found in the past that it is pointless when such a starting point can't be agreed on. Either the 'information' is available to an algebra or it's not. If it's not, I think one implication of the Information Principle is that there is no ambiguity for the usual cases (insert 'to' a projection is another story). As for the CWA, I don't think of it as a 'logical' assumption, more a practical device to avoid physical problems. Received on Wed Mar 17 2010 - 17:28:08 CET