Next Generation Database Management Systems ... - Semantic Scholar

Next Generation Database Management Systems Technology* Michael L. Brodie, GTE Laboratories, USA Francois Bancilhon, Altair, France Craig Harris, Ontologic, USA Michael Kifer, SUNY Stony Brook, USA Yoshifumi Masunaga, U. of Information and Library Science, Japan Earl D. Sacerdoti, Copernican Group, USA Katsumi Tanaka, Kobe University, Japan

ABSTRACT Database management systems (DBMS) technology is advancing in two directions. The evolutionary or parochial direction raises questions such as: How can DBMS technology meet current new application requirements? What features might it offer users? The revolutionary direction raises questions such as: What requirements will the next generation of computing, applications, and users place on DBMS technology? How can DBMS technology contribute to the next generation of computing? Current requirements pose known but difficult technical challenges as opposed to unknown future requirements which potentially pose greater challenges and will have a larger effect on DBMS technology. This paper considers both directions in speculating on advances in DBMS technology and relates them to current DBMS research, development, and product directions. The paper expresses the opinions of panelists on the above topic as discussed at the First International Conference On Distributed and Object-Oriented Databases, Kyoto, Japan, December 1989. 1. Directions For Next Generation DBMS Technology (Michael L. Brodie) Next Generation DBMSs: The Evolutionary Direction What will next generation DBMSs look like? With the widespread use of DBMSs (over 5,000,000 in use) and an annual growth of over 20%, conventional DBMS technology can be said to be mature. However, less than 10% of business and scientific data is managed by DBMSs due, in part, to limits of current DBMS technology. This underscores the need for next generation DBMS technology. As a basis for discussion, consider the following hypotheses for two directions for the development of the next generation of DBMSs: the evolutionary or parochial direction and the revolutionary direction. First, consider the evolutionary direction hypothesis: * W. Kim, J-M Nicolas, S. Nishio (eds) Deductive and Object-Oriented Databases, Elsevere Science Publishers, Amsterdam, The Netherlands, 1990

1

"DBMS technology will continue to evolve the scope and efficiency of DBMSs for new types of data, new functionalities, new implementation techniques, new computing paradigms, and new computing architectures. The evolution will be slow. There will be no next generation DBMSs in the sense that relational DBMSs are replacing older DBMS technology. Extended relational DBMSs will be the primary DBMS type in the mainframe DBMSs marketplace until the year 2000. Current DBMSs will incorporate functionality and implementation techniques from the different approaches to advanced DBMSs (e.g., deductive, object-oriented (OO)1 ) and from other technologies (e.g., programming languages, AI, operating systems, and distributed computing). Current DBMSs will slowly evolve to become effective in distributed, heterogeneous, and active contexts. The marketplace will choose the features and the developers will incorporate the chosen features in efficient ways (e.g., DB2, Ingres, Oracle, or Sybase plus objects, inheritance, deduction, non-standard data types, multimedia support). While developers enrich conventional DBMS technology, researchers will integrate inherently incompatible approaches such as deductive and OO." "New deductive and OO DBMS products will be the source of and testing ground for enhancements but will themselves find acceptance only in narrow application domains. By the mid 1990's, OO DBMSs will become efficient, robust, more general purpose, and will have an underlying OO theory. Mainstream DBMSs will not be deductive but they may be OO. Just as in the early days of relational and network DBMSs, there are DBMS wars on SQL-based DBMSs (e.g., exaggerated and unsubstantiated claims for performance, tool sets, interoperability) and OO DBMSs (e.g., features, performance, tools sets, applicable application domains). The lack of precision in the use of terms such as pure relational, extended relational, and OO is already harmful and unproductive. The lack of experience with new application domains, new techniques (e.g., OO) and the lack of generic solutions to advanced DBMS problems (e.g., query optimization, concurrency control) make it very difficult to evaluate these evolutionary approaches to next generation DBMSs." Approaches To Evolutionary DBMSs There are many approaches to next generation DBMS technology including OO, deductive, extensible relational, extended relational, DBMS toolkits, active, homogeneous and heterogeneous distributed, intelligent, expert, and knowledgebase. There are almost as many OO DBMS prototypes as there are DBMS research groups. By 1991 there will be over 13 OO DBMS products (i.e., Ontologic's Ontos, Servio Logic's GemStone, Innovative Systems' Vision, Objectivity's Objectivity/DB, Graphael's G-Base, Object Design's ObjectStore, Symbolics' Statice, Hewlett-Packard's IRIS, Object Sciences' Object-Base, Mdbs's Object/1, Altair's O2, Itasca Systems Inc.'s Orion II, and Juniper Software's Persist). There are a dozen deductive DBMS prototypes, including ECRC's EDUCE and MEGALOG, MCC's LDL, UCLA's Tangram, Stanford's NAIL!, INRIA's ISIDE and RDL1, University of Aberdeen's PERLOG, Oki-ICOT's PHI, and ICOT's CRL. But, there are few products or plans for products (e.g., MAD's Declare, Quintus' Quintus Prolog, Graphael's G-Base with 1 In late 1989, Oracle and Ingres announced DBMS products with limited support for objects.

2

its Prolog query feature, University of Melbourne's Aditi, Seimens' DB Prolog, and Samsung's/Bellcore's LAURE). There are several, extensible relational DBMS prototypes (e.g., Berkeley's Postgres, IBM's Starburst) and as many extended relational DBMS products (most relational DBMS products claim to be extended in some way). There are several DBMS toolkit prototypes (e.g., Wisconsin's EXODUS, University of Texas' Genesis) but no such products. There are several active DBMS prototypes (e.g., Xerox's HiPac) but no such products. There are many homogeneous and heterogeneous distributed DBMS prototypes (e.g., IBM's R*, MCC's Shared Heterogeneous Data Base, INRIA's Sirius-Delta and MRDSM, University of Maryland's ADMS+) and many so-called distributed DBMS products (e.g., Ingres' Ingres Star, Oracle's Oracle Connect, Sybase's Sybase, IBM's DB2, Data Integrator's Mermaid). Other recent approaches to advanced DBMSs include intelligent DBMSs, expert DBMSs, and KBMSs (KB = knowledgebase) however, there are few prototypes let alone products in these areas. Next Generation Computing: The Revolutionary Direction What will the next generation of computing look like? Advances in social, political, and technical realms provide challenges and opportunities and call for change. Changes include the ways we think, communicate, conduct business, and spend our non-working time. What will this future look like and what role could DBMS technology play in this future? To understand the opportunities and related requirements for DBMS technology consider the potential technological environment and potential applications. The American National Science Foundation sees five new technologies as being the most influential in shaping our future: massive computing power (e.g., supercomputers), massive storage capacity (e.g., optical storage), far reaching sensor technology, neural nets, and powerful personal workstations. These technologies will change the infrastructure of science, technology, business, and home life. Mathematicians, medical researchers, engineers, scientists, office workers, shopkeepers, and homemakers will use computers as assistants or even guides in their tasks. New application domains (e.g., multimedia, geographic information systems, office and factory automation, telecommunications automation, automation of business, consumer functions, entertainment, and education) and new computing paradigms and requirements (e.g., distributed, collaborative or group work; integrated or global information systems; the need to compute across organizational and geographic boundaries, and to use existing and new computing resources in combination) illustrate potential next generation applications. Desktop or kitchen counter workstations will provide access to vast libraries of sophisticated tools, knowledge, and massive amounts of information. The libraries will exist, transparent to the user, on their workstation and via advanced communications, on millions of computers throughout the world. These future technologies and applications will not only affect the way people interact with machines, but will also affect the ways that people interact with each other. What will be the requirements for storing, accessing, manipulating, managing, and controlling these massive amounts of distributed information and related processing?

3

Now consider the hypothesis for the revolutionary direction in which DBMS technology will be a major contributor to the next generation of computing. "The next generation of computing will be based on a new paradigm of computing which is evolving from current concepts in distributed computing, interoperability, and collaborative or cooperative problem solving. The new paradigm will involve vast numbers of heterogeneous (e.g., relational, deductive, OO, functional), distributed, co-operating resources (e.g., humans, computers, information bases) in massive computer networks. Each resource will contribute one (e.g., the system itself) or more (i.e., the system's components) objects to a global object space. The object space will provide the union of the available functionalities and the most efficient implementations. A global object manager will support efficient and intelligent (e.g., transparent) interoperability between arbitrary computing resources. Hence, resources can be combined in unanticipated ways to meet new application requirements and opportunities. The object space will be based on the OO approach and will be supported by a generic technology which will provide a tool kit for combining computing components in arbitrary ways. In this context, the notion of a single DBMS as a separate component serving a wide range of applications will cease to exist. Instead, multiple DBMSs will support small sets of applications." "Current DBMS technology will contribute significantly to the management and support of the distributed, heterogeneous (multi-paradigm) object space as will operating systems, programming languages, distributed computing, and other technologies. DBMS technology will be extended to provide the basic support for a global object management system. Similarly, operating systems technology will be extended to provide basic support for global, OO, distributed or network operating systems functionality. At the global level of the object space, DBMS and OS features will be integrated. At the individual systems level, local and homogeneous distributed DBMSs, as described in the evolutionary direction above, and local operating systems will continue to exist. The object space will be based on a yet-to-be-developed formulation of the OO approach or some other approach that will provide transparency over differences in component systems. In this context, the essential contribution of DBMS technology will be the underlying systems technology and possibly, a global object model with which to express the functionality of the object space." Approaches To Next Generation Computing By the mid 1990's the notion of an object space will become an architectural paradigm which will provide the basis of several major computing environments. These environments will provide practical interoperability with limited efficiency, intelligence, and distribution. There are several research, product, and standards development projects exploring different aspects of this vision of next generation computing. The projects originate in disjoint technologies including databases (e.g., GTE's Distributed Object Management [MANO88], Open Systems Liaisons Object Mapper, Stanford's Mediatorbased SoD and KSYS, University of Florida's Federated Information Bases), programming languages (e.g., MIT's Argus), operating systems (e.g., Open Systems Foundation's OSF/1, APM Ltd's ANSA), communications (e.g., Open System Liason's Software Bus), software engineering (e.g., Norway's Eureka Software Factory), artificial intelligence (e.g., Intellicorp's Intelliscope), and in new technologies that combine features of several

4

technologies (e.g., Yale University's LINDA). DBMS technology will contribute technology for features such as persistence, sharing, object management and migration, optimization, transactions, recovery, and heterogeneous distributed databases. Much of the work in the evolutionary DBMS direction is highly applicable in this context. Research Questions and Approaches To understand the technical challenges to be addressed and the research needed for both directions, we must first develop a vision of the next generation DBMS. As DBMSs grow beyond their role as central repositories of passive data objects, what concepts and questions arise? What does it mean to support a distributed object space of passive and active objects? What is an active object? What is an active DBMS? What functions must they provide? What computing paradigms must be supported? How can a DBMS support multiple paradigms (e.g., languages and execution models)? In what architectures must they take part? What modelling concepts, tools, and techniques will be needed? How will future applications be designed and developed? What systems functions will be called for (e.g., concurrency control, search, browsing, object migration, query optimization)? What will performance mean in future application domains? How are the research questions being followed and what are the major approaches? It is important to evaluate the approaches to DBMS technology, their intended contributions, their relative benefits and limits, and the potential of successfully completing their goals. What are their intended contributions? How do they differ (other than terminologically)? Are they complementary? Can the intended results be integrated? Why will one approach, as opposed to others, provide the needed result? Why will one approach be adopted over others? 2. Performance Techniques For OO DBMS (Craig Harris) The revolutionary direction is extremely desirable and technically possible within ten years. Challenges will arise in forming agreements between people to permit the systems to cooperate. Examples where agreement is called for are object reference semantics, object schemas/dictionaries, data representations, security, performance, and commit protocols (e.g., participating DBMSs may have to export their protocols to a global manager). Beyond ten years we may have cognizant systems aware of the needs of users and other systems with they interoperate. The evolutionary approach will evolve as described in the hypothesis. There will be a great emphasis on performance. There are many new, universally applicable performance improvement techniques such as caching, clustering, and network buffering. There are littleknown techniques used in several OO DBMSs that produce radical improvements over relational and earlier OO DBMSs. Pointer swizzling involves translating database references (OIDs) to virtual memory references when moving objects into virtual memory. Applications then operate at virtual memory speeds which is an improvement of three orders of magnitude over normal pointer dereferencing. A second technique is the avoidance of joins in OO DBMSs since object pointers reference objects directly. Within a few years,

5

OO DBMSs will operate at near-file system speeds, about 100 times that of relational DBMSs. These among other reasons will make OO DBMSs appealing for performance and for modelling requirements. A possibly even more important factor will be the potential of reducing software lifecycle costs through reusability enabled by abstract data types. Hence, OO DBMSs may become as widely used as relational systems by the mid 1990's. 3. Integrating Deductive and OO Paradigms (Michael Kifer) The two hypothesized directions will co-exist for 10 to 15 years. The evolutionary direction will produce practically useful results but no major breakthroughs. Breakthroughs and related commercial systems will come by the year 2000 from the revolutionary approach in developing new database programming paradigms. Future database languages will be general purpose programming languages, transparently supported by traditional database amenities such as persistence and concurrency control. The next generation of such languages will have an open architecture which will simplify the addition of new languages. Hence, there will be a host of compatible database programming languages. The next generation of database programming languages can be classified along two axes (see Figure 1). The first axis is for the data representation paradigm with relational at one extreme and OO at the other. At the logical level in the relational paradigm, data is grouped by properties. For instance, information regarding the same person may be split among different relations, such as EMP, MGR, PROJ, each describing different properties of persons. But, records pertaining different persons but addressing the same property (e.g. project assigned to the person) will be grouped together in one relation (PROJ here). At the logical level in the OO paradigm, data is grouped by objects. The second axis is for the programming paradigm with declarative and the imperative programming modes at the extremes. Together the axes classify four language types. Pascal-R and GLUE (NAIL!-2) are imperative relational languages. Deductive database languages, such as NAIL! [MNSU87] or LDL [NT89], are declarative relational languages. OO DBMS (e.g., O2, Ontos) are imperative OO languages. The fourth, and a new language class is both declarative (or deductive) and OO (DOOD). DOOD includes such languages as F-logic [KL89], O-logic [KW89], C-logic [CW89] and to a certain extent, IQL [AK89].

6

Programming Paradigm

DOOD (F-logic, O-logic, C-logic, IQL)

Deductive DB (LDL, NAIL!) Declarative

Pascal-R GLUE (Nail-2)

Imperative OODB (O , Ontos, . . . ) 2

Imperative

Representation Paradigm Group by Properties (relational approach)

Group by Objects (O-O approach)

Figure 1. Programming vs Representation Paradigms

Contrary to what is often being claimed, F-logic, O-logic, and C-logic prove that the deductive and OO paradigms are compatible. Unfortunately, few researchers have tried to define the notion of object-orientation. Most such attempts are non-systematic. For instance, the Object-Oriented Manifesto [ABDD89] describes OO languages by their most characteristic properties. They arbitrarily distinguish between mandatory and optional properties. Such works do not see object-orientation as a data representation issue. Once the decision is made to group data by objects, a logical next step would be to explore the potential of the OO representation. One can now talk about such concepts as object names (or object identities), hierarchies of classes, inheritance, and typing. The difference between optional and mandatory characteristics of object-orientation becomes merely an issue of the relative importance of there features of the OO data representation. The degree of objectorientation of different languages can now be measured with respect to object structure used in the language. No single paradigm is universally appropriate or acceptable hence, multi-paradigm languages may be better sometimes. Some arguments for multiparadigm languages are: pure OO or relational languages are not flexible enough; some knowledge is naturally 7

imperative whereas some is naturally declarative; personal and political preferences may call for several paradigms be supported. Among the four classes of languages, the DOOD class is particularly important, since it has the benefits of declarative and OO paradigms. The declarative paradigm is specificational, high-level, extensible, modifiable, and easy to understand. The OO paradigm provides the richness of object structure and offers the potential of integration, through methods, with other languages. These benefits have been proven in several different contexts (e.g. AI, databases, programming languages). This vision of the next generation database programming languages calls for research in several directions. First, logical foundations of OO DBMS must be completed. This could be done by 1992. Recently, designed logics (C-logic, O-logic, and F-logic) are promising developments in this direction. Second, there is a need to understand the principles behind designing clean imperative OO and relational database languages. The GLUE language project (a successor of NAIL) is working in this direction. The OO end calls for like efforts.Third, principles of integrating the four classes of languages must be explored. There are clean ways to integrate imperative and declarative languages within the relational and OO domains separately. Integration of relational languages with declarative OO languages does not present problems. However, there are no known ways to integrate OO languages within relational languages. Lastly, optimization of programs in each language class must be understood. 4.

Multimedia Requirements For Next Generation DBMSs (Yoshifumi Masunaga)

Both hypothesized directions are desirable and probable The primary challenge is integration which may be addressed with the OO approach. Next generation DBMSs (e.g., multimedia databases) call for the integration of all approaches to databases. Different approaches to databases are appropriate for different problems. Some requirements of a multimedia electronic library include: multiple data types on various media; complex data structures; integration of multiple databases; integration of database and programming languages; access to remote data; deduction capabilities; and temporal and spatial semantics and data. OO DBMSs are being used to address the first four challenges. Deductive capabilities are needed in most applications (e.g., in each database in a multimedia application). Hence, they should be integrated with the other approaches. It may be appropriate to enhance particular approaches depending on the intended application domain. For example, relational DBMSs are appropriate for business data processing whereas OO DBMSs may not be appropriate. OO may be better suited for nonbusiness data processing (e.g., CAD) and may be difficult to integrate with traditional data processing languages (e.g., COBOL).

8

OO will play a large role in both directions and in the integration of the approaches. Given the large number of reasonable OO data models and their differences (e.g., classes versus types), it is too early to identify a standard OO data model. The widespread use of C++ may make it a de facto OO data model/language standard. Hence, it may be important to explore language independent approaches to OO data model definition or the development of a multi-paradigm approach. 5. Integrating Software technologies (Earl D. Sacerdoti) Both hypothesized directions are desirable and will take ten years to complete. We must consider non technical aspects of the integration and adoption of any new technology. A new software technology (e.g., DBMSs, OO DBMSs, deductive DBMSs, object spaces) is only a small fraction of the impetus behind, or rationale for, changing system utilities. Compatibility with existing hardware, software, personnel and procedures, the level and nature of training of the user community, and management styles imposed by the technology are of at least equal weight. Organizations use systems despite new technology, not because of it. During research, development and early deployment, a new technology is at the center of its users' universe (the Ptolemaic view). This is needed to validate the concepts and to focus on the advantages and new problems. To transfer the technology into real use, we need to take the Copernican view. It must be integrated as a technology peripheral to the already installed technology base. The evolutionary direction will take ten years owed to the conservative nature of software users (e.g., most of the information processing community is not yet using relational databases). Because of the need to integrate software with the installed base, upward compatibility is critical. Distribution will become critical for robustness and natural geographic distribution. As distribution becomes critical, other technologies (e.g., communications, networking) may become more important that database technology. Aspects of the OO approach and OO DBMSs will be incorporated into general computing (e.g., liberalization of data types). However, the deductive approach will not become widespread. Users don't trust it and they do not see the need for deduction in applications. But, deductive capabilities are useful and could become integrated into standard computing if it were made invisible. Hiding may also be called for with the OO approach. Proponents of OO and deductive databases have argued strongly for their corresponding DBMSs. However, they did not justify the requirement that these capabilities be architecturally within the DBMS (as opposed to, for example, being in a language). In the revolutionary direction will see heterogeneous integration in limited contexts. For performance and political reasons, it will first happen within small versus enterprisewide systems. Now, integration appears to be more important than efficiency. Various stages of inter-computing will precede the full revolutionary vision. These include making platforms work together, users work together, and making, operating and other systems work together. OO approaches seem to be contributing to these efforts.

9

Acceptance of next generation DBMSs poses development challenges including: upward compatibility, higher-level OO languages than C++, making new features optional, availability of development and maintenance aids, validation of approaches (e.g., deductive), and making database semantics explicit so that, they can be used in modelling business rules. 6. OO DBMS As An Object Base Environment (Katsumi Tanaka) Next generation DBMS technology will develop as described in the hypotheses. OO DBMSs should be extended to object base environments as platforms for software and information-base development. The object base environment will have an object base manager, an OO database programming language, and an OO user interface. The following research issues arise for object base environments. First, OO DBMSs are more than OO programming languages plus minimal persistence and sharing. Database applications need database concepts not called for in other areas (e.g., views). Research must identify these concepts and integrate them with non-database OO systems. Second, we need methodologies for object base design. Third, we need an environment for database application development which is applicable for each type of DBMS. It should include a database programming language with no impedance mismatch and class libraries for database application components. Success of the next generation DBMSs calls for major problems to be solved in areas outside DBMS technology (e.g., extensions of OO programming languages, hypermedia technology, CIM databases) and at the interface between technologies. The DBMS community must explore non-DBMS domains otherwise, they will be addressed outside the DBMS community. Problems on the interface of technologies include: the need for a tight integration of hypermedia and OO DBMSs that eases design, use, and maintenance of hypermedia applications; Where is the deductive capability to be placed? Should a deductive component be built on top of an OO DBMS or as a component within an OO DBMS? 7. OO versus Deductive Database Systems (Francois Bancilhon) Relational systems will not evolve significantly. First, it is difficult to maintain the simplicity and cleanliness of the relational interface when adding new features. Second, performance is the only major improvement needed for relational systems to improve their primary application domain, business applications. Lastly, researchers are not highly motivated to make relational extensions which will be left to the vendors. It is too early to mix OO and deductive technology. It is already difficult to integrate all OO concepts in an OO system without the added complexity of a deductive component which is even in a different paradigm. The result will be confusing to users. OO and deductive are competing technologies. Whereas there are several definitions of OO DBMSs [ABDD89, ZM89]; there is no clear definition for a complete deductive database system. Is

10

it a database system or a deductive system? If they are DBMSs, then benchmarks are called for to measure system capabilities and to provide a basis of comparison. Deductive and OO technology can be compared in terms of three characteristics. Their status can be early, mature, or finished. Applications areas are horizontal (e.g., systems and interface implementation, application programming) and vertical (e.g., business, CAD, CASE). Deductive technology is still in an early stage of development (e.g., lack of effective implementation techniques). Its vertical applications are unknown and the horizontal applications are application programming and data manipulation, due to its declarative nature. So, deductive DBMSs will not appear before the mid 1990's. Aside from the above characteristics, there is little demand for it from the development community. Subjectively, logic programming is less popular than OO programming. In the long term, it is the most promising technology since it transfers most of the work to the machine. Hence that is where research effort should be focused. OO technology is mature. It applies to all vertical applications, including business data processing, and to systems, interface, and data manipulation on the horizontal application axis. OO DBMS products exist and are in demand. Unfortunately, OO DBMSs are ahead of the technology, but this experimentation will pay off. OO DBMSs will be applied in special purpose applications due to the lack of acceptance of new technology, as Sacerdoti pointed out, in conventional database application areas. Acceptance will come after the mid 1990's, because of the solutions that will be found by researchers and the consequent validation of OO DBMS technology. There is nothing inherently difficult about OO DBMS performance. They will ultimately outperform relational DBMSs. Two problems dominate the development of next generation DBMSs. First, organizations are building and selling DBMSs before the technology and systems quality are validated. Second, there is considerable confusion being generated regarding the features of DBMSs (e.g., relational and other systems being promoted as being OO). There is a clear need for research in both deductive and OO database technologies. 8. Questions and Answers Francois Bry: Since relational and deductive systems are based on the same declarative paradigm, it is contradictory to say there are many relational and no deductive applications. One deductive application involves a public transportation system in which the database was reduced by a factor of 600 by replacing a large amount of data by a small number of deductive rules (e.g., "if it is a holiday, the holiday schedule applies" versus storing each day's schedule). There are many examples of systems calling for business or government rules (e.g., hiring policies, British Nationality Act) that are naturally expressed in deductive databases. Much can be done with simple deductive systems without complex recursion and negation. Deductive databases are not popular owed to problems of introducing new technologies, as Sacerdoti described, and because of the current lack of performance to be gained by query optimization needed for deductive databases. In this regard, many implementation techniques for relational systems have yet to be applied to deductive systems.

11

Carl Hewitt: Is there a lack of distribution technology for OO or deductive databases? Can technology be developed to support distributed deductive OO databases? Francois Bancilhon: It is a hard problem that few people are addressing. Craig Harris: Most OO DBMSs claim to support at least a client-server form of distribution. However, the technology is not in place to distribute objects around a distributed system for execution. Earl Sacerdoti: Distribution may call for more intelligent networks instead of more intelligent databases. One such OO networking system facilitates distribution in factory automation. Won Kim: Distribution technology does exist for OO DBMSs. For example, Orion-2 is a prototypical distributed OO DBMS at MCC and Orion-II will be a distributed OO DBMS product. Distributed relational database technology applies to distributed OO DBMSs. Yehoshua Sagiv: OO DBMSs will address the needs of large databases due, in part, to their marriage between complex objects and proven software technologies. In the future, vast numbers of people will use personal databases (e.g., in their offices) for which they will want declarative languages, such as deductive databases provide, as opposed to imperative languages of OO systems. Hence, OO DBMSs should be designed to accommodate declarative languages. The development of a logic for OO databases is a step in that direction. Carlo Zaniolo: OO and deductive databases are incomparable since they address different goals. OO address such areas as systems issues, integration of databases and programming languages, and encapsulation, whereas deductive databases address areas such as ease of use and programmability. A good application for deductive database languages is (rapid) prototype development for which fourth generation languages are currently used. Deductive languages are more expressive and usable, however, the development community is unfamiliar with deductive languages for them to judge or use deductive languages. Elisa Bertino: Relational DBMSs are only now beginning to be used in information processing, as Saerdoti described. Because of the slow adoption rate of new technologies and to the small number of organizations doing applications to which OO DBMSs are being directed, it seems that OO DBMSs will take a long time to be adopted. Craig Harris: There is a very large market for relational systems. There is also a large enough market for OO DBMSs to keep several companies in business. The market started with CAD, CAM, and CASE. New applications for which OO DBMSs are highly applicable are being found continually (e.g., medical, imagery, design, VLSI, financial analysis). Other DBMSs were never considered for many of these applications because of their unique requirements. Francios Bancilhon: There are many new applications being developed around the world (e.g., 50% of those being developed on the 600,000 Unix workstations worldwide). OO DBMSs may be highly acceptable or even necessary in many of these application. This is the case in applications such as systems integration.

9. References

12

[ABDD89] M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier, and S. Zdonick, "The Object-Oriented Database Systems Manifesto," in W. Kim, J-M Nicolas, S. Nishio (eds) Deductive and Object-Oriented Databases, Elsevere Science Publishers, Amsterdam, The Netherlands, 1990 [AK89] S. Abiteboul and A P.C. Kanellakis, "Object Identity as a Query Language Primitive," Proceedings of the ACM SIGMOD Conference, 1989, ACM, New York, 159173 [CW89] W. Chen and D.S. Warren, C-logic for Complex Objects, Proceedings of the ACM PODS Conference, 1989, ACM, New York, 369-378 [KL89] M. Kifer and G. Lausen, "F-Logic: A Higher-Order Language For Reasoning about Objects, Inheritance, and Schema," Proceedings of the ACM SIGMOD Conference, 1989, ACM, New York, 134-146 [KW89] M. Kifer and J. Wu, "A Logic for Object-Oriented Logic Programming (Maier's O-logic Revisited)," Proceedings of the ACM SIGMOD Conference, 1989, ACM, New York, 379-393 [MANO88] F. Manola, Distributed Object Management Technology, Technical Memo, GTE Laboratories, Inc., Waltham, MA, June 1988 [MNSU87] K. Morris, J. Naughton, Y. Saraiya, J. Ullman, and A. Van Gelder, YAWN! (yet another window on NAIL!), Technical Memo, Computer Science Dept., Stanford University, 1987 [NT89] S. Naqvi and S. Tsur, A Logical Language for Data and Knowledge Bases, Computer Science Press, Rockville, MD, 1989 [ZM90] S. Zdonick and D. Maier, "Fundamentals of Object-Oriented Databases," in S. Zdonick and D. Maier (eds.), Readings In Object-Oriented Database Systems, Morgan Kaufmann, San Mateo, CA, 1990

13