OEM views meeting   1/14/97   - Yue
Attendees: Serge, Jason, Roy, Yue.

*** We read Jason's writeup on view specification, which is a summary
of the Dec. 17 meeting.  We in general agreed on the basic view
definition language we had designed, with the syntax:

Select a database:     Open <Database or view name>
Define a view:         Define_View <View Name> View_def_queries End_Define
View_def_query format:
    Define <Name> := Select Select_Exp
                     [ From From_exp ]
                     [ Where Predicate ]
                     [ With Path_Exp ]

Note that we are restricting all path expressions that appear within 
the With clause in the following manner:  either every path expression
begins with a variable that is directly selected within the Select
clause, or the path expression must be an extension of a path expression 
appearing within the Select.  For example if "Frodos.Restaurant" 
is a path expression appearing within the Select then 
"Frodos.Restaurant.Entree" would be a valid With clause path expression.

---

*** We decide to move on to the the next issue: how to "implement a view".

There are 3 basic options:
  1.  Materialized Fully
  2.  Materialized on demand
  3.  Virtual 

Overview of each:

  1.  Materialized Fully

  This is perhaps the easiest to implement.  The real problem comes
  when you consider maintenance in the face of modifications to the
  data.  

  2.  Materialized on demand

  The update problem present in #1 is also present here.  Although
  in this case instead of updating the view, we can simply "mark"
  the object as being "out of synch".  This synch property will always
  relate to the object's value, but it will indicate very 
  different things when the object is atomic versus complex.  

  An added complexity of the materialized on demand scheme is the 
  overhead inherent in storing information about what has been
  fetched about every object within the view.  

  3.  Virtual

  At this time it is not clear whether it is possible to rewrite a 
  query in terms of our view specification in the general case.  
  A counterexample of this will probably surface very quickly.  It
  will then be interesting to note for which queries and view
  specifications it will work.

---

We then spent a fair amount of time on how a materialized scheme
would be implemented.  Here is a summary: 

The most straightforward to implement a view is to materialize the
entire view according to the view definition. Later queries asked to
the view can be evaluated on the materialized copy of the view, which
is an ordinary OEM database.

Here are the general issues and concepts that need to be added 
to a DBMS:

 1. There need to be multiple work space: at least one for the base 
    database and one for the view
 2. There need to be a way to relate the view objects to base objects. 
    This is necessary because a view may be defined by multiple 
    view queries, and results from later queries need to be 
    'merged' with results from previous queries such that the 
    same object only appears once in the view. This can be done 
    by using some 'mapping table' between OIDs. 

    Alternatively each object could have an annotation which specifies
    the OID of the object within the source database.  This is very
    similar to the work that Chaw is doing and has the advantage that
    all data will remain in "clean" OEM format.  Disadvantages 
    include all those that Chaw is facing.

 3. A new module that interprets the query results will need to be 
    written.  This module will handle the evaluation of the 
    With clause..

The general steps involved in answering a view specification are:
 1. Evaluate the 'From clause' and 'Where clause', this gives 
    us a set of nodes that should appear in the view. 
    Let this set be X.
 2. Independently, 
    2.1 Evaluate the 'Select clause'. This may involve 
        the construction of new oem nodes and labels. 
        The result is an oem graph with nodes in X as 
        leaf nodes.  
    2.2 Evaluate the 'With clause'. The result is an oem 
        graph with nodes in X as 'roots'.
 3. Merge the resulting graph from 2.1 and 2.2.

Note that each object which appears within the source database and
will appear within the view needs to be created anew within the
view workspace and a mapping must be added to the table between
the newly created object and its mate within the source database.

---

The final issue that we just barely touched on is what sort of properties
would need to be proven about Lorel and our view specification language
in order to support a virtual view.  That is, what basic tools do we
need in order to rewrite a query so that the query would only touch data 
elements described by the view.

The ultimate problem that we face is the following:
Given a query Q on the view V, how to rewrite the query into a 
new query Q' on the base database DB, 
such that
   Q'( DB ) = Q( V( DB )) for all possible DB.

A simpler first step is maybe to solve the following question:
Give two Lorel queries Q1, Q2, how to find a third query Q3 
such that for all DB, 
   Q3( DB ) = Q1( Q2( DB ))