C. Laasch and M. H. Scholl. A Functional Object Database Language. In Proceedings of the 4th Int'l Workshop on Database Programming Languages, pages 136--156, New York, August 1993. Springer.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....algebra, the optimization process and the physical algebra we discuss a more complex example in Section 5 and give some closing remarks about the ongoing implementation and further research topics in Section 6. Related work The CROQUE project is based on the COCOON (e.g. the language BCOOL [LS93] and the OSCAR ( HFW90] Kla92] project in various parts. In both projects object algebras have been developed. BCOOL is a functional one and so it is more closely to the CROQUE approach than ABRAXAS from OSCAR. ODMG OQL was mainly influenced by the O 2 project [Deu91] A more detailed ....

....and methods types and type constructors. First, every CROQUE OQL query is transformed into an expression over the logical object algebra developed in [Asm95] This logical algebra is not operation oriented like the relational algebra, but a functional one similar to AQUA [LMS 93] and BCOOL [LS93] It consists of 15 basic operations: PATH, LITERAL, LOOP, COLLECT, GROUP, SORT, EXISTS, UNION, INTERSECT, MINUS, FLATTEN, SETCONVERT, BAGCONVERT, STRUCT and CREATECOLLECTION. Only some of these operations are considered here: ffl PATH: this operation represents an instantiation of a class, an ....

C. Laasch and M. H. Scholl. A Functional Object Database Language. In Proceedings of the 4th Int'l Workshop on Database Programming Languages, pages 136--156, New York, August 1993. Springer.

....compromising type safety. On the other hand, this solution does not help the programmer since it makes modelling the application domain very hard; the demigration problem has simply been avoided. DOOR, BCOOL The database object model DOOR [25] and the functional object database language BCOOL [15] o er migrators that allow objects to gain and loose types freely. References that became ill typed due to an object dropping a type are set to a null value. However, this requires to check the whole database for such references and therefore does not scale well. LOOM The knowledge representation ....

....the demigration problem but concentrate on issues like positioning of derived classes in the class and type hierarchy, combining constraining with extension, and updatability of objects in derived classes. In [14] views can be used as classes; invalid references are set to a null value like in [15], requiring a full scan over the whole database. Database standards The ODMG standard [6] does not treat sets of objects as classes, whether de ned using OQL or not; instead it uses the term class to mean abstract data type implementation . It does not even use the term view and lacks ....

Christian Laasch and Marc H. Scholl. A functional object database language. In Catriel Beeri, Atsushi Ohori, and Dennis E. Shasha, editors, Proceedings of the 4th International Workshop on Database Programming Languages, Workshops in Computing, pages 136-156. Springer Verlag, August 1993.

....can therefore use a static type check without compromising type safety. On the other hand, this solution does not help the programmer since it makes modelling the application domain very hard. DOOR, BCOOL The database object model DOOR [WCL96] and the functional object database language BCOOL [LS93] ooeer migrators that allow objects to gain and loose types freely. References that became ill typed due to an object dropping a type are set to a null value. However, this requires to check the whole database for such references and therefore does not scale well. LOOM The knowledge ....

Christian Laasch and Marc H. Scholl. A functional object database language. In Catriel Beeri, Atsushi Ohori, and Dennis E. Shasha, editors, Proceedings of the 4th International Workshop on Database Programming Languages, Workshops in Computing, pages 136156. Springer Verlag, August 1993.

....relational database systems, too. We omit this last step here. Finally, we summarize the major results of our investigations and give an outlook on future activities in Section 8. 2 Related Work 2. 1 Preparatory Work of our Own The CROQUE project is based on the COCOON (e.g. the language BCOOL [LS93] and the OSCAR [Kla92] projects in various parts. In both projects, object algebras have been developed. BCOOL is a functional language and so it is closer to the CROQUE approach than the algebra of OSCAR. Alternative storage structures for object oriented databases have been developed for ....

....in Appendix A. 4 The Logical Algebra First, every CROQUE OQL query is transformed into an expression over the logical object algebra developed in [Asm95] This logical algebra is not operation oriented like the relational algebra, but a functional one similar to AQUA [LMS 93] and BCOOL [LS93] It consists of a set of 14 basic operations (some of them being redundant) only some of which are considered here: ffl PATH: this operation represents an instantiation of a class, an implicit join of two object sets, a combination of these two, or an access to a method (still without ....

C. Laasch and M. H. Scholl. A Functional Object Database Language. In Proc. of the 4th Int'l Workshop on Database Programming Languages (DBPL), pages 136--156, New York, August 1993. Springer.

....time and transaction time. In the formal model we do not treat different granularities of times specifically. Definition 1 An extensional database instance is given by: 1. Let be a type, then v 2 dom( is a possible value for . The domain dom( of complex types is constructed as usual [LS93, RS96, BFG96] e.g. dom(set of( dom( The temporal domain is given by dom(T IME) INST ANT S [ fnowg. The domain of temporal types is given by partial functions: ffl dom(valid time of( fT IME 7 dom( g, ffl dom(transaction time of( fT IME 7 dom( g. 2. DObject is a ....

C. Laasch and M.H. Scholl. A Functional Object Database Language. In 4th Intl. Workshop on Database Programming Languages, 1993.

.... in object databases is concerned is to provide all kinds of derived information (e.g. computed attributes, views, subschemas, type inferencing, automatic classification) We have designed a prototype object database language, COOL, to prove the concepts and as an experimentation platform [25, 24, 23, 11]. Update operations of this COOL language respect all the integrity constraints, that is, they automatically propagate to all the derived concepts. The second line of evolution (database dynamics) profits from those language properties described above. Once database updates are defined formally in ....

C. Laasch and M. H. Scholl. A functional object database language. In Proc. 4th Int'l Workshop on Database Programming Languages (DBPL-4), Manhatten, New York, August 1993.

....syntax of ODL given in [Cat96] provides only very little detail on the exact semantics of the proposed object model ( formal semantics can easily be defined ) This section presents the CROQUE approach to define such formal semantics. Our formalization builds upon the BCOOL model presented in [LS93] While our primary goal is to formalize the ODMG object model, we took the freedom to modify the model in the following two major respects: 1. In CROQUE, mutable objects are atomic. The replication of large parts of the ODMG (meta ) type system according to the distinction of mutable and ....

....and by means of gain lose operations throughout their lifetime) Both features are not included in the ODMG proposal, but they are mentioned as planned for the final release. In order to provide more flexible (object preserving) query functionality, we added this from the beginning (see also [LS93, SS90] Furthermore, we adopt the BCOOL approach to arrange object types into a lattice, such that (object preserving) projections ( casts in the OQL terminology) need not be restricted to named supertypes present in the ODB schema. ODL types are formalized as follows: there is one basic sort ....

[Article contains additional citation context not shown here]

C. Laasch and M. H. Scholl. A functional object database language. In C. Beeri, A. Ohori, and D.E. Shasha, editors, Database Programming Languages (Proc. DBPL-4, New York), pages 136--156. Springer, Workshops in Computing, August 1993.

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