Re: Possible problems with Date & McGoveran View Updating
From: Jan Hidders <jan.hidders_at_pandora.be.REMOVE.THIS>
Date: Fri, 03 Oct 2003 10:59:21 +0200
Message-ID: <3f7d3a45.0_at_news.ruca.ua.ac.be>
>>Mikito Harakiri wrote:
>>
>>>"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
>>>news:s7n9b.21899$%C3.1400873_at_phobos.telenet-ops.be...
>>>
>>>>Mikito Harakiri wrote:
>>>>
>>>>>"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
>>>>>news:Ym%8b.20114$7y3.1376399_at_phobos.telenet-ops.be...
>>>>>
>>>>>>Mikito Harakiri wrote:
>>>>>>
>>>>>>>"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
>>>>>>>news:PX38b.14807$2Z.580673_at_phobos.telenet-ops.be...
>>>>>>>
>>>>>>>> A small example. Suppose we have a table
>>>>>>>> Emps(name,dept) and a view TrEmps defined by
>>>>>>>>
>>>>>>>> SELECT name
>>>>>>>> FROM Emps
>>>>>>>> WHERE dept = "sales";
>>>>>>>>
>>>>>>>> then if you add a tuple to this view it is perfectly
>>>>>>>> clear which tuple should be added to Emps and so this
>>>>>>>> is a well-defined update.
>>>>>>>
>>>>>>> This view is not updateable. If you delete a tuple from
>>>>>>> this view, do you delete from the base table or update
>>>>>>> dept = 'sales' into some other value (which we can't
>>>>>>> deduce from TrEmps alone)?
>>>>>>
>>>>>> According to the definition I gave this deletion is
>>>>>> well-defined. The unique "minimal" solution is that the
>>>>>> corresponding tuple is deleted from Emps, and indeed that
>>>>>> is all that the database knows for certain: this tuple has
>>>>>> to to be removed. I find this quite intuitive, can you
>>>>>> explain why you don't?
>>>>>
>>>>>Because if you update base table
>>>>>
>>>>>update Emps
>>>>>set dept = 'marketing'
>>>>>where dept = 'sales'
>>>>>
>>>>>the observed effect on TrEmps is deletion of a tuple.
>>>>
>>>> No, this is an illegal update because you are trying to insert
>>>> a tuple into a relation that cannot have such a tuple. This
>>>> makes sense because your view is your ontology so the only
>>>> thing that you can tell the database is that someone is no
>>>> longer with sales. It's the user with the marketing-view that
>>>> should tell the database that this employee is now with
>>>> marketing.
Date: Fri, 03 Oct 2003 10:59:21 +0200
Message-ID: <3f7d3a45.0_at_news.ruca.ua.ac.be>
D Guntermann wrote:
> "Jan Hidders" <jan.hidders_at_pandora.be> wrote in message > news:jWo9b.22053$NH3.1410149_at_phobos.telenet-ops.be... >
>>Mikito Harakiri wrote:
>>
>>>"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
>>>news:s7n9b.21899$%C3.1400873_at_phobos.telenet-ops.be...
>>>
>>>>Mikito Harakiri wrote:
>>>>
>>>>>"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
>>>>>news:Ym%8b.20114$7y3.1376399_at_phobos.telenet-ops.be...
>>>>>
>>>>>>Mikito Harakiri wrote:
>>>>>>
>>>>>>>"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
>>>>>>>news:PX38b.14807$2Z.580673_at_phobos.telenet-ops.be...
>>>>>>>
>>>>>>>> A small example. Suppose we have a table
>>>>>>>> Emps(name,dept) and a view TrEmps defined by
>>>>>>>>
>>>>>>>> SELECT name
>>>>>>>> FROM Emps
>>>>>>>> WHERE dept = "sales";
>>>>>>>>
>>>>>>>> then if you add a tuple to this view it is perfectly
>>>>>>>> clear which tuple should be added to Emps and so this
>>>>>>>> is a well-defined update.
>>>>>>>
>>>>>>> This view is not updateable. If you delete a tuple from
>>>>>>> this view, do you delete from the base table or update
>>>>>>> dept = 'sales' into some other value (which we can't
>>>>>>> deduce from TrEmps alone)?
>>>>>>
>>>>>> According to the definition I gave this deletion is
>>>>>> well-defined. The unique "minimal" solution is that the
>>>>>> corresponding tuple is deleted from Emps, and indeed that
>>>>>> is all that the database knows for certain: this tuple has
>>>>>> to to be removed. I find this quite intuitive, can you
>>>>>> explain why you don't?
>>>>>
>>>>>Because if you update base table
>>>>>
>>>>>update Emps
>>>>>set dept = 'marketing'
>>>>>where dept = 'sales'
>>>>>
>>>>>the observed effect on TrEmps is deletion of a tuple.
>>>>
>>>> No, this is an illegal update because you are trying to insert
>>>> a tuple into a relation that cannot have such a tuple. This
>>>> makes sense because your view is your ontology so the only
>>>> thing that you can tell the database is that someone is no
>>>> longer with sales. It's the user with the marketing-view that
>>>> should tell the database that this employee is now with
>>>> marketing.
> > This would fail also if the employee only had visibility to marketing > information. The view would have to be qualified as dept='SALES' OR > dept='MARKETING' for a view update to be acceptable based on the > constant complement approach.
Yes, but I was not assuming the constant complement approach. In fact, I was trying to find out if there exists some theoretical justification for this approach. As a consequence I have to start without the assumption.
- Jan Hidders