Change schema components

HECATAEUS (Papastefanatos et al. 2010) focuses on the dependencies between schema components and artifacts such as views and queries. Recall that commercial systems have tight restrictions on schema evolution when dependencies exist one cannot drop a column from a table if a view has been created that references that table. Using HECATAEUS, the developer is given fine-grained control over when to propagate schema changes to an object to the queries, statements, and views that depend on it. 

Planning knowledge is especially critical for problems containing multiple situations and/or multiple unknowns. It is by means of this knowledge that the solver determines the priority with which he or she addresses each situation. Thus, for the Change situation, if more than one component of the mental model is unknown, the plans must shift to include a search for another situation (or a repetition of the current one) that will allow determination of one of the missing elements. This may necessitate, of course, a call to one of the other schemas. 

The primary instructional objective for SPS is to assist students in creating schemas that are based on the five situations described in detail in chapter 3 Change, Group, Compare, Restate, and Vary. My purpose in developing SPS was to construct a series of lessons that reflected the basic knowledge components of a set of schemas, that allowed direct assessment of those components, and that resulted in students creation of the specified schemas. 

The evolution of XML schemas is easier than for relational schemas since the schemas can be extended by optional components that do not invalidate existing instances. Due to the absence of a standard schema modification language, schema changes are usually specified by providing a new version of the schema. In research approaches, schema matching and mapping techniques are being used... 

---