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

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

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.

First 50 documents

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