Backend Database Systems

FRED J. MARYANSKI
Digital Equipment Corporation, 146 Main Street, Maynard, Massachusetts 01754

Backend database systems have been proposed as a solution to the problems of

overloaded data processing installations. This tutorial examines backend database systems
in terms of their basic structure, their potential benefits and drawbacks, and the problems
facing developers of such systems. Several prototype systems are described, and research
on extensions of the backend concept is discussed. The structure of the hardware and
software components of backend database systems is presented in detail. The
performance problems encountered in recent prototypes are pointed out and potential
solutions indicated.
Keywords and Phrases: database systems, backend machine, distributed databases,
database machines
CR Categories: 3.50, 4.33, 6.22

INTRODUCTION
and prototyped similar systems. However,
The introduction of generalized database according to the definitions presented here,
management systems in the late 1960s re- the author is unaware of any backend
sulted in a substantial increase in the ca- DBMS available in the marketplace. In this
pabilities of business data processing in- paper the structure and operation of back-
stallations. Unfortunately, this increase in end databases are presented, followed by a
data processing capability has stimulated a discussion of their economic and perform-
corresponding increment in the demand for ance characteristics. The intent of this tu-
services. As a result many installations have torial is to provide the reader with an un-
reached the point of resource saturation. derstanding of the concepts embodied in
The obvious, yet increasingly unappealing, backend databases and of the problems cur-
recourse to saturation is a mainframe up- rently impeding the progress toward their
grade. A recently devised alternative to emergence as commercially viable entities.
such an upgrade is the offloading of data- The concentration in this tutorial is on
base management functions from an exist- backend database systems realized in soft-
ing mainframe to a directly attached mini- ware on Von Neumann computers. The
computer. This alternative configuration is realization of backend systems using spe-
known as a backend database management cial-purpose database machines is a topic
system (DBMS). that also has attracted considerable atten-
Since the development of the first pro- tion and has been reported in depth re-
totype backend DBMS by Canaday et al. cently [BERR77, HSIA79, LANG79]. Many of
at Bell Laboratories [CANA74], many com- the issues discussed herein apply to both
mercial and research groups have evaluated software and hardware backend systems.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or
distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its
date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To
copy otherwise, or to republish, requires a fee and/or specific permission.
© 1980 ACM 0010-4892/80/0300-0003 $00.75

Computing Surveys, Vol. 12, No. 1, March 1980

4 * F.J. Maryanski
ICONTENTS

Host
(APPLICATIONFUNCTION)
INTRODUCTION
1. BACKEND DBMS ARCHITECTURE
2. BEiNEFITS AND DRAWBACKS
Performance I INTER
Cost PROCESSOR
Reliability LINK
Security
AdditionalResources
Modularity
3. R E S E A R C H E F F O R T S
XDMS
BACKEND
IDMS (DATABASEFUNCTION)
KSU
MADMAN
Analysis of Prototypes
Additional Work
4. E X T E N S I O N S
Multiple-HostBackend D B M S
Multiple-ProcessorBackend D B M S
5. I M P L E M E N T A T I O N P R O B L E M S
Communication
Machine Code Conversion
Portability
Marketing
6. C O N C L U S I O N
ACKNOWLEDGMENTS
REFERENCES FIGURE 1. Backend D B M S .

However, the in-depth presentation and tion are presented, and their impact is an-
analysis will center on software database alyzed. The problems facing the implemen-
systems. tors of backend databases are described in
Similarly, a substantial number of the Section 5.
issues presented in this tutorial are also of
importance in the study of distributed data- 1. BACKEND DBMS ARCHITECTURE
base systems. Discussions of distributed
databases can be found in AscH74, DEPP76, In its most elementary form a backend
HARD78, LOWS77, MARY78a, MILL78, and DBMS consists of a locally connected pair
Roth77b, The reader wishing to acquire of computers, as shown in Figure 1. The
some basic information on database sys- application programs are executed by the
tems is referred to the tutorials in KIM79, host computer, while the backend machine
SHNE76, or SIBL76 or to recent textbooks controls access to the database. The soft-
on the subject [CARD79, DATE77, DEEN77, ware functions necessary to support data-
MART77, Ts]c77]. base application programs are divided be-
Section 1 presents the architecture of tween the host and backend computers ac-
backend database systems, considering cording to the above rule.
both hardware and software organization. In order to establish a foundation for
In the second section the expected benefits understanding the manner in which a back-
and drawbacks of the backend DBMS con- end DBMS functions, let us first consider
cept are described in detail. Section 3 dis- the operational sequence of application
cusses several research excursions into the programs and a database management sys-
area of backend databases. In Section 4 tem in a single-machine environment. Fig-
extensions to the basic backend configura- ure 2 depicts the software organization of

Computing Surveys,Vol. 12,No. I,March 1980

 Backend Database Systems • 5

'APPLICATION PROGRAM K
WORK AREA
0
APPLICATION PROGRAM i E y
WORK AREA R

DBMS BUFFERS
G

SCHEMA SUBSCHEMA SUBSCHEMA

i

1 K

FIGURE 2. Single-machine D B M S .

a single-machine DBMS. The major com- currently available data. If this is the case,
ponents of a single-machine database sys- Step 8 is executed next.
tem are 4. The DBMS requests that the operat-
ing system perform a transfer between the
(1) the database software (DBMS); secondary storage device containing the re-
(2) the application programs; quested data and the system buffers.
(3) the operating system and its buffers; 5. The operating system initiates the
(4) the schema, which is a logical descrip- transfer between secondary storage and pri-
tion of the entire database; mary memory.
(5) the subschemata, which describe the
6. The data are transferred from second-
portion of the database available to the ary storage into the system buffers. This
individual application programs and may require that a portion o f the existing
provide a mechanism for validating the contents of the buffer space be written onto
program's access rights to the data; and secondary storage in order to provide suf-
(6) the work areas, which are shared by the ficient space for the new data without loss
application programs and the DBMS.
of previous information.
The sequence of operations in a single- 7. The operating system notifies the
machine DBMS is described below. A re- DBMS that the transfer is complete.
trieval operation is presented for illustra- 8. The DBMS places the data and status
tive purposes. The same general opera- information in the work area of the appli-
tional sequence applies to the other opera- cation program that issued the request.
tions, such as storage, deletion, and modi-
fication. Completion
9. The application program may access
Origination and Validation the data and status information in the work
1. The application program issues a re- area in the course of its execution.
quest to the DBMS indicating the opera-
tion required and the data to be operated In order to form a backend database sys-
upon. tem, the functional modules of the single-
2. The request is validated against the machine DBMS must be distributed be-
subschema to ensure that the application tween the host and backend machines.
program has the right to issue the request. Communication and interface modules
must be added. Figure 3 illustrates the soft-
Data Access ware organization of a backend DBMS. The
3. The DBMS checks its buffers to de- new components include a communication
termine if the request can be satisfied with system that must exist on both computers,

Computing Surveys, Vol. 12, No. 1, March 1980

6 F . J . Maryanski
APPLICATION PROGRAM K
WORK AREA
APPLICATION PROGRAM 1
WORK AREA OPERATING
! SYSTEM HOST
HOST INTERFACE (HINT)

COMMUNICATION SYSTEM

COMMUNICATION SYSTEM

BACKEND INTERFACE (BINT)

DBMS OPERATING BACK-

SYSTEM END

DATA BASE DATA BASE

TASK TASK
SUB- SUB- 1 K
SCHEMA SCHEMA SCHEMA
1 K
BUFFERS

FIGURE 3. Software organizationof backend DBMS.

host and backend interface routines, and The interprocessor link should be of at
the database tasks that reside on the back- least channel speed if intermachine com-
end computer. The functions of the com- munication is not to become a bottleneck
ponents required for extension into the [CANA74, MARY76b]. Simulation studies
backend environment are discussed in the have indicated that intermachine links with
following paragraphs. speeds of 1 Mbaud or greater will produce
The communication system must provide only minimal communication delays. Con-
the facilities for the transmission of com- figurations with the host and backend pro-
mands, data, and status information be- cessors sharing common memory have been
tween the host and backend machines. The proposed for situations in which quick re-
control of the physical links, proper utili- sponse is necessary.
zation of line protocols, transmission error The interface routines are the processes
detection and correction, processor and that exchange information via the commu-
task synchronization, and management of nication system. The host interface, HINT,
message buffers are among the responsibil- is the process that is called by the applica-
ities of the communication system. Since a tion program when access to the database
backend DBMS is a special case of a com- is desired. HINT must format the database
puter network, the communication facility request according to the requirements of
need not contain all the features of a fuU- the communication system and then trans-
scale network communication system. For mit the request as a message to the backend
example, a routing mechanism is unneces- interface via the communication system.
sary in a two-machine backend DBMS. When the database operation is complete,

Computing Surveys, Vol. 12, No. 1, March 1980

 B a c k e n d Database Systems • 7
the data and status information returned as
the result are transmitted from the backend I USER PROGRAM I
interface to the host interface in the form
of a message. H I N T must then unpack the I HOSTINTERFACE TASK
l OPERATING
SYSTEM
message and return the information to the (HINT) ] HOST
application program in the expected form.
Since H I N T must service all the applica- I COMMON,CAT,ONSY.EM
I
l
tion programs on the host, it must be able
to associate each returning message with a
particular application program.
The backend interface, BINT, behaves
in a manner analogous to that of its host l OMMUNICATIONSYSTEM
counterpart in that it serves as the vehicle
for the interchange of information between OPERATING
BACKEND INTERFACE TASK SYSTEM
the communication system and the data- (RINT)
base tasks. It must unpack and pack mes- BACKEND

sages that are sent to and from the host

l
l
DATA BASE
i
TASK
interface via the communication system.
The responsibility for directing a database I
request to the appropriate database task DBMS
for execution lies with BINT. In systems in
which the number of database tasks is dy-
namic, B I N T must have access to a mech-
anism for the allocation and deallocation
of tasks. - - DB REQUEST
Figure 3 shows a number of database ....... DATA/STATUS
tasks residing in the backend machine.
If a backend is to operate efficiently,
FIGURE 4. I n f o r m a t i o n flow in b a c k e n d D B M S .
the DBMS module must be multipro-
grammed [CANA74, MARY76b]. Therefore
several tasks capable of presenting data- tions. Figure 4 depicts the flow of informa-
base requests to the DBMS must reside on tion in a backend DBMS.
the backend machine. The database re- Origination a n d Validation. The orig-
quests presented to the DBMS by the data- ination and validation occur in the same
base tasks are those that have originated in fashion as in the single-machine case, with
the application program and are transmit- H I N T performing the actions previously
ted through the interface routines and the executed by the DBMS.
communication system to the database
tasks. The database task acts as a surrogate Host-to-Backend Communication. A
on the backend machine for an application message containing the database request is
program on the host. When the database sent from H I N T to B I N T via the commu-
request is complete, the database task re- nication system.
turns the resulting data and status infor- Data Access. B I N T passes the request
mation to the backend interface, which in- to the proper database task, which calls the
itiates the transmission of the result to the
DBMS. T h e database is then accessed in
host machine.
the same manner as on a single-machine
T h e sequence of execution for a database
system. T h e result of the operation is
operation in a single-machine environment passed through the database task to BINT.
was outlined earlier. The operational se-
quence for a database command in a back- Backend-to-Host Communication. A
end DBMS is presented here to illustrate message containing the data and status in-
the basic difference in the two configura- formation produced as a result of the op-

Computing Surveys, Vol. 12, No. 1, March 1980

8 • F.J. Maryanski
eration is transmitted from BINT to H I N T link. In fact, the execution of a single data-
via the communication system. base command requires more time in a
backend D B M S than in a single-machine
Completion. H I N T places the result system because it must pass through more
into the work area, where it may be ac- modules. In order to realize the perform-
cessed by the application program. ance benefits of concurrency, the operation
of both CPUs and the secondary storage
2. BENEFITS AND DRAWBACKS devices must be synchronized so that bot-
Backend database systems have received tlenecks are minimized. This synchroniza-
considerable attention owing to their poten- tion depends on both system structure and
tiai for increasing the performance of in- jobstream characteristics. If a backend
stallations with heavy database require- D B M S is to achieve increased performance,
ments. The research into these systems has the gains due to concurrency must out-
identified several important areas in which weigh the losses caused by communication
the utilization of backend machines may overhead. In situations where database
provide considerable benefits. However access is not a system bottleneck, the in-
there are also certain drawbacks that can troduction of a backend machine may de-
arise if the backend concept is not realized grade rather than improve performance
properly. In this section we evaluate the [MARY78b].
potential effects of a backend D B M S rela-
tive to a number of factors crucial to most Cost
data processing installations. As mentioned in the introductory section,
a primary motivation for the backend
Performance D B M S work is the development of an eco-
nomic alternative to the upgrading of a
A backend D B M S can improve the large mainframe. The attachment of a ded-
throughput of a heavily loaded mainframe icated minicomputer to an existing main-
if the following conditions are met: the frame is an order of magnitude cheaper, in
backend machine is multiprogrammed, a terms of hardware costs, than replacing the
high-speed link is utilized, and a substantial mainframe with a larger machine [HEAC75,
demand for database access exists [CANA74, MARY76a]. But factors other than the costs
HEAC75, MARY76b, MARY78b, ROSE77b]. of the processors must be considered in the
The previous statement is based on proto- evaluation of the economic alternatives.
type and simulation experiments rather The media used for the storage of the data-
than experience with production systems base on the existing mainframe and the
because of the current status of backend backend machine must be compatible in
D B M S development. The throughput in- order to avoid a substantial conversion cost.
crement depends on the overall workload. Backend D B M S communication and inter-
However, an improvement of approxi- face software must also be included in the
mately 25 percent has been projected from pricing equation. When all factors are con-
many experiments [HEAc75, MARY76b, sidered, the great difference in price be-
MARY77, MARY78b]. The reason for the tween that of a mainframe to replace the
performance increment is the concurrent entire existing system and of a minicom-
operation of the host with backend proces- puter to assume the database function is
sors and secondary storage devices. The the factor that makes a backend D B M S
addition of the backend processor permits a viable economic alternative to a main-
application program execution, D B M S ex- frame upgrade [CANA74, HEAC75, LOWE76,
ecution, and secondary storage access to MARY76a, NOLA77].
occur simultaneously.
On the other hand, a performance pen-
Reliability
aity is incurred by the introduction of the
interface and communication software and The basic determination to be made con-
the transmission time of the intercomputer cerning reliabilityis whether a tightly cou-

Computing Surveys, Vol. 12, No. 1,March 1980

 Backend Database Systems • 9
pied pair of machines is more reliable than processor can free a substantial portion of
a single computer. Since there are more the processor's resources. A review of Fig-
components in a backend DBMS composed ures 2 and 3 indicates that the host machine
of two machines than there are in a single- (which previously contained both database
machine system, the incidence of failure, and application modules) no longer must
of either software or hardware, is high- maintain the DBMS software, the schema,
er. However, in a backend DBMS, the ne- and the database page buffers. The primary
cessity for intermachine communication memory released by the transfer of these
causes the machines to check the informa- entities to the backend machine is at least
tion passed between them; the existence of partially occupied by the host interface rou-
a malfunction may be detected more tine and the communication software. If
quickly [HEAC75], thus reducing the length the interface and communication software
of time in which the system operates with do not require all of the released space,
an undetected error. then additional application programs can
reside on the host machine; the result is an
increase in concurrency and throughput
Security [MARY76a, ROSE77b].
The preceding discussions emphasize
A backend DBMS provides a solution to that the size of the interface and commu-
one type of security problem, but it is by nication software is a critical backend
no means a panacea in terms of security. If DBMS performance factor. The host inter-
the backend machine is dedicated com- face routine requires relatively little mem-
pletely to the database management func- ory-approximately 5K in some prototypes
tion with no resident application programs, [CANA74, MARY79]. The memory require-
it is not possible for a malevolent pro- ments of the communication software de-
grammer to access the data files indepen- pend on the generality of the functions
dently of the DBMS [HEAc75, LOWE76, performed. A backend DBMS is a limited,
ROSE77b]. But in many single-machine special-case network and does not require
database systems under various operating a full spectrum of message handling fea-
systems it is possible for an application tures in the communication system. The
program to access directly any file if the development of a minimal communication
proper identification information is known. package as used in the XDMS prototype
Placing all data files on a separate machine [CANA74] is likely to provide the best ser-
forces all access to occur through the vice with the smallest demand on resources.
DBMS and so eliminates this type of se-
curity breach.
In order to gain unauthorized access to
data in a backend DBMS, the intruder Modularity
must appear to the DBMS as a valid user.
Thus a backend DBMS causes the illicit The principle of modular design is generally
user to concentrate penetration efforts on applied in the creation of both hardware
defeating the password mechanism or mon- and software in order to produce well-de-
itoring the behavior of either the host in- fined, reliable, and correct devices and pro-
terface routine or the communication sys- grams. A backend DBMS is an example of
tem. The system designer must realize the modular design at the computer system
possible vulnerable points of a backend level. The basic components are machines
DBMS and make every effort to improve that perform either database or application
security in these areas [CSUR79]. functions. This separation of functions pro-
vides the basis for several such interesting
extensions to the basic backend configura-
Additional Resources tion as multiple-host or backend processors,
distributed databases, and database ma-
Attaching a computer dedicated to data- chines. These extensions are discussed in
base management to a general-purpose Section 4.

Computing Surveys, Vol. 12, No. 1, March 1980

10 F. J. Maryanski

UNIVAC APPLICATION PROGRAM AUGMENTED

1108 SCHEMA
TABLE
XDMS INTERFACE

XDMS AUGMENTED
META-4 BACKEND
SCHEMA

SYSTEM
TABLE

FIGURE 5. X D M S h a r d w a r e configuration.

3. RESEARCH EFFORTS as a takeoff on the concept of a frontend

processor. The backend D B M S imple-
There have been several major research
mented by Canaday's group resided on the
efforts focusing on backend databases. The
hardware configuration depicted in Figure
projects described here include X D M S at
5. The DMS-1100 database management
Bell Laboratories, the IDMS backend pro-
system, which is a CODASYL-based pack-
duced by Cullinane for the U.S. Army, the
age, existed on the UNIVAC 1108. A tai-
backend studies at Kansas State Univer-
lored CODASYL DBMS, operating system,
sity, and the M A D M A N machine by Gen-
and communication package were written
eral Electric. Other related research pro-
for the META-4 machine. A personnel ap-
jects are also mentioned briefly.
plication system was moved from the UNI-
VAC 1108, under DMS-1100, to the back-
XDMS
end D B M S for testing purposes. It is im-
The principal motivating factors in the de- portant to note that the UNIVAC machine
velopment of the first backend D B M S were remained available to other applications
interests in the CODASYL data model during the course of the development and
[CODA78a, CODA78b] and in minicompu- testing of the backend DBMS.
ter applications. The name "backend" was The Bell Laboratories prototype, known
coined by the members of the project team as XDMS, performed successfully using a

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems • 11
personnel database for several months. The quate performance. However this enhance-
primary purpose behind the implementa- ment did not prove necessary.
tion of XDMS was to demonstrate the fea- The XDMS system provided a locking
sibility of the backend concept. From this mechanism to control concurrent updates
viewpoint, XDMS was an unquestionable and a rollback and recovery feature. For an
success. explanation of the problems associated with
The groundbreaking effect of XDMS locking, rollback, and recovery see DHAL77,
must be kept in mind when evaluating it in EDEL74, FOSS74, GIOR76, SAYA74, or
terms of the potential benefits presented in VERH78. No special security facilities were
the previous section. The XDMS system included in the system.
performed to the satisfaction of the devel- The modular system organization and
opers. Although no performance statistics offloading of host resources to the backend
are available, the paper by Canaday et al. are significant achievements of the XDMS
[CANA74] points out the need for better project. The XDMS project is a landmark
performance and suggests that increased in the database management area, since it
communication bandwidth is the mecha- introduced an alternative database archi-
nism to achieve this goal. For the prototype tecture and spawned an enormous amount
the machine was connected using a 2-kbaud of follow-on research.
communications link rather than a channel-
to-channel adapter with a capacity of the IDMS
order of 1 Mbaud. Since the host sends a
single database command to the backend, The U.S. Army Computer Systems Com-
the ratio of communication time to pro- mand was facing the problem of saturation
cessing time can be quite substantial. In at its data processing installations, which
systems transmitting single database com- handle the Army's everyday business data
mands, better performance under heavy processing tasks. Inspired by the success of
workloads is observed for application pro- XDMS, Computer Systems Command
grams composed predominantly of complex sponsored research efforts by the Cullinane
statements than for those with primarily Corporation and Kansas State University;
simple statements. The complexity of a these eventually led to the synthesis of
database statement can be measured in prototype backend database systems by
terms of the amount of backend processing both groups. The Cullinane effort concen-
and number of secondary storage accesses trated on extending IDMS, its IBM 360/
required to complete the statement. The 370 database package, to operate in a back-
reason for the improved performance is end environment [CULL75].
that complex statements keep the backend The prototype system created by the
machine busier, thus providing more con- Cullinane Corporation resembles XDMS in
current operation among host and backend several ways. Both database packages are
processors. For simple database commands, CODASYL-based, and in both cases the
only a small amount of the host process- database functions are supported by a
ing load is transferred to the backend minicomputer coupled to a large main-
computer. frame. In the case of the IDMS prototype,
Cost, offioading of resources, and modu- a PDP-11/70 performed the database func-
larity were all important considerations in tions for an IBM 370/158.
the XDMS design. The META-4 computer Perhaps the most significant difference
was selected on the basis of its expected between the Bell Laboratories and Culli-
cost/performance ratio for the project. A nane efforts is that the vendor-supplied op-
key factor in the selection of META-4 was erating system was retained for the IDMS
its microprogramming capabilities. Ini- backend. CuUinane developed a new ver-
tially, the designers felt that several primi- sion of IDMS, known as IDMS-11, for the
tive database functions would have to be PDP-11 as part of the project. The com-
implemented in microcode to achieve ade- munication software was implemented by

Computing Surveys, Vol. 12, No. 1, March 1980

12 * F. J. M a r y a n s k i

Cullinane based on a design provided by The I D M S backend prototype is signifi-

Kansas State University [WALL76]. How- cant in that it marks the firstentrance by
ever the remainder of the system soft- a database vendor into the area of backend
ware on the PDP-11/70 was supplied by systems. Although the initialversion was
the vendor. carried only to the prototype stage, the
The I D M S prototype operation is based vendor is expected to pursue the backend
on the transmission of a single database concept fu~her.
c o m m a n d to the backend, as in X D M S .
Hence it is susceptible to the possibilityof KSU
communication overhead outweighing the The second backend database research pro-
performance benefits of concurrent opera- gram supported by the U.S. A r m y Com-
tion. As with X D M S , a low-speed commu- puter Systems C o m m a n d was conducted by
nication line (4800 baud) was utilizedin the Kansas State University. The initialphase
initial prototype. Extensive tests of the of thiswork centered upon an evaluation of
I D M S backend were performed by the U.S. the feasibilityof a backend D B M S in a
Navy. W h e n the system isrun with a single typical data processing environment
application program, the response time is [MARY76a]. The economic and perform-
predictably slow. However, tests of a mul- ance benefits and penalties of a backend
tiprogramming environment have indicated D B M S were weighed during this study.
that three application programs can com- The backend concept was judged attractive
plete execution in the same time as one to the point that the support of the CuUi-
application program in a uniprogrannning nane project was initiatedby the Army.
environment. These results demonstrate Much of the research effort at Kansas
that when a backend D B M S executes a State has concentrated on the development
single program, communication and task of network communication software
switch overhead have a severe impact on [WALL76] as a key component of two pro-
performance. But in a multiprogramming totype backend database systems [FARR79,
environment, concurrent operation of the Hous78, MARY79]. The hardware topolo-
host and backend processors and the disk gies used for backend databases are de-
tend to mitigate the overhead. Therefore picted in Figure 6. The KSU prototypes
more work can be accomplished in a given were developed purely for research pur-
time period. Naturally,the workload can be poses. As a result all machines supported
increased beyond the capacity of the sys- other computing activities to various de-
tem, thus resulting in performance degra- grees. Neither the database packages nor
dation. The determination of the peak the operating systems were altered during
workload is an important step in the tuning the prototype development. In addition,
of a backend D B M S configuration. only a low-speed, telephone-line link was
The work on the I D M S prototype was possible among the machines, which se-
very strongly motivated by cost and re- verely limited system performance.
source configurations.The sponsors of the The first prototype system [Hous78,
project viewed the backend D B M S as an MARY79] involved the TOTAL database
economic means of increasing the capacity package executing with an Interdata 8/32
of their overtaxed systems. The primary host and either the ITEL AS5 or Interdata
and secondary storage on the host com- 7/32 as the backend. The software struc-
puter freed by the introduction of the back- ture corresponds to that presented in the
end D B M S can be allocated to existing first section of this paper. In this prototype
applications. the key software components were imple-
Security was also one of the motivating mented in a variety of languages. TOTAL
factors for the support of the IDMS back- is written in assembly language on both the
end project. Future plans call for the devel- Interdata and ITEL computers; the inter-
opment of a highly secure backend DBMS. face routines and the application programs

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems ° 13

are in Cobol; the communication system is

implemented in Concurrent Pascal on the
Interdata machines and in assembly lan- ITEL
guage on the ITEL. This potpourri of im- AS5
plementation languages resulted from a
design constraint to develop interface
software that linked together existing ap-
plication, communication, and database
modules.
A key difference in this prototype back-
end DBMS was the use of a large main-
frame as a backend to a minicomputer host.
There was a marked performance differ- INTE RDATA INTERDATA
ence between the system with the ITEL 8/32 7/32
backend and that with the Interdata 7/32
backend. Overall, the ITEL backend sys-
tem showed a 41 percent improvement in
terms of response time when compared
with the minicomputer backend.
One of the difficulties of the first KSU
prototype was that the interpretive nature
of Concurrent Pascal executing under the
SOLO operating system [BRIN77] required
additional routines to permit calls to and
from the Cobol interface modules. In order
to reduce the complexity entailed in these
translation routines, a second prototype
I
FIGURE 6. H a r d w a r e topology of K S U b a c k e n d sys-
tems.

that used Concurrent or Sequential Pascal is simplified. Portable backend software

for all modules was developed [FARR79]. permits a data processing installation to
This design decision limited the prototype select the most cost-effective hardware con-
to the Interdata machines. The second figuration for a backend DBMS.
KSU prototype differs from other efforts in
that its driving factors were modularity and
MADMAN
portability rather than cost or performance.
Although cost measures are very difficult The MADMAN system is a CODASYL
to apply in a university environment, it is D B M S developed by General Electric for
possible to compare roughly the perform- execution on PDP-11 hardware under
ance of the two prototypes. The comparison R S X - l l M , RSX-11D, or IAS operating sys-
cannot be precise since the Pascal design tems [HoTc78]. Because of the memory
restriction forced the substitution of a min- limitations of the PDP-11 architecture, in-
imal locally written DBMS for TOTAL in sufficient resources are available for both
the second prototype. In approximately the application programs and the database
same environments, the second prototype management system. (Note that this limi-
responds from 1.5 to 3 times faster than the tation does not apply to the PDP-11/70.) In
first system. order to alleviate this demand for minicom-
The development of portable backend puter memory, a backend machine has been
database software facilitates the extension tightly coupled to the minicomputer as de-
of the backend concept to the multiple- picted in Figure 7 [HuTc78]. An LSI-11 is
processor configurations discussed in the used as the backend machine.
next section. Also, the linking together of By utilizing compatible processors, a
heterogeneous host and backend computers shared memory connection, as illustrated

Computing Surveys, Vol. 12, No. 1, March 1980

14 F. J. Maryanski

MAIN I~
MEMORY I
TM
HOST

I
BACKEND
CONTROL

~1 SHARED
MEMORY

FIGURE 7. M A D M A N backend D B M S .

in Figure 8 [HuTc78], can be realized. This memory and CPU cycles were deemed to
arrangement permits high-speed interpro- be the critical resources in the MADMAN
cessor communication with minimal over- environment, only the CPU portion of the
head. In the configuration shown in Figure database activity is off-loaded to the back-
8, the disks remain connected to the host, end. Disk operations are still performed by
unlike the previously described backend the host. The M A D M A N designers felt that
database systems. In the M A D M A N back- primary memory and CPU cycles were the
end system, the host initiates the disk I/O key resources in this situation. In this sense,
operations, but the information is trans- the M A D M A N architecture diverges radi-
ferred to common memory, which is the cally from the organization of the other
PDP-11/70 main memory. The U N I B U S backend systems.
windows provide the backend with the abil- M A D M A N is built from smaller proces-
ity for simultaneous access to buffers con- sors than the other backend systems. It is
taining database requests and information the only system with a microprocessor
transferred to or from secondary storage. backend machine.
As with the backend processors in the Cost was the motivating factor in the
aforementioned systems, the LSI-11 is mul- selection of the LSI-11 as the backend ma-
tiprogrammed to permit overlap of I/O and chine for MADMAN. Another aim of the
CPU operations. system was portability among several exist-
MADMAN differs in several significant ing PDP-11 minicomputers. The intention
ways from the other backend systems. The is to be able to tie an LSI-11 to any of the
most important distinction is the direct minicomputers to form a backend D B M S
connection of the host and backend via system. In addition to cost and portability,
shared memory and bus linkages. This ar- a goal of the M A D M A N system is increased
chitecture provides faster physical com- performance. Although it appears that the
munication links than in the other backend design has accomplished the first two goals,
systems and also greatly simplifies the soft- extensive testing is still required to deter-
ware required to transmit information be- mine if the M A D M A N design is suitable
tween machines. Device-dependent driver- for the factory control environment.
type software is required for communica- The presence of a PDP-11 host, smaller
tion in MADMAN, while the other backend than a PDP-11/70, requires minor modifi-
systems are built with more sophisticated cations to the architecture of the
communication packages. Because primary MADMAN backend DBMS. These

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems • 15

UNIBUS
~L AL
II
÷ ~r
UNIBUS
PDP-i1/70 MAP

CACHE ~t
4-! CONTROL
UNIBUS UNIBUS
II WINDOW WINDOW
i DATA
BASE
MEMORY
~L

K MASS BUS ~F

Q-BUS

1 '''-'' l
FIGURE 8.
I I
M A D M A N shared-memory connection.

changes, along with a detailed account of The XDMS, IDMS, and KSU prototypes
the design of the system, are presented in all are limited by the speed of the machine
a paper by Hutchison and Roman interconnection. The use of a high-speed
[HuTc78]. line between the host and backend certainly
would increase the throughput of these sys-
Analysis of Prototypes tems. However the amount of the increase
is still unknown. The shared memory con-
In the second section of this paper, six nections of the MADMAN system have the
potential benefits of backend databases potential to minimize the communication
were identified. Since we have presented overhead. But thus far testing has not yet
four prototype systems, we can now deter- confirmed the viability of the MADMAN
mine how close these prototypes have come architecture.
to providing these benefits.

Performance Cost
Although improved performance is a neces- The studies supported by the U.S. Army
sity if backend database systems are to [CULL75, MARY76a] strongly endorsed a
become commercially viable, none of the backend system as an economic alternative
prototypes has exhibited this capability. to the upgrading of an overloaded main-

Computing Surveys, Vol. 12, No. 1, March 1980

16 * F. J. M a r y a n s k i

frame. The MADMAN system is intended Modularity

for use as an economical factory control The designers Of all four prototype systems
system. The common denominator of the view the backend database as an architec-
enterprises that decided that a backend ture that can easily be expanded to provide
D B M S is attractive from a cost standpoint efficiency and portability in database man-
is that a large number of installations were agement. Some work was carried out at
involved. In situations such as these, the Bell Laboratories to include an IBM-370
price differential between a minicomputer host in the X D M S configuration. The PDP-
and a mainframe or between a microcom- 11/70 serving as the backend machine in
puter and a minicomputer can be multiplied the IDMS prototype is designed to inter-
by the number of installations. The savings face with any of several mainframe hosts,
in hardware thus outweigh the cost of de- including IBM-360/370 and CDC-6400 ma-
veloping the backend system architecture. chines. The second K S U prototype was
built using portable communication and
Reliability interface software. The software developed
in that project can be moved to any ma-
None of the backend DBMSs have suffi- chine supporting Concurrent Pascal. The
cient operating history to demonstrate that M A D M A N LSI-11 backend machine is de-
they are more or less reliable than a single- signed to interface to a.variety of PDP-11
machine DBMS. X D M S is the only system hosts.
that contained rollback and recovery soft- The modular structure of the backend
ware tailored for a backend system. A seri- architecture has resulted in a fair degree of
ous evaluation of the reliability of backend success with respect to portability. In some
databases must be deferred until opera- large enterprises with heterogeneous hard-
tional systems can be studied. ware, the portability embodied in the back-
end concept may be sufficient justification
Securi~ for the use of a backend DBMS.
The concept of a secure backend is consid-
ered viable by researchers in the security Additional Work
area [HART78, HSIA78]. However none of
the reported work on 'the prototype back- In addition to the work mentioned in the
end systems substantiates this claim, d e - preceding paragraphs, the properties of
spite the fact that one of the motivating backend databases have been studied by
factors behind the support of the IDMS several other groups. Lowenthal [LowE76]
prototype was the secure backend concept. analyzes thoroughly many aspects of back-
There has been some investigation of the end databases and presents both technical
applicability of backend database systems and economic arguments for the backend
to security environments, but the results of concept. Lowenthal and his colleague Ro-
this work are not yet available. senthal [RosE77a, RosE77b] both analyzed
the resource requirements for a backend
machine and arrived at the conclusion that
Additional Resources
effective backend processing requires a very
Freeing primary memory on the host ma- powerful minicomputer with the following
chine was an important goal of the four features: an address space of the order of 1
backend prototypes. This is one potential Mbyte, a large range of microprogramming
benefit that has been realized in all proto- features, high-performance I/O capabili-
types. Owing to the limited testing on the ties, and special byte and pointer manipu-
prototypes, the impact of the additional lation instructions. These specifications ex-
memory on overall system performance ceed the power of the minicomputers used
cannot be evaluated. in the previously described prototype sys-

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems • 17
terns. As of this time, a full-scale commer-
cial implementation has not provided a re-
alistic measure of the computational power
required by the backend machine.
The Datacomputer developed by the HOST
Computer Corporation of America
[MAre75] can be classified as a backend
machine available to other nodes in the
Arpanet. The Datacomputer is a PDP-10
with a large amount of off-fine storage, pro-
jected to be able to support databases of
the order of one trillion bits. All communi- COMMUNICATIONS
cation with the Datacomputer is done in a CONTROLLER
special language, Datalanguage, which pro-
vides both definitional and manipulative
capabilities.
Although there is some conceptual simi-
larity between the Datacomputer and the
backend machines described previously,
the proposed applications differ radically.
Instead of serving as a database processor COMMUNICATIONS
locally connected to a host machine, the CONTROLLER
Datacomputer is designed to serve as the
basic component in a geographically dis-
tributed database network known as
SDD-1 [ROTH77a]. We consider only lo-
cally connected backend computers in this
presentation.
The concept of performing the database BACKEND
functions using special-purpose hardware
has been put forth by several groups of
researchers [BERR77, HSIA79]. These ma-
chines have been proposed to operate either
as backend machines or as intelligent de-
vice controllers which expedite the per- FIGURE 9. Specialized communications processors.
formance of the database functions. Data-
base machines can achieve high perform-
ance at low cost by simultaneously access- form many database operations at very
ing all of the memory in the execution of a high speeds [OZKA77] at greatly reduced
single database instruction. This parallel costs [HSIA78]. It is a distinct possibility
access is accomplished through the use of that the economy and speed gained from
associative memories or specialized disk the use of specialized hardware will result
control devices. In a configuration utilizing in configurations such as that depicted in
a database machine as a backend, the data- Figure 9, and may well be very common in
base operations reside in the database ma- the next decade. In Figure 9 further func-
chine, which executes these operations as tional specialization is obtained by dedicat-
its primitive instructions. The interface and ing a processor to the communications
communication functions remain in the function. This configuration has been uti-
backend processor. lized in the design of the MININET
Compared with conventional systems, [PEEB75, PEEB78] and MIMICS database
database machines have the ability to per- networks [WALL76].

Computing Surveys, Vol. 12, No. 1, March 1980

18 • F. J. Maryanski
4. EXTENSIONS backend interface routine must maintain a
correspondence between the database re-
The basic two-processor backend DBMS,
quests that it receives and the identity of
implemented entirely in software, has
the backend interface routine which trans-
proved to be the basis for a substantial
mitted the request. This correspondence
number of configurations which can be ex-
can be maintained if a host identifier is
pected to have a major impact on the field
associated with each database request.
of database management. The extensions
A multiple-host backend D B M S presents
presented here involve incorporating addi-
a very efficient method of utilizing system
tional processors into the configuration, as
resources, since a single copy of the data-
in the cases of the multiple-host or multi-
base software can serve apphcation pro-
pie-processor backend DBMS. In addition,
grams on multiple machines. Thus the
efforts on distributed database systems
amount of additional main memory avail-
[AscH74, DEPP76, HARD78, LOWE77,
able for applications and the degree of con-
MARY78a, MILL78, ROTH77b] and database
currency in the system increase linearly
machines [BERR77, HSIA79, LANG79] are
with the number of hosts in the multiple-
related to the research in backend database
host configuration. The performance is
systems but will not be treated further in
bounded by the capacity of the backend
this paper.
machine, and so the number of hosts that
can be serviced efficiently is a function of
Multiple-Host Backend DBMS the database demand and the power of the
The most elementary extension to the basic backend machine. The multiple-host back-
backend D B M S configuration results from end D B M S appears to be most attractive
attaching several host processors to a back- when several hosts with light to moderate
end machine, as in Figure 10. In this config- database requirements can be connected to
uration, known as the multiple-host back- a single backend. This configuration will
end D B M S [CANA74, MARY76C, MARY78C], free a substantial amount of main memory
all database requests from all host proces- and still provide reasonable throughput.
sors are performed at the backend machine. The multiple-host arrangement exploits
This extension is easily realizable if the the security benefits of the backend D B M S
communication system permits the back- by concentrating the database activity of
end processor to exchange information with several machines at one central point. As
multiple machines. The only addition to discussed previously, the efforts to defeat
the basic operational sequence is that the and protect the security of the data are
limited to a relatively small number of al-
ternatives in a backend database system.
FIGURE 10. Multiple-host backend DBMS.
Multiple-Processor Backend DBMS
HOKST Figure 11 portrays the database function
shared among multiple backend processors.
In this configuration the backend machines
are joined by high-speed links in order to

I I....... I I process the database requests of the host at

a high rate. The primary motivation for this
BACKEND topology is the improved throughput due
to the increased concurrency in execution
of the database function [LOWE76,
MARY77].
The multiple-processor backend D B M S
is very well suited for the use of micropro-
cessors as the component backend ma-

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems • 19
data, distribution by function, and pipelin-
ing--are explained here. Figure 12 depicts
HOST multiple backend processors distributed by
data. Each processor can execute the full
range of database functions on a subset of
the database. A controlling processor is re-
quired to issue the commands to the data-
base processors and to assemble the indi-
vidual responses into the result of the data-
base request for transmission to the host.
The backend node in this configuration is
BACKEND actually single-threaded, since all database
processors operate upon the same request
in parallel. The expectation is that the con-
current execution of the individual com-
mands will result in an overall increase in
throughput. A study of a similar configu-

)
ration by Ozkarahan, Schuster, and Sevcik
[OZKA77] indicates that the response time
improvement is strongly dependent on the
type of database request. Operations such
as a simple retrieval or updates are very
FIGURE Ii. Multiple-processor backend D B M S . well suited for simultaneous execution by
multiple processors. However, an operation
such as relational cross-retrieval, which in-
chines. A high degree of concurrency can volves processing records (or tuples) se-
be achieved at a low cost, thus producing a quentially, is not performed more quickly
cost/performance ratio that makes this than in a single-processor configuration.
backend configuration economically at- A multiple-processor backend D B M S
tractive. distributed by function is pictured in Figure
A multiple-processor backend D B M S 13. In this configuration a number of spe-
can be realized in a number of configura- cial-purpose microprocessors are governed
tions. Three approaches--distribution by by the controlling processor. Each func-
tional processor performs a limited number
of database functions over the entire data-
FIGURE 12. Multiple-processor backend distributed by
base. As indicated in the figure, common
data.
functions such as retrievals may be embod-
ied in several processors. The controlling
processor performs the backend interface
CONTROLLER
function of parceling out the database re-
quests to the appropriate functional pro-
cessors and then transmitting the results to
the host. A functionally distributed multi-
ple-processor backend permits concurrent
execution of several database requests, thus
providing the potential for a high degree of
throughput. However, the problems asso-

() ) ciated with the updating of common data

by multiple processors arise. Therefore
some mechanism for concurrency control
must be included in the system. The alter-
natives are either to provide for communi-

Computing Surveys, Vol. 12,No. 1,March 1980

20 • F. J. Maryanski

TO
HOST

CONTROLLING
PROCESSOR

RETRIEVE RETRIEVE ~...~

( DATABASE
0
FmURE 13. Multiple-processor backend distributed by function.

cation among the functional processors is monitored by a dedicated processor in a

which may access shared data, as in Figure manner similar to that of the functionally
13, or to include a processor dedicated to distributed backend machine.
the concurrency control function, as shown All three multiple-processor backend
in Figure 14. In the configuration of Figure DBMS configurations rely on a large num-
14 each secondary storage access of shared ber of concurrently executing microproces-
data must be verified by the concurrency sors and high-speed interconnections to in-
control processor. crease throughput at a reasonable cost. Ad-
The third approach to the synthesis of a vances in technology are making such con-
multiple-processor backend DBMS em- figurations feasible, as evidenced by the
ploys the technique of pipelining. The exe- developmental efforts of several manufac-
cution of a database request by a backend turers in this area [HsIA79].
machine involves several discrete steps. As
illustrated by Figure 15, one or more pro- 5. IMPLEMENTATION PROBLEMS
cessors can be dedicated to the execution
of each of these steps. In a pipelined back- Although the concept of the backend data-
end machine several database requests can base system has been well known for sev-
be in the various stages of processing si- eral years and though in many cases the
multaneously. Bottlenecks can be alle- economic and performance benefits out-
viated by the inclusion of additional pro- weigh the drawbacks, still no commercially
cessors at each stage. Access to shared data available backend database systems, ac-

Computing Surveys, Vol. 12, No. L March 1980

 Backend Database Systems 21

TO
HOST

CONTROLLING
PROCESSOR

RETRIEVE I I RETRIEVE I I STORE I I UPDATE

CONCURRENCY
CONTROLLER

I DATA BASE 0

FIGURE 14. Multiple-processor

backend distributedby functionwithconcurrencycontroller.

cording to the definitions presented in this be sufficiently general to permit the trans-
paper, are known to the author. Some in- mission of database commands, data, and
staUations are investigating home-grown status information without error between
backend implementations, but the concept the host and backend and also able to ac-
will not have a significant impact until a complish such transmissions with minimal
backend DBMS is marketed and supported overhead.
by a major vendor. A number of implemen- In order for the impact of the communi-
tation difficulties have hampered the com- cation delay between the host and backend
mercial development of backend databases. to be minimized, the interprocessor link
The more important of the implementation must be at least channel speed [MARY76b,
issues are discussed in this section. RosE77a]. None of the previously discussed
prototypes benefited from the luxury of
such a high-speed connection. In these sit-
Communication
uations the experimental nature of the pro-
A backend DBMS can be viewed as a two- totype backend DBMS precluded any
node local network. The means of commu- hardware modifications. Thus, although
nication between the two processors must performance benefits have been predicted

ComputingSurveys,Vol.12,No.1,March1980
22 F. J. Maryanski

I TO volved backend minicomputers connected

HOST to mainframe hosts, the code conversion
problem has already surfaced. The mapping
of character and integer data between the
' COMMUNC
I ATO
I NI different implementations can be accom-
plished in a straightforward manner, but at
the cost of some additional processing for
each database request.
Other code conversion problems are
more difficult to resolve. Some of the major
ones follow.
(1) Special care is required to ensure that
communication control characters remain
in their correct binary form during message
transmission.
BACKEND (2) The variations in the positions of spe-
NODE cial characters and letters with regard to
digits within the numerous collating se-
, EXECUTE quences can result in records being main-
tained in different order and the resequenc-
ing of report entries when a backend D B M S
replaces a single-machine system.
CONCURRENCY (3) Floating point numbers, although
CONTROL fortunately rare in database applications,
cannot be converted exactly between ma-
chines with different word sizes.
In the first Kansas State prototypes, all
code conversion is performed by the com-
I IlO munication software on the IBM machine
[MARY79], since less processing overhead is
incurred by the more powerful mainframes
than if conversion took place on the mini-
computers. New architectures are being de-
DATA BASE 0 signed with firmware or hardwired instruc-
tions for translation between EBCDIC and
ASCII. Such features would minimize the
conversion overhead in a backend DBMS.
FIGURE 15. Pipelined multiple-processor backend. Perhaps the ideal approach to the code
conversion problem is to eliminate it en-
for backend configurations with high-speed tirely by use of plug-compatible host and
finks by various modelers [MARY76b, backend processors. The increase in per-
RosE77a, MARY77, MARY78b], no support- formance can then be attained by the re-
ing experimental data exist at this time. moval of the conversion overhead. This
approach argues strongly for the use of
Machine Code Conversion compatibleprocessors in a backend DBMS.
The problems of differing internal machine
Portability
representations between the host and back-
end computers is not of great theoretical The incompatibility of hardware and soft-
difficulty but nonetheless has an impact on ware supplied by different vendors gives
the performance of backend database sys- rise to the problem of software portability
tems. Since initial backend prototypes in- in a backend DBMS. Ideally the commu-

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems • 23
nication, database, and interface modules overtaxed mainframes, through a descrip-
of a backend DBMS all should be easily tion of several research efforts in this area,
transportable to different architectures. In to an analysis of the implementation prob-
order to realize this goal, the modules must lems hindering the developers of commer-
be implemented in common high-level lan- cial systems. Although this paper indicates
guages. Many large enterprises find it nec- an absence of vendor-supplied backend
essary to construct backend database sys- database systems, many users have em-
tems using various processors as backend barked upon projects to produce home-
machines in different configurations. Con- grown systems. Unfortunately, the nature
sequently, a need for portable software ex- of these projects precludes their description
ists to provide compatibility and reduce in the general literature.
development costs. It is hoped that the Since its initial presentation in 1974, the
utilization of optimizing compilers for high- concept of the backend DBMS has un-
level system development languages will leashed a flurry of research and develop-
eliminate most of the execution time inef- ment activity. The architecture of backend
ficiencies. databases is now well defined, as are the
performance problems that must be over-
Marketing come if the backend DBMS concept is to
In addition to the technical issues discussed become a commercial reality. Future devel-
previously, marketing problems have ham- opments on backend databases and the re-
pered the entrance of backend database lated subjects of database machines and
systems into the commercial sector. While distributed databases promise to be among
the technical dilemmas certainly appear the most significant in computer science in
surmountable, the issues of the market- the next few years.
place are much more subtle. Naturally, the The views expressed in this paper are those of the
fact that the backend DBMS is a new con- author and do not necessarily express the views of
Digital Equipment Corporation.
cept does cause hesitation among potential
customers. However this problem has been ACKNOWLEDGMENTS
faced many times in the past. A backend
DBMS is a combined hardware-software The author wishes to thank Rudd Canaday of Bell
product--a database management package Laboratories, Bob Goldmanand Tom Meurer of Cul-
on a minicomputer that can be attached to linane Corporation, Clarence Godfrey of the U.S.
Navy, and John Hutchison of General Electric, who
a customer's mainframe. Very few vendors provided informationbeyondwhat is available in the
have the expertise to develop and support literature on the prototype backend systems. The
both the hardware and software of a back- editorial comments of Gerard Salton and Adele Gold-
end DBMS. The problems of communi- berg and the suggestions made by the referees are
cation, code conversion, and portability deeply appreciated.
compound the dilemma for prospective
vendors. REFERENCES
In spite of the marketing obstacles, the AscH74 ASCHIM, F. "Data base networks--an
need for backend database systems in the overview,"Manage. Inf. 3, 1 (Feb. 1974)
user community will cause some vendors to 12-28.
BERR77 BERRA,P.B. Database machines,ACM
develop marketable systems. The efforts by SIGIR Newsletter, Winter 1977,pp. 4-23.
Cullinane and MRI described earler are BRIN77 BRINCHHANSEN,P. The architecture of
indicative of the vendor recognition of the concurrent programs, Prentice-Hall,En-
commercial potential of the backend glewood Cliffs,N.J., 1977.
CANA74 CANADAY,R. E., HARRISON, R. D., IVIE,
DBMS. E. L., RYDER,J. L, ANDWEHR,L.A. "A
back-end computer for data base manage-
6. CONCLUSION ment," Commun. A C M 17, 10 (Oct 1974)
575--582.
This tutorial has focused on backend data- CARD79 CARDENAS,A. E. Data base manage-
base systems, beginning with the birth of ment systems, Allyn & Bacon, Boston,
the concept as a response to the need of 1979.

Computing Surveys, Vol. 12, No. 1, March 1980

24 • F. J. Maryanski
CODA78a CODASYL COBOL, J. Devel., 1978 HSIA78 HSIAO, D.K., "Relevant aspects of the
(available from Material Data Manage- database computer work to mihiary se-
ment Branch, Dept. of Supply and Ser- curity and applications," in U.S. Army
vices, Hull, Que., Canada). AIRMICS Workshop on DBMS, July
CODA78b C O D A S Y L Data Description Language 1978, pp. 102-113.
Committee, J. Devel., 1978 (available HSIA79 HSIAO, D. K., ED. "Special issue on
from Material Data Management Branch, database machines," Computer (IEEE),
Dept. of Supply and Services,Hull, Que., March 1979.
Canada). HUTC78 HUTCHISON, J. S., AND ROMAN,
CSUR79 COMPUTINGSURVEYS,"Special section on W.G. "MADMAN machine," in Work-
data encryption" (P. J. Denning, Special shop on Computer Architecture for Non-
Editor) 11, 4 (Dec. 1979). Numeric Processing, Aug. 1978, pp. 85-
CULL75 CULLINANE, J., GOLDMAN, R., MEURER, 90.
T., AND NAVARAWA, R. Commercial KIM79 KIM, W. "Relational database systems,"
data management processor study, Cul- Comput. Surv. 11, 3 (Sept. 1979) 185--211.
linane Corp., Wellesley, Mass., Dec. 1975. LANG79 LANGDON,G. G., JR., ED. "Special issue
DATE77 DATE, C. J. An introduction to data- on database machines," IEEE Trans.
base systems, 2nd ed., Addison-Wesley, Comput. C-28, 6 (June 1979).
Reading, Mass., 1977. LOWE76 LOWENTHAL, E . I . "The backend com-
DEEN77 DEEN, S.M. Fundamentals @database puter," in Current directions in DPM de-
systems, Hayden, Rochelle Park, N.J., velopment, Auerbach, Pennsauken, N.J.,
1977. 1976.
DEPP76 DEPPE, M. E., AND FRY, J. P. "Dis- LOWE77 LOWENTHAL, E . I . "A survey--the ap-
tributed data bases: A summary of re- plication of data base management com-
search," Comput. Networks 1, 2 (1976). puters in distributed systems," in Conf.
DHAL77 DHALIVAL, D. S., AND KONSYNSKI, B. Very Large Data Bases, Oct. 1977, pp.
R. "Data integrity considerations in 85-92.
computer based accounting systems," in MARI75 MARILL, T., AND STERN, D. "The data-
Proc. ACM Ann. Conf., Oct. 1977, pp. 6- computer--a network data utility," in
10. Proc. AFIPS 1975 Nat. Computer Conf.,
EDEL74 EDELBERG, M. "Data base contamina- vol. 44, AFIPS Press, Arlington, Va., pp.
tion and recovery," in Proc. ACM SIG- 389-395.
MOD Conf., May 1974, pp. 419.-430. MART77 MARTIN, J. Computer data-base orga-
FARR79 FARRELL, M.W. "Concurrent program- nization, 2nd ed., Prentice-Hall, Engle-
ming of a user envelope in a distributed wood Cliffs, N.J., 1977.
data base management system," M.S. the- MARY76a MARYANSKI, F. J., FISHER, P. S., AND
sis, Computer Science Dept., Kansas WALLENTINE,V.E. "An evaluation of a
State Univ., Manhattan, Kans., March conversion to a backend database man-
1979. agement system," in Proc. ACM Ann.
Foss74 FossuM, B.M. "Data base integrity as Conf., Oct. 1976, pp. 293-297.
provided for by a particular data base MARY76b MARYANSKI, F. J., AND WALLENTINE,
management system," in Data Base Man- V.E. "A simulation model of a backend
agement Systems, Kimble, J. W., and data base management system," in Pitts-
Koffeman, K. L. (Eds.), North-Holland, burgh Modeling and Simulation Conf.,
Amsterdam, April 1974, pp. 221-288. April 1976, pp. 243-248.
GIOR76 GIORDANO, N. J., AND SCHWARTZ, M. S. MARY76C MARYANSKI, F. J., WALLENTINE, V. E.,
"Data base recovery at CMIC," in Proc. FISHER, P. S., CALHOUN,M. A., AND SER-
ACM SIGMOD Conf., June 1976, pp. 33- r~OWITZ,L. "A mira'computer based dis-
42. tributed data base system," in NBS IEEE
HARD78 HARDGRAVE, W . T . "Distributed data- Trend and Applications Symp. Micro
base technology: An assessment," Inf. and Mini Systems, May 1976, pp. 113-
Manage. 1, 4 (Aug. 1978) 157-167. 117.
HART78 HARTSON, H.R. "Secure database man- MARY77 MARYANSKI, F. J. "Performance of
agement study," U.S. Army AIRMICS, multi-processor backend data base sys-
Atlanta, Ga., Dec. 1978. tems," in Conf. Information Science and
HEAC75 HEACOX, H. C., COSLOY. E. S., AND Systems, Aug. 1977, pp. 437-441.
COHEN, J . B . "An experiment in dedi- MARY78a MARYANSKI, V . J . "A survey of devel-
cated data management," in Conf. Very opments in distributed data base manage-
Large Data Bases, Sept. 1975, pp. 511- ment systems," Computer (IEEE) 11, 2
513. (Feb. 1978) 28-38.
Hous78 HousH, R.D. "An implementation of a MARY78b MARYANSKI, F. J., AND KREIMER,
distributed data base management sys- D . E . "The effects of distributed pro-
tem," M.S. thesis, Computer Science cessing in a data processing environ-
Dept., Kansas State Univ., Manhattan, ment," in Annual Simulation Syrup.,
Kans., 1978. March 1978, pp. 183-197.

Computing Surveys, Vol. 12, No. 1, March 1980

 Backend Database Systems . 25

MARY78C MARYANSKI, F. J., WALLENTINE, V. E., shop on Computer Architecture for Non-
FISHER, P. S., AND CALHOUN, Numeric Processing, May 1977, pp. 35-
M . A . "Distributed data base manage- 39.
ment using minicomputers," in Minis ver- ROTH77a ROTHNIE, J. B., AND GOODMAN,N. "An
sus Mainframes, Infotech State-of-the- overview of the preliminary design of
Art Rep., 1978, pp. 141-157. SDD-I: A system for distributed data-
MARY79 MARYANSKI,F. J., FISHER, P. S., HOUSH, bases," in Berkeley Workshop on Distrib-
R. D., AND SCHMIDT,D.A. "A prototype uted Data Management and Computer
distributed DBMS," in Hawaii Int. Conf. Networks, May 1977, pp. 38-57.
System Sciences, Jan. 1979, vol. 2, pp. ROTH77b ROTHNIE, J. B., AND GOODMAN, N. "A
205-214. survey of research and development in
MILL78 MILLER, M.W. "A survey of distributed distributed database management," in
data base management," Inf. Manage. 1, Conf. Very Large Data Bases, Oct. 1977,
6 (Dec. 1978) 243-264. pp. 48-62.
NOLA77 NOLAN, R. L. "Restructuring the data SAYA74 SAYANI,H . H . "Restart and recovery in
processing organization for data resource a transaction-oriented information pro-
management," Inf. Process. 77 (Aug. cessing system," in Proc. ACM SIGMOD
1977) 261-265. Conf., May 1974, pp. 351-366.
OZKA77 OZKARAHAN,E. A., SCHUSTER,S. A., AND SHNE76 SHNEIDERMAN, B., ED. Database man-
SEVCIK, K.C. "Performance evaluation agement systems, AFIPS Press, Arling-
of a relational associative processor," ton i Va., 1976.
ACM Trans. Database Syst. 2, 2 (June SIBLEY, E. H., ED. "Special issue on
SIBL76
1977) 175-195.
data base management systems," Comput.
PEEB75 PEEBLES, R., AND MANNING, E. "A Surv. 8, 1 (March 1976).
computer architecture for large (distrib-
uted) data bases," in Conf. Very Large Tsic77 TSICHRITZIS, V. C., AND LOCHOVSKY,
Data Bases, Sept. 1975, pp. 405-427. F. H. Data base management systems,
PEEB78 PEEBLES, R., AND MANNINGE. "System Academic Press, New York, 1977.
architecture for distributed data manage- VERH78 VERHOFSTAD, J. S . M . "Recovery tech-
ment," Computer (IEEE) 11, 1 (Jan. niques for database systems," Comput.
1978), 40-47. Surv. 10, 2 (June 1978) 167-196.
ROSE77a ROSENTHAL, R. S. "An evaluation of WALL76 WALLENTINE, V. E., HANKLEY, W. J.,
data base management machines," in An- FISHER, P. S., CALHOUN, M. A., AND
nual Computer Related Information Sys- MARYANSKI, F. J. "An overview of
tem Symp., U.S. Air Force Academy, 1977. MIMICS design," TRCS77-04, Computer
RosE77b ROSENTHAL, R. S. "The data manage- Science Dept., Kansas State Univ., Man-
ment machine, a classification," in Work- hattan, Kans., Dec. 1976.

RECEIVED FEBRUARY 1979; FINAL REVISION ACCEPTED DECEMBER 1979

Computing Surveys, Vol. 12.,No.1,March 1980