rdbas: a relational database system for non-experienced users

North-Holland Microprocessing and Microprogramming 12 (1983) 99-109

RDBAS: A Relational Database System for Non-Experienced Users

99

R o m a n H e r m i d a , J o s e R u z , J o s e T i r a d o a n d

A l f r e d o B a u t i s t a

Dept. de Informatica y Autornatica, Facultad de Ciencias Fisicas, Universidad Complutense, Madrid-3, Spain

In the last years, the relational approach has developed into a very interesting foundation to the implementation of database management systems oriented towards small computers.

This paper deals with a software tool for assisted access to databases using the relational model (RDBAS). A main design goal has been the elaboration of a system whose utilization by unexperienced users requires only a bit of learning effort. Working towards this goal, a non-procedural semi-graphic query language with relational processing capability has been implemented. This language is based on the domain relational calculus and can be used in an interactive way.

An interesting feature of this system is the extensibility of its command repertory. Specific purpose new commands can be defined to be used, even by people who are unaware of the query language.

Information structures and techniques used in implementation are also discussed.

Keywords: database management, relational database, query language, personal database.

1. Introduction

In the seventies, the relational data model [4] has attracted the attention of a large number of resear-

chers from several areas in the field of data processing. Several factors can be pointed out as

causes of the widespread interest aroused by the relational model, and the following are emphasized: - The simplicity of its data structures. Relations

are the sole information structures in a relational database (DB) and they are expressed in a universally understood representation by means of tables.

- The soundness of its theoretical foundation.

This factor along with the former, has provided

a basis to the development of a lot of research

on several DB topics such as data semantics [11]

or DB machines [8]. - The definition of operators with set-processing

capability like those of the relational algebra. These operators avoid the need for program loops for the expression of DB access requests.

- The introduction of non-procedural high-level

query languages which simplify the direct in-

teraction of end users with DBs to retrieve or update data in any desired combination.

The field of small computers has also been in- fluenced by the relational model. Thus, in the last

years, several Universities and research centers have considered the relational model as an in-

teresting foundation to the implementation of database management systems (DBMSs) on small computers, and as a result they have undertaken

projects in this direction. We can cite for instance: - The MRS system [7] developed in the University

of Toronto on machines of the LSI/PDP-11

family. This system has a query language rather similar to SQL [3].

- TITAN [6], a system implemented on an Apple II microcomputer. It is intended for users

without a specific programming knowledge.

- PEIRCE [12], a system developed in the Florida Atlantic University on a minicomputer HP2100. PERICE has a query language based on the relational algebra and allows the users to add new

commands to the basic command set of the

system. - T h e PEPIN system [2], which has been

developed in collaboration by the University of Paris and the INRIA, puts an special emphasis on performance.

This paper deals with the design and implemen-

100 R. t-lermida et al. / RDBAS: A Relational Database System for Non-Experienced Users

tation of a software tool for database management on small computers using the relational model. The main design goals inspiring the concep- tion of our system are the following:

• Simplici ty . The system must be easy to use by users who are not necessarily experienced. It must have, therefore, an easy-to-learn high-level query language where the complexity of expressing a data access request will be related to the complexity of the access request itself. There are several studies on the difficulties to learn and use query languages [10,13,15]. They seem to show that query languages with bidimensional structure provide the users with an easier and faster way to expressing access requests.

• Capabili ty to interact with users, helping them to per form any DB operations.

• Adaptabi l i t y . The system must be able to cope with sundry working environments. To achieve this goal, the system must allow the definition of specific purpose commands, which reduce the time to express the most frequent access requests, and which t ransform the system into a tool able to be handled even by people who don ' t know the query language.

• Modular i ty . The system software must be modular enough to be able to run on computers with a small-sized main memory.

A detailed study of the query language, through several examples is presented in section 2. Section 3 is devoted to briefly show how to define and use user-provided commands. Informat ion structures supporting DBs are analyzed to some degree of detail in section 4. Section 5 deals with the execution of data access requests called by users. A short description of the software organization of our system can be found in section 6. Finally, in section 7 we present our concluding remarks and we ad- vance some ideas which will be developed in the near future.

The current version of our system is running on an HP21MX minicomputer with 32K of main memory.

2. Query Language

There exist several factors which have a dramatic

influence on the users acceptance of a DBMS. Amongst them, the structural simplicity and the selective power of the query language are conclusive.

In our system, the direct interaction of end users

with a DB is performed through a semi-graphic high-level query language based on the relational domain calculus. This language is inspired on the sintax of Query-by-Example [17] and it can be used in an interactive way.

The various features of the query language will be described taking as an example a database of paintings exhibited in Spanish Museums, con- sisting of two relations. The first relation, named PAINTER, stores information about painters, specifying for each one an identification number ( P T E R # ) , his name (PNAME), his birth year (BIRTH) and his nationality (NATION). The se- cond relation, named P A I N T I N G , stores for each painting an identification number (PTING #), its title (TITLE), the painter 's identification number ( P T E R # ) , the picture seize (WIDTH and H E I G H T ) , and the place where it is being exhibited (MUSEUM and CITY).

The use of the query language is based on the display of the scheme of the relations invoked by the user. When a relation scheme is displayed on the screen, the user must fill in the information re- quired by the operation he wishes to perform. The following set of examples shows the main features of the query language.

2.1. Selection Operations

2.1.1. Selection in one relation

The expression of a question about the information stored in one relation is the simplest case of selection operation. Let us suppose the user wishes to ask for ' the names and birth years of all Spanish painters ' . Fig. la shows how this question is expressed. The user responds to the message 'REL? ' invoking a relation name. Then, the system shows the scheme of that relation. Next, using the relation scheme as a form to fill in, all the necessary information to determine unambiguously the data that he wishes to retrieve, must be inserted. For this, a character 'D ' must be placed in the field of each attribute whose values must be displayed. Further-

R. Hermida et aL / RDBAS." A Relational Database System for Non-Experienced Users 101

wSE REL ? PAINTER PTER# PNAME BIRTH NATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D D =SPAIN

REL ? @E

(a)

wSE REL ? PAINTER PTER# PNAME BIRTH NATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D .NUM #SPAIN

REL ? PAINTING PTING# TITLE PTER# WIDTH HEIGHT MUSEUM CITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

,NUM =PRADO -MADRID

(c) wSE REL ? PAINTING PTING# TITLE PTER# WIDTH HEIGHT MUSEUM CITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D D >'HEIGHT

Fig. 1. Selection Operations.

more, each criteria of selection must be stated by means of a comparison operator f rom the set / > , > = , < , < = , ¢ , - - / and an operand type- compatible with the attribute heading its column.

The expression of a question is finished by the answer ' @ E ' to a new message ' R E L ? ' . This ter- minat ion line has been omitted in the remaining examples.

2.1.2. Queries on several relations

Let us consider the question ' f ind the names of those foreign painters who have some paintings in

the Prado Museum' . The way to express this question is shown in fig. lb. There we can observe the introduction of a variable, NUM, whose name is preceded by a point. It serves to specify that the system's answer shall be made up only by tuples of the relations P A I N T E R and P A I N T I N G with identical PTER#-componen t s . The use of such variables gives to the query language the unrestricted join capability as defined by Codd [5].

It is obvious that the variables appearing in the expression of a query merely play a referential role. Therefore in the later example any other name, such as .23 or .X, might be used instead.

102 R. Hermida et al. / RDBAS: A Relational Database System for Non-Experienced Users

(a) WIN REL ? PAINTING

PTING# TITLE PTER# WIDTH HEIGHT MUSEUM CITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9352 GUERNICA 471 7.82 3.50 PRADO MADRID

wOE REL ? PAINTER PTER# PNAME BIRTH NATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<t300

(b)

(c) ~MO REL ? PAINTING PTING# TITLE PTER# WIDTH HEIGHT MUSEUM CITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

=COUNT ORGAZ'S BURIAL PRADO MADRID

Fig. 2. Update Operations.

2.1.3. Context searching capability When a criterium of selection on a relation is expressed using a name of an attribute as operand, a context searching operat ion must be performed. This means that for every tuple in the relation, the value of one attribute is compared with the value of another attribute.

Let us consider the question ' f ind every painting which is wider than it is high' which is expressed in fig. lc. In this example we can see how the criterum of selection > ' H E I G H T makes the system to per- fo rm a context searching operat ion carrying out the comparison of the values of the attributes W I D T H and H E I G H T , for every tuple of the relation P A I N T I N G .

2.2. Update Operations

2.2.1. Insertion The insertion of a tuple into a relation requires the

user to give a value for each attribute of the relation. Fig. 2a shows the insertion of a tuple in the relation P A I N T I N G .

2.2.2. Deletion The deletion command allows the user to delete those tuples of a relation verifying some criteria of qualification. Fig. 2b shows the use of this command to delete f rom the relation P A I N T E R those tuples representing painters who were born up to the year 1300.

2.2.3. Modification This command allows the user to assign constant values to some attributes of those tuples of a relation which satisfy specified qualifying conditions. The use of this command to move the painting titl- ed 'Count Orgaz 's Burial ' to the Prado Museum is depicted in fig. 2c.

R. Hermida et aL / RDBAS: A Relational Database System for Non-Experienced Users 103

Before execution of any operation, such options as the deletion of duplicate tuples or the storage of the result in a temporary file may be selected.

2.3. Relation and Index Management

In our system, the initial definition of the structure of a relational DB can be made through the creation of a source file describing the DB schema by means of a data description language specially tailored for this purpose. A DB description in- cludes, for each attribute, a declaration of its name, type (integer, real or character string) and length.

Moreover, the name of each relation, its attributes and its pr imary key must be specified. The indices which will exist in the DB may also be declared in this description.

However, the initial structure of the DB can be altered by the interactive creation or deletion of relations and indices through appropiate commands. Particularly, when a new relation is being created the system interacts with the user asking him for the name of the relation and the names of its attributes. I f some attribute did not previously exist in the DB, it would be necessary to specify its type and length.

2.4. Other Commands

There is another group of commands to per form auxiliary tasks which will now be briefly considered.

Incorrect or incomplete queries may be edited before or after execution avoiding the need for a complete retyping of such queries. This facility becomes specially interesting when the user has to refine insufficiently defined selection criteria.

Commands exist also to load and unload relations on source files or input /output devices.

Another interesting feature allows the user to save as a permanent relation of the DB, any working relation produced as result of query execution and to rename it if necessary. This allows the chain- ing of query operations and provides new resources to modify the structure of the DB.

3. Command Repertory Extension

The query language also supports the definition of special-purpose new commands which are intended to adapt the DBMS operation to specific working environments.

The definition of a new command is written like an access request to the DB, but in this case symbols preceded by quotation marks may appear in the place reserved to the comparison operands. These symbols will be replaced by constants when the command is used.

Fig. 3a shows the interactive definition of a command, named EXWID, which is intended to find those paintings of a museum exceeding a certain width. After the definition of the operation that the command must perform, the system asks for the messages which must be sent to the user, in time of execution, to request the needed constants. Finally the system accepts the insertion of a label which will head the system's response after the execution of the command.

The use of this command is very easy. It is suffi- cient to invoke its name and to answer the messages sent by the system (see figure 3b).

4. Database Structures

Databases are implemented using the minicomputer file system as support of relations and auxiliary information structures, shown in fig. 4. All information about the structure of a DB is stored in a dedicated file named description file. The existence of this file allows the system to establish the suitable mapping between conceptual and physical levels of the DB and, therefore, allows the users to express queries independently of the storage structure and access methods.

The description file holds the names of all relations belonging to a DB and, for each relation, it stores the list of its attributes along with specifica- tion of the name, the type, the length and the position in a tuple, for each attribute. Furthermore, the description file stores for each relation the list of attributes composing its pr imary key, and the list of attributes on which an index file has been created. A table of user defined commands is also included.


(a) wSC COMMAND NAME . . . ? EXWID REL ? PAINTING PTINGQ TITLE PTER$ WIDTH HEIGHT MUSEUM CITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

O O >"WID - 'X -"Y

REL ? BE

WHAT'S THE MESSAGE FOR WIO WHAT'S THE MESSAGE FOR X WHAT'S THE MESSAGE FOR Y HEADER TO SYSTEM'S ANSWER ?

? ENTER WIDTH : ENTER MUSEUM :

; ENTER CITY : w,w WIDE PAINTINGS www

wEXWID ENTER WIDTH : i . 5 0 ENTER MUSEUM : PRADO ENTER CITY : MADRID

www WIDE PAINTINGS www

PTING# TITLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

234 THE FAMILY OF CARLOS IV g352 GUERNICA

(b)

Fig. 3. User Defined Commands.

The description of the structure of a DB, as well as the description of the existing indices, are kept in main memory buffers, as far as possible, to achieve faster acces to data.

Each relation of a DB is supported by a direct access file with fixed length records, each representing a tuple of the relation.

Some access request to data can be accelerated by the creation of dense index files with the stan- dard structure of B-trees. Each leaf of the B-tree contains a block of index records, and each record stores an attribute value and the starting address of a chain of pointers which are pointing to the main file records having that attribute value. This index- ing structure makes possible an uniform management of pr imary and secondary indices.

The use of dense index files avoids the need for

the records of the main file to be stored in a specific ordering and, therefore the main file can be kept closely packed. In the other hand, it has been shown that the use of dense index files with the structure of B-trees does not involve a greather waste of storage than that needed to structure the main file similarly. On the contrary, some storage saving can be achieved [14].

The selective power of each index, expressed as the ratio between the number of different attribute values existing in the index and the total number of records existing in the main file, can be computed at any moment f rom the information stored in the description file. The value of this quotient becomes an useful parameter when a query is executed to select what indices must be used.

Finally we wish to emphasize that the existence

R. Hermida et a L / RDBAS: A Relational Database System for Non-Experienced Users 105

DATABASE DESCRIPTION

1 I

INDICES TABLE

USER PROVIDED 1 COMMANDS TABLE

STRUCTURE OF RELATIONS

COMMAND t

! COMMAND 2

INDEX ON ATTR. al OF REL.A l l INDEX ON ATTR.

a2 OF REL. A INDEX ON ATTR. bt OF REL. B

RELATION A RELATION B I

Fig. 4. Database Structures.

of some index files does not affect our system capability to process any correct query, and it can only result in faster query processing.

5. Query Execution

Before the execution of any DB access request a

phase of syntactic analysis takes place where various types of errors such as incorrect characters, type incompatibility, undefined operands, etc., can be discovered. When this phase of analysis is suc- cesfully finished, the query.execution is performed following some heuristics intended to help in the minimization of the response time.

The simple queries involving one relation, are ex-


ecuted in a single pass, by combining the selection and projection operations. If there are several indices defined on the attributes whose values must be compared by 'equal' with constants, the index with the highest selective power will be used to rapidly find a set of tuples satisfying one of the search conditions. The remaining conditions are directly checked against each of the previously found tuples.

What we have just said about comparisons by ' = ' is applicable to comparisons by ' < ' , ' < = ', ' > ' or ' > = ' only when the index file has the clustering property. Otherwise the use of the index may cause the blocks of the main file to be read many times.

When carrying out a context searching operation on a relation, without any other criteria of selection, the entire relation is sequentially processed.

Those queries involving two or more relations re- quire the execution of join operations and, of course, they are the operations which can the largest affect on the system performance. The early execution of selection operations can often pro- duce an important reduction of the response times because the join algorithms might run over relations with a smaller cardinality.

On the other hand, when there is a need for executing a sequence of join operations the order of execution may highly influence the response time of the system. An obvious strategy is to try to minimize the size of the relations produced as in- termediate results. Therefore, the cardinality of the relations plays a very important role in the selection of the order according to which the join operations are to be executed.

The join of two relations, A and B, can be car- ried out using the following alternative strategies:

1. For each value of the join attributes of the relation A, those tuples of the relations A and B which have this value in its join attributes are found and kept in two working relations. Next, the cartesian product of the working relations is computed obtaining so a subset of the whole result.

2. This is a technique of nested loops. The algorithm proceeds by comparing each and every tuple of the relation A to those in the relation B and it aims, at the same time, to reduce the number of disk accesses. In general, if the main memory has

room for N disk bloks, the algorithm will compare in each pass the records of one block of the file A with the records of N-1 blocks of the file B. No new disk accesses are performed until the whole join of two subsets of the relations A and B loaded in main memory has been computed. Particularly, if a whole relation fits into main memory, taking up P blocks, it is loaded; and the remaining N-P blocks are used to load successive subsets of the other relation.

3. In this technique, an initial sorting of the two relations on the join attributes is performed. Next, the resulting sorted relations are simultaneously processed and the join is performed.

The choice of the method to perform the join operation depends on such factors as the existence of indices and the size of relations.

When there are clustering indices on the join attributes of relations A and B, the join is executed according to the method 1. When there are no clustering indices the execution of all the defined selection operations is performed as soon as possible. Afterwards, taking into account the size of the resulting relations a choice is made based on the evaluation of suitable analytical expressions to select the fastest of the algorithms 2 and 3. In general, we can say that method 2 (nested loops) will be chosen to execute the join of small sized relations, whereas method 3 (initial sorting) works much better when large relations are to be joined.

Suitable procedures have been developed to execute updating requests. These procedures can act on a relation and its associated indices. When deletion or modification operations are being executed, the search of those tuples satisfying the stated criteria of qualification is performed according to the procedures used to execute selection operations.

6. Software Organization

The software of our system is composed of a set of segments. Because of its modularity it is able to run on computers with small memory capacity. Only a small common program and one segment are simultaneously kept in memory. All segments are stored on disk and they are loaded into memory

R. Hermida et a L / RDBAS: A Relational Database System for Non-Experienced Users 107

USERS

COMMANDS 1

RELATION AND INDEX MANAGEMENT

INTERACTIVE QUERY LANGUAGE

USER PROVIDED COMMANDS DEFINITION

USER PROVIDED COMMANDS USE

SYNTACTIC ANALYSIS

TUPLE UPDATE PROCEDURES

SELECTION G PROJECTION ALGORITHMS

JOINS SEQUENCE G ALGORITHMS CHOICE

JOIN ALGORITHMS

.... I l FILE MANAGEMENT

PHYSICAL DB

RESULT DISPLAY

Fig. 5. Software Organization.

depending on the nature of the action to be performed.

Each segment can perform some well selected tasks alone, avoiding the system performance degradation because of a very frequent segment

swapping when long data manipulat ion operations are involved.

The general structure of the system is shown in fig. 5. There we can see that a segment exists which accepts the user supplied commands and directs the

108 R, Hermida et al. / RDBAS: A Relational Database System for Non-Experienced Users

system to execute the suitable actions. When the execution of a command is finished the user is in- formed and the result, if there is any, is displayed. Communicat ions among segments are performed through shared memory areas.

7. Conclusion

Throughout this paper we have shown the structure and operation of a relational DBMS oriented to small computers. The implementat ion of the DBMS on a HP21MX minicomputer , with RTE operating system and a small size of main memory (32K), shows that this is a reasonable working environment.

It has often been said that the relational DBMSs performance is lower than the performance of non- relational systems with user visible 'navigat ion ' ,

such as the systems based on the hierarchical or the network models. Also often erroneous conclusions about relational DBMSs have been derived f rom the comparison between the time that a relational system needs to execute a very complex query, and the time that a non-relational system spends in the execution of a very simple access request. The truth is, however, that a relational DB without user visible 'navigat ion ' can be designed and provided with all the necessary structural and statistical information to execute the most frequent transactions giv- ing response times similar to those of non- relational systems. But, in addition, the relational system allows the user to express queries in simple and concise terms, even when the execution of such queries is an extremely complex task to the system. We have shown how our system can take advantage of the existence of index files and statistical infor-

mat ion such as the size of relations and the selective power of indices.

At the present t ime we are testing the ease of use and the performance of the system through expressing and executing selected queries on two DBs (a DB about students and a DB about bibliographic references). At the same time the system is working as a tool to teach DBs. In addition, a new high level relational interface which is based on the relational algebra has been developed for teaching purposes.

Further development will be made, in the near

future, with a twofold aim. First of all we will deal with the design of an interface to make possible the use of the DBMS, in an uniform way [4], f rom pro- grams written in FORTRAN. This interface will enable the system to serve as an aid to engineering and scientific applications. Next, the implementation of a software package to the assisted design of relational DBs will be undertaken. We wish this

system to be able to take into account such aspects o f DB design as the physical implementation and the more frequent transactions. But without forgetting the interesting results the DB theory of- fers many which can be applied in the very early stages of DB design [1, 9, 16].

References

[1] Bernstein, P., 'Synthesizing third normal form relations from functional dependencies', ACM TODS, (1,4), 1976, pp. 277-298.

[2] Bouchet, P., Chesnais, A., Feuvre,. J., Jomier, G., and Kurincks, A., 'Databases for microcomputers: the PEPIN approach', SIGMOD Workshop on Small Database Systems, Oct. 1981, Orlando, Florida, pp. 146-151.

I3] Chamberlin, D.D., et al., 'SEQUEL 2: A unified approach to data definition, manipulation, and control', IBM J. Res. and Develop. (20,6), Nov. 1976, pp. 560-575.

[4] Codd, E., 'A relational model for large shared data banks', Comm. ACM, (13,6), 1970, pp. 377-387.

[5] Codd, E., 'Relational database: A practical foundation for productivity', Comm. ACM, (25,2), 1982, pp. 109-117.

[6] Falquet, G., Petitpierre, D., Magnenat-Thalman, N. and Thalmann, D., 'A portable relational database management system for microcomputers', Microprocessing and Microprogramming, 9 (1982), pp. 17-25.

[7] Hudyma, R., Kornatowski, J., and Ladd, I., 'MRS: A microcomputer database management system', SIGMOD Workshop on Small Database Systems, Oct. 1981, Orlan- do, Florida, pp. 174-185.

[8] Luque, E., Ruz, J., Ripoll, A., and Bautista, A., 'Database concurrent processor', Proc. Int. Conf. on Very Large Data Bases, Oct. 1979, Rio de Janeiro, Brazil, pp. 273-279.

[9] Minker, J., Gallaire, H., and Nicolas, J.M., 'Advances in database theory', Plenum Press, N.Y., 1981.

[10] Reisner, P., 'Human factors studies of database query languages: A survey and assessment', ACM Computing Surveys, (13,1), Mar. 1981, pp. 13-31.

[11] Schmid, H.A., and Swenson, J., 'On the semantics of the relational model', ACM SIGMOD Int. Symposium on Management of Data, 1976, pp. 9-36.

[12] Solomon, H., and Kirshen, C., 'PEIRCE: A relational DBMS for small systems', SIGMOD Workshop on Small Database Systems, Oct. 1981, Orlando, Florida, pp. 152-161.

R. Hermida et al. / RDBAS: A Relational Database System for Non-Experienced Users 109

[13] Thomas, J.C., and Gould, J.D., 'A psychological sutdy of Query by Example', Proc. NCC, AFIPS Press, Arlington, Va., 1975, pp. 439-445.

[14] UIIman, J., 'Principles of database systems', Computer Science Press, Potomac, Maryland, 1980.

[15] Welty, C., 'A comparison of a procedural and a non- procedural query language: syntactic metrics and human factors', Ph.D. dissertation, Univ. Massachusetts, Amherst, May 1979.

[16] Zaniolo, C., 'A new normal form for the design of relational database schemata', ACM TODS, (7,3), 1982, pp. 489-499.

[17] ZIoof, M., 'Query by Example: A database language', IBM Syst. J., (16,4), 1977, pp. 324-343.

of Ph.D. at the UCM. His research interests are database theory and database management systems.

Jose J. Ruz was born in Montitla, Spain. He received the M.S. and Ph.D. degrees in Physics from the UCM in 1975 and 1980 respectively. Since 1976 he has held the position of associate professor of Computer Science at the UCM. His current research interests lie in computer architecture and database machines.

Jose F. Tirado was born in Madrid, Spain. He received the M.S. and Ph.D. degrees in Physics from the UCM in 1973 and 1977 respectively. Since 1974 he has been a member of the Department of Informatics at the UCM. His research interests include computer architecture and database management systems.

Roman Hermida was born in Padron, Spain. He received the M.S. (Physics) degree from the Universidad Complutense de Madrid (UCM) in 1977. In 1978 he obtained a grant from the 'Ministerio de Educacion y Ciencia' to work towards the degree

Alfredo Bautista was born in AIcala de Guadaira, Spain. He received the M,S. (Physics) degree from the UCM in 1975. At the present he is an associate professor of Computer Science at the UCM. His research interests are database machines and fault tolerant computing.

rdbas: a relational database system for non-experienced users

Documents