Lerner, B. S., Habermann, A. N., " Beyond Schema Evolution to Database Reorganisation", Proceedings of ECOOP/OOPSLA 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....where the database has one logical schema to which modifications of class definitions and class hierarchy are applied. Instances are converted (eagerly or lazily, but once and forever) to conform to the latest schema. Examples of systems that follow this approach are Orion[BKKK87, Ban87] OTGen [LH90] O 2 [FMZ94, FFM 95] GemStone J [Gem98, Gem00] Objectivity DB [Obj99a, Obj99b, Obj99d, Obj99c] Versant [Ver00] PJama also employs this technique. Class versioning, which allows multiple versions of each class to co exist. Instances can always be represented as if they belong to a ....

....have to extract them out of the above change specification file, combine them with some additional code and pass them to a C compiler. The potential importance of being able to combine schema evolution with more general database reorganisation has been properly recognised only in one work [LH90] A system called OTGen (Object Transformer Generator) is described in this paper, which assists the database administrator in understanding the effects of changes to class definitions, provides the default transformations, and provides the mechanism to allow overriding of the default ....

B.S. Lerner and A.N. Habermann. Beyond Schema Evolution to Database Reorganisation. In Proceedings of ECOOP/OOPSLA 1990, volume 25 of ACM SIGPLAN Notices, pages 67--76, October 1990.

....be reduced to checking whether an agent may perform an operation on a class or a class instance. This general approach enables the definition of many different access control policies such as simple Unix like user classifications, or more sophisticated ones such as role based access control as in [15, 16]. Moreover, operations may be made to depend on the data itself, rather than just the class. Access Control Rules (ACRs) constitute the basic mechanism for specifying authorization in ISCO. These come in two flavours: class and instance based. The rationale behind such a distinction is probably ....

B. Lerner and A. Habermann. Beyond schema evolution to database reorganisation. ACM SIGPLAN Notices, 25(10):67--76, 1990.

....may be reduced to checking whether an agent may perform an operation on a class or class instance. This general approach enables the definition of many di#erent access control policies such as simple Unix like user classifications, or more sophisticated ones such as role based access control as in [19, 20]. Moreover, operations may be made to depend on the data itself, rather than just the class. Syntactically, access control rules appear in the epilogue of a class definition (see Section 3.1.2) and look like Prolog clauses whose success or failure indicates the permissibility of the operations ....

B. Lerner and A. Habermann. Beyond schema evolution to database reorganisation. ACM SIGPLAN Notices, 25(10):67--76, 1990. 5

.... 1991, 1992b; Ventrone and Heiler 1991) and object oriented databases (Banerjee, et al. 1986, 1987a, 1987b; Skarra and Zdonik 1986, 1987; Zdonik 1986; Penney and Stein 1987; Chou and Kim 1988; Kim and Chou 1988; Bretl, et al. 1989; Kim, et al. 1989; Nguyen and Rieu 1989a, 1989b; Osborn 1989; Lerner and Habermann 1990). 1.2. Pragmatic considerations Before looking in detail at the issues, since the demand for evolving schemata is being driven by the user community, this section discusses briefly some of the constraints or practical considerations for any proposed solution to the problems. First, it is ....

....can be achieved in a number of ways. For instance, within the object oriented paradigm a common method is to establish a set of invariants to ensure the semantic integrity of the schema and a set of rules or primitives for effecting the schema changes (Banerjee, et al. 1986; Bretl, et al. 1989; Lerner and Habermann 1990) while within the relational model a set of atomic operations is proposed which result in a consistent and, as far as possible, reversible database structure (Shneiderman and Thomas 1982) It is important that the evolutionary history of the database s relational or class structure be traceable. ....

[Article contains additional citation context not shown here]

Lerner, B.S. and Habermann, A.N. 1990. `Beyond schema evolution to database reorganisation'.

....as most RDBMSs absorb such changes obviating the need to change applications. 3 . effects on extensional data, and . effects on application programs. Most literature on schema evolution [Banerjee et al. 1987, Penney and Stein 1987, Skarra and Zdonik 1987, Kim and Chou 1988, Joseph et al. 1989, Lerner and Habermann 1990] focuses on the first and second category, but these areas are not the subject of this paper. There is little reported research in the third category, and this is in stark contrast to its significance for application programmers. One of the intentions of this paper is thus to illustrate the ....

Lerner, B.S. and Habermann, A.N., "Beyond Schema Evolution to Database Reorganisation", Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications, October 1990. 19

No context found.

Lerner, B. S., Habermann, A. N., " Beyond Schema Evolution to Database Reorganisation", Proceedings of ECOOP/OOPSLA 1990.

No context found.

B. Lerner and A. Habermann. Beyond schema evolution to database reorganisation. ACM SIGPLAN Notices, 25(10):67-76, 1990. 5

No context found.

B. Lerner and A. Habermann. Beyond Schema Evolution to Database Reorganisation. In SIGPLAN Notices, 25(10), pages 67--76, 1990.

No context found.

B.S. Lerner and A.N. Habermann, "Beyond schema evolution to database reorganisation". SIGPLAN Not. vol. 25, no. 10, pp. 67-76, 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