Area of Interest: A main focus of my research is to build a database system supporting materialized views. Such a system stores the computed result of the view (i.e., derived data) to speed-up queries on it. Most previous research in this area has focused on algorithms for view maintenance (i.e., re-establishment of view consistency), with limited attention to implementation issues. While many strengths and weaknesses of materialized views can be learned by a view maintenance implementation, an overall solution to implementation involves more than just high-level algorithms; it requires fundamental results from the database disciplines. Many questions arise in this context. What are the techniques for efficiently computing the information that the view maintenance algorithms require? When are materialized views maintained? Are they maintained before the transaction that updates the base table commits, or after the transaction commits? Are the developed techniques applicable to object-oriented databases?
Recent Progress: Together with colleagues at Columbia University and Bell Laboratories, the effort to realize maintenance of materialized view on the Ode object-oriented database has resulted in one of the first view maintenance prototypes in the world. The contributions include a model that allows multiple views in the layers to be maintained with different maintenance policies---immediate, deferred, and snapshot, as well as techniques for minimizing the overhead of maintaining the auxiliary information required for view maintenance. We have also formalized the concurrency control problem in systems supporting materialized views, and developed a serializability theory based upon conflicts and serialization graphs. Presently I am extending further the implementation to support concurrency.
Possible Extensions: There are a number of interesting directions to proceed. For instance, we can relax consistency of a system by allowing view read transactions to see a limited amount of inconsistency. Strict serializability on the view read transactions is often too restrictive for a range of time-critical applications such as banking and billing on the Web. The question of practical feasibility remains unclear whether it is possible to apply several proposed extended transaction models to realize this. How can we define the inconsistency tolerance for materialized views? Furthermore, we may be able to extend materialized views to support strong resilience by allowing the database to have erroneous data, typically accumulated silently until discovered. Today's database systems usually provide a declarative way to define the explicit constraints, to guard against the intrusion of inconsistent data. The system envisioned is to work to stabilize or transform such inconsistencies into the acceptable (materialized view) states after finding them in the database.