Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Views in Object Oriented Databases A report by: Patricia Bisset, Kevin Busby, Andrew Girdwood, Garry Milne and Georges Vautherin. May 2002 Contents: 1. Abstract ………………………………………………………………… 1 2. Introduction ……………………………………………………………. 1 3. Views ……………………………………………………………………. 3.1 What is a view? …………………………………………………. 3.2 Background : Database Architecture …………………………. 3.3 Relational Databases …………………………………………... 3.4 Views in Relational Databases ………………………………... 3.5 Views in Object Oriented Databases …………………………. 2 2 2 3 3 5 4. Problems and issues with views in OODBs………………………. 6 5. Examples of suggested solutions in OODB views …………….. 8 5.1 Example 1: Serge Abiteboul & Anthony Bonner .…………….. 8 5.2 Example 2: Peter Barclay & Jessie Kennedy ………………… 9 6. ODMG standards and views …………………………………………. 11 6.1 ODMG ……………………………………………………………. 11 6.2 Extending the ODMG standard with views …………………… 11 7. Conclusion ……………………………………………………………... 13 8. References …………………………………………………………….. 14 Views in Object Oriented Databases - Report 1. Abstract The purpose of this report is to examine the use of the concept of views in Object Oriented Databases (OODBs). The report will look at the use of views in Relational Databases (RDBs), and why their support is seen as a useful and necessary part of a DBMS (Database Management System). We will take a general look at the issues and problems involved with the use of views in Object Oriented Databases (OODB), and then, through examples, look at some of the suggested solutions to these problems. We will then examine how support for views could be incorporated into the Object Data Management Group (ODMG) standards. 2. Introduction It is generally agreed that OODB features should meet as much as possible of the functionality of RDBs. A very important relational functionality is represented by views. Views provide a calculated set of data derived from the database, and this provides both security of data, and user-friendliness, by tailoring data sets for specific users. Views also provide for the simplification of queries. The first notable point when researching this topic was the lack of material on the subject of views in OODBs. Although widely regarded as a desirable mechanism for OODBs, the majority of commercial OODBs do not have any support for view mechanisms, and there still exists no standard for their implementation. There remains surprisingly little information on the subject in textbooks on OODBs. Our report draws mainly on journal articles and conference proceedings which have addressed some of the issues involved. The lack of concrete examples of the implementation of views in OODBs points to the problems involved, and although a fair amount of research has been carried out, it seems no single solution has yet been agreed. 1 Views in Object Oriented Databases - Report 3. Views 3.1 What is a view? A view is a table that is not stored directly but instead, is defined in terms of a query language [3]. Another definition is that a view is a virtual database whose schema and contents are derived from an existing database through a mapping process [7]. A view may establish different names for attributes and relationships and may reflect a different structure of data. The resulting data structure may be more compatible or more understandable to the user’s perception [7]. Views help manage the intellectual complexity of interacting with the data by hiding unnecessary detail and presenting information in the most appropriate format. Views can also provide a level of security by allowing access to certain data only to certain users. A view can be seen as a part of the database by a requesting application. 3.2 Background: Database Architecture Figure 1 Database Architecture (Ref: CO22008: Introduction to Databases) 2 Views in Object Oriented Databases - Report Internal View This is a very low-level representation of the entire database In effect, the internal schema is the storage definition structure. Conceptual View An abstract representation of the entire information content of the database. It is in general, a view of the data as it actually is. The external level is concerned with the way individual users see the data. External View A user is anyone who needs to access some portion of the data. Access via a 3GL, COBOL, etc (programmer) or a query language(causal user). All access methods include a Data Sub-Language (DSL). A DSL is a combination of two languages: a data definition language (DDL) - definition and description a data manipulation language (DML) - manipulating data Each user sees the data in terms of an external view Defined by an external schema, consists of external record descriptions, and understands the mapping between external schema and the conceptual level. 3.3 Relational databases The relational data model comprises: relational data structure (A relational data structure is a collection of tables or relations.) relational integrity constraints relational algebra or equivalent 3.4 Views in relational databases Relational views provide logical data independence, as, if the representation of a table changes, the programmer can change the view of the new table so that it matches the old table and the existing program continues to work [3]. A view is a way of collecting information from parts of one or more tables to enable users to more easily access the relevant contents of the database. View mapping techniques are implemented primarily to derive external relations from internal relations stored in the database (see Figure 1). Each query in the mapping defines a derived relation in the view, which in turn appears as a set of derived relations. Most often, a view is composed of a 3 Views in Object Oriented Databases - Report unique derived relation; thus the concept of view and derived relation are synonymous (for most database specialists). However it is not always possible to perform updates on views as if they were ordinary tables since the intent of the update may be incomplete or inconsistent with the view definition [3]. E.g. creation of a view using SQL: CREATE VIEW a_View_Name [(column_list)] AS a_SQL_Query; Attributes can be renamed in column_list if required. Let us suppose a user needs to manipulate regularly details about employee, name and position. (These details can be found in two distinct tables: employee and jobhistory.) It might be simpler to create a view limited to this information only, rather than always extracting it from two tables: CREATE VIEW empjob AS SELECT employee.empno, surname, forenames, position FROM employee, jobhistory WHERE employee.empno = jobhistory.empno; This view can then be accessed like any other table: SELECT empno, surname, forenames FROM empjob WHERE position LIKE ‘%Program%’; A view can (should) be dropped when no longer required: DROP VIEW empjob; Thus, views can be employed to enable users to create simpler queries, rather than using techniques such as self-joins or sub queries. A view is populated with data when it is defined or when it is accessed. When a view has been defined, it must behave as a normal relation. In particular, an authorised user must be allowed to query the derived relation. Two techniques have been proposed to query views. One is to apply the view definition mapping at each query: this is called query modification. The other one is to materialise the view: this is called view concretion. It is very important to understand that a view is a dynamic window over a database and must reflect all changes made in the database. 4 Views in Object Oriented Databases - Report 3.5 Views in Object Oriented Databases In OODBs, a view must not define the data which is accessible to an application but the operations, which an application needs to have at its disposal to perform its task accurately. Since these operations are the only way to access and manipulate data, a view definition may result in the need to define some “view specific” operations. While relational database systems make it possible to define a view on top of the conceptual schema, objectoriented database systems only provide one common interface per class, the interface that consists of all operations, which can be applied to the objects of the class. This implies that the interface of a class needs to provide not only the operations associated with the class but also operations which are only associated with a single view. A necessary condition for the creation of views is that the operators which can be applied to create a view are object-preserving (the resulting objects of an object-preserving query are some of the existing objects from the database). Otherwise each view definition would create new objects which is not the intention of the user. Relational views can create new attributes or hide existing ones whereas object oriented views must hide or create behaviour as well as structure. 5 Views in Object Oriented Databases - Report 4. Problems and issues with views in OODBs There are both technical and conceptual problems with views in an objectorientated database. Data encapsulation is a fundamental premise of objectorientated design; it states that the properties of any object are only visible to that object. A database view is a request from a user to access a range of data. The two contrasting requirements are not easy to reconcile. In addition, whereas a view in an RDB need only display a set of tuples, a view in an ODB may have to return various objects, or sets of values, making its implementation far more complex. [7] Also, views in RDBs are virtual tables with independent relations. In OODBs a complex class hierarchy exists where classes are connected by relationships (eg inheritance), and it is very difficult to define how to create a view. [5] Most of the suggested OODB view approaches to be found use an object creation approach as a method for their viewing structure. New objects, sometimes referred to as imaginary objects since they would not normally appear in the database, are created with the required access methods to reveal both the correct data and the structure to the user. Similarly to views in RDBs, these imaginary objects provide an additional level of security in the database since there is an additional level of abstraction between the user and the data. However, they also throw up the considerable problem to OODBs of Object Identity. Every object has its own object identity (OID), and when creating a view of the data, one of the problems is whether each derived object should keep the identity of the base class (class it has been derived from) or have a new identity. This can be split into two separate kinds of views - the first objectpreserving views, where objects keep their identities, the second objectgenerating views, where objects generate new identities. With preserving, it is more straightforward as the object in the view keeps the same id and any changes can be propagated back to the base instance. With preservation, the view can add only operations and derived relationships and attributes. Objectgenerating views, are more complicated since a cross-reference needs to be kept between the base class instance and the view instance and does not allow for all changes to be propagated back to the base class. [6] Another consideration is that the creation of new objects in a database just to view pre-existing data causes problems. Is the data presented in the imaginary object view a copy of the data from the original? If the data presented to the user is a copy then there is the risk that it is out of date by the time the user views it. In particularly large databases in which complex and demanding views are requested it may not be advisable to copy the data and structure just to facilitate one view. Familiar object-orientated programming languages are not always sufficient for database views since they do not have the same notations population as a 6 Views in Object Oriented Databases - Report database nor do basic OO-languages naturally have the concept of multiple abstractions over the same data. [2] Views from object-orientated databases may have to represent complex data or structure. A view might have to represent an array or container object. In order to depict this data some sort of interface or browsing tool is sometimes provided to the user. This interface needs to be sufficiently powerful and capable to represent the view and yet generic enough so that users with different knowledge backgrounds can still make use of it. 7 Views in Object Oriented Databases - Report 5. Examples of Suggested Solutions in OODB Views This section explains some examples of theories which have been suggested by database professionals with regard to defining or implementing views in object oriented database systems. The two papers which provide the examples are: Objects and Views [1] written by Serge Abiteboul and Anthony Bonner in 1991; Viewing Objects [2] written by Peter Barclay and Jessie Kennedy in 1993. 5.1 Example 1: Serge Abiteboul & Anthony Bonner In this paper the authors claim that the natural way to overcome difficulties in OODBs associated with restructuring data is to introduce a view mechanism. The view should allow the programmer to restructure the database and change the behaviour of objects. This paper presents views as being virtual classes; these virtual view classes are defined by specifying their population. They can be populated by existing objects of other classes and also by new objects created by the programmer. In the case of a virtual view class being populated with new objects, these objects are defined as imaginary as they have no reality outside of their existence in the virtual view class. One problematic feature is that these new imaginary objects are given a new OID, and as seen previously, object identity is a huge issue within OODB views. The paper is concerned only with the programmer populating the view class, and is adamant that the system must take care of other issues to do with the class stating that the structure, behaviour and position of the view class in the class hierarchy can be derived by the system. The paper introduces the theory of there being many databases in a system across which data can be imported, and that a view as such merely represents a database which imports all its data from other databases. Coupled with the ability to import data is the ability to hide certain data that has been imported, for example the view class could import the data representing an employee class but hide the salary attribute of the employee class. In common with other theories, in particular the next paper [2], Abiteboul and Bonner blur the distinction between attributes and methods when populating view classes. The paper bases its theories on the O2 model where the database is a hierarchy of classes with each class having a type, and every object in the class having a value of that type. Each object also has a unique OID. As regards populating the virtual view class, the paper treats separately the population of the class with existing objects and the population of the class with new imaginary objects. If being populated with existing objects then there are 3 ways in which this can be achieved; specialization, generalization and behavioural generalization - the 3 methods are based on OO theories. Population by specialization is done through a selection statement such as (Adult is the view class): Ex1. class Adult includes (select P from Person where P.Age ≥ 21); 8 Views in Object Oriented Databases - Report Population by generalization is achieved by specifying a virtual view class, which includes other classes, such as (Ship is the view class): Ex2. class Ship includes Tanker, Cruiser, Trawler; Population by behavioural generalization can be achieved for example by defining a virtual view class Printable that includes all classes that have a Print method. Such methods of population allow for multiple inheritance and so the paper insists that with regard to implementation, an object can only be real in one class. With regard to creating new imaginary objects, the paper details how an imaginary Family class (and as a result object) could be created which would be an object which would contain other Person objects. New attributes could be created for this Family class such as number of children. The main problem the paper encounters with regard to new imaginary objects is that of object identities and the mapping between object identities and tuples in the database. The paper concludes with five ideas regarding views in OODBS, these are: 1. 2. 3. 4. 5. A view should be treated as a database. A view should be easily constructed. The spirit of object-orientation should be kept. The user should be relieved of mundane tasks. More flexibility should be provided. 5.2 Example 2: Peter Barclay and Jessie Kennedy This paper investigates the use of views within an OODB, and takes the approach whereby views are themselves objects which are instances of view classes. The paper makes use of theories defined in previous papers written by the same authors. These are the Napier Object Model (NOM) and the Napier Object Oriented Data Definition Language (NOODDL). The NOM is a simple object data model whilst NOODDL is a data manipulation language whereby schema can be described. It is important to note that in common with the first paper, the distinction between attributes and methods is blurred, and they are treated the same, the term property covering both. Although this paper represents views as objects, the view is populated with existing data and no new objects are created. This is in great contrast to the other paper [1] and is a deliberate attempt by the authors to steer clear of the object identity problem which occurs when new objects are created to populate a view. This paper takes the approach that there are three types of view which are treated separately. These are selection, projection and join views. With a selection view, objects which do not meet the selection criteria are hidden. 9 Views in Object Oriented Databases - Report With a projection view, the make-up of objects can be changed, properties may be gained or lost. With a join view separate objects may be combined to represent one view object, or one object may be divided to represent many separate view objects. The selection view could be considered to be very similar to the idea of population by specialization in the first paper [1], whilst the idea of join views is similar to population by generalization. With the construction of all these view objects the paper states that one view of the data must not affect any other view of the data, and so it is vital to ensure data independence. 10 Views in Object Oriented Databases - Report 6. ODMG Standards and Views 6.1 ODMG The Object Data Management Group (ODMG) was founded in 1991 by a small number of object database vendors, researchers and users [4] to try to create an industry standard for OODBs. The current standard is ODMG 3.0. However, even though this group of people have written these standards, there is no evidence that any commercial product fully implements the standard (except O2), and it seems that creating a standard for such a complicated area of OODB is not a particularly simple procedure. An important element in relational databases is views and at present the ODMG standard does not support views, yet it is seen by the Object Oriented community as being an important function of databases and therefore needs to be included in the standards. 6.2 Extending the ODMG standard with Views In examining how the ODMG standard could be extended to cover a standard for views, we now look at the research paper Extending the ODMG standard with Views (by Garcia-Molina et al, 2002[5]) This paper has been written to present a standard that the ODMG can include in their next specification of the standards. [This paper is a more concise paper than one previously published in 1997 [6] and has been used since it is more up to date.] The general suggestions that the paper makes is that each OO View should be seen as a new type (i.e. class), and that the Object Definition Language (ODL) should be extended to include this. Additionally, the binding to the programming language needs to be extended and in this paper the author uses C++ to give examples. To get over the object identity problem, the authors have decided to use object-preservation to overcome the OID problem. The paper outlines that the functionality of the view should have the same functionality of that of Relational Databases such as: the data should be independent so as to protect the original data only certain attributes and methods should be 'visible' it should allow for canned queries They suggest that the ODL should be extended to have an 'IS-VIEW' relationship (similar to that of an 'IS-A' relationship) and that from this it can import all or some features from the base class, have additional/derived features. With this, it can act like any other class with OQL (Object Query Language), so OQL would not have to be changed in any way. 11 Views in Object Oriented Databases - Report Therefore, an ODL hierarchy would look like Figure 2 Figure 2. This means, that a class can be treated like any other full class, but cannot instantiate and it would act similar to an interface (or abstract class). An interface is a class with all its methods deferred and no objects, therefore its not able to instantiate. Figure 3 is an example of what the ODL would look like, with a key to explain the structure of it. Figure 3 Thus, with the IS-VIEW relationship, instances of the base type can belong to a view, all the features that are imported from the base type belong to a view, objects stored in the database will not be affected by the introduction of the View in the new schema and finally, the structure of the object will remain unchanged. For the implementation of the IS-VIEW relationship, the authors have used C++, and have implemented the 'View' class as an abstract class which is placed in the hierarchy between the base class and the superclass of this base class. 12 Views in Object Oriented Databases - Report 7. Conclusion We have seen that, although the concept of view mechanisms is seen as very fundamental in the world of databases, its context in the OODB world remains among the academic and research domain rather than in available retail OODB packages. The argument that OODB technology is still in its infancy is losing its credibility now, since, for instance, it is over 20 years since the ODMG was set up, and some of the papers on OODB views were written in the early 1990s. It seems that the reluctance to use OODB views is due to the fact that the object oriented model is far more complex than the relational model, and it is impossible to fully integrate the relational concept of views into the object model. We have seen that the main problem areas are integrating view objects into the complex class hierarchy, and the problem of OIDs. The main differences in the proposed solutions concern the functionalities supported by the view mechanism, where the views appear in the hierarchy, whether a view has a separate OID, and the update operations allowed on views. Although several good proposals have been suggested, as we have seen in this report, there is no one perfect solution, and still no mention of views in the ODMG standards. It may be that there is no such thing as an agreeable standard, and that view mechanisms are inevitably implemented differently by different vendors in the future. However, the importance of the added functionality afforded by the use of views make it unlikely that the view will play no part in OODB technology, which is, after all, meant to be an advancement in database technology. 13 Views in Object Oriented Databases - Report 8. References: [1] S. Abiteboul, A. Bonner, Objects and Views, ACM SIGMOD Record, Proceedings of the 1991 ACM SIGMOD international conference on Management of data April 1991, Volume 20 Issue 2. [2] P. Barclay, J. Kennedy, Viewing objects, 11th British National Conference on Database - BNCOD11, 1993, Keele, UK, 07/07/1993-09/07/1993, M. Worboys, A.F.Grundy (Eds), 93-110, 1993. [3] R.G.G. Cattell, Object Data Management - Object Oriented and Extended Relational Database Systems, Addison-Wesley, 1994, ISBN 0-201-54748-1 [4] R. Cooper. Object Databases - An ODMG approach. Thomson Computer Press, 1997. [5] J. Garcia-Molina, M.J. Ortin-Ibanez, G. Garcia-Mateos. Extending the ODMG standards with views, Information and Software Technology 44, 2002, pp161-173. [6] G. Guerrini, E. Bertino, B. Catania, J. Garcia-Molina. A Fromal model of views for object-oriented database systems, Theory and Practice of Object Systems 3 (3), 1997, pp. 157-183. [7] K. Jeffery Expert Database Systems, Academic Press, Harcourt Brace Jovanovich – ISBN 0-12-382255-6 [8] M. Roantree, J.B. Kennedy, P.J. Barclay Providing views and closure for ODMG object model. Information and Software Technology, 41, 1999, pp 1037-1044. 14