18

DESIGN AND
IMPLEMENTATION OF A
LIBRARY AUTOMATION
SYSTEM
jYH-SHENG KE, CHING-LIANG LIN, CHIOU-
FENG WANG, AND YUH-LING HWANG

1. Introduction

In a modern library, the substantial part of typical information storage and

retrieval activities concerns

1. Data entry and validation;

2. Documents cataloging and retrieval;
3. Query processing and telebrowsing;
4. Statistics generation;
5. Tabular output.

These functions not only include the traditional information retrieval facilities but
also require very sophisticated computation and processing. Most of present-day
library information retrieval systems are supported by conventional file-oriented
software, which do not efficiently enable the more sophisticated data processing.
Recently, the concept of database management systems (DBMS) has arisen, and
provides a solution for integrating related data and facilitating sophisticated data
manipulation. Among a variety of database models, the relational model has been
recognized as the most promising for expanding the facilities of traditional infor-
mation retrieval software towards the more advanced data processing.

JYH-SHENG KE • Institute for Information Industry, 6th Floor, No.116, Sec. 2, Hanking E.
Road, Taipei, Taiwan, Republic of China. CHING-LIANG LIN, CHIOU-FENG WANG, and
YUH-LING HWANG. Institute of Information Science, Academia Sinica, Taipei, Taiwan,
Republic of China. This work was partially supported by the National Science Council, Republic
of China, under contract No. NSC70-0404-EOOI-Ol.

323
S.-K. Chang (ed.), Management and Office Information Systems
© Plenum Press, New York 1984
324 JYH-SHENG KE, et al.

In a relational database, stored data are interpreted as two-dimensional

tables. Manipulation of stored data by means of set-oriented relational operators
may be interpreted in terms of operations acting on rows and columns of tables.
The expressive power of these relational operators is at least equivalent to the
first-order predicate calculus. Based on these relational operators, it is not difficult
to implement a nonprocedural query language on top of DBMS to enable novice
users to retrieve information in an easy straightforward way.
In this chapter we will present a library automation system which integrates
the functions of both the information retrieval system and the management infor-
mation system. The system presented is essentially the integration of a data entry
and validation subsystem, an information retrieval subsystem, and a relational
database management system with an intelligent user interface which provides an
extensible nonprocedural query language for novice users to access data and
retrieve information. Figure 1 shows the relationships among these subsystems.

User's
Querv

I
Schema
Translator
I

i
I
User Table-Driven 1--~~--4Da ta
Interface Data Entry I?ictionary
~'------~~'"
(In forma tion &
Retrieval) Validation Raw Data

I
I
i
down up
load load

Data Base
Management 1--~_--IData Base
System (Normaliz
ed Data)

FIGURE 1. Library information management system.

DESIGN AND IMPLEMENTATION OF A LIBRARY AUTOMATION SYSTEM 325

There are four principal areas of library operations: acquisition, cataloging,

circulation, and reference service. Automation of these activities may be compli-
cated by their interactions and relationships. In order to reduce the implementa-
tion cost by detecting the improper system specification earlier, a Petri-net-based
tool has been used to model the flow and transfer of information among work
stations in the intended library system. The tool is essentially a very high-level
specification language which can be used to define the library procedures and the
associated work stations. Based on the concept of Petri-net hierarchy, the intended
library system can be systematically top-down structured and specialized.
This chapter is organized as follows: Section 2 describes the data entry and
validation subsystem. Section 3 describes the information retrieval subsystem and
its underlying database management system. Section 4 illustrates the Petri-net-
based tool for modeling the activities of library systems. Finally a conclusion
remark has been made to investigate further research studies.

2. Data Entry and Validation (DEV) Subsystem

In a library, a substantial part of clerical work concerns data entry and val-
idation of form data. For example, the acquisition of a book requires filling a
request form and a purchase order form, and the arrival of a book requires catalog
processing which is essentially to fill a specially designed form with relevant infor-
mation. In the course of data entry, the DEV subsystem should guide the clerical
staff in what sequence the entries are made, and with what codes to record it. For
each different library function, there is a different form to be filled out. The com-
plexity of the data entry sequence usually forces the system designer to design
different DEV subsystems for different library functions. This results in spending
a considerable amount of implementation cost. The problem will be worse if rules
of library functions have been changed such that the DEV subsystem should be
changed accordingly. For these reasons, we have implemented a universal data
entry interface design tool to be used in designing a variety of data entry subsys-
tems. The implemented data entry interface design tool includes a high-level data
specification language (DSL) to be used to define each data item in the application
domain, a high-level layout specification language (LSL) for defining the format
of display layout, and a table-driven automaton with a report generator which can
guide the clerical staff to enter/update data in a user-defined specific and relevant
sequence.
To design data entry subsystems for each library function (e.g., cataloging,
acquisition, etc.), the designer need only use the DSL and LSL to define data
items and display layout, respectively. A schema translator will translate these
definitions into internal table forms which will then be used to drive the automata
and report generator. Figure 2 shows the specification of data items for cataloging
register no() /* registration number */
type is str;
pic is 4; i
class no() /* classification nuniller */
type Is str;;
cutter no() /* cutter number */
type is str;;
author() /* author name */
type is str;
sel is mul:;
authorship() /* author statement */
type is str;
sel is mul;;
title() /* book title */
type is str;
sel is mul;;
edition() /* edition */
type is str;
sel is mul;;
pub~lace() /* publisher place */
type is str;
sel is mul; i
publisher() /* publisher name */
type is str;
sel is mul:;
pub data() /* publish date */
type is str;
pic is 4;
sel is mul;;
preface () /* preface */
type is str;
sel is mul;;
page() /* number of pages */
type is int;;
illustration () /* illustration */
tvoe is str = {llill.II,'I "};;
h~lght() /* height */
type is inti;
width () /* ItJidth */
type is int;
sel is mul;;
subject () /* subject heading */
type is str;
sel is mul;;
copies () /* copies */
type is str;
sel is mul;;
location () /* storage location */
type is stri;
check-out() /* check-out status */
type is char = 'y', In'
case is {series-name: (check-out ~~ 'n') };;
borrower() /* borrower name */
type is str;;
data-due() /* due date */
type is str;
sel is mul;;
series name () j* series name */
tvpe is str;
sel is mul:;
series no () /* series number * /
type is str;
sel is muI: i
reprint() /* reprint status */
type is str = {"Reprinted!!, II II};
case is {ISBN: (reprint !~ "reprinted"));;
reprinter() /* reprinter name */
t'tpe is str;;
ISBN() /* ISBN number */
type is str;
sel is mul;!

FIGURE 2. Book specification with DSL.

DESIGN AND IMPLEMENTATION OF A LIBRARY AUTOMATION SYSTEM 327

a book. Figure 3 shows the display layout specification of a catalog card. Figure
4 shows the computer display of a catalog card.

3. Information Retrieval Subsystem and Relational Database

The information retrieval subsystem (IRS) is the most important part of the
library automation system. With IRS, the user can retrieve information on books
by specifying titles, authors, subjects, keywords, or their logical connections. The
underlying data storage system of IRS is a relational database management system
(RDBMS). In RDBMS, a high-level data definition language (DDL) can be used
to define the database schema (and subschema) which represents the information
about data items and the association among data item. To retrieve information
from a relational database is essentially to do manipulation on a set of related
tables. Manipulation of relational tables can be accomplished by using set-oriented
operations, namely, restriction, projection, join, division, union, intersection, and
difference. In the relational database, there is a set of base relations which rep-
resents the structured raw data transferred from the data entry subsystem. The
combination of above-mentioned relational operations possesses a powerful capa-
bility for deriving relations from the underlying base relations.(l) Figure 5 shows
the architecture of the RDBMS. The designed RDBMS includes two subsystems,
namely, relational interface system (RIS) and physical storage system (PSS). The
RIS provides DDL, DML, authorization and integrity check, and supports for
alternative views of stored data. The PSS maintains indexes on selected attributes,
manages disk space allocation, file access, storage buffers, locking, and transaction
consistence. In the following, Section 3.1 describes the RIS, Section 3.2 describes
the PSS, Section 3.3 describes the interface between IRS and DEV, and Section
3.4 describes an extensible nonprocedural query language for use by novice users
to retrieve data from the database.

3.1. Relational Interface System

The relational interface system provides high-level, data-independent facili-
ties for data definition, manipulation, and retrieval. The data definition facilities

%class no%-* %cutter no%-* %author%-l

- {O&l}%title%~* / by {O&l}%authorship%-*. {l&O}
{O&l}%edition%-* ed. {llo} -- {O&3}%pub place%-* : {l&O}%publish-
er%-*, {l&O}%pub date%-*.{l&O} %register no% {OIO}%preface%-*,
{lIO}%page%-* p~{l&O} : {O&l}%illustration%-* ; {O&O}%height%-*
{O&l}%width%-*cm. {ala} -- ({O&2}%series narne%-* ;
(l&l}%series no%-*) {21o} %copies%!* -
%reprint%-* by {l&l}%reprinter%-*.{l&O} {l&l}
%subject% *
%ISBN%-* borrovler: {O&l}%borrower%-* {l&l}%date-due%-*
location : {O&l}%location%-*

FIGURE 3. Layout specification with LSL.

328 JYH-SHENG KE, et al.

130 K51 Kindred, Alton R

Introduction to computers / by Alton R.
Kindred. -- New Jersey : Prentice-Hall, 1976. 0348
vi, 538 p. : ill. ; 21cm

Reprinted by Mei Ya.

1. computer funda~entals.

location : 1

FIGURE 4. Display of catalog card.

or the RIS allow the database administrator to define the data at conceptual level
as well as internal level. They also allow a variety of external views to be defined
upon common underlying data to provide different users with different views. The
external views of the common data also facilitate some authorization checks and
privacy control. The data manipulation facilities of the RIS allow data to be
inserted, deleted, modified, manipulated, and retrieved by using a set of high-level
relational operators which exempt the users from knowing the internal storage
structure of the stored data.

3.2. Physical Storage System

The physical storage system manages disk storage allocation, indexed file
access. B-tree structure has been used for indexing secondary keys of each relation.
The disk space contains a set of files each of which is constructed by a set of fixed-
size pages. For the purpose of saving space, we employ the concept of logical page
number (what the relational operator sees) and physical page number (what the
data is really stored on). A page table has been maintained to map logical page
number into physical page number. Page identification is maintained by hashing
and clustering. The PSS also supports concurrency control by using multilevel
locking techniques. Details of RDBMS can be found in Ref. 2.

3.3. IRS and DEV Interface

As we mentioned before, the raw data of each book are entered into the trans-
action file through the data entry subsystem. After validation, the raw transaction
file data are transferred into RDBMS. A down-load routine has been imple-
mented to extract the data of each new transaction file record into several related
relational tables for storage in the RDBMS. Similarly, an up-load routine has
also been implemented to construct a transaction file data record from several
related relational tables whenever an update or retrieval command has been issued
by the user.
DESIGN AND IMPLEMENTATION OF A LIBRARY AUTOMATION SYSTEM 329

3.4. Extensible Nonprocedural Query Language

One of the practical problems of library information retrieval is that most of
the users who want to borrow books or documents do not have programming or
computer-related knowledge; an easy-to-use user interface badly needs to be pro-
vided for them to retrieve information. Focusing on this problem, an extensible
query language (SQL) has been designed to allow casual users to retrieve infor-
mation from the underlying database. The user's input query language has been
made as easy as possible. With a few minute's learning, a user who knows the
operational rules of the library should be able to enter his queries. Details of XQL
can be found in Ref. 2. In the following we will present some examples to illus-
trate the expressive power of XQL in retrieving library information.

Example 1. Find all books written by James Martine.

XQL. Get book; author is James Martine.

Example 2. Get the titles of all books published by Plenum Press after 1980.
XQL. Get title; publisher is Plenum Press and year> 1980.

Example 3. Find the authors who write books in computer science or control
theory.
XQL. Get author; subject is computer science or control theory.

4. Petri-Net Modeling oj Library Procedures

The activities involved in a library system can be very complicated. At the

initial phase of the system design, the designer may not be able to fully understand

FIGURE 5. Architecture of RDBMS.

 ~ order request

I
---+-- ACQUISITION

I
book arrival

CATALOGING

book
cataloged

I
REFERENCE ~ ~ CIRCULATION
FIGURE
system.
6. Petri-net modeling of library office

~_e_r_r_e_~ues~__ "__________________________,

GENERATE ORDER
--I-- REQUEST FORI!
I

¢ form prepared

~IBRARY SELECTION

, / <D ~~ '"OOkCESSING

not ok y y
CANCEL
ORDER
REQUEST
I
--+--
,

r/:y ~--
=0 I
--+- SEND PURCHASE
ORDERS TO
SUPPLIER

receivi~ ~
~: j - - , \ ------ -~

:jJ
I

om'o ""'c/ r' \-, II I m'"" I[ I

CONTACT
SUPPLIER
~ I
~
I
I
~/
0 if
CANCEL
ORDER

good
CHECK
CORRECTNESS

defect or
'
I
I I I
RESENDI
ORDER I
LREQUEST,

book wrong boo

REGISTER AND~ CONTACT SUPPLIER

NOTIFY CATALOGER· TO RESEND BOOK

~
FIGURE 7. Petri-net modeling of acquisition process.
DESIGN AND IMPLEMENTATION OF A LIBRARY AUTOMATION SYSTEM 331

the procedures of the library system. In order to reduce the implementation cost
by detecting the improper system specification earlier, we have developed a Petri-
net based tool, PITSSL, to be used to model the flow and transfer of data among
the work stations of the library system. This wor~ is very similar to Zisman'sY)
PITSSL is essentially a very-high-Ievel specification language which can be used
to define the library procedures and the associated work stations. Based on the
concept of Petri-net hierarchy, the intended library functions can be top-down
structured and specialized. Details of PITSSL can be found in Ref. 4. In the
following, Fig. 6 shows the relationships between the four major parts of the
library system, Fig. 7 shows the Petri-net modeling of the acquisition process, Fig.
8 shows the form-filling process, and Fig. 9 shows the PITSSL description of
Fig. 8.

5. Conclusion

In a library, most of the clerical work has been involved in form-filling. For
each different library function, a different data entry subsystem is required to

8 order request

¢ ENTER AUTHOR NA.'lE

got author nar.te

+ ENTER TITLE

¢
-L
got title

ENTER PUBLISHER NA:'lE

i

6 got publisher name

--l- ENTER PUBLISH DATE

6 got publish date

6
I
ENTER VENDER NA1lE

got vender name

FIGURE 8. Petri-net modeling of generating order request form. 1 ENTER LIBRARIAN NAl·lE

got librarian name

332 JYH-SHENG KE, et at.

AUTHOR NAME:
receive rl: order request;
transmi t tl : got_author _name;
actions
Tell-user: sys-inf{id:"Author Name ?");
Ask-user: sys-req{id:AUTHOR,m);
end t AUTHOR NANE;
BOOK TITLE:-
- receive rl: got author name;
transmit tl: got=book-tltle;
actions
Tell-user: sys-inf(id:"Title ?");
Ask-user: sys-req{id:TI'l'LE,m);
end t BOOK l' I TLE:
PUBLISHER:
receive rl: got book title;
=:
transmi t tl: got=-publ name;
actions
Tell-user: sys-inf(id:"Publisher ?");
Ask-user: sys-req(id:PUBLISHER,m);
endt PUBLISHER:
PUBLISH DATE:
-receive rl: got publ name;
transmit tl: got-publ-date;
actions --
Tell-user: sys-inf(id:"Publish Date(II/D/Y) ?"):
Ask-user : sys-req{id:PUBL DATE) ;
endt PUBLISH DATE; -
VENDER NAME:-
- receive rl: got publ date:
Transmi t tl: got ==vender _name;
actions
Tell-user: sys-inf(id:"Vender Name ?");
Ask-user: sys-req(id:VENDER);
endt VENDER NAME;
LIBRARIAN: -
receive rl: got vender name;
transmit tl: got-librarIan name;
actions - -
Tell-user: sys-inf(id:"Your name ?");
Ask-user: sys-req(id:LIBRARIAN,m);
endt LIBRARIAN:

FIGURE 9. PITSSL specification of form generation.

facilitate the clerical staff entering form data. The development of a universal
DEV system design tool has greatly reduced the implementation cost of the data
entry subsystem. The use of the relational model database in the application of
information retrieval has several advantages; among them are data integrity, flex-
ibility, and low cost of implementation. The nonprocedural query language makes
the concept of access paths transparent to the user, which is particularly useful to
the casual user. Specification of correct and consistent office procedures is usually
a difficult job. In this paper we present a Petri-net-based modeling technique for
hierarchically top-down structured-designing the library procedures. Although the
modeling power of the regular Petri nets is limited to some extent, the use of the
Petri-net model in specifying the library procedures has been proved to be suc-
cessful and optimistic, and we are continuing to extend the modeling power of
Petri nets by incorporating some program-proving techniques. Hopefully we are
able to develop a more realistic and adequate modeling tool in the near future.
DESIGN AND IMPLEMENTATION OF A LIBRARY AUTOMATION SYSTEM 333

References

1. C. J. DATE, An Introduction to Database Systems, 3rd ed., Addison-Wesley, Reading, Massa-

chusetts, 1981.
2. J. S. KE, S. K. CHANG, S. M. CHIOU, and Y. L. YAN, XQL: An extensible query language
translation system, Int. j. Policy In! 5(1), 147-161, 1981.
3. M. D. ZISMAN, Representation, specification, and automation of office procedures, Ph.D. disser-
tation, Department of Decision Science, The Wharton School, University of Pennsylvania, Phil-
adelphia, September, 1977.
4. J. S. KE, W. M. GUH, and S. H. TAN, Design of information transfer systems, Proc. of National
Computer Symposium, Taiwan, December 1981.
5. J. S. KE, C. L. LIN, C. F. WANG, and Y. L. HWANG, Design and implementation of a relational
database management system, TR-81-009, Institute of Information Science, Academia Sinica,
December 1981.