management system, at the model level. Designers and programmers can use obects to

describe and extend the behavior of the database itself; without the substantial coding involved in changing the application Jystem. In this article, the authors extend Adam to handle constraints and F-elationships.

Extending ODBMSs Using Metaclasses OSCAR D~Az, University of Basque Country NORMAN W. PATON, Heriot- Watt University

oriented language capabilities, deduc- tive databases add expert-system capa- bilities, and active databases, which can respond automatically to events within or outside the database, add event-driven capabilities. T h e ever- increasing complexity of database sys- tems is also stimulating research into extensible databases, which users can tailor to specific applications. T h e complexity of the data users will store in future database systems is also bound to increase the demand for extensible, powerful data dictionaries to describe that data.

Adam, an object-oriented database-

atabase system design- ers have proposed several ways t o increase the amount of functionality the database system itself can provide. Obiect-oriented databases add obiect-

management system we developed, provides metaclasses to make it easier t o extend an ODBMS. In Adam, metaclasses turn traditional classes into normal objects, which can receive messages and which have attributes and methods that describe the data- base's s t ructure and behavior. I n essence, the attributes and methods take on the role of a data dictionary - designers use them to describe the database itself.

Systems based on metaclasses are not as extensible as other approaches, including persistent languages' or the use of a storage and optimizer manag- er' because they let designers extend the data model only, not the DBMS kernel. However, such systems are much easier for designers t o use because metaclasses let them use the

0 Metaclasses let database D designers extend Adam, an object-oriented database-

40 07407459/94/SO4.W 0 1994 IEEE MAY 1994

object-oriented data model to extend itself and avoid the considerable cod- ing involved with other approaches. In ou r experience, programmers can develop extensions quickly with a modest amount of coding because inheritance and the overriding model mechanisms make i t easy to reuse existing functions to specify exten- sions.

Metaclasses also differ from the parameterized classes supported in object-oriented languages like C++. With the parameterized class mecha- nism, you can create several classes with the same attributes and methods, but specify different types for some of the attributes or methods. For exam- ple, you can create different collection classes to represent collections of inte- gers, strings, persons, and so on. Each collection class supports the same operations; it is simpi; the type of data on which it acts that differs from class “new” to Student. Hence, Entity-con-

such classes share object-creation behavior and attributes. This flexible mechanism lets you create new kinds of classes easily.

METACLASSES

In the object-oriented paradigm, you use the subclass mechanism to refine classes. When you introduce a new class - Student, for example - you think about how it differs from or is similar to other classes, like Person, to determine what is new and what you can reuse.

Metaclasses let you use this mecha- nism to define the system itself. Figure 1 shows the levels of refinement in a metaclass system. At the lowest level, instances represent real-world entities whose characteristics are abstracted into classes at the second level. Classes, which in this system are treated as instances, share some features that are abstracted into a metaclass. Likewise, the object meta-class holds the shared

I E E E S O F T W A R E

definition of metaclasses. For unifor- mity and to avoid infinite regression, meta-class is an instance of itself.

So you use a metaclass to define the structure and behavior of class objects, just as you use a class to define the structure and behavior of instance objects. Using subclasses, you can introduce new concepts to specialize existing ones, a t both the class and metaclass levels. For example, the metaclass Entity-concept, which defines, obviously, the structure and behavior of entity concepts, can easily be reused to define Relationship-con- cept.

The creation process is uniform. In Figure 1, to create the Entiq-concept metaclass, you send the message “new” to Meta-class; to create the Student class, you send the message “new” to Entity-concept, and t o create the object john, you send the message

Advantages. This approach treats metaclasses as classes and application- defined classes as standard database objects. T h e first property supports t he ref inement of default system behavior using specialization and inheritance. T h e second property means classes can be s tored and accessed using the data-model facility.

T h i s approach has three major advantages:

+ Extensibility. Because the system itself is described w-ith the object-ori- ented approach, it can be seen as a core of facilities you tailor to specific applications.

+ Accessibility. Data held at the class level, metadata, is available like any other data in the system because class- es are proper objects.

+ Uniformity. You use the same tools to query, relate, and specialize data and metadata. Because there are no new mechanisms to learn and no distinction is made between data and metadata, your only concern is the level of abstraction at which you are

Meto-class 1 .

Relatiomhip-tonrepi A

(lass level

1 instance level

1 line5 john I i

0°C

Figclre 1. Metadata for a file. Both the lookup-metadata for a file and the file-spe- cific metadatri are stored within sector boundaries, as indicated.

4 1

:- new( [entity-concept, [ is-a( [class] 1 ,

slot~slot~tuple(created_by,global,single,optional,string)) 11) * meta-class :- new([student, [

is-a( [personl), created-by([josemil), slot(slot~tuple(cname,global,single,optional,string)),

slot(slot~tuple(surname,global,single,ogtional,string)),

1 I ) * entity-concept slot(slot-tuple(age,global,single,ogtional,integer))

:- new([ObjIden, [ cname ( [ john1 ) ,

metaclass Entity-concept, a class Student, and a terminal instance john. Although every object is created by sending the message “new” to its class (message sending is indicated by 3)) class and terminal instance creation are not identical. Unlike john, the definition of Student includes the desc r idon of the attributes cname.

Figure 2. Metaclass, class, and instance definition in Adam. Thefeatztres specrfied 1 surnake, and age and can also involve $17- each slot are its name (such as mame), visibility (such as global), cardinality some method definitions. Moreover, (such as single), status (such as optional), and result gpe (mch as strind.

working. Object-oriented languages differ in

their support for metaclasses as proper objects. C++ does not support meta- classes a t all, and Smalltalk-80, Loops, Adam, and Clos do, but with major differences.

ADAM

In object-oriented modeling, you identify the entities involved, rather than doing a stepwise refinement of the process. Metaclasses let you describe the system itself in terms of database objects, so the system itself is the domain to be modeled and the process concerns how t o create, retrieve, update, and delete db orjects.

Broadly speaking, a db object is an aggregate of structural and behavioral information, described using attributes and methods. Before you can extend an Adam database, you must under- stand which attributes and methods are used to implement the Adam sys- tem.

Object creation. A DBMS’s principal feature is i t s abil i ty t o create d b objects. As Figure 2 shows, in Adam, you create any object by sending the object-creation message “new” to another db object, its class. ;U1 classes understand the message. Thus , in Adam we distinguish between termi- nal instances and classes.

+ Teiminnl instances (for example, john in Figure 2) cannot create other

.._______ ~ ~~

instances - you cannot send the object-creation message to this kind of object. Terminal instances have a system-generated object identifier, do not have slot or method descriptions, and cannot be arranged in hierar- chies.

+ Classes are object generators that understand the object-creation mes- sage. They have an application-pro- vided object identifier, may have slot o r method descriptions, and can be arranged in hierarchies, using the meta-attribute is-a.

Following the object-oriented par- adigm, attributes and methods define a class. A class encompasses structural and behavioral features, which are defined in Adam using the metameth- ods put-slot and put-method, respec- tively. These methods are stored in Class-beh, a metaclass that stores behavior common t o a l l classes. Class-beh is an object that describes the DBMS itself. Depending on the class, these methods define attributes o r nieta-attr ibutes, methods o r metamethods.

For example, t o define a class’s structure, you use the meta-attributes slot-desc and method-desc, also stored in Class-beh. Figure 2 shows the five structural features common to every slot in Adam: name, visibili- ty, cardinality, status, and result type.

However, terminal-instance cre- ation and class creation differ in some aspects.

Figure 2 shows these distinctions, in Adam notation, in the creation of a

the system automatically generates the object identifier of john and uni- fies it with the variable ObjIden. O n the other hand, the programmer gives the objec t ident i f ie r of S tuden t through the literal student.

T o account for these differences, in Adam the object class holds the method ner used to create terminal instances, and the object meta-class holds the new used to create object generators (either classes o r meta- classes). Both objects are instances of Class-beh. Figure 3 shows this instan- tiation hierarchy.

Object behavior. Every db object can be retrieved, updated, and deleted, regardless of its place in the instantia- tion hierarchy. For example, every object can receive the message “delete,” so i t is n o t desirable to repeat the definition of delete in every class. Instead, in Adam, behavior com- mon to all objects is arranged in an inheritance hierarchy.

As Figure 4a shows, the root of the inheritance hierarchy is the class Object, which collects the behavior common to all objects; Figure 4b shows that, by defining Class-beh as a subclass of Object, all object genera- tors in the system become instances (that is, classes) of Object. Similarly, all terminal instances are instances of Object because their classes are sub- classes of Object. This is done by the method new, which ensures tha t Object is the superclass of every class to which you do not explicitly give a s.uperclass. T h e Adam DBMS is thus described by Class-beh, Class, Meta-class, and Object.

4 2 M A Y 1 9 9 4

:Idam has heen implemented using the Eclipse persment Prolog system (an extension of AlegaLog’), which it us e s to su 1) port second a ry storage ~nanagnicn t, concurrency control, and transactions.

EXTENDING ADAM

.l’o extend Achni, VOLI specialize the

constrained instances and classes where constraints are specified. Like any o the r object , a constrained instance is created when the message “new” is sent to its class, and it can have attributes, receive messages, and be deleted. T h e creation and deletion of constrained classes, on the other hand, required extensions to both the inheritance iind instantiation hierar- chies.

T h e instant ia t ion h ie rarchy is extended so that the attribute defini- tion - of terminal instances only - can include :I list of contstraints. For example, Figure 6 shows how the class E,ntitv-class is constrained. Adam

. . Class-beh, C l a s s , hleta-class, and Object classes along nvo dimensions:

+ T h e inheritance hierarchy, in Xvhich objects are arranged to share coinmon behavior.

+ T h e instantiation hierarchv, in which objects are arranged according keeps standard attribute definitions in t o their ahility to genera te o the r ohjects.

The issue is how these dimensions are affected I)? the introduction of new fiinctionaliq .

Constrained objects. I 11 d a t a Iia s e s , integri?. constraints keep data consis- tent. .I database’i data model provides structural constraints, but other con- straints cannot t i e reflected structura- I!.. ‘Thesc range f rom simple ( a t eenqer mus t he between 1 3 and 10 wars old) to coinplex (the projects a lecturer is responsible for must be the same projcctt” the research assistants \r orL on). C;onstraints like these that restrict the va ld database states are ca 11 ed Stiltil. C . O ? / S W f / i / / rs. Us LI a I l!., p r ogr a 111 ni e r s ha n tl- code

these constraint,j into an application, capturing violations with procedural mechanisms such as t r iggers o r enforcing them informally to avoid illegal updates, h u t these techniques are not uniformly reliable. A database that can be easili. and reliably extend- ed to include constraints as attributes can reduce development cost5. Kecause Adam requires tha t con- straints be coded only once, it can enforce them uniformly, and is thus easier to maintain.

the meta-attribute slot-desc, which is updated by the method pu-slot, which in turn has as its input parameter the tuple slot-tuple. For constrained class- es, the attrihute definition refers not only t o t h e features described in slot-triple but also to the list of con- straints. This information is stored in

new (t)

new put_s/ot put-method slot desr rnetf;od-desc *\ is-a

Key: new

f- instance-of ~ ( + I specialization ~

Figure 3. Instantiation hierarcby in Adam.

the meta-attribute attribute-desc. F igure 6 also shows t h e new

method, put-ntti-ibzite, which creates extended attributes. Slot-tuple collects the standard attribute description, which is then passed as a parameter to the standard put-slot method to create an appropriate slot. Constraints are then introduced using the put-ransts

Key:

Person Student iohn

Obiect

Class-beh Working-in Person b “ I ”/

Figure 5 illustrates ho>r m e extend- ed -\dam to support con~traints. 1T-e introduced t w o neu kinds of objects.

Figure 4. I?iherztance hierarchy in Adam. (A) Class Obect holds the behaviol. co?nmon to nil oLyects. I t creates Class-beh. (B) Because Class-beh is a subclass of Olyert, crll object generators a w instances of Olyect.

I ~ _ _ _ _ ~ - ___ ~ ~~~ ~ ~ _ _ _ _ _ _ ~ ~ 1

I E E E S O F T V v A R C 4 3

Figure 5. Extending A d a m t o support constraints with the put-consts and delete-consts methods.

method, which generates the appro- priate code for enforcing the con- straints, and updates the correspond- ing attribute-desc attribute.

Once put-attribute is available, any terminal-instance class can define attr ibutes by calling this method. However, the normal procedure is to define attributes when you create the class, not after. For this, we extended

the instantiation hierarchy to special- ize the method nm for class creation. Figure 7 shows the metaclass Entity-meta-class, which holds the specialized new method that lets you specify constraints a t class creation. First, the class is created with the attribute definitions removed using the default new method (by sending new to Super). Then attribute defini-

:- new([entity-class, [ is-a ( [class] ) , elot(s lot-tuple(attribute_desc,global ,eet ional , attribute-tuple) ) ,

method((put_attribute(global,[l, [attributefuplel, 1 1 , [AttTuple] ) : - message-recipient(ClasaName), AttTuple = attribute-tuple(AttName,Vis,Car,Status

SlotTuple = slot-tuple(AttName,Vis,Car,Status,Type),

(Consts < > [ I 3 put-consts( [Conatsl) 3 ClassName)

Type, Consts),

pUt-SlOt([SlOt~ple]) + ClassName,

) )

method((gut-consts(family, [ I , Iplogl. [ I . [constel) :- ...

Figure 6. Entity-class definition.

t ions are added by t h e method put-attri bute.

With the extended system, you can define a constraint class such as

new( :lecturer, ; attri&te(a:tribute- tupie(age, glojal,

single, optional, string,

[age of lecturer > 2 0 : ) ) 1 1 ) entity-class

Because lecturer is an instance of Entity-class, the example uses the class-creation method defined in Figure 7 .

W h e n you delete a constrained class from the inheritance hierarchy, Adam must remove the code that maintains the constraints. T o achieve this, we specialized the delete method, as shown in Figure 7. Before sending delete to the superclass, the method requires some deletions in the related classes. Although this specialization is included in Entity-meta-class, for deletion it functions as a subclass of Object (that is, as a class of the inheri- tance hierarchy).

Relationship objects. Most object-ori- ented systems associate semantic information with abstract relation- ships, such as generalization and aggregation, but few describe the semantics of application-defined rela- tionships. Programmers are forced to wire the semantics of a relationship in to their code. Adam supplies a mechanism to specify the semantics of these relationships in the same way that semantic data models describe the semantics of abstract relationships.

Suppose working-in is a relation- ship between a company and a person. Once the relationship is established, can a person obtain a working-address attribute from the company’s address attribute? If the system does not speci- fy anything, different applications may draw different conclusions as to what working-in means. Applications must also understand the semantics of inser- tion, deletion, and modification opera- tions in application-defined relation-

4 4 M A Y 1 9 9 4

:-new([entity-meta-class, [ is-a( [meta-class1 ) ,

ships. Enhancirig the semantics of a p p 1 I ca t i o n - d e 1'1 ne d re 1 a t i o n 5 h i p 5

~ method( (new(globa1, [I, [string, plogl, 1 1 ,

[ClassName,Attsl ) :- findall(NoAtt,

(Member(NoAtt,Atts),not NoAtt =

in the database and helps preserve the system's behavioral integrity.

Figure 8 shows how we extended Adam to suppori: application-defined relationships with two new kinds of objects: relationship instances and relationship classes. You handle rela- t ionship instances like any o the r object. Relations hip classes, however, have new requirements both to create and delete them, so we had to special- ize both the inheritance and instantia- tion hierarchies.

I$re s pe ci a I i n: d the instant i a ti on hierarchy because defining relation- ships involves semantics in addition to those used to define entities. Hence, the 111 e t a c 1 ass Ke 1 a t i o n s h i p-cl a s s , which indicates how to define rela- tionship objects, is a subclass of the metaclass Entity._class. Relationship- class inherits the normal behavior of an entity object, as well as new fea- tures t o account for the extended semantics of relationships. Figure 9 shows these adtli tional semantics, related-class1 ~ related-class2, and operational_sernantics, which are held in extra meta-attributes. These slots are only repositories for data the sys- tem inust interpret - they convey real meaning only if there are ade- quate procedures to support the rela- tionship's expected behavior.

Programmers must consider relat- ed-class I and related-class? only when the relationship class is created. ' lo account for these new semantics, Relationship-met:i-class is a subclass of Entity-Ineta-class that has specialized the method mzi. Figure 10 shows this d e f i n i ti o n . B e fo re the s pe ci a1 i zed method neii is sent to Super, it checks if the classes that are to be related exist.

In addition, relationship classes inherit the abiliri to cope with con- straints. Figure 11 shows the relation- ship class M70rlung-in, which includes the constrained attribute seniority. In this case, Vi'orking-in is an instance of Relationship-class, so to create it, we

attribute(-)), NOAttE),

new([ClassName,NoAtts]) 3 super, (member(attribute(AttTuple), Atts).

put-attribute([AttTuple]) 3 ClaSEName, false

i true) 1 ) ,

method( (deletetglobal, [I, [I,[], 11) :- delete-consts 3 self,

L

Figure 7. Entity-meta-class definition.

W - k bmtvM-do% new(+) - new(+) c-

delefeit) delete(+)

oms h r f t v b new(+) t- put-attribute +.-----

put_consts relotedItlass2 delete-mnsts op-semantics

Figure 8. A n extension to support application-defined relationships.

:- new([relationship-class, I: is-a([entity-classl), slot(slot~tuple(related_classl,global,globa1,sing1e,

~lot(slot~tuple(related_class2,global,sing~e,

slot(slot~tugle(operational~semantics,global,set, I optional,related-class_tuple) 1,

optional,related-class-tup1e)),

optiona1,plog) ) ,

!

... 11) * relationship-meta-class.

Figure 9. Relationship-class definition.

:- new([relationehip_meta-c~aee,[ ie,a([entity-meta,claarr] 1 , method( (new(global,[I, [etring, plogl, I 1 I [Name,

Attel ) : - Check that claeeee to be related exiet

Create role attribute8

Create attribute-baaed view of the relationehip

new(tNanm, Atte]) * euper

...

...

... ) I ,

method((delete(globa1, [ I , [ I 8 [ I l [ I ) : - Make appropriate modifications in the related

claesee ... delete =+ euper

) )

Figure 10. Relationship-meta-class definition.

I : - new( [working-in, [

related-claeel([ related_Cla88_tUpl~(per8On,th0_~lOy0e, workinggla~ee~ eet, [ I 1 ) ,

related-clase2( [ related_claee_tuple(company,the_compsny,~loyeee, est, 11 8

operational_semantice([ propagate moving from the-company to the-employ-

eel ) I attribute(

[eeniority of working-in > 0 1 ) ) attr~te-t~le(seniority,glabal,set,qptioaal8integer,

Figure 11. Relationship class Wmking-in.

F i p r e 12. Metaclass compatibility problems.

4 6

used the method new that had been specialized to support relationship semantics. The relationship semantics are declared in the meta-attributes defined in Relationship-class and inter- preted by methods specified either in Relationship-class o r in Relation- ship-meta-class. The attribute opera- tional-semantics indicates what behav- ior follows from the establishment of a relationship. For example, in Work- ing-in, whenever the message “mov- ing” is sent to a company, it also goes to all the company’s employees.

Deleting a relationship class involves deleting some extra code from the related classes. Figure 10 shows the specialization of the delete method that accomplishes this.

DRAWBACKS

Some authors have pointed out sev- eral problems with metaclasses!

+ Metaclasses make the system more difinrlt to understand. In our experience, once programmers are more familiar with metaclasses, having a single mech- anism for both data and metadata helps them progress from database design to database ystm design.

+ By themselves, metaclasses do not provide mechanisms to handle all the run- time consequences of extending the data model. For example, we showed how to describe constraints by defining an extension using metaclasses, but we did not show how to maintain these con- straints. In practice, active rules gener- ated as a side-effect of constraint cre- ation maintain constraints: Thus , Adam uses metaclasses to create and manipulate constraints and active rules to enforce them. + Metaclasses do not facilitate low- level extensions. Metaclasses exist at the model level, above the structures that specify access language, storage man- agement, and concurrency and access control. Thus, metaclasses do not let applications define policies at all lev- els, which some extensible database systems support. The trade-off is that

M A Y 1994

i t is much easier to implement the extensions that are supported.

+ With metaclasses, programmers must cope with three levels o f objects: instances, classes, and metaclasses. W e acknowledge that it can be difficult at first to grasp the notion of specializing behavior used to create classes and behavior used to create instances. The programmer must keep bo th the inheritance and instantiation hierar- chies in mind when extending the sys- tem.

+ Because instance methods can invoke class methods, problems can arise when the class hierarchy is not parallel t o the corresponding metaclass hier- archy. Figure 1 2 shows a class hierarchy that does no t mirror the metaclass hierarchy: S tudent is a Person; whereas, Student-meta-class is not a Person-meta-class. Suppose that Person has a height attribute and a method to check if a given person is taller than average - the is-thispr- son-tall method, which is inherited by Student.

Because this method implies a metaclass request (to obtain the value for the average-height a t t r ibute) and the metaclasses of Person and Student do not coincide, this method will fail for the Student class.

Th i s problem does no t arise in Smalltalk, in which the system implic- itly defines metaclasses and arranges them in a structure that mimics the class hierarchy. In Adam, however, we had to apply some metaclass-compati- bility rules.

After presenting these problems, Silva Khoshafian and Suzanne Abnous conclude that the metaclass approach is “not satisfactory,’’ and favor the C + + classes-as-types a p p r ~ a c h . ~ W e think this conclusion is partially true when you are talking about programming languages, but we believe explicit metaclasses are a pow- erful mechanism for improving data- base extensibility, uniformity, and accessibility. It takes some time to get used to metaclasses, but the results are worthwhile.

ntroducing metaclasses in to I ODBMSs makes it easier to treat data and metadata uniformly. You need only one mechanism to browse, query, relate, and specialize objects. Extensi- bility and accessibility are by-pro- ducts of the uniformity that metaclases provide for the user domain, and uni- formity moves upward to the system domain. Any new facility introduced for objects is automatically applicable to both data and metadata. ODBMSs can smoothly evolve through the introduc- tion of new functions without changing the core system.

Metaclasses are no t free f rom drawbacks, and further research is

needed. Nevertheless, uniformity is a major achievement whose advantages have been put to work in many areas.

W e and our colleagues are contin- uing to explore metaclasses in Adam, work that includes developing an extensible active database system in which active rules are implemented as objects,6 developing an interface that can be readily tailored to support visu- alizing the data-model exten- sions,’ and a combination of all these features.’ Other work done in tai- lorable metadata systems has shown that these facilities can be used in data-dictionary systems and heteroge- neous +

REFERENCES 1. A. Dearle et al., ’’Constructing Database Systems in a Persistent Environment,” Proc. Int’l Con$

2. M.J. Carey et al., “The Exodus Extensible DBMS Project: An Overview,” in Readingsin Object- Vely Large Data Bases, Morgan Kaufmann, San Mateo, Calif., 1987, pp. 117-126.

Oriented Database Management System, S. Zdonik and D. Maier, eds., Morgan-Kauhann, San Mateo, Calif., 1989, pp. 474-499.

3. J. Bocca, “MegaLog: A Platform for Developing Knowledge-Based Management Systems,” Proc. Int’l Symp. Database Systemsfor Advanced Applicatzons, 1991, pp. 374-380.

4. S . Khoshafian and R. Abnous, Object Orientation: Concepts, Languages, Databases, User Interfaces, John Wiley & Sons, New York, 1990.

5. N. Paton, 0. Diaz, and M.L. Barja, “Combining Active Rules and Metaclasses for Enhanced Extensibility in Object-Oriented Systems,” Data and Knowledge Eng., Vol. 10, 1993, pp. 45-63.

6. 0. Diaz, N. Paton, and P.M.D. Gray, “Rule Management in Object-Oriented Databases: A Uniform Approach,” Proc. Int’l Cor$ Vely Large Data Bases, Morgan-Kauhann, San Mateo, Calif., 1991, pp. 317-326.

7. N. Paton, G. al-Qaimari, and A.C. Kilgour, “An Extensible Interface to an Extensible Object- Oriented Database,” Proc. Int’l Workshop on Interfaces t o Database System, Springer-Verlag, London, 1993, pp. 265-281.

8. L. Mark and N. Roussopoulos, “Metadata Management,” Cmputer, Dec. 1986, pp. 26-34. 9. S. Hong and F. Maryanksi, “Using a Meta Model to Represent Object-Oriented Data Models,”Proc.

Data Eng. Con$, IEEE CS Press, Los Alamitos, Calif., 1990, pp. 11-19.

Oscar Diaz is a lecturer in computing science a t the University of the Basque Country, San Sebastiin. His research interests include active databases, object-oriented databases, and extensible database systems.

Diaz received a BSc in

Norman W. Paton is a lecturer in computer sci- ence at Heriot-Watt University, Edinburgh. His research interests are extensible database sys- tems, active databases, interfaces to extensible databases, and the integra- tion of deductive and

computing science from object-oriented techniques. Paton received a BSc and a PhD in computing the University of the Basque Country and a PhD in

object-oriented databases from Aberdeen University.

iddress questions about this article to Diaz ar Departamento de Lenguajes y Sistemas Informdticos, Universidad del Pais Vasco, Euskal Herriko Unibertsitatea, Apartado 649, San Sebastiin, Spain; ipdigao@si.ehu.es; or Paton at Department of Computing and Electrical Engineering, Heriot-Watt University, Riccarton, Edinburgh, Scotland; norm@cee.hw.ac.uk.

science from Aberdeen University.

~~

I E E E S O F T W A R E 4 7