| B. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. TODS, 25(1):83--127, 2000. |
....state from one version to the next. This thesis will explain how TFs interact with SOs to ensure that nodes upgrade to the correct new state. This thesis will not attempt to automate the generation of transform functions or simulation objects, although previous work suggests that this is possible [24, 30, 45]. The rest of the proposal is organized as follows. Section 2 presents our upgrade model and assumptions. Section 3 describes the upgrade infrastructure, and Section 4 introduces an upgrade example. Section 5 describes scheduling functions; Section 6, simulation objects; and Section 7, transform ....
....the old version s state. TFs may also call methods of the new version on other nodes. However, a TF cannot depend on these calls succeeding, since they may be simulated on the remote node and so may fail due to simulation limitations. Previous systems provide tools to generate TFs automatically [24, 30, 45]. We believe such tools can be useful to generate simple TFs and SOs, but creating complex TFs and SOs will require human assistance. Notation TF v denotes a transform function that produces the state for a version v class from the state of a version v 1 class (the specific classes are ....
[Article contains additional citation context not shown here]
B. S. Lerner. A model for compound type changes encountered in schema evolution. ACM Transactions on Database Systems, 25(1), 2000.
....on state recovery to restore it. This requires that state transfer work correctly between nodes running different versions (e.g. using SOs) and that the scheduling function allow enough time between node upgrades for state transfer. Previous systems provide tools to generate TFs automatically [16, 20, 27]. We believe such tools can be useful to generate simple TFs and SOs, but creating complex TFs and SOs will require human assistance. 7 Correctness Criteria This section presents informal correctness criteria for simulation objects. We describe the criteria in the context of a node running ....
B. S. Lerner. A model for compound type changes encountered in schema evolution. ACM Transactions on Database Systems, 25(1), 2000.
....knowledge model for ontologies: We must add operations that deal with changes in slot restrictions, with slot attachment, and so on. The second cause is the use of composite operations which few researchers in the schema evolution community have addressed (with the notable exception of Lerner [17]) Consider for example a change in the domain of a slot from a class to its superclass. Our model for tra#c connections in Amsterdam may have used a slot speed limit only for roads. To change the domain of the speed limit slot to include thoroughfares (both roads and canals) we need to move ....
Lerner, B.S., A Model for Compound Type Changes Encountered in Schema Evolution. ACM Transactions on Database Systems, 2000. 25(1): p. 83-127.
....with schema updates. A remarkable advantage of this approach is that it is based on a formal notion of consistency, which provides the user with a decidable static consistency checking mechanism to validate the schema and extant data modifications. A completely different approach is taken in [39], where algorithms were devised to analyse complex type changes by comparing two schema versions and accordingly derive transformation rules that can applied to propagate the changes to extant objects. The work done by the research group(s) led by Elke A. Rundensteiner deserves a separate mention, ....
B. Staudt Lerner, A Model for Compound Type Changes Encountered in Schema Evolution, ACM Transactions on Database Systems 25 (1) (2000) 83--127.
....for RDB or OODB today [20, 35, 30, 36] provide support for the re structuring of the application schema by means of a fixed set of simple evolution primitives, as does our XEM system. Recent work has been done to focus on the issues of supporting more complex schema evolution operations for OODBs [4, 24]. These allow the user to string together several primitives to form higher level yet still specific change transformations. Finally, SERF [12, 11] is a template based, extensible schema evolution framework developed at WPI that allows complex user defined schema transformations in a flexible yet ....
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....for RDB or OODB today [20, 35, 30, 36] provide support for the re structuring of the application schema by means of a fixed set of simple evolution primitives, as does our XEM system. Recent work has been done to focus on the issues of supporting more complex schema evolution operations for OODBs [4, 24]. These allow the user to string together several primitives to form higher level yet still specific change transformations. Finally, SERF [12, 11] is a template based, extensible schema evolution framework developed at WPI that allows complex user defined schema transformations in a flexible yet ....
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
.... this, most object oriented database systems (OODB) today support a pre defined taxonomy of simple fixed semantic schema evolution operations [BKKK87, Tec94, BMO 89, Inc93, Obj93] More advanced changes such as combining two types have also recently been looked at by Breche [Bre96] and Lerner [Ler96] but are still limited to being a fixed set. Anything beyond the fixed taxonomy often requires Copyright 1999 IEEE. Personal use of this material is permitted. However, permission to reprint republish this material for advertising or promotional purposes or for creating new collective works for ....
.... schema evolution to a predefined set of simple schema evolution operations with fixed semantics [BKKK87, Tec94, BMO 89, Inc93, Obj93] With the SERF framework we can now offer arbitrary user customized and possibly very complex schema evolution operations such as merge, inline and split [Ler96, Bre96] without users having to resort to writing ad hoc code. Moreover, for each transformation type itself there can be many different semantics based on user preferences and application needs. For example two classes can be merged by doing a union, an intersection or a difference of their ....
[Article contains additional citation context not shown here]
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....and O 2 [Tec94] all essentially handle a similar set of xed evolution primitives; though based on their own respective object models. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Both Breche and Lerner [Br e96, Ler96] have investigated the issue of complex operations. Lerner [Ler96] has introduced compound type changes in a software environment, i.e. focusing on type and not on object instance changes. The SERF framework [CJR98b] presents a exible way of doing transformations by means of a re usable, ....
....primitives; though based on their own respective object models. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Both Breche and Lerner [Br e96, Ler96] have investigated the issue of complex operations. Lerner [Ler96] has introduced compound type changes in a software environment, i.e. focusing on type and not on object instance changes. The SERF framework [CJR98b] presents a exible way of doing transformations by means of a re usable, parameterized SERF template. However, none of these systems provide any ....
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....or even impossible to achieve with the current commercial database technology [Tec94, BOS91, IS93, Inc93] In fact, it typically requires the user to write throw away programs to accomplish these. Research has been done recently towards providing evolution support for such complex changes [Br e96, Ler96] However, this new work is again limited to providing a fixed set of now more complex operations with fixed semantics. The provision of any fixed set, may it be simple or complex, is not satisfactory, as it would be very difficult for any one user or system to pre define all possible semantics ....
....as Itasca [IS93] GemStone [BOS91] ObjectStore [Inc93] and O 2 [Tec94] all essentially handle a set of evolution primitives based on their own object models. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Br e96, Ler96, Cla92] have investigated the issue of more complex operations. Ler96] has introduced compound type changes in a software environment, i.e. focusing on the type and not on the object instance changes. She provides compound type changes like Inline, Encapsulate, Merge, Move, Duplicate, Reverse ....
[Article contains additional citation context not shown here]
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....research. Linguistic reflection is an extremely powerful approach to type evolution. It remains to be seen how easy it is for software engineers to use reflection in specifying highly generic programs that may be reused in many contexts. A system that does identify type changes is Tess [Ler94, Ler96] Given two sets of type definitions, one representing a newer version of the other, Tess compares the type definitions to identify corresponding types and to define mappings that transform instances of those types from the old representation to the new. The type comparison algorithms currently ....
....Tess compares the type definitions to identify corresponding types and to define mappings that transform instances of those types from the old representation to the new. The type comparison algorithms currently implemented in Tess compare types based upon the structures of those types. In [Ler96] the author suggests that other algorithms that rely on type signatures and formal specification [ZW95a, ZW95b] may improve speed. DRASTIC may be able to utilise this approach to automate the generation of change absorbers. 8.7 Related Work Summary Many groups are addressing the issue of ....
B. Staudt Lerner. A model for compound type changes encountered in schema evolution. Technical Report UM-CS-1996-044, Computer Science Department, University of Massachusetts at Amherst, 1996.
....are very difficult or even impossible to achieve with the current commercial database technology [18, 3, 9, 8] In fact, it typically requires the user to write throw away programs to accomplish these. Research has been done recently towards providing evolution support for such complex changes [2, 13]. However, this new work is again limited to providing a fixed set of now more complex operations with fixed semantics. The provision of any fixed set, may it be simple or complex, is not satisfactory, as it would be very difficult for any one user or system to pre define all possible semantics ....
....[8] and O 2 [18] all essentially handle a similar set of fixed evolution primitives; though based on their own respective object models. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Both Breche and Lerner [2, 13] have investigated the issue of more complex operations. Lerner [13] has introduced compound type changes in a software environment, i.e. focusing on the type and not on the object instance changes. She provides compound type changes like Inline, Encapsulate, Merge, etc. Breche [2] proposed a ....
[Article contains additional citation context not shown here]
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....with the current commercial database technology [KGBW90, Tec94, BMO 89, IS93, Inc93] In fact, most OODBs would typically require the user to write ad hoc programs to accomplish such transformations. In the last two years, research has begun to look into this issue of complex changes [Br e96, Ler96] However, this new work is again limited by providing a fixed set of some selected ( even if now more complex) operations. The provision of any fixed set, may it be simple or complex, is not satisfactory, as it would be very difficult for any one user or system to pre define all possible ....
....such as Itasca [IS93] GemStone [BMO 89] ObjectStore [Inc93] and O2 [Tec94] all essentially handle a set of evolution primitives similar to Orion s. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Br e96, Ler96, Cla92] have investigated the issue of more complex operations. Ler96] has introduced compound type changes in a software environment, i.e. focusing on the type and not on the object instance changes. She provides compound type changes like Inline, Encapsulate, Merge, Move, Duplicate, Reverse ....
[Article contains additional citation context not shown here]
B.S. Lerner. A model for compound type changes encountered in schema evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....it must always be possible to access the original form, subject to appropriate authorisation. Many researchers have investigated the support of evolution in object oriented database systems [Andany et al. 1991, Coen Porsini et al. 1991, Bratsberg, 1993, Ferrandina et al. 1995, Odberg, 1995, Lerner, 1996, Roddick et al. 1996] They address such problems as adding and deleting class definitions in an existing populated database, and modifying definitions by adding, removing, altering and moving class attributes. Method definitions and any stored queries may have to be altered to accommodate the ....
Lerner, B.S. (1996) A Model for Compound Type Changes Encountered in Schema Evolution.
....best of our knowledge has not been explicitly addressed by any current research or commercial OODB system. Advanced Schema Evolution. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Both Breche and Lerner [Br e96, Ler96] have investigated the issue of more complex operations. Lerner [Ler96] has introduced compound type changes in a software environment, i.e. focusing on the type and not on the object instance changes. She provides compound type changes like Inline, Encapsulate, Merge, etc. Breche [Br e96] ....
....research or commercial OODB system. Advanced Schema Evolution. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Both Breche and Lerner [Br e96, Ler96] have investigated the issue of more complex operations. Lerner [Ler96] has introduced compound type changes in a software environment, i.e. focusing on the type and not on the object instance changes. She provides compound type changes like Inline, Encapsulate, Merge, etc. Breche [Br e96] proposed a similar list of complex evolution operations for O 2 , i.e. now ....
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....with the current commercial database technology [KGBW90, Tec94, BOS91, IS93, Inc93] In fact, most OODBs would typically require the user to write ad hoc programs to accomplish such transformations. In the last two years, research has begun to look into this issue of complex changes [Br e96, Ler96] However, this new work is again limited by providing a fixed set of some selected now more complex operations. The provision of any fixed set, may it be simple or complex, is not satisfactory, as it would be very difficult for any one user or system to pre define all possible semantics and all ....
....OODBs such as Itasca [IS93] GemStone [BOS91] ObjectStore [Inc93] and O 2 [Tec94] all essentially handle a set of evolution primitives similar to Orion s. In recent years, the advent of more advanced applications has led to the need for support of complex schema evolution operations. Br e96, Ler96, Cla92] have investigated the issue of more complex operations. Ler96] has introduced compound type changes in a software environment, i.e. focusing on the type and not on the object instance changes. She provides compound type changes like Inline, Encapsulate, Merge, Move, Duplicate, Reverse ....
[Article contains additional citation context not shown here]
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
....changes to the database schema. Other systems such as Itasca [Inc93] provide a graphical user interface (GUI) that allows the users to specify their schema changes graphically while the system again propagates the schema changes to the database. Other systems such as O 2 [Tec94, Br e96] TESS [Ler96] and SERF [CJR98b] all deal with more advanced schema changes, such as merging of two classes, which are often composed of a sequence of schema evolution primitives. All of these systems deal with applying not a single schema change but a sequence of schema changes to the underlying database. ....
....deferred mechanism by offering time savings as the queried set of objects and the number of schema evolution operations to be applied on it grows larger. In recent years, research has begun to focus on the issues of supporting more complex schema evolution operations. Breche and Lerner [Br e96, Ler96] studied the design of a set of more complex operations. Lerner [Ler96] has proposed compound type changes like Inline, Encapsulate, Merge etc. but more from the aspect of discovering the transformation sequences to map between these given two schemas. Lastly, our previous work on SERF [CJR98b] ....
[Article contains additional citation context not shown here]
B.S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report UM-CS-96-044, University of Massachusetts, Amherst, Computer Science Department, 1996.
No context found.
B. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. TODS, 25(1):83--127, 2000.
No context found.
B. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. TODS, 25(1):83--127, 2000.
No context found.
Lerner, B.S. (2000). A Model for Compound Type Changes Encountered in Schema Evolution.
No context found.
B. S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. ACM TODS, 25(1):83--127, March 2000.
No context found.
B. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. Technical Report 96-044, Computer Science Department, University of Massachusettes, 1996.
No context found.
B. S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. ACM TODS, 25(1):83--127, March 2000.
No context found.
B.Staudt Lerner. A model for compound type changes encountered in schema evolution. ACM TODS 25(1), 2000, 83-127
No context found.
B. S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. ACM TODS, 25(1):83--127, March 2000.
No context found.
B. S. Lerner. A Model for Compound Type Changes Encountered in Schema Evolution. ACM TODS, 25(1):83--127, March 2000.
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