Re: Setting up updatable views ?

On Oct 4, 1:21 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Oct 2, 9:29 am, Cimode <cim..._at_hotmail.com> wrote:
>
> > While working on a db core on these last years, one of the question
> > that gave me most difficulty was what would be an efficient taxonomy
> > to list prequisites for a system to support updateable views. I would
> > be happy to exchange on that subject.
>
> View updatability is a very interesting area imo. Perhaps you would
> like to offer your initial thoughts?

Sure...A little history to clarify the viewpoint...Some years ago, I started coding an assembler db core that would respect as much as possible the fundamental principle of independence between logical and physical layer as defined in RM. The purpose of that effort was to identify some computing (non fundamental) issues that would be faced by any developper that would attempt to develop a trdbms...

The primary serious issue I faced was to attempt to establish a computing model that would *coherently* support the concept of unique tuple identification *without* using directly physical pointers. The idea was to establish a *logical* solution to the problem of how a tuple could be identified within a given domain of value or a specific relation. At that point, I used some trigonometrics to establish mathematical functions that establish *discernability* over elements in a degree N relation. I started first with a degree 2 relation tuple that I reduced to a single numeric value. Then, that function could allow to uniquely identify that specific tuple and that tuple only single value (in fact, it could reestablish the identifiers of the 2 value of each separate attributes within their respective domain). I later attempted to determine a manthematical function that would allow a generalization of the property of discernability to a degree N relation tuple.

For testing such solution and making sure it does not have aspects I have not thought of, I started imagining a test scenario that would reveal the limits of such solution through how it would be (or not be) practical to allow the support of view updates in a system. So I started focusing on establishing a taxonomy of requirements that would allow view updates. So here's the taxonomy I came up with so far:

> Identification requirements: all requirements that a computing model should meet in terms of how such system establishes discernability between tuples to support efficiently view updates.
> Predictability requirements: all requirements that a computing model should meet to allow *predictable* updates. In such requirements, I usually ask myself question such as: how ought a grouped query ought to handle to be updated and how would it give a result that would be reasonnable and coherent to understanding.
> Concurrency requirements: all requirements that a computing model should meet to allow comit/rollback principle over view operations. Here I ask my self questions such as : can we apply a 2 phase commit model to hadle concurrency?

So far I have focused onto answering the first part and here is what I came up with:

Identification requirements

> The identifier value for a specific tuple is not a part of the physical layer
> The identifier is the output of a mathematical function that allows to identify a point.
> The above output ought to reestablish the identifiers of all attribute values into there respective domains
> The identifier of a specific tuple is a stable mathematical function of the identifier of such tuple in the domain from which the relation draws tuples.
> The identifier should be a numerical value that may allow not only to identify the tuple within the relation but also with the domain.
> The identifier should be established at run time or at compile time.

I really hope this makes sense. I find it more and more difficult to use online media to precisely explain what I am getting at. Received on Thu Oct 04 2007 - 13:21:11 CEST