We believe that the idea proposed in 21 can be

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: re restricted, it provides a formal foundation based on which systems can be developed and tailored for a particular application. We believe that the idea proposed in 21] can be exploited to develop a formal account of encapsulation in ORLog. We plan to incorporate encapsulation in ORLog along this guideline in future. 7.2.4 Enhancing the ORLog User Interface The current prototype interface we have developed for Coral has several limitations. We have an elaborate plan to enhance this interface so that it becomes a practical system building tool. Some of the enhancements that we are considering are as follows. We are now working on a more user-friendly graphical user interface for ORLog. In this interface, users will be able to de ne database schema and objects, browse database, execute queries, navigate through the object structures and develop applications, all in a graphical way. Another graphical tool is being developed to track inheritance con icts at compile time so that such con icts may be resolved, if desired, by the users using the mechanisms provided in ORLog. We are also considering developing a method to ensure type safe databases in ORLog based type inference from the signatures de ned in ORLog programs. In the current state, ORLog is a main memory database. We would like to include persistence to ORLog objects. This will demand a signi cant amount of research and development since the issue of object persistence raises new issues that are currently being investigated by the database researchers. A particular issue that comes to ones mind is that what are the new issues that need to be addressed in a framework like ours where objects are viewed as relations since we take a translational approach to implementation. This almost certainly has performance related implications. Hence, a natural next step would be to implement ORLog using a direct approach and use 107 persistent objects instead of relations, as our experience grows. 7.2.5 Updates and Query Optimization So far we have only considered retrieval queries and methods that are side-e ect free. To consider methods with side-e ects would require a rm logical basis for updates. A possible course of action would be to investigate adapting ideas similar to transaction logic by Bonner and Kifer 15]. In 46], Kifer shows that such integration is possible in a logical way in languages similar to F-logic. A nal open issue is query optimization in ORLog. We believe that query optimization can now be investigated since we have a clear semantics of inheritance which most of the previous proposals lacked and rendered such study extremely hard. 7.2.6 Schema Integration and Evolution We believe that OR model and ORLog can be used for schema integration and evolution applications. The notion of withdrawal proposed in OR model may become handy in modeling such applications. Although we leave it as our future work, we can cite works that are already using similar languages and models for such applications. In 54], F-logic 47] has been used to query heterogeneous databases. Since ORLog has strong similarity with F-logic, ORLog may also be used for such applications. In fact, the language SchemaLog 51, 52] has been developed mainly for modeling schema integration and evolution applications. Again, it turns out that ORLog is able to simulate SchemaLog to a limited extent. Unlike F-logic or ORLog, in which functionalities needed for interoperability need to be simulated, SchemaLog allows for constructs for direct and e cient interoperability. We intend to explore these issues further in our future works. 108 Bibliography 1] S. Abiteboul. Towards a deductive object-oriented language. Data and Knowledge Engineering, (5):263{287, 1990. 2] S. Abiteboul and R. Hull. IFO: A formal semantic database model. ACM Transactions on Database Systems, 12(4):525{565, 1987. 3] H. A t-Kaci and R. Nasr. LOGIN: a logic programming language with built-in inheritance. Journal of Logic Programming, 3:182{215, 1986. 4] H. A t-Kaci and A. Podelski. Towards a Meaning of LIFE. Technical Report 11, Digital Paris Research Labs, 1991. 5] A. Albano, G. Ghelli, and R. Orsini. A relationship mechanism for a strongly typed object oriented database programming language. In Proceedings of the 17th International Conference on Very Large Data Bases, pages 565{575, Barcelona, 1991. 6] K. R. Apt and R. Blair. Arithmetic classi cation of perfect models of strati ed programs. In R. A. Kowalski and K. A. Bowen, editors, Proc. 5th Int. Conference on Logic Programming, pages 765{779. The MIT Press, 1988. 7] K. R. Apt, R. Blair, and A. Walker. Towards a Theory of Declarative Knowledge. Morgan-Kaufmann, 1988. 8] M. Baldoni, L. Giordano, and A. Martelli. A Multimodal Logic to De ne Modules in Logic Programming. In D. Miller, editor, Proceedings of the International Logic Programming Symposium ILPS'93, pages 473{487. The MIT Press, 1993. 9] F. Banchilhon, C. Delobel, and P Kanellakis. Building an Object-Oriented Database Sys...
View Full Document

This document was uploaded on 01/10/2011.

Ask a homework question - tutors are online