Re: Requirements for update languages?

Hi Jan, sorry for being late but your article did not appear on our university news server...

hidders_at_REMOVE.THIS.uia.ua.ac.be (Jan Hidders) wrote in message news:<3dcde82e$1_at_news.uia.ac.be>...

> Ok. So let's look at this more closely. Let's say we have tables EMP(Emp#,
> Dept#) and DEPT(Dept#) with a foreign key from EMP.Dept# to DEPT.Dept#. If I
> now only have DEPT in my view then if I delete a department I also delete
> all its employees. However, if I then again add the department (because I
> made a mistake the first time) then the employees are still gone. You would
> probably claim that this is not a good view because the user can delete
> employees but not put them back. I would argue that it is not the user who
> has deleted the employee, but the database. Compare this to the situation
> where there is no foreign key, but another user who has gotten the task of
> firing all employees that do not belong to an existing department. Also then
> it could happen that you delete a department and after a while you put it
> back and then you are left with a department without employees. I don't
> think there is really such a big difference between the database computing
> some extra updates after you have committed and another user that bases some
> of his or her updates on the data you committed.

I see a difference. If *the database* does additional updates, then those updates are executed within *my* transaction and *I* feel responsible for my transactions. I don't feel respnsible for transactions of other users.

Concerning deletion of Departments: As I wrote in the thread "View updating in practice?" I believe that we should design self-contained schemata by taking update requirements into account, i.e., include all objects into the schema that are referenced by user operations. If this does not make sense for some application one can still deny SELECT permissions. This way one must explicitly grant modification rights without selection rights (and, hopefully, think about it).

Jens Received on Thu Nov 14 2002 - 15:28:02 CET