G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....used for instance in ORION [4] 3. Filtering: changes are never propagated: objects are assigned to different schema versions according to their semantics indeed used for instance in CLOSQL [21] 4. Hybrid: uses or combines two or more of the previous approaches used for instance in Sherpa [22] and O 2 [12] In any case, simple default mechanisms can be used or user supplied conversion functions must be defined for non trivial extant object updates. As far as complex schema changes are concerned, 20] considered sequences of schema change primitives to make up high level useful ....

G. T. Nguyen and D. Rieu. Schema Evolution in Object-oriented Database Systems. Data and Knowledge Engineering, 4:43--67, 1989.

....used for instance in ORION [2] 3. Filtering: changes are never propagated: objects are indeed assigned to different schema versions according to their semantics used for instance in CLOSQL [35] 4. Hybrid: uses or combines two or more of the previous approaches used for instance in Sherpa [36] and O [1] In any case, simple default mechanisms can be used, or user supplied conversion functions must be defined for non trivial extant object updates. The work [37] introduces an axiomatic model for change propagation which is capable of identifying in a declarative manner the set of objects ....

G. Nguyen, D. Rieu, Schema Evolution in Object-oriented Database Systems, Data and Knowledge Engineering 4 (1989) 43--67.

....to define and manipulate a nested object and all the objects it references directly or indirectly as a single unit (Kim et al., 1987) The concept of complex object has been proposed for that purpose. There are several different definitions of complex object (Atkinson et al., 1989; Kim et al., 1989; Nguyen and Rieu, 1989). Due to space limitations, we consider only the definition given in the Orion database 1. published in Proc. of the 7th International Conference on Systems Research Informatics and Cybernetics, Baden Baden, Germany, 1994. 2. This research was partially supported by the Swiss National Fund for ....

Nguyen G.T. and D. Rieu (1989); Schema evolution in object-oriented database systems; Data & Knowledge Engineering, 4 (pp. 43-67).

....of class based languages. Our findings, however, also apply to object oriented database programming languages based on Smalltalk. A concept closely related to roles is class migration. It refers to the change of the class of an object [9] Class migration is also important in schema evolution [18, 11, 2] if instances of an old version of a class must be migrated to a newer version. The remainder of the paper is organized as follows: We portray the characteristic features of the role concept in section 2. In section 3, we show that representing roles by ordinary class hierarchies is difficult. In ....

G.T. Nguyen and D. Rieu. Schema Evolution in Object-Oriented Database Systems, pages 43--67. North-Holland, 1989.

....may be added, and existing attributes may become obsolete. An important issue is that the DBS must be able to check and resolve inconsistencies due to schema changes dynamically, i.e. without database shutdown. The database services must be available during the reorganization of the database [Banerjee87, Nguyen89, Zicari91]. The reorganization of the database, i.e. of the stored data, to conform to the new schema can be achieved in three ways: a) conversion, i.e. the objects are immediately changed to follow the new schema, b) screening, i.e. the changes are deferred to the time when the data is accessed, and ....

G. Nguyen, D. Rieu; Schema evolution in object-oriented database systems; Data & Knowledge Engineering, Vol. 4, No. 1; Jul. 1989

....oriented database management systems is provided. The ORION project ( BKKK87] KBC 89] offers a more detailed taxonomy, together with a (semi formal) semantics of schema updates restricted to object oriented databases. The ORION system, together with the GemStone ( PS87] BMO 89] and Sherpa ( NR89] systems, are among the first object oriented database systems to support schema type evolution. In the Cocoon project ( Tre91] TS92] an approach to the evolution of schemas in object oriented databases is followed in which schema objects (e.g. object types) are considered to be objects like ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989. 36

....no clear definition associated with this term and it has been interpreted to mean different things by different researchers. While Kim [Kim90] treats versioning of 10 This example is an adaptation of a similar example in [KN88] schema for object management as schema evolution, Nguyen and Rieu [NR89] considers the various schema change operations and the associated consequences as being its main issues. Osborn [Osb89] gives some interesting perspectives on the consequences of the polymorphic constructs in object oriented databases and how this aids in avoiding code evolution. Our ....

Nguyen, G.T. and Rieu, D. Schema evolution in object-oriented database systems. Data and Knowledge Engg., North-Holland, 4:43--67, 1989.

....to the schematic information and contents of a database. It is a somewhat abused term in the database field, in that it has been interpreted to mean different things by different researchers. While Kim [24] treats versioning of schema for object management as schema evolution, Nguyen and Rieu [41] considers the various schema change operations and the associated consequences as being its main issues. Osborn [42] gives some interesting perspectives on the consequences of the polymorphic constructs in object oriented databases and how this aids in avoiding code evolution . An important ....

Nguyen, G.T. and Rieu, D. Schema Evolution in Object-oriented Database Systems. Data and Knowledge Engg., North-Holland, 4:43--67, 1989.

.... change propagation: ffl instance conversion, where instances must be transformed to fit into the modified type definition (see also [SZ86, SZ87, TK89, LH90] ffl object reclassification, where classification of objects must be reconsidered, according to changing class definition (cf. NR89a, NR89b] The above table gives an overview on which schema changes propagate to data objects. Instance conversion is necessary for those changes manipulating a type or the type lattice. As an example, consider again update U 1 . Instances of type person, that have been created before U 1 was executed, ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, North-Holland, 4(1):43--67, July 1989.

....address the problems that may arise when an object is created under one version of the class and is accessed through another version of that class. Consistency problems may occur when attributes or links are added or deleted. Work on schema evolution is reported in for instance [Ah 84] KiC88] NgR89] PeS87] and [SkZ87] Although the issue of schema evolution is outside the scope of this work, it seems that the mechanism of composite object representations and presentation description objects gives us attractive schema evolution features. It seems to give us the ability of updating objects ....

....20 The change in the composition means for strong connection, a change in a component, or deletion or addition of a component. For weak connection it means the deletion or addition of a component. 21 This way of working, i.e. delaying the updating until access time is called screening in [NgR89] in contrast to conversion where all updates occur immediately. The advantages of screening are performance and a limitation of the propagation of the changes. A disadvantage is the possibility of inconsistency between two accesses (see the end of this section) whether changes have been made ....

Nguyen, G.T., Rieu, D., `Schema Evolution in Object-Oriented Database Systems', in Data and Knowledge Engineering, Vol 4(1989), pp 43-67, 1989.

....and Object Versioning Due to the evolutionary nature of the design process, changes to the schema are more as a rule than an exception. As the design evolves, the schema evolves by changes to the class definition, changes to the class hierarchy and changes to the composite class hierarchy [Ban87][Ngu89]. As explained in the earlier section, versioning is an important requirement for design applications. Schema versioning refers to the creation of a new version based on changes to the hierarchical organization of the classes[Kim88] Class versioning refers to the creation of a new version of an ....

G.T. Nguyen and D. Rieu. Schema evolution in Object Oriented Database Systems. Data and Knowledge Engineering, Vol.4, No.1, pages 43-67, 1989

....about the resource the resolution unit issues a failure message. In this case, user servers keep track of failed queries to further increase their knowledge about other types of information. Any new database or user server joining a local schema will have the effect of evolving the local schema (Nguyen, 1989). Therefore, query failures work as a trigger for user servers to increase their knowledge about the space of information. This provides a dynamic way to increase their knowledge about information and the likelihood of a user query to be successful in the future. 7. Conclusion In this paper, we ....

....of type names, structure and behavior. One of the most important features of FINDIT is the flexibility and ease with which databases join and leave the system and organize themselves within the system. Extension is done either through class instantiation or schema evolution or both (Kim, 1988) (Nguyen, 1989), Banerjee, 1987) Usability is enhanced as the system will allow both expert and novice users to utilize FINDIT according to their level of knowledge. This means that, for instance, an expert user will not have to go through the same steps as a novice user would go through. Users, with minimal ....

G. T. Nguyen and D. Rieu, "Schema Evolution in Object-Oriented Database Systems," IEEE Data & Knowledge Engineering, pp. 43-67 (1989).

....allow software designers to retrieve schema objects at any time in their evolution histories. Concluding remarks and results of the paper are summarized in Section 6. 2 Related Work The issue of schema evolution has been an area of active research in the context of ODBMSs [BKKK87, KC88, PS87, NR89] In many of the previous work, the usual approach is to define a set of invariants that must be preserved over schema modifications. Changes to schema are corrective in that once the schema definitions are changed, the old definitions of the schema are no longer traceable. In TIGUKAT, a set of ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989. Submitted to the Sixteenth International Conference on Conceptual Modeling (ER'97).

....class hierarchies. Metadata may be manipulated by the object management services. As such, we may apply other services to metadata, such as versioning and archiving of metadata. The Metadata service provides control and maintenance of metadata. The study of metadata and its maintenance is ongoing [65]. Updating types and other forms of data model and schema evolution is a difficult problem. For example, what happens to existing instances of an altered entity type As new data models incorporating complex objects and versions are developed, so metadata research develops. Depending on the data ....

Nguyen G. T. and D. Rieu, Schema Evolution in Object-Oriented Database Systems, vol. 4, pp 43-67, North Holland, 1989.

....of acceptable logbooks. The logbook is intended as a structuring mechanism for initial specifications in the context of Snapshot Information Systems as well as Temporal Information Systems ( Sno90] Furthermore, it supports the development of Evolving Information Systems (e.g. PW95] Tre91] [NR89]) The history of a UoD may also be described by an application model history, such as introduced in [PW95] In this view, the evolution of a UoD is seen as the evolution of its elements. An element evolution describes the state of the element at each point of time. This dual vision on evolving ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989.

....to change propagation that maintains the semantics of properties between different versions of types. A downside of the approach is that defining handlers on various type versions can become confusing and unmanageable in systems with a large number of types that change often. Nguyen and Rieu [Nguyen and Rieu 1989] discuss schema evolution in the Sherpa model and compare their work to Encore, Gemstone, Orion, and one of their earlier models for CAD systems called Cadb. The emphasis of this work is to provide equal support for semantics of change and change propagation. The schema changes allowed in Sherpa ....

NGUYEN, G. AND RIEU, D. 1989. Schema Evolution in Object-Oriented Database Systems. Data & Knowledge Engineering 4, 43--67.

....for versioning types in Encore as a support mechanism for evolving type definitions. This work is focussed on dealing with change propagation rather than semantics of change. Their schema evolution operations are similar to Orion and, thus, representable by the axiomatic model. Nguyen and Rieu [4] discuss schema evolution in the Sherpa model and compare their work to Encore, GemStone, Orion, and their earlier model called Cadb. The emphasis of this work is to provide equal support for semantics of change and change propagation. The schema changes allowed in Sherpa follow those of Orion ....

G.T. Nguyen and D. Rieu. Schema Evolution in ObjectOriented Database Systems. Data & Knowledge Engineering, 4:43--67, 1989.

....especially if the data model uniformly treats everything as an object. Thus, query processing has to co exist with changes to the schema. Dynamic schema modification has been studied within the context of object oriented database systems. A comparative summary of this work is given in [NR89] which classsifies the types of shchema changes as follows: ffl changing class definitiions, i.e. instance variables or methods, ffl modifying the class lattice by changing the relationships between classes, and ffl adding or deleting classes in the lattice. The interaction of these changes ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, pages 43--67, 1989.

....It does not deal with data sharing problems between schema versions nor with programs compatibility. Thus, data redundancy may occur and old programs must be explicitly transformed by introducing the convenient time values in the old DB queries. Dynamic classi cation has been introduced in [10] to support incremental database schema design. In this approach an instance is dynamically related to a class and each class change can make instances migrate to other more relevant classes. Such an approach doesn t deal with schema versioning nor programs compatibility. In fact, managing several ....

G.T Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data and Knowledge Engineering, 4(1):4367, 1989.

....Instead of defining handlers on the various versions of types, pre existence and post existence implementations can be defined for the temporal behaviors on these types. These implementations can return, similar to Encore, a default value, a nil value, or generate an error. Nguyen and Rieu [NR89] discuss schema evolution in the Sherpa model and compare their work to Encore, Gemstone, Orion, and one of their earlier models for CAD systems called Cadb. The emphasis of this work is to provide equal support for evolving schema definitions and for propagating changes to instances. The schema ....

G.T. Nguyen and D. Rieu. Schema Evolution in Object-Oriented Database Systems. Data & Knowledge Engineering, 4:43--67, 1989.

....presentation description objects using other presentation description objects. 8 displayed as something . 9 The binding tables are also used for the resolution of links to particular versions. 10 This way of working, i.e. delaying the updating until access time is called screening in [20] in contrast to conversion where all updates occur immediately. The advantages of screening are performance and a limitation of the propagation of the changes. A disadvantage is the possibility of inconsistency between two accesses. 11 Currently, all components are version significant in the ....

G. T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data and Knowledge Engineering, 4:43--67, 1989.

....process. In Section 6, we show how the immediate object coercion is implemented in our approach. Concluding remarks and results of the paper are summarized in Section 7. 2 Related Work The issue of schema evolution has been an area of active research in the context of ODBMSs [BKKK87, KC88, PS87, NR89] In much of the previous work, the usual approach is to define a set of invariants that must be preserved over schema modifications in order to ensure consistency of the system. Orion [BKKK87, KC88] is the first system to introduce the invariants and rules approach as a more structured way of ....

....process and the added responsibility on the user are quite significant in CLOSQL. ffl Hybrid: A hybrid approach combines two or more of the above methods. GemStone mentions an effort to incorporate a hybrid approach, but currently we are unaware of such a system implementation. In Sherpa [NR89] schema changes are propagated to instances through conversion or screening, which is selected by the user. However, only the conversion approach is discussed. Change propagation is assisted by the notion of relevant classes. A relevant class is a semantically consistent partial definition of a ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989.

....allow software designers to retrieve schema objects at any time in their evolution histories. Concluding remarks and results of the paper are summarized in Section 6. 2 Related Work The issue of schema evolution has been an area of active research in the context of ODBMSs [BKKK87, KC88, PS87, NR89] In many of the previous work, the usual approach is to define a set of invariants that must be preserved over schema modifications in order to ensure consistency of the system. The Orion [BKKK87, KC88] model is the first system to introduce the invariants and rules approach as a more structured ....

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data

....may be added, and existing attributes may become obsolete. An important issue is that the DBS must be able to check and resolve inconsistencies due to schema changes dynamically, i.e. without database shutdown. The database services must be available during the reorganization of the database [Banerjee87, Nguyen89, Zicari91]. The reorganization of the database, i.e. of the stored data, to conform to the new schema can be achieved in three ways: a) conversion, implying the data being immediately changed, b) screening, i.e. the changes are deferred to the time when the data is accessed, and (c) schema versioning. ....

G. Nguyen, D. Rieu; Schema evolution in object-oriented database systems; Data & Knowledge Engineering, Vol. 4, No. 1; Jul. 1989

....applications because the definition of an adequate object structure, even prior to any valuation of its attributes, is what engineering design is all about. ARTIFICIAL INTELLIGENCE IN DESIGN 92 5 The support for incomplete and inconsistent objects is therefore the basis for object evolution (Nguyen, 1989). It is complemented by a classification mechanism and a migration facility. They both implement the assistance given to the designers when asking : To what object definition(s) does this partial design correspond best and Attach this partial design to the most suited existing definition(s) ....

....they belong may change. For example, my DC 3 used to belong to the Commercial aircraft class only. Being too old now, it has to migrate to the class Collection item. A similar requirement exists when the class graph is modified (Casais, 1990) This issue is often referred to as schema evolution (Nguyen, 1989). Should the designers require the addition or deletion of attributes in the classes or relationships between classes, the existing instances may be required to migrate because they do not conform to the new class definitions anymore. For example, if the concept of business aircraft evolves from ....

Nguyen G.T., Rieu D. 1989. Schema evolution in object-oriented database systems.

....the classes to which they belong may change. For example, my DC 3 used to belong to the Commercial aircraft class only. Being too old now, it has to migrate to the class Collection item. A similar requirement exists when the class graph is modified [5] This issue is often called schema evolution [20]. If the designers require the addition or deletion of attributes in the classes or relationships between classes, the existing instances may be required to migrate because they do not conform to the new class definitions anymore. For example, if the concept of business aircraft evolves from ....

Nguyen G.T., Rieu D. Schema evolution in object-oriented database systems. Data & Knowledge Engineering. North-Holland. 4(1).1989.

....work has shown however that instances cannot always be exact representatives of their classes [NGU91a, KOT88] They may bear distorsions with respect to the templates defined by the classes. They may also evolve and need to migrate from one class to another, because of changing values or structure [CAS90, KIM90, NGU89a]. Taking into account these observations, this paper relaxes some of the usual assumptions associated with existing instantiation mechanisms. It is assumed in the following that : an instance may be a representative of several classes simultaneously, an instance is not necessarily an exact ....

....instance X has three corresponding informations attached : a relevant structure, an inconsistency degree, an incompleteness degree. Informally, relevant structure are meaningful although partial definitions corresponding to incomplete objects that are allowed to belong to potential classes [NGU89a]. Each class C possesses a set of relevant structures which are generated automatically when the class is defined and modified. Each relevant structure represents a partial object definition. This is used to track object evolution. All instances are attached to exactly one relevant structure at ....

NGUYEN G.T., RIEU D. Schema evolution in object-oriented database systems. Data & Knowledge Engineering. North-Holland. Vol. 4. N°1. July 1989.

No context found.

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989.

No context found.

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43--67, 1989.

No context found.

G.T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data & Knowledge Engineering, 4:43-67, 1989.

No context found.

G. T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data and Knowledge Engineering, 4(1):43-67, July 1989.

No context found.

G.T. Nguyen and D. Rieu. Schema Evolution in Object-Oriented Database Systems. Data & Knowledge Engineering, (4):43--67, July 1989. 90] Erik Odberg et al. Preliminary Design of EPOSDB II, September 1990. Internal design document.

No context found.

G. T. Nguyen and D. Rieu. Schema evolution in object-oriented database systems. Data and Knowledge Engineering, 4(1):43-67, July 1989.

No context found.

Nguyen, G.T. and Rieu, D. Schema evolution in object-oriented database systems. Data Knowl. Eng., 4(1):43-67. 1989.

No context found.

Nguyen G.T. and Rieu D. #1989# Schema evolution in object-oriented database systems, Data and Knowledge Engineering, 4: 1989. pp. 43-67.

No context found.

G.T. NGuyen and D. Rieu. Schema evolution in object-oriented database systems. In Data and Knowledge Engineering, 1989.

No context found.

Nguyen, G.T. and Rieu, D. Schema evolution in object-oriented database systems. Data Knowl. Eng., 4(1):43-67. 1989.

No context found.

Nguyen, G.T. and Rieu, D. Schema evolution in object-oriented database systems. Data Knowl. Eng., 4(1):43-67. 1989.

No context found.

Nguyen G.T. and Rieu D. Schema Evolution in Object--Oriented Database Systems. IEEE Data & Knowledge Engineering, 4(1):43--67, 1989.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC