Skarra A H and Zdonik S B, Type Evolution in an Object-Oriented Database, in: Research Directions in Object-Oriented Programming, ed. B. Shiver, and P. Wenger, (MIT Press Series in computer Systems 1987) 393-415.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....16 end; 17 end; 18 return; 19 end; 20 end; 21 endtype TransExample Fig.6.4. An example of a transaction for the type Machine updates. 7. Related works In the area of object oriented databases, class modifications have been extensively studied in the recent literature [Bane 87] Penn 87] Skar 87] and [Delc 91] The available methods determine the consequences of class changes on other classes and on the existing instances, so that possible violations of the integrity constraints can be avoided. These approaches deal mainly with sequential systems and have focused on preserving only ....

A. H. Skarra and S. B. Zdonik, Type evolution in an Object-Oriented Databases, Research directions in object-oriented programming, Eds. Peter Wegner and Bruce Shriver, MIT press, pp.393-415.

.... systems are not the only systems faced with problems of structure conversions; similar problems arise in other areas such as programming languages, structure oriented programming environments (Gandalf [Garlan86] Centaur [Borras88] Synthesizer Generator [Reps89] and object oriented databases [Skara87] . In most of these areas, type conversions are based on explicit specifications of the desired transformations [ISO95] Synthesizer Generator [Reps89] uses transformation declarations , SIMON [Feng93] is based on an extension of attributes grammars, Centaur is based on another extension of ....

A. H. Skara, S. B. Zdonik, "Type Evolution in an Object-Oriented Database", Research and Directions in Object Oriented Systems, B. Shriver and P. Wagner, ed., MIT Press, September 1987.

....an object of one type version to another, rules for keeping the type graph consistent and for converting existing objects to correspond to the new graph, or a set of operations to be applied to objects and types whenever structure differences exist. The versioning approach is used in 5 [Bor85, SZ87] Methods associate a set of error handlers with the different versions of a type, either focusing on instance level variations or on type level changes. 3.3 Structured documents The methods for document transformations are usually suitable for a specific definition of a document representation ....

A.H. Skarra and S.B. Zdonik. Type evolution in an object-oriented database. In B. Shriver and P. Wegner, editors, Research Directions in Object-Oriented Programming, pages 393--416. The MIT Press, Cambridge, Massachusetts, 1987.

....of the schema at the physical level. Firstly, the complete schema can be converted to a new version as in Orion [19, 21, 22] This method, while being conceptually simple, prohibits the parallel schema versions required in some application environments. The approach of Skarra and Zdonik in Encore [23 25] is to version at class level and thus permit parallel changes as long as they are in different classes. Secondly, Kim and Chou [26] and later Andany, Leonard and Palisser [13] present a system whereby views (or contexts) are constructed and schema evolution is achieved through view creation. ....

A.H. Skarra and S.B. Zdonik, "Type evolution in an object-oriented database", in Research directions in object-oriented programming, Shriver, B., (ed.) Cambridge, MA: MIT Press, pp. 393-416, 1987.

....take to bring existing objects in line with a modified class. There are mainly two approaches [42] screening and conversion. Screening is to defer (possibly indefinitely) modifying instances. The values are either filtered or corrected before they are used. Several systems adopt this approach [41, 60]. Conversion is to require with each schema change that all instances be converted to the new class definition immediately after the change. Converting an instance means new attributes may be added into the object with default values and other attributes may be deleted from the object according to ....

....one logical schema for one common database and present different views of the database through different versions of the schema. Although there is a considerable amount of work in single schema modification, there are only a few works on the semantics and implementation of schema versioning (e.g. [40, 60]) There are two shortcomings to single schema modification. One is that it does not allow the history of modification of objects to be preserved. For example if an attribute of a class is dropped, the values of the attribute in existing instances are irretrievably lost; even if the attribute is ....

[Article contains additional citation context not shown here]

A.H. Skarra and S.B. Zdonik. Type evolution in an object-oriented database. In B. Shriver and P. Wegner, editors, Research Directions in Object-Oriented Programming, pages 393--413, MIT Press, 1987.

....a subtype. Our rationale for dispensing with types and instances in the description of engineering data is very similar to that of Demaid and Zucker [3] Our model also resembles the hybrid model in [9] If parent objects are regarded as types, it is also possible to talk about type evolution [2,7] in our model. Object T in Figure5 represents a type, which declares attributes a and b, while object X represents an instance of this type. Now we want to create a new version of type T, called T2, in which attribute b is deleted and a new attribute c is added. Then we also want to change ....

....have T as the parent. Of course, this mechanism does not solve the type evolution problem. It, however, gives us the handle to deal with the problems in a meaningful way. We are developing the model mainly as a data representation for configuration processes. Therefore, unlike Skarra and Zdonik [7], we have not addressed the problem of application programs that must access instances of one version of a type as if they were instances of another version of the type. 3 Composite Objects Configurations are represented as composite objects, which have other objects as components. We make a ....

Skarra, A.H., and S.B.Zdonik. "Type Evolution in an Object-Oriented Database". In B.Shiver and P.Wegner, editors, Directions in Object-Oriented Programming, pages393--415. MIT Press 1988.

....to the instances. One either includes a data migration utility to adapt existing data objects to the changed schema, or an other mechanism (screening, versioning) has to ensure consistency between data and structure. An early investigation of type changes in populated databases exists for ENCORE [26]. This work addresses the effects of type changes to objects and to programs that use objects of the type. The impact of type polymorphism on schema evolution is investigated in [18] The first systematic analysis of desirable schema evolution possibilities was done for the ORION data model [2, ....

....that the same situation shows between the meta schema level and the schema level as well. new definition (e.g. ORION [3] and (ii) type versioning is a strategy where a new version of a type is created whenever a type is modified. Instances created after the change, belong to the new version [26, 1], and the same object may be viewed through different versions of the schema. 6 Our approach was to realize a more sophisticated state function oe, based on a combination of the above strategies, that keeps databases type valid without any instance conversion. For this purpose, the database ....

A.H. Skarra and S.B. Zdonik. Type evolution in an object-oriented database. In Research Directions in Object-Oriented Programming, 1987.

....graphs (VDGs) which are subsequently mapped into the structures of an underlying database. A powerful visual interface is thus provided for database schema evolution. Various approaches to database schema evolution have been proposed, particularly in the context of object oriented databases [3, 4, 7, 2, 13, 15, 16]. Theses approaches can be divided into three categories based on the external representation of the structure of the objects in the database (object schema) to application programs and interactive users, and the internal representation of the objects in the underlying database: 1) Schema ....

....must be con verted to conform to the new schema. Because of this, the schema modification approach does not support the transparency of change for the existing application programs. The application programs that use the old schema may need to be modified. 2) Schema versioning approaches [1, 13] support multiple schemas and multiple internal object representations for an object. The instantiation of objects to a schema version is performed at the time of the creation of the objects. In this approach, the objects belonging to a version of a schema must always stay in that version. ....

H. A. Skarra and S. B. Zdonik. Type Evolution in an Object-Oriented Database. In Research in ObjectOriented Databases . Addison-Wesley, 1987.

....include definitions for T1 and its base classes (if ################################ 12 The latter questions relate to the problem of schema evolution, a well known hard problem in database systems. Researchers in object oriented database systems have offered several approaches to the problem [Bane87, Penn87, Skar87], although none seems entirely satisfactory. any) Now suppose we write another program P2 that defines T2 as a subtype of T1 and adds a T2 node to G. If we then run P1, the program will terminate with an error when it invokes the virtual function on the new node. Note that this is not a type ....

Skarra, A., and Zdonik, S.B., "Type Evolution in an Object-Oriented Database," in Research Directions in Object-Oriented Programming, B. Shriver and P. Wegner, eds., MIT Press, 1987.

....they either include a data migration utility to adapt existing data objects to the changed schema, or some other mechanism has to ensure consistency between data and structure. An early investigation of changing types in populated database exists for the ENCORE database management system [SZ86, SZ87] This work addresses the effects of type changes to objects and to programs that use objects of the type. The first systematic analysis of desirable schema evolution possibilities was done for the ORION data model in [BKKK87, BCG 87] A set of all necessary schema updates was listed and ....

....updates, changing the definition of types or classes, may have an impact on the existing instances. We distinguish in our model two different ways of schema 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 ....

A.H. Skarra and S.B. Zdonik. Type evolution in an object-oriented database. In B. Shriver and P. Wegner, editors, Research Directions in Object-Oriented Programming, pages 393--413. MIT Press, 1987.

....due to static changes listed in ORION [20] are similar to the elementary transformations presented in this paper. The main difference is the possible violation of the inheritance that doesn t exist in structured editing systems. Most systems such as O 2 [21] ORION, GemStone [22] ENCORE [23] [24] cover these transformations. Moreover, behavioral inconsistencies, which do not exist in structured editing systems, are not fully covered in database systems. Only O 2 and ENCORE provide mechanisms for partial recovery of these problems. 6.4 Programming languages The problem of type ....

A. H. Skara, S. B. Zdonik, "Type Evolution in an Object-Oriented Database", Research and Directions in Object Oriented Systems, B. Shriver and P. Wagner, ed., MIT Press, September 1987.

....for simulating the semantics of the new interface on top of instances of the old, or vice versa. Since the former schema is not discarded but retained as an alternate interface, the emulation scheme provides program compatibility. Such a facility has been developed for the Encore system [21]. Encore pays for this additional functionality with a loss in runtime efficiency. Under a conversion scheme, the cost of the evolution is a function of the number of affected instances. Once converted, an old instance can be referenced at the same cost as a newly created one. However, the cost ....

....value. The best a programmer could do in such a system is associate a default attribute value for all instances of older (newer) type versions by installing an exception handling routine to return the value when an application attempts to reference that attribute from an old (new) instance [21]. The Common Lisp Object System CLOS [22, 15] while not an OODB system, provides extended support for class evolution nonetheless. As Common Lisp system development is performed in an interactive context, class redefinition is a frequent occurrence. Rather than discard all existing instances, ....

[Article contains additional citation context not shown here]

Skarra, A. H. and Zdonik, S. B. Type Evolution in an Object-Oriented Database. in: Research Directions in Object-Oriented Programming. MIT Press Series in Computer Systems, MIT Press, Cambridge, MA, 1987, pp. 393--415. An early version of this paper appears in the OOPSLA '86 proceedings.

....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 and classes as well ....

Skarra, A.H., Zdonik, S.B., `Type Evolution in an Object Oriented Database', in Research Directions in Object Oriented Programming, eds. Shriver, Wegner, pp 393-415, 1987.

.... of TM: ffl a TM based DBMS prototype, ffl a logical query language for TM databases, ffl further conceptual primitives for dealing with synchronization, ffl the specification of general dynamic constraints, ffl application development on top of TM, and ffl the problem of schema updates [Bane87a,Bane87b,SkZd87,Zica90a,Zica90b,Zica91], and that of object updates [Zdon87] in the presence of TM s three level constraints. An interesting solution to the problem of object oriented updates in the presence of integrity constraints is offered by the Cactis object oriented database system [HuKi89] An efficient incremental update ....

A. H. Skarra & S. B. Zdonik, "Type Evolution in an Object-Oriented Database," in Research Directions in Object-Oriented Programming, B. D. Shriver & P. Wegner, eds., MIT Press, Cambridge, MA, 1987, 393-- 416, MIT Press series in Computer Systems.

....will coexist with former versions. Application program may regard the database as through any of these versions. Database objects may be created from within any schema version context, however the SMM system must ensure that they may behave consistently in any other context as well. Encore [SZ87] extends objects with special error handlers which respond to requests not originally supported by the object, but which may arise from within other version contexts. CLOSQL [MS92] temporarily converts objects dynamically to become an instance of the type version as expected. A particular problem ....

Andrea H. Skarra and Stanley B. Zdonik. Type Evolution in an Object-Oriented Database. In Bruce Shriver and Peter Wegner (Eds.): Research Directions in Object-Oriented Programming, pages 393--415. MIT Press, 1987.

....new clients and to share the extent. This avoids conversion of the clients to conform to new class versions. Conversion might be an error prone and costly process. Class versioning also prevents information to be lost. ABB 83] supports class versioning by substitute read and write functions, SZ87] by error handlers, Zdo90, Cla92] by multiple views to objects. Database views [GPZ88, KDN90, Ber92] is a general technique for having derived information, and it may successfully be used for class evolution. However, often it is not possible to create objects of views and it is not possible to ....

A. H. Skarra and S. B. Zdonik. Type Evolution in an Object-Oriented Database. In B. Shriever and P. Wegner, editors. Research Directions in Object-Oriented Programming, pages 393--415. MIT Press, 1987.

....sense that temporal support of real world objects is extended in a uniform manner to schema objects, and then used to support schema evolution. Some of the ideas in [Rod91, Rod92, Rod95] have been carried forward in the design of the TSQL2 temporal query language [Sno95] Skarra and Zdonik [SZ86, SZ87] define a framework within the Encore object model for versioning types as a support mechanism for changing type definitions. A type is organized as a set of individual versions. This is known as the version set of the type. Every change to a type definition results in the generation of a new ....

....is available. Thus, even 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 ....

A.H. Skarra and S.B. Zdonik. Type Evolution in an Object-Oriented Database. In Research Directions in Object-Oriented Programming, pages 393--415. M.I.T. Press, 1987.

No context found.

Skarra A H and Zdonik S B, Type Evolution in an Object-Oriented Database, in: Research Directions in Object-Oriented Programming, ed. B. Shiver, and P. Wenger, (MIT Press Series in computer Systems 1987) 393-415.

No context found.

Skarra,A.H.---Zdonik,S.B.: Type evolution in an Object-Oriented Databases. In Research Directions in Object-Oriented (Shriver, B. and Wegner, P., eds.), MIT Press 1986.

No context found.

A. Skarra and S. Zdonik, "Type Evolution in an Object-Oriented Data Base," B. Shriver and P. Wegner, eds., Research Directions in Object-Oriented Programming, pp. 393-416, MIT Press, 1987.

No context found.

A. H. Skarra and S. B. Zdonik, Type Evolution in an Object-Oriented Database, In Research Directions in Object-Oriented Programming, MITP, Cambridge, MA, Computer Systems, 1987, pp. 393-415.

No context found.

A. Skarra and S. Zdonik. Type evolution in an Object-Oriented Database. In Proceedings of the Conference on Object-Oriented Systems, Languages and Applications (OOPSLA), 1987.

No context found.

A.H. Skarra and S.B. Zdonik. Type Evolution in an Object-Oriented Database. In A.F. Cardenas and D. McLeod, eds., Research Foundations in Object-Oriented and Semantic Database Systems, pp. 137--155. Prentice-Hall, 1990.

No context found.

Skarra A.H. and Zdonik S.B. #1987# Type evolution in an object-oriented database, in Research Directions in Object-Oriented Programming, B. Shriver and P.Wegner #eds#, MIT Press, 1987.

No context found.

S. Zdonik A. Skarra. Type evolution in an object-oriented database. In Research Directions in Object Oriented Programming, MIT Press series in Computer Science, pages 393--415. MIT Press Cambridge, 1987.

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