insert to projection

#21

Vadim Tropashko wrote:

Quote:

On Sep 4, 9:58 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
... We can delete from projection ...

Are you suggesting projection being updatable in respect to deletion?

Not as things stand, at least not always, meaning not always with the
conventional tables and relvars that have one predicate.

Quote:

I fail to see this, here is my worksheet:
...

If I read that worksheet right, it means we can't delete 
from a conventional table or relvar and expect to be negated,
which I don't argue with. (whereas I don't think anybody disagrees that
we already can delete and expect to be negated.)

#22

On Sep 6, 11:40*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

If I read that worksheet right, it means we can't delete to be negated,
which I don't argue with. *(whereas I don't think anybody disagrees that
we already can delete and expect to be negated.)

What do you mean by negating a tuple? View update expresses increments/
decrements of the base relations in terms of increments/decrements of
the view(s). Compare it to (a relatively simple) view maintenance
problem where increments/decrements of the view(s) in terms of
increments/decrements of the base relations. Maintenance of the
projection view (or any other relational expression for that matter)
is easy: just take a projection of any incremant/decremant of the base
relation.

#23

Vadim Tropashko wrote:

Quote:

On Sep 6, 11:40 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
If I read that worksheet right, it means we can't delete to be negated,
which I don't argue with. (whereas I don't think anybody disagrees that
we already can delete and expect to be negated.)

What do you mean by negating a tuple? ...

Retracting/negating the proposition the tuple stands for.

View update expresses increments/

Quote:

decrements of the base relations in terms of increments/decrements of
the view(s). Compare it to (a relatively simple) view maintenance
problem where increments/decrements of the view(s) in terms of
increments/decrements of the base relations. Maintenance of the
projection view (or any other relational expression for that matter)
is easy: just take a projection of any incremant/decremant of the base
relation.

No argument that it's conceptually easy, but in practice the base could
have a dozen such projections.

#24

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:

Walter Mitty wrote:
....
Part of the problem with regard to sloppy language is that the term "view
update" is misleading. If view C is defined as A join B and one were to
apply an update, let's say MINUS D, what gets updated? If we were, in
reality, updating view C, then the update would be really simple. We
would update view C by changing its definition. The new definition of C
is (A join B) minus D. This might require making D be persistent, so
that the view can be applied later. Hey, presto! View C has just been
updated!

But that's not what we really mean when we say "update view C". What we
mean is "leave view C defined exactly as before, but update A and B such
that the effect on C's apparent extension is the same as if the update
had been applied to a base relvar whose extension is the same as C's
apparent extension." Under this meaning of "update view C" the operation
is underconstrained, as has already been noted.

I changed the subject back to delete from join because the above is not
about insert to projection. They are very different problems (unlike
delete from join, insert to projection is not just a matter of
constraints).

Insert to projection is indeed underconstrained, provided the projection is
non trivial.

When you insert into a projection, this means adding tuples to the relvar on
which the projection is based. If there are attributes in the base relvar
that are not present in the projection, then those attributes remain
unspecified by the insert into the projection. They become "missing data"
in the resulting tuples. That's underconstrained.

#25

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:

Mr. Scott wrote:
"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message
news:uskom.43824$PH1.21867 (AT) edtnps82 (DOT) ..
Mr. Scott wrote:
"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message
news

Gbom.42669$Db2.5159 (AT) edtnps83 (DOT) ..
Why do implementation languages not allow this? Surely not for
logical reasons? We can delete from projection because NOT Pa implies
NOT Pab, eg., <NOT> R{a} -> <NOT> R{a,b}. Logically, we can insert to
projections because Pab implies Pa. Isn't the problem really a
language deficiency?
I don't understand. Is the binary predicate P somehow related to the
unary predicate P, and if so, how exactly?

Sure it is, the truth of the tuple <a 1, b 2> implies the truth of the
tuple <a 1> and the falsity of the tuple <a 1> implies the falsity of <a
1, b 2>, as far as a relation R with predicate P is concerned.
Projection means quantification and vice versa, what's the problem?
(Could it be that predicates aren't recorded?).

Can you express the relationship formally? Something about your
explanation doesn't seem right. There can be a row <a 1> in the
projection if and only if there is a row that is a superset of <a 1> in
the table. That works out to something like,

Px iff (exists y exists z Pyz /\ (x = y))

But this actually denies insert to projections because it is not enough
to know that there is at least one z, it is necessary to know which z or
set of z's there are for a given x, unless you want to introduce nulls.

What I wrote could be taken wrong. When I said that "logically" we can
insert to a projection it would be have better to say that several
projections are inserted when we insert <a 1, b 2, c 3>, eg., R{a} or <a
1> but the converse isn't logical. It's a starting position for figuring
out a language definition that would allow insert to projection. I didn't
mention rows and tables because I think they are probably not part of a
solution.

In general, a conclusion follows from a set of premises, not the other way
around. Sometimes there is only one set of premises from which a conclusion
follows, and it is only then that the corresponding view update should be
deemed permissible. The underlying criteria for permitting an operation on
a view has to be a one-to-one mapping from the set of conclusions into the
power set of premises.

#26

Walter Mitty wrote:
....

Quote:

Insert to projection is indeed underconstrained, provided the projection is
non trivial.

When you insert into a projection, this means adding tuples to the relvar on
which the projection is based. If there are attributes in the base relvar
that are not present in the projection, then those attributes remain
unspecified by the insert into the projection. They become "missing data"
in the resulting tuples. That's underconstrained.

This is just re-phrasing Scott's logical argument.

More accurate to say it's undefined (in the typical dbms). Undefined
because the resulting header of an assignment of a projection is
typically not specified unless a relvar with the projected heading is
recorded (Vadim also said this). Whereas insert to projection and
delete from join are defined, just not treated as possible by most dbms'
because the result form excludes all possible true combinations.

We really need to ask what is the purpose of the logical foundation. I
say it is to i) unambigously predict resulting extension values without
reading code and 2) use logical theorems to optimize the physical
implementation. To accomplish this, all that's required is to use
different language definitions, eg., don't use C' = C MINUS D to define
delete nor D' = C UNION I to define insert, Different definitions for
delete and insert don't deny logical axioms at all and those axioms can
still be used for both of the above purposes. If one likes, one could
call those new definitions constrained.

In other words, logic is applied to the definitions of a language's
verbs by a dbms to obtain recordable extensions. This is quite
different from a dbms that duplicates logical statements. I'd say it
is the essential difference between the typical commercial dbms and the
logic-based AI systems. Application and duplication are two different
purposes. A language designer needs to choose which purpose. It seems
most sql designers ignore the question and pretend to do both

Whereas inserting to projection isn't amenable to constraining the
definition of the assignment, rather that would need expanding the
result in a form that allows an expanded interpretation without
requiring the explicit specification of allowable headers. I think some
people call such a form a 'multi-relation', which is neither a table nor
a relvar as we know them, but I'm not sure if they all have the same
form in mind,

(They aren't alone. I think the almost pathological introduction of
insert to union or insert to projection here when the topic is delete is
symptomatic of a general inability to separate questions and focus on a
dbms' purpose. Once a dbms designer chooses a suitable delete from join
definition, the next thing he needs to check is what that means to his
delete operator in general.)

#27

paul c wrote:
....

Quote:

recorded (Vadim also said this). Whereas insert to projection and
delete from join are defined, just not treated as possible by most dbms'
because the result form excludes all possible true combinations.
...

Oopa, sorry, meant to say "Whereas insert to union and
> delete from join are defined, just not treated as possible ..."

#28

paul c wrote:

Quote:

paul c wrote:
...
recorded (Vadim also said this). Whereas insert to projection and
delete from join are defined, just not treated as possible by most
dbms' because the result form excludes all possible true combinations.
...

Oopa, sorry, meant to say "Whereas insert to union and
delete from join are defined, just not treated as possible ..."

Bloody hell, let me try again: "Whereas insert to projection and delete
from join are defined, just not treated as possible ...".

Sorry if some of you may be annoyed by all my repetition, just saying
one more time that I think insert to join is a different problem and
can't be solved with only a different definition of insert.

#29

paul c wrote:
....

Quote:

Sorry if some of you may be annoyed by all my repetition, just saying
one more time that I think insert to join is a different problem and
can't be solved with only a different definition of insert.

Oops yet again, meant insert to projection not insert to join. Sorry
one more time. I think I'll give it a rest until my coordination improves.

#30

On Sep 4, 12:58*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

Why do implementation languages not allow this? *Surely not for logical
reasons? *We can delete from projection because NOT Pa implies NOT Pab,
eg., <NOT> R{a} -> <NOT> R{a,b}. *Logically, we can insert to
projections because Pab implies Pa. *Isn't the problem really a language
deficiency?

Implementation languages do allow this. As long as the columns that
are not in the view are either nullable or have a default constraint,
then insert to projection is allowed. Here's an example:

CREATE TABLE ex
(
K int NOT NULL ,
A int NULL ,
B int NULL ,
C int NULL ,
D int NOT NULL DEFAULT (0),
PRIMARY KEY CLUSTERED (K)
)
go

create view exview as
select K,A,B from ex
go

insert exview (K,A,B) VALUES (1,1,1)
go

select * from ex
go

Results:

K A B C D
----------- ----------- ----------- ----------- -----------
1 1 1 NULL 0

(1 row(s) affected)