Zdonik, S. B.: Object-Oriented type evolution. In Advances in Databases Programming Languages (Kim, W., ed.),, ACM Press 1990, pp. 277--293.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....many research projects concern models definition for engineering design applications as CAD, CASE etc. These applications showed clearly that manipulated objects and their structures must evolve. So, considering this aspect, built in mechanisms (as in ORION [1] GEMSTONE [15] ENCORE [17] . are currently used, allowing extensibility through programming heavy effort. This evolving aspect appears for data (evolving data) and structures modeling these data (evolving schema) In systems like Shood where each concept is modeled by objects (classes instances . we can use a same ....

S. B. Zdonik, Object oriented type evolution. In Kim, W., Editor, Advances in Databases Programming Languages, pp 277-293, ACM Press.

....view o f the object, if run time checking for existence of roles (non nil optional role attributes) is allowed. Supporting the second position is easy, since provision of run time checking and or exception handling mechanisms is needed anyway for correct treatment of role dropping ( FBC 87] [Zdon90], ABGO93] Furthermore, use of implicitly defined combinatorial types ( Knie96] can significantly reduce the amount of run time type checking. Note that the statically safe interpretation coincides with the restricted interpretation of perspectives in most published role models, while the ....

....binding with highest priority for . receiver role most specialized subrole of receiver role (essential role of) receiver object fixed variable d) B3 a B1 a B3 c B3 b B1 c B1 b B2 a B2 c B2 b A c A a A b Proposals in interesting categories A c) Scio89] ScSw89] [Zdon90] 1 , RiSc91] GSR94] WJS94] 2 . B1 a) ACO85] StZd89] Zdon90] 1 , WJS94] 2 B1 b) FDC 87] ABG091] BeGu95] B1 c) VeCa93] ABGO93] Darwin B2 a,b,c) No approaches known yet. B3 a,b,c) No approaches known yet. Each semantics can be expressed in Darwin. Examples are ....

[Article contains additional citation context not shown here]

Zdonik: "Object-Oriented Type Evolution". In: [Bancilhon & Buneman 90], pp. 277-288.

....one. Finally, we have examined whether the considered approaches model the history of associations between an object and its type (class) Indeed, an important dynamic aspect of object oriented databases is that an object can dynamically change type, by specializing or generalizing its current one [22] (often this type change is referred to as object ) Thus, we distinguish the approaches keeping track of the dynamic links between an object and its most specific class from those that does not consider this aspect. As a final remark, let us mention that, as noticed in [17] in contrast to ....

S. Zdonik. Object-Oriented Type Evolution. In F. Bancilhon and P. Buneman, editors, , pages 277--288. Addison-Wesley, 1990. 22

....is able to migrate to different classes, or to dynamically acquire and loose classes, appropriate constraints must be imposed to ensure that correct evolutions are defined. Semantically meaningful migrations depend from the application domain. One option is to specify special integrity constraints [36]. Such constraints include: ffl specifying a class as essential a class C is essential if an object which is a member of C cannot at a subsequent point in time migrate to another class and stop belonging to the set of members of C. This means that migrations of an object which is a member of C ....

....are available in SQL [9] and have been revisited in an object oriented context [5] ranging from forbidding the deletion of the referred object, to propagating (that is, cascading) the deletion to the referencing object, and to setting the reference to null. To avoid dangling references, Zdonik [36] proposes to keep a tombstone ob 3 Here and in what follows, the term user should be intended in the broader meaning of an actual user or an application. OBJECT EVOLUTION IN OBJECT DATABASES 7 ject in place of the deleted object. This solution overcomes the problem of dangling references, since ....

[Article contains additional citation context not shown here]

S. Zdonik. Object-Oriented Type Evolution. In F. Bancilhon and P. Buneman, editors, Advances in Database Programming Languages, pages 277--288. AddisonWesley, 1990.

....ID will be used as identifiers for objects, and the special symbol o represents the undefined identifier which is used for a tombstone object, i.e. an undefined object a deleted object. The idea of tombstone object is useful in handling the object deletion problem (such as dangling reference) [25]. ffl A finite set M whose elements are called methods and play the role of operations on our data structures. We will define methods more formally later. For the moment, we can think of the elements of M as uninterpreted symbols (i.e. uninterpreted lambda expressions) 7 Besides, we assume ....

....section to further illustrate the DOOR data model presented in last section. The first example is based on the example shown in Figure 2 with particular emphasis on player qualification. The second one is about how the object reference problems (such as the dangling reference problem mentioned in [25]) are handled by DOOR. For simplicity and clarity, the method component is omitted and denoted by an underscore. 4.1 Illustration of Player Qualification Assume the class hierarchies shown in Figure 2, i.e. Child Person, Adult Person, Student Worker Student, Student Worker Employee, we ....

S.B. Zdonik. Object-oriented type evolution. In F. Bancilhon and P. Buneman, editors, Advances in Database Programming Languages, pages 277--288. ACM Press, Addison-Wesley, 1990. 29

....values of unaffected attributes common to all employees 5. 1 Classes and types While researchers in knowledge representation systems have been aware of the problem of mutating objects for some time [10, 66] it has only recently begun to receive attention in the object oriented database community [76, 72]. In most object oriented database systems the permanent binding of an object s identity to a single class constrains the tracking of real world entities over time. This is a critical problem, because one is forced to model entities that evolve dynamically with objects that cannot. The ability to ....

....time. This is a critical problem, because one is forced to model entities that evolve dynamically with objects that cannot. The ability to change the class of an object provides support for object evolution. It lets an object change its structure and behaviour, and still retain its identity. In [76] a type system which allows this kind of evolution is presented. An object x can have a set of types, and the change from one type to another is a process of selectively adding and deleting types to the set of types of x. The notion of typing is retained whilst allowing some flexibility in system ....

[Article contains additional citation context not shown here]

S.B. Zdonik. Object-oriented type evolution. In F. Bancilhon and P. Buneman, editors, Advances in Database Programming Languages, pages 277--288. ACM Press, 1990.

....one seen by the dereferencing application) implies that this error handler is invoked. Error handlers are manually implemented upon change, and may perform any computation. AVANCE [7] maintains substitute functions on attribute level, in principle between all versions. The Multiple view approach [8] allows for making new layers to add new properties (or hide old ones) and which may be implemented on top of lower layers. Old representation is never obsoleted, and must be maintained even if newer versions are referenced. 1 LISPO 2 also provides support for application modification and ....

Stanley B. Zdonik. Object-Oriented Type Evolution. In Francois Bancilhon and Peter Buneman (Eds.): Advances in Database Programming Languages, chapter 16, pages 277--288. Addison-Wesley, 1990.

....class hierarchy, with the possible implication that an employee aspect addition to a person may no longer be acceptable as a person. Iris [FBC 87] also allows for arbitrary addition and removal of types dynamically, however there is only one context of behavior, and thus no notion of role. Zdo90] allows for roles to be added and removed, providing special abilities to specify that some roles are not removable ( essential type ) and that some roles may only be acquired upon creation ( exclusionary type ) Based on these, other restrictions on evolution may be specified, although in an ....

Stanley B. Zdonik. Object-Oriented Type Evolution. In Francois Bancilhon and Peter Buneman (Eds.): Advances in Database Programming Languages, chapter 16, pages 277--288. Addison-Wesley, 1990.

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

....to a version of a schema must always stay in that version. Therefore, if the schema of the objects is subsequently augmented, it would not be possible for the objects to be updated by the programs associated with a later version without loss of information. 3) Schema derivation approaches [3, 4, 7, 15] support multiple schemas for an object and a common internal object representation. Irrespective of whether objects are created under different schema versions, they are converted to the common representation. The instantiation of objects to a schema version is performed at run time. Although ....

S. B. Zdonik. Object-Oriented Type Evolution . In Advances in Database Programming Languages. AddisonWesley, 1990.

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

S. B. Zdonik. Object-Oriented Type Evolution. In Fran¸cois Bancilhon and Peter Buneman (Eds.): Advances in Database Programming Languages, chapter 16, pages 277--288. AddisonWesley, 1990.

.... Finally, we have examined whether the considered approaches model the history of associations between an object and its type (class) Indeed, an important dynamic aspect of object oriented databases is that an object can dynamically change type, by specializing or generalizing its current one [Zdo90] often this type change is referred to as object ) Thus, we distinguish the approaches keeping track of the dynamic links between an object and its most specific class from those that does not consider this aspect. As a final remark, let us mention that, as noticed in [Sno95] in contrast to ....

S. Zdonik. Object-Oriented Type Evolution. In F. Bancilhon and P. Buneman, editors, , pages 277--288. Addison-Wesley, 1990.

....scheme [21] instances never change their type version. Aware of the restrictions this causes (cf. previous section) Zdonik proposed a scheme whereby an existing instance can be wrapped with extra storage and a new interface, enabling it to be a full fledged instance of a new type version [24]. While still accessible through its original interface version, the wrapped object can also be manipulated through 2 Whether the instances are converted eagerly or lazily becomes an implementation issue. new attributes original attributes new interface old interface Figure 2: Zdonik s ....

....possible to derive one from the other. Advisor is a dependent attribute, since a change in Program might necessitate a change in advisor. Likewise, Program is a dependent attribute, since a change in advisor might imply that the student has switched degree programs. cf. Figure 3) Zdonik et al. [21, 24] almost always cite evolutions involving independent or derived attributes in their examples. The original Encore emulation scheme is adequate for supporting evolutions that introduce shared and derived attributes. Zdonik s wrapping proposal addresses the problems associated with independent ....

[Article contains additional citation context not shown here]

Zdonik, S. Object-Oriented Type Evolution. in: Advances in Database Programming Languages, edited by F. Bancilhon and P. Buneman. ACM Press, New York, NY, 1990, pp. 277--288.

....highlights the dynamic aspect of the objects and the associated structures used in this area. Usually, the taking into account of this special aspect is done, using some kind of code based solutions. Those hard wire solutions (such as in ORION [Banerjee 87] GEMSTONE [Penney 87] ENCORE [Zdonik 90] . drastically reduce the extensibility of the proposed code and increase the cost of its maintenance. This evolving aspect appears both for data (evolving data) and structures modeling these data (evolving schema) In systems such as SHOOD [Cointe 87] where each concept is modeled as an object ....

S. B. Zdonik. Object oriented type evolution. In Kim, W., Editor, Advances in Databases Programming Languages, pp 277-293, acm Press.

....approach where the class hierarchy may evolve in all directions. This covers for the typical evolution situations of subclassing, and generalisation, which allows for creating superclasses from existing classes, see [SN88] and [Ped89] In addition it covers what is known as type versioning [Zdo90] The second part of the paper (Section 4) treats two problems introduced by evolving the schema: there are existing objects and clients to take care of. Type change transparency [ABB 83] allows for existing clients and objects to exist by creating new versions of the types and converting ....

....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 add representation in ....

S. B. Zdonik. Object-Oriented Type Evolution. In F. Bancilhon and P. Buneman, editors. Advances in Database Programming Languages, pages 277--293. Addison-Wesley Publishing Company, 1990.

....1988] trigger mechanisms [Dayal et al. 1988] and have led to progress in the following domains: n Type generic commands. Combining concepts from Entity Relationship data models [Chen, 1976] and Object Oriented technology [Atkinson et al. 1989] n Object type evolution [Zicari, 1989; Zdonik, 1990], management of structured and composite objects which evolve over time; n Relation types and their use for graphs, composite objects and constraint propagation [Boudier et al. 1988] n Extension of object orientation to capture contextual behavior [Dittrich et al. 1987] n Extension of ECA ....

....the platform (a passive object server) and the tools and activities that must be built on top of it. No real services are provided for activity control or for the tool control. On current trends, PSEE DB integrate both approaches: ERA DB extended with OO features with better support for versions [Zdonik, 1990], structuring and consistency control. Products like PCTE and Adele 2 are of that class. The PSEE approach usually starts from such a platform and adds process modeling, e.g. ALF [Derniame et al. 1992] TEMPO [Belkhatir et al. 1993] However, we do think that process support needs extensions in ....

Zdonik, S. (1990). Object-oriented type evolution. In Kim, W., editor, Advances in Databases Programming Languages, pages 277--293. ACM Press.

....values of unaffected attributes common to all employees 5. 1 Classes and types While researchers in knowledge representation systems have been aware of the problem of mutating objects for some time [10, 62] it has only recently begun to receive attention in the object oriented database community [71, 24]. In most object oriented database systems the permanent binding of an object s identity to a single class constrains the tracking of real world entities over time. This is a critical problem, because one is forced to model entities that evolve dynamically with objects that cannot. The ability to ....

....time. This is a critical problem, because one is forced to model entities that evolve dynamically with objects that cannot. The ability to change the class of an object provides support for object evolution. It lets an object change its structure and behaviour, and still retain its identity. In [71] a type system which allows this kind of evolution is presented. An object x can have a set of types, and the change from one type to another is a process of selectively adding and deleting types to the set of types of x. The notion of typing is retained whilst allowing some flexibility in system ....

[Article contains additional citation context not shown here]

S. B. Zdonik. Object-oriented type evolution. In F. Bancilhon and P. Buneman, editors, Advances in Database Programming Languages, pages 277--288. ACM Press, 1990.

....conditions are evaluated lazily (incrementally) FeMZ94] whenever a new object is inserted into a DAG class. 6. 2 Roles and schema evolution The management of objects that evolve dynamically over time has been of some concern to research activities in the context of schema evolution [SkZ87] [ZDO90] [BAN87] ZIK91] Schema evolution addresses the problem of schema updates applied to an object base due to changing application requirements. There are two approaches to schema evolution: conversion and versioning. The former restructures the affected instances to conform to classes which have ....

....In general, schema evolution requires human intervention, i.e. the involvement of a database administrator, to apply the schema changes and check the consistency of the database schema. Such issues do not affect roles. However, research activities relating to object oriented schema type evolution [ZDO90], SkZ87] and parametrized primitives for schema updates in O 2 [ZIK91] in particular, have influenced our work on dynamic objects. 6.3 Roles and other approaches The notion of role has also been used in expressing potential object states and behavior in the context of office information ....

Zdonik S (1990) Object-oriented type evolution. Advances in Database Programming Languages, ACM Press, New York

....even where the new form of the data differs markedly from the old. Existing applications may operate with new data if the system supports a type system that allows new structure to be related to existing structure, such as subtyping [Cardelli, 1984] or mechanisms geared specifically to evolution [Zdonik, 1990, Connor et al. 1995] A more powerful technique is required where such a mechanism is not supported or where the evolution does not follow the predicted path provided by the type system. 4 Embedded and overlapping objects Encapsulation requires that objects hide their internal structure. Some ....

Zdonik, S.B. (1990) Object-Oriented Type Evolution. In F. Bancilhon and O.P. Buneman (ed) Advances in Database Programming Languages. Addison-Wesley, pp. 277-288.

....first introduce some approaches adopted in some contemporary OODBMSs. There are generally two kinds of approaches: the deferred approach and the immediate approach. Deferred Approach delays the application of change to objects, even indefinitely. Zdonik gave an approach based on class version [9]. After the class is modified, a new version of the class will be generated at once. The new version includes an exception handling method or procedure; When the instance of the class is accessed, if its version is not consist ent with the class, the exception handler will be activated, and then, ....

S. Zdonik, "Object-Oriented Type Evolution", in Advances in Database Programming Languages, F. Bancilhon and P. Buneman, eds., Addison Wesley, Reading Mass., 1990, pp 277-288

....unlike roles they do not simply evolve from one type into another by means of inheritance or inter object relationships. The management of objects that evolve dynamically over time has also been of concern to other researchers who have examined such concepts in the light of schema evolution [4] [10] [2] 5] Schema evolution is concerned with changes in types introduced at the schema level and how these changes can be propagated to all instances of a type in the database that is affected by the changes. Roles, on the other hand, are mainly concerned with refining the behavior of only ....

....updates and subsequent object conversion, and in particular those applicable to changes in the structure of a type lattice [4] may also be applicable to roles. Research work on schema evolution which has influenced our work on roles relates to the notion of object oriented schema type evolution [10], 4] and to parameterized primitives for schema updates in O 2 [5] 3 Objects that Change Shape and Behavior The object oriented modeling concepts and terminology used in this paper are based on those found in [11] and [12] The discussion focuses on objects which have the following ....

[Article contains additional citation context not shown here]

S. Zdonik "Object-Oriented Type Evolution", in Advances in Database Programming Languages, ACM Pres, F. Banchilhon, P. Buneman (eds), 1990.

....the persistent counterpart may be multi perspectived and thus not always regarded as an instance of just one class. The model of objects with roles naturally reflects the evolving and multi perspectived nature of real world objects. However, the notion of object roles is not a new one, SZ89, Zdo90, Ara89, RS91, Vel93, SS91] are some other approaches with similar abilities to add and remove object memberships in classes dynamically. An important characteristic of the presented approach, however, is the use of the class hierarchy as the basis for role addition and removal. Most other ....

Stanley B. Zdonik. Object-Oriented Type Evolution. In Francois Bancilhon and Peter Buneman (Eds.): Advances in Database Programming Languages, chapter 16, pages 277--288. Addison-Wesley, 1990.

....developed databases have to be integrated. Classes in object oriented databases already provide for some evolution by the use of subclassing, which lets a class extend another class by the use of inheritance. This allows for a class hierarchy to be evolved downwards . Several authors [12, 13, 9] have recognised that this is insufficient, and they have proposed special purpose mechanisms for generalisation of classes, versioning of classes, and integration of classes. By extracting the essential concepts from these evolution and integration techniques, we propose a unified framework for ....

....and to share the extent. This avoids conversion of existing applications to conform to new class versions. Conversion might be an error prone and costly process. Class versioning also prevents information from being lost. 1] supports class versioning by substitute read and write functions, and [13, 7] by multiple views. 11] is a proposal for versioning of entire schemas in object oriented databases. Class integration is usually done additively by views, e.g. 9] These constructs have many similarities, yet still, they are different. Common to the additive approaches is that the extents (the ....

S. B. Zdonik. Object-Oriented Type Evolution. In F. Bancilhon and P. Buneman (editors), Advances in Database Programming Languages, chapter 16, pages 277-- 293. Addison-Wesley Publishing Company, 1990.

No context found.

Zdonik, S. B.: Object-Oriented type evolution. In Advances in Databases Programming Languages (Kim, W., ed.),, ACM Press 1990, pp. 277--293.

No context found.

Stanley B. Zdonik. Object-Oriented Type Evolution. In Francois Bancilhon and Peter Buneman (Eds.): Advances in Database Programming Languages, chapter 16, pages 277-- 288. Addison-Wesley, 1990.

No context found.

Stanley B. Zdonik. Object-Oriented Type Evolution. In Francois Bancilhon and Peter Buneman (Eds.): Advances in Database Programming Languages, chapter 16, pages 277--288. Addison-Wesley, 1990.

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