Schema evolution is the support of schema changes during the lifetime of a Chimera application even if the database is already populated. Schema evolution for a data model as rich as Chimera is a complex task. In order to support a schema designer in the initial design as well as the further evolution of a schema, the Schema Evolution Assistant (SEA) had to be developed as an IDEA tool.
The schema designer interacts with the SEA using the graphical user interface of the Chimera Prototyping Tool (CPT/GUI) which provides a flexible means for intuitively handling even large and complex application schemas. The graphical user interface displays the class hierarchy of a Chimera schema, where the level of detail can be modified, e.g., by showing/hiding attributes, or by hiding entire (sub)trees of the hierarchy. For the further specification of a class, a class definition window offers the possibility to define all features of that class incrementally and interactively. The same interface is also used for the evolution of existing schemas. In both cases, the GUI informs the user about consequences of a schema change the user might not be aware of and might not intend to do. In such cases a dialogue may be entered in order to overcome the problem.
To perform such tasks, the SEA of course has to have access to the schema of the current application, and it has to reason about this schema and the results of schema changes in a hypothetical manner. Instead of tightly integrating the SEA with the underlying Chimera DBMS, which already has a schema management component itself, we originally decided to follow a reflective schema management approach for two reasons: First, providing the SEA with its own, external schema management facility increases the independence of SEA from a particular Chimera implementation. Second, using the Chimera DBMS itself for schema management immediately provides us with all advantages of an advanced data model and language, including facilities for browsing, integrity checking, and trigger execution.
This decision led to the development of the Reflective Schema Evolution Assistant. The experience we gained with the construction of a reflective schema evolution component was very positive up to a certain degree. Chimera turned out to be a very powerful means for structurally representing Chimera schemas, including the ability of using derived classes and derived attributes for implicit concepts (like, e.g., the derivation of redefined attributes, when the local attributes of each class are given), and the use of integrity constraints for checking the consistency of the represented application schema.
However, the actual Chimera specification and, consequently, our Chimera DBMS do not provide much support for the specification of procedures. Procedural code in operations and triggers is restricted to sequences of Chimera DML or external procedure calls, where only atomic values can be passed over to external procedures since there is no well-defined representation of Chimera objects in a host language, and of host-language terms in Chimera. Of course, these limitations could have been solved by either extending Chimera, or by extensively using external procedures to perform all non-trivial computations within the host language. The first solution however would have led to the abolishment of the unique platform of the IDEA project, the common data model and language. The second solution tends to make the advantages gained by the reflective representation of application schemas obsolete by introducing a huge overhead of data transmission and conversion, at the same time removing the elegance of the reflective approach.
We therefore decided to suspend our work on the Reflective Schema Evolution Assistant, realizing that this very powerful approach is still desirable but not reasonable with the Chimera model and system currently available.
Trying to keep the advantages of our reflective implementation, we designed a non-reflective Schema Evolution Assistant which uses some of the components originally written for the reflective version of the SEA, but uses the Chimera DBMS's data dictionary for schema representation instead of a reflective schema database. The organization of schema evolution into two phases as it could easily be realized with the reflective SEA due to the transaction concept provided by the DBMS was one of the advantages of the reflective SEA, allowing, for example, hypothetical schema reasoning. We therefore also designed the Non-Reflective SEA as working in two main phases, planning respectively executing schema evolution requests. During the planning phase, the user may be asked for missing information and for strategical decisions.
Both the Reflective and the Non-Reflective SEA are available as tools for use within our CPT. The results of our work on reflective schema evolution as well as the non-reflective Schema Evolution Assistant have been described in detail in our publications.