However the approach to implementation can be classi

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: e into existence have their unique characteristics. However, the approach to implementation can be classi ed into four distinct groups. (i) Implementation based on rewriting or translation into Datalog like languages, (ii) implementation based on extension to existing Datalog like languages, (iii) hybrid implementation, and (iv) systems based on direct implementation. In the rst category some of the systems that are known to have been implemented are OOLP+ 25], OIL 76], Logical-objects 13], LLO 56]. In the second category are the systems CORAL++ 71], LDL + + 69], Logres 23], IQL+ 1], among many others. ROCK & ROLL 10] and ConceptBase 45] are two systems that belong to the third category. We are not aware of any deductive object-oriented database systems that has been implemented directly that qualify as a member of the fourth category. We already brie y discussed about these systems in the previous chapter from a theoretical standpoint. The development of ORLog was motivated by the need for a solid formal basis and a mathematical foundation for deductive object-oriented databases so that a commercially viable prototype can be built to meet the industrial demand for advanced database systems. It was also the goal that the language and the data model on which the language is built should be as natural and intuitive as possible. Except 86 for few technical aspects we believe that we met these requirements. In practice, users of ORLog need not worry about these technical issues which were needed for the mathematical development of the language. 5.1 Related Research and Motivation The number of deductive object-oriented database systems that emerged from the multitude of research done in this area is very small. We brie y discuss one representative system from each of the rst three categories described above that are available in the literature. The goal of this discussion is to bring out the distinctions between the implementation approaches that are currently reported and practised and give a avour of each of these styles. We hope that this discussion will also bring out few advantages and disadvantages of each of these alternatives approaches. It should be clear from the discussion that follows that every approach has their strengths and weaknesses and there is no absolute yardstick against which we can brand one approach to be the best. 5.1.1 CORAL++ Coral++ 71] is an integration of Coral with C++. The goal is to use an existing object model and perhaps an existing imperative language with its associated type system to extend the functionality of the Coral system. This allows Coral++ to exploit features in C++ and vice versa. Note that Coral is implemented in C++, hence an integration of the two is natural and practical. Coral++ separates querying from creating, deleting and updating databases by providing separate sub-languages for the latter. It also relies on C++ for maintaining type safety, inheritance, encapsulation, and most other object-oriented features of the language. The overall goal is to use Coral run time system as much as possible and automatically invoke codes that handle object-oriented aspects of the language internally that are treated as external functions. Users need to de ne class de nitions, methods, etc. in a C++ style sub-language, and can write C++ expressions in the rule bodies. A database in Coral++ is required to be compiled along with the class de nitions and basic Coral++ system so that the augmented Coral++ system becomes aware 87 of the new user de ned classes. Then a translation is applied to so that (i) for each method invocation and attribute access in Coral++ rule, external C++ predicates can be generated by the preprocessor that perform the relevant task at run-time, and (ii) that every method invocation can be replaced by these external predicates. Finally, the translated program is evaluated using the Coral interpreter. Note that the issues related to inheritance, encapsulation, etc. are resolved by C++ during compilation and translation, while Coral is responsible for deductions only. 5.1.2 OOLP+ The goal of this work is to implement an object-oriented logic programming language using only existing technologies, namely Prolog. The main idea is to de ne a suitable translation procedure for an object-oriented language, called the OOLP+ 25], into Prolog. Hence, objects are clearly viewed as predicates or relations in the target language. OOLP+ provides constructs to de ne classes, objects and instances, methods, etc. in a key-word based language. In this language superclasses, instance objects, instance and class variables, and methods for an object class can be de ned. Methods are de ned using an extended syntax of Horn clauses. Limited amount of method ordering is possible in a speci cational way. Method overriding is possible also in a limited way using Prolog cut. Then given an OOLP+ program, the translation is applied and a Prolog program is obtained that captures the intended meaning of the OOLP+ program. T...
View Full Document

Ask a homework question - tutors are online