Re: On view updating

Marshall Spight wrote:
> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:2r6lvdFl18ghU1@uni-berlin.de...
>
>>I think they've got it wrong on several counts.
>>
>>1) Is whether view updating is crucial to "logical data independence".
>>
>>Very little have I seen in the way of defending this point. Since
>>relvars are "variables" and the rest are computed values, and Date
>>insists so much on the logical distinction between variabke and values,
>>well we should apply a rather trivial distinction
>>
>>that rvalues are not lvalues.
>>
>>By insisting that views should be seen as updatable Date actually
>>insists that in his model some values should be used as lvalue.
>
>
> I dunno. It seems to me that regardless of this distinction, updatable
> views are very useful.
>

Indeed, updatable views are useful, but the point is: *let's not over do it*

in the previous Date&McGoveran line of thought, currently defended by McGoveran only (or so it seems to me) all it boiled down to was either:

1. Our prescribed algorithms is able to infer the base relvars update unambiguously and you should be happy with inferred updates
2. if the prescribed algorithm doesn't match the semantics you know are in the domain modelled, then it "follows" (by the way of some handwaving) that you have a badly designed schema, which can further be broken down to: 2a) The schema has some structural deficiencies (like it is lacking BCNF or something even fuzzier 2b) Schema is lacking some of the static constraints available in the domain. For example the schema designer forgets to declare a uniqueness constraint, but bear in mind static constraints can be a hell of a lot more complicated than what people have usually in mind (uniqueness, foreign keys, etc).

If my understanding of their position is correct, I think this is position is untenable and doomed to fail.

It may be a "correct" (sound) formalism that they are constructing but it is very likely a pragmatically useless formalism. Just as with their Tutorial D type system.

> There was a time when I considered a database schema to be
> something unique, but now I see that it is just an interface;
> an API even. In that light, updatable views can be thought
> of as a declarative mapping from one interface to another.
> Given that much of modularity depends on interfaces changing
> rarely if at all, then the ability to define views declaratively
> gives one the ability to specify a per-application interface
> to an underlying interface that is then free (or anyway freer)
> to evolve according to changing business needs.
>

Sure. But just consider that currently Oracle, SQL et. comp. offers you the means to specify just that by providing your own update rules. CREATE TRIGGER ... INSTEAD OF UPDATE ... {do the other stuff}

That some of the update rules should have reasonable defaults inferred automatically by the DBMS and active by default is one thing, but the idea that all update rules should be automatically inferred according to the prescribed algorithm is what I criticize.

>
> [...]
>
>
>>3) That it is useful and even that it is palatable for the database
>>designer to specify all static invariants in a database schema.
>
>
> I'm curious as to the use of the word "static" here. (It may be that
> there is background to this comment that I'm not aware of.)
>

Well, static means it apply to a single database instance. Such as a foreign key, etc.

Once you introduce history properties, you get dynamic integrity constraints -- those are properties over the history of database instances.

A trivial but useful example: once ORDER_STATUS=APPROVED at some point in time, it can never become CREATED at any subsequent point in time. Because in order to formally specify this you need to quantify over the history of database instances, these are called dynamic constraints.

> I would describe most of the invariants or constraints in a dbms
> as non-static, in that they are not checkable ahead of time, or
> at compile time, or statically, but maybe this is not what you
> mean in this context by that term.
>
>
>
>>Then there's the third point that the relational model is by design a
>>model less powerful than first order logic in order to address the
>>pragmatics of database implementation. It is a very desirable trade-off
>>between expressivity and engineering properties of the software systems.
>
>
> Less powerful, you say? Can you explain this? I spent the weekend reading
> papers describing the relational algebra as being exactly as powerful as
> the relational calculus which is in turn exactly as powerful as the
> first order predicate logic. But you are saying "less powerful." Can you
> help me resolve this paradox?
>
>

Sure very simple. Try to let the user input the known fact that X=2 OR X=3. Say "mary has blue eyes or mary has green eyes".

Or to say that "Whoever has blue eyes will be likable to john"

>
>>Now by mandating the view update sucessful resolution, we want to
>>transform relational model into Prolog.
>>We don't need that because if we want Prolog, we already have it.
>
>
> I'm not sure whether we really want Prolog by itself, expect perhaps as an
> interesting example.
>

Well, sure. Then we talk about constraint databases. Because of increase in expressing power they have some undesirable engineering properties (like non-termination vis-a-vis queries).

> But mightn't we want a general purpose application language with relational
> features that was Turing complete? That would necessitate adding something
> beyond the basic relational model, and perhaps adding Prolog is just
> the ticket. Actually, I'd probably add a bunch more things as well.
>
>

But that wouldn't make it a useful model as it was before. It is very useful because it has some nice properties, vis-a-vis optimizations, declarativity, termination, etc. If you want more power and less of the above properties, you don't need relational model, just go ahead and use Prolog or some similarly powerful logic language. By extending the relational model to give you more expressivity you'd just be reinventing something else already there.

> Marshall
>
>

Costin Received on Mon Sep 20 2004 - 20:59:45 CEST