Relational schema evolution

For the rest of this section, we first consider the current state of the art in relational database systems regarding their support for schema evolution. We examine their language, tool, and scenario support. We then consider recent research revelations in support for relational schema evolution. Finally, we use Table 6.1 to summarize the schema evolution support of the considered approaches w.r.t. requirements introduced in Sect. 2. 

Table 6.1 Characteristics of systems for relational schema evolution...

Schema evolution is the ability to change deployed schemas, i.e., metadata structures formally describing complex artifacts such as databases, messages, application programs, or workflows. Typical schemas thus include relational database schemas, conceptual ER or UML models, ontologies, XML schemas, software interfaces, and workflow specifications. Obviously, the need for schema evolution occurs very often in order to deal with new or changed requirements, to correct deficiencies in the current schemas, to cope with new insights in a domain, or to migrate to a new platform.

To provide an overview about the current state of the art and recent research results on schema evolution in three areas relational database schemas, XML schemas, and ontologies. For each kind of schema, we outline how and to what degree the introduced requirements are served by existing approaches. 

While we cover more than 20 recent implementations and proposals, there are many more approaches that can be evaluated in a similar way than we do in this chapter. We refer the reader to the online bibliography on schema evolution under http // se-pubs.dbs.uni-leipzig.de (Rahm and Bernstein 2006) for additional related work. Book chapter 7 (Fagin et al. 2011) complements our paper by focusing on recent work on mapping composition and inversion that support the evolution of schema mappings. 

Powerful schema evolution infrastructure The comprehensive support for schema evolution discussed before requires a set of powerful and easily usable tools, in particular to determine the impact of intended changes, to specify incremental changes, to determine Diff evolution mappings, and to perform the specified changes on the schemas, instances, mappings, and related schemas. 

Relational database systems, both open-source and proprietary, rely on the DDL statements from SQL (CREATE, DROP, and ALTER) to perform schema evolution, though the exact dialect may vary from system to system (Tiirker 2000). So, to add an integer-valued column C to a table T, one uses the following syntax ... 

PRISM (Curino et al. 2008) is a tool that is part of a larger project called Panta Rhei, a joint project between UCLA, UC San Diego, and Politecnico di Milano investigating schema evolution tools. The PRISM tool is one product of that joint venture that focuses on relational evolution with two primary goals allow the user to specify schema evolution with more semantic clarity and data preservation and grant multiple versions of the same application concurrent access to the same data. 

Native XML databases, unlike relational systems, are built from the ground up to support XML storage. Relatively few of these systems support XML schemas or schema evolution. One notable exception is Tamino (Software AG 2006). 

There are several differences between ontologies and relational schemas that influence their evolution ... 

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... 

Chandra AK, Merlin PM (1977) Optimal implementation of conjunctive queries in relational data bases. In ACM symposium on theory of computing (STOC). ACM, NY, pp 77-90 Curino C, Moon HJ, Zaniolo C (2008) Graceful database schema evolution The PRISM workbench. PVLDB 1(1) 761—772... 

In Sect. 2, we introduce the main requirements for effective schema and ontology evolution. Sections 3 and 4 deal with the evolution of relational database schemas and of XML schemas, respectively. In Sect. 5, we outline proposed approaches for ontology evolution and conclude in Sect. 6. 

Each individual change to a DTD induces a change on all valid documents to maintain document validity. For instance, if one adds a new required element or changes the quantifier on an element so that it becomes required, XEM will automatically add a default element to all instances that lack the element. Note that this evolution scheme takes a relational approach to evolution in the sense that all instances must evolve to match the new schema rather than allowing documents to belong to multiple versions simultaneously. 

Temporal XML Schema (Currim et al. 2009) - also referred to as xXSchema -is a way to formalize the temporal nature of schema and document versioning. The framework is assembled by the same research group that helped develop the temporal extensions to SQL. In all other frameworks discussed to date, the relationship between versions of schemas and documents are informal if they exist at all two versions of the same schema version are considered to be two separate schemas, related to each other only by whatever point-in-time script was used to perform the migration. xXSchcma makes evolution over time a first-class concept, modeling different versions of the same conventional XML schema in the same document. 

Let us assume that the target schema evolves to a new schema T consisting of one relation Takes that combines all the attributes in T (i.e., sid, ma j or, course) and further includes an extra grade attribute. Moreover, assume that the evolution mapping from T to T is ... 

Let us now assume that the source schema evolves to a new schema S" consisting of the two relations Takes" and Course shown in Fig. 7.2. Thus, in the new schema, courses are stored in a separate relation and are assigned ids (cid). The relation Takes" is similar to Takes except that course is replaced by cid. Let us assume that the source evolution is described by the following LAV mapping ... 

Thus, in the new schema, the relation Manager of T is intended to be a copy of the relation Reports of T, while the relation Sel fMgr is intended to contain all employees who are their own managers, that is, employees for which the eid field equals the mgr field in the relation Reports of T. Note that the evolution mapping M is a GAV mapping. 

Assume now that the target schema evolves to a new schema T that consists of a single relation Takes that keeps the association between sid, name, and course, while dropping the major. The target evolution can be described by the following mapping ... 

---