Re: Implicit constraints in a view

Aloha Kakuikanu wrote:
> NENASHI, Tegiri wrote:
> > It is your fantasme about the constraint: 'type' is a virtual column
> > that the clever implementation of insert can utilize as the selector
> > but to update the virtual column, it does not have sense.
>
> No virtual columns! We have two relation variables
>
> RealPeople and Imposters
>
> and three relation constants
>
> R1 = {(typ=RMI)}
> R2 = {(typ=IRM)}
> R3 = {(typ=I)}
>
> and the view written in RA as
>
> (RealPeople/Impostors) x R1
> U
> (Impostors/RealPeople) x R2
> U
> (RealPeople/\Impostors) x R3

It is a banal constatation that one can present a virtual column in the view by the Cartesian product -- the essence is the same -- you did not add some new information.

>
> > I do not
> > say that in your private modele it is not possible; it is possible but
> > you must fix the rules of the play. One can not say: Oh we have that
> > rule, oh, now we have this rule. One can talk about no matter what
> > your private modele but you have to give the rules for the modele.
>
> I'm not sure why you call my model "private". I have a set of relation
> variables, and a set of relation constants. I ask if a particular RA
> expression is updateable or not. What makes this problem different from
> view update?

There are many problems in your presentation of the problem:

                 you continue to change languages:  incorrect SQL-->
correct SQL--> your local dialecte of the relational algebra;
                  no constraints--> the selector virtual column like a
constraint --> no constraints;
                  no rules that determine when the view is updatable,
                  et cetera.

"This problem is different from view update" because one does not know your modele, your language, your rules of update. But one knows the rules in SQL.

>
> > > I suggest that you are not allowed to do the following
> > >
> > > insert ('SomeGuy', 'NotAValidTyp') into AllPosters;
> >
> > In the modern SQL modele, one can not insert into the virtual column
> > and it has a sense: it does not exist in the database. It is the same
> > like to insert into a table that does not exist.
>
> Nope. This update is not possible becase a user is not allowed to
> modify relation constants (nor introduce new ones).

It is your private criterium that is the same as the criterium of the SQL: one can not update a virtual column. C.J. Date if I do not mistake uses the word 'virtual' and 'extend' to specify a view, and not the Cartesian product by a constant relation. That, it is also why your dialecte is private: it is not SQL but it is not the language of Date.

--
Tegi