Multidatabase Interoperability

10 T he development of database systems, or DBSs, has given rise to many databases. Frequently, dozens of databases exist on a large computer and thousands of databases are accessible through computer networks. In particular, videotex systems, like Prestel, Teletel, Telidon, etc., provide hundreds of databases on almost any subject such as cinema, train, and airline schedules; banking services; and restaurant fare. An increasing number of users have an interest in simultaneously accessing and manipulating data from several databases. A user may search for restaurants through several restaurant guides or may check several airlines for the cheapest flight, or may need to extract data from a public database for his personal database, etc. The basic property of such databases is that they are independently created and administered. 1-3 Since each administrator of a database has his own database needs, databases differ physically and logically. The physical differences may concern data formats, login procedures, concurrency control, etc.4 The logical differences may concern data manipulation languages or even entire data models. Even if the participating databases all use the same data model, they usually present mutual semantic conflicts.4 These conflicts are differences, redundancies, or incompatibilities with respect to names, values, and meanings among similar data. They result from different perceptions of the same reality by different people. In the sidebar on page 13, we show examples of differences that may occur. This situation calls for a new type of system designed to manage multiple databases. Such systems have been called multidatabase (management) systems or MBSs5-a term now rather widespread. One may attempt to base the design of such a system on the idea of global schema. This schema should define from all databases a logically single, integrated database. Users should then manipulate only data ofthe global schema or ofan external schema derived from it. In both cases, they should feel as if they were in front of a classical database for which the global schema would constitute the classical conceptual schema. This is the approach taken, for instance, in MULTIBASE.6 However, it appears that the creation of a global schema is usually difficult.1'4'7'8 This is the case even if the participating databases constitute only a small number and present the same data model for the common usage. The main reason is the lack of a general solution for the semantic conflicts in a situation in which the autonomy of each of the constituent databases is preserved. In particular, if the databases disagree about a value, then there is no single integrated value satisfactory for all users. Furthermore, no general technique for updates through the global schema seems to exist. Finally, even for organizational reasons alone, a single schema for the thousands of databases on future open systems is a dream.2 A more general approach may be to assume that the databases the user may access basically have no global schema. 1,2.7,9 The user will then in general know that he faces multiple databases. The system should provide him with functions for manipulating data that may be in visibly distinct schemas and tnay be mutually nonintegrated. One may say that the con-