Library System Analysis PDF

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 212

University of Khartoum

Faculty of Art
Department of Library and Information Science

Thesis Title: Library System Analysis: determining the


Functional Requirements for a Proposed Computerized
Library Management System. Case stud : the University
of Khartoum Library.
Candidate’s Name: Omer Hassan Abdelrahman Ali
Degree Sought: Ph. D. in Library and Information
Science- Graduate College- University of Khartoum
Supervisor: Prof. Radia Adam Mohamed
Date: 2004
ACKNOWLEDGEMENTS

I would like to express my sincere thanks and gratitude to my supervisor


Professor Radia Adam Mohamed who had introduced me to the concept of
systems sometime before I embarked on this study. That was when she
taught me in the course of the Postgraduate Diploma in Library and
Information Science. I started since then to think of the library as an
information system and of library operations as processes within this
information system. I would also like to thank her for her valuable
suggestions and remarks, and for encouraging me continuously to carry out
this study.
My thanks are also due to the Heads of department of the University of
Khartoum Main Library who were always ready for my interviews and re-
interviews. I would like to specifically mention Mr. Abdelmajeed Alsiddig,
Head of the Acquisitions Section at the time of carrying out the interview,
and Mr. Mohammed Ahmed Awad, Head of the Reader Services
(Circulation) Section.
I would also like to extend my thanks to those library attendants who were
helpful to me especially at the School of Mathematical Sciences Library, and
the Library of Computerman College.
ABSTRACT
Thesis Title: Library System Analysis: determining the Functional
Requirements for a Proposed Computerized Library Management System.
Case stud : the University of Khartoum Library.
Candidate’s Name: Omer Hassan Abdelrahman Ali
Degree Sought: Ph. D. in Library and Information Science- Graduate
College- University of Khartoum
Supervisor: Prof. Radia Adam Mohamed
Date: 2004

This research has investigated and analyzed the University of Khartoum


Library System in terms of the operations and functions carried out in the
three core sections of the library i.e. the Acquisitions, the Cataloguing and
classification, and the Reader Services (Circulation) Sections. The purpose
of the analysis is to determine the specific functional requirements of a
proposed computer-based Integrated Library Management System (ILMS).
This proposed system is recommended to be selected form the available off-
the –shelf software packages. For the purpose of gathering information about
the existing library system, a number of techniques have been employed
including interviews, document analysis, observation, and literature review.
The Structured Systems Analysis and Design Method (SSADM) is used in
analyzing the existing library system. This method necessitated the
decomposition of the system into smaller functional subsystems. The results
of the University of Khartoum Library System analysis have been
documented by a number of structured tools such as the Data Flow
Diagrams (DFDs) and the Data Dictionary. The U of K Library System
database has also been described and designed by following the relational
database model. Based on the results of the system analysis, the specific
requirements and the detailed functional requirements of the proposed
computer-based Integrated Library Management System (ILMS) have been
defined and outlined. The specific functional requirements, together with the
database description are intended to be used by the University of Khartoum
Library administration for writing a Request For Proposal (RFP) that will
assist the library administration in selecting a suitable, up-to-date, flexible
and interoperable Integrated Library Management System (ILMS).
‫ﻣﺴﺘﺨﻠﺺ‬
‫ﻋﻨﻮان اﻟﺮﺳﺎﻟﺔ‪ :‬ﺗﺤﻠﻴﻞ ﻧﻈﺎم ﻣﻜﺘﺒﻲ‪ :‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮﻇﻴﻔﻴﺔ ﻟﻨﻈﺎم إدارة ﻣﻜﺘﺒﺎت ﻣﺤﻮﺳﺐ ﻣﻘﺘﺮح‪ .‬دراﺳﺔ ﺣﺎﻟﺔ‪،‬‬
‫ﻣﻜﺘﺒﺔ ﺟﺎﻣﻌﺔ اﻟﺨﺮﻃﻮم‬
‫اﺳﻢ اﻟﻄﺎﻟﺐ ‪ :‬ﻋﻤﺮ ﺣﺴﻦ ﻋﺒﺪ اﻟﺮﺣﻤﻦ ﻋﻠﻲ‬
‫اﻟﺪرﺟﺔ اﻟﻤﻤﺘﺤﻦ ﻟﻬﺎ‪ :‬دآﺘﻮراﻩ ﻓﻲ ﻋﻠﻮم اﻟﻤﻜﺘﺒﺎت و اﻟﻤﻌﻠﻮﻣﺎت‪ -‬آﻠﻴﺔ اﻟﺪراﺳﺎت اﻟﻌﻠﻴﺎ‪ -‬ﺟﺎﻣﻌﺔ اﻟﺨﺮﻃﻮم‬
‫اﻟﻤﺸﺮف ‪ :‬أ‪ .‬د‪ .‬ا ﻟﺮﺿﻴﺔ ﺁدم ﻣﺤﻤﺪ‬
‫اﻟﺴﻨﺔ ‪2004 :‬‬

‫ﻗﺎم هﺬا اﻟﺒﺤﺚ ﺑﺪراﺳﺔ وﺗﺤﻠﻴﻞ ﻧﻈ ﺎم ﻣﻜﺘﺒ ﺔ ﺟﺎﻣﻌ ﺔ اﻟﺨﺮﻃ ﻮم ﻣ ﻦ ﺧ ﻼل اﻟﻌﻤﻠﻴ ﺎت واﻟﻮﻇ ﺎﺋﻒ اﻟﺘ ﻲ ﺗ ﺘﻢ‬
‫داﺧ ﻞ اﻷﻗ ﺴﺎم اﻟ ﺜﻼث اﻷﺳﺎﺳ ﻴﺔ ﻓ ﻲ اﻟﻤﻜﺘﺒ ﺔ وه ﻲ أﻗ ﺴﺎم اﻟﺘﺰوﻳ ﺪ‪ ،‬واﻟﻔﻬﺮﺳ ﺔ واﻟﺘ ﺼﻨﻴﻒ‪ ،‬وﺧ ﺪﻣﺎت‬
‫اﻟﻘﺮاء‪ .‬ان اﻟﻬﺪف ﻣﻦ اﻟﺘﺤﻠﻴﻞ ه ﻮ ﺗﺤﺪﻳ ﺪ اﻟﻤﺘﻄﻠﺒ ﺎت اﻟﻮﻇﻴﻔﻴ ﺔ اﻟﺨﺎﺻ ﺔ ﺑﻨﻈ ﺎم ﻣﺘﻜﺎﻣ ﻞ ﻷدارﻩ اﻟﻤﻜﺘﺒ ﺎت‬
‫ﻣﺒﻨ ﻲ ﻋﻠ ﻲ اﻟﺤﺎﺳ ﻮب ‪.‬ه ﺬا اﻟﻨﻈ ﺎم اﻟﻤﻘﺘ ﺮح ﺗﻤ ﺖ اﻟﺘﻮﺻ ﻴﺔ ﺑ ﺎن ﻳ ﺘﻢ اﺧﺘﻴ ﺎرﻩ ﻣ ﻦ ﺑ ﻴﻦ اﻟ ﻨﻈﻢ اﻟﻤﻜﺘﺒﻴ ﺔ‬
‫اﻟﺠﺎهﺰة ﻓ ﻲ اﻷﺳ ﻮاق‪ .‬ﻟﻘ ﺪ ﺗ ﻢ اﺳ ﺘﺨﺪام ﻋ ﺪﻩ ﻃ ﺮق ﺑﻐ ﺮض ﺟﻤ ﻊ ﻣﻌﻠﻮﻣ ﺎت ﻋ ﻦ ﻧﻈ ﺎم اﻟﻤﻜﺘﺒ ﺔ اﻟﺤ ﺎﻟﻲ‬
‫‪،‬ﺗ ﺸﻤﻞ ه ﺬﻩ اﻟﻄ ﺮق ﻋﻠ ﻲ اﻟﻤﻘﺎﺑﻠ ﺔ ‪ ،‬ﺗﺤﻠﻴ ﻞ اﻟﻮﺛ ﺎﺋﻖ ‪ ،‬اﻟﻤﻼﺣﻈ ﺔ‪ ،‬و ﻣ ﺴﺢ اﻷدب اﻟﻤﻜﺘ ﻮب‪.‬ﺗ ﻢ اﺳ ﺘﺨﺪام‬
‫اﻟﻤﻨﻬﺞ اﻟﻤﻬﻴﻜﻞ ﻟﺘﺤﻠﻴﻞ وﺗﺼﻤﻴﻢ اﻟﻨﻈﻢ ﻓﻲ ﺗﺤﻠﻴﻞ ﻧﻈﺎم اﻟﻤﻜﺘﺒﺔ اﻟﺤﺎﻟﻲ ‪.‬ﻓﺮض هﺬا اﻟﻤ ﻨﻬﺞ ﺗﻔﻜﻴ ﻚ اﻟﻨﻈ ﺎم‬
‫إﻟ ﻰ ﻧﻈ ﻢ ﻓﺮﻋﻴ ﺔ وﻇﻴﻔﻴ ﺔ أﺻ ﻐﺮ‪ .‬وﻗ ﺪ ﺗ ﻢ ﺗﻮﺛﻴ ﻖ ﻧﺘ ﺎﺋﺞ ﺗﺤﻠﻴ ﻞ ﻧﻈ ﺎم ﻣﻜﺘﺒ ﺔ ﺟﺎﻣﻌ ﺔ اﻟﺨﺮﻃ ﻮم اﻟﺤ ﺎﻟﻲ‬
‫ﺑﺎﺳﺘﺨﺪام اﻷدوات اﻟﻤﻬﻴﻜﻠﺔ ﻣﺜﻞ ﺧﺮاﺋﻂ ﺗﺪﻓﻖ اﻟﺒﻴﺎﻧﺎت ‪ ،‬وﻗﺎﻣﻮس اﻟﺒﻴﺎﻧﺎت ‪.‬آ ﺬﻟﻚ ﺗ ﻢ ﺗﻮﺻ ﻴﻒ وﺗ ﺼﻤﻴﻢ‬
‫ﻗﺎﻋ ﺪة ﺑﻴﺎﻧ ﺎت ﻧﻈ ﺎم ﻣﻜﺘﺒ ﺔ ﺟﺎﻣﻌ ﺔ اﻟﺨﺮﻃ ﻮم ﺑﺎﺗﺒ ﺎع ﻧﻤ ﻮذج ﻗﻮاﻋ ﺪ اﻟﺒﻴﺎﻧ ﺎت اﻟﺘﻨﺎﺳ ﺒﻴﺔ ‪.‬وﻗ ﺪ ﺗ ﻢ ﺗﺤﺪﻳ ﺪ‬
‫اﻟﻤﺘﻄﻠﺒﺎت اﻟﺨﺎﺻﺔ واﻟﻤﺘﻄﻠﺒﺎت اﻟﻮﻇﻴﻔﻴﺔ اﻟﻤﻔﺼﻠﺔ اﻟﺨﺎﺻﺔ ﺑﻨﻈﺎم إدارة اﻟﻤﻜﺘﺒﺎت اﻟﻤﺒﻨ ﻲ ﻋﻠ ﻲ اﻟﺤﺎﺳ ﺐ‬
‫اﻟﻤﻘﺘ ﺮح ﺑﻨ ﺎء ﻋﻠ ﻲ ﻧﺘ ﺎﺋﺞ ﺗﺤﻠﻴ ﻞ اﻟﻨﻈ ﺎم اﻟﺤ ﺎﻟﻲ ‪.‬وﻳﻬ ﺪف ﺗﺤﺪﻳ ﺪ اﻟﻤﺘﻄﻠﺒ ﺎت اﻟﻮﻇﻴﻔﻴ ﺔ وﺗﻮﺻ ﻴﻒ ﻗﺎﻋ ﺪة‬
‫اﻟﺒﻴﺎﻧﺎت إﻟﻰ أن ﺗﺴﺘﺨﺪم ﺑﻮاﺳ ﻄﺔ أدارﻩ ﻣﻜﺘﺒ ﺔ ﺟﺎﻣﻌ ﺔ اﻟﺨﺮﻃ ﻮم ﻣ ﻦ اﺟ ﻞ آﺘﺎﺑ ﺔ )ﻃﻠ ﺐ ﺗﻘ ﺪﻳﻢ ﻋ ﺮض (‬
‫ﻳ ﺴﺎﻋﺪ أدارﻩ اﻟﻤﻜﺘﺒ ﺔ ﻓ ﻲ اﺧﺘﻴ ﺎر ﻧﻈ ﺎم ﻣﻜﺘﺒ ﻲ ﻣﺘﻜﺎﻣ ﻞ ﻣﻨﺎﺳ ﺐ ﻳﺘ ﺼﻒ ﺑﺎﻟﻤﺮوﻧ ﺔ واﻟﺤﺪاﺛ ﺔ‪.‬‬

‫‪TABLE OF CONTENTS‬‬

‫‪Acknowledgements‬‬ ‫‪……………………………………………….. i‬‬


‫‪Abstract (English) ……………………………………………………. ii‬‬
‫……………………………………………………)‪Abstract (Arabic‬‬ ‫‪iv‬‬
‫‪Table of Contents ……………………………………………………… v‬‬
‫‪List of Figures …………………………………………………… x‬‬
‫‪List of Abbreviations ………………………………………………… xi‬‬

‫‪CHAPTER ONE: INTRODUCTION………………………………. 1‬‬


‫……………………………………………………………… ‪1.0 Introduction‬‬ ‫‪1‬‬
1.1 Statement of the Problem and Justification of the Study…………… 2

1.1.1 Emergence of Electronic Information ………………………. 5


1.2 Objectives of the Study……………………………………… 7
1.2.1 General Objectives: ………………………………………. 7
1.2.2. Specific Objectives……………………………………………. 8
1.2.2.1 Activities to be Carried Out: ……………………………….. 9
1.3 Scope of the Study and Research Hypotheses …………………… 10
1.3.1 Scope………………………………………………………… 10
1.3.2 Limitations…………………………………………………… 10
1.4 Methodology…………………………………………………… 11
1.5 Organization of the Study ……………………………………… 12

2. CHAPTER TWO: SYSTEM ANALYSIS APPROACHES…… 15


2.1 Systems and Systems Analysis…………………………………… 15
2.2 Systems Analysis Approaches……………………………………... 16
2.2.1 System Development Life Cycle (SDLC)……………………….. 16
2.3 Methodologies of Systems Analysis and Design …………………..22
2.3.1. The Structural Perspective of SDLC …………………………… 25
2.3.1.1 Structured Vs. Object-Oriented Approaches………………….. 29
2.3.1.2 Structured Vs Classical ……………………………………… 30
2.3.1.3 Individual Vs Integrated Approaches………………………… 32
2.4 Design or Selection?……………………………………………… 32

3. CHAPTER THREE: METHODOLOGY……………………….. 34


3.1 Techniques of Data Collection……………………………………. 34
3.1.1 Interviews………………………………………………………. 34
3.1.2 Document Analysis …………………………………………. 36
3.1.3 Observation …………………………………………………… 37
3.1.4 Literature Review………………………………………………. 38
3.2 Methodology of Documenting the Facts ………………………… 38
3.2.1 Structured Methodology……………………………………….. 38
3.2.2 Major Tools of SSADM……………………………………….. 40
3.2.2.1 Data Flow Diagrams (DFDs)………………………………… 40
3.2.2.1.1 Components of DFDs……………………………………… 43
3.4 Products of Structured Analysis…………………………………. 44
3.4.1 Type of Database Model Used………………………………… 45
3.4.2 Input/Processes/Output charts………………………………… 47

4. CHAPTER FOUR: DETAILED INVESTIGATION AND


ANALYSIS OF THE EXISTING SYSTEM………………….. 48
4.1 Background Information on the University of
Khartoum. ……………………………………… 48
4.2 Background Information on the University of Khartoum Library
System (UKLIS)………………………………………………… 49
4.3 The Existing Library System Organization……………………… 51
4.3.1 The Area Under Study…………………………………………. 51
4.3.1.1 Background of the Area Under study……………………….. 52
4.3.1.2 Automation in the Library ………………………………….. 54
4.3.2 Description of the Existing System Under Study…………….. 55

4.3.2.1 The Acquisitions Subsystem……………………………….. 55

4.3.2.1.1 Functions of the System…………………………………. 55

4.3.2.1.2 Procedures for Acquiring Books………………………… 57

4.3.2.1.3 Limitations of the Existing Acquisitions Subsystem ……. 58


4.3.2.2 The Catalogues Subsystem ………………………………… 59

4.3.2.2.1 Activities of the Cataloguing and Classification Section…. 60


4.3.2.2.2 Limitations of the Existing Cataloguing Subsystem……… 62

4.3.2.3 The Circulation Subsystem (The Reader Services Section) …. 63

4.3.2.3.1 Procedures in the Circulation Subsystem …………………. 63


4.3.2.3.2. Limitations of the Existing Circulation Subsystem………. 63

4.4. Additional Limitations of the Existing Library Manual System …. 65


4.4.1 Technical Limitations ………………………………………….. 65

4.4.2 Non-Technical Limitations …………………………………… 66

4.5 Documentation of the Findings of the Existing

U of K Library System ………………………………………… 67

CHAPTER FIVE: SPECIFIC REQUIREMENTS DEFINITION..89


5.1 The System Files ……………………………………………… 90
5.1.1 Title File ……………………………………………………. 90
5.1.2 Borrower File ………………………………………………. 90
5.1.3 Subject File ………………………………………………… 91
5.1.4 Vendor File ………………………………………………… 91
5.1.5 Budget File ………………………………………………… 91
5.1.6 Payment File ………………………………………………. 91
5.1.7 Statistical File …………………………………………….. 92
5.2 Type of System to be implemented ………………………… 92
5.3 Outputs, Inputs, and Processes …………………………….. 93
5.3.1 The Acquisitions subsystem …………………………….. 93
5.3.1.1 Outputs ………………………………………………… 93
5.3.1.2 Inputs …………………………………………………… 94
5.3.1.3 Processes and Operations ……………………………… 94
5.3.2 The Cataloguing Subsystem ………………………………… 94
5.3.2.1 Outputs ……………………………………………………. 94
5.3.2.2 Inputs ……………………………………………………… 95
5.3.2.3 Processes …………………………………………………. 95
5.3.3 The Circulation Subsystem ………………………………… 96
5.3.3.1 Outputs …………………………………………………… 96
5.3.3.2 Inputs …………………………………………………… 97
5.3. 3.3 Processes ………………………………………………… 97
5.4 System Resources ……………………………………………. 98
5.4.2 Input Method and Devices ………………………………. 98
5.4.2.1 Input Method …………………………………………… 98
5.4.2.2 Input Devices …………………………………………. 98
5.4.2.3 Output devices ………………………………………… 99
5.5 The Database …………………………………………….. 99
5.6 Connectivity to the Internet and Interoperability …………….. 101

CHAPTER SIX: DETAILED FUNCTIONAL SPECIFICATIONS OF


THE PROPOSED SYSTEM ……………………………… 104
6.1 Acquisitions Control ……………………………………….. 105
6.1.1 General …………………………………………………….. 105
6.1.2 Pre-order Searching and Verification ……………………… 108
6.1.3 Ordering and Order Maintenance ………………………… 108
6.1.4 Receipts …………………………………………………… 109
6.1..5 Claiming ……………………………………………….. 110
6.1.6 Payment and Fund Accounting ………………………… 110
6.1.7 Vendor File …………………………………………….. 111
6.2 Cataloguing and Database Maintenance ………………….. 113
6.2.1 General ……………………………………………………. 113
6.2.2 Standards ………………………………………………….. 114
6.2.3 Import and Export ………………………………………… 114
6.2.4 Indexing …………………………………………………... 115
6.2.5 Call Numbers …………………………………………….. 116
6.2.6 Printing and Data entry ………………………………….. 116
6.2.7 Authorities ………………………………………………. 117
6.2.8 Item Records …………………………………………….. 118
6.3 OPAC ……………………………………………………… 120
6.3.1 general ………………………………………………….. 120
6.3.2 Search Interface Functionalities ………………………… 120
6.3.3 Navigation ……………………………………………… 122
6.3.4 Help and “Artificial Intelligence” Enhancements …….. 123
6.3.5 Content Display ………………………………………… 124
6.3.6 Printing and Downloading …………………………….. 125
6.4 Circulation ……………………………………………. 126
6.4.1 Circulation Parameters ………………………………… 126
6.4.2 Circulation Control …………………………………… 128

CHAPTER SEVEN: DATABASE DESIGN ……………. 132


7.1. The Conceptual Database Design …………………….. 133
7.1.1 The Acquisitions Subsystem Database ……………… 134
7.I.2 The Cataloguing Database …………………………… 138

7.1.3 The Circulation Database …………………………… 141


7.2 The Logical Database Design ………………………… 145
7.2.1 Overview of the Relational Model Used …………… 145
7.2.2 Implementation of the Logical Design …………….. 148
7.2.2.1 The Acquisitions Subsystem …………………….. 148
7.2.2.2 The Cataloguing and Circulation Subsystems …… 149
7.3 The Physical Database Design ………………………. 162
7.3.1 Overview Of The Physical Database ……………… 162
7.3.2 Steps Followed in Designing the Prototype Physical
Database ………………………………………….. 162
7.3.3 The Physical Design of The Catalogue database and
OPAC of the U of K Library ……………………… 164
7.3.4 Summary……………………………………………. 177

CHAPTER EIGHT: PRESENT AND FUTURE


TRENDS IN LIBRARY MANAGEMENT SOFTWARE ……… 179
8.1 Definition …………………………………………………… 179

8.2 Software Packages Options ………………………………… 180

8.2.1 Advantages of using off – the – shelf packages …………… 180


8.3 Recent Trends in Library Management Systems ……….. ..… 181

8.3.1 Client/Server architecture ………………………………… 183


8.3.2 Web Technologies and Metadata Standards ……………… 184

8.3.2.1 Metadata Standards ………………………………………. 185

8.3.2.1.1 Dublin Core ………………………………………… 185


8.3.2.1.2 VRA Core …………………………………………… 186
8.3.2.1.3 Encoded Archival Description (EAD) ………………… 187
8.3.2.2 Web Technologies ……………………………………… 187

8.3.2.2.1 Z39.50 ……………………………………………… 187


8.3.2.2.2 XML ……………………………………………… 191
8.4 Open Source Systems ………………………………….. 193
8.5 Application Service Providers (ASP) ………………….. 195

CHAPTER NINE: SUMMARY AND CONCLUSION ……… 196


9.1 Summary and Conclusion …………………………………. 196

Bibliography ………………………………………………… 202


Appendices ………………………………………………….. 214

LIST OF FIGURES

Figure 4.1 The Five Organizational Levels………………………. 52

Figure 4.2 Management Structure Chart of the U of K Library


System …………………………………………………. 68
Figure 4.3 Context Diagram of the U of K Library System……… 69
Figure 4.4 Level 0 Data Flow Diagram of the U of K Library
System … …………………………………………… 70
Figure 4.5 Physical Data Flow Diagram of the Acquisitions
Subsystem …………………………………………… 71
Figure 4.6 Logical Data Flow Diagram of the Acquisitions
Subsystem…………………………………………… 72
Figure 4.7 Physical Data Flow Diagram of the Cataloguing
Subsystem…………………………………………. 73
Figure 4.8 Logical Data Flow Diagram of the Cataloguing
Subsystem………………………………………… 74
Figure 4.9 Physical Data Flow Diagram of the Circulation
Subsystem……………………………………….. 75
Figure 4.10 Logical Data Flow Diagram of the Circulation
Subsystem……………………………………….. 76
Figure 4.11 Documents/Data Item Grid…………………… 77
Figure 4.12 Proposed Organization Structure of the U of K
Library System ……………………………… 79
Figure 4.13a IPO Chart of Purchasing Process in the Acquisitions
Subsystem…………………………………… 80
Figure 4.13b IPO Chart of Cataloguing and Classifying Books in
The Catalogues Subsystem ………………………. 81
Figure 4.13c IPO Chart of Lending Process in the Circulation
Subsystem………………………………………… 82

LIST OF ABBREVIATIONS

AACR2 : Anglo-American Cataloguing Rules Second Edition


ASCII : American Standard Code For Information
Interchange
ASP : Application Service Provider
BBC : Bliss Bibliographic Classification
CD-ROM : Compact Disk Read Only Memory
CDS/ISIS : Computerized Documentation Services /Integrated
Set of Information systems
CPU : Central Processing Unit
DBMS : Data Base Management System
DDC : Dewey Decimal classification
DFD : Data Flow Diagram
EAD : Encoded Archival Description
EDI : Electronic Data Interchange
FTP : File Transfer Protocol
HIPO Chart : Hierarchical Input- Process – Output Chart
ID : Identification
ILMS : Integrated Library Management System
ILS : Integrated Library system
IPO Chart : Input – Process - Output Chart
ISBN : International Standard Book Number
ISO : International Standardization Organization
ISSN : International Standard Serial Number
LMS : Library Management System
MARC : Machine Readable Catalogue
OOA&D : Object Oriented Analysis and Design
OPAC : Open Public Access Catalogue
OSS : Open Source System
PC : Personal Computer
RDBMS : Relational Data Base Management System
RFP : Request For Proposal
SDLC : System Development Life Cycle
SSADM : Structured System Analysis and Design Method
TCP/IP : Transmission Control Protocol/Internet Protocol
UKLIS : University of Khartoum Library System
U of K : University of Khartoum
VRA Core : Visual Resources association core categories
XML : eXtensible Markup Language
CHAPTER ONE
INTRODUCTION
1.0 introduction
We are living in a world of systems: systems are around us, whether being
natural systems such as the solar system, the ecological system, and the
human body system; or man- made systems such as social and political
systems, banking and financial systems, and information. systems. This fact
attracted the attention of intellectuals and scientists long time ago, since the
days of Aristotle who thought, “ The whole is more than the sum of its
parts”. In recent times, the idea of the “General System Theory” can be
attributed to the Hungarian biologist Ludwig Von Bertalanffy who was
quoted by Provost (2004) as stating that “ the notion of a system may be seen
as simply a more self-conscious and generic term for the dynamic
interrelatedness of components”. According to Provost (2004), Bertalanffy
asserted in 1936 that “ there are characteristics of systems that are
homologous to all systems simply because they are systems”.
O’Connor and McDermott (2004) highlight the need for systems thinking
skills in today’s world; they outline the following benefits of systems
thinking:
i) We will be able to predict events and prepare for them;
ii) We will have more effective ways of dealing with problems, and
better thinking strategies;
iii) The way to gain more influence in our organizations or institutions
is to understand the structure of the system. It is the structure of the
system, not the effort of the people in it, that determines the
outcome.
iv) Systems thinking helps us to understand the complexity of a
process so as to improve it. It also helps with team and team
building, because teams act as a system.

McLeod (1983) in reviewing the systems approach asserts that in an


organization, the manager should see his organization as a system residing
within a larger environmental system and consisting of several subsystems;
consequently, the manager will be able to understand a problem if it exists.

1.1 Statement of the Problem and Justification of the Study

The University of Khartoum Library, established in 1902, is the largest

university library in the country. It has been serving the university

community ever since. Because of the recent proliferation in the number of

new universities, the library has assumed an additional role; providing

library services to users from outside the university. The library has been

functioning manually throughout its history. This fact caused the library to

function less effectively in terms of the internal library housekeeping

activities. This has had a negative impact on the library’s ability to provide

efficient and effective services to its users. In this age of information

technology, information superhighway, and digital libraries, it is difficult for

a library to cope up with the ever-increasing volume of information while

operating manually. Thus, library automation has become a necessity


nowadays, so that the library can carry out its basic function of meeting its

users’ needs.

Kimber (1974), points out that an automated library system can monitor and

report on its own performance and can also detect the behavior of library

users. Such a system assists the library manager to bring about real

improvements in the services his library is providing for its clientele.

Kimber also asserts that automation of individual library systems has

important implications for the structure and organization of library services

on national and international scales. This is particularly evident at this time

of the advent in telecommunications technology, and the spread of regional

and international library networks.

Automation is also a very effective tool in the measurement and statistical

analysis of the library’s performance. Facilities in automated systems such

as report generation can be used for the system’s optimization, to assist in

forward planning, and as valuable information in user studies.

Library automation can also prove to be cost-effective; unit costs of library

operations are changing in favor of automated systems. This is because labor

cost tends to rise, while computer hardware and software costs are dropping

steadily. According to Kimber (1972), there is a large labor component in

manual systems than in automated ones and so the passage of time favors the
latter. Despite their slightly higher unit costs at present, because it takes a

long time to develop, or to study and select, an automated library system,

and then install it, the economic argument is one for automation sooner

rather than later.

Providing improved and efficient services to library users is a major

reason for introducing computer-based library systems. Automated

library systems make for new and better services to the library’s clientele.

Housekeeping automated systems which are concerned with the library’s

internal operations, and for which this study is carried out, provide

mostly indirect services to library users; For example automated

cataloging systems together with the Open Public Access Catalogue

(OPAC), can improve the library’s catalogues and make them widely

available. Circulation systems can improve services through their strict

control of the lending process. The ordering and acquisitions system, on

the other hand, is more valuable to the library staff themselves.

Teigen (1998) outlines the following ideas, which she received from

fellow librarians through the LM_NET listsrv, as justifying library

automation:

i. Automation helps with accountability by keeping track of

materials, cutting down on loss, and analyzing what is being used.


ii. More accessibility of the library’s collection. Searches can be

carried out in more many ways and more quickly than with a

traditional library catalogue.

iii. There are less clerical tasks involved with automation, leaving

more time to work with library users.

iv. Computerized records are simple to update, so reports and

inventories are more accurate and can be combined quickly.

v. More reports and statistics can be generated immediately by the

computer.

vi. Automation allows staff to analyze collection usage pattern

easily, leading to better collection development.

It can be concluded from the above ideas that the reason to the evolution of

the library for the information age is not to introduce technology on the basis

of technological criteria alone. It is necessary to consider the goals of the

library and its users and then assess the appropriateness and utility of a given

technology for achieving these goals.

1.1.1 Emergence of Electronic Information


The concept of the Digital Library has had a strong impact on libraries

worldwide; it has necessitated the need for library automation in order for

libraries to benefit from the advent of information and communication

technology. Bailey (1990), in an editorial of the Public Access Computer

Systems Review, notes that the nature of library services is changing, as an

increasing number of academic libraries provide Internet access to their

online catalogues and other databases. The (American) Association for

Research Libraries outlines the following elements as common to the

definition of the digital library:

i. The digital library is not a single entity;

ii. The digital library requires technology to link the resources of

many;

iii. The linkages between the many digital libraries and the

information services are transparent to the end users;

iv. Universal access to digital libraries and information services is

a goal;

v. Digital library collections are not limited to document

surrogates: They extend to digital artifacts that cannot be

represented or distributed.
Dunsire (2001) highlights the fact that advances in networking technology

has been a major reason for change in library services; the ability to link

libraries, users and resources together over great distances, and the need to

cooperate and share to improve services and reduce costs has called for the

necessity of applying standards to library services and functions.

Kenney (2000) highlights the fact that Internet technology is fueling

librarian’s initiatives; library catalogues have been moved to the surface of

the web and could easily be searched by means of WebOPACS. Digitized

collections have been created and maintained. Kenney hints that the

Integrated Library System (ILS) will be the glue that holds together the

digital library of the future.

1.2 Objectives of the Study

1.2.1 General Objectives:

The major objective of this study is to analyze the library operations carried

out in the U of K library system. This analysis will assist in determining the

functional requirements of a proposed computer-based Integrated Library

Management System (ILMS). This entails the functional decomposition of

the existing library system, highlighting the points of strengths and

weaknesses of each of the three core subsystems under study, and


consequently improving the flow of information between the different

library subsystems. This leads to improving the efficiency and effectiveness

of the library services through computerization of library processes and

functions. Analysis of the existing system and the subsequent steps of

defining the library system database, and defining the specific functional

requirements of the proposed (ILMS) are carried out and based on well-

established systems analysis tools and techniques.

1.2.2. Specific Objectives

The specific objectives of this study are to study and analyze the individual

library subsystems, namely:

i. The Acquisitions subsystem; To study the process of library materials

selection, sources of materials, mode of acquisition, registration and delivery

to the cataloguing and classification subsystem.

ii. The Cataloguing and Classification subsystem; To study the process of

cataloguing and classifying library materials, especially books, and the

outputs from this subsystem, namely types of catalogues and indexes.


iii. The Circulation Subsystem; To study the rules and regulations that

enable the library users to utilize the different services offered by the library,

and to study those rules and regulations that enable the U of K library to

control the circulation of its book holdings.

1.2.2.1 Activities to be Carried Out:

The specific objectives also include the following activities:

A. Design of the following aspects of the U of K library system

database:

i. Conceptual and logical design of the following three core

subsystems:

• Acquisitions module; design of accessions database for the

library’s book holdings, identifying the different entities and

attributes.

• Cataloguing/Classification module; design of a catalogue

database with its different entities and attributes,

• Circulation module; to design user profile database for the

circulation control.
ii. Design of a prototype physical database for the Cataloguing

subsystem and its OPAC interface.

B. Functional Requirements Specifications of the Modules in the

Proposed Library System.

The requirements specifications of the proposed Integrated Library

Management System will cover all functional requirements of the system

module by module i.e. the Acquisitions module, the Cataloguing module,

and the Circulation module.

1.3 Scope of the Study and Research Hypotheses

1.3.1 Scope

This study covers three subsystems of the University of Khartoum Library

System (UKLIS), namely, the Acquisitions subsystem, the Cataloguing and

Classification subsystem, and the Circulation subsystem. The Periodicals

subsystem is not included in this study.

This study aims at analyzing the existing system so as to determine the

proposed Integrated Library System’s specific requirements in order to assist

in the selection of a suitable ILMS. A detailed system design is beyond the

scope of this study.


1.3.2 Research Hypotheses

This study has put forward the following hypotheses:

i) The manual system of the U of K library is the main obstacle for

improving the U of K library services;

ii) There are problems in the flow of information among the different

U of K Library subsystems;

iii) Weaknesses in the existing manual library system can be

eradicated by the introduction of computer-based Integrated

Library Management System (ILMS)

1.4 Methodology

The structured method is employed for the purpose of analyzing the U of K

library system. This method is a formal disciplined approach that

concentrates on allowing the users to play an important role in the system’s

development process. In order to produce a well- structured system analysis,

certain aspects of the existing system should be accurately defined. These

aspects include: the system’s inputs, its outputs, the data structure, and the

processing of the data within the system.


The structured methodology is characterized by the use of graphic

documentation. A variety of tools are used for the purpose of structured

analysis and. These include data flow diagrams (DFDs) and a data

dictionary.

For the purpose of acquiring detailed facts about the nature of the existing U

of K library system, the following techniques are used:

i. Interview: Care is taken to interview the correct person who

can give accurate, detailed facts of the present system. The

interviews carried out are structured interviews and the facts

obtained are recorded in writing.

ii. Observation: Direct observation is practiced. This is supported

and facilitated by the researcher’s knowledge and experience of

the library system under investigation.

iii. Document Analysis: Valuable facts on the existing system are

obtained by reading and analyzing various records including

annual reports, ad hoc reports, forms and charts. Care is taken

to exclude out of date documents.

iv. Literature review: Literature on systems analysis and library

automation and on integrated library management systems is


extensively reviewed. Documents available online on the

Internet have been an excellent source of information.

1.5 Organization of the Study

Chapter Two of this study reviews literature on the field of systems analysis

and design. It focuses on discussing the methods and methodologies of

systems analysis with emphasis on the Systems Development Life Cycle

(SDLC) method. The chapter then highlights the structural aspects of the

SDLC. The chapter concludes by highlighting two different approaches of

systems analysis and design, namely the individual and the integrated

approaches.

Chapter Three explains the methodology employed in this study. It

highlights the different techniques used for the purpose of gathering data in

order to analyze the existing U of K library system. The tools of systems

analysis employed in this study are also explained in this chapter, focusing

on the Data Flow Diagrams (DFDs). The chapter concludes by discussing

the database model used in this study to define and describe the U of K

library system database.

Chapter Four deals with the analysis of the existing University of Khartoum

library system, starting with background information about the system and
moving on to the analysis of the operations and functions of the three

subsystems covered by this study; i.e. the Acquisitions subsystem, the

Cataloguing subsystem, and the Reader Services (Circulation) subsystem.

Detailed description of the activities carried out in the U of K library system

is offered in this chapter. Problems and limitations of each subsystem are

also highlighted. The analysis of the library system is supported by graphical

documentation provided at the end of this chapter, including data flow

diagrams and IPO charts. The data dictionary of the U of K library system is

also compiled, based on the DFDs, and presented at the end of this chapter.

Chapter Five defines the specific requirements of the proposed library

management system. These requirements are based on the results of the

analysis of the existing U of K library system. The specific requirements

include inputs, outputs, operations (processes), and system resources.

Chapter Six is a continuation for Chapter Five; it elaborates on the

functional specifications of the proposed Integrated Library Management

System (ILMS). This detailed functional specification can be used by the U

of K library administration as the basis for a Request for Proposal (RFP) to

assist in selecting a suitable off-the- shelf (ILMS).

Chapter Seven deals with the description and design of the U of K library

system database. It offers a conceptual and logical design for the three core
modules of the U of K library system. There is also the physical design of

the Cataloguing module and its OPAC interface. This description is to

accompany the detailed functional specification to be used in the Request

For Proposal (RFP) for the proposed Library Management System.

Chapter Eight discusses present and future trends in Integrated Library

Management Systems (ILMSs). It explains the effects and impact of the

Internet and the advances in information technology on Integrated Library

Management Systems (ILMSs).

Chapter Nine summarizes the research and highlights the conclusions drawn

from this research.


CHAPTER THREE
METHODOLOGY
This chapter describes the different techniques and methods
used in the process of carrying out this study. It starts by
describing the techniques employed for gathering facts about
the existing U of K Library system.It then proceeds to explain
and describe the methodology used in analyzing the existing
system.

3.1 Techniques of Data Collection


In the process of collecting data and information to understand
and analyze the present system, four techniques of fact
gathering are employed, these are;
a) interviewing;
b) analyzing documents;
c) Observation; and
d) Literature review

3.1.1 Interviews

Three interviews were held with the respective heads of the


investigated subsystems. The interviews took the form of
structured interviews; the questions were prewritten and
most of the answers of the interviewees were recorded in
writing. The researcher was in close contact with the
interviewees and returned to them in many instances so as
to clarify some points.

Theirauf (1986) pointed out that interviewing is an excellent


way to see what is transpiring in a system. It is talking
directly with the individual responsible for getting the job
done.

Most of the questions of the interview were open-ended


questions. These open questions, as noted by Watteville and
Naught (1977), are often more fruitful than closed questions
which can be fully answered with “Yes’ or “No”.

Skidmore (1997) supports the view that interviewing will be


used at different times and for different purposes as the
project of analyzing the existing system progresses. He
outlines the following purposes of interviewing:
a) to gather facts about the procedure and decisions
taking place in an organization;
b) to check the analysts understanding of system
operations with users at all levels;
c) to validate aspects of a proposed system design;
d) to build confidence in the design of a new information
system.

Fitzgerald and Fitzgerald (1987), stress that the personal


interview is the most important data-gathering tool for the
systems analyst. They point out that interviewing should be
used throughout the system study because it produces the
most up to date information of all the resources available to
the analyst.

For the purpose of recording the facts gathered by


interviews about the U of K Library System, an Interview
Notes form is used to document the answeres of each of the
three heads of the subsystems under study ( refer to
Appendices I, II , III ) . This form consists of the following
items:
• Person Interviewed- this is the name of the head of
dapartment (subsystem) who answered the interview
questions.
• Date of Interview
• Department of the person interviewd i.e the subsystem
under study.
• Interview Notes. These are the answers of the
interviewee to the strucured questions of the interview. The
answers are edited and summerized.
• Inputs. These are the input forms or records that are
used to input data in the concerned subsystem.
• Outputs. These are the forms or files used to hold the
output data from the subsystem.
• Relavant forms. Theses are any other forms or records
used in carrying out the functions of the subsystem under
study.
Samples of all the input forms, output forms, and relevant
forms are shown in appendix IV.

3.1.2 Document Analysis


This is a very important fact gathering technique. Documents
represent the formal information flow of the present system. In
this regard, speciments of the relevant documents used in the
investigated U of K Library system are collected and analyzed.
These documents are mostly forms. They assisted in
understanding how data is passed and used in the existing
system. The documents analyzed also include reports, whether
annual reports of the University of Khartoum library or reports
written by some library experts about the library system.
Skidmore (1997) pointed out that document analysis assists in
understanding the flow of information in the system under study
by answering the following questions:

a) what event triggers the generation of the document;


b) Who generates the document?
c) How is it prepared?
d) Where is the data derived from?
e) Who uses the document?
f) For what purpose is it used?
g) How is it stored?
h) How long is it kept for?

The answers to these questions supplemented the interview


notes in drawing the various data flow diagrams and the other
graphical representations of the University of Khartoum Library
System (UKLIS).

3.1.3 Observation
Observation, or directly witnessing how the system works, is a
basic method of fact gathering for systems analysis. The
researcher took advantage of his prior knowledge and
experience of the University of Khartoum Library System- the
system under investigation- in observing the different aspects of
the system. By prior experience with the system and personal
relationships with the system’s users, the researcher has been
able to avoid what is termed by Theirauf (1986) the
“Howthrone effect”; when people are aware that they are being
watched, they tend to act differently. Both Skidmore (1997) and
Theirauf (1986) agree that observation is a very time consuming
method for gathering information. Skidmore stresses that
observation of a system in normal operation will expose many
features, which might not be considered relevant, discussed or
documented in any formal way. He points out that the value of
observation as a fact finding technique depends upon how long
the activity is undertaken and the skill of the observer,
Skidmore (1997). Burch (1981) highlights the fact that
observation allows the analyst to participate in the procedures
being performed by the employees, and that with this kind of
hands-on- experience the analyst may find out that the forms are
improperly designed, thus the analyst can often determine better
and quicker ways of doing something.

3.1.4 Literature Review


Literature review on systems analysis and on library automation
has been carried out by consulting print sources and non-print
electronic sources. In this regard a number of websites have
been visited and navigated through. All print and electronic
sources consulted are listed in the Bibliography at the end of
this study.

3.2 Methodology of Documenting the Facts


All facts gathered by using the different fact gathering
techniques mentioned above are documented. Questions and
answers of the interviews are recorded down (See Appendices I,
II, III Interview Notes ). Facts gathered from analyzing forms
are documented by using the technique of Document /Data
Item grid. This grid shows the existence and duplication of data
items on various documents (Refer to Figure 4.11
Document/Data Item grid). Facts gathered by observation are
also documented in writing throughout the detailed
investigation period.

3.2.1 Structured Methodology


This study employs the Structured Systems Analysis and
Design Methodology (SSADM). Hutchings (2002) in a
public document on the internet, outlined the purpose of
structured methodologies as the following:
1. to formalize the requirements of elicitation process to
reduce the chances of misunderstanding the requirements;
2. to introduce the best practice techniques to the analysis
and design process.

He further describes the SSADM as a method which adopts


a prescriptive approach to information systems
development in that it specifies in advance the modules,
stages, and tasks, which have to be carried out, the
deliverables to be produced, and the techniques used to
produce the deliverables. SSADM is a methodology used in
the analysis and design stages of systems development.

Teague, and Pidgeon (1985, 62) highlight the following


characteristics of the SSADM:
i) `It is graphic. A data flow diagram presents the system
strucure visually- the most effective form of human
communication.
ii) It is partitioned. A data flow diagram decomposes the
system into parts so that its structure can be understood and
communicated.
iii) It is top-down. A set of data flow diagrams presents the
details of the system by partitioning the transformations
(processes) hierarchically from the top down. Similarly, the
system dictionary provides a decomposition of the data
strucures.
iv) It is nonredundant. With “a place for everything and
everything in its place” the structured specification is
friendly to change. Minimum redundancy supports the
many revisions to the specification necessary during an
iterative process, accommodates change during system
development, and facilitates modifications after the system
is in production.
v) It is accurate.
vi) It is minimal in the sense that it eliminates
nonessentials, omitting what can be decided later or left to
the discretion of the system designers or implementers, but
it must not omit details that will result in rejection of the
system by the users.

3.2.2 Major Tools of SSADM

There are three key techniques employed by the Structured


Systems Analysis and Design Methodology (SSADM) in the
process of systems analysis and design. These techniques are
• Data Flow Diagrams (DFDS);
• Entity –relationship diagram,
• Hierarchyand Input/Process/Output(HIPO) charts .

Two of the above mentioned techniques are employed in this


study. They are the the DFDs and the HIPO charts.

3.2.2.1 Data Flow Diagrams ( DFDs): These are the most


important tools used by system analysts. this is the process
of identifying, modeling, and documenting how data flows
around an information system. A Data Flow Model consists
of a set of integrated Data Flow Diagrams supported by
appropriate documentation. Data Flow Diagrams (DFDs)
represent processes, external entities, and data flows.
Fitzgerald and Fitzgerald (1987) defines a data flow
diagram as a graphic representation of a system that shows
data flows to, from, and within a system. It also shows the
processing functions that change the data and the storage of
this data. DFDs show the movement of information (data
flows) from both the physical and the logical viewpoint .i.e
how it is done and what is done. DFDs, as pointed out by
Skidmore (1991), are used in three stages of the system’s
development process. These stages are:
i) Current Physical DFD. This records facts about the
existing system.
ii) Current Logical DFD. This records the logical
information about the existing system.
iii) Required logical DFD. This models the information
processing requirements of the new proposed system.

Bansal (2000) points out that the DFD as a modeling


technique for information systems in a diagramatic form
was first proposed by DeMarco in 1978. Accordingly an
information system is seen as having three main
components- data represented by a data flow or a data
store, system processes working upon data, and external
entities interacting with the system. The data either flows or
is stored in a data file.

There are two types of DFDs; physical DFD and logical


DFD. A physical DFD representation of processes shows the
performer, the place and the method of performance of the
process. Bansal (2000) explains the functions of both types
of DFD in systems analysis as follows :

“ the physical representation makes the system easily


understandable, but adds unnecessary details to the DFD
and makes it complicated. The logical representation of
processes on the DFD keeps the DFD neat and clean, but
understanding of the system may be a little difficult…. the
physical representation does not help in improvimng the
system while the logical representation clearly deals with the
system objectives, and hence helps in improving the
system…. to take advantages of both, both representations
are used in a system representation through DFDs. At the
higher level, where the whole system needs to be
understood, physical representations of the processes are
used. Once , the the system becomes clear, the physical DFD
is converted to yield a logical representation of the system.”
Bansal (2000, 76).

Downs (1988) points out that there are several methods by


which data flow diagrams can be constructed, each
corresponding to a system design method. He further
outlines two methods:
i. the bottom-up approach which starts with a flow to or
from a user (external entity) and progressing through the
whole system at this detailed level.
ii. The top-down approach – employed in this study-
which starts with the most high-level functions and the
major data flows in and out of these. A diagram with a
small number of boxes, called the context diagram, is
constructed to represent the top level. This is expanded to
produce a more detailed diagram, and so on.

Gangolly (1997) highlights the following functions of a Data


Flow diagram:
i. defining the scope of the system under study. This is
accomplished by drawing the context diagram for the
system.
ii. Documentation of how the existing system works. This
is accomplished by drawing the physical DFDs of the
existing system. these DFDs specify the current
implementation of the existing system, and would answer
questions such as:
• Who performs the tasks?
• How they are performed?
• When or how often they are performed?
• How the data is stored i.e in what media?
• How the dataflows are implemented (media)?

iii. documentation of what the system does. This is


documented in logical DFDs of the existing system. These
logical DFds are derived from the physical DFDs with
abstraction of all implementation details. These logical DFDs
are usually levelled to reduce the perceived complexity of the
system, and balanced in order to assure consistency in the
design.
iv. Documentation of what the proposed system will do. This
is depicted in a set of logical DFDs which describe what the
modified or proposed system will do in order to meet the user
requirements. These functional specifications are devoid of
implementation considerations, and therefore rather abstract
specifications of the proposed system. These logical DFDs are
also levelled and balanced.
v. Documentation of how the proposed system will work.
The logical DFDs of the proposed system are then examined to
determine which implementation of it meets the user
requirements most efficiently. The result is a set of physical
DFDs of the proposed system. They answer questions such as:
• Who will perform the variuos tasks?
• How they will be performed?
• When or how often they will be performed?
• How the data will be stored? and
• How the dataflows will be implemented?

in this last step, man-machine bounderies are drawn, and media


selected for all data flows and data stores.

3.2.2.1.1 Components of DFDs


Teague and Pidgeon (1985) explain the components of a data flow
diagram. According to them, a data flow diagram consists of four
components, each drawn with a different symbol as will be explained
below.
i. Data Flow : a data flow is a movement of information within
the system or across the system boundary. It can be thought of
as a pipeline through which packets of data of known
composition flow.Data flows must be an input or output of a
process box. Data flows are represented by directed arcs
whereas physical flows are represented by a double line as far
as this study is concerned; e.g the flow of books from one
section of the University of Khartoum Library System to
another is represented by a double line.
ii. Process : a process transforms or changes incoming data
flows into outgoing data flows. Each process is documented
with a brief Process Description, which is a brief outline of the
process activity which is taking place.process are represented
by circles in a DFD.
iii. External Entity: These are sources or sinks of data (people
or organizations or other systems) that are lying outside the
context of the system under study.External entities are
represented by squares in a DFD.
iv. data stores : these are files or repositions of information. A
data store can hold permanent, temporary, historical, or external
data. These files receive inputs or outputs only from processes.
Stores are identified with a D+Number, the D stands for data.
Data stores are represented by an open rectangle whereas
duplicate data stores are represented with an open rectangle
with two vertical lines.

3.4 Products of Structured Analysis

Teague and pidgeon (1985) point out that the major product
of structured analysis is the structured specification, which
is a document defining the user requirements of the new
system. This document consists of three major components,
they are:
i) a set of data flow diagrams
ii) a system dictionary, and
iii) a database description.
In addition to these major components the complete system
specification contains any other specific essential user
requirements, as well as an explicit list of performance targets
that will be the basis for acceptance of the new system by the
users.

As for the strucured specification of the U of K Library


System, all the above major components are produced
throughout the study. There are a number of DFDs in chapter
four of this study that depict the functions and activities of the
system under study. The DFDs are accompanied by the “Data
Dictionary’ which is a mojor componenet of the system
specification. It defines the different data flows and data stores
of the U of K Library System.This data dictionary is the basis of
the third product of the strucured specification, which is the
“Data base Description”; Chapter 7 of this study deals with the
Database design. The database is a collection of inmterrelated
records. The major advantage of a database is the ability to
share the same data across multiple applications and systems.
In the information system framework, the end product of
database design is a Database Schema. Which is a technical
blue print of the database. In the Database stage, the data
model that were developed earlier for the system users ( the
DFD and Data Dictionary) are translated into data structres that
are supported by the chosen database technology.

3.4.1 Type of Database Model Used


Database models are classified accordintrg to the way records
are strucured by them. There are a number of database models .
The electronic journal “Biblio Tech Review: information
technology for libraries” in an article entitled “Database
Management Systems (DBMS)”, reviews types pf databases
and outlines the following types:
i) Hierarcical, described as obsolete now.
ii) Network , described as fast and efficient, but inflexible and
technically obsolete;
iii) Relational, which use the Structured Query Language (SQL)
to extract and update data and conform as closely as possible to
the theoretical relational rules of normalization.
iv) Nested, they allow related multiple values and subvalues
within a field and they can easily support variable length, non-
limited fields.
v) Proprietary, developed by some library system suppliers.
vi) Free Form databases or “ Text Retrieval Systems’; they have
no structre making functions other than retrieving records from
the information file -e.g circulation, acquisition- difficult to
achieve.
vii) Object Oriented DBMS (OODBMS); object orientation for
a database means the capability of storing and retrieving objects
such as images and video, in addition to data. Accodring to the
review article mentioned above, the implications of OODBMS
for library systems are unclear.

This study has chosen the relational model for the database
design. Relational databases implement data in a series of tables
that are related to one another via “Foreign Keys”. In a
relational database files are seen as simple two dimensional
tables, also known as relations. The rows are records, and the
columns correspond to fields.
This study has chosen the relational model because of its many
advantages that it has over the rest of the models. An important
advantage is that the relational approach is easy to understand
and appreciate since to end users, it appears that all the data is
stored in a two dimensional tables, called flat files. The rows
(tuples) represent records, while the columns (attributes)
represent fields. Columns represent tables to one another. In
other words, relationships are represented by foreign keys in the
dependent (child ) tables.

Koernke (1983) stresses that the significance of the relational


model is that relationships are considered to be implied by data
values. He proceeds to highlight that the principal advantage of
carrying relationships in data is flexibility.i.e relationships need
not be predefined.
The U of K library system will thus be modeled to take
advantage of the following characteristics of the relational
approach;
• Data independence.
• Flexibility.
• Ease of use by end users and the information service
personnel (in
this case library staff).
• Security of data.
• Symmetry access, which refers to the ease with which
queries are
constructed.

For the purpose of this study, three levels of the U of K system


database are described and designed, namely, the “Conceptual
Database”, the “Logical Database”, and the “ Physical
Database”. The latter is restricted to the Catalogue and OPAC
database, bearing in mind that the library system recommended
is an integrated one, having the catalogue database as its system
database.

3.4.2 Input/Processes/Output Charts


The system is also described by Input/Process/Output (IPO)
charts. By using these charts, a selected set of the system are
represented by IPO charts with three components-the input to
the function,the process that transform this input, and the output
from the function (refer to figures 4.13a, 4.13b, and 4.13c).
CHAPTER FOUR
DETAILED INVESTIGATION AND ANALYSIS OF THE EXISTING
SYSTEM

The purpose of this chapter is to understand the existing U of K library


system so as to clarify the following points about the system:
• To understand how each job in the system is carried out,
• To find out overlapping or duplicated efforts in performing certain
jobs,
• To identify duplicate set of records in the existing system.
• To determine if the people are well trained and if they know how the
current system should operate,
• To identify the controls in the existing system; if there are very few
controls in the existing system, then there will be a need to improve the
system controls in certain areas in the new proposed system.

4.1 Historical Background Information on the Khartoum University


The present University of Khartoum was established in 1903 as the
Gordon Memorial College. The purpose of the College was to supply the
civil service with qualified junior personnel. It consisted of a primary
school, a training college, an institutional workshop, and a secondary
school. By the year 1940 the college became a center for higher
education consisting of the schools of Agriculture, Arts, law, Science
and Engineering, and Veterinary Science.
The Gordon Memorial College was upgraded to a university college in
special relationship with the University of London in 1947. In the same year,
the Kitchener School of medicine, which was established in 1924, was
incorporated into the University College.
The present University of Khartoum was created by the first parliament after
independence in 1956.The University of Khartoum Act was passed in 24
July 1956. Since then the university has continued to grow at the
undergraduate level as well as at the postgraduate level. Three postgraduate
degrees are offered by the various institutions; they include postgraduate
Diploma, Master of Arts (MA), Master of Science (MSc), Master of
Literature (M.Lit), Master of Law (LMM), and Doctorate of Philosophy
(PhD). The U of K now is composed of about 40 academic units including
faculties, schools, centers, and institutes. There are about 1300 teaching staff
members, 6000 postgraduate students and about 30,000 undergraduate
students registered for more than 300 academic programs.

4.2 Background Information on the University of Khartoum Library


System (UKLIS)
The University of Khartoum Library System (UKLIS) consists of the main
central library and six branch libraries. Three of these libraries are situated
on the main campus; they are the libraries of the Faculty of Engineering, the
library of the faculty of Law, and the library of the Faculty of Mathematical
Sciences. The other three branch libraries are on separate cites ranging from
2 to 20 Kilometers away. These are the Medical Library serving the faculties
of Medicine, dentistry, and Pharmacology, which is situated at about two
kilometers from the center. The second one is the faculty of Education
library, situated at about 20 kilometers form the center, and the third one is
the library of the faculties of Agriculture and Veterinary Sciences, which is
about 15 kilometers far from the center. Another branch of the University
library, situated within the main university campus, is the Sudan library,
which is intended to take care of materials about Sudan or written by
Sudanese. It also houses all theses written for Masters and Ph.D. degrees
done in Sudan or by Sudanese abroad. The Sudan Library enjoys the Legal
Deposit right, which entitles it to have three copies of whatever publication
written by any Sudanese no matter where that publication is written.
The University of Khartoum library services are under the management of
the university librarian. The library serves a total of more than 37,000
students and staff members, and estimated 10,000 users from other
institutions of higher learning. Students’ intake has been increasing steadily
during the period from 1956 – 1991. A major increase in the University
student intake occurred in 1991, under the new higher education policy in
the Sudan; the intake was doubled in that year especially in the faculties of
the humanities and social sciences. A major increase in the students’ intake
also took place in the other faculties. As mentioned earlier, the latest
statistics indicate that about 30,000 undergraduate students are registered for
more than 300 academic programs.
The main library’s collection services the information needs of the faculties
of Arts, economics and social studies, Sciences, and the school of
management and Business Studies, in spite of the fact that all these faculties
have departmental libraries. The Post of the University Librarian is
equivalent to a full professor. He is directly responsible to the Vice
Chancellor. The University Librarian is the Convenor of the Library
Committee, which is chaired by the Vice Chancellor. This committee has no
executive powers. There is a post of Deputy Librarian, a library registrar and
a number of five faculty or branch librarians, in addition to the three heads
of sections.
There are also a number of Assistant Librarians and Library Assistants.
Refer to Figure 4.2 (Management Structure Chart of the U of K Library
System) for more details about the posts in the library.

4.3 The Existing Library System Organization


There are four sections or subsystems within the university Main Library of
which only three departments constitute the scope of this study. The four
sections are:
i. The Acquisitions section which is responsible for the acquisition of
books and periodicals for the whole library system, including the
branch libraries. This section is also called the Book Orders Section.
ii. The catalogues Section, responsible for the classification and
cataloguing of books intended to be kept in the main library. Books
acquired for the branch libraries are classified and catalogued at their
respective libraries.
iii. The Reader Services Section (the circulation Section) that is
responsible for reference and borrowing activities both for books and
periodicals. This section also looks after reading rooms and all other
reading facilities and services.
iv. The Periodicals Section, responsible for handling, registering, and
keeping the serials in the main library.

4.3.1 The Area Under Study


As it has been mentioned earlier in chapter 1, this study deals with the
operations and functions at the departmental level of the University of
Khartoum Main Library system. It also deals with the flow of information
between the three core departments of the library system. These departments
are namely; the Acquisitions Section (the Book Orders Section), the
Catalogues Section, and the Reader Services (Circulations) Section.
According to Fitzgerald and Fitzgerald (1987), the departmental level is
level three of the organization. See figure 4.1 “ the Five Organizational
Levels that comprise the area under study”, as depicted by Fitzgerald and
Fitzgerald.

Figure 4.1 the Five Organizational Levels. Reproduced from Fitzgerald &
Fitzgerald, 1987.

4.3.1.1 Background of the Area Under Study


The U of K library services have been deteriorating steadily since the
beginning of the 1990’s. Radia Adam (1985) pointed out that the U of K
library system (UKLIS) is regarded as the best library system in Sudan.
According to her, the UKLIS stood out as an exceptional case regarding
libraries in Sudan. This is supported by the fact that all library experts who
visited the country at that time indicated the adequacy of the Khartoum
library system. Nevertheless, this bright picture of the U of K library system
has been changing ever since.
In her report about the UKLIS (1991), Carpenter outlined the following as
the major problems afflicting the University of Khartoum Library:
i. Lack of objectives, strategic planning and policies;
ii. Lack of user needs studies and lack of library use statistics;
iii. Problems of space;
iv. Most stock is out of date;
v. Poor storage and display facilities;
vi. The adoption of multiple classification schemes

throughout the library system.

McDonald (1994) in his report “ A Strategic Assessment of the University of


Khartoum Library” outlined the following as the major weaknesses of the
Library:

i. Shortage of qualified staff;

ii. Lack of space

iii. Lack of automation.

iv. Bad conditions for the staff.

v. Poor under standing of library role in the university.


vi. The implementation of more than one classification scheme
resulting in confusion.

vii. Poor means of communication within the library system.

viii. Poor ventilation.

ix. Weak cooperation with other libraries.

x. Lack of documentation services.

McDonald recommended the setting up of a strategic plan in order to


confront the above-mentioned weaknesses. In this regard, he stressed the
necessity of providing quality user services that should meet both user needs
and the university teaching and research requirements, and that user needs
should be assessed with a feed back mechanism to enlighten the library
management.

4.3.1.2 Automation in the Library

There is no automation at all in the area under study; all activities and
processes are carried out manually. Throughout the library system, there is
only little automation at the Medical library where the UNESCO’s software
for bibliographic databases (CDS/ISIS) is used for creating an electronic
catalogue of the library holdings. McDonald’s report (1994) highlights the
need of the Khartoum University library for a database or computerized
catalogue of all its holdings, which is not available at the Library up to the
present time. There is an ongoing project of networking the different
university campuses. This project, according to Shareef (2002), will provide
the university with an Intranet. This Intranet will include the intercampus
network, interfaculty network, and gate to the Internet. This project is also
intended to include an elibrary subproject, which according to Shareef will
provide library services such as library catalogues, CD-ROM services,
Online services and small database service.

4.3.2 Description of the Existing System Under Study

There are three subsystems covered by this study, namely;

i. The Acquisitions subsystem, also called (the Book Orders


Section)

ii. The Catalogues subsystem;

iii. The Circulation subsystem also called (the Reader Services


Section).

Each one of these subsystems is going to be analyzed in terms of the


activities performed. These activities are detailed in the description of the
inputs, processes and outputs of each subsystem. Charts and diagrams
combine the verbal description of these procedures. Refer to Figure 4.3 the “
Context Diagram of the U of K Library System” and Figure 4.4 “ Level 0
Data Flow Diagram of the U of K Library System” showing the area under
study of the U of k Library system.

4.3.2.1 The Acquisitions Subsystem


4.3.2.1.1 Functions of the System

The function of this subsystem in the library is to acquire library materials from
different sources and by a number of ways and means. These ways include the
following;

i. By purchase; there are a number of sources by which library


materials are selected before being purchased. These sources include
Books in Print catalogues and commercial publisher’s catalogues.
Refer to Figure 4.13a “IPO chart of Purchasing Process”.

ii. By donation

iii. By exchange, whereby the library has exchange programs with a


number of other university libraries.

The acquisition of books and periodicals is centralized in the main library.


This allows central control over the library materials budget. The
acquisitions Subsystem employs a number of forms to be used for the
process of selecting and purchasing books (See Appendix IV for all the
forms employed by the U of K Library System).

All acquired books are registered in the Accessions Register with each book
having a unique accession number. This register is a repository showing the
actual number of books holdings in the library, which is about 357,607 items
at the time of carrying out this study.

The major activities performed by the Acquisitions subsystem are the


following:
a. Receiving suggestions for procurement of books from faculty
departments.

b. Checking for requested materials and placing orders with


registered vendors or agents.

c. Accessioning acquired books.

d. Sending the procured materials to the cataloguing and


classification section for technical processing.

e. Maintenance of files and records of procurement.

f. Maintenance of expenditure details about books.

g. Compilation of exchange lists.

h. Supervision of exchange programs with other libraries.

4.3.2.1.2. Procedures for Acquiring Books

The library orders purchases of books directly from book suppliers either
locally or abroad. The acquisition of books follows the following procedure:

a. University academic staff fills Book Request Form.

b. Request forms are passed on to the head of the acquisitions


section.

c. Head of Acquisitions section verifies that the requested item is


not in stock or on order.
d. Request is passed on to the Chief Librarian for approval.

e. Approved request is sent back to the Acquisitions section.

f. Book order is prepared and sent to the book supplier.

g. A copy of the order form is kept in the Books-on-Order file.

h. After receiving the requested book, the copy of order is moved


form Books-on-Order file to Received-Books file.

i. Received book is registered in the Accessions Register with a


unique serial Accession Number.

j. The book is then transferred to the Cataloguing and


Classification section.

k. The requester of the book is informed that the book is available


now (after it is classified and catalogued).

These procedures are depicted graphically in Figure 4.5

“ Physical Data Flow Diagram of the Acquisitions Subsystem”, and


Figure 4.6 “Logical Data Flow Diagram of the Acquisitions
Subsystem.

4.3.2.1.3 Limitations of the Existing Acquisitions Subsystem


The head of the acquisitions Section highlighted in the interview with him
the following points as the major problems afflicting the work in his section;

a. Books are transferred from this section to other departments i.e. the
cataloguing section or other branch libraries, without being listed.
They are just carried away, with no attached document showing their
titles, number, etc.

b. Lack of computers and automation in the section; all work is done


manually.

c. Lack of a separate budget for the section.

4.3.2.2 The Catalogues Subsystems

This section is responsible for carrying out the major technical processes that
library materials must undergo before being accessible to users. The
technical services of cataloguing and classifying books are decentralized.
Books intended to be used in the main library are processed at the main
library’s section of cataloguing and classification; whereas processing of
library materials of branch and departmental libraries are carried out in their
respective libraries. This caused the problem of the existence of more than
one classification scheme throughout the library system. In fact there are
four different classification schemes implemented throughout the library
system; these are namely; The Dewey Decimal Classification Scheme
(DDC) and the Bliss Bibliographic Classification Scheme (BBC) in the
main library; the Colon classification scheme in the Shambat Library, and
the Library of Congress Medical Classification Scheme in the medical
library. According to the Carpenter report (1991), the existence of these four
different schemes is one of the obstacles that hinder the development of new
comprehensive centralized services and processes. MacDonalad (1994)
called for the centralization of library services all over the university in lieu
of the existing disarray of libraries and departmental libraries within the
university. McDonald’s report also drew attention to the fact that the main
library’s Acquisitions section and the technical services section are relatively
far from each other, raising questions about communication between these
sections, and the efficiency and security within these sections. He further
proposed the centralization of technical support services (the cataloguing
and classification services) throughout the library system.

The library maintains three types of catalogues; Author Catalogue, Subject


Index, and Classified index, all compiled according to the international
standards. As for the catalogue formats used; there are two different formats
in use now; the old out of date sheaf catalogue format and the more familiar
card catalogue format that was implemented as a realization of one of
Carpenter’s report recommendations. This latter catalogue format is being
used only for the newly acquired materials. Refer to Figure 4.13b “IPO
Chart of cataloguing and Classifying Books”.

4.3.2.2.1 Activities of the Cataloguing and Classification Section

The following activities are carried out in this section:

a. Cataloguing the book following the Anglo-American Cataloguing


Rules, second edition (AACR2). This is done by extracting the major
bibliographical data that describe the book. Major bibliographic data
include the following items:

• Author statement, including editors, revisers, translators, etc.

• Title, including subtitles

• Edition,

• Place of publication, publisher, and date of publication,

• Series statement,

• International Standard Book Number (ISBN),

• Price.

b. Classifying the item according to the Dewey Decimal


Classification Scheme (DDC). Implementation of the DDC in the U
of K library is a realization of one of the recommendations of the
Carpenter report as mentioned earlier. Previously, the library used to
classify according to the Bliss Bibliographic Classification Scheme.

c. Assigning a call number for the catalogued item with the help
of the Dewey decimal classification Scheme DDC and authority file.

d. Pasting the spine of the book and noting the call No. on the
spine label.

e. Preparing temporary catalogue cards to be used by the staff of


the circulation subsystem because there was always time lag before
the final catalogue cards are typed.
f. Preparing library catalogue cards; author, subject and classified
catalogue cards for each processed item.

g. Sending the processed books to the Reader Services


Department (the Circulation Section).

h. Sending reminders to staff members who have requested some


of the processed items.

i. Transferring catalogue cards to the Reader Services


Department, where they are kept in their respective catalogue boxes.

The above activities are depicted graphically in figure 4.7 “ Physical DFD
of the Catalogues subsystem”, and in figure 4.8 “Logical DFD of the
cataloguing subsystem”.

4.3.2.2.2 Limitations of the Existing Cataloguing Subsystem

In the interview with the Head of the cataloguing system, he pointed out the
following difficulties of the existing system:

a. The manual filing of the catalogue cards, which is a

time- consuming operation.

b. Absence of links with catalogues of other institutions, especially


universities, whether locally or internationally.

c. There is no union catalogue of the whole university library system


including the Branch libraries.
d. There is a problem of space for the catalogue cabinets, as the library
collection is growing steadily.

4.3.2.3 The Circulation Subsystem (The Reader Services Section)

As for the Circulation Services, loan of books and journals back issues is
restricted to academic staff, researchers and postgraduates students. For the
purpose of keeping loan records, two slips are used by the system; one slip
holds the details of the borrowed item. This is filed under the accession
number of the item, whereas the other slip is filed with data items about the
borrower, and filed under the name of the borrower. Refer to Figure 4.13c
“IPO Chart of the Lending Process”.

4.3.2.3.1 Procedures in the Circulation Subsystem

The procedures below are depicted graphically in figure 4.9 ‘Physical DFD
of the Circulation Subsystem”

a. Requests for spot reading are received from students.

b. Requests for borrowing are received from staff members.

c. Borrower's data is checked against the borrowers’ file before loans are
granted.
d. Catalogues are consulted for call numbers.

e. Books are issued to borrowers.

4.3.2.3.2. Limitations of the Existing Circulation Subsystem

The Head of the Circulation system outlined the following as the major
problems afflicting his section:

a. It is not possible to detect those borrowers who do not abide by the


borrowing regulations, and hence take appropriate action.

b. It is not possible to tell how many items a specific reader has out at
any one time,

c. The act of filing the issue every day is very time consuming, and
mistakes might be made.

d. There is no way of telling how many times a book has been


borrowed without checking the date label, if there is any.

e. There is no standard overdue notice form to deal with delays, not


returned books and lost books.

f. There is a need for bar coding to facilitate the circulation process and
enhance security in the library.

The existing circulation system is in need of an effective way to collect


essential information for the library management. The system needs the
following:
a. Statistical loan analysis on a periodical basis whether by day, month,
term or year.

b. Statistical loan analysis by classification number, department, status,


and faculty.

c. Lists of overdue books,

d. Lists of reservations,

e. Lists of blacklisted users.

f. List of books out of circulation for some reason. (e.g. binding, repair,
missing…etc.).

g. Lists of reserved books awaiting collection,

4.4. Additional Limitations of the Existing Library Manual

System

4.4.1 Technical Limitations

All the forms used by the U of K library system to carry out the functions
and procedures described above are collected and analyzed in the course of
this study. (Refer to Appendix II for samples of the forms and documents
used by the U of K library system). After the analysis of these forms, it has
become apparent that there is a considerable degree of duplication of data
items within these forms. i.e. there is a repetition of certain data elements in
a number of records such as the repetition of the elements of Author name,
Publisher, Price. etc. Refer to figure 4.11 “Document / Data Item Grid”
which shows the duplication of data items in the different documents used
by the U of K Library System.

Another limitation of the existing manual system is that there are a large
number of different records for an item, although as mentioned above, these
records share some bibliographic data elements.

4.4.2 Non-Technical Limitations

There are other non-technical limitations that affect the well functioning of
the existing library system. These are arrived at in the course of observing
the system in action and interviewing the Heads of the library sections under
study. These limitations include the following:

a. The library does not have a budget of its own. It depends largely on
intermittent allocation of funds from the vice-chancellor.

b. The proposed organizational structure of the library system is not


implemented. Refer to Figure 4.12 “ Proposed Organization Structure
of the U of K Library System”. For example, there is no “Council of
Libraries “, and that the post of the University Librarian is still under
the name of “Librarian” and not “ Dean of Libraries” as suggested by
the proposed organization structure. There are some other changes
recommended by the proposed structure, such as the following:
• The creation of three posts parallel to the post of the Chief Librarian of
the Central Library; these are the Heads of Branch Libraries, Sudan
Library, and the Technical Section.

• The amalgamation of the three library departments of Acquisitions,


cataloguing, and serials under the umbrella of the Department of
Technical Services.

4.5 Documentation of the Findings of the Existing U of K Library


System

The following pages depict the existing library system by using standard
tools and techniques of systems analysis and design. They include the
following tools:

i. Data Flow diagrams (DFDs); on pages 69-76

ii. Document /Data item Grid; on pages 77-78

iii. IPO Diagrams; on pages 80-82;

iv. The data dictionary; on pages 83-88


CHAPTER FIVE

SPECIFIC REQUIREMENTS DEFINITION

This chapter deals with the new proposed computer –based library system

requirements i.e. what the new system must do. The specific requirements of

the new system will be defined broadly in order to cover the details of the new

system. These requirements are arrived at after reviewing the data collected

during the analysis of the existing system. The investigation of the existing

system showed what the users of the U of K library system want from their

system to do for them. These specific requirements will be defined in terms of

the following aspects:

1. Outputs that the system must produce,

2. Inputs that the system needs in order to produce the outputs,

3. Operations and processes that the system must perform in order to produce

the outputs.

4. Resources that the system must use in order to produce the outputs.

There are some other important aspects that will be taken into

consideration when defining the new system requirements. These aspects

include the following:


i. The type of files the system is going to use,

ii. The type of database the system is going to use,

iii. The type of system that is going to be implemented, i.e.

integrated versus non-integrated systems.

5.1 The System Files

The library system is going to use a number of files in order to deal with

the different aspects of the library work. These file s are:

5.1.1 Title File

The purpose of this file is to hold details of the different types of materials in
the library collection, especially the books, so as to carry out the following
jobs:
i. to determine whether to purchase a book title or not;
ii. to generate a book order and send it to a specific publisher so as
to acquire the book;
iii. to contain bibliographic details of the book that can be used as
access points to retrieve the specific book title;
iv. to allow for the issuance of a specific title to library users;
v. to tell the state of the book as to its circulation i.e. whether it is in
stock, borrowed, on the reserve list, lost, etc.

5.1.2 Borrower File


This file maintains necessary data about the library users. It includes such data as user
names, their faculties and departments, their academic specializations, interests and so on.
The majority of the information about users will be derived from the university registry
system, with added details that are associated with the library system. Details of Borrowers
who are not students in the U of K will have to be entered manually into the user file. This
file will retain the following details about the circulation activities in the library:
i. Details of the number of books issued out of the library at any
moment in comparison with the total number allowed.
ii. The reservations that have been made by the library users;
iii. Details about overdue books to be used to issue overdue notices.
iv. Details of books that have been reserved by some users to be
compared with details of returned books so as to issue availability
notices for books on reserve.
5.1.3 Subject File
This file has the function of controlling terms used to retrieve catalogue records, and terms
used to determine the subject of a book so as to be classified. This file should contain a
thesaurus.

5.1.4 Vendor File


This file contains all the necessary data about the vendors that the U of K
library is dealing with. It includes data items such as vendor name, vendor
address, orders from this vendor, and remittances to this vendor. etc.

5.1.5 Budget File


This file holds details of the acquisition budget allocated to different faculties
of the university. This file contains such details as the proposed budget, the
utilized on order budget, and the utilized paid out budget.
5.1.6 Payment File
This file is composed of two parts: the order part and the payment part. The order part is
generated when an order is made out and order details are entered into it to go to the title
file, and to record the payment information. The payment part is used to account for all
purchases to the library. The transactions file forms the basis of the budget allocation and for
producing exception reports showing which budgets are likely to overrun and which have
actually overrun so that the file can be properly updated.

5.1.7 Statistical File


This file has the function of handling statistics about the library use. It is
mainly concerned with the work of the circulation subsystem.

5.2 Type of System to be implemented


It is believed that an integrated library system is the best choice for the many
benefits and advantages of integrated systems.
Lapota, (1995) defines an integrated library system as an automated system in
which all of the functional modules – acquisitions, circulation, cataloguing, and
OPAC – have a common bibliographic database. She further outlines the
following advantages of integrated systems over non-integrated systems:
i. There is no duplication of efforts to create and maintain multiple
copies of bibliographic records, because there is one bibliographic
record for each library item for all transactions.
ii. There are minimum chances of making mistakes while entering data
on records because they are entered only once, and modifications to
records are automatically carried out throughout the system.
iii. Library staff and users can access all types of information at one
location.
5.3 Outputs, Inputs, and Processes

The outputs, inputs, and processes of the new proposed system will be dealt with from the
viewpoint of each of the subsystems that constitute the proposed system, namely the
Acquisitions subsystem, the Cataloguing subsystem, and the Circulation subsystem. A
general requirement of the way of inputting data to the proposed library system is that it
should be an on-line system. This aspect is particularly needed in the circulation subsystem.

5.3.1 The Acquisitions Subsystem


This subsystem is responsible for acquiring new books for the library either by
purchasing them, exchanging them with other libraries, or receiving them free
of charge as gifts and donations from individuals, other libraries or other types
of institutions. In order to be able to carry out this job effectively and
efficiently, this subsystem must have the following specific outputs, inputs, and
should perform the operations and processes defined below:

5.3.1.1 Outputs
The outputs of this subsystem should include the following:
i. Book orders to be sent to booksellers and / or agents, via email.
ii. a list of items on order organized by author, department, or subject
iii. Lists of new accessions,
iv. Reminders to be sent to booksellers and agents for delayed orders.
v. Notification of users when an item recommended by them have been
received,
v. Production of statistical reports that will assist the library management on
decision-making.

5.3.1.2 Inputs
The inputs should cover the following aspects:
i. New book orders,
ii. Amendments to existing orders
iii. Booksellers reports,
iv. Acknowledgements of the receipt of items by the library.
5.3.1.2 Processes and Operations
i. The major process of this ordering subsystem is to deal with new orders and send the appropriate form to the book supplier.

ii. checking of the date of order to decide whether there is a need to send a
reminder to the supplier,
iii. editing of the order record after receiving the item and adding it to the
catalogue file. This process is useful only in the type of integrated system that
is recommended in this study.
The ordering subsystem should be able to incorporate and deal with records
structured in the MARC format and the Dublin core set of metadata elements.
This subsystem should also be compatible with Z39.50 protocol. This latter
compatibility will facilitate the process of acquiring the bibliographic data
items of books from databases available online on the Internet.

5.3.2 The Cataloguing Subsystem


This system is envisaged to be an online system with full facilities of key to
disk entry.
5.3.2.1 Outputs
The main output of this subsystem is the library catalogue which can be in a
number of formats. One of these forms is the catalogue card produced by the
computer. These cards, according to Ted (1993), have the following
advantages:
i. The computer-produced catalogue is easily merged with the manual
catalogue, thus saving searching time.
ii. no need for cumulative files.

On the other hand, this type of catalogue has the following disadvantages:
i. cards have to be filed, which may lead to misfiling,
ii. no saving of space is achieved; it will take the same space that is taken by
the traditional card catalogue.

One of the important outputs of the cataloguing subsystem is the OPAC


(Open Public Access Catalogue), which is basically an interface between the
library users and the integrated database of the library system.
5.3.2.2 Inputs
1. Bibliographic details of books held by the library.
In the integrated library system recommended these details come from the
acquisitions subsystem file. Therefore they should be checked and amended by
adding such details as classification number, call number, and subject
headings. etc.
5.3.2.3 Processes
The processing mode of the cataloguing subsystem should be on-line. The
newly added catalogue records are processed individually one at a time,
checked, edited, and incorporated into the master file. The main processes
carried out by this subsystem are;
1. Checking the accuracy of newly entered records. The bibliographic data
required for the cataloguing process should be detailed and accurate according
to the cataloguing rules and codes followed by the library. This check should
be controlled by the following:

i. The data items that should be included in the record?


ii. The record structure form that is used by the system i.e. fixed
length or variable length record.
iii. The metadata protocols used by the system i.e. the Dublin
core or the Z39.50 communication protocol.
2. The catalogue subsystem should also be able to carry out the following jobs:
i. To provide access to the complete and up to date library
catalogue from a number of access points.
ii. To provide more and improve access points and search
capabilities,
iii. To provide the opportunities of resource sharing through
national and regional union catalogues.
iv. To get rid of some of the inherent problems of manually
produced library catalogue, such a manual card filing.etc..

5.3.3 The Circulation Subsystem


The main function of this subsystem is to control circulation activities of the
library, especially the activity of lending and borrowing of library materials.
5.3.3.1 Outputs
i. Production of overdue notices,
ii. Production of lists of overborrwoing. The system should
check that the borrower is within the limits allowed whenever
a book is issued to him/her. There should be immediate
notice from the system if the user tries to take books which
exceed the limits.
iii. Updated loan file.
iv. Calculation of fines against those users who delay borrowed
materials.
v. Detection of users who do not abide by the library regulations
at the point of issuing borrowed material.
vi. Statistical report of library use over specified periods of time.

5.3.3.2 Inputs
i. Book Code: each book of the library holdings needs to be
defined uniquely, so a code number should be associated with each book.
This code may take one of the following forms:
- Accession number
- ISBN (International Standard Book Number) which is
unique for a title, not a copy.
- Title number and copy number

11. Borrower Code: As in the case of books, every member of the university
community who has the right to borrow books should have a unique
identifying code. This code could be obtained from the faculty or
department registry so that codes already allocated to different university
members are used.

5.3.3 Processes
The basic function of the circulation system is the recording of details about items on loan
and the linking of these details with the user who borrowed the item. Therefore the system
should carry out the following functions:
i. Link book, borrower and date information rapidly and accurately,
ii. Enable rapid and easy consultation of the issue files,
iii. Prepare overdue notices,
iv. Signal over-borrowing and prepare lists of books on loan to individual
borrowers,
v. Detect problem borrowers at point of issue,
vi. Enable rapid updating of the loans file and calculation of fines on return.
vii. Facilitate collection of statistics on the system.

5.4 System Resources


5.4.1 Local Area Network. There is a need for a Local Area Network (LAN) within the
library building so that the different subsystems of the library can be linked together. This
network will facilitate the carrying out of the different library functions and activities by the
proposed computer-based library system. The hardware technical specification should be
based on the most recent available standard hardware in the market . This will guarantee that
the proposed library system will not face any hardware problems. It is also true that
computer hardware prices are declining steadily while the technical specifications are
getting more and more sophisticated.

5.4.2 Input Method and Devices


5.4.2.1 Input Method
The input method of the proposed computer-based library system is the on-line method. This
method involves the capturing of data at its point of origin in the library and the inputting of
that data into the computer. This method is appropriate for some of the library’s activities,
particularly in the circulation subsystem. The display monitor is the online medium for
inputting data. The online system includes a monitor screen and a keyboard that are directly
connected to a computer system.
5.4.2.2 Input Devices
Input devices have the function of bringing data to the computer’s CPU for processing. The
devices to be used in the proposed computer-based library system include the following:
• Keyboards which are usually used in conjunction with a screen on which data
is displayed.
• Bar code readers. Bar codes are used as a code to identify a library items by
means of a bar code reader. These in turn are linked to a computer and the
transaction data is cumulated and analyzed to provide management
information.
• Scanners to input texts of pages including drawings and photographs.

Other input and data capture devices include mouse, magnetic tapes and disks and optical
disks (CDs).

5.4.3 Output devices


• Printers. The following characteristics should be considered in their
selection: speed, quality of output, range of type fonts available, noise
levels, option to produce multiple copies, cost of purchase, cost of
operation.
• Monitors. Color monitors are more suitable because many library
software use color to emphasize their graphical features like menus and
status bars, etc.
• Computer Output Microform (COM). This is needed to output library
catalogues and indexes. A reader is necessary to access the information on
a COM.

5.5 The Database


The library system database will be mainly of a bibliographic type, which will incorporate
the library catalogue database. This database contains a series of linked bibliographic
records with each record containing a number of fields that describe an entity (a book, a
borrower, etc.). each record will include some combination of the following fields: title,
author, call number, ISBN, abstract, ID number, keywords …etc (for the detailed list of
records and fields see Chapter seven “Database Design”. A catalogue and OPAC database
for the University of Khartoum Library System is described and designed in chapter seven
of this study. This database description, together with the detailed functional specifications
outlined in the following chapter, will act as a basis for the Request For Proposal to be
written by the University of Khartoum Library for the selection of an appropriate Integrated
Library Management System.
The database structure recommended to be used in the University of Khartoum Library
system database is the relational structure rather than the two other main structures, i.e. the
hierarchical and the network structure. The reason for this is explained in chapter seven of
this study “Database Design”.
The MARC “Machine Readable Catalogue” format is to be the standard record format for
the system’s database. This format will facilitate the exchange and download of catalogue
records from other libraries’ catalogues into the U of K Library catalogue database. This
standard record format which is used widely in catalogue databases complies with ISO
2709, the standard for bibliographic interchange on magnetic tape. The MARC format is
also compatible with the second edition of the Anglo-American Cataloguing Rules
(AACR2), and the twentieth edition of the Dewey Decimal Classification Scheme (DDC),
both of which are employed by the University of Khartoum Library system.
McCallum (2000) notes that there were three major reasons for developing the MARC
format:
• To efficiently accommodate variable length data;
• To enable easy selection of subsets of data elements; and
• To provide sufficient semantics (parsing and markup) to support data
element identification that would open up many possibilities for retrieval,
internal system record configurations, and data manipulation.
MacCallum further asserts that the MARC format can be used to describe the Internet
resources, and that it has kept up with developments in this area.
5.6 Connectivity to the Internet and Interoperability
The system should be an open system, client-server system. It should also be able to work
across a wide area network and should be Internet accessible.

The Open Public Access Catalogue (OPAC) of the University of Khartoum Library System
is envisaged to be incorporating a Z39.50 standard. This is an international standard for
communication between computer systems, primarily library and information related
systems. It is expected in the very near future that library services will be Z39.50 enabled.
The effect of Z39.50 on the OPAC is that it enables access of any or all of the world’s major
library catalogues or just the local sources with a single search. There are two elements to
Z39.50: the client and the server: each library that wishes to publish its catalogue must have
the Z39.50 server running. Any end user wishing to search various catalogues must then run
a client and tell it where to find the various catalogues that they would like to search.
The proposed system is thus expected to be able to access and handle the electronic and
digital resources available an the internet. Baker (2002), stresses that digital resources are
important fro researchers, teachers and students, both in and off-campus. He outlines the
following benefits of digital resources:
i) Effectiveness: each search result can generate ideas for a subsequent search. They
may also contain direct links to related material on the World Wide Web.
iii) Convenience: searchers can access these digital resources any where
at any time, with a computer connected to a local area network or the
Internet.
iv) Concurrency: many users can have simultaneous access to the same
resource.
v) Space: electronic resources do not require storage space and shelving.

The system should be interoperable. the SearchWeb Services.com defines


interoperability as " the ability of a system or a product to work with other
systems or products without special effort on the part of the (user). "
Miller (2000) provides a broader definiton for interoperability; He states that "to be
interoperable, one should actively be engaged in the ongoing process of ensuring that the
systems, procedures and culture of an organization are managed in such a way as to
maximize opportunities for exchange and re-use of information whether internally or
externally."

On the need for systems’ interoperability, Baker (2002) stresses that “the (user) should be
able to search across and retrieve resources from a wealth of confronting systems, gaining
access to maps, full-text content, census data, images and video, and more increasingly,
users will expect the resources with which they deal to be available in this interoperable
fashion”, Baker (2002).
The Z39.50 Protocol, together with the Dublin Core Metadata Initiative, is a valuable tool in
linking and discovering distributed resources, hence acting as a tool for systems
interoperability. Chapter Eight of this research provides more details on the Z39.50 and the
Dublin Core Metadata Initiative.
CHAPTER SIX
DETAILED FUNCTIONAL SPECIFICATIONS OF THE PROPOSED INTEGRATED
LIBRARY MANAGEMENT SYSTEM

This chapter outlines in detail the functional specifications of the proposed Integrated Library
Management System. These functional specifications are intended to be used as a basis for a
Request For Proposal (RFP). This RFP is to be written by the University of Khartoum Library
administration to library systems suppliers and vendors so that they may supply the library with a
suitable and appropriate system to satisfy its needs and requirements.
The detailed specifications below cover a wide range of functions that are envisaged to be carried
out by the three core subsystems of the University of Khartoum Library, namely the Acquisitions
subsystem, the Cataloguing subsystem (including the OPAC interface), and the Circulations
subsystem.
It has been taken into consideration that the functional specifications of the proposed system
comply with the international standards in the field of library and information work; as Hodgson
(2002) put it:
“ Librarians have recognized and supported, long before the dawn of computers, the need
for standards to aid in collection management, share resources with other libraries, and improve
access for library patrons. The widespread use of Integrated Library Systems (ILS), global
communications via the Internet, and growing numbers of digital library initiatives have made the
need for compliance with standards more critical than ever” Hodgson (2002, 9).

The computer-based Integrated Library Management System (ILMS) is also envisaged to be


interoperable with the Internet and other systems, flexible, and user friendly.
The Functional Specifications outlined below are based mainly on the outcome of the U of K
Llibrary system analysis. Nevertheless, the researcher has made use of two documents to help in
the organization and layout of the functional specifications. These documents are the Request for
Proposal for an integrated library system prepered by the State University of New York , and the
Request for Information produced by the Alabama University Library.
The functional specifications are categorized under four main categories, each of which is divided
into a number of subdivisions. The four main categories are:
6.1 Acquisitions Control;
6.2 Cataloguing and Database Maintenance;
6.3 OPAC; and
6.4 Circulation

6.1 Acquisitions Control


6.1.1 General
The Acquisitions module of the proposed library management system should:
1. be fully integrated with all modules.
2. have records that are retrievable using any indexed field as defined by
the U of K library.
3. have no limits on number of order records associated with a title.
4. support the basic functions associated with acquiring and processing all
kinds of monographs, including, but not limited to:
- order record creation
- receipt
- claiming
- cancellation
- vendor report tracking
- payment
- MARC holdings
- fund accounting
5. accommodate the following order types, including, but not limited to:
- prepayment
- gift
- standing order
- subscription
- continuation
6. store acquisitions data, including, but not limited to:
- bibliographic data
- order type
- order status
- location / copy information
- invoice information
- vendor information
- vendor report information
- fund accounting information
- notes to vendor
- notes to cataloging
- notes to acquisitions
- order notes (source/requester)
- a minimum of four library- defined fields
7. provide a complementary capability to set default values and session
preferences.
8. allow retention of order data for as long as the library desires.
9. allow archiving of order data.
10. provide a variety of order statuses, including, but not limited to:
- in pre-order process
- on order
- claimed
- received but not paid
- partially received
- currently received
- completed
- cancelled
11. have a fund structure of at least four levels of hierarchy that is
updated dynamically, and includes, but is not limited to:
- amount appropriated
- amount encumbered
- amount expended
- uncommitted balance
- cash balance
12. have a fund structure flexible enough to identify separately such extra
charges as postage, bank charges, surcharges, and rush charges among
the items in a flexible way.
13. have a dynamic link of acquisition records to OPAC.
14. provide the ability to block bibliographic and/or order records from
public view.
15. provide the ability to assign unique location code for each copy of
title if desired.
16. include basic word processing features.
17. provide free text note fields of unlimited length, including, but not
limited to:
- notes to vendor
- notes to acquisitions department
- general notes
18. provide the ability to delete duplicate records or those created in error.
19. provide the ability to get on-line help in staff mode.

6.1.2 Pre-order Searching and Verification


The system should:
1. provide the ability to check bibliographic records to the database for
duplication using ISBN, or some other match point of the University
of Khartoum library’s choice.
2. differentiate between types of orders (particularly standing orders) in
the index display.

6.1.3 Ordering and Order Maintenance.


The system should:
1. link order to bibliographic information.
2. allow one purchase order number for each title.
3. automatically and immediately update appropriate fund records when
orders are placed.
4. facilitate both ordering by defaulting to user-defined values in fields
such as vendor and fund.
5. prevent duplicate assignment of purchase order numbers, whether
automatically generated or manually input, unless specifically
requested.
6. support on-line creation of order records with multiple access points.
7. support record import from a bibliographic utility or resource file.
8. allow multi-fund encumbrances.
9. sort printed purchase orders by vendor, or other library-assigned fields.
10. allow a second printing or re-send of purchase orders.
11. support foreign currency encumbrance and printing.
12. maintain distinct order date.
13. support production of paper orders, claims, cancellations, reports, and
invoices.
14. support the transmission of orders, claims, cancellations, reports, and
invoices using electronic data interchange (EDI) in accordance with
current electronic means.
15. provide a mechanism (highlighted text or an audible beep) to alert
receipt staff to special processing instructions.
16. display complete payment history including line notes.
17. permit changes to all order types and statuses including cancel and
ceased.
18. be able to create pseudo orders that do not print and that can be
changed back and forth between real and pseudo orders.
19. allow for the suppression of order printing.

6.1.4 Receipts
The system should:
1. support predictive check in for materials based on pattern records that
can be either keyed in locally or imported from an outside source.
2. allow staff to override automatically predicted issues/volumes if an
unexpected item is received (i.e. combined issue, supplements,
directory issues, etc) without having to edit pattern.
3. allow quick and easy receipt with a minimum of keystrokes or carriage
returns.
4. automatically change firm order status from “ on order” to “ in
process” upon receipt.
5. display all call number, location, and routing information at the point
of receipt.
6. permit free-text description of issues that deviate from established
patterns of enumeration/chronology.
7. allow a link to bibliographic, order, and holdings records during check
in to resolve problems that occur during receipt.
8. maintain distinct data of receipt.
9. provide an easy way to force or suppress display of current receipts;
10. provide ability to produce a variety of receipt tickets by email.
11. allow the operator to set a date other than today’s as the receipt date.
12. alert the operator to possible duplicate issues, gaps in receipt, etc.
13. support production of a call number label at time of receipt.

6.1.5 Claiming
the system should:
1. not automatically produce claims unless the library desires this.
2. allow for claim cycle overrides on an individual order basis.
3. provide a printed report of titles to be claimed.
4. provide flexibility in the management of claiming intervals with
default claim intervals by frequency and the ability to override and
change these values if authorized.
5. provide claim history information for every title.
6. provide room for extensive claiming notes.
7. produce claims that include the purchase order number.
8. automatically close or clear open claims upon receipt.
9. support electronic claims with the vendors.
10. alert the operator (by audible beep and on claim report) if a volume is
received that is beyond the range of the expected volume.

6.1.6 Payment and Fund Accounting


The system should:
1. automatically update encumbrances, expenditures, and balances when
payments are made.
2. support straightforward processing of invoices with real-time updating
of fund records.
3. allow new accounts to be created at any time.
4. allow existing accounts to be updated at any time.
5. allow an unlimited number of funds.
6. allow for encumbrances to be split across funds.
7. provide various end-of-fiscal-year options, which may vary from fund
to fund.
8. support the ability to search invoice records by order number, vendor
invoice number, vendor and by other library determined access points;
results should be sorted based on operators options.
9. support electronic transfer of invoice data via EDI, magnetic disk, etc.
10. track fund records on-line with all balances and expenditures
available immediately and provide a full audit trail.
11. provide the ability to print out ledgers of invoices posted for a given
period of time.
12. provide the ability to accommodate different currencies and figure
exchange rates.
13. allow authorized staff to delete payment lines and entire invoice
records even after the invoice has been authorized for payment.
14. allow an authorized staff member to alter invoice data after record is
approved.

6.1.7 Vendor File


The system should:
1. support an unlimited number of separate vendor record files.
2. incorporate a vendor file which makes provision for adding an
unlimited number of records incorporating vendor names and
including an unlimited number of both order and remittance
address.
3. be updated in real-time to maintain the currency of all vendor
records and statistics.
4. provide a formatted screen with appropriate prompts for entry of
vendor file data.
5. be able to print the entire contents of the vendor name/ address file.
6. provide vendor file accessibility, including, but not limited to:
- vendor name
- vendor code
- keyword search for vendor name
7. support vendor records that include, but are not limited to, the
following information:
- vendor name
- vendor addresses (the number to be determined by the U of K
Library)
- vendor phone, fax, e-mail, ID numbers, notes
- library-supplied vendor claim period indicator
- vendor performance statistics
- discount information by vendor
8. support cumulative vendor statistics for the current and closed fiscal
years, including, but not limited to:
- average receipt period in days
- number of claims sent
- number of copies cancelled
- total amount ordered
- amount encumbered
- amount invoiced

6.2 Cataloguing and Database Maintenance


6.2.1 General
The cataloguing module of the proposed library system should:
1. indicate the existence of other, related records to staff, i.e whether a
title has a bibliographic record, an order record, .. etc and associate
these records with each other.
2. automatically enter enough “brief” identifying information form
bibliographic record in related records without staff having to retype
it.
3. support the automatic update of “brief” title information in all related
records when a change is made to the bibliographic record.
4. support easy movement among all modules (functions).
5. support individual user access to all authorized functions with one
secured logon.
6. support standard statuses (such as in processing, available, etc.) and the
ability for the U of K library to define additional statuses.
7. allow true physical deletion of bibliographic and authority records.
8. block record deletion if a connection to another record is present, for
example, a circulating item.
9. support a spell check function.
10. support record purges by library defined parameters.
11. support the ability to delete and undelete records (before they are
physically purged from the system).
12. support the ability to search authority-controlled identifiers that can
be both system generated, based on data in the fixed and variable
fields of the bibliographic record, and added by library staff at any
time. Examples include internet resource, periodicals, microform,
reference, and various special collections. This functionality, called
document types, is currently supported by the multi LIS system.

6.2.2 Standards
The system should:
1. support full compliance with the MARC format for bibliographic data.
2. support MARC repeatable fields, tags, subfield codes, indicators.

3. allow and display all current and former MARC fields, tags, subfield
codes, indictors and delimiters
4. impose no limits on the record length, or subfield length (other than
those consistent with MARC). If any such limits do exist, they should
be library defined.
5. allow acceptance of brief or incomplete bibliographic records, most
likely created at the ordering stage.
6. generate clear and context-specific error messages for invalid use of
fields, tags, subfield codes, indicators, and delimiters.
7. allow cataloger-determined order of tags within a level of tagging
(4XX, 5XX, 6XX, 7XX).
8. accommodate future changes in the MARC authority/bibliographic/
holdings formats or new format standards as they are developed.

6.2.3 Import and Export


The system should:
1. support the dynamic transfer of bibliographic and authority records
from vendor files, CD-ROMs, and other available technology.
2. support the transfer of bibliographic and authority records into the
system by File Transfer Protocol (FTP).
3. allow batch loading of such records without interrupting other system
use.
4. support output of bibliographic, authority and files in MARC format.
5. support the overlay of existing bibliographic and authority records.
6. allow the library to define fields which will generate an overlay
without programmer intervention.
7. prevent protection of specific information in the overlay without
programmer intervention.
8. allow protection of specified fields on an existing bibliographic or
authority record when that record is being overlaid by another record.

6.2.4 Indexing
the system should:
1. supports dynamic indexing of all MARC fields.
2. allow indexing down to the indicator and subfield levels
3. support the dynamic indexing of keyword for all the above fields,
subfields, and indicators.
4. support keyword access to specified fields in staff mode.
5. allow the library to configure, as a default, the maximum number of
records that could be retrieved by search.
6. supports integration of series into title index.
7. support detection of duplicate records.
8. allow for search indexes to be defined by the library.
9. allow indexing of brief or incomplete records.
10. allow manual update, overlay, and/or batch overlay of bibliographic
data on records with attached items checked out.
11. support dynamic suppression/masking of bibliographic records and all
associated records.
12. support dynamic reversal of the suppression/masking of records.
13. impose no limits on the number of indexed fields for a single
bibliographic, authority, or holdings record.

6.2.5 Call Numbers


The system should:

1. support separate indexing of various classification schemes, including,


but not limited to:
- Dewey Decimal Classification Scheme
- Bliss Bibliographic Scheme
- The Colon Classification Scheme
- local
2. return a range for call number searches.
3. return an appropriate surrounding range of call numbers in an actual
shelflist if base call number is unused.
4. support a “true” shelflist ,in other words, support an index presentation
in call number order containing brief main entry and/or title
information to allow easy shelflisting of new titles.

6.2.6 Printing and Data entry


The system should:
1. support screen printing and printing of specific screen elements which
can be defined by the University of Khartoum library.
2. support full bibliographic and authority record printing.
3. supply full and current system documentation in print form.
4. supply full and current system documentation in online form.
5. provide formatted templates and default values for online data entry.
6. support the explosion of fixed fields into mnemonically tagged fields
for ease of data entry and editing.
7. support copying/deriving a bibliographic or authority record to create a
new record.
8. allow easy insertion of tags and data into their proper positions in the
MARC record.

9. support full screen editing.


10. support word processing capabilities.
11. support “cut and paste” from one record to another (from both local
databases and outside sources).
12. support accurate “cut and paste” of diacritics.

6.2.7 Authorities
The system should:
1. allow an authority record for each authorized heading.
2. support full compliance with the MARC format for authorities data.
3. allow all MARC format for authorities data field tags, subfield codes,
indicators, and delimiters in authority records.
4. support one authority record for occurrence of a heading in various
indexes.
5. support input of local authority records and/or local authority files.
6. support the dynamic indexing of authority records.
7. support separate indexes for multiple thesauri, such as Library of
Congress Subject Headings List (LCSH) and the Medical Subject
Headings List (MeSH).
8. allow for local notes in authority records.
9. permit existing and new authority records to automatically create
“see”, “see also” and “explanatory/scope references” in both OPAC
and staff modes.
1 0. allow authority heading, for example, series-like phrase and base
conference heading authority records.
11. support global update functionality for headings, subdivisions, and
strings of characters

6.2.8 Item Records


The system should:
1. contain in the item record information including, but not limited to:
- item identification number (barcode)
- author and title
- date of publication
- location
- temporary location
- call number
- enumeration/chronology date
- current status
- notes visible to patrons
2. make available information about an item’s status by searching the
item ID number (barcode).
3. allow authorized circulation staff to create item records on the fly for
items that have not yet been bar-coded.
4. alert the staff member to the proper routing of the item when an item
record created on the fly is discharged.
5. contain the following access points for record on the fly, including, but
not limited to:
- item ID number (barcode)
- call number
- author
- title
6. allow temporary relocation of an item to different circulation unit or
location.
7. allow circulation of that relocated item to borrowers from the
temporary location.
8. allow the option for checkout/check in of items that do not have
barcodes.
9. allow display of the temporary location in the OPAC.
10. allow summary display of all item records showing temporary
location and/or status.
11. support an unlimited number of bibliographic records that can be
attached to a single record (i.e., bound-with).
12. allow a virtually unlimited number of item record to be attached to a
single bibliographic record.
13. allow the item record to be moved to a different bibliographic record
or have other maintenance actions performed to it while circulation
transactions are present.
14. allow the input of various barcode schemes.
15. allow online error checking and validation of barcodes.
16. allow both public and non-public notes on the item record..
17. support re-sequencing of item records.
18. support creation of date of record entry into system as well as an
additional date that changes to reflect latest update.

6.3 OPAC
6.3.1 general
The system should:
1. provide an online public access catalog (OPAC) that is fully integrated
with other modules.
2. allow the user to search for all formats (books, journals, computer files,
maps, sound recordings, musical scores, visual materials, and archival
materials).
3. allow the user to find a range of levels of records, from full
bibliographic records to brief, minimal-level records.
4. allow the user to see records for materials in all status categories (fully
cataloged, on order, in process, lost, withdrawn)
5. permit the library to display or to suppress the public display of any
record category or of any particular record, while retaining staff access.
6. permit the library to suppress the display of specified fields to the
public.
7. allow access to various other bibliographic, citation, numeric, image,
or full-text files; these files may be loaded locally, accessed remotely,
or linked through local area networks; The system should also allow the
user to limit searches to single or customizable groups of databases .
8. allow the user to send to library staff electronic requests for service,
e.g., reference questions, holds/recalls and search requests, interlibrary
loan requests, or document delivery requests.

6.3.2 Search Interface Functionalities


The system should:
1. provide for a continuum of users, from novice to experienced users.
2. give users the maximum possibility of finding library resources,
without requiring knowledge of cataloguing rules or established norms
of headings.
3. encourage the user to explore the software capabilities without fear of
getting lost.
4. perform (optionally truncated) phrase search for names, subjects,
series, and titles.
5. allow the library to create customized headings, search keys, and
indexes if these are not otherwise provided (for example, conference
proceedings, corporate authors ..etc.).
6. provide a means by which records for periodicals can be searched
separately.
7. support searching on the full length of a field.
8. support searching on rotated (i.e., permuted) subject headings.
9. support case-insensitive searching.
10. support standard number searches (ISBN, ISSN, report number, local
control numbers, )
11. support call number searching .
12. fully support keyword searching:
- all fields may be indexed.
- universal and fields-delimited keyword searching.
- logical search operators (Boolean AND ,OR, NOT).
- positional operators ( ‘adjacent’, ‘near’, ‘with’, ‘same’ ).
- wildcards (for example, “wom?n”).
13. support the ability to combine call numbers with other terms.
14. allow override of the stoplist to search for entries consisting primarily
or entirely of stopwords.
15. allow the user to limit a search by library-specified data elements,
including, but not limited to:
- year of imprint
- range of dates
- language
- format
- item type
- place of publication
- publisher
- holding library
- location within library
- circulation status
16. allow all records for any heading to be retrieved.
17. provide feedback on search progress.
18. warn of large search result.
19. allow in-process searches to be stopped/canceled.
20. allow searches to be modified without having to be fully retyped.
21. save searches throughout a session; allow search history to be
displayed.
22. allow search strategies to be stored and invoked by user at another
time or in another database.
23. support user selected display format for a searching session.
24. support an interface that permits users to choose from among multiple
language interfaces, including Arabic..

6.3.3 Navigation
The system should:
1. allow easy toggling between OPAC and staff functions.
2. allow user to review partial set before all records have been retrieved if
result set is large.
3. make it easy for a user to navigate among retrieved records.
4. provide a clear guide mechanism to facilitate moving around within the
alphabetical (or other) sequence.
5. support forward and reverse browse/scan of headings displays, call
number indexes, and standard number indexes.
6. allow user to skip to a specified record or line number.
7. bypass index and go directly to record when search results in one hit.
8. minimize number of mouse click and scrolling required.
9. allow the user to return easily to a previous level or screen.
10. provide functional keyboard equivalents for user interface elements
such as menus, push buttons, scroll bars, etc., that can be activated by
pointing devices such as a mouse.
11. support hypertext capabilities that permit use of part of a displayed
record (e.g., subject, author, etc.) as the search argument of the next
search.
12. support hypertext capabilities that permit an internet URL in the
displayed record to retrieve the item referred to that URL.
13. allow the user to move through long, complex holding statement in a
flexible and efficient manner.

6.3.4 Help and “Artificial Intelligence” Enhancements


The system should:
1. be designed to anticipate and prevent “errors” from occurring.
2. provide pull-down lists of options searching and limiting.
3. ignore errors in spacing, punctuation, and diacritics.
4. check for and drops initial article in a title search.
5. ignore stopwords;
6. display a browse screen with the user’s search argument in its proper
alphabetical location in the index when a search retrieves no records..
7. provide full help system:
- brief instructions and examples on search screen.
- maximum library control over and editing of help and
explanatory screen.
- help is contextual.
- help can be read/scanned in its entirety.
- help can be printed, and e-mailed.
- library customizable online tutorial.
8. set no limit on results but alerts user if large set would be retrieved and
offers suggestions for refining search.
9. lead user to the correct form of name when unauthorized form is
searched and notifies user when doing so.
10. support variation in spelling, common abbreviations and acronyms,
and singular/ plural forms of words (e.g., color/colour, &./ st./saint).
11. provide messages that are clear, concise, and easily understood by all
levels of users.

6.3.5 Content Display


The system should:
1. support both a text-based interface and a web browser interface..
2. display full MARC record and customized brief record.
3. display all applicable see also references.
5. provide maximum local library control over bibliographic record
displays; library chooses:
- data elements to display at each level
- order in which they are displayed
- limit on the number of records that can be displayed, sorted,
printed
7. provide the ability to show location, call number, and copy information
in any order desired, and to change order, e.g., display call numbers at
beginning of record display.
8. display non-Roman characters, particularly Arabic characters.
9. support various user specified sort capabilities on retrieved sets such as
those listed here.
- reverse chronological by date
- library location or sub location
- call number
- author
- title
- chronology (especially to link successive title entries for serials)
- relevancy
- alphabetical
10. display search query and number of hits obtained along with search
results.
11. display system record number in public mode.
12. display call number and location prominently in every view.
13. support auto time-out set by library with user warning message.
14. provide a display that clearly indicates when full text is available for
citation.
15. provide the option to highlight call numbers and status displays.
16. display status information whenever item level information is
displayed; such statuses include on order, in process, on reserve,
missing, charged out, at bindery, or similar language.

6.3.6 Printing and Downloading


The system should:
1. allow all displayed fields to be printed and downloaded.
2. allow help text to be printed or downloaded.
3. print to a locally-attached printer or a printer on the network.
4. format downloaded data for loading into standard bibliographic
management systems as well as in plain ASCII.
5. allow user to specify record elements to print or download.
6. allow user to mark or select records from a multiple record set and
print them with a single command.
7. give users options for sorting sets to be printed or downloaded.
8. support various electronic transfer modes including e-mail, etc.

6.4 Circulation
6.4.1 Circulation Parameters
The system should:
1. allow all circulation parameters to be library specific.
2. accommodate circulation parameters based on library-user type, item
type, and library location.
3. be table driven so that authorized library operators can modify tables
that control due dates, grace periods, renewals and hold capabilities,
overdue schedules, fines, replacement and processing costs, and
content of overdue notices.
4. allow circulation policy tables to be easily constructed and modified by
authorized library staff.
5. provide loan rule options or control, including, but not limited to:
- hourly loan periods with or without overnight privileges
- daily loan periods
- absolute loan periods due on a certain date regardless of checkout
date and applicable to library-user categories specified by the
library
- renewals
- renewal limits
- number of overdue and fine notices
- timing of overdue and fine notices
- text of overdue and fine notices
- text of hold available notices
- text of recall notices
- rush recall for reserve
- fine grace periods
- fine rates and time lengths (including different fine rates for recall
and reserve items)
- default replacement costs when not specified in item records
(depending on library)
- timing of billing notices
- text of billing notices
- ability to print notices
- library unit-controlled notices
6. provide an on-line calendar that accommodates a very complex
schedule including adjusting loan period for holidays and closed
library hours. An authorized library operator is able to create and
modify calendar. Calendar is library specific.
7. provides a real, historic calendar that functions accurately in
conjunction with fines calculations and provides the option for days the
library is closed.
8. verify check-digits on manually input as well as scanned barcodes .

6.4.2 Circulation Control


The system should:
1. allow entry of borrower and item identification by scanner or keyboard
entry.
2. automatically display library-user name, barcode, address, and item
barcode, item title, and due date/time slip.
3. allow operator to assign due date at checkout.
4. not check out items that are non-circulating and alerts the operator both
visually and audibly; requires operator acknowledgment before
proceeding.
5. allow authorized library staff to manually block library users with
ability to enter an explanatory note.
6. allow authorized library staff to override any block.
7. allow creation of temporary item record and permits checkout.
8. alert operator when attempting checkout for an item already in
circulation; system should require acknowledgment by operator before
proceeding.
9. allow renewals of items depending on library-user type.
10. allow global renewal of all items on loan to one person or specified
subset of all items.
11. allow operator to assign new due date of renewed item.
12. allow renewal of overdue items depending on library-user type.
13. allow a renewal limit on items depending on library-user type and
item type.
14. allow override of renewal limit by authorized library staff.
15. block renewal when the item has a hold.
16. allow jumping from one circulation function to another (e.g.,
checkout to patron record) without re-keying the patron ID.
17. check in items by scanner and keyboard items entry.
18. give the operator the option to print a receipt of returned item for
patron.
19. alert the operator when items are checked in. System should require
operator acknowledgment before proceeding, and should print a
routing slip for the following conditions:
- on hold
- not returned
- needs cataloging review
- needs circulation review
- item has been billed for replacement
- item had been missing
- needs number of pieces review
20. allow operator to modify date and item of checking prior to current
date/time.
21. provide circulation backup capability when server is down.
22. allow holds to be placed (either by title so that first available copy
satisfies the hold or by specific copy). System should also allow holds
to be overridden by authorized staff.
23. allow holds to be placed on items that are not checked
out . System should also allow holds to be overridden by authorized
staff.
24. allow holds to be placed on items that are “on order”. System should
allow holds to be overridden by authorized staff.
25. automatically block placing a hold/recall for library- users with any
outstanding blocks.
26. automatically block library-users from placing multiple holds on the
same item.
27. allow holds to be placed depending on library-user type and item type
28. allow placement of recalls depending on library-user type and item
type.
29. allow reordering of hold queue by authorized library staff.
30. allow operator to cancel holds.
31. monitor the length of time item sits on hold shelf and generates report
to alert staff to cancel holds after library defined period.
32. stop the automatic production of overdue notices for items with
“claims returned” or “lost” status until situation is resolved.
33. accurately calculate and display fine at time of check in.
34. allow operator to access the library-user’s fine and payment record.
Fine records should store data, including, but not limited to author,
title, call number, item barcode, date/time checked out, date/ time
checked in, and amount overdue.
35. determine fines by library-user type and item type..
36. allow authorized library staff to waive part or all of assigned fines.
37. allow authorized library staff to access library-user’s records.
38. allow library-user’s file to be accessed by user’s name, barcode, or
some other identifier defined by the library.
39. provide user records which include but are not limited to:
- user name
- library-defined identifier
- user barcode
- primary and alternate addresses
- primary and alternate phone numbers
- user type
- department
- creation date
- expiration date
- date of last update
- free text note fields which display to the library user and staff or
to staff only
- e-mail address
40. allow for multiple user records and/or profiles for a particular user
within one user file.
41. allow printing of a user record including all currently checked out
items, holds, fines, and bills.
42. allow creation of and updates to user records, either manually or by
batch load.
43. allow the option to send some or all notices via e-mail.
44. generate notices automatically as determined by library-defined
parameters, including, but not limited to:
- overdues
- fines
- recall
- hold availability
45. allow operator to print or e-mail notices on demand.
CHAPTER SEVEN
DATABASE DESIGN

The purpose of this chapter is to provide a description

for the U of K library system database, and to design a

prototype database for the cataloguing and OPAC

modules of the proposed Integrated Library

Management System. The database description and

partial design of the modules mentioned above is to be

accompanied with the detailed functional specifications

of the proposed library system outlineed in the previous

chapter. They can then be used together to serve as a

basis for the Request For Proposal (RFP) for the

Integrated Library Management System to be selected

and implemented by the U of K Library.

The design includes a conceptual and logical database

for the three core subsystems of the U of K library

system, in addition to the physical databse design for

the cataloguing subsystem and its OPAC interface.

Database Management Systems (DBMS) are very

important for library management systems. They

underpin all the activities of a library management


system by providing the basic storage and retrieval

technology.

Database design can be divided into three phases,

according to Davis and Olsn(1985). These are :


i. Requirements determination, where the data requirements of
individual users and applications are determined. This has already
been done in chapter 4 of this study by means of Data Flow
Diagrams (DFDs) and the data dictionary.
ii. Conceptual and logical design of the database. This refers to the
integration of the individual user and application views into an
overall conceptual view that resolves view conflicts. There are two
parts of this phase: an unconstrained or natural conceptual design
and a conceptual design that is constrained for a particular Data
Base Management System (DBMS).
iii. Physical design where the coceptual logical design is translated
into a physical storage strucure.

Kroenke (1983) points out that database design is divided into two phases
: logical design , where the needs of users are specified, and physical
design, where the logical design is mapped into the constraints of
particular program and hardware producs.
The system requirements, expressed earlier in this study in Chapter 4, in
the form of Data Flow Diagrams and the Data dictionary will act as
inputs to the Logical database.
For the purpose of this study, the above viewpoint of Davis and Olsen of
dividing the database design into the following three phases, has been
followed :
i. the conceptual database design,
ii. the logical database design,
iii. the physical database design.
Each of the above models will be explaind under its respective section.

7.1 The Conceptual Database Design


The primary objectives of designing the conceptual database are as follows:
a. To assign attributes to entities in an optimal way.
b. To determine the characteristics of the attributes.

In order to design the conceptual database for the U of K library system, the
following rules have been applied:
a. Determining the scope of the transactions within each subsystems under
consideration.
b. Determining the relevant transactions within each subsystems that the
database must support.
c. Determining the business rules within each subsystem.
d. From steps b and c above, determining the entities.
e. Determining the identifiers for each entity.
f. Addition of attributes to entities.

The Library subsystems considered in the process of the conceptual data


base design are as follows;
i. The Acquisitions subsystem;
ii. The Cataloguing subsystem;
iii. The Circulation subsystem;

7.1.1 The Acquisitions Subsystem Database


7.1.1.1 Scope
The Acquisitions subsystem is concerned with the selection, ordering, and
acquisition of new books and other nonprint information sources to the
library.
7.1.1.2 Transactions within the acquisitions subsystem
1. Receive request
2. Check items on stock
3. Add a record to the orders file
4. Dispatch order to the vendor
5. Check outstanding orders
6. Chase outstanding orders
7. Receive item and check
8. Notify requester
9. Arrange for payment list
10. Pass on the item for further processing

7.1.1.3 The rules within the Acquisitions subsystem


1. Each request form should contain one book-title.
2. Several copies of the same title can be requested with the same request
form.
3. Different orders could be sent to one vendor.
4. A user can request more than one book-title.
5. Request for library materials are made only by the head of departments.
6. Invoice can contain many book - titles.
7. Each acquired book is assigned a unique accessions number.
8. A specific title can be requested by only one user.
9. A vendor can send to the library more than one invoice.
10. A vendor can receive more than one reminder.
11. A reminder can contain more than one book-title.

7.1.1.4. Entities within the Acquisitions subsystem


1. Book
2. Request-Form
3. Order-Form
4. Vendor
5. User
6. Invoice
7. Reminder

7.1.1. 5 Identifier for each entity (Primary Key)


Entity Identifier
1. Book ISBN
2. Request- Form Request - Number
3. Order- Form Order-Number
4. Vendor Vendor-code
5. User User-ID-No.
6. Invoice Invoice-Number
7. Reminder Order-Number

7.1.1.6 Assigning of Attributes to Entities


Book
Bk-ISBN
Bk-Title
Bk-Author
Bk-Publisher
Bk-Edition

Request-Form
Request #
Request-Date
Book-Title
Book-ISBN
Book-Author

Book-Edition
User - ID-No.

Order-Form
Order #
Order-Date
Book-Title
Book-ISBN
Book-Edition

Vendor
Vendor-Code
Vender-Address
Vendor-Name
Book-ISBN
Book-Title

User
User-ID-No.
User-Name
User-Address
User-Status

Invoice
Invoice #
Invoice-Date
Book-Title
Book-Author
Book-Price
Book-ISBN
Order-No.

Reminder
Order #
Order-Date
Book-ISBN
Book-Title
Book-Author

7.I.2 The Catalogueing Database


7.1.2.1 Scope
The activities of this sub-system involve indexing, cataloguing and location
of library materials.

7.1.2.2 Transactions within the cataloguing Subsystem


Below are steps in sequential order which define events within the
cataloguing
subsystem:
1. Locate /find documents for borrowing through search on the catalogue
database .
2. Show library holdings.
3. Data entry to catalogue database.
4. Downloading information from external sources.
5. Authority control.

7.1.2.3 The Rules within the Cataloguing subsystem


1. Bibliographic details on a book are entered once in the database.
2. Catalogue forms with all bibliographic details like subject, author,
title must be filled for every document.
3. Catalogue database should contain three files (Book file, periodical
file, user profile).
4. Authority control files must be established.
5. All entries and updates into the catalogue database must be done by
authorized and trained library personnel, as materials are received,

6. The MARC standard should be used to download bibliographic


information from external resources into the catalogue database.
7. Updating/backup of the catalogue must be done weekly.
8.Printing of portions of catalogues should be done when need arises, but
printing of the entire catalogue must be done once a year.

7.1.2.4 The Entities Within Cataloguing Subsystem


This has been done through the examination and analysis of the transactions
and rulers above:
1. Catalogue Forms.
2. Book/Document
3. Journal

7.1.2.5 Identifieres for Each Entity (Primary Key)


This has been done to ensure that the entities are real entities. We have
identified the unique data items, and/or combination of data items that
identifies the occurrence of the entities identified.
Entity Identifier
Catalogue forms Classification_Number_Copy-No.
Book/Document ISBN_Number_copy_number.
Journals ISSN_Number_Vol_Number_Issue_Number.

7..1.2.6 Ensuring That The Conceptual Design Satisfies The Rules And
Transactions' Needs
This is the validation process carried out to ensure that the conceptual design
rules satisfies the needs.

1. The first transaction on the location of documents for borrowing and


showing of the library holdings is done through the catalogue database.
There is a 1: M relationship between the OPAC and the users.
2. Data entry to catalogue database is done through the entity catalogue
entry and through downloading from external information.
3. The authority control files shall be created to support the functioning of
the database and the system.

7.1.2. 7 Addition of Attributes To Entities


Entity Attribute
1. Catalogue forms: Author's name
Book title
Call number
ISBN
Subject heading
Pagination
Date of publication
Publisher
Place of publication

2. Journal Journal title


ISSN
Volume number
Issue Number
3. Book/Document Book Title
Author's name
Call number
ISBN
Date of publication
Place of publication
Publisher

7.1.3 The Circulation Database


7.1.3.1 The Scope
The functions of the circulation subsystem are setting loan parameters, loan
policies, reservations, bills, loans, borrower file maintenance, inquiries,
reports, statistics.

7.1.3.2 Transactions Within Circulation Subsystem


1. Providing information on the location of library items.
1. Charging and discharging of documents.
2. Identification of items on loan.
3. Recording of reservations.
4. Printing of ' book available' notices to the requester.
5. Printing recall notices for overdue items.
6. Renewal of loans.
7. Notification of library staff about overdue items.
8. Notification of library staff about delinquent borrowers.
9. Billing of borrowers with overdue books, recording of receipts of fines.
10. Calculation and printing of various types of library statistics.
11. Analysis of summary statistics and statistics of circulation of particular
items for use in acquisitions, planning of services etc.
12. Printing of due date slips, automatically generating orders for lost books
or additional copies.
13. Printing and mailing or/emailing labels for remote borrowers.

7.1.3.3 The Rules within the Circulation Subsystem


These are statements about the cardinality of relationships among
entities, referential integrity, and domain restrictions in summary :
1. Book arrangement on the shelf depends on call number.
2. For every item loaned there must be update in the database.
3. For every item received there must be a record.
4. For every returned, reserved book , there should be notification to the
next requester.
5. For every overdue item, there should be one recall notice.
6. For every overdue item, one notification is provided for the library
staff.
7. One bill is prepared for each overdue item.
8. For each bill that is honoured , one receipt is to be prepared.
9. For every statistical report, a corresponding analysis report should be
prepared.
10. For every additional copy of a needed item, an order should be
prepared.
11. For every lost book an order is prepared.
12. Loans should only be granted to users with the borrowing right.
13. The users of the U of K Library should only be the students and staff
of the University of Khartoum, or students of other universitiers
holding the U of K library card.
14. A short loan period must be one week.
15. A long loan period must be two weeks.
16. Only staff borrowers are entitled to long loan periods.
17.Spot reading referencing must be for three hours.
18.Sudent users must not borrow more than four books at a time.
19. Staff borrowers must not borrow more than eight books at a time.
20. A borrowed item must not be renewed more than two times.
21. A single user can only use one reserved book at a time.

7.1.3.4 Entities Within Circulation Subsystem


This has been done through the examination and analysis of the transactions
and the rules above:
Book on loan
Reserved book
Overdue book
Bill
Receipt
Statistic report
Order
User
Analysis report
Notification form
Lost book.

7.1.3.5 Identifiers for Each Entity (Primary Key)


This has been done to ensure that the entities are real entities. Below are
the unique data items.
Entity Identifier
Book on loan Call_Number + Copy_Number + user_ID.
Reserved book Call_Number + Copy_Number + user_ID.
Overdue book Call_Number + Copy_Number + user_ID.
Bill Bill_Number.
Receipt Receipt_Number.
Statistic reports Stat_Report_Number.
Order Order_Number.
User User_Number.
Analysis report Analysis_report_Number.
Notification form Notification_form_Number.
Lost book Call_Number_Copy_Number.

7.1.3.6 Ensuring That The Conceptual Design Satisfies The Rules And
Transactions Needs.
The establishment of an Online Public Access Catalogue (OPAC) and the
catalogue database will facilitate most of the operations of the circulation
subsystem. These transactions and rules of the conceptual design are met
through the following activities:
1. Prevision of information on the location of library items is done through
the OPAC.
2. Charging and discharging of documents.
3. Identification of material on loan is done through the OPAC.
4. Records of items on reservation are also to be maintained in the catalogue
database which can be accessed through the OPAC.
5. Printing of book available notices to the requester is done through OPAC.
6. Printing of recall notices for overdue items is to be done through OPAC
7. Renewal of loans is to be done through the OPAC by authorized users or
the library personnel.
8. Notification of library staff of the overdue items is to be done through
OPAC
9. Notification of the library personnel of the delinquent users, is to be done
through the OPAC.
10. Billing of borrowers with overdue books, recording of receipts of fines is
to be done through the catalogue database.
11. Calculation and printing of various types of library statistics is to be done
through the catalogue database.
12. Analysis of summary statistics and statistics for circulation of particular
items for use in acquisitions, planning of services etc.
13. Printing of overdue data slips and automatically generating orders for
lost books or additional copies.
14. Printing mailing labels for anticipated remote borrowers.
7.2 The Logical Database Design
7.2.1 Overview of the Relational Model Used
The relational model depends on the relational theory that treats data as relations and
describes how data should be structured and managed. Relational Database Management
Systems (RDBMS) use the Structured Query Languages (SQL) to extract and update
data. Examples of Relational DBMS are Oracle, Sybase, and Informix. The relational
DBMS work best when the data structres have been normalized to eliminate data and
field duplication.
The relational model is a way of looking at data and their interactions that
describe the real world. It consists of a set of rules from the relational theory
for restructuring and managing data while maintaining integrity. the
relational model has been chosen to be usedn in designing the University of
Khartoum Library System database because of the many advantages that it
has over the other types of database models. These advantages can be
summerized as follows:
• The relational approach is easy to understand and appreciate since to end
users, it appears that all the data is stored in a two dimensional tables,
called flat files. The rows (tuples) represent records, while the columns
(attributes) represent fields. Columns represent tables to one another.
In other words, relationships are represented by foreign keys in the dependent (child )
tables.
• The relational model is the most popular type of DBMS in use and as aresult
technical developments s appear quickly and reliably.
• The relational DBMS have well developed management tools and security with
automatic data logging and recovery.
• The relational DBMSs have referential integrity controls that ensure data
consistency.
• The relational DBMSs have transactional integrity features to ensure that
incomplete transactions do not occur.
• The emerging Object Oriented DBMS is not clear as to its implications for library
systems. Object orientation for databases means the capability of storing and retrieving
objects along with data. Most Object Oriented DBMSs can handle images, video and
other objects but do so in a non-standarad way in many cases.

The U of K library system will thus be modeled to take advantage of the


following characteristics of the relational approach;
• Data independence.
• Flexibility.
• Ease of use by end users and the information service personnel (in this
case library staff).
• Security of data.
• Symmetry access, which refers to the ease with which queries are
constructed.

Shepherd (1990) recommends six stages given below for mapping the conceptual
database to the logical database. Accordingly, the researcher has followed these stages in
mapping each entity of the conceptual database for the U of K library. In some cases the
justification for each activity is also given. For convenience, stages two and three have
been merged.

The stages are;


1. Converting each entity into a table, including the intersection entities.
This results in a logical model that mirrors the conceptual model.
2. Mapping each attribute of the entity into a column of the table.
3. Identifying each primary key and mapping each relationship into a
foreign key.
4. Normalizing the design. Normalization has been done following the
principles of normalization which were developed in the 1970's and the
early 1980's as guidelines to follow using relational databases.

In the Case of the U of K library system, redundant attributes have been removed . Data
entities have been defined so as to avoid update, insertion and deletion anomalies. The
entities are shown in the section entitled- Implementation of the logical design-

5. Deciding which deletion integrity rule to use . For the U of K Library


System database, the rule Set to null is chosen to set the foreign-key
values to NULL so as to prevent deletion of the dependent tables when
the parent tables is deleted. This is important in the case of a relational
database which operates in a library system where entities such as users
(borrowers in our case) keep on changing hence the need to make
changes in the different files/fields.
6. Determining the indexes. At this stage, the keys on which indexes will be
based are determined.
7.2.2 Implementation of the Logical Design
7.2.2.1 The Acquisitions Subsystem
1. Conversion of each entity into a table and mapping of each attribute
of the entity to a column of the table.
BOOK (BK-ISBN, BK-TITLE,BK-AUTHOR, BK-PUBLISHER,BK-
EDITION)
REQ-FORM (REQUEST #, REQUEST-DATE, BK-TITLE, REQUESTER-
NAME,
BK-ISBN, BOOK-TITLE, BOOK-AUTHOR)
ORDER-FORM (ORDER #, ORDER-DATE,BK-ISBN-EDITION,
VENDOR-NAME)
VENDOR (VENDOR -CODE, VENDOR-NAME, VENDOR-ADDRESS,)
USER ( USER-ID-NO, USER-NAME, USER-ADDRESS, USER-
STATUS)
INVOICE (INVOICE#, INVOICE-DATA, ORDER # BK-ISBN, BK-
TITLE, BK-PRICE)
REMINDER (ORDER #, REMINDER-DATE, VENDOR-CODE, BK-
ISBN)

2. Identification of the Primary Key and mapping each relationship to a


foreign key,
BOOK (BK-ISBN, BK-TILTE, BK-AUTHOR, BK-PUBLISHER, BK-
EDITION, ORDER #, VENDOR-ID, INVOICE #)
REQ-FORM (REQUEST #, REQUEST-DATE, USER-ID-NO, BK-ISBN,)
ODER-FORM (ORDER #, ORDER -DATE, BK-ISBN, VENDOR-CODE)
VENDOR (VENDOR-CODE, VENDOR-NAME, VENDOR-ADDRESS,)
USER (USER-ID-NO, USER-NAME, USER -ADDRESS, USER-
STATUS)
INVOICE (INVOICE #, INVOICE-DATE, ORDER #, BK-
ISBN,VENDOR-CODE)
REMINDER (ORDER #, REMINDER-DATE, VENDOR-CODE, BK-
ISBN)

3. Normalization of the Design


After applying the normalization rules, it has been arrived at the design
below.
BK-ON-ORDER (BK-ISBN, BK-TITLE, BK-AUTHOR, BK-PUBLISHER,
BK-EDITION, ORDER #)
BK-RECIVED (ORDER #, BK-ISBN, VENDOR-ID, INVOICE #)
REQ-FORM (REQUEST #, REQUEST-DATE, USER-ID-NO, BK-ISBN,)
ORDER-FORM (ORDER#, ORDER-DATE, BK-ISBN, VENDOR-CODE)
VENDOR (VENDOR-CODE, VENDOR-NAME, VENDOR-ADDRESS,)
USER (USER-ID-NO, USER-NAM, USER-ADDRESS, USER-STATUS)
INVOICE (INVOICE #, INVOICE-DATE, ORDER #)
INVOICE-DETAILS (BK-ISBN, INVOICE #, VENDOR-CODE)
REMINDER (ORDER #, REMINDER-DATE, VENDOR-CODE, BK-
ISBN)

4. Decision on which Deletion Integrity Rule to Use


The deletion integrity rule that has been chosen to be used in this database is
the Set-to-NULL rule. This rule results in the severing of relationships
between different entities (Files) when deleting files. This is done by setting
the foreign key value in the dependent file to NULL.

7.2.2.2 The Cataloguing and Circulation Subsystems


The six stages of mapping the conceptual database to the logical database are
applied below on each entity at a time. Each entity is mapped on a separate page.

Entity Name : Overdue –Books + Notification –Form.

1. converting the entity into a table and mapping attributes to columns


in the table
Overdue-Books+ Notification Form (Notification Form Number,
Date, Borrower's-name, date-due
Authors-
Name, Book-Title, Brower's-ID-
Number).
2. identifying the primary key and mapping each relationship into a
foreign key.
Primary Key: Notification-form-number.
Foreign Key: Due-Date

3. normalization of the data


The data resulting from the normalization exercise is shown in the tables
below. The entities are outside the braces and the attributes are shown inside
the braces.

Overdue book notification Form (Notification Form Number,


Date, Borrowers-ID-Number,
ISBN, Copy-number, Book-title,
Due-Date, Authors-Name)

4. applicable deletion integrity rule to be used for each parent dependent


table combination : set-to-Null
5. determining the indexes: Indexes will be determined on the basis of
the following key;
Primary Key: Notification-Form-Number
Foreign Key: Due-Date
Secondary Key: Borrower's-Name, Borrower's-ID, Author's-name, Book-
title.
Entity name: Book- on -Loan
1. converting the entity into a table and mapping attributes to columns
in the table.
Books on Loan (Book-Title, Copy-Number, Authors-Name, Call-Number,
ISBN, Date-of-Publication, Place-Of-Publication, Publisher.
2. identifying the primary key and mapping each relationship into a
foreign key.
Primary Key: Book-Title + Copy-Numer (Composite key)
Foreign Key: Author's-name
3. normalizing the data
Books on loan (Book-title-Copy-number, ISBN, Call-number,
Author's-name, Publisher).
4. applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. indexes will be determined on the basis of the following key;
Primary Key: ISBN,Copy-Numer
Secondary Key: Author's-name
Foreign Key: Call-number
Entity name: Bill- of- lost- book (s)
1. converting the entity into a table and mappi g attributes to columns
in the table.
Bill of lost books (Bill-number, Book-title, Authors-name,
ISBN, Price-of-lost-book, Borrowers-ID,
Total Price-of-lost-books)
2. identifying the primary key and mapping each relationship into a
foreign key.
Primary Key: Bill-number, Foreign Key: Price-of-lost-book
3. normalizing the data
Bill of lost books (Bill-number, Book-title, Authors-name,
ISBN-ISSN, Price-of-lost-book,
Borrower's-ID)
4.applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. determining the indexes on the basis of the keys.
Primary Key: Bill-number
Foreign Key: Price-of-lost-book
Secondary Key: Title-of-book, ISBN, author's-name, Borrower's-ID.
Entity name: Receipt
1. converting te entity into a table and mapping attributes to columns in
the table.
Receipt (Receipts-number, Amount-paid, bill-number-
Hounoured, Borrower's-name, Date-of-payment,
Title (s)-of-books-paid-for, Signature-of-payer)
2. identifying the primary key and mappimg each relationship into a
foreign key
Primary Key: Receipt-number
Foreign Key: Borrower's name
3. normalizing the data
Receipt (Receipt-number, Amount-Paid, Borrowers-name,
Date-of-payment, title,-of-book-for,
Name-of-payer)
4.applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. determining the indexes on the basis of the keys
Primary Key: Receipt-number
Foreign Key: Borrower's-ID
Secondary Key: Book-Title, Author's-name., Bill-Number.
Entity name: Borrower

1. converting the entity into a table and mapping attributes to


columns in the table
Borrower (Borrower's-ID Borrower's-name, Borrower's -Department
Academic-Year, Borrower's-status, Borrower's-Address)
2. identifying the primary key and mappimg each relationship into a
foreign key
Primary Key: Borrower's-ID
Foreign Key: Borrower's-Department?
3. normalizing the data
Borrower (Borrower-ID, Borrower-name, Academic-year,
Borrower's-department, Borrower-Status)
4..applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. determining the indexes on the basis of the keys
Primary Key: Borrower-ID
Foreign Key: Department
Secondary Key: Borrower's-name, Borrower's-Status
Entity name: Statistical- Report
1. converting te entity into a table and mapping attributes to columns
in the table.
Statistical Report (Statistical Report-Number, Author's-name
Report-Title, Subject, Date-of-issue, Subject,
Pagination)
2. identifying the primary key and mappimg each relationship into a
foreign key
Primary Key: Statistical-report-Number
Foreign Key: Report-Title
3. normalizing the data
Statistical Report (Statistical -Report-Number, Author's -name,
Report-Title, Date-of-issue, Pagination, title)
4.applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. determining the indexes on the basis of the keys
Primary Key: Statistical-report-Number
Foreign Key: Report-Title
Secondary Key: Author's-name, Date-of-issue
Entity name: Annual- Report- of- the- U- of –K- Library
1. converting te entity into a table and mapping attributes to
columns in the table.
Annual report of the Uof K Library (Annual-report-Number,
Annual-Report-
Title, Date-of-issue, issuing-
Department,
Issued-to-:, Subject, Pagination)
2. identifying the primary key and mappimg each relationship into a
foreign key
Primary Key: Annual-report-Number
Foreign Key: Annual-report-Title
3. normalizing the data
U of K Library-Annual-Report (Annual-Report-Number, Annual-
Report-
Title, Date-of-issue, Issued-to,
Pagination,
Copy-Number)
4.applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. determining the indexes on the basis of the keys
Primary Key: Annual-report-Number
Foreign Key: Annual-report-Title
Secondary Key: Author's-name, Date-of-issue
Entity name: Catalogue- Form
1. converting the entity into a table and mapping attributes to
columns in the table
Catalogue Forms (Call Number, , Copy Number, Book-Title,
Author-Name, subject-Headings)
2. identifying the primary key and mappimg each relationship into a
foreign key
Primary Key: Call number
Foreign Key: Book-Title
3. normalizing the data
Catalogue Forms (Call Number, , Copy Number, Author-Name,
subject-Headings, Pagination)
4.applicable deletion integrity rule to be used for each parent
dependent table combination : set-to-Null
5. determining the indexes on the basis of the keys
Primary Key: Call-number
Foreign Key: Book Title
Secondary Key: Author's-name, Author's name, Subject heading
Entity name: Lost Book
1. converting te entity into a table and mapping attributes to
columns in the table
Lost Books (ISBN Copy Number, Author's -names. ISBN,
Publisher,
Place of Publication, Date of Publication, Price-of-lost
book(s),
Borrower's -ID)
2 . identifying the primary key and mappimg each relationship into a foreign key

Primary Key: ISBN Copy Number


Foreign Key: Borrower's -ID
3. normalizing the data
Lost Book (ISBN Copy Number, Author's -name, Publisher,
Borrower's -ID, Price-of-lost book (s) ),
4.applicable deletion integrity rule to be used for each parent
dependent table combination : Restrict
5. determining the indexes on the basis of the keys
Primary Key: ISBN, Copy -number
Foreign Key: Borrower's_ID
Secondary Key: Title of Book, Borrower's name, Publisher, ISBN
Entity name: Book-on-Reserve
1. converting the entity into a table and mapping attributes to
columns in the table
Books on Reserve (ISBN Copy Number, Author's -name. ISBN,
Call-
Number, Pagination, Subject heading, Publisher,
Date of
Publication, Place of Publication, Due-Date,
Borrower -ID, Copy-number)
2 . identifying the primary key and mappimg each relationship into a foreign key

Primary Key: ISBN Copy Number (Composite key)


Foreign Key: Call-Number
3. normalizing the data
Lost Book (ISBN Copy Number, Author's -name, Call number,
Pagination, Subject-heading, Publisher, Copy-Number, Borrower's -ID,
Due-date )
4.applicable deletion integrity rule to be used for each parent
dependent table combination : Restrict
5. determining the indexes on the basis of the keys
Primary Key: ISBN
Foreign Key: Call-Number
Summary on normalizing the design for the cataloguing and
circulations subssytems.
The data resulting from the normalization exercise is shown in the tables
below. The entities are shown outside the braces and the attributes are
shown inside the braces.
Overdue -book –notification- Form (Notification-form-number, Date,
Borrowers-
ID-Number, ISBN, Copy-number,
Book-title,
Due-Date, Author's-Name)

Book- on- loan (Book-title-Copy-number, ISBN, Call- number


,Author's-
name, Publisher)

Bill- of - Lost -book ( Bill-Number, Book-Title, Authors-Name, ISBN-


Price-of-lost-book, borrower's-ID)

Order (Order-Number, Book-Title, Journal-Title, Authors-


Name,
ISBN-ISSN, Price-of-lost-book, borrower's-ID)

Receipt (Receipt-Number, Amount-Paid, Borrower's-name, Date-


of-
payment, Title-of-book-paid-for, Name -of-Payer)
Borrower (Borrower-ID, Borrower-Name, Academic-Year,
Borrower's-
department, Borrower-Status)

Statistical Report ( Statistical Report-number, author's-Name, Report-


Title, Date- of-issue, Pagination, Title)
U- of –K- Library-Annual-Report (Annual-Report -Number, Annual-
Report -
Title, Date-of-Issue, Iced-to,
Pagination, Copy-
Number)
Catalogue -Form (Call-number, Copy-Number, Book
title,
Authors- name, Subject-Headings)

Book (Title, ISBN, Call Number, Author's


=name,
Publisher, Subject-heading, Copy-
Number)
Journal (Issue Number, Volume Number, Journal -
title,
Publisher, Periodic)

Lost- book (ISBN-Copy-Number, Author's, Publisher,


Borrowers-ID, Price of Lost Books (s)).

Book- on- Reserve ( ISBN Copy-Number, Authors-Name, Call-


Number,
Pagination, Subject-Heading, Publisher,
Copy-
Number, Borrowers-ID, Due-Date)
7.3 The Physical Database Design
7.3.1 Overview Of The Physical Database
After completion of the logical database, the physical database can be
designed. The design for the physical database thus adapts the logical
database to the physical environment .The result is a physical database that
can be implemented.
A physical database consists of physical files, records and data items. The
physical files represent the logical data entities. These physical occurrences
represent logical occurrences of an entity. The data items represent the
logical attributes of an entity.
The purpose of the physical database design is to optimize response time, throughput ,
recovery, performance and storage space , yet not destroy the relational nature of the
data.
The researcher has initiated the next step of designing the physical database
by adapting the logical database to the physical environment. Unfortunately
due to time constraints, making a complete design of the U of K library
databases has not been possible. However, at the termination point of this
study the physical design of a prototype catalogue (and OPAC) database are
in place for trial (i.e implementation). A follow-up-study can be made to
evaluate the performance of this design. An other reason is that systems
analysis and design is rarely done by one person; it has always been the case
that such kind of study is carried out by a team, so that the different aspects
of the analysis and design can be accomplished.

7.3.2 Steps Followed in Designing the Prototype Physical


Database
1. Each (subject) entity was converted into a separate physical file.
1. A record structure was established for every attribute of an entity.
2. Multiple data entries are put into one file.
3. Using the data dictionary that was drawn-up earlier, the researcher
embarked on establishing the field values of the individual records
(attributes) as shown below.
4. Where entities (tables) are accessed more frequently, a close link was
created by placing them together.

The researcher decided to do the physical design of a prototype catalogue


database and its interface, the Online Public Access Catalogue (OPAC).
This decision was necessary in light of the urgent need to automate the
circulation activities before any other activity so as to help the users in
accessing the library holdings. The output of the physical design could be
used by the University of Khartoum Library adminstration as part of A
Request For Proposal for the supply of an appropriate Integrated Library
Management System.
The output of the physical design will be equally useful in selecting
hardware , particularly in determining the capacity of hardware required
(hard disc capacity, memory, etc.)
Following the steps outlined above, a physical design for the U of K Library
system catalogue database and OPAC have been developed. The design
represents the record structure for the different entities (files) in the database
with the corresponding attributes.The structure shows the field name, field
size and length, type of field, the format in which the field is
written/displayed, the index (es) which indicate the relationship between a
particular field with the parent record , that is if it is a primary key, a
secondary key or a foreign (linking) key.
7.3.3 The Physical Design of The Catalogue database and OPAC of the
U of K
Library
Record Structure

RECORD NAME: BORROWER

Field Name: Borrower's_ID


Field size and length: 8
Type: Alpha-numeric
Format: XX-9999-XX
Index (es) by: Primary Key: Brrower's-ID
Total Length: 302400 characters ( i.e 8 x 37300 current
users of the
U of K Library plus an anticipated increase in
users of
500 which will add another 500x 8
characters).
Total number of records: Currently 37300 ( i.e 36000 students and
1300 teaching
staff)
A projected increase in the numbers of
users is 500
thus a total of increase to 37800 users is
projected in
the next five years.)

Field Name: Borrower's_name


Field size and length: 50
Type: Alpha-numeric
Format: Text
Index (es) by: Secondary Keys: Brrower's-name
Total Length: 756000 characters ( i.e 20 x 37300 current
users of the
U of K Library plus an anticipated increase
in users of
500 which will add another 500x 20
characters).
Total number of records: 37300 (Current), 37800.(Projected)

Field Name: Borrower's_ Department


Field size and length: 30

Type: Alpha-numeric
Format: Text
Index (es) by: Foreign Key: Department
Total Length: 1134000 characters ( i.e 30 x 37300 current
users of
the U of K Library plus an anticipated
increase in
users of 500 which will add another 500x 30
characters).
Total number of records: 37800 (Projected)

Field Name: Academic_year


Field size and length: 8
Type: numeric
Format: 9999/9999
Index (es) by: Secondary Key: Academic _year
Total Length: 302400 characters ( i.e 8 x 37300 current
users of the
U of K Library plus an anticipated increase
in users of
500 which will add another 500x 8
characters).
Total number of records: 37800

Field Name: Borrower's_Status


Field size and length: 10
Type: Alpha-numeric
Format: Text
Index (es) by: Secondary Key: Brrower's-Status
Total Length: 303400 characters ( i.e 8 x 373000 current
users of
the U of K Library plus an anticipated
increase in
users of 500 which will add another 500x 10
characters).

Total number of records: 298.400 ( Projected)


Field Name: Borrower's_Address
Field size and length: 90
Type: Alpha-numeric
Format: Text
Index (es) by: Secondary Key: Brrower's-Address
Total Length: 1.134.000 characters ( i.e 30 x 37300 current
users of
the U of K Library plus an anticipated
increase in
users of 500 which will add another 500x
30
characters).
Total number of records: 37800

RECORD NAME: CATALOUGE FORM

Field Name: Record_Number


Field size and length: 6
Type: Numeric
Format: 000001
Index (es) by: Primary Key: Record-Number
Total Length: 2.745642 characters ( i.e 6 x 357.607 current
holdings
of the U of K Library plus an projected
increase in
holdings of up to 100,000 which will
require 100,000 x 6 characters).
Total number of records: 457607 ( Projected increase in the next five
years)
Field Name: Book_Title
Field size and length: 150
Type: Alpha-numeric
Format: Text
Index (es) by: Secondary Key: Book-title
Total Length: 68.641.050 characters ( i.e 150x 357,607
current holdings of the U of K Library plus
an anticipated increase in holdings of up to
100,000 which will require 1000,000 x 150
characters).

Field Name Author’s _Name


Field size and length: 50
Type: Alpha-numeric
Format: Text
Index (es) by: Secondary Key: author's_name
Total Length: 23,800,350 characters ( i.e 50 x 357,607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will require 50x 100.000
characters).
Total number of records: 357,607,000 ( Current holdings of books)
plus
100,000 (Projected)

Field Name: ISBN


Field size and length: 20
Type: numeric
Format: 99-99-99-99/9-9-9-9-9-9
Index (es) by: Primary Key: ISBN
Total Length: 7152140 characters ( i.e 20 x 357.607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will require 100,000 x 20
characters).

Field Name: Call_Number


Field size and length: 20
Type: Alpha-numeric
Format: 999-999xxx
Index (es) by: Foreign Key: Call_number
Total Length: 7152140 characters ( i.e 20 x 357607 current
holdings of the U of K Library plus a
projected increase in holdings up to 100,000
which will increase to 100.000
x20characters).
Total number of records: 4.676.070 ( Projected)

Field Name: Copy_number


Field size and length: 3
Type: Numeric
Format: 999
Index (es) by: Primary Key: Copy_number
Total Length: 1.372.821 characters ( i.e 3 x 357697
current holdings of the U of K Library plus a
projected increase in holdings of up to
100,000 which will require 100,000 x 3
characters).
Total Number of records: 1.372.821 (Projected)

Field Name: Subject_Heading (subject_description)


Field size and length: 500
Type: Alpha-numeric

Format: Text
Index (es) by: Secondary Key: Subject_heading
Total Length: 228803500 characters ( i.e 500 x 357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will require 500x 100.000
characters).
Total number of records: 457.607 (Projected)

Field Name: Collation


Field size and length: 100
Type: Alpha-numeric
Format: Text
Index (es) by: ----
Total Length: 45,760,700 characters ( i.e 100 x 357607
current the U of K Library plus a projected
increase in holdings up to 100,000 which
will require 100,000 x 100 characters).
Total Number of Records: 457607 (Anticipated)

Field Name: Pagination

Field size and length: 4


Type: numeric
Format: Text
Index (es) by: --
Total Length: 1.830.428 characters ( i.e 4 x 357607 current
holdings of the U of K Library plus a
projected increase in holdings up to 100,000
which will increase to 100.000 x4
characters).
Total number of records: 457607 ( Projected increases in the next five
years)

Field Name: Edition


Field size and length: 25
Type: Alpha-numeric
Format: Text
Index (es) by: ---
Total Length: 11440175 characters ( i.e 25 x 357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will require 100,000 x 25
characters).
Total number of records: 457607 anticipated.

Field Name: Series


Field size and length: 100
Type: Alpha-numeric
Format: Text
Index (es) by: ___

Total Length: 45.760.700 characters ( i.e 100 x 357607


current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will increase to 100.000
x100 characters).
Total number of records: 457607 ( anticipated)

Field Name: Other_title


Field size and length: 150
Type: Alpha-numeric
Format: Text
Index (es) by: ---
Total Length: 73641050 characters ( i.e 150 x 357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000. If one third of the documents have
another title, then 100,000 x 200 characters
will be required).

Total number of records: 457607

Field Name: Notes


Field size and length: 150
Type: Alpha-numeric
Format: Text
Index (es) by: ___
Total Length: 73641050 characters ( i.e 150 x 357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 )

Total number of records: 357607

Field Name: Key_words (Descriptors)


(This field could be used as an alternative
to another field subject_headings)
Field size and length: 500
Type: Alpha-numeric
Format: Text
Index (es) by: Secondary keys: Key_words (Descriptors)
Total Length: 228803500 characters ( i.e 500 x 357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will require 100,000 x 500
characters).
Total number of records: 457607

Field Name: Abstract


Field size and length: 500

Type: Alpha-numeric
Format: Text
Index (es) by: ___
Total Length: 228803500 characters ( i.e 500 x 3357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will increase to 100.000
x500 characters).
Total number of records: 457607

Field Name: Conference_Title


Field size and length: 200
Type: Alpha-numeric
Format: Text
Index (es) by: ---
Total Length: 91521400 characters ( i.e 200 x 357607
current holdings of the U of K Library plus a
projected increase in holdings up to 100,000
which will require 100,000 x 200
characters).
Total number of records: 4457607

Field Name: Corporate_Author (Corporate body)


Field size and length: 200
Type: Alpha-numeric
Format: Text
Index (es) by: ___
Total Length: 91521400 characters ( i.e 200 x 357607 current holdings of the U of K Library plus a projected increase in
holdings up to 100,000 which will increase to 100000 x200 characters).
Total number of records: 457607

Field Name: Language


Field size and length: 2
Type: Alpha-numeric
Format: Text (Abbreviated) e.g. En for English, Fr
for French, etc
Index (es) by: ---

Total Length: 915214 characters ( i.e 2 x 357607 current holdings of the U of K Library plus a projected increase in holdings
up to 30,000 which will require 100,000 x 2 characters).

Total number of records: 547607

Field Name: Location


Field size and length: 100
Type: Alpha-numeric
Format: Text (Acronym of library preferred)
Index (es) by: ___
Total Length: 45760700 characters ( i.e 100 x 357607
current holdings of the U of K Library plus
a projected increase in holdings up to
100,000 which will increase to 100.000
x100 characters).
Total number of records 457607

Field Name: Volume_Number


Field size and length: 3
Type: Alpha-numeric
Format: xx9
Index (es) by: Primary Key: Volume_number_Issue-
Number
Total Length: 1372821 characters ( i.e 3 x 357607 current
holdings of the U of K Library plus an
anticipated increase in users of 500 which
will add another 30,000 x 3 will add another
100,000 x 3 characters).
RECORD NAME: Book/Document

Field Name: Title , Call_Number, ISBN, Author_Name,


Publisher, Subject_Heading and copy number.
(All these fields have been defined earlier for
the entity Catalogue_ Form . Therefore
the same information can be used for
creating the structure for this record)

RECORD NAME: Book- on- Reserve

Field Name: Title , Call_Number, ISBN, Author_Name,


Publisher, subject_Heading and copy number,
Pagination, Borrower's_ID. (All these
fields have been defined
earlier for the entity Catalogue_Form .
Therefore
the same information can be used for
creating the structure for this record. Additional
field for this
record are shown below):-

Field Name: Due-Date


Field size and length: 10
Type: Alpha-numeric
Format: 99/99/9999
Index (es) by: Secondary Key: Due_Date

Total Length: 378000 characters ( i.e 10 x 37300 current


users of the U of K Library plus an
anticipated increase in of 500 which will
add another 500 x10 characters).
Total number of records: 37800

Field Name: Date_of_Publication


Field size and length: 10
Type: Numeric
Format: 99/99/9999
Index (es) by: Secondary Key: Date_of_Publication
Total Length: 378000 characters ( i.e10 x 37300 current
user of the U of K Library plus an
anticipated increase in of 500 which will
add another 100.000 x10 characters).
Total number of records: 37800
RECORD NAME Bill of Lost Book (s)
Field Name: Bill_number
Field size and length: 5
Type: Alpha-numeric
Format: 9999x
Index (es) by: ____
Total Length: 2288035 characters ( i.e 5 x 357607 current
holdings of the U of K Library plus a
projected increase in holdings of up to
100,000 which will require 100.000 x5
characters).
Total number of records: 3437607 Projected increase in the next five
years)

Field Name: Price_Of_lost_Book


Field size and length: 6
Type: Alpha-numeric
Format: 9999xx
Index (es) by: ____
Total Length: 2745642 characters ( i.e 6 x 357607 current
holdings of the U of K Library plus a
projected increase in holdings of up to
100,000 which will require 100.000 x6
characters).
Total number of records: 457607 ( Projected increase in the next five
years)

( Other fields in this record are; book_title, Author's_name, ISSN,


ISBN and
Borrower's_ID which have already been defined in the catalogue record.)

7.3.4 Summary
The information given in the physical design phase can be used to
implement an automated catalogue (physical database and OPAC) for the
U of K library. The details of the record structures, together with the detailed
functional specifications outlined in the previous chapter, will be used to
select a suitable hardware and library management software for the U of K
library. This information, i.e the functional specificatons and the database
description, can also be useful for programmrs who may be requested to
improve on the library management software that may be acquired by
UKLIS. This will be necessary when additional functions are required of the
software.i.e they can customize the software and tailor it to meet more
specific needs of the library users.
CHAPTER EIGHT
PRESENT AND FUTURE TRENDS IN LIBRARY MANAGEMENT
SOFTWARE

This chapter reviews some of the recent technological trends and


highlights their implications for and impact on library management
systems. Most recent technological trends are associated with the ability
of library systems to get access to and exploit the vast wealth of
information available on the Internet. So Library management systems
designers and suppliers have been concentrating, besides the
functionality and user friendliness of the systems, on the
interoperability of their systems, and their coping with and catering for
the requirements of digital information.

8.1 Definition

Library management software is defined as special purpose database


systems that are designed to control the basic activities of a library. A
typical library management system will offer a number of modules
including the following:
• Ordering and acquisitions module – to control the ordering and
acquisition of new stock,
• Cataloguing module – to carry out the maintenance of the catalogue
database,
• Circulation control module – to control the circulation of stock, dealing
with issues, returns, and borrower records, reservations and fines.
• Online Public Access Catalogue (OPAC) – offers an interface to the
catalogue database.
• Serials control – to control all processing associated with serials, such as
ordering, acquisitions, cataloguing, binding and circulation.

In addition to the above modules, which are often called core functions,
a number of library software offer modules for other operations such as
management information, interlibrary loans, and community
information.

Tennant (2003), cited by Maquignaz and Miller (2004) describes the


Integrated Library management System (ILMS) as the most cost-
effective way to handle library infrastructure tasks such as acquisitions,
cataloguing, and circulation.

8.2 Software Packages Options

There are a number of options as far as the selection of library


management software is concerned.
i. Acquire a pre – Written off – the – shelf package.
ii. Acquire a turnkey package incorporating both hardware and software.
iii. Write in – house programs.
iv. Commission the writing of programs.
v. Participate in the formation of, or in, a cooperative that offers access to
software and / or hardware and / or database (s).
In many instances it is sensible to use a commercially available package,
since it is too costly to write a software package locally or to commission
someone to do this, even though a tailor – made package designed
specifically for a given application is most likely to fit all the
requirements of that application.

8.2.1 Advantages of Using Off – the – Shelf Packages

i. They are economical because the investment cost for the initial creation and
latter maintenance of the package is spread over many years.

ii. The package comes as a well – tested set of programs, and the supplier has
sufficient number of clients to justify adequate maintenance
arrangements.

iii. The software producer is likely to be a specialist in that kind of software and
should therefore; produce a better – quality product with valuable
features whose

importance might not occur to a new user.

iv. Packages are well – documented, including detailed system specification,


Identification of hardware requirements input and file specification,
and systems timing and user manuals.

v. Packages are available at short notice and therefore, systems can be


implemented earlier.
vi. Support and advice service should be available from the package supplier.

8.3 Recent Trends in Library Management Systems

The development of integrated library systems (ILS) has and will be affected by
new trends and advances in the area of overall information
management. These areas include such issues as metadata,
communications protocols, and the challenge of integration with the
digital resources and other information systems existent in the Internet.
These issues call for the designing of effective ways of navigating the
Web and linking tools to its vast electronic resources and programmes.

Following is a review of factors impacting on recent trends of library


management systems, with a focus in development in Web technologies
and standards, and their implications for library management systems.

Ebenezer (2002) points out that the present and future integrated library
management systems (ILMSs) are characterized by the following: they
• Use multi-tiered client/server architecture and TCP/IP
networking protocols.
• Have Web-based OPACs
• Employ graphical interface for library maintenance functions.
• Support UNICODE, hence the use of non-Western characters
• Have an object oriented architecture
• Are built on industry-standard relational database management
systems (RDBMS)
• Are Z39.50 compliant (client and server)
• Support the Interlibrary lending (ILL) protocol (ISO 10160/61)
• Are Electronic Data Interchange (EDI) compatible.

An additional trend in modern library management systems is their inclination


towards a modular architecture based on software components and
well-defined application programming interface (API) which allows
faster upgrading of software. This is particularly relevant to the Open
Source Software (OSS) reviewed below.

The “Top Tech Trends” web- pages of the British Library and information
Technology association outlines the following aspects of development in
library automation;
• The impact of computer industry developments and
standards (technical and metadata), in particular Z39.50, XML,
Java, and Web services;
• The use of customization and personalization technologies;
• The emergence of partnerships between integrated library
systems vendors and digital content providers;
• Integration of many aspects of information service
provision between libraries, museums and archives regarding the
development of digital collections, and between library and
computing services in universities; between special libraries and
other corporate information systems within their host
organizations;
• A move to enhance the scope and content of the library
OPAC, to use it as a tool for integrating access to
information resources; the requirement to support
resource sharing and document delivery functions.
• The Open Source Software movement;
• The advent of the Application Service Provider model for
outsourcing of services; and
• The move to wireless applications.

Following is a brief definition and discussion of some of the recent


technological characteristics of modern Integrated Library
Management Systems (ILMSs).

8.3.1 Client/Server Architecture

An online document posted on the Internet by the Carnegie Mellon


University highlighted that the term client/server was first used in
reference to personal computers on a network. According to the this
paper “This software architecture is a versatile, message-based and
modular infrastructure that is intended to improve usability,
flexibility, interoperability, and scalability as compared to
centralized, mainframe, time sharing computing”.
The Carnegie Mellon university paper proceeds to define a client as
“the computer which requests services whereas the server is the one
which provides that service”. This paper highlights the fact that a
single computer machine can be both a client and a server depending
on the software configuration. This type of architecture emerged as a
result of the limitations of file sharing architecture. It introduced a
database server to replace the file server and by using a relational
database management system (RDMS), user queries could be
answered directly. One of the important advantages of client/server
architecture is that it reduces network traffic by providing a query
response instead of transferring the whole file. It also improves
multi-user updating through a Graphical User Interface (GUI) to a
shared database. In this type of architecture, Standard query
language (SQL) statements are used to communicate between the
client and server.

Ebenezer (2000) explains the distinction between two types of client/


server systems: two and three tier systems. In two- tier systems, the
client software system has both the Graphical User Interface (GUI)
and the application programme, whereas in three –tier systems, the
user interface programme still resides on the client, and the data on
the data server, but a third layer, the application server, is interposed
between them. The application components can be distributed over
several machines. They are connected by the software called
middleware.
8.3.2 Web Technologies and Metadata Standards

There are three emerging Web technologies and standards that are
affecting and will continue to affect the development of library
management systems. These three technologies are interrelated and
deal mainly with metadata; they are the Z39.50, XML, and Java
which is very important for the development of Web-based library
systems.

Hodgson (2002) defines the term “metadata” in the “RFP Writer’s


Guide to Standards for Library Systems published by the National
Information Standards Organization, as “data about data”.
Metadata schema is being developed to help in cataloguing web-
accessible electronic resources and items in locally digitized
collections. The use of metadata to catalogue information resources
has the following advantages:
• Improved accessibility and rerievability;
• It provides more effective relevance ranking of search
results;
• it acts as a surrogate for a resource such as a large file
that could be time-consuming to download or view,
raw data that require an explanation to understand, or
even a resource not available in electronic form; and
• It assists in legal issues of intellectual property rights
identification, tracking, and management.

8.3.2.1 Metadata Standards


There are a number of different kinds of metadata that are
associated with an information resource, which can address
different aspects. Theses are described below:

i. Descriptive metadata identifies the resource and

provides data about its contents.

ii. Administrative metadata is used to manage the


resources; such as version numbering.

iii. Technical metadata provides system-related


information about the resource such as the file type
or format or resolution level of an image.

iv. Use metadata can keep track of usage and users.

There are three metadata standards, which are associated with


library work; these are the Dublin Core, the VRA Core, and the
Encoded Archival Description (EAD).

8.3.2.1.1 Dublin Core


This is short for The Dublin core Metadata Element Set. It is an initiative, which
began at a 1995 workshop (in Dublin, Ohio), the purpose of which is to improve discovery
of networked information resources. The Dublin Core has developed into
an official standard of the American National Standards Institute (ANSI) and the National
Information Standards Organization (NISO), and is now a well-known
and referenced metadata standard. It consists of fifteen elements defined for the description
of any type of resource. These elements are:
Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation,
Coverage, and Rights. Dublin Core has been given official standing with the World Wide Web Consortium (W3C) and the Z39.50
standards initiatives. This standard is maintained by The Dublin Core Metadata Initiative (DCMI) agency.

McCallum (2000) highlights the following points about the Dublin Core:
i. A basic set of 15 data elements for resource description with minimal
content rules. The data elements are clear enough for the author of a web
document can supply them without training.
ii. Dublin Core is also an officially expanded set of elements. The
expansion is for qualifiers that refine the fifteen basic elements and
others that allow naming of the content rules for the data (the rules for
formulating data element content e.g. AACR2 and DDC).

Rust (1998) criticizes the Dublin Core metadata set as lacking the necessary
elements to support copy right; He stressed that Dublin Core supported information
discovery, but not the terms and conditions on which a copy could be accessed.

8.3.2.1.2 VRA Core


This stands for Visual Resources Association Core Categories developed by The
Visual Resources Association. It consists of a metadata set of 28 elements called the VRA Core, designed to describe works of
Art, architecture, artifacts, and comparable cultural objects. A visual resource collection needs at least two records for a given
item: one record to describe the physical object i.e. the “Work”, and another record to describe each surrogate of the object which
is

created for viewing online or offline i.e. the “Image”. The VRA Core includes a
record type element used to distinguish between Work records and Image records.
The VRA categories have been mapped to Dublin Core and MARC format and too
many others related visual art cataloguing schemas.

8.3.2.1.3 Encoded Archival Description (EAD)


The Encoded Archival Description is an encoding scheme for archival
and manuscript collection finding aids, which provides access to other
information by describing in detail an archive’s holdings. The EAD
standard supports the interrelationship between the data content of
catalogue records and finding aids by providing a MARC equivalency
attribute, matching MARC field numbers, for related findings and
elements. The Maintenance Agency for the EAD is the Library of
Congress, Network development and MARC Standards Office, in
partnership with the Society of American archivists.

8.3.2.2 Web Technologies

8.3.2.2.1 Z39.50
The Z39.50 has been developed as a protocol to facilitate the interoperation of
integrated library systems.

Lunau (2000) defines the Z39.50 as a communications standard which


describes the rules and procedures for communicating between two
computer systems for searching and retrieving information from
databases. It enables a remote source to be searched using the interface
of the local client, doing away with the need to master a variety of
search interfaces and facilitating the integration of bibliographic
resources. The Staffweb Internet site of the Northwestern University
Library has posted a paper on the Z39.50. This paper highlights the fact
that the Z39.50 “ enables a user in one system to search and retrieve
information from other computer systems that have also implemented
Z39.50, without knowing the search syntax that is used by those other
systems”.

The Staffweb paper also points out that the Z39.50 is an American
National Standard originally approved by the National Information
Standards organization (NISO) in 1988. The Z39.50 protocol is based on
client/server architecture (explained in section 8.3.1). The protocol
standardizes the message that clients and servers use regardless of the
underlying software, systems, or platforms. A client system that
implements the Z39.50 protocol, which is called a Z-client, allows
communication with diverse servers, and a server system that
implements the protocol, which is called a Z-server is searched by
clients developed by different vendors. The protocol is independent of
the underlying transport mechanism, but most current implementations
are carried out by using the TCP/IP over the Internet. The Z39.50 was
designed to help with searching library bibliographic catalogues
utilizing different library system software. It is now used to access a
wide range of databases in many disciplines across a variety of
organization types. A library implementing Z-client technology can give
their users access to any Z-server compliant database without the user
having to know that system’s native search interface. Libraries can
adopt a single standardized Z39.50 interface to enable their users to
simultaneously access the library’s catalogue, CD-ROMS, online
databases subscribed to, and Internet resources. The Z39.50 standard
can be used to access and retrieve all multimedia information including
text, images and digitized documents. The Library of Congress is the
designated Z39.50 maintenance agency. There is also a voluntary group,
the Z39.50 implementation Group (ZIG), which holds regular meetings
to discuss implementation issues and recommend improvements to the
protocol.

An online article in the Biblio Tech Review (at


www.bibliotechreview.com), highlights the typical simplified search
process involved in a Z39.50 session as the following:
• OPAC user selects Target library (Z-server) from an OPAC
menu.
• OPAC user enters search terms.
• OPAC software sends search terms and Target library details to a “Z-
client” a piece of software usually running as part of the library
system.
• Z-client translates the search terms into “Z-speak and contacts the
target library’s Z-server software.
• There is a preliminary negotiation between the Z-client and Z-server
to establish the rules for the “Z-association” between the two systems.
• Z-server translates the “Z-speak” into a search request for the Target
library’s database and receives a response about numbers of matches
etc.
• Z-client receives records.
• Records are presented to the OPAC interface for the user.

The latest version of Z39.50 allows search statements to be defined by using the
following features:
• Complex Boolean statements involving all standard Boolean
operators AND, OR, NOT.
• Comparison operators for databases e.g. greater than, equal to,
or less than.
• Proximity searching.
• Truncation.
• Completeness i.e. part of field, complete field etc.

A National information Standards Organization (NISO) document (2004) deals with


the Z39.50 protocol from the viewpoint of Interoperability of library systems. It
states that “as the role of the library changes, its ability to access and be accessed
becomes paramount and this involves interoperability… Interoperability requires
standards on several levels. It is necessary to standardize both what is being
exchanged (data elements), how to structure it for exchange, and how to actually
exchange it. (Protocol transactions and messages and profiles.) The Z39.50 falls in
this last category of protocol standards. The NISO document highlights the
following components of information retrieval that are addressed by the protocol:
• Searching and presenting results
• Sorting of the results before presentation, so that only the
most recent are presented from a large results set.
• Removal of the duplicates from the set
• Negotiating retrieval of large results sets (segmentation,
query refinement etc.)
• Retrieval of selected contents
• Browsing indexes and thesauri
• Restricting access to authenticated users
• Extended services including placing orders, updating files,
regular repeating queries, saving results sets and
exportation of data.

Ebenezer (2000) describes the potential implications of Z39.50 for library services and systems as
profound. She outlines these implications in the following areas:
• Z39.50 tools allow the searching and downloading of
bibliographic records in MARC format, which has
implications for the sourcing of catalogue records.
• It permits the development of user-mediated document supply
and Selective Dissemination of Information (SDI) services.
• Z39.50 OPACs allow the extension of bibliographic access to
other Z39.50-enabled systems, allowing the growth of virtual
union catalogues which are cheaper and easier to maintain
than physical union catalogues.

8.3.2.2.2 XML
The eXtensible Markup Language (XML) is a format for structured documents and data on the
Web. It is a subset of SGML, the international Standard Generalized Markup Language defined in
ISO 8879, which was developed for technical documentation before the Web existed. Hudgson
(2002) outlines the following components of XML that make it a powerful Internet tool:
• Open system approach – XMl is non-proprietary and utilizes
ASCII, making XML data machine independent and
accessible across computing platforms. `
• Separation of content and display – XML coding focuses on
the structure of the document with the intent that it can then be
reused and customized for different purposes. Separate style
sheets can be created using eXtensible Style Language (XSL),
or any other tool, to define particular display or print formats.
• Extensibility- XMl is called extensible because it allows the
creation of customized markup tags and applications. This
allows groups of people or organizations to create their own
customized XML applications for exchanging information in
their domain.
• Internationalization- XML utilizes Unicode, a single
comprehensive character set that encompasses virtually all of
the world’s written languages.
• Database interoperability- XML uses the concept of a
document composed of a series of entities, which can contain
one or more elements. This component nature of XML
accommodates interfacing with a database, since XML tags
can be mapped to database fields, and makes it very suitable
for sorting the XML in a database, as whole documents or in
components for greater repurposing capability.
• Extended linking- XML’s linking capabilities go beyond the
simple HTML one-way hyper linking from point A to point B.
XML links can be to multiple targets, activate automatically,
embed or replace information, or be defined “out of line” in a
separate document.
• Metadata support- the metadata describing a document can be
explicitly tagged with XML, making the data much more
useable and searchable than HTML’s meta-tags allow.
The XML has superseded the Hypertext Mark-up Language
(HTML) as the basis for structuring information objects on the
World Wide Web; Payne (2000) explains this as follows “XML
enforces the separation of content and information and how it is
to be displayed, the mixing of which in HTML is one of its
greatest weaknesses”.

The implication of the XML for Integrated Library Systems (ILS) is in the interfacing of
these systems: by using the XML as the common input/output format, the traditional
library system could be more easily integrated with the Internet technology and other
proprietary systems. Newly developed tools or systems would not require separate special
interfaces to be written. It is expected that a totally XML-based integrated library
management system is likely to come out in the near future.
Herwijnen (2000) outlines the following advantages of XML for libraries:
i. The structure and markup of an XML document
facilitates the creation of document databases, while
at the same time XML content can be delivered on the
Internet or on a CD-ROM.
ii. The “meta-data” can be explicitly read from the XML
tags, provided that libraries can agree on a standard
set of tags. For books and journals, the meta-data is
captured in the form of a bibliographic “MARC”
record, that has to be created by hand and added to the
libraries database. XML would thus obviate the need
for MARC records.

8.4 Open Source Systems (OSS)


Open Source Systems (OSS) are software created and maintained by software developers and
made available for free to institutions and organizations. The Open source initiative defines the
OSS in the following way “Open source promotes software reliability and quality by supporting
independent peer review and rapid evolution of source code. To be certified as open source, the
license of a programme must guarantee the right to read, redistribute, modify, and use it freely.”
Chudnov (1999) highlights the following aspects of Open Source Systems:
• Open source software is typically created and
maintained by developers crossing institutional and
national boundaries, collaborating by using internet-
based communications and development tools;
• Products are often offered free to use through a license
that specifies that applications and source code ( the
programming instructions written to create the
applications) are free to use, modify, and redistribute as
long as all uses, modifications, and redistributions are
similarly licensed;
• Successful applications tend to be developed more
quickly and with better responsiveness to the needs of
users who can readily use and evaluate open source
applications because they are free;
• Quality, not profit, drives open source developers who
take personal pride in seeing their working solutions
adopted;
• Intellectual property rights to open source software
belong to every one who helps build it or simply uses it.
Open Source Systems have the two important advantages for libraries:

i. They give libraries direct control over the technology


they use; and
ii. Systems librarians can develop the software and focus
on local functional requirements;

There are a number of experimental open source library systems that are believed to have the
potential of competing with the available off-the –shelf commercial packages. These include the
following systems:
i. OSDLS/Pytheas; originated in 1999 by a medata librarian at
the University of Arizona as a result of dissatisfaction with
vendor-based systems.
ii. Koha; developed in 1999 by a small team of programmers
working for a consulting company in New Zealand to address the
needs of small library branch.
iii. OpenBiblio; has been consistently developed since the year
2002. It is now the most user- friendly, intuitive open source
Integrated Library System available on the free market.

8.5 Application Service Providers (ASP)


ASPs are internet-based services that allow one to rent software on a per-use or
subscription basis. The software and data sit on the ASP’s server and is accessed via a
simple Web connection, available to anyone within the customer organization
(Dzurinko 2003). Ebenezer (2002) explains the role of ASP’s in the library context as:
“A library ASP hosts a library’s database at a central location, manages the system
application software, and provides hardware and software support for the application.
The library’s PC acts as a thin client, i.e. provides access to the system software via a
web browser through the library’s firewall. Data content and integrity remain under
the control of the library, hardware and software maintenance and support lies with the
vendor.”
For libraries, the ASP is regarded as a communications/support package through which a vendor takes care of software, hardware,
and system support, whereas the library concentrates on the management of data content, maintenance of data integrity, and
delivery of library services.

To use an ASP, all the library needs is a high-speed internet connection and a web
browser. Nevertheless ASP’s have a number of shortcomings, specifically in the
areas of security, customization, and cost.
CHAPTER NINE
SUMMARY AND CONCLUSION

9.1 Summary and Conclusion


The purpose of this research has been to investigate and analyze the University of
Khartoum Library System (UKLIS) in terms of its activities and operations. This
has been done by studying the different functions and procedures carried out in
the core subsystems of the UKLIS under study. These core subsystems are the
Acquisitions subsystem, the Catalogues subsystem, and the Circulation or Reader
Services subsystem.
This study has been embarked on with the following hypotheses in mind:
i) The manual system of the University of Khartoum Library is
the major reason for the ineffectiveness of the U of K library
services;
ii) There are problems in the flow of information among the
different U of K Library subsystems;
iii) Weaknesses in the existing manual library system can be
eradicated by the introduction of a computer-based Integrated
Library Management System (ILMS).

The outcome of the UKLIS analysis and investigation has proved the above-
mentioned hypotheses to be true. Consequently, the functional requirements of a
proposed Integrated Library Management System (ILMS) have been specified
and outlined.
The analysis of the UKLIS has been started by obtaining some background
information about the environment of the system under investigation, i.e. the
University of Khartoum (U of K). The study then proceeds to pinpoint the area
under study of the UKLIS. This area consists of the three core subsystems of the
UKLIS, namely,
i) The Acquisitions Subsystem,
ii) The catalogues Subsystem, and
iii) The Circulation or Reader Services subsection.
Each of the above core subsystems has been analyzed in terms of the
functions and procedures carried out by the respective subsystems. The
analysis is followed by highlighting and pinpointing the weaknesses and
limitations of each subsystem.

In performing the investigation and analysis of the UKLIS, the researcher


has followed well-established methods and techniques of systems
analysis. These methods and techniques included the utilization of
graphical tools, such as the Data Flow Diagrams (DFDs), to document the
existing system. The Data Dictionary is another documentation tool used
to define the different components of the DFDs. Other documentation
tools used in this study include the Document/ Data Item Grid, and the
Input/Process/Output (IPO) diagrams.

As for the techniques of data collection, these include interviews with key
persons in the subsystems under investigation, observation, document
analysis, and literature review.
The findings of the UKLIS investigation and analysis have proved the
research hypotheses to be true; below are some of the major findings of
the UKLIS analysis:
i) There are defects in the information flow within the
library system; for example, books are transferred from
some library sections to others without proper
documentation;
ii) Lack of automation and computers in almost all of the
UKLIS sections; resulting in backlogs in the system.
iii) The UKLIS catalogue is isolated from other libraries’
catalogues whether internally or externally;
iv) There are problems of tracking and controlling library
materials in the Circulation Subsystem;
v) There is need for statistical analysis for the activities of
the Circulation subsystem to be used for management
purposes;
vi) More than one classification system is implemented by
the UKLIS, threatening of a chaotic situation in the
library shelving system in the future.

In light of the pitfalls and weaknesses of the existing manual system at the U of
K Library, and based on what the library system should be able to do in order to
fulfill its objectives of satisfying the users needs of library and information
services, a Specific Requirements Definition for a proposed computerized library
system has been worked out. This requirements definition has recommend that
the proposed system should consist of seven types of file; these are: the Title file,
the Borrower file, the Subject file, the Vendor file, the Budget file, the Payment
file, and the statistical file.

The Requirements Definition recommended that the proposed system be an


integrated system. The Requirements Definition then proceeds to outline the
different outputs/processes/ and inputs of each of the three core subsystems under
study. The Requirements Definition also has highlighted the hardware expected
to be utilized by the proposed system, including the input and output devices.
The system database is an important component of the Requirements Definition;
a lengthy data base description has been carried out, based on the findings of the
existing U of K Library System. The data base description has included the
design of the conceptual and logical database for the proposed library system, in
addition to the partial design of the physical database for the Catalogues
Subsystem and its OPAC interface.

Bearing in mind the benefits and characteristics of Integrated Systems, an


Integrated Library Management System (ILMS) has been proposed to eradicate
the weaknesses in the existing U of K Library manual system. In this regard, a
detailed Functional Specification of an Integrated Library Management System
(ILMS) has been outlined. These specifications are based on the functions and
activities that the U of K library system is performing or expected to perform in
the future. The detailed specifications are meant to be used by the U of K
administration to assist in writing a Request For Proposal (RFP) that will be sent
to ILMS suppliers so they can provide the library with the most suitable system.

The detailed functional specifications are categorized under four main categories,
namely:
i) Acquisitions Control;
ii) Cataloguing and Database Maintenance;
iii) OPAC; and
iv) Circulation.

Each of the above main categories is subdivided into smaller categories,


covering almost all of the activities and functions expected to be performed by
the proposed ILMS.

The proposed ILMS is recommended to be an up to date, functional, and


flexible system. It is expected to incorporate all of the features that enable it to
interoperate and deal with the ever-changing environment of digital and
electronic information sources and content available on the Internet. These
recommended features include incorporation of the Z39.50 communication
protocol, the Dublin Core Metadata Initiative, and the Extensible Markup
Language (XML), and many more cutting edge technologies.

Currently, there are several library management software in the market (off- the-
shelf packages) some of which are based on the relational model, which has been
recommended by this study. Below are some of the most popular library
management systems used in academic and university libraries all over the world.
(See Appendix 5 for an alphabetical list of the library software available in the
international market)
• Voyager Integrated Library Management System., Produced by
Endeavor Information Systems. This system supports non-Roman scripts
such as Arabic scripts. Widely used in the USA, Australia, and New
Zealand.
• Aleph500 Library and information Management System. Produced by
Ex-Libris.With multilingual support. Widely used in the USA, Europe,
and China.
• Unicorn Library Management System. Produced by Sirsi Corporation.
• Millennium Library Automation System. Produced by Innovative
Interfaces.
• Horizon Integrated Library Management System. Produced by Dynex,
with an Arabic Language version.
• AMICUS. Produced by Extended Library Access Solutions (EliAS).
With an Arabic Language version.

Integrated Library Management Systems (ILMS) developers and suppliers are


doing their best to meet the demands and requirements of the new electronic
information environment. However, Maquignaz and Miller (2004) are skeptical
about the Integrated Library Management Systems (ILMSs) being able to cope
with the different aspects of web information. They quote Kennedy (2003) as
saying “integration, metasearching, open source software and the internet are all
pushing the ILS in new directions”. Integrated Library Management Systems
have to address the pertaining issues of E-Services in order not to be bypassed by
the rapid technological developments.
BIBLIOGRAPHY

Adam , Radia (1985) “ The Role of Governments in Planning and


Developing Library and Information Services (LIS) in the Sudan and
the Region of Eastern Africa : A Comparative Study” A PhD thesis in
LIS, University of London , School of Archives and Information
Studies.

Anctil, Eric and Beheshti, Jashmid (2004) “Open Source Integrated


Library Systems : An Overview”. Available at :
http://www.anctil.org/users/eric/oss4ils.html

Association of Research Libraries (1995) “Definition and Purposes of a


Digital Library”. An online document available at:
http://www.arl.org/sunsite/definition/html

Avison, D. and Fitzgerald, G. (2002) “information Systems


Development : methodologies and Tools. 3rd ed. McGrawHill.

Bailey,Charles (1990) “Libraries with Glass Walls” in The Public- Access


Computer Review 1, No.2 (1990):91-93. Available online at:
http://info.lib.uh.edu/pr/v1/n2/bailey.1n2

Baker, David (2002) “ Digital Library Development” , supporting


documents of the Digital Library workshop held in Khartoum, December
2002.
Bansal, Ram. (2000) “ Systems Analysis and Design : A modern
Approach to Systems Development” New Age International Ltd. New
Delh.
Bjrneborn, Lennart (2004) “ Small-World Link Sructures Across an
Academic Web Space – A Library and Information Approach”. PhD thesis
from the Department of Information Studies, Royal School of Library and
Information Science, Denmark. Available at:
http://www.db.dk/lb/home_uk.htm.phd

Boss, Richard W. (2004) “Client Server technology”. An online


document available at:
http://www.ala.org/ala/pla/plapubs/technotes/clientserver.htm

Buckland, M. K. and Gallvin, B. (1972) “Circulation Control: Online,


Offline or Hybrid”. In Journal of Library Automation 5, 30 – 8 (1972).

Burch, John G. (1992) "Systems Analysis, Design and Implementation",


boyed &fraser publishing company. Boston.

Carnegie Mellon University (2004) “ Client/Server Software Architecture :


An overview” available at :
http://www.sei.cmu/str/descriptions/clientserver_body.html

Carpenter, Julie (1991) “The Rehabilitation of the University of Khartoum


Library and Information Services” . International Library and Information
Development, Oxford.
Chudnov, Dan (2003) “Open Source library Systems: Getting Started”. Available at:
http://www.oss4lib.org/

“ Database Management Systems” in Bibliotech Review: Information


Technology for Libraries. 2001. Available online at:
www.Bibliotechreview

Date, C. J. (2000) “Introduction to Databae Systems”. 7th ed., Wesley


Publishing Company, Massachusetts.

Davis,Gordan, Band Olson , Margarethe H. (1985) “ Management


Information Systems,Concepts, Structue, and Development” 2nd ed.
MeGraw- Hill.

Deddens, Marcia (2002) “Overview of Integrated Library Systems”. An


online document available at:
http://www.educause.edu/ir/library/pdf/DEC0201.pdf
Dewitz, Sandra Donaldson (1996) “ Systems Analysis and Design and the
Transition to Objects”. McGraw- Hill , New York.

“ Definitons of Systems and Models” , an online document available at the


PhysicalGeography.net at:
http://www.physicalgeography.net/fundamentals/4b.html

Dolan, A . K . and Kroenke , M.D. (1983) “ Database Processing :


Fundamentals, Design and Implementation”. 3rd ed. MacMillan Publishing
Co. New York.
Downs, J.E (1985) “Basic Systems Design”. Stanley Thornes, Leekhamton .

Dzwrinko, Mary K. (2000) “ Application Service Providers”. In


Intrgrated Library Systems Report (ILSR), Nov. 2000. Available at:
http://www.ilsr.com/asp.htm.

Ebenezer, Catherine (2002) “Overview and Evaluation of Present Trends


in library management Systems” available at:
http://www.dlist.sir.arizona.edu/archive/00000241/01/whither_integrated_lib
rary_systems.doc
Fisher, Shelagh and Delbridge, Rachel (2001) “Harmonizing the Process
of Procuring Library management System : A Feasibility Study”.
Available at:
http://www.cerlim.au.uk/projects/harmonize/harmonize.pdf

Fitzgeral, Jerry and Fitzgerald, Ardra. F (1987) “ Fundamentals of


Systems Analysis : Using Structred Analysis and Design Techniques”,
3rd ed. John Willy & Sons, New York.

Gangolly, Jagdish S. (1997) “Systems analysis and Design”. An online


document available at:
http://www.albany.edu/acc/courses/fall97/acc681/ch7.html

Gatenby, Janifer (2000) “Internet, Interoperability and Standards:


Filling the Gaps”. Available at the National Information Standards
Organization’s website at: www.niso.org
Genanoy, D. C. (1994) “ Integrated Online Library Systems: Principles,
Planning, and Implementation”. While Plains , New York .

Gradute College Prospectus (1994), University of Khartoum . Khartoum

Harris, David (1995) , “ Systems Analysis and Design: A project


Approach” . Harcourt Brace & Company, New York .

Hawes, DFW and Botten, DA. (1983) “ Library Automation at the


Polytechnic of the South Bank”. The Library Association, London .

Herwijnen, Eric (2000) “The impact of XML on library procedures and


services” an online document available at:
http://www.lhcb.web.cera.ch/lhcb/~euh/xmlandlibrary.htm

Heseltine Richard (1993) “New Directions in the Library Automation


Industry: The Prospects for structural Change”. In Copmuters in Libraries,
Proceedings of the Seventh Annual Computers in Libraries International
Conference held in london in February1993. Mekler, London.

Hodgson, Cynthia (2002) “The RFP Writer’s Guide to Standards for


Library Systems”. Available at the NISO website at: http://www.niso.org

Hoffer, J.A et al (1999) “ Modern Systems Analysis and Design”. The


Benjamin/Cummings Publishing. New York.
Hunter, M. Gordon (1998) “ System Development Case Studies”. The
McGrawHill Companies, New York .

Introduction to Data Flow Modelling (2003). An online document


available at: http://www.doc.mmu.ac.uk/online/SAD/T04/dfds.htm

Introduction to Methodologies and SSADM (2003). An online document


available at:
http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

Kendal, Kennith E. and Kendal, John E. “ Systems Analysis and


Design”. Prentice Hall International.

Kenney, Brian (2003) “The Future of Integrated Library Systems:An LJ


Round Table” in Library Journal. Available online at:
http://www.ixiasoft.com/document.asp?docname=/pdf/LibraryJournal_june-
2003.pdf

Kimber, R.T. (1974) “ Automation in Libraries”. 2nd ed, Pergamon Press.

Korth, Henry F. and Silberschatz, Abraham (1991) “Database System


Concepts”. 2nd ed. McGraw-Hill, Inc. New York.
Kroenke, David M (1983) “ Data Processing : Fundamentals, Design,
Implementation” 2nd ed. Science Research Associates Inc.

Chicago .

Latham, Stephen J. (1993) “Open Systems and Libraries”. In computers


in Libraries international, Proccedings of the seventh Annual Computers in
Libraries Internationa Conference held in London, February, 1993, pp76-79.
Meckler, London.

Laurie, P. (1985) “ Databases : How to Manage Information on Your


Micro”. Chapman and Hall, London .

Lopata, Cynthia l (1995) “Integrated Library Systems” . In Eric Digest


April, 1995. Available online at:
http://www.ericfacility.net/databases/ERIC_Digests

Lovercy, Ian (1984) “ Automating Library Procedures : A Survivor’s


Handbook”. Library Association Publishing, London .

Manjunath, G. K (2004) “Library Automation: Why and How?” An online


document available at: http://www.igidr.ac.in/lib/paper1.html
Maquignaz, Laura and Miller, Jane (2004) “The Centrality of the
Integrated Library Management System: a Strategic View of Information
Management in an E-Service Environment” an online paper available at:
www.vala.org.au/vala2004pdfs/02MaqMil.PDF

Marvin, Gore and Stubble, John W. “ Elements of Systems Analysis”.

4th ed. Wan. C. Brown Publishes.

Mbaakanyi, Duduzile M (1993) “Library automation at the University of


Botswana”. In Survival Strategies in African University Libraries: new
Technologies in the Science of Information. Proceedings from a workshop,
University of Zimbabwe, Harare.

McCallum, Sally (2000) “Extending MARC for Bibliographic Control in


Web Environment: Challenges and alternatives. Available at:
http://www.loc.gov/catdir/bibcontrol/mccallum_paper.html
McDonald, A C (1994) “A Strategic Assessment of the University of
Khartoum Library”. The British Council, Khartoum.

McLeod, Raymnd (1983) “Management Informtion Systems” . Science


Rsearch Assocution , Inc.Chicago.

Michael, H. B. (1987) “ Developing Data Strucured Databases”.


Prentice - Hall Inc. , New Jersey .

Millard, Maree (1999) “Tips and Hints on Library Automation and


Automated Library Systems”. Available at:
http://www.home.aone.net.au/libauto/Tips.html

Miller, Paul (2000) “ Interoperability What is it and Why should I Want


it?” in Ariadne, issue 24 sept 2000. Available online at:
http://www.ariadne.ac.uk/issue24/interoperability/intro.html

MINISIS Integrated Library System Overview (1993). A document


published by the Software Development and Applications Group of the
Information Sciences and Systems Division of the IDRC, Canada.

Moscoso, Purificacion and Teresa Malo de Molina (1999) “ And After


Automation, What? Spanish Libraries and the Challenge of Modernization”.
In Journal of Librarianship and Information Science, 13 (2).
O’Connor, Joseph and McDermott, Ian (2004) ‘The Art of Systems
Thinking” . Available online at:
http://www.itsnlp.com/products/artsystems.htm

Ogg, Harold C. (1997) “ Introduction To The Use of Computers in


libraries : A textbook for Nontechnical Students”. Information Today, Inc.

Osborne, Larry (1998) “Systems Approach to Library Operations” a


course outline available online at:
http://www.hypatia.slis.hawaii.edu/~osborne/647/647syl.pdf

Payne, Geoffrey (2000) “Future Library Systems: beyond the Electronic


Card Catalogue” An online document available at:
http://www.vala.org.au/vala2000/2000pdf/Payne.PDF

Provost, Wallace H. (2004) “ Structure and Change in Complex Systems”.


Available online at: http://www.n4bz.org/gst/gst1.htm

Rajaraman, V. (2000) “Analysis and Design of Information Systems”. 2nd


ed., Prentice-Hall of India, New Delhi.

Rowley, Jennifer (1996) “The Basics of Information Systems”. Library


Association Publishing, London.

Royan, Bruce (1993) “IT Applications in Library and Information


Systems: Trends in the UK”. In LATIG, The Journal of the Library
Association Information technology Group.No. 26 pp 28-31, Jan 1993.
Rust, Godfrey (1998) “Metadata: The Right Approach: An Integrated
Model for Descriptive and Rights Metadata in E-commerce”, in D-Lib
Magazine July/August 1998 available at:
http://www.dlib.org/dlib/july98/rust/07rust.html

Saffady, William (2000) “The Status of Library Automation at 2000” in


Library Technology Reports 36 (1) available online at:
http://nnlm.gov/psr/lat/v36n5/ltr_review.html

Salah Eldin, Mohamed (2003) “The Use and Perception of Internet


Resources and Their Impact on Library Services: An analytical Study
Among Sudanese Librarians”. A PhD Thesis in LIS, University of
Khartoum, Graduate College, Khartoum.

Satzinger, John W. (1993) “Introduction to Essential Systems Analysis”.


An online document available at: www.cis.smsu.edu/satzinger/satzpub.htm

Schlabach, Martin L. and Barness, Susan J. (1995) “ The Mann Library


Gateway System”. In The Public-Access Computer Systems review, Vol. 5
No.! (1995) pp 5-19. Available online at:
http://www.informations.com/serials/pacsr/pr-v5n01-sclabach-the.txt

Schmidt, Ingrid (2003) “Library Management Systems (LMS)”. Available


at: http://www.newsmediasales.com/kontakt.html
Shareef, Sami Mohamed (2002) “University of Khartoum Network
Project (UofKnet): The Project Documents”. Khartoum University,
Khartoum.

Shepherd, C. J. (1990) “ Database Management: Theory and Application”.


Richard, D. Iwrin Inc.

Simkin, Mark G. (1987) “ Introducion to Computer Information Systems


for Business”. W. M. C. Brown Publishers, Iowa.

Simmons, GL. (1997) “Introducing Systems Analysis and design.” The


National Computing CentreLtd.

Skidmore, Steve. (1997) “ Introduing Systems Analysis”. 2nd ed.


Macmillan Press, London.

State University of New York (2004) “ Integrated Library Management


System : Request for Proposal” available at:
http://www.sunyconnect.suny.edu/slam/SLAMr/fp.doc

Stephen Pinfield et al (1998) “Realizing the Hybrid Library”. In D-Lib


Magazine, Oct. 1998. Available online at:
http://www.dlib.org/

Structured Systems and Design Method (SSDM) (2003). An online


document available at: http://www.sandhill.co.uk/methods/
Teague, Lavette C. and Pidgeon Christopher. (1985) “ Structural
Analysis Methods for Computer Information Systems”. Science Research
Association, Chicago .

Ted, Lucy A. (1993) “ An Introduction to Computerized Library Systems”.


3rd ed. John Willy, Chichester.

Teigen, Karen (1998) “ Justification for Library Automation” in Integrated


Library Systems Reports. Avaialble online at:
http://www.ilsr.com/justify.htm

Simons, GL. (1979) “Introducing Systems Analysis and Design”. The


National Computers Center Ltd.

Thierauf, Robert J. (1980) “ Systems Analysis and Design : A Case Study


Approach” 2nd ed. , Bell and Howell Company.

University of Alabama Libraries (2004) “ Request For Information.


Available at: http://www.usg.edu/galilo/rfp/alabama.html

University of Khartoum Library (1993). Annual Report of 1993 to be


submitted to the University Senate.

Wasserman, Anthony (1980) “Information System Design


Methodologies”. In Journal of the American Society of Information Science,
Jan. 1980.
Wiederhold, G. (1987) “ File Organization for Database Design “
McGraw-Hill Series, London.

Wetherbe, J.C. (1988) “ Systems Analysis and Design”. 3rd ed., West
Publishing Company, New York.

“What is Interoperability?” Available at the SearchWebServices.com


website at: http://searchwebservices.techtarget.com/sDefinition/O,,sid26-
gci21237,00.html

Whitten, Jeffery L. and Bentley, Lonnie D. (1998) “ Systems Analysis


and Design Methods”. McGraw-Hill Companies Inc, Boston.

Wyllys, R.E. (2002) “Systems Analysis and Evaluation: Elements of a


System and Their attributes”. An online document available at
http://www.gslis.utexas.edu/13875/syselements.html.

Yourdon, Edward (2001) “Tools of Structured analysis”. An online


document available at: http://www.yourdon.com/books/msa2e/CH04.html

Z39.50 (2004). An online document by the Northwestern University


Library, available at:
http://staffweb.library.northwestern.edu/it/support/FAQs/index.html
Z39.50: Part1- an Overview (2004). An online document available at http://www.biblio-
tech.com/
• Acumen & Scope e-Library (formerly F.I.L.M.S) is a comprehensive library
management system that scales easily from small educational libraries to very large
public libraries . Available from Functional Solutions (Vendor) it is Web based
Library Automation software- Z39.50 compliant, RFID enabled.
• ALEPH integrated Library System produced by Ex Libris Ltd.
• ALICE Library Automation Software – known as ALICE in Europe and Australia,
ANNIE in America, EMBLA in Iceland, OASIS elsewhere. Particularly strong in
school libraries but have other markets. Vendor is Softlink (Australia)
• Amicus Client server Library Automation System (markted by Elias) developed
according to the specifications of the Canadian National Library. It was designed to
become a modern replacement product for their DOBIS system.
• Amlib Library Automation Systems from Info Vision Technology limited is a
windows library management system for public, academic, or special libraries.
• ANNIE Library Automation Software produced by Softlink. This is the American
name of the product.
• Athena system. – fully integrated Windows-based system by Sagebrush
Technologies
• Aurora Library systems from Aurora Information Technology. Aurora systems are
designed to provide the maximum to libraries through application of prevailing
standards, and the use of rapid development techniques to ensure appropriate
solutions.
• BlissLib Automated Library System is suitable for small corporate, school, or
personal collections of just about any type of material.
• Bookmark- School Library automation system. BOOK MARK is used by over 1,200
schools in Australia and is also used in schools and institutions in Papua New Guinea,
Indonesia, Brazil, Latvia, The Ukraine, Vanuatu, Malaysia, and the Marshall Islands.
• BuCAT- A library software system developed by TKM in Manitoba for installation
on VAX computers.
• CARL. Solution from TLC Carl is a library automation and management system for
large libraries and consortia. Also known in past as Knight- Ridder’s CARL.
• Concourse is a fully integrated Library System available for Windows
95/98/NT/2000. Available from BOOK Systems Inc.
• Data* Library- Designed for small to medium sized public and special libraries,
Data* library is a fully integrated Library Management System offering full
bibliographic control, circulation, OPAC and more. (Vendor is Altarama)
• Data Trek : Library automation and electronic management.
• DOBIS/LIBIS: produced by Elias.
• Dynix- Owned by Ameritech Library Systems, established in USA, Australia and
Europe. Client Server. Includes the Dynix, Horizon, NOTIS and Scholar products.
• HORIZON- see Dynix
• In Site Software : On- line catalogs for school libraries.
• Knight- Ridder’s CARL : Information and services regarding Knight- Ridder’s
CARL. See above under CARL
• LIBERO- Library Management System form Insight Informatics. LIBERTO
is a comprehensive library management system providing a quality and
cost-effective solution to all major housekeeping functions.

• Library soft Library Automation system by New Generation Technologies Inc.-.


• Library Solution- from TLC Carl is Windows NT based that is totally scalable for
libraries of all size.
• LibriVision (marketed by Elias)
• MAELISA is an integrated Library system based on a 32- bit client/ server architecture
that runs on Windows operating system. It is a user- friendly software package for
academic, special, medical and research libraries and information centers. Marketed by
Library Associates Inc. (Korea), is an affiliate of Kyung IL Technology, Inc. with Korean
and Philippine baser clients.
• Master library Systems by Book Systems, Inc
• WEBRARY-Internet OPAC
• MC2 Systems : Library automation software for DOS Computers.
• Microfusion- Microfution Information Management System software. Used by school
libraries.
• OASIS Library Automation Software produced by Softlink (Australia)
• OLIB7 Library Management System- Q-Ray is OLIB7 distributor in The Netherlands
and Belgium.
• Ovid - offering the library sector Z39.50 client/ server support with web interfacing.
• PC Card Catalog a library automation product for Windows 95/98/NT. PC Card
Catalog is a Windows 95/98 NT system designed for the smaller library (<25,000 items).
Includes catalog lookup; printing labels, lists and catalog cards; Circulation and OPAC
modules produced by DIAKON Systems.
• Resource Mate(r)2.0 isWindows 3.1/95/98/2000/NT/ME/XP Resource Library Software
designed for Church Libraries, clergy, Synagogue Libraries, professionals, Corporations
and private Schools. It features full cataloging, searching and circulating .
• Spydus- Automated Library System from Civicam Pty Limited, is in its third generation.
Spydus is a functionally rich, web- centric application built around open systems concepts.
• Stacks- fully integrated library automation system from Hardcover Software and
ImagiNET Resources Corp.
• TKM- Total Knowledge Management Library systems.
• URSA-Universal Resource Sharing Application- offered by CPS Systems, Inc , is a
solution for Inter Library Loans (ILL). Does not require libraries to use a common
automation vendor in order to do automated resource sharing.
• Voyager library management Systems Client/ server automation systems from Endeavor
Information Systems .
• VUBIS – Library system developed by the University of Brussels.

You might also like