This paper deals with a data model of a software system used to manage library patrons. This system is known as a circulation system and is usually developed within a library management system. The paper discusses functionalities of a circulation system that allows circulation at the level of library consortium. Based on these functionalities, a data model is made that contains all necessary data for managing library users, both local users and users from other libraries within the consortium. The presented model was used in the development of one particular circulation system, but consideration of the following can be useful in the development of any other circulation system as well.
Besides storing and recording a library collection, one of the main activities of each library is to provide that collection to library users. Its business affairs as related to its users are circulation, both within the local collection and the library consortium, and interlibrary loans. There are a number of library management systems that support these processes. On the Library of Congress website for MARC standards there is a section with an overview of library software packages [5]. Some of those software packages which support circulation are ALEPH 500, Voyager, Atriuum, Polaris Library Systems, SirsiDynix Symphony, Evergreen Integrated Library System and Koha.
This paper discusses the functionalities of a software system for circulation of a library collection with emphasis on the circulation within a library consortium. According to these functionalities, a data model is made that contains all necessary data for managing library users, both local users and users from other libraries within the consortium. Data model and functionalities are presented using UML notation. The results presented in this paper were used in the implementation of the library management system BISIS [1] which is deployed and used in a number of university and city libraries throughout Serbia. The results presented could be useful to anyone who is involved in the development of library management systems.
Library circulation includes all activities associated with management of library users such as recording user data, charging and discharging library items. In order to improve library performance, a large number of research papers in this field describe various aspects of circulation and some directions for further development of electronic support for the process of circulation. Internet-oriented services provided to users and internet-oriented communication and data sharing between libraries represents a major direction in which research is headed. The experiences presented in papers [2] and [4] show that the electronic services that libraries provide to users allow more efficient use of either the printed or electronic library collection.
In paper [3] several of those services are described and how they improve the library business.
The most of the software system for circulation is commercial and it is not publicly accessible for downloading. What is possible is to download the accessible instructions for the users and, based on their contents, to analyze the software functionalities. The systems enable standard activities related to the work with the users such as charging and discharging, membership fee renewal, printing lending form and receipt, searching users and publications as well as generating statistical reports. Some of them include the support for UNICODE, bar code and RFID technology, printing and sending reminders to the users for the exceed of loan period and publication reservation. Client applications of the systems are implemented either as Windows applications only supported by the Windows operating systems or as web applications.
A library consortium is an association of libraries in a particular area that work together towards improvement of services for its patrons. One of the activities at the consortium level is consortial circulation. The consortial circulation is a process in which users of one library are allowed to borrow books from other libraries which are members of the consortium. Member libraries of the consortium set up rules for the usage of library collections. Good examples for library consortiums are public libraries that are composed of several libraries in a city area or university libraries within a university. To enable this activity, it is necessary to provide software support for the circulation of library collections at the consortium level. In other words it is necessary to enable user data exchange between libraries within a consortium. The library where a user belongs to and/or pays fees represents his home library. When a user goes to a library which is not their home library, it is necessary to provide access to data about that user which is located in their home library. This access is needed, for example, to check whether the user has the privilege to borrow books. Also, when the user borrows the book in one library, this information should be available to other libraries in the consortium. Communication and data exchange among libraries are defined by standardized NCIP (NISO Circulation Interchange Protocol) protocol for exchange data about library users. The protocol is public and can be downloaded from the official website of the protocol [6]. Besides its definition the site offers additional documentation that can be useful for understanding the protocol, news from the area of its development and use, as well as information about implementation of the protocol by various software vendors.
In paper [7] modelling and implementation of a system that allows circulation for local library users are described. Functionalities of the system are shown and described using a use case diagram. The diagram shows actions a librarian carries out on a daily basis when serving users. These include registering new users, extending user fees, checking out and retrieving books and searching users and the library collection. In order to provide service for users who come from other libraries within a consortium, it is necessary to provide functionalities for searching, charging and discharging. Those functionalities now must include communication with systems of other libraries in order to exchange user data. Further in the text these functionalities are explained in detail using activity diagrams with the aim to observe differences in the operation of the system in the case of local users and in the case of users from other libraries. Based on these functionalities a data model is created and described in the next section.
The activity diagram in Figure 1 shows the functionality for finding data about users, whether the data is from a user in the local system or from a user in the library consortium. The diagram clearly shows differences in the operation of the system in the case of two types of users. Activities Entering user number and Choosing library represents input of user identification number and choice of the library which a user belongs to. Based on this information data about the user can be found. Depending on what was chosen upon choice of library, whether the user is a local user or a user from another library, one of two workflows is performed. In the case of a local user, data about the user is found in the local system which is represented with Finding local user activity. If the case in point is another library in the consortium the application accesses the system of that library and finds the user's data. This is represented with the activities Connecting to home library and Finding user. After finding the user whether in the local system or in the system of another library, the user data is returned to the application for further processing which represents the activity Accepting user data. In the case of local user data a librarian is allowed to modify this data and save the changes made. But in the case of users from other libraries the librarian does not have the ability to change the data.
The activity diagram in Figure 2 shows the functionality of charging the user. The differences among charging local users and charging users from other libraries can be seen on the diagram. Functionalities of the renewals and discharging do not differ essentially from the functionality of charging and are therefore left out from the paper. It is assumed that discharging is done in the same library as charging. Charging, which is represented with the activity Charging, can be done in two different ways: by entering the publication's Item ID or by searching the library collection. Depending on the choice one of the workflows is performed. The activity Entering Item ID represents entering of the publication's item ID. Charging by searching the library collection is represented by the activity Searching publications and Finding publication. During the collection search the librarian selects from the search results the item ID of the publication which is then checked out to the user. Charging of selected publications is presented with the activity Checking out publication. Depending on whether it is charging the local user or charging the user from any other library, one of two workflows is performed. In the case of charging a local user, data about charging is stored in the local system, which is represented with the activity Storing data about charging. In the case of charging a user from another library, data is stored in the system of that library and that is presented with the activities Connecting to home library and Storing data about charging. This approach ensures that the user's charging data from any library is stored in the one place from where they are available to all libraries in the consortium. Besides that a portion of the data about the user and their charges are placed in the local system for the purpose of registering the charges of publications within the collection, which is represented with the activity Storing data about charging remote user.
One of the exceptions of the described functionalities can be unavailable network connection to user's home library. In that case there are two solutions. One solution is to not allow charging of the user, which is bad solution from the viewpoint of the library users. Other solution is to allow charging and store data only in local system and, after connection is restored, store data in user's home library too. This solution is bad for libraries because, in the moment of charging, there is no way to check user's data and all responsibility concerning correctness of user's data is on librarian. This approach is very error prone and because of that libraries should decide which solution they are going to use. Detail description of these solutions is omitted from the paper because it has no impact on data model.
Based on the described functionalities a data model was created for the circulation system. This model is designed according to the requirements and set of data used in the library management system BISIS. It includes data required for both circulation within the local library collection and circulation within the library consortium. This model as well as the following considerations presented in this section can serve as the basis for the development of any circulation system and may be useful to anyone who deals with circulation systems. Moreover, with fewer modifications and adjustments according to needs of particular library this model could be implemented within any circulation system. For example, libraries can have different sets of user's data which they store.
Paper [7] shows the class diagram of the data model for the circulation system. This data model meets all system requirements related to managing local library users. Within the model there is a class that describes the user data which is stored in the system (Users), a class that describes the data about user's membership in the library (Registering), and the class that describes the data about user's charges (Lending). In addition to these there are classes that represent the coders from which the values are taken. As previously mentioned the set of data shown in the model is adjusted to the system BISIS and the libraries that use it.
With regard to checked out publications the model stores only its item IDs within the user's charging data. Since the item ID number uniquely identifies a publication, other data about this publication can also be found. Data about publications is stored in the form of bibliographic records that are located in another part of the system. Besides the item ID number within the user's charging data there is also the date and location within the library where the publication was charged, the loan period and the librarian's name who charged the publication. Information about the date and the librarian also exist for renewals and retrievals of publications. It is assumed that renewal and retrieval is done on the same location as charging of publication.
In the previous section, the activity diagram in Figure 2 shows the functionality of the charging users. When it comes to charging local users the previous described model satisfies all requirements for carrying out this activity. Only change which is done is possibility to have different locations for charging, discharging and renewal of publication. To enable charging users from other libraries in the consortium the previously described model requires some extensions. The activity diagram shows that while the user charges from other libraries, data about charging is placed within the system of the library that the user belongs to. In this way the data is organized within a consortium so that all information about a user is stored in one place from where it is available for other libraries in the consortium. To make this happen it is necessary to resolve several tasks related to this data model.
As already mentioned in the current model an item ID number, location, date and librarian are stored for each charge. The first task is related to the item ID number. In a system that stores data about charging (the system of the library that the user belongs to) there is no information that ties the bibliographic record to the item ID number. In other words the publication is not identified, because that information is in the system of the library where the charging is done. Moreover, that item ID number could be assigned to any publication that belongs to that system. This means that when storing data in the system of the user's home library, it is important to store information about the publication itself. This task is solved by extending the data model with the class Record that contains a bibliographic record of the publication that the user has charged outside the home library. This extension is shown in the class diagram of Figure 3. The variant that was chosen was to place the entire record in the class Record, not just some data from the record, because the circulation system BISIS already has an interface for work with bibliographic records. With this solution there is no need to extend the system which would work only with certain data from records.
The second task that needs to be solved in order to store data about charging in the system of the user's home library is related to the location of charging. In the current model class Location describes the circulation departments within the library where charging could be done. In order to input information into the model and the library where the charging is done the model is extended with the class Library which describes the libraries within the consortium. Each library has locations (departments) for charging and those locations are further described with the class Location. This extension is also shown on the class diagram in Figure 3. This solution requires that the data about the libraries in the consortium and their locations be uniform and shared by all systems in order to uniquely determine in which library and in which location within the library is the charging performed.
The third task that needs to be resolved is related to data about the librarian who performed the charging. If this task could be solved in a similar manner as the previous one, where for each charge it is known which librarian from which library in the consortium level completed the task, this would mean that the data about librarians would be shared at the consortium level. Such data organization in the consortium would not be practical because this data is changed often. Thus the task is solved another way. For charges that are made at locations in other libraries, information about the librarian is not stored within the system of the user's home library, but rather stored in the system of the library which has performed the charging. The method of storing this data will be explained later.
The class diagram in Figure 3 shows the data model extension that allows storing user charges from other libraries. This extension allows storing all user charges at the consortium level in the system of the library to which the user belongs. Figure 3 shows new previously explained classes, as well as the class Lending, Location and Librarian. All three associations between Lending and Librarian have zero value for lower value of multiplicity to enable to store charging without information about librarian who did it.
Besides the data about charges being placed in the system of the user's home library, the activity diagram in Figure 2 also shows that some data about charges and the user are stored in the system of the library which performs charging. The reason for recording and tracking the charged publication within the system of the owning library and recording the user who charged the publications is to create various statistics within that system.
The class diagram in Figure 4 shows the extension of the data model that allows storing data about charging in the local system of the library which performs charging. The class Remote Users describes charges of users from other libraries within the consortium. In addition to data about charging, this class also displays the user identification number, the user's name and their home library. Based on this data it is possible to find other user data stored in the system of the user's home library. Besides this data, an item ID number is stored for each charging of a publication, along with location and date of the charging, the loan period for the charge and the librarian who performed the charging. There is also data about the date, location and librarian for renewals and retrievals of publications. Classes Location, Librarian and Library are previously explained.
The class diagram in Figure 5 shows the entire data model of the circulation system within library management system BISIS. This data model satisfies all the system functionalities related to managing both local users and users from other libraries within the consortium.
The circulation of the library collection today includes a wide range of services provided to users. Besides the availability of different information over the Internet, utilizing the collections of several libraries and delivering library materials to specific locations is becoming a standard in the library business. This paper considers the functionalities of the circulation system that enables the use of collections of several libraries and supports the circulation within the entire library consortium. Based on the specified functionalities one possible data model of the system is given and is explained in detail. This model and the following considerations presented in this paper can be used as the basis for the development of any circulation system. The results presented in this paper were used in the implementation of the library management system BISIS.
The work is partially supported by Ministry of Education and Science of the Republic of Serbia, through project no. III47003: "Infrastructure for technology enhanced learning in Serbia".
Local Proceedings also appeared in ISBN 978-86-7031-200-5, Faculty of Sciences, University of Novi Sad.