Download 5. Examples of Suggested Solutions in OODB Views

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