S. Monk and I. Sommerville. Schema evolution in OODBs using class versioning. ACM SIGMOD Record, 22(3):16--22, 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... changes divergent changes Figure 3: Convergent versus divergent parallel changes Such versioning mechanisms have been extensively used for schema evolution in object oriented databases in order to support forward and backward compatibility of applications with schemas and existing objects [31, 36, 39]. The previous discussion refers to the ability to create and to deploy di#erent versions of a component. We will now classify the di#erent kinds of versioning, and the mechanisms needed to support them. Software changes may be carried out sequentially or in parallel (see Fig. 2) With ....

....a transition phase [11] not only need dynamic checks to ensure consistency: They also need some form of monitoring which is capable of mediating between the two versions actively. Object database systems, for example, provide mechanisms for adapting instances across historical schema changes e.g. [45, 31, 41, 14]. 7 2.4 Change Support (how) During a software change, various support mechanisms can be provided. These mechanisms help us to analyze, manage, control, implement or measure software changes. The proposed mechanisms can be very diverse: automated solutions, informal techniques, formal ....

S. Monk and I. Sommerville. Schema evolution in OODBs using class versioning. ACM SIGMOD Record, 22(3):16--22, 1993.

....one for every converted instance. A similar approach, also known as screening (which looks most consistent when it is combined with schema versioning or object versioning, that preserves and allows to access various versions of objects) was implemented in a number of systems, e.g. CLOSQL [MS92, MS93, Mon93] and ORION [BKKK87, Ban87, KC88] We consider this approach too expensive and therefore impractical, since it means that a large amount of information (fields deleted in the course of evolution or even all of the old versions of each evolving instance) has to be kept in the database ....

....a separate image of instance for each class version or by keeping one version specific copy of the instance and dynamically converting it every time it is accessed using a different class version) depends on the concrete system. Examples of systems implementing class versioning are CLOSQL [MS92, MS93, Mon93] and POET [POE00] Schema versioning, which allows several versions of one logical schema to co exist simultaneously. Similar to the previous approach, instances can be represented in multiple ways to confirm to a specific schema version. Schema versioning has been explored in e.g. the ....

[Article contains additional citation context not shown here]

S. Monk and I. Sommerville. Schema Evolution in OODBs Using Class Versioning. ACM SIGMOD Record, 22(3):16--22, September 1993.

....where both components and aspects reside in a database. The appropriate components and aspects are retrieved by the assembling process which carries out the weaving. 2. 2 Instance Adaptation during Class Versioning The second example is based on instance adaptation during class versioning [3, 14, 20] in object oriented databases. Class versioning allows several versions of one type to be created during evolution. An instance is bound to a specific version of the type and when accessed using another type version (or a common type interface) is either converted or made to exhibit a compatible ....

....(or a common type interface) is either converted or made to exhibit a compatible interface. This is termed as instance adaptation and is essential to ensure structural consistency. A detailed description of class versioning is beyond the scope of this paper. Interested readers are referred to [3, 14, 20]. The following discussion demonstrates that the instance adaptation code cross cuts the class versions and can be separated using aspects. It should be noted that the instance adaptation aspects cross cut persistent entities (the class versions) and are persistent by nature. a) b) c) Legend ....

[Article contains additional citation context not shown here]

Monk, S. & Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

....are proposed. Section 4 discusses the basic alternatives of how to implement them. 2. Object evolution caused by maintenance Taking a look at object evolution, two communities can be distinguished. The database community, investigating the evolution of object oriented database schemas (e.g.[1, 11, 2]) and the software engineering community investigating the evolution of object (class ) hierarchies during the development process (e.g. 7, 8] In software engineering, the end of the development process marks also the end of the examination of the objects evolution (or history) However this ....

S. Monk and I. Sommerville. Schema Evolution in OODBs Using Class Versioning. SIGMOD RECORD, 22(3):16--22, 1993.

....channels are proposed as a mechanism to support these maintenance operations. Then possible realizations of service channels and their purpose are discussed using an illustrative example. 2. Maintenance operations on objects 2.1. Object model evolution As outlined in [17] object evolution [1, 18, 4, 12, 13] is usually investigatied during the development process. But in contrast to object evolution during development, object evolution in the maintenance phase mostly happens just on the implementation level. Hence, the initial object model is becoming less and less a documentation or specification of ....

S. Monk and I. Sommerville. Schema evolution in oodbs using class versioning. SIGMOD RECORD, 22(3):16--22, 1993.

....systems (OODBS) process centered software engineering environments and workflow management. Workflow schema evolution is similar to schema evolution in OODBS in that schema modifications of OODBS should be supported in the presence of instances (objects) without requiring a system shut down. In [13] and [16] class versioning is used for schema evolution in OODBS. However, the problem of migrating objects (in OODBS) and the problem of migrating workflows (in WFMS) differ significantly. For instance, when workflows are to be migrated, in contrast to objects, their execution histories have to ....

S. Monk and I. Sommerville. Schema Evolution in OODBs using Class Versioning. SIGMOD Record, 22(3), September 1993.

....policies for different application requirements. The elements of the DCDO solution are not necessarily unique and fundamentally different from existing techniques to solve related problems. In particular, the model and implementation uses ideas from schema evolution in object oriented databases [6, 7, 8, 19, 22, 54, 55, 56, 62, 63, 64], and from Microsoft s Component Object Model [15, 26, 53] However, these approaches were not designed for distributed object computing systems, which impose different constraints and challenges. High level designs appropriate for this environment have not yet been developed to take advantage of ....

....an evolution operation removes an attribute from a class, new instances of that class will not contain storage space for that attribute, and application programs bound to a previous version of the class cannot retrieve from a new instance anything but a default value defined by a handler. CLOSQL [54, 55] is an OODBMS that gives programmers more control over how instances are converted from one version to the next, and more flexibility in converting instances to different versions of their type. CLOSQL implements class versioning, and allows programmers to associate update and backdate functions ....

Monk, S., Sommerville, I., "Schema evolution in OODBs using class versioning," SIGMOD Record, vol. 22, no. 3, pp. 16-22, September 1993.

....[Ra Rundensteiner, 1995] In the system proposed here, partially derived classes can be defined with non derived elements in the intension as well as in the extension of the class. Other papers on schema evolution [Skarra Zdonik, 1986; Andany et al. 1991; Tresch, 1991; Tresch Scholl, 1992; Monk Sommerville, 1993; Brche et al. 1995; Ferrandina et al. 1995] offer such mechanisms as lazy conversion, or class or schema versioning, with elements common to the derivation relationship; but they do not offer the possibilities that derived and partially derived class definition affords. 113 In order to avoid ....

S. Monk, Y. Sommerville, "Schema Evolution in OODBs Using Class Versioning," SIGMOD Record, vol. 22, no. 3, pp. 16-22, September 1993.

....Existing systems use two approaches to provide versioning mechanism. In the first one [SG94] CJ90] Kat90] the versioning mechanism is applied only to objects and not to the database schema. In the second one, the versioning mechanism is applied either to separate classes, TK89] TOC93] [MS93], or to sets of classes [SZ86] ALP91] or to the entire schema [BKKK87] The objects stored in the schema instance have versions associated with their class versions. Both approaches are not satisfactory since they provide no solution to manage together versions of the schema and versions of the ....

S. Monk and I. Sommerville. Schema Evolution in OODBs Using Class Versioning. In SIGMOD RECORD, Vol. 22, No. 3, pages 16--22, 1993.

....Orion [5] GemStone [30] OTGen [20] and O 2 [13] support class modification, where a single version of a database schema is changed, and the contents of the database are updated to LEWIS GRIMSHAW DYNAMICALLY CONFIGURABLE DISTRIBUTED OBJECTS 3 reflect the change. Encore [31] CLOSQL [26], and Clamen s system [11] support class versioning, in which multiple versions of a single class co exist, and the systems implement various strategies for updating the rest of the database, including class instances. These approaches offer excellent guidelines for evolving distributed objects, ....

Monk, S., Sommerville, I., "Schema evolution in OODBs using class versioning," SIGMOD Record, vol. 22, no. 3, pp. 16-22, September 1993.

.... coercing between representation as of different versions of a class. Substitute functions may be defined between consecutive and non consecutive class versions, and the approach provides some abilities to restrict the complete compatibility between versions of a class if desired. CLOSQL [5, 14] is similar, having update backdate functions to define coercion procedures (in both directions) between consecutive versions (in a linear chain) of the same class. Dynamically, objects are coerced along the chain from the creation version to the referenced class version. Encore [4] defines a ....

Simon Monk and Ian Sommerville. Schema Evolution in OODBs using Class Versioning. SIGMOD Record, 22(3):16--22, September 1993.

....to dynamically changing a database schema. Schema evolution ( BKKK87, MSOP86, LH90, BBB 88, Bar91, TS92] systems tend to focus on how changes to the schema are described and ways of ensuring that changes do not invalidate the database contents. Versioning approaches ( BB88, SZ86, Zdo90, MS93, Cla92, Bra93] focus on how to allow multiple versions of an object to co exist at run time. The most obvious similarity between such database systems and DRASTIC is that a process booted over a DRASTIC platform with a persistent store must be able to access the state in the store after any ....

S. Monk and I. Sommerville. Schema Evolution in OODBs using Class Versioning. SIGMOD Record, 22(3):16--22, September 1993.

....technique is used for object adaptation [4] All existing objects must be converted to objects fitting class definitions in the new schema. The main drawback of this approach, is the incompatibility of old programs w.r.t the new schema when conversion occurs. ffl In a versioning based approach [11, 3, 5, 7, 12], a schema update induces the derivation of new versions of classes or a schema. Old programs can continue to interact with (old or new) objects in the database using the old schema, which has been retained. In this case, two techniques of object adaptation are provided in the literature: ....

....of classes or a schema. Old programs can continue to interact with (old or new) objects in the database using the old schema, which has been retained. In this case, two techniques of object adaptation are provided in the literature: emulation and object versioning. 1. In the first technique [7, 12], an object is associated to the version of a class under which it is created. The representation of an object is never restructured after its creation. The system is responsible for assuring access to old and new objects by programs. Since properties are never deleted, a program will always ....

Monk, S. and Sommerville, I. Schema Evolution in OODBs Using Class Versioning. SIGMOD RECORD, 22(3), Sept. 1993.

....Michigan Faculty Award Program, and the NSF NYI grant #IRI 9457609. than expected [11] but also because typical OODB application areas such CAD CAM and multimedia information systems are not well understood and require frequent schema changes. Thus, there is active research on schema evolution [3, 12, 21, 9, 22]. However, even with the schema evolution support currently provided in most OODBs, schema updates on shared OODBs are problematic and thus generally avoided. This is because in a typical environment, a developer must consult with others to determine the impact of a desired schema change on the ....

....at schema compilation, in cases when detectable, and let the user resolve it. 5 Related Research The continued support of old programs when performing schema evolution has been recognized as a key issue in the literature [9, 20] Some systems such as such as Encore [20] Orion [9] and CLOSQL [12] use more traditional versioning concepts rather than the view approach. They typically construct new versions of the schema as well as of the object instances, with instances being assigned to the schema version under which they have been created. This approach inevitably confines the scope of a ....

S. Monk and I. Sommerville, " Schema Evolution in OODBs Using Class Versioning," in SIGMOD RECORD, VOL. 22, NO.3, pp. 16--22, September 1993.

....We demonstrate the feasibility of our solution by presenting general algorithms for hard schema changes as well as primitive ones. 1 Introduction Schema evolution has been recognized as a very important functionality of OODBs required by many advanced engineering and scientific applications [1, 7, 12, 4, 13]. In spite of schema evolution support provided by most OODBs, schema updates on shared databases remain problematic. This is because in a shared user environment, a desired schema change is likely to impact other programs. In current OODBs, schema update capabilities are hence more limited by ....

....to query is present, the values of object identifiers are updated. 4 Hard Schema Change Operators 4. 1 Introduction The taxonomy of base schema evolution operators first introduced by Banerjee et al. 1] for Orion has been adopted in most other schema evolution research and commercial OODBs [11, 3, 7]. To demonstrate the feasibility of TSE, it is thus important to show that our approach can realize this set of schema change operations in a transparent fashion. In addition to handling transparently these primitive (soft) schema evolution operators, TSE also supports several complex operators ....

[Article contains additional citation context not shown here]

S. Monk and I. Sommerville. Schema evolution in OODBs using class versioning. SIGMOD RECORD, VOL. 22, NO.3, September 1993.

....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 existing class definition[Mon93]. An object is stated as versioned when it changes its state, i.e. the attribute values are changed. The version derivation hierarchy can be expressed in a version hierarchy graph. y : 20 x : 10 A1 y : 20 x : 10 A1 A2 x : 20 y : 30 modify Design Attribute : x A1 A2 (b) a) A new Design ....

S. Monk and I. Sommerville. Schema Evolution in OODBs using Class Versioning. SIGMOD RECORD, Vol.22, No.3, pages 16-22, September 1993

.... to define a number of invariants that must be satisfied by the schema and then to define rules for maintaining these invariants (e.g. 3] 3] The techniques for the realization of schema evolution functionality include direct implementations, views (e.g. 35] 35] and versions (e.g. 19] [25]) 19, 25] 32] 32] proposes an axiomatic model to provide a common framework for different schema evolution policies. All of these typically support the schema change taxonomy initially proposed for ORION [3] 3] Whereas we focus on the real time aspects of schema evolution, in addition to ....

.... a number of invariants that must be satisfied by the schema and then to define rules for maintaining these invariants (e.g. 3] 3] The techniques for the realization of schema evolution functionality include direct implementations, views (e.g. 35] 35] and versions (e.g. 19] 25] [19, 25]) 32] 32] proposes an axiomatic model to provide a common framework for different schema evolution policies. All of these typically support the schema change taxonomy initially proposed for ORION [3] 3] Whereas we focus on the real time aspects of schema evolution, in addition to the ....

S. Monk, and I. Sommerville, "Schema Evolution in OODBs Using Class Versioning," SIGMOD Record, Vol. 22, No. 3, September 1993, pp. 16-22.

....if objects are coerced to a newer schema definition, historical queries can be run by giving an appropriate time point in the history of the object. To overcome the corrective nature of schema evolution, the concept of schema versioning in ODBMSs has been proposed [SZ86, SZ87, KC88, ALP91, MS92, MS93] In most of these systems, a change to a schema object may result in a new version of the schema object, or the schema in general. However, schema changes are usually of a finer granularity than definable versions. This implies that not every schema change should necessarily result in a new ....

Simon Monk and Ian Sommerville. Schema Evolution in OODBs using Class Versioning. ACM SIGMOD Record, 22(3):16--22, September 1993.

....The necessary data conversions and program modifications may be expensive due to factors such as a requirement to shutdown the system, programmer effort, machine resources, etc. However, research on schema evolution is emerging (Banerjee et al. 1987, Skarra Zdonik 1987, Lerner Habermann 1990, Monk Sommerville 1993). Work on quantifying the extent and form of schema evolution will be described in Section 4. 3 Software Maintenance Tools Tools for managing change in information systems can broadly be divided into those supporting project management (Section 3.1) and those supporting implementation (Section ....

Monk, S. & Sommerville, I. (1993). "Schema Evolution in OODBs Using Class Versioning". SIGMOD Record, Vol. 22, No. 3, pp. 16--22.

.... invariants that must be satisfied by the schema and then to define rules for maintaining these invariants (e.g. 3] To avoid expensive changes to existing applications dependent on the original schema, researchers studied other approaches such as object oriented views [35, 36, 44] and versions [19, 25]. 32] proposes an axiomatic model to provide a common framework for defining and comparing different schema evolution policies. All of these typically support the schema change taxonomy initially proposed for ORION [3] In this paper, we focus instead on the real time aspects of schema evolution, ....

S. Monk, and I. Sommerville, "Schema Evolution in OODBs Using Class Versioning," SIGMOD Record, Vol. 22, No. 3, September 1993, pp. 16-22.

....data is shared by different views of the schema, i.e. both old as well as newly developed applications can continue to interoperate. In this paper, we present examples that demonstrate our approach. 1 Introduction Schema evolution is an important issue in Object Oriented Database (OODB) research [1, 7, 8, 18, 4, 19], not only because data models are less stable than expected [6] but also because typical OODB application areas such as CAD CAM and multimedia information systems are not well understood and require frequent schema changes. However, even with the schema evolution support by most OODBs, schema ....

....prototype. Our TSE system successfully addresses all these issues [10] 5 Algorithms for Realizing Schema Changes in TSE 5. 1 Introduction The taxonomy of base schema evolution operators first introduced by Banerjee et al. 4] for Orion has been adopted in most other schema evolution research [17, 3, 8, 7]. In fact, most commercial OODB systems such as O2 [19] and GemStone [9] only support a subset of this taxonomy. To demonstrate the feasibility of the TSE approach, it is thus important to show that our approach can realize this set of schema change operations. We have developed a complete set of ....

[Article contains additional citation context not shown here]

S. Monk and I. Sommerville, "Schema Evolution in OODBs Using Class Versioning," in SIGMOD RECORD, VOL. 22, NO.3, pp. 16--22, September 1993.

....off. A drawback of the proposal is that no automatic composition of handlers can be done to compute transitive conversions. Therefore, the introduction of a new type version requires the specification of handlers for all existing type versions, not only for one. Monk and Summerville [MS92, MS93] introduce class versioning to support schema evolution. The versions of a class are derived from each other in a linear sequence, along which instances can be converted from old to new schema versions (using update functions) and vice versa (using backdate functions) In this way, also ....

Simon Monk and Ian Sommerville. Schema Evolution in OODBs Using Class Versioning. SIGMOD Record, 22(3):16--22, September 1993.

....about 59 of attributes are changed on the average. In summary, schema evolution is a pervasive problem in many large systems, and there certainly is a need for the capability of managing the evolution of a schema without any service interruption [25] There is active research on schema evolution [4, 2, 10, 14, 11, 15, 29, 8, 31, 32]. Most work focuses on the modification of a database schema and the corresponding migration of database instances from the old to the modified schema. However, this direct change on the schema may modify existing views and the application programs written against the views can no longer run. ....

....for Realizing Schema Changes in the TSE System One of the first object oriented schema change approaches has been proposed by Banerjee et al. 8] for the ORION data model. Note that this taxonomy, adopted in most other schema evolution research for OODBs such as Encore [27] Goose [7, 11] CLOSQL [15], Rose [14] OTGen [10] and COCOON [30] still corresponds to the most frequently used set of schema changes. In fact, most commercial OODB systems such as O 2 [31] and GemStone [16] only support a subset of this taxonomy. To demonstrate the feasibility of the TSE approach, it is thus important to ....

[Article contains additional citation context not shown here]

S. Monk and I. Sommerville, " Schema Evolution in OODBs Using Class Versioning," in SIGMOD RECORD, VOL. 22, NO.3, September 1993.

.... coercing between representation as of different versions of a class. Substitute functions may be defined between consecutive and non consecutive class versions, and the approach provides some abilities to restrict the complete compatibility between versions of a class if desired. CLOSQL [MS92, MS93] is similar, having update backdate functions to define coercion procedures in both directions between consecutive versions of the same class. Dynamically, objects are coerced along the chain from the creation version to the referenced class version. Encore [SZ87] defines a notion of a version ....

Simon Monk and Ian Sommerville. Schema Evolution in OODBs using Class Versioning. SIGMOD RECORD, 22(3):16--22, September 1993.

.... a temporal dispatch algorithm to demonstrate that no new concepts need to be added to the schema evolution model to solve the temporal dispatch To overcome the corrective nature of schema evolution, the concept of schema versioning in ODBMSs has been proposed [SZ86, SZ87, KC88, ALP91, MS92, MS93] In most of these systems, a change to a schema object may result in a new version of the schema object, or the schema in general. However, schema changes are usually of a finer granularity than definable versions. This implies that not every schema change should necessarily result in a new ....

S. Monk and I. Sommerville. Schema Evolution in OODBs using Class Versioning. ACM SIGMOD Record, 22(3):16--22, September 1993.

....at the time the schema change was made. Should the need subsequently arise to access the instance from version 2, the instance can be changed back into an instance of version 2 using the update method of version 1 of the class definition. For further detail on dynamic instance conversion see [MonkSom93]. CLOSQL also implements a system for supporting schema evolution first developed in the ENCORE system [SkaZdon86] In this mechanism a version set interface (VSI) is created for the set of versions of each class definition. As well as containing class versions, the VSI also contains exception ....

Monk, S R and I Sommerville. Schema Evolution in OODBs Using Class Versioning. SIGMOD Record 22 (3). 16-22. 1993.

No context found.

S. Monk and I. Sommerville. Schema evolution in OODBs using class versioning. ACM SIGMOD Record, 22(3):16--22, 1993.

No context found.

S. Monk. Schema Evolution in OODBs Using Class Versioning. SIGMOD RECORD, 22(3), 1993.

No context found.

Monk, S.---Sommerville, I.: Schema evolution in OODBs using class versioning. SIGMOD RECORD, Vol. 22, 1993, No. 3, pp. 16--22.

No context found.

Monk, S. and Sommerville, I., Schema Evolution in OODBs Using Class Versioning. ACM SIGMOD Record, 1993, 22(3): p. 16-22.

No context found.

Simon Monk and Ian Sommerville. Schema evolution in OODBs using class versioning. SIGMOD Record, 22(3):16-22, September 1993.

No context found.

Simon Monk and Ian Sommerville. Schema Evolution in OODBs using Class Versioning. SIGMOD Record, 22(3):16--22, September 1993.

No context found.

S. Monk and I. Sommerville, "Schema Evolution in OODBs Using Class Versioning", ACM SIGMOD Record, Vol. 22, No. 3, pp. 16-22, 1993.

No context found.

S. Monk and I. Sommerville, "Schema Evolution in OODBs Using Class Versioning", ACM SIGMOD Record, Vol. 22, No. 3, pp. 16-22, 1993.

No context found.

Monk, S., Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

: S. Monk, I. Sommerville, Schema Evolution in OODBs Using Class Versioning, SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Monk, S. & Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, 22(3), Sept. 1993, pp. 16-22

No context found.

Monk, S., Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Simon Monk and Ian Sommerville. Schema evolution in OODBs using class versioning. SIGMOD Record, 22(3):16-22, September 1993.

No context found.

Monk, S., Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Monk, S. & Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Monk, S.R. and Sommerville, I. Schema evolution in OODBs using class versioning. SIGMOD Rec., 22(3):16-22. 1993.

No context found.

MONK S., SOMMERVILLE I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Monk, S. and Sommerville, I., Schema Evolution in OODBs Using Class Versioning. ACM SIGMOD Record, 1993, 22(3): p. 16-22.

No context found.

Monk, S. & Sommerville, I.: Schema Evolution in OODBs Using Class Versioning. SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Monk, S. & Sommerville, I., "Schema Evolution in OODBs Using Class Versioning", SIGMOD Record, Vol. 22, No. 3, Sept. 1993, pp. 16-22

No context found.

Monk, S., Sommerville, I.: Schema Evolution in OODBs Using Class Versioning. SIGMOD RECORD 22 (1993)

No context found.

Monk S. and Sommerville I. #1993# Schema evolution in OODBS using class versioning, SIGMOD RECORD, 22#3#, Sep. 1993. pp. 16-22.

No context found.

Monk, S.R. and Sommerville, I. Schema evolution in OODBs using class versioning. SIGMOD Rec., 22(3):16-22. 1993.

No context found.

Monk, S.R. and Sommerville, I. Schema evolution in OODBs using class versioning. SIGMOD Rec., 22(3):16-22. 1993.

First 50 documents  Next 50

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