Schema Evolution publication categorizer

We introduce a protocol for schema evolution in a globally distributed database management system with shared data, stateless servers, and no global membership. Our protocol is asynchronous--it allows different servers in the database system to transition to a new schema at different times--and online--all servers can access and update all data during a schema change. We provide a formal model for determining the correctness of schema changes under these conditions, and we demonstrate that many common schema changes can cause anomalies and database corruption.

The Extract-Transform-Load (ETL) flows are essential for the success of a data warehouse and the business intelligence and decision support mechanisms that are attached to it. During both the ETL design phase and the entire ETL lifecycle, the ETL architect needs to design and improve an ETL design in a way that satisfies both performance and correctness guarantees and often, she has to choose among various alternative designs.

Mappings between different representations of data are the essential building blocks for
many information integration tasks. A schema mapping is a high-level specification
of the relationship between two schemas, and represents a useful abstraction that specifies
how the data from a source format can be transformed into a target format. The development
of schema mappings is laborious and time-consuming, even in the presence of tools that facilitate
this development. At the same time, schema evolution inevitably causes the invalidation of

Schema evolution is the increasingly important ability to adapt deployed schemas to changing requirements. Effective support for schema evolution is challenging since schema changes may have to be propagated, correctly and efficiently, to instance data and dependent schemas, mappings, or applications.

Schema evolution is an unavoidable consequence of the application development lifecycle. The two primary schemas in an application, the conceptual model and the persistent database model, must co-evolve or risk quality, stability, and maintainability issues. We study application-driven scenarios, where the conceptual model changes and the database and mapping must evolve in kind. We present a technique that, in most cases, allows those evolutions to progress automatically. We treat the mapping as data, and mine that data for patterns.

Schema evolution is an unavoidable consequence of the application development lifecycle. The two primary schemas in an application, the client conceptual object model and the persistent database model, must co-evolve or risk quality, stability, and maintainability issues. We present MoDEF, an extension to Visual Studio that supports automatic evolution of object-relational mapping artifacts in the Microsoft Entity Framework.

Large, mission critical applications built on Oracle Database 11g Release 1 and earlier
versions are often unavailable for tens of hours while the application’s database objects
are patched or upgraded. Oracle Database 11g Release 2 introduces edition-based
redefinition, a revolutionary new capability that allows online application upgrade with
uninterrupted availability of the application. When the installation of the upgrade is
complete, the pre-upgrade application and the post-upgrade application can be used at

The problem of archiving and querying the history of a database is made more complex by the fact that, along with the database content, the database schema also evolves with time.

The administrators and designers of modern Information Systems face the problem of maintaining their systems in the presence of frequently occurring changes in any counterpart of it. In other words, when a change occurs in any point of the system –e.g., source, schema, view, software construct– they should propagate the change in all the involved parts of the system.

Databases are continuously evolving environments, where design constructs are added, removed or updated rather often. Research has extensively dealt with the problem of database evolution. Nevertheless, problems arise with existing queries and applications, mainly due to the fact that, in most cases, their role as integral parts of the environment is not given the proper attention. Furthermore, the queries are not designed to handle database evolution. In this paper, we introduce a graph-based model that uniformly captures relations, views, constraints and queries.

Traditional modeling techniques typically focus on the static part of databases and ignore their dynamic part (e.g., queries or data-centric workflows). In this paper, we first introduce and sketch a graph-based model that that uniformly captures relations, views, constraints and queries. We then present Hecataeus, a tool for implementing and visualizing the above framework

Schema evolution poses serious challenges in historical data management. Traditionally the archival data has been (i) either migrated under the current schema version, to ease querying, but compromising archival quality, or (ii) maintained under the original schema version in which they firstly appeared, leading to a perfect archival quality, but to a taxing query interface.

Among other issues, database evolution includes the necessity of propagating the changes inside and between abstraction levels. There exist several mechanisms in order to carry out propagations from one level to another, that are distinguished on the basis of when and how the changes are performed. The strict mechanism, which implies the immediate realization of modifications, is a time–consuming process. In this paper we propose a solution that is closer to the lazy and logical mechanisms, in which changes are delayed or not finally realized, respectively.

DEMO PAPER:

Modern information systems, and web information systems in particular, are faced with frequent database schema changes, which generate the necessity to manage such evolution and preserve their history.

The life of a modern Information System is often characterized by (i) a push toward integration with other systems, and (ii) the evolution of its data management core in response to continuously changing application requirements. Most of the current proposals dealing with these issues from a database perspective rely on the formal notions of mapping and query rewriting.

The old problem of managing the history of database information is now made more urgent and complex by fast-spreading web information systems. Indeed, systems such as Wikipedia are faced with the challenge of managing the history of their databases in the face of intense database schema evolution. Our PRIMA system addresses this difficult problem by introducing two key pieces of new technology.

Given a multirelational database scheme and a relational mapping f transforming it, an important question is whether the resulting scheme is equivalent to the original one. This question was addressed in the literature with respect to those relational schemes that satisfy the so called universal relation assumption; however, no study was ever concerned with multirelational (data base) schemes that do not necessarily satisfy this assumption.We present two general definitions of lossless transformation of the database scheme based on the so-called closed world and open world assumptions.

Bancilhon and Spyratos [l] show how the choice of a complementary view will
select a view update translator. They claim that “User requirements impose [the
constraint that] . . . (ii) The user must have the means to cancel, if he wishes,
the effect of every update that he is allowed on the view.” (p. 562) If this
requirement is eliminated, there are other reasonable translations that become
acceptable. We present a particular view update translator that is quite reasonable,
but that does not preserve any complement, and for which the requirement
does not hold.

A temporal data warehouse can be defined as a set V of materialized views over non-temporal sources. We present a self-maintainable temporal data warehouse that, besides a set of temporal views V, has two kinds of auxiliary views: a set T of auxiliary relations containing only temporal information necessary to maintain the data warehouse and a set C of complements allowing the warehouse maintenance without consulting the source databases.

Abstract. One of the most severe problems related to database evolution
is how to reflect in the data level the changes that have occurred
in the conceptual schema of a database. This is specially relevant when
evolution operations affect ISA relationships. In this paper we present
our view of the evolution of ISA relationships, focusing on the artifacts
that generate the sentences for changing the data in a consistent way.

n temporal databases, transaction time and valid time are added to the data. In this context, the modification of the schema which a database management system (DBMS) can undergo during its lifetime, known as schema changes, must develop into the higher concept of scheme evolution. Changes to the schema produce versions of previous schemas along both time axes and these versions must be maintained and managed during the whole database life. An overview on the issues of temporal relational databases and relational schema changes is presented.

There is much current interest in publishing and viewing databases as XML documents. The general benefits of this approach follow from the popularity of XML and the tool set available for visualizing and processing information encoded in this universal standard. In this paper, we explore the additional and unique benefits achieved by this approach on temporal database applications. We show that XML views combined with XQuery can provide surprisingly effective solutions to the problem of supporting historical queries on past content of database relations and their evolution.

Telecom Databases need very high availability for
both read and write transactions. Thus it is desired that
not even schema changes are allowed to block any type
of transactions. We show in this paper a method to handle
schema changes which is based on a transaction oriented
change with the aid of triggers. The old and the
new schema can be used concurrently so it is never necessary
to block any transactions.
A nice feature of the method presented in this paper
is that it is easy to integrate into an already existing
DBMS.
This functionality is rarely, if ever, found in neither

The days when a company could take its system offline for any kind of maintenance are rapidly disappearing. As businesses become global and move toward e-commerce, systems now have to be highly available because the cost of outage for corporations involved in e-commerce can easily reach millions of dollars per hour. Today, it is unlikely that the customer will come back if your systems are unavailable, they will simply give that business to your competitor whose systems are online.