A formal model of views for object‐oriented database systems

Abstract

The deenition of a view mechanism is an important issue for object-oriented database systems, in order to provide a number of features that are crucial for the development of advanced applications. Due to the complexity of the data model, the object-oriented paradigm introduces new problems in the deenition of a view mechanism. Several approaches have been deened, each deening a particular view mechanism tailored to a set of functionalities that the view mechanism should support. In particular, views can be used as shorthand in queries, can support the deenition of external schemas, can be used for content-dependent authorization , and, nally, can support some form of schema evolution. In this paper, we f o rmally introduce a view model for object-oriented databases. Our view model is comparable to existing view models for what concerns the supported features; however, our model is the only one for which a formal deenition is given. This formal deeni-tion of object-oriented view mechanisms is useful both for understanding what views are and as a basis for further investigations on view properties. The paper introduces the model, discussing all the supported features both from a theoretical and practical point of view. A comparison of our model with other models is also presented.

A Methodology to Define External Schemas in ODMG Databases

“…In [12,15], a mechanism to define external schemas is proposed. It is based on the derived class definition mechanism proposed in [29], which allows the definition of derived classes with object generating semantics.…”

“…The semantics of the derivation relationship is 'it has been defined (derived) from'. The derivation relationship is also used in other mechanisms [14,15], but they extend the object-oriented paradigm to define a new dimension (derivation dimension). This extension allows the use of derivation relationship in user schemas.…”

“…The UNDEFINE ES <name> [AND NOT USED] operation deletes from the repository the external schema name; optionally, if the parameter AND NOT USED is specified, all derived classes defined for the schema name that are not being used in other schemas are also deleted. This is an optional feature because the schema definer may want to preserve derived classes that are not used in other schemas as shorthand in queries [15] or to be included in new external schemas.…”

“…With respect to the second problem (the lack of mechanisms to define external schemas) much work has been carried out in order to provide OODBs with this functionality [11,12,13,14,15,16,17,18,19,20,21]. These works propose solutions to define external schemas, although they differ in their approach and in the object model used.…”

Consistent schema version removal: an optimization technique for object-oriented views

“…Systems that enable interoperability for multiple software applications in dynamic environments must allow applications to evolve and flexibly change their data requirements, while minimizing or even eliminating the impact of such change on other existing applications. Several approaches [3,11,15,17,18] have been proposed to support schema evolution and/or data integration needs by using object-oriented views. Nevertheless, these approaches run into a potential problem of generating a large number of schema versions over time resulting in an excessive build-up of classes and underlying object instances, not all being necessarily still in use.…”