* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Updatable Views in Object-Oriented Database Systems
Survey
Document related concepts
Microsoft SQL Server wikipedia , lookup
Oracle Database wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Functional Database Model wikipedia , lookup
ContactPoint wikipedia , lookup
Clusterpoint wikipedia , lookup
Relational model wikipedia , lookup
Transcript
Mapping Heterogeneous Ontologies Through Object Views Kazimierz Subieta Polish-Japanese Institute of Information Technologies & Institute of Computer Science PAS, Warsaw, Poland Poland [email protected] defined by joins). Moreover, database applications are written in programming languages (such as C/C++), which are tightly coupled with physical data structures. The level of data independence of such languages is too low to process imaginary data. Additionally, various kinds of semantic, representational and schematic discrepancies among heterogeneous data require other features of views (such as full algorithmic power, access to metadata, reflective capabilities, recursion, and others) which are beyond the intellectual scope of the relational model, relational DBMS, and current theoretical approaches to databases. Hence the mentioned above qualities of views are actually wishes. They are not available for majority of applications. Most frequently, in addition to views written in SQL and stored in a database, the applications involve proprietary solutions written in lower-level languages. For instance, such an approach is assumed in OMG CORBA [OMG95], where interfaces in IDL can be considered virtual views, but mappings between stored and virtual objects (i.e. adaptors and wrappers) are to be written in a regular programming language. In Oracle new ideas are implemented; in particular views with a check option (preventing undesirable side effects during view updating) and special options ("do instead of" triggers) making it possible to control translations of view updates. Perhaps Oracle is also pioneering the integration of views into fully-fledged language for programming database applications (PL/SQL). There is also an advanced proposal concerning views in the emerging SQL3 standard [SQL99]. The user can define views with a check option, updatable, insertable and recursive. Many very particular details of the proposal (10 pages of specification), unclear compatibility with the specification of other constructs of the language (ca. 1100 pages) and the eclectic nature of the standard cause doubts if the idea is reasonable and implementable. Recently significant research is also done into object-relational mapping through special views, e.g. [BKSW91, FaRi97, HaKe95, PMSL94, VeAp95]. The approaches address current need to integrate relational databases with object-oriented programming languages and other tools, e.g. CORBA ORBs. The development of object views is still in the research stage. To the best of our knowledge, no commercial OODBMS offers views. Some capabilities are introduced in the ODMG standard [ODMG00], but Abstract - The traditional concept of a database view is currently under influence on new ideas, in particular the CORBA approach to distributed objects, objectoriented databases, XML and other Web technologies, semistructured data, and autonomous mobile agents. These new trends cause widening the scope of database views by novel features, which are beyond the current theoretical and conceptual paradigms of database systems. New concepts related to database views are wrappers, adaptors, mediators and ontologies. The paper discusses features of object-oriented views, which have to fulfill new needs and expectations. The discussion is focused on integrating heterogeneous databases into a federated database. Emphasis is put on relaxing the database view concept from limitations induced by stereotypes inherited from the relational data model, to fulfill nowadays requirements concerning efficient integrating heterogeneous data sources and services. 1 Introduction A database view defines virtual data that are derived from stored data and are compliant to the assumed data model. Such virtual data have to be queried and updated similarly to stored data. From the user viewpoint there should be no differences concerning retrieval and manipulation of stored and virtual data; this property is known as transparency of views. Virtual transparent database views are considered very important for current and future database technologies. The literature presents many expectations concerning such views, which include their potential as an integration tool for heterogeneous database federations. Views allow the designers to map (heterogeneous, autonomous) local databases according to a common federated schema [ChMe97, DGS94, Elia95, JoRi98, KDN90, Paep93, SIMB94, SST92]. Further expectations concerning views concern a higher level of data independence, known as schema evolution [Bell97b, Brat92, BFK95, KaEa98, LDB97]. Views enable the designers to change a database schema without affecting already written applications. Views are a standard functionality of SQL-based DBMS-s. However, many conceivable mappings between stored and virtual data cannot be expressed due to the limited computational power of SQL. View updating is usually limited to views defined as vertical/horizontal restrictions of stored relations (plus other limitations; Oracle, however, allows limited updating of views 1 Local, autonomous databases supported by local database management systems. essentially reduced to macro-definitions (the “define” clause of OQL). The approach has many limitations and open issues [Rupp98]. There are several prototypes, in particular, a prototype for O2 [Souz95], MultiView [Rund94, Rund96, KuRu96] and stored functions in Loqis [SMA90, Subi91]. There are also many other papers (mostly theoretical), in particular, [AbBo91, ABS97, BaKe93, Bell97a, Bert92, BuFa99, Daya90, GeZi94, GBCG97, GPZ88, HeZd90, KiKe95, LaSc91, LTY93, MaBa91, SLT90, SLT91, SuMi89, SAD94]. The proposals are incompatible and tightly bound to a particular data model or formalism; thus comparing and evaluating them is not easy; see [Mots96]. In our opinion, the state-of-the-art concerning utilization of object views as tools for developing heterogeneous database federations should be considered premature at this time. In this paper we try to recognize major issues that has to be considered and discuss various research aspects of object views. The rest of the paper is organized as follows. In Section 2 we present architectural issues concerning federated databases. Section 3 is devoted to novel concepts: wrappers, mediators and ontologies. Section 4 discusses the potential of object models as abstract canonical ontologies. The section presents also various aspects of object views. Section 5 discusses the view updating problem. Section 6 concludes. A local database is accessed by a local application programming interface (API), which exists before integrating the database within the federation. A local API is used by a wrapper, which is dedicated to a federated database. The role of a wrapper is to map a local API into a programming interface expected by the federated system. A wrapper makes it possible to build a schema mapping between API of a federated system and API of a local system. On the side of the federated system there is an API_f of a federated system. API_f is used by global applications to access resources stored in local databases. The access supports transparency: from the point of view of a programmer all local resources are seen as a single centralized database. There is some network protocol, which is prepared to connect a global application to local resources. Global applications may need an own working database. In particular, it is necessary for storing copies of data sent from local databases. Fig.2 present a more detailed view on the architecture from the position of an administrator of a local database. 2 Architectural Issues Local database Local export schema (schema mapping) Export subschema 2 Export subschema 3 R Forbidden Forbidden Forbidden Forbidden R/W Interface IB1 R/W Forbidden R/W ... ... ... ... View V1 Forbidden R R R/W Forbidden Forbidden Interface IA2 API Wrapper ... Export subschema 1 Interface IA1 Obiekty A Obiekty A Obiekty Data A A Obiekty A Obiekty A Obiekty Data B A Local export subschemata (accessibility matrix) Ob.wirt. V3 Ob.wirt. V3V Virt. data 1 Ob.wirt. V3 Ob.wirt. V3V Virt. data View V2 2 defines s ne mi ter de Local Administrator User 1 User 2 User 3 Fig.2. More detailed architecture of a local database In Fig.2 we have shown an API and a wrapper which adapt the local database to external requests. Assuming autonomicity of a local database the local database administrator (DBA) is an authority having two kinds of functionalities: Fig.1. Architecture of a federated databases Define a part of the local database, which can be The basic architecture of a federated system is presented in Fig.1. It consists of the following parts: accessed from global applications. The functionality restricts accesses to the local database from the side of 2 The global application collects results from all sub- federation. Moreover, it customizes (adapts) the local database to the standard of the federated schema. requests; then integrates the particular result into a global result. Determine rights of particular users to access particular resources of the local database (R - read, R/W - read and write, etc.). This scenario is a bit idealistic. For various reasons, e.g. optimization, it can be modified. The scenario may assume sequential processing of sub-requests: a next subrequest is generated when previous sub-requests have returned results (in order to make the next sub-request more precise, c.f. processing based on semi-joins). It is also possible to send the result of a sub-request addressing local database A to a local database B; then, send a subrequest to B; it addresses data stored in B plus data sent from A. Another method: for the given global request the federated DBMS collects all the data from local databases, which are sufficient and minimal for accomplishing the request. This method implies generating for the given request sufficient and minimal sub-views addressing local databases. Taking a bit idealistic view1, the local DBA has two kinds of facilities to determine the local export schema: Interfaces. DBA can define many interfaces to the same data. Interfaces are understood as primitive views, which only restrict and rename stored properties. Views. They enable DBA to define more sophisticated mapping of local database into federated schema. Views having the properties of interfaces (mentioned above) plus selection capabilities are referred to as data-preserving views. In many cases such views are insufficient. 3 Wrappers, Mediators and Ontologies Interfaces and views defined by the local DBA implicitly define a local export schema. Such a schema must be also written explicitly (e.g. by some automatic facility) as a part of a schema repository. The repository has the same role as the interface repository in CORBA. The schema repository is necessary for global applications e.g. to decompose a global query into subqueries addressing particular local databases. Another functionality of the local DBA is presented conceptually in the form of an accessibility matrix. It enables the administrator to grant access rights for particular users. In this way each user sees the local database through its own export sub-schema. For some applications this functionality might be omitted, i.e. from the position of the local DBA all users of global applications have the same rights. The sum of all local exported schemas constitutes the entire federated schema. Analogously, the sum of all exported sub-schemata for a particular user constitutes his/her external schema to the entire federated database. The general scenario of processing requests (queries) which uses this architecture is the following: Recently Internet, Web and development of fast and wide computer networks have caused a big pressure to integrate heterogeneous, geographically distributed data, which are not necessarily under the control of some DBMS. New terms are coined to denote various situations related to integrating heterogeneous data sources. Wrappers or adaptors (coming from the CORBA and Internet camps) are specialized program modules making it possible to map an internal API to the external API expected by some global application. Usually the mapping rises the level of abstraction, for instance, in CORBA applications the internal API is a collection of some C++ functions while an external API is an IDL interface. Wrappers are considered non-sophisticated programs for changing data representation, names of functions, etc. Moreover, wrappers are usually dealing with data units of low granularity (e.g. tuples rather than tables) and mapping is 1:1, i.e. one "internal" data granule (e.g. a relational tuple plus subordinated tuples) is conceptually mapped into one "external" data granule (e.g. a CORBA object). A wrapper can be considered a "physical bridge" between local databases and global applications. Another concept is mediator [Wied92]. It comes from the camp of data warehouses and integrating semistructured data. Till now, however, the concept is intuitive and defined pragmatically rather than semantically or theoretically. A mediator has to resolve (semantic, representational, structural, schematic) incompatibilites among data to be integrated. A similar role is assigned to database views; moreover, there are proposals, which treat mediators as virtual views [BRU96]. Perhaps the conceptual border between database views and mediators is difficult to define, but there are essential pragmatic A global application's request (a query) refers to the global view (the federated schema). The request is decomposed into sub-requests addressing particular local object views. Each sub-request is mapped by a local view mapping mechanism and wrapped into a request addressing local data. Such a request is executed within a local database. The result is mapped through the wrapper, then through the local view and returned to the global application. 1 In many cases the local DBA uses specific facilities, which cannot be classified as interfaces or views. 3 Performance concerning data accesses and processing; differences, which allow us to consider mediators as a new quality: Privacy, safety and security issues; transaction processing; Mediators can act on irregular data and can produce irregular data, while database views act on formatted data (e.g. tables) and produce formatted data Exceptions, error messages, extreme cases, null values, side effects, and other exceptional issues; According to (false) stereotypes of the relational model, a database view is to be defined by a single query (e.g. in SQL). However, current query languages have the power much below the algorithmic power. Mediators do not assume such limitations. The designers of mediators can use the full power of algorithmic programming languages as well as advanced higher-level methods, including methods attributed to artificial intelligence. Associations and other semantic dependencies among data; Issues related to API to data and data services, in particular, syntax, semantics and operational pragmatics of a query language; Data naming conventions; meaning of data names in the reality; Peculiarities of data representation. Mediators can use any resources from the computer environment (e.g. data written in files) while database views can use only resources stored in a database. Metadata information related to data and services. Formally, an ontology is defined as a specification of conceptualization [GrOl94], i.e. a description (like a formal specification of a program) of the concepts and relationships that can exist in a particular data/service environment. The postulated "formal specification" is an idealistic (and obviously utopian2) assumption promoted by AI theoreticians. As a matter of fact, current data/service environments are too complex to specify them by a formal logic (or even by any mathematical framework). In reality some elements of an ontology can be defined formally (for instance, schema and metaschema), some half-formally (for example, the semantics of object interfaces), and some informally (for example, mappings between objects and the business domain). Nevertheless, ontology is a useful concept, because it allows us to denote the real scope of issues that the designers of heterogeneous systems have to deal with, without binding them to current limited database models and theories. Different data servers have different ontologies. Even if the servers are supported by the same DBMS, the differences may concern semantics of data in the business domain, structuralization of data, representation of data, etc. Having a common ontology enables collaborators to work together with minimal risk of misunderstanding each other [Wied94]. The task of designers of federated applications based on heterogeneous data/service sources can be subdivided into the following steps: Database views themselves are stateless: each invocation of a view cannot utilize information from previous invocations of the same view. (Stateful views are referred to as capacity-augmenting views; they are considered yet as a research topic.) Stateful mappings cannot be avoided in many global (federated) applications. Mediators can be stateful with no limitations. Database views are self-contained named entities defined in a special syntax of a query language and stored in the database as identifiable persistent units. In contrast, mediators are programs written in a regular programming language and stored as a part of an application program in main memory. Thus, mediators have much lower abstraction level and maintenance potential than database views. Another term related to integrating heterogeneous data sources is ontology. An ontology is a formal theory or description of a being or reality. The term has a long history in philosophy, but it comes to the database world from the world of artificial intelligence. In this context the term has a technical meaning. It is understood as a formal description of everything that the designer or programmer has to know about some particular data/service environment to use it correctly and efficiently in a particular application. Note that ontology is a more general term than a database schema or a database view. From the database perspective an ontology includes formalization of the following issues: Understanding ontologies of all participating data/service sources and describe it (formally, semiformally or informally); The meaning, pragmatics and behaviour of data and data services in the (business) reality; Developing a common ontology which will satisfy the needs of future global applications, and on the other Static and dynamic constraints among data; causeeffect relationships; Associations among data and services (methods, procedures, etc.) acting or utilizing data; Peculiarities utilization; of data access, maintenance 2 Papers concerning mapping between heterogeneous ontologies for autonomous mobile agents (considered by AI) remain early theoretical ideas discussed by the database camp in late 70-ties. From that time the database domain has made important steps to full awareness of the problem. It seems not to be fully recognized yet by the AI camp. and 4 hand, will correspond to all participating data/service sources; such a common ontology is called canonical. non-normalized relations (NF2), a variety of object algebras, F-logic, comprehensions, monoid calculus, and other, see e.g. [AHV95, AlAr93, BNPS92, BRU96, Clue98, DaDe91, FeMa95, GKGH+97, HeSc91, KiLa89, LaSc93, LMSV+93, ShZd90]. There is little agreement which model is adequate for investigations concerning object views. In general, capabilities of view definitions can be a subject of various assumptions. The most comfortable case is when views are provided as an additional facility for retrieval. In this case the user can use the new possibility or not, depending on the problem, familiarity with the new option, his/her customs, etc. On the opposite extreme we have a non-comfortable case, when views are to be used for integrating hundreds heterogeneous databases, according to some federated ontology, which includes data model, programming interfaces, naming conventions, representation of values, semantics of values in the business domain, exchange formats, etc. In such a case the capabilities of view definitions are to be comparable to the capabilities of universal programming languages, including access to metadata, reflection, recursion, full algorithmic power, advanced view updating, complex data structures, and many other features. For instance, resolving schematic discrepancies among heterogeneous databases [KLK91] requires access to metadata and reflection. Similarly, dynamic invocations within CORBA environments require accesses to an interface repository, which is a recursive structure. Assuming it will be seen through database views, it should be possible to use recursive views, queries with transitive closures or other equivalent facilities. A basic misconception concerning object views is that proponents of ideas do not realize that the second, noncomfortable extreme presents a very wide and unexplored terra incognita. The typical paper at the beginning contains promises addressing the non-comfortable extreme. Then, there is a concrete syntax and semantics, which is frequently advanced and complex, but obviously close to the first extreme: a view definition is reduced to a single query in some limited query language (much below the algorithmic power), with a lot of additional options, perhaps important, but secondary. This style of research papers cause that the progress in the domain is difficult to evaluate and cause frustrations [DVB93]. Generality of object-oriented views requires many features: Developing a formal mapping between ontologies of participating databases and a canonical ontology. Any low-level or unspecified details of ontologies decrease the potential of common understanding. Hence the requirement that a canonical ontology has to be defined on a high abstraction level, which hides implementation details of participating ontologies. This point of view is taken by OMG CORBA, which uses some variant of an object model as a basis for a canonical ontology. In OMG CORBA the mapping between a particular ontology and a canonical ontology is determined through wrappers and adaptors written in regular programming languages. The CORBA object model, although powerful, is not sufficient from the database perspective. A more powerful object model, which includes collections, relationships and other features of databases, is proposed by ODMG [ODMG00]. Still, the ODMG object model is considered limited for many applications. Moreover, it is recently under some critics concerning the insufficient level of precision and consistency (see papers by the authors of the IRO DB project, papers by Suad Alagic, and other sources). Developing a mapping between a particular ontology and a canonical ontology is frequently a difficult task. For various types of discrepancies between data and services the mapping cannot be reduced to defining views in some query language. The mapping requires deep understanding of formal properties of data and services, as well as understanding of the meaning of data in the business domain. This goal requires query/programming languages and tools, which will be either powerful (universal), abstract, and simple to use. In the following we discuss the potential of object views to fulfill this role. 4 Object Models as Abstract Canonical Ontologies The object-orientedness is currently the major paradigm of many domains of computer technologies, including the analysis and design of software systems, programming languages, interoperability, componentbased software, databases, visual programming interfaces, and others. Thus the natural expectation that the objectoriented paradigm is a viable candidate for developing a canonical ontology for heterogeneous database federations. There are also expectations that the research into object views will result into a powerful and simple tool for determining mappings between ontologies. Object database models introduce many notions thus the formalization of their features (data structures, query languages, views, etc.) is more complex than in the relational case. There are many proposals: the ODMG object model and approaches to formalization of OQL, Restricting and renaming attributes in virtual objects (cf. SQL); Possibility to define virtual attributes; Views joining information from two or more (stored or virtual) objects; Views with parameters, recursive, and higher-order; views defined by complex algorithms, with the 5 possibility of access to metadata and reflective capabilities. Other optimization techniques, known as materialized views, assume various forms of caching results returned by view invocations. Updatable views supporting the transparency principle. The correct translation of view updates is a big problem, which till now has no proper treatment. Majority of approaches to object-oriented queries is unable to correctly formulate this problem, because updating operations are not expressible in proposed formal frameworks, e.g. an object algebra. 4.2 In principle, views are virtual, i.e. they exist only as a definition of a mapping between stored data and imaginary data. For several reasons (optimization, security, accessibility, parallelization, etc.) many authors have proposed materialized views. They assume that the result returned by view invocation is calculated in advance. A disadvantage of materialized views concerns updating of stored data, which implies updating materialized views. To cope with this issue various techniques are proposed. The majority of them assume incremental updating, i.e. updating the minimal part of a materialized view, which is to be influenced by updating. To accomplish this kind of algorithm the view definition must satisfy the distributivity property. It can be roughly formulated as: Integration of notions such as strong typing, classes, encapsulation, inheritance, methods, etc. Development of methods to avoid performance penalty due to view processing. To be more close to the non-comfortable extreme of view definition capabilities there is a need to extend the scope in which object views are typically set. Object views should follow the paradigms of programming languages rather than traditional database concepts, such as relational/object algebras or calculi. Assuming queries are programming languages’ expressions, the concept of programming languages that is analogous to database views is a functional procedure (i.e. a procedure returning an output) [SKL95, Subi97]. If a first-class, dynamically bound procedure is stored in a databases and returns a collection, then an invocation of the procedure is semantically equivalent to execution of a query. Such a procedure will be defined by queries and can be called within queries. The goal of the research into such object views is to integrate the above idea with query languages into a homogeneous, semantically simple, consistent and universal system. 4.1 Virtual vs. Materialized v(s1 s2) = v(s1) v(s1) where v(s) is the result returned by the view v for database state s; s1, s2 are any data states that the view v concerns; and is a state composition operator (e.g. union of sets). The distributivity property makes it possible to keep a 1:1 relationships between database objects and elements of a materialized view. An interesting variant of a materialized view is when it stores not newly calculated data, but references to stored data. For instance, this kind of view can be defined in Loqis as a function: function RichEmp begin return EMP where SAL > 2000 end; Performance of Object Views The function returns references (OIDs) to object of employees earning more than 2000. Such a view shares (to some extent) advantages of virtual and materialized views. In particular, updating of any attribute (except SAL) in EMP objects causes no changes in the materialized view. Actions on the view are necessary in the case of deleting and inserting EMP objects and in the case of updating the SAL attribute in any object. The idea can be generalized to materialized views which return not only references to objects, but also references to attributes and methods. The majority of approaches to object views assume (sometimes implicitly) that virtual objects are eventually calculated when the corresponding view is used in a query. For many applications such an approach will result in very bad performance. Relational systems use a query modification technique, which practically avoids any performance/storage overhead related to processing views. Query modification assumes macro-substitution of view invocations [SuPl00] and then optimizing resulting queries by rewriting [PlSu99, PlKr99, Plod00]. A big advantage of query modification is that in many cases it enables using other very efficient techniques, for example indices and other access support data structures. Another optimization technique, known as predicate move-around [LMS94], is similar to query modification, but works in otherwise direction. The technique assumes that a predicate occurring in a query invoking a view modifies the view definition. The technique can be efficient when a view is defined by a complex algorithm (thus query modification is not applicable). 4.3 Views Defined by Complex Algorithms Traditionally, a database view is to be defined by a single query. For complex mappings between local and federated ontologies this assumption leads to severe limitations, because the power of all known query languages (including SQL and OQL) is much below the algorithmic power. In Loqis this limitation is avoided. For example, the WellPaid function has a parameter JobPar and a local variable a: 6 function WellPaid( JobPar ) begin real a := avg(EMP.SAL); return EMP where JOB = JobPar and SAL > 2*a; end; as a rule - are not sufficiently general and not well understood. In effect, view updating was limited to particular cases. Another disadvantage of the relational research into view updating concerns some naive (implicit) assumptions that the transformation of view updates has to be done into some auto-magical way, e.g. by utilizing functional dependencies and other properties of relations stored in the database. In general, transformations of view updates have to be controlled by the view definer by special options dedicated to this purpose. This is eventually accomplished in Oracle-8, but the solution is not sufficiently general yet and has no theoretical or conceptual background. Object databases open new horizon for the view updating problem. Some part of the object databases camp follows more general theoretical paradigms based on the semantics of programming languages rather than (obsolete and inefficient) paradigms based on algebras, calculi or logic. From the position of the programming languages' semantics (including operational and denotational semantics) updating operators are regular operators, thus the research concerning view updating can be based on a stable fundament. Concerning updating of object views we can distinguish two cases: Get companies where well-paid clerks used to work previously: WellPaid( "clerk ").PREV_JOB.COMPANY Although the presented "algorithm" is very simple, in general there are no limitations. A wider discussion concerning various features of object views implemented in Loqis (views defined by joins, virtual attributes, virtual links, etc.) can be found in [SuPl00]. 4.4 Object Views as Database Modules The relational model has introduced some ambiguity concerning the term "view". Essentially, database design methodologies as well as the ANSI/SPARC architecture regard a view as some part of the database schema, or (more precisely) as some mapping between a database schema and an external (user) schema. In contrast, an SQL view is essentially a programming function (like functions or functional procedures in Pascal or C) which maps stored tables into a virtual table. In general the SQL approach to views is limited. A view should be defined as a module, which stores several named functions (a la SQL views). Such a module should follow the maintenance semantics of SQL views, i.e. it can be stored in a database and deleted from the database. A module being a view can store other run-time entities, in particular: Common private functions; Public and private classes necessary for the view definition; methods within these classes; Constraints and rules; for instance, rules for view updating; Public and private persistent data; for instance, data necessary for capacity-augmenting views. a) Data can be updated by generic operations, i.e. assignment, deleting and inserting. b) Data cannot be updated by generic operations. Any updating of data objects has to be done by methods (following the narrow understanding3 of encapsulation). The case b) implies no special conceptual problems with view updating. In this case the view definer has to define a view together with a class that virtual objects will belong to. The class stores all the methods (written or adopted by the view definer) necessary for updating virtual objects. During writing the methods the view definer has full access to stored data objects, thus can update them with no limitations. There is some danger of inconsistent updates, thus one research problem concerns automatic discovering of them. Another problem concerns connecting the objects generated by a view invocation to the methods stored within the class. Assuming views are dynamically bound and methods are statically bound this can imply technical difficulties. In majority of cases we cannot avoid generic updating operations. However, the case a) is more challenging for researchers. The simplest solution we obtain assuming that a view invocation returns references to stored objects rather than new objects. These references can be used as l-values in assignment and deleting statements. (Inserting is problematic.) The case is generalized in Loqis, where a 5 Updatable Views The majority of research and development devoted to heterogeneous database federations assume that global applications are based purely on retrieval from local databases. Some applications, however, strongly depend on updating. In case of heterogeneous database federations this updating is to be done through local views and wrappers. Updatable views, which follow the transparency principle (i.e. the user does not know whether she is working with stored or virtual data) are still in infancy. Typical theoretical paradigms (relational algebras, relational calculi and formal logics) do not deal with updating operations. Thus updating is to be introduced by some ad hoc enhancements to these formalisms, which - 3 The understanding of the concept of encapsulation can be different. Originally (as proposed by D.Parnas) it means subdividing object's properties into public and private, independently of the property's kind (c.f. Modula-2 and C++). Many authors are trying to promote the narrow view, where only some methods are public; other properties are private. 7 view invocation can also return structures built upon references to attributes. This allows one to update views defined by complex queries, including queries defined by joins. Such an updating, however, may lead to undesirable side effects, thus additional syntactic and semantic features are necessary to prevent them. The most general case (currently under investigations) is based on virtual object identifiers. They are returned by view invocations. Virtual identifiers are complex structures storing all the information about the "origin" of the virtual object. Virtual identifiers make it possible to overload generic view updating operations by specific methods defined by the view definer [SuMi89]. During writing the methods the view definer has full access to stored data objects, thus can update them with no limitations (similarly to the case b)). The overloading methods are fully transparent for the view user: she is using generic updating operations with no differences. Although conceptually the method seems to be viable and implementable, there are many details (optimization, in particular), which so far are not sufficiently investigated. [BaKe93] Barclay, P.J., J.B. Kennedy. Viewing Objects. British National Conf. on Databases, Springer LNCS 696, 1993. [BKSW91] Barsalou, T., A.M. Keller, N. Siambela, G. Wiederhold: Updating Relational Databases through Object-Based Views. SIGMOD Conf., 248-257, 1991 [Bell97a] Bellhasene, Z. Identifying Virtual Composite Objects: a Step Forward to Updated Object Views. DEXA Conf., 523-528, 1997 [Bell97b] Bellahsene, Z. Extending a View Mechanism to Support Schema Evolution in Federated Database Systems. Proc of DEXA Conf., 573-582, 1997 [Bert92] Bertino, E. A View Mechanism for ObjectOriented Databases. Advances in DB-Technology, EDBT Conf., Springer LNCS 580, 136-151, 1992 [BNPS92] Bertino, E., M. Negri, G. Pelagatti, L. Sbatella. Object-Oriented Query Languages: The Notion and the Issues. IEEE TKDE 4, 223-237, 1992 [Brat92] Bratsberg, S.E. Unified Class Evolution by Object-Oriented Views. ER Conf., 423-439, 1992 [BFK95] Breche, P., F. Ferrandina, M. Kuklok: Simulation of Schema Change Using Views. DEXA Conf., 247-258, 1995 [BRU96] Buneman, P., L. Rashid, J. Ullman. Mediator Languages - a Proposal for a Standard. Report of an I3/POB Working Group, University of Maryland, April 1996 [BuFa99] Busse, R., P. Fankhauser. Declarative and Procedural Object-Oriented Views. ICDE Conf., 1999 [ChMe97] Chen, R., W. Meng. Efficient View Maintenance in a Multidatabase Environment. Proc of DASFAA Conf., 391-400, 1997 [Clue98] Cluet, S. Designing OQL: Allowing Objects to be Queried. Information Systems 23(5), 279-305, 1998 [DaDe91] Davis, K.C., L.M.L. Delcambre. A Denotational Approach to Object-Oriented Query Language Definition, Intl. Workshop on Specifications of Database Systems, Workshops in Computing Series, Springer-Verlag 1991. [Daya90] Dayal, U. Queries and Views in an ObjectOriented Data Model. 2nd DBPL Workshop, Morgan Kaufmann, 80-102, 1990 [DVB93] de Graaff, J.M., R. J. Veldwijk, M. Boogaard: Logical Data Independence Via Views: A Misapprehension? DASFAA Conf. 313-323, 1993 [DGS94] Durant, J., M. Ganti, R. Salinas. Object View Broker: A Mediation Service And Architecture to Provide Object-Oriented Views of Heterogeneous Databases. ADB Conf. 412-428, 1994 [Elia95]Eliassen, F. Managing Identity in Global Object Views. RIDE-DOM, 70-77, 1995 6 Conclusion The paper is presents a research agenda concerning objects views considered as a tool for mapping heterogeneous ontologies into a federated ontology. We have tried to show that many research efforts devoted to this topic present too narrow understanding of the problem, thus the produced results we consider premature. The complexity of database ontologies requires novel approaches, which are going far beyond the traditional paradigms known from the relational model. These approaches should assume a rich and abstract canonical object model, in order to cover all conceptual issues that may occur in local databases to be integrated. Moreover, object views should be defined as complex database modules, having full algorithmic power and dealing with complex data structures and abstractions. 7 References4 [AbBo91] Abiteboul, S., A. Bonner. Objects and Views. SIGMOD Conf., 238-247, 1991 [AHV95] Abiteboul, S., R.Hull, V. Vianu. Foundations of Databases. Addison-Wesley, 1995 [AlAr93] Alhajj, R., M.E. Arkun. A Query Model for Object-Oriented Databases. ICDE Conf., 163-172, 1993 [ABS97] Amer-Yahia, S., P. Breche, C. Souza dos Santos. Object Views and Updates. Engineering of Information Systems Journal 5(1), 1997 4 Acronyms of journals and conferences according to the M. Ley DBLP Bibliography, http://www.informatik.uni-trier.de/~ley/db/index.html 8 [FaRi97] Fahl, G., T. Risch. Query Processing Over Object Views of Relational Data. VLDB Journal 6(4), 261-281, 1997 [FeMa95] Fegaras, L., D. Maier. Towards an Effective Calculus for Object Query Languages. SIGMOD Conf., 47-58, 1995 [GeZi94] Gentile, M., R. Zicari. Updating Views in Object-Oriented Database Systems. Intl. Symposium on Advanced Database Technologies and their Integration, Nara, Japan, 1994 [GPZ88] Gottlob, G., P. Paolini, R. Zicari. Properties and Update Semantics of Consistent Views. ACM Transactions on Database Systems, 13(4), 1988 [GrOl94] Gruber, T.R., G. Olsen. An Ontology for Engineering Mathematics. 4th International Conference on Principles of Knowledge Representation and Reasoning, Bonn, Germany. Morgan Kaufmann 1994. [GKGH+97] Grust, T., J. Kröger, D. Gluche, A. Heuer, M.H. Scholl. Query Evaluation in CROQUE - Calculus and Algebra Coincide. Advances in Databases. 15th British National Conference on Databases. Springer LNCS 1271, 84-100 , 1997 [GBCG97] Guerrini, G., E. Bertino, B. Catania, J. GarciaMolina. A Formal Model of Views for Object-Oriented Database Systems. Theory and Practice of Object Systems, 3(3), 157-183, 1997 [HaKe95] Hamon, C., A.M. Keller: Two-Level Caching of Composite Object Views of Relational Databases. ICDE Conf., 428-437, 1995 [HeZd90] Heiler, S., S. Zdonik. Object Views: Extending the Vision. ICDE Conf., 1990 [HeSc91] Heuer, A., M.H. Scholl. Principles of ObjectOriented Query Languages. GI Conf. on Database Systems for Office, Engineering and Scientific Applications, Springer-Verlag, 178-197, 1991 [JoRi98] Josifovski, V., T. Risch: Calculus-Based Transformations of Queries over Object-Oriented Views in a Database Mediator System. CoopIS, 218231, 1998 [KDN90] Kaul, M., K. Drosten, E.J. Neuhold: ViewSystem: Integrating Heterogeneous Information Bases by Object-Oriented Views. ICDE Conf. 2-10, 1990 [KaEa98] Kaushal, R., B. Eaglestone. View-Based Support for Transparent Schema Evolution in Federated Database Systems. IADT Conf., 160-167, 1998 [KiLa89] Kifer, M., G. Lausen. F-logic: A Higher-Order Language for Reasoning About Objects, Inheritance and Scheme. SIGMOD Conf., 1989 [KiKe95] Kim, W., W.Kelley. On View Support in Object-Oriented Database Systems. (In) Modern Database Systems, Addison-Wesley, 108-129, 1995 [KLK91] Krishnamurthy, R., W. Litwin, W. Kent. Language Features for Interoperability of Databases with Schematic Discrepancies. SIGMOD Conf., 40-49, 1991 [KuRu96] Kuno, H.A., E.A. Rundensteiner. The MultiView OODB View System: Design and Implementation. Theory and Practice of Object Systems. Special Issue on Subjectivity in Object-Oriented Systems, 1996 [LaSc91] Laasch, C., M.H. Scholl, M.Tresch. Updatable Views in Object-Oriented Databases. 2nd DOOD Conf., Springer LNCS 566, 1991 [LaSc93] Laasch, C., M.H. Scholl. A Functional Object Database Language. 4-th Intl. Workshop on Database Programming Languages, Springer Workshops in Computing, 1993, 136-156, 1993 [LDB97] Lacroix, Z., C. Delobel, P. Brèche. Object Views and Database Restructuring. DBPL Conf., 1997 [LMSV+93] Leung, T.W., G. Mitchell, B. Subramanian, B. Vance, S.L. Vandenberg, S.B. Zdonik. The AQUA Data Model and Algebra. 4-th Intl. Workshop on Database Programming Languages, Springer Workshops in Computing, 157-175, 1993 [LMS94] A.Y.Levy, I.S.Mumick, Y.Sagiv. Query Optimization by Predicate Move-Around. 20th VLDB Conf., 1994, pp.96-107 [LTY93] Ling, T.W., P.K. Teo, L.L. Yan. Generating Object-Oriented Views from an ER-Based Conceptual Schema. DASFAA Conf., 148-155, 1993 [MaBa91] Mamou, J.-C., C. Bauzer-Medeiros. Interactive Manipulation of Object-Oriented Views, ICDE Conf., 1991 [Mots96] Motschnig-Pitrik, R. Requirements and Comparisons of View Mechanisms for ObjectOriented Databases. Information Systems, 21(3), 229252, 1996 [ODMG00] ODMG Team. The Object Data Standard ODMG 3.0. R.G.G. Cattel, D.K. Barry, Eds., Morgan Kaufmann, 2000 [OMG95] OMG Team. Object Management Group, CORBA: The Common Object Request Broker Architecture and Specification. July 1995, Release 2.0. [Paep93] Paepcke, A. An Object-Oriented View Onto Public, Heterogeneous Text Databases. Proc of ICDE Conf. 484-493, 1993 [PMSL94] Pirahesh, H. B. Mitschang, N. Südkamp, B.G. Lindsay. Composite Object Views in Relational DBMS: An Implementation Perspective. EDBT Conf., 23-30, 1994 (also) IS 19(1): 69-88 (1994) [PlSu99] Płodzień, J., K. Subieta. Optimization of Object-Oriented Queries by Factoring Out Independent Subqueries. Institute of Computer Science Polish Academy of Sciences Report 889, Warsaw, November 1999 9 [PlKr99] Płodzień, J., A. Kraken. Object Query Optimization in the Stack-Based Approach. 3rd Conf. on Advances in Databases and Information Systems (ADBIS’99) Springer LNCS 1691, 303-316, Sept. 1999 [Plod00] Płodzień, J. Optimization Methods in Object Query Languages. PhD Thesis. Institute of Computer Science Polish Academy of Sciences, Warsaw, February 2000 [Rund94] Rundensteiner, E.A. A Classification Algorithm for Supporting Object-Oriented Views. CIKM, 18-25, 1994 [Rund96] Rundensteiner, E.A. Object-Oriented View Technology: Challenges and Promises, Intl. Symposium on Cooperative Database Systems for Advanced Aplications, Kyoto, Japan, 1996. [Rupp98] Rupp, S. A Critique of Release 2.0 of ODMG93 Standard. http://gameboy.gia.rwthaachen.de/odmgbugs [SIMB94] Sarriguren, A.G., A. Illarramendi, E. Mena, J.M. Blanco: Query Processing in a Multidatabase System with an Integrated View Based on Description Logics. FQAS Conf., 87-100, 1994 [SLT90] Scholl, M.H., C. Laasch, M. Tresch. Views in Object-Oriented Databases. FMLDO, 37-58, 1990 [SLT91] Scholl, M.H., C. Laasch, M. Tresch. Updatable Views in Object-Oriented Databases. 2nd DOOD Conf. Springer LNCS 566, 1991 [SQL99] ISO-ANSI Working Draft. Database Language SQL - Part 1: SQL/Framework, March 1999 [SST92] Scholl, M.H., H.-J. Schek, M. Tresch. Object Algebra and Views for Multi-Objectbases. Intl. Workshop on Distributed Object Management, Edmonton, Canada, 1992 [ShZd90] Shaw, G.M., S.B. Zdonik. A Query Algebra for Object-Oriented Databases. ICDE Conf., 152-162, 1990 [Souz95] Souza dos Santos, C. Design and Implementation of Object-Oriented Views, DEXA Conf. 1995, Springer LNCS 978, 91-102, 1995 [SAD94] Souza dos Santos, C., S. Abiteboul, C. Delobel. Virtual Schemas and Bases, EDBT Conf., Springer LNCS 779, 81-94, 1994 [SuMi89] Subieta, K., M. Missala. View Updating Through Predefined Procedures. Information Systems 14(4), 291-305, 1989 [SMA90] Subieta, K., M. Missala, K. Anacki. The LOQIS System. Institute of Computer Science Polish Academy of Sciences, Report 695, Warszawa, Nov. 1990 [Subi91] Subieta, K. LOQIS: The Object-Oriented Database Programming System. 1st Intl. East/West Database Workshop, Kiew, USSR 1990, Springer LNCS 504, 403-421,1991 [Subi97] Subieta, K. Object-Oriented Standards: Can ODMG OQL be Extended to a Programming Language? (In) Cooperative Databases and Applications, World Scientific, 459-468, 1997 [SKL95] Subieta, K., Y. Kambayashi, J. Leszczyłowski. Procedures in Object-Oriented Query Languages. 21st VLDB Conf., 182-193, 1995 [SuPl00] Subieta, K., J. Płodzień. Object Views and Query Modification. 4th IEEE Intl. Baltic Workshop on Databases and Information Systems, June 2000. [VeAp95] Vermeer, M.W.W., P.M.G. Apers. ObjectOriented Views of Relational Databases Incorporating Behaviour. DASFAA Conf. 26-35, 1995 [Wied92] Wiederhold, G. Mediators in the Architecture of Future Information Systems, IEEE Computer Magazine, March 1992 [Wied94] Wiederhold, G. An Algebra for Ontology Composition. ARPA and Standford University Report, 1994 10