F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of Int'l Conf. on Very Large Databases (VLDB), September 1995.  Home/Search   Document Not in Database   Summary   Related Articles   Check

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

F. Ferrandina, T. Meyer, R. Zicari, and G. Ferran. Schema and database evolution in the O2 object database system. In 21st Conference on Very Large Databases, pages 170--181, 1995.

....O2, e.g. we found no information about the mechanisms for supporting the atomicity of individual transforms, or about the performance impact of upgrade support on normal case operation. The O2 screening approach co locates versions of upgraded objects physically near the new version of the object [33]. This requires database reorganization when versions are created. In contrast, our system does not require co location of object versions; this allows us to preserve clustering of non upgraded objects without database reorganization and furthermore, we are often able to preserve clustering for ....

F. Ferrandina and G. Ferran. Schema and database evolution in the O2 Object Database System. In Proceedings of the 21st International Conference on Very Large Data Bases (VLDB), 1995.

....automatic system aid and control. In the object oriented field, two main approaches were followed to ensure consistency in pursuing the semantics of change problem. The first approach is based on the adoption of invariants and rules, and has been used, for instance, in the ORION [6] and O 2 [20] systems. The second approach, which was proposed in [36] is based on the introduction of axioms. In the former approach, the invariants define the consistency of a schema, and definite rules must be followed to maintain the invariants satisfied after each schema change. Invariants and rules are ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of the 21st Int'l Conf. on Very Large Databases (VLDB), pages 170--181, Zurich, Switzerland, September 1995.

....problems have been investigated to a certain extent. In particular, two main approaches were followed to ensure consistency in pursuing the semantics of change problem. The first approach is based on the adoption of invariants and rules, and has been used, for instance, in the ORION [4] and O 2 [12] systems. The second approach, which was proposed in [24] is based on the introduction of axioms.In the former approach, the invariants define the consistency of a schema, and definite rules must be followed to maintain the invariants satisfied after each schema change. Invariants and rules are ....

....in ORION [4] 3. Filtering: changes are never propagated: objects are assigned to different schema versions according to their semantics indeed used for instance in CLOSQL [21] 4. Hybrid: uses or combines two or more of the previous approaches used for instance in Sherpa [22] and O 2 [12]. In any case, simple default mechanisms can be used or user supplied conversion functions must be defined for non trivial extant object updates. As far as complex schema changes are concerned, 20] considered sequences of schema change primitives to make up high level useful changes, solving ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of the 21st Int'l Conf. on Very Large Databases (VLDB), pages 170--181, Zurich, Switzerland, September 1995.

....requiring upgrades, which we expect to be the common case, since upgrades are likely to be rare (e.g. no more frequent than once a week or once a day) The results also show that the slowdown when upgrades are needed is small. There has been quite a bit of earlier work on upgrades in OODBs [4, 18, 15, 23, 22]. This work has either avoided lazy upgrades entirely, or under much broader conditions than are necessary; or the systems allow lazy upgrades even when they are unsafe. We discuss related work in more detail in Section 5. The paper is organized as follows. Section 2 describes our approach to de ....

....it as needed) depends on the concrete system. Our discussion focusses on the schema evolution approach because it is most relevant to our work; a problem with the versioning approach is the huge amount of storage it requires. The scheme evolution approach is used in the commercial systems O2 [15, 3], GemStone [23, 8] Objectivity DB [22] and Versant [25] and in the research systems Orion [4] OTGen [18] and PJama [2, 14] and is the only approach available in commercial RDBMS. Very few of these systems support general transforms and lazy conversion: Gemstone and Orion do not support ....

[Article contains additional citation context not shown here]

F. Ferrandina and G. Ferran. Schema and database evolution in the O2 Object Database System. In Proceedings of the 21st International Conference on Very Large Data Bases (VLDB), 1995.

....requiring upgrades, which we expect to be the common case, since upgrades are likely to be rare (e.g. no more frequent than once a week or once a day) The results also show that the slowdown when upgrades are needed is small. There has been quite a bit of earlier work on upgrades in OODBs [4, 18, 15, 23, 22]. This work has either avoided lazy upgrades entirely, or under much broader conditions than are necessary; or the systems allow lazy upgrades even when they are unsafe. We discuss related work in more detail in Section 5. The paper is organized as follows. Section 2 describes our approach to ....

....it as needed) depends on the concrete system. Our discussion focusses on the schema evolution approach because it is most relevant to our work; a problem with the versioning approach is the huge amount of storage it requires. The scheme evolution approach is used in the commercial systems O2 [15, 3], GemStone [23, 8] Objectivity DB [22] and Versant [25] and in the research systems Orion [4] OTGen [18] and PJama [2, 14] and is the only approach available in commercial RDBMS. Very few of these systems support general transforms and lazy conversion: Gemstone and Orion do not support ....

[Article contains additional citation context not shown here]

F. Ferrandina and G. Ferran. Schema and database evolution in the O2 Object Database System. In Proceedings of the 21st International Conference on Very Large Data Bases (VLDB), 1995.

....features such as property sharing and viewpoints merging, unconsidered so far, in a clean and homogeneous way. 1 Introduction In traditional object oriented databases, evolution of objects is a considerable issue. A lot of work has been carried out on schema evolution and correlated instances [13, 17, 7, 1, 4, 5]. The database schema represents a common structure and behaviour for instances of classes. However, the concept of class is too restrictive to support evolution of structure or behaviour dynamically. Moreover, these modifications should not, because of persistence, require recompilation of ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proceedings of International Conference on Very Large Data Bases (VLDB'95), Zurich, Switzerland, 1995.

....In the object oriented field (see [27, 11] for the relational case) two main approaches were followed to ensure consistency in pursuing the semantics of change problem. The first approach is based on the adoption of invariants and rules, and has been used, for instance, in the ORION [4] and O 2 [12] systems. The second approach, which was proposed in [25] is based on the introduction of axioms. In the former approach, the invariants define the consistency of a schema, and definite rules must be followed to maintain the invariants satisfied after each schema change. Invariants and rules are ....

....available primitive schema changes with the axioms automatically ensures schema consistency, without need for explicit checking, as incorrect schema versions cannot actually be generated. For the change propagation problem, several solutions have been proposed and implemented in real systems [4, 12,23, 24]. In all cases, simple default mechanisms can be used or user supplied conversion functions must be defined for non trivial extant object updates. As far as complex schema changes are concerned, 22] considered sequences of schema change primitives to make up high level useful changes, solving ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of Int'l Conf. on Very Large Databases (VLDB), September 1995.

....of extant data with the modi ed schema. In the object oriented eld, two main approaches were followed to ensure consistency in pursuing the semantics of change problem. The rst approach is based on the adoption of invariants and rules, and has been used, for instance, in the ORION [3] and O 2 [11] systems. The second approach, which was proposed in [22] is based on the introduction of axioms. In the former approach, the invariants de ne the consistency of a schema, and de nite rules must be followed to maintain the invariants satis ed after each schema change. In the latter approach, a ....

....available primitive schema changes with the axioms automatically ensures schema consistency, without need for explicit checking, as incorrect schema versions cannot actually be generated. For the change propagation problem, several solutions have been proposed and implemented in real systems [3, 11, 21]. In most cases, simple default mechanisms can be used or user supplied conversion functions must be de ned for non trivial extant object updates. A notable exception is [19] where a formal notion of logical consistency of the global approach is devised and proved decidable, in the context of a ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of the 21st Int'l Conf. on Very Large Databases (VLDB), pages 170-181, September 1995.

....ed schema. In the object oriented eld for the relational case) two main approaches were followed to ensure consistency in pursuing the semantics of change problem. The rst approach is based on the adoption of invariants and rules, and has been used, for instance, in the ORION [4] and O 2 [12] systems. The second approach, which was proposed in [22] is based on the introduction of axioms. In the former approach, the invariants de ne the consistency of a schema, and de nite rules must be followed to maintain the invariants satis ed after each schema change. Invariants and rules are ....

....available primitive schema changes with the axioms automatically ensures schema consistency, without need for explicit checking, as incorrect schema versions cannot actually be generated. For the change propagation problem, several solutions have been proposed and implemented in real systems [4, 12, 21]. In all cases, simple default mechanisms can be used or user supplied conversion functions must be de ned for non trivial extant object updates. As far as complex schema changes are concerned, 20] considered sequences of schema change primitives to make up high level useful changes, solving the ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of the 21st Int'l Conf. on Very Large Databases (VLDB), pages 170-181, Zurich, Switzerland, September 1995.

....the schema updates in place, i.e. the previous state of the schema is irreversibly lost after the update. Therefore, applications have to be adapted to the modified schema immediately in order to be executed. Usually those adaptations of applications have to be done manually. Some approaches [4] allow at least to perform the transformation of the database in a deferred way, thus avoiding possibly long phases during which the database is blocked from application accesses. Other approaches simulate schema updates through views [2, 16, 19] Instead of changing the underlying database ....

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O 2 Object Database System. In VLDB, pages 170--181, 1995.

....to the evolution tool. Another approach (described, for example, in [15] involves utilization of some special schema change specification language which usually has much in common with the schema definition language (or is just a part of it) A mix of these approaches may be allowed, as in O 2 [6]. The two ways of specifying the change may be compared in Figure 1. The disadvantage of direct specification of the new definition of class is that the programmer does not see the specification of the change itself. It also may make the job of the evolution tool harder. But the obvious ....

....of all potentially affected classes. Another concern is how to handle instances of a deleted class. Currently the tool just checks that there are no such instances in the store by scanning it. In future, we may consider the implementing a more sophisticated technique, similar to that existing in [6]. It allows the programmer to re bind these instances to a different class, usually one of the superclasses of the deleted class. 2.4 Persistent Data Conversion The problem of instance or static data conversion from old to new formats of is one of the most challenging in the evolution ....

[Article contains additional citation context not shown here]

Fabrizio Ferrandina, Guy Ferran, Joelle Madec, Thorsten Meyer, and Roberto Zicari. Schema and Database Evolution in the O 2 Object Database System. In Proc. of the 21th International Conference on Very Large Databases, pages 170-181, Zurich, Switzerland, September 11-15, 1995.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of Int'l Conf. on Very Large Databases (VLDB), September 1995.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O2 Object Database System. In Proc. of Int'l Conf. on Very Large Databases (VLDB), September 1995.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, and G. Ferran. Schema and database evolution in the O2 object database system. In 21st Conference on Very Large Databases, pages 170--181, 1995.

No context found.

F. Ferrandina and G. Ferran. Schema and database evolution in the O2 Object Database System. In Proceedings of the 21st International Conference on Very Large Data Bases (VLDB), 1995.

No context found.

F. Ferrandina and G. Ferran. Schema and Database Evolution in the O2 Object Database System. In Proceedings of the 21st VLDB Conference, 1995.

No context found.

Ferrandina, F.---Meyer, T.---Zicari, R.---Ferran, G.---Madec, J.:Schema and database evolution in the O2 object database system, VLDB'95, Zurich 1995, pp. 170--181.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O Object Database System. In Proc. of the 21st Int'l Conf. on Very Large Databases (VLDB), pages 170--181, September 1995.

No context found.

F. Ferrandina and G. Ferran. Schema and database evolution in the O2 Object Database System. In Proceedings of the 21st International Conference on Very Large Data Bases (VLDB), 1995.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O # Object Database System. In Proc. of the 21st Int'l Conf. on Very Large Databases (VLDB), pages 170--181, Zurich, Switzerland, September 1995.

No context found.

F. Ferrandina, G. Ferran, T. Meyer, J. Madec, and R. Zicari. Schema and Database Evolution in the O 2 Object Database System. In Proceedings of the 21st Conference on Very Large Databases (VLDB), Zurich, Switzerland, 1995.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and database evolution in the o2 object database system. In VLDB, pages 170-- 181, 1995.

No context found.

F. Ferrandina, G. Ferran, T. Meyer, J. Madec, and R. Zicari. Schema and Database Evolution in the O 2 Object Database System. In International Conference on Very Large Data Bases, 1995.

No context found.

F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in the O 2 Object Database System. In Proceedings of the 21 th VLDB Conference, Zurich, Switzerland, 1995.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC