Library program Ruslan. Automated library and information system "Ruslan". automated reader workstation. Obtaining a copy of a document

User guide

Version 3.8.1

annotation

This document provides information about the purpose of the Automated workplace reader", the conditions for its use. The sequence of user actions that ensure successful execution of the program is described and illustrated in detail.

Chapter 1. Purpose of the program

The program is designed to provide remote users with access to resources of Z39.50 services. Remote users can be any users of the Web server on which the Automated Reader Workstation operates. Z39.50 service resources can be various remote databases (bibliographic, full-text, ISO delivery request databases). Thus, the program is an intermediate link in a multi-link information system, providing users with the following capabilities:

search for bibliographic, full-text information, information about orders, information about the location and availability of a document in remote databases with the ability to eliminate duplication, navigate through search indexes and automatically expand a query using thesauruses and authority files;

ordering a document (copy) according to its description;

checking order status;

displaying a list of documents received for temporary use.

In other words, the program has a Web user interface. Therefore, the gateway is accessed via .

Chapter 2. Program execution conditions

The necessary conditions for executing the program are:

Preferred, but not mandatory, conditions for running the program are:

Chapter 3. Program Execution

Working with the program consists of sequentially performing the following steps:

Steps 2-4 can be performed multiple times within one session, because search in general is an iterative process.

The ability to complete step 4 depends on the initialization method (user identification required) and the capabilities of the specific .

The ability to navigate through search indexes is determined by the capabilities of the specific one.

3.1. Initialization

There are two modes for establishing a connection with: with and without user identification. In the first case, the user must fill out the fields of the form offered to him necessary for identification: username and password. The type of form is determined by the Web server developer and, generally speaking, may differ from the example given on. However, it is fundamental that the user must provide a username and password. When you enter a password, depending on the Web Agent you are using, the data is not displayed or appears as placeholders.

Figure 3-1. Example of a form for identifying a Z39.50 server user

In the mode without user identification, the connection is established by activating the corresponding link. Links to various sources of information can be provided by the Web server developer on one or more pages.

If the connection is successfully established, the user is given a request form and can proceed to step 2 (see ). If initialization fails for some reason (for example, the server is currently unavailable or the password is incorrect), the program will issue a diagnostic message indicating the reason. In this case, the user can try to eliminate the reasons themselves (for example, check the case of the characters entered and enter the password again), try to establish a connection to the source later, at another time (if the server is unavailable) or seek help from the administrator.

3.2. Search

The type of search form offered to the user after successful initialization is determined by the developer of the Web server and the capabilities of a particular Z39.50 source (access points, logical operators, record presentation forms, navigation capabilities and elimination of duplication). An example of such a form for searching bibliographic information with the names of control elements is given on.

Figure 3-2. Example search form and controls

	List of access points
	List of databases
	Request field
	List of qualifying attributes
	List of operators
	Document location information switch
	Sort switch
	List of sort keys
	List of post formats
	Query expansion switch
	Duplicate elimination switch
	List of thesauri
	Number of records field
	Search button
	Search index view button

3.2.1. Request fields

The search is carried out according to words specified by the user in request fields. The order in which the fields are filled out does not matter. The distinction between uppercase and lowercase letters, or lack thereof, is determined by the specific . Most servers do not distinguish between these letters. You can enter multiple words in one field. Words are separated or not separated from each other in accordance with the rules of the natural language in which the search is carried out.

3.2.2. Access points

The meaning of the request in a specific field is determined by the access point selected from access point lists. The set of access points is determined by the developer of the Web server and the capabilities of the specific . Lists of access points can be of two types - with the ability to select only one element and with the ability to select several elements. The method for selecting multiple elements from lists of the second type is determined by the user's operating system and its Web agent. If multiple elements are selected, then a logical OR operation is considered to be performed on these elements.

3.2.3. Qualifying attributes

You can also clarify the meaning of the request using list of qualifying attributes. For example, multiple words can be interpreted as a phrase when the order of the words is important and a precise search is required, otherwise the value "Word List" can be selected. The set of clarifying attributes will also be determined by the Web server developer and the capabilities of the specific . When searching by author's name, it is possible to use the clarifying attribute "Normalized name". In this case, the name should be entered as follows: surname, comma, initials (for example, “Ivanov, A.I.”).

3.2.4. Entering dates

Dates, with the exception of the year of publication, should be entered in accordance with 7.64-90 in the format YYYYMMDD (for example, "19970328" - March 28, 1997). The publication year should be entered in the YYYY format, while some servers require the mandatory selection of the “Year” qualifying attribute.

3.2.5. Logical operators

If queries are entered into several fields, then logical operations are performed on these fields, selected by the user from operator lists located between the filled fields.

3.2.6. Truncation

You can search by the beginning and ending letters of words, as well as by letters from the middle of the word (respectively, the truncation operations are right, left, right, and left). To do this, use the "*" symbol, which can only be placed at the beginning or end of the request field. If "*" is at the beginning of the query field, then the search is carried out using the final letters of the word. If "*" is at the end of the query field, then the search is carried out using the initial letters of the word. If "*" is at the beginning and at the end of the query field, then the search is carried out using letters from the middle of the word.

If the truncate operation is applied to an expression that has a Word List qualifying attribute, the search will be based on the starting, trailing, or middle letters of each word. If the operation is applied to an expression that has the qualifying attribute "Phrase", then the first or last word is truncated.

3.2.7. Examples of filling out request fields

Examples of correct and incorrect filling of query fields and selection of clarifying attributes are given in tables and respectively.

Table 3-1. Examples of correct filling of request fields

Request field	Qualifying attribute	A comment
neuron set*	List of words	All documents will be found whose description contains words starting with " neuron" And " set" - for example, if the title contains the words " neuron nykh set to her", " neuron new set And", " neuron But- set ev", " set and on binary neuron Oh"
neural network*	Phrase	All publications in the description of which the word "" will appear will be found. neural" and is immediately followed by a word beginning with " set" - for example, if the title contains the phrase " neural network And"
*work tion	List of words	work" And " tions" - for example, if the title contains the words "about work information tions", "once work compass method tions "
*information processing	Phrase	All publications will be found whose description contains words ending with " work" and immediately followed by the word " information" - for example, if the title contains the phrase "about information processing "
works form of techno	List of words	All publications will be found whose description contains words containing the letter combinations " works ", "form ", "techno" - for example, if the title contains the words "times works ka in form tion techno logy" or "times works ka super techno logical modeling processes based on de form tion parameters"

Table 3-2. Examples of incorrectly filling out request fields

3.2.8. Record submission forms

The preferred form of presentation of the found records is selected from list of record submission forms. The list is determined by the Web server developer. The ability to present a record in the required format is determined by the specific . If records cannot be provided in the required format, then the user receives either a diagnostic message or records in one of the supported formats.

3.2.9. Number of records retrieved

IN number of records field the user has the ability to specify the portion size of the records to be retrieved. The waiting time for a response with search results may depend on the value of this parameter. The actual number of records in a portion is determined by the specific .

3.2.10. Eliminating doublets

With help doublet elimination switch the user has the ability to control the process of displaying doublet records. If the switch is in the “On” position, then a doublet elimination operation is performed on the found records - instead of several records considered doublet from the point of view of a specific record, one record is shown - a representative. This operation is quite resource-intensive, so it is not performed if there is a large number of records found. In this case, the user may receive a corresponding diagnostic message; All found records are shown.

3.2.11. Sorting

With help sort switch And sort key list the user has the ability to set criteria for sorting the found records. Sorting is done in ascending order of key values, not case sensitive.

3.2.12. Query extension

With help request expansion switch And list of thesauri the user has the ability to control automatic query expansion using thesauri and authoritative databases. It is recommended to use this feature only in cases where the number of records found is unacceptably small. This may reduce the search accuracy.

3.2.13. Mode change

With help mode change links The user has the ability to change the operating mode of the program. Operating modes differ in the number of controls in the search form and, accordingly, in the available functionality. The range of operating modes is determined by the Web server developer.

3.2.14. Calling the Virtual Keyboard

With help Virtual Keyboard links the user has the ability to call up a dialog menu designed to enter characters from various alphabets, which may be difficult or impossible to enter directly from the keyboard. The selected character ends up at the end of the current one request fields. The procedure for working with the Virtual Keyboard is described in the corresponding User Guide.

3.2.15. Calling the Dialogue for entering classifiers (categorizers)

With help Dialogue call links for entering classifiers (categorizers) the user has the ability to call up a dialog menu designed to navigate and select the meaning of the search term from various classifiers (categorizers). The selected value is included in the current one request field. The procedure for working with the Dialog for entering classifiers (categorizers) is described in the corresponding User Guide.

3.2.16. Calling help

With help help buttons the user has the opportunity to go to a document describing how to work with the program or to any other document.

3.2.17. Executing a search query

The search query is executed after corresponding impact on search button. If the search is successful and records are found, the user receives information about the records found and proceeds to step 3 (see).

If the search is successful, but no records are found, the user receives a corresponding message and can proceed to create a new request by returning to the page with the request form. The return is carried out by user means (navigation control button or key combination) or through the corresponding navigation elements presented on the search results page.

If the search is unsuccessful, the user receives diagnostic messages explaining why the search failed. In this case, the user can also proceed to compose a new request. If the number of diagnostic messages exceeds a certain level determined by the Web server administrator, then these messages are not immediately displayed, but can be displayed by activating the appropriate navigation elements presented on the search results page.

3.2.18. Executing a request to view server search indexes

A request to view search indexes is executed after appropriate action on search index view button. Generally speaking, the ability to view is determined by the developer of the Web server and the capabilities of the particular .

If the browsing is successful, the user receives a list of search terms contained in the index corresponding to the selected access point. The list begins with the term that is lexicographically closest to the query. The list also indicates the approximate number of entries containing a particular term.

Depending on the settings of the Reader Workstation, the viewing results are displayed either in a new or in the current window. In the first case, when the hyperlink corresponding to the selected term is activated, the value of the term is transferred to the request form. In the second case, when the hyperlink is activated, records are searched for this term. If the search is successful, the user proceeds to step 3 (see).

The user is also provided with the ability to navigate through the search index using the appropriate navigation elements presented on the search results page.

Figure 3-4. Example of viewing search results - bibliographic records in short form

Figure 3-5. Example of viewing search results - bibliographic record in full form

3.4. Ordering a document according to its bibliographic description

The document ordering stage consists of several stages, the number of which depends on the order properties specified by the user. At the first stage, the user is shown a bibliographic description of the document and is offered the opportunity to supplement it with information about a specific document (volume, issue, number), because a description can be compiled for a set of documents. Such additions are not mandatory, but may affect the result of order processing. In addition, the user is asked to select from a list one of four forms of working with a document: “Receiving a document for temporary use”, “Receiving a copy of a document”, “Obtaining a certificate of the location of a document”, “Obtaining a certificate of the cost of delivery of a document”. After completing the selection, the user can continue placing the order by activating the "Continue" button.

If there is information about the location of the document, the user is prompted to select the preferred holder (organization, department) by activating the appropriate switches. An example of how to start placing an order for a document is given at.

Figure 3-6. Ordering a document - stage 1

3.4.1. Obtaining a document for temporary use

When ordering a document for temporary use, at stage 2 of placing the order, the user is shown a bibliographic description of the document. In addition, if at the first stage of placing an order the user specified additional information about the document (volume, issue, number), he is given the opportunity to make changes to this information if necessary. The user is also given the opportunity to choose how to process the order if it is impossible to immediately provide him with the document. You can choose one of three ways to process an order: “Put the request in a queue”, “Do not put a request in a queue”, “Proceed in accordance with the library rules”. An example of the corresponding form is given at. After completing the selection, the user can continue placing the order by activating the "Order" button. After this, he is shown information about the order made (see).

Figure 3-7. Ordering a document for temporary use

3.4.2. Obtaining a copy of a document

When ordering a copy of a document, at stage 2 of placing an order, the user is shown a bibliographic description of the document. In addition, if at the first stage of placing an order the user specified additional information (volume, issue, number) about the document, he is given the opportunity to make changes to this information if necessary. The user is also given the opportunity to specify specific document pages to be copied. Filling in the corresponding field is optional. The user also has the option to specify the preferred form of copy (for example, photocopy or electronic copy). The list of possible copy forms is determined by the Web server developer. An example of the corresponding form is given at.

After completing the selection, the user can continue placing the order by activating the "Continue" button. In this case, the user proceeds to the third stage of placing an order. At this stage, he is shown a bibliographic description of the document. In addition, if at the second stage of placing an order the user indicated specific pages to be copied, he is given the opportunity, if necessary, to make changes to this information. After completing the selection, the user can continue placing the order by activating the "Order" button. After this, he is shown information about the order made (see).

Figure 3-8. Ordering a copy of a document

3.4.3. Obtaining certificates

When ordering certificates about the location of a document or the cost of delivery of a document, at the 2nd stage of placing an order, the user is shown a bibliographic description of the document. In addition, if at the first stage of placing an order the user specified additional information (volume, issue, number) about the document, he is given the opportunity to make changes to this information if necessary. An example of the corresponding form is given at. After completing the selection, the user can continue placing the order by activating the "Send request" button. After this, he is shown information about the order made (see).

Figure 3-9. Ordering a certificate of location of a document

Figure 3-10. Result of placing an order

Chapter 4. Messages to the operator

4.1. Initialization

The messages that the user can receive during the initialization stage, the meaning of these messages and the user's actions are presented.

Table 4-1. Messages during the initialization phase

Message	Description	User Actions
Network is turned off	It is impossible to establish a connection with a specific one due to its unavailability	Try to establish a communication session another time, or
Network unavailable
Timeout when trying to establish a connection
Server is not available
There is no route to the server
Invalid information - server not found or not responding
Reliable information - server not found	The server specified in the Reader Workstation configuration does not exist, or the name service is not functioning correctly	Contact the Web server administrator with a description of the problem
The name is correct, but there is no record of the specified type
Fatal error	It is impossible to establish a connection with a specific one, most likely due to an error in the software of the Reader Automated Workstation	Contact the Web server administrator with a description of the problem
The server unexpectedly closed the connection	unexpectedly closed the communication session, most likely due to an error in the server software	If possible, contact the software developers with a description of the problem
Can't get a response	It is impossible to establish a communication session with a specific person, most likely due to an error in the server software
Unable to send request
An incorrect response was received from the server
An unexpected response was received from the server
Server denied access	There is not enough permission to work with a specific	Check that the username and password are entered correctly. If necessary, enter these parameters again. If unsuccessful, contact the administrator.

4.2. Search, view search results, order a document

The messages that the user can receive at the stages of searching, viewing search results, ordering a document, the meaning of these messages and user actions are presented.

Table 4-2. Messages at the stages of searching, retrieving, ordering a document

Message	Description	User Actions
Constant system error	cannot perform the operation	If possible, contact the administrator with a description of the problem.
Temporary system error	temporarily unable to perform the operation	Try the operation later
Unsupported search	The user-specified search expression could not be processed	Reformulate request
The search expression consists only of stop words	can't complete search query	Reformulate the query to remove stop words
Too many words		Reformulate the query by reducing the number of words
Too many logical operators		Reformulate the request by completely clearing some fields
Too many truncated words		Reword the query to minimize the number of truncated words
Truncated words are too short		Reformulate the query by increasing the length of the truncated words
Attempting to retrieve a non-existent record
System error when retrieving records	cannot present the found record	If possible, contact the administrator with a description of the problem.
The specified database combination is not supported	cannot perform an operation on the specified databases	Reformulate the query to reduce the number of databases selected
Search results no longer exist - deleted by server	unilaterally deleted search results, possibly due to lack of resources	Search again
Search results are still being generated	received a request to retrieve records while the search was not yet completed
One of the specified databases is locked	cannot perform an operation on one of the specified databases
The specified result set does not exist	cannot present records without first performing a search	If possible, contact the Web server administrator with a description of the problem.
Resources are exhausted - no result		Search again later or contact your Web server administrator with a description of the problem.
Resources exhausted - unpredictable partial result available		Continue work. If the result is unsatisfactory, exit the work and try to resume it later
Resources exhausted - reliable partial result available
(Unspecified) error	cannot complete the operation for an unknown reason	If possible, contact the Web server administrator with a description of the problem.
No access	denied access to a database or record due to the user not having the appropriate permissions
Recording format is not set to abstract format	can't submit an entry	If possible, contact the Web server administrator with a description of the problem.
Unsupported request type
Invalid request	cannot complete the search request because it's incorrect	Reformulate the request or contact the Web server administrator with a description of the problem
Database unavailable	cannot perform an operation on a specific database	Perform the operation again later
Unsupported operator	does not support searching using this operator	Reformulate the query to exclude the unsupported operator
Too many databases specified	cannot complete the operation due to insufficient resources	Reformulate the query, reducing the number of databases
Too many search results generated	cannot complete the search request due to insufficient resources	If possible, contact the Web server administrator with a description of the problem. Shut down and try to resume later
Unsupported attribute type	cannot complete the search request	If possible, contact the Web server administrator with a description of the problem.
Search by access point is not supported		Reformulate the request using a different access point.
Unsupported term value for this access point		Reformulate the query using a different form of specifying the term
Access point not specified		If possible, contact the Web server administrator with a description of the problem.
Unsupported relation attribute	cannot complete the search request	Reformulate the query using a different relation attribute. If possible, contact the Web server administrator with a description of the problem.
Unsupported structure attribute		Reformulate the query using a different structure attribute. If possible, contact the Web server administrator with a description of the problem.
Unsupported position attribute		Reformulate the query using a different position attribute. If possible, contact the Web server administrator with a description of the problem.
Unsupported truncation attribute		Reformulate the query using a different truncation attribute. If possible, contact the Web server administrator with a description of the problem.
Unsupported attribute set	cannot complete a search request due to an error in the gateway configuration	If possible, contact the Web server administrator with a description of the problem.
Unsupported attribute combination	cannot complete the search request	Reformulate the query using a different combination of attributes.
Invalid search expression		Reformulate the request or contact the Web server administrator with a description of the problem
Incorrect term value for this access point		Reformulate request
Only zero step view is supported	cannot complete a search index request due to an error in the gateway configuration	If possible, contact the Web server administrator with a description of the problem.
The specified view step size is not supported
Insufficient permissions to perform the operation	refused to perform the operation due to the user not having the appropriate permissions	Contact the Web server administrator with a description of the problem or continue working
Non-existent database	cannot complete the request due to an error in the gateway configuration	If possible, contact the Web server administrator with a description of the problem.
Database access denied	denied access to the database, possibly due to the user not having the appropriate permissions	Contact the Web server administrator with a description of the problem or continue working
The record cannot be submitted in the required form.	cannot submit the record in the required format	Select a different post format
Unsupported recording format	cannot submit the record in the required format	Select a different post format
The service is not provided for this database	cannot execute a query for a specific database	Select another database
Post deleted	In the time between searching and retrieving the record, it was deleted	Continue working with the program
SQL error	cannot perform the operation	If possible, contact the developers with a description of the problem.
Quota exhausted	The user can no longer submit new orders to the system	Cancel unnecessary orders, or contact the administrator Z39.50 servers CAE Common Application Environment CSS Cascading Style Sheets HTTP Hypertext Transfer Protocol HTML Hypertext Markup Language IEC International Electrotechnical Commission ILL Interlibrary Loan Machine Readable Cataloging TCP/IP Transmission Control Protocol/Internet Protocol GOST State standard

-- [ Page 1 ] --

Automated

library and information

Server "Ruslan" Version 2.16.x

Administrator's workstation Version 1.8.x

ADMINISTRATOR'S GUIDE

Introduction

Technical support

1. Description of the interface of the Administrator's workstation

2. Setting up the Ruslan data schema

2.1. Setting up library data sources

2.2. Setting up MARC record indexing tables

2.3. Configuring MARC Access Points

3. Setting up the Ruslan server

3.2. Setting up the work of directories

3.4. Adding a new directory

4. User management

4.1. Operations on access rights groups

4.2. Operations on users

5. Library database management

5.1. Creation of library databases of the organization

5.2. Editing parameters of an organization's library databases

5.3. Determination of quantitative indicators of library databases......60

5.4. Removing a library database or data from a library database....................................61

5.6. Analysis of statistics for library databases

5.7. Updating access points to bibliographic databases

5.9. Uploading records from library databases

5.10. Setting the initial number of the library database record key generator

5.11. Viewing records in library databases

5.12. Control of doublets in the fields of MARC records and service records........76

5.13. View the history of changes to bibliographic records and restore a deleted or changed record

5.14. Batch editing bibliographic records

6. Library technologies

6.1. Working with a buffer base

6.2. Borrowing analytics

6.3. Setting up background processing tools for bibliographic records.....97

6.4. Configuring background processing tools for service records

6.5. Setting up export and import of data for the university automated control system

6.6. Setting up a server to support the automated book issuance process

6.7. Setting up a server to support the process of reader control of books issued to them

6.8. Setting up a server to support the process of collecting book issue statistics

6.9. Setting up a server for dispatching electronic ordering of documents

6.10. Setting up a server to support the fund inventory process..121

7. Data archiving

7.1. Archiving using Oracle DBMS

7.2. Archiving using the Administrator's workstation

7.3. Starting the archiving process with the Ruslan server

8. Transferring data to another computer

9. Ensuring uninterrupted operation of the server part of IBS "Ruslan".......135

10. License management

11. Monitoring and managing the operation of the Ruslan server

11.1. Overloading server parameters

11.2. Analysis of the current server state

11.3. View users connected to the server

11.4. Viewing the list of library databases known to the server

11.5. Analysis of physical database connections

11.6. Analysis of server operation statistics

Applications

Appendix 1. Diagnostic messages of the Ruslan server

Appendix 2. Service database tags

Appendix 3. Exchange format for service databases

Appendix 4. Request Format

Introduction This manual is intended for the administrator of the automated library and information system (ALIS) "Ruslan".

IBS "Ruslan" consists of client and server parts. The server part consists of the Ruslan server and the Administrator's automated workstation (AWS). The client part is a set of target library modules (ARMs) that interact with the Ruslan server using the Z39.50 protocol.

The Ruslan server is the core of the Ruslan IBS and supports three interfaces:

Z39.50 – for interaction with library workstations and Z39.50 clients of other manufacturers;

Oracle® Net Services (Net8) – for interaction with a data warehouse based on the Oracle® DBMS;

Microsoft® DCOM – for interaction with the Administrator's workstation.

The Administrator's Workstation (hereinafter referred to as Workstation) is designed to manage library data in the Oracle® DBMS and the Ruslan server. The workstation has no independent significance (outside the server part of the IBS "Ruslan").

The manual contains a description of the interface and capabilities of the Administrator's workstation for solving problems of setting up, managing and monitoring the IBS "Ruslan".

Technical support Technical support is provided by Baltiksoft LLC.

Company website: www.balticsoft.ru Email: [email protected] Terms

– – –

1. Description of the Administrator's Workstation interface To launch the Administrator's Workstation, select the shortcut "Administrator's Workstation of ABIS "Ruslan"" on the desktop or in the task menu in the "ABIS Ruslan" folder.

Select the “New Session” command from the “File” menu (Fig. 1) or click on the “New Session” icon on the toolbar (Fig. 2) or enter the key combination Ctrl+N.

– – –

A dialog box will appear as in Fig. 3. There are two values to choose from in the list: “RUSLAN-Database” and “RUSLAN-Server”. If you select the first value in the list (“RUSLAN-Database”) and click the “OK” button, then (after authorization) the interaction interface (via Oracle® Net Services (Net8)) with the “Ruslan” data schema will open (Fig. 5). We will henceforth call this interface “RUSLAN-Database”. If you select the second value in the list (“RUSLAN-Server”), the interaction interface (via Microsoft® DCOM) with the Ruslan server will open (Fig. 7). We will henceforth call this interface “RUSLAN-Server”.

Rice. 3 After selecting “RUSLAN-Database”, an authorization dialog box will appear (Fig. 4). If the initialization file (see ABIS "Ruslan". Installation Guide) is in working folder and is not damaged, then the first two fields of the dialog box will be filled in. Otherwise, working with the Administrator's workstation is impossible. After you enter the administrator password and click on the “Run” button, you will be authorized in the Oracle DBMS. After authorization, a connection will be created to the service data source (Fig. 5), which contains the “Ruslan” data schema.

Rice. 4

Rice. 5 After selecting “RUSLAN-Server”, an authorization dialog box will appear (Fig. 6). Enter the network name of the computer (on which the Ruslan server is running), the username on this computer and the password.

If the computer is part of a Microsoft domain, you must add the domain name before the user name (for example, MY_DOMEN\username).

If the workstation is launched on the same computer as the Ruslan server and the OS is Windows XP, then just enter localhost in the “Server Address” field.

If the workstation and the server are running under Windows 2003 SP1/SP2 or Windows Vista, but the computer is not part of a domain, then you must specify the computer name in the “Server Address” field and also specify it before the user name (for example, MY_COMPUTER\username). The password is required.

(Fig. 7). If the Ruslan server service is not running (see IBS "Ruslan". Installation Guide), the workstation will not be able to establish a connection with it and an error message will appear.

Rice. 6 Both interfaces (“RUSLAN-Database” and “RUSLAN-Server”) have a similar appearance and are divided into three parts. On the left is a navigator window with administration objects in the form of a tree. At the bottom there is a log window. On the right is the main window, which reveals the contents of administration objects (in most cases in the form of a table). You can resize parts of interfaces. All operations in the interfaces are performed using context menus. To open the context menu, click the right mouse button.

Rice. 7 When moving in the navigator window from one object to another, the workstation automatically checks whether changes have been made to the contents of the objects.

If the workstation believes that changes have been made (in some cases there may not be real changes), then it displays the message “Perhaps the parameters have been changed. Save changes? You can save the changes or refuse to save at your discretion. If you are sure that you have not made any changes, then it is better to refuse.

2. Setting up the Ruslan data schema

This section describes the operations for setting up the data schema of the IBS "Ruslan" in the Oracle DBMS. The data schema consists of a set of tables storing a list of databases, a table of parameters for the Ruslan server, an indexing table for MARC records, lists of access points to MARC records, security data, as well as the procedures that serve them.

The data schema is configured from the “RUSLANDatabase” interface (see point 1).

2.1. Setting up library data sources Setting up database databases involves registering or de-registering them, as well as changing their parameters: the password of the source owner and the number of connections that the Ruslan server establishes with the DBMS.

Registration of the source of library data This operation is necessary so that the IDB created during the installation process (see IBS "Ruslan". Installation Guide) becomes known to IBS "Ruslan". In a normal situation, when creating an IDB, automatic registration occurs. However, for one reason or another (system failure, accidental manual de-registration), it may be necessary to perform this operation manually.

To register a database, select the “Data Sources” object in the navigator window and in the main window, call the “New” command from the context menu

(Fig. 8). In the main window the table will appear new line with the name "New Source". Double-click the left mouse button on this line. A dialog box for editing source parameters will appear (Fig. 9).

Rice. 8

Rice. 9 Enter the required parameters (see example in Fig. 10) and click the “Run” button. In the “Number of connections” field, you specify the number of connections that the Ruslan server will establish with this IDB. The number of connections determines how many operations with the database can be performed in parallel. If you are not sure, then set the number of connections to three. If you entered incorrect source parameters, you can edit them again. If you have registered an extra source, you can delete it using the “Delete” context menu command. After all the required sources have been registered, call the “Save” command from the context menu. If you want to cancel all changes, then call the “Restore” command from the context menu.

– – –

De-registration of the source of library data This operation excludes the IDB from the list of sources known to the ILIS "Ruslan". In a normal situation, when the IBD is deleted, automatic de-registration occurs. However, for one reason or another (system failure), you may need to perform this operation manually.

To register a database, select the “Data Sources” object in the navigator window and in the main window select the database that you want to de-register. From the context menu, select the “Delete” command. A confirmation of the operation will appear. If the operation is confirmed, the specified IBD will disappear from the list. To complete the operation, call the “Save” command from the context menu. The operation can be canceled by calling the “Restore” command from the context menu.

Changing IBD parameters It is possible to change two parameters of a registered IBD: the IBD owner's password and the number of connections that the Ruslan server establishes with the IBD. The number of connections determines how many operations with the database can be performed in parallel. You can also change the source owner name, but this will effectively mean registering a new IDB.

To change the parameters of the IDB, double-click with the left mouse button on the line describing the required IDB. A dialog box for editing source parameters will appear (Fig. 10). To change the password, enter the password twice in the adjacent fields. To save the changes, click the “Run” button. Next, you can edit the parameters of another IDB. To commit the changes made, call the “Save” command from the context menu. To cancel all changes made, call the “Restore” command from the context menu.

2.2. Setting up indexing tables for MARC records To add, delete or edit indexing tables, select the “Indexing” object in the navigator window and call the context menu in the main window (Fig. 12). The New command creates a new (empty) index table. The “Edit” command calls up a dialog box for editing the selected indexing table (Fig. 13). The same command can be called by double-clicking the left mouse button. The Delete command deletes the selected index table. The Save command saves all changes made to all index tables.

The Restore command undoes all changes made to all index tables. The Load command loads index tables from a text file. After downloading, you must execute the “Save” command to save the indexing tables. "Unload" command

dumps index tables into a text file.

Each indexing table has an identifier number, a comment, and a descriptive part itself, which contains a description of how to index the fields of a MARC record.

Rice. 12

Rice. 13 The descriptive part in the indexing table editing dialog box (Fig. 13) is expanded in the form of a table for ease of working with it.

The context menu contains the following commands: “Add” – to add a new indexing rule to the end of the table, “Insert” – to insert an indexing rule before the selected one, “Delete” – to delete an indexing rule. To edit a table cell, click on it with the left mouse button. Each indexing rule occupies one table row.

The order of the rules matters: when indexing a MARC record, the indexing table (descriptive part) is scanned from top to bottom for each field (subfield) of the record, and when the field satisfies the next indexing rule, indexing occurs in accordance with this rule, the table is not scanned further. An indexing rule consists of three attributes: field pattern, subfield pattern, and indexing type. The field template consists of three numeric characters. The subfield template consists of a single character, which can be either a number or a lowercase letter of the English alphabet. Also, when specifying a field or subfield template, a dash (minus sign) means any character. For example, a field pattern of the form "02-" means "all fields from 020 to 029". The indexing type consists of two digit characters.

The following indexing types are available:

00 – do not index;

01 – subfield-phrase: parses the subfield into words and provides the ability to search by word, by list of words and by phrase within the subfield;

11 – phrase field: parses the subfield into words and provides the ability to search by word, list of words and phrase within the field (makes sense, for example, to provide a search with a term structure of the “normalized name” type for records in the RUSMARC format);

02 – as is: removes leading and trailing spaces, the rest is treated as a word, provides the ability to search by word;

03 – ISBN: special indexing type for subfields containing ISBN or ISSN;

4X - Coded Field: Provides the ability to index coded fields and their parts as words. The subfield pattern specifies the starting position of the indexed element, and the X character contains the length of the indexed element in characters. The position and length are specified by one character, with the number 10 corresponding to the character “a”, the number 11 to the character “b”,..., the number 35 to the character “z”;

05 – numeric range: in the subfield only numeric elements of the word are highlighted, the range symbol (minus sign) is expanded, i.e., for example, in a subfield with the content “N5, 6-9” the elements (words) “5” will be indexed, "6", "5", "7", "8", "9";

06 – UDC: special type of indexing for subfields containing UDC. When indexing, a parenthesis is considered a separator; a period is not considered a separator;

An inline 200 field is indexed if the first indicator for that field is not zero;

08 – optimization of 999 fields: used to speed up the process of indexing fields (999th in the Ruslan ABIS) containing accounting information. The rule is placed at the beginning of the indexing table. In this case, the field template contains “ass”, the subfield template contains “-”;

09 – inventory number: a special type of indexing for fields (subfields) containing inventory numbers. In this case, the inventory number must consist of three elements separated by a separator character (“-”, “\”, “/”, etc.).

All indexed elements (words) are indexed as lexograms (compared in lexicographical order), and also as numbers (compared in numerical order), if they consist entirely of numeric characters (with a possible minus sign at the beginning).

There are the following special field template values: “000” – marker (indexing type is always 4X), “acc” – enabling optimization of 999 RUSMARC fields (indexing type is always 08), “key” – internal record key – required element indexing tables, with the exception of cases of re-indexing of some fields (the subfield template is always “-”, the indexing type is always 02).

Different MARC formats may require different types of indexing for the same field and subfield patterns. Each bibliographic database is associated with one indexing table (which can be divided into two in a two-phase indexing scheme). Therefore, each bibliographic database can only contain records of a specific MARC format.

To reduce the system response time to operations of inserting and changing bibliographic records, the Ruslan server provides a two-phase indexing scheme. When inserting/changing a MARC record from automated workstations of ABIS "Ruslan" (with the exception of the Administrator's workstation), the record is inserted/changed and indexed/reindexed in accordance with the indexing table for the first phase. If these operations are successfully completed, a corresponding message is sent to the user and the Ruslan server is sent to background performs indexing/re-indexing of the MARC record in accordance with the indexing table for the second phase. Errors in the second phase are not recorded anywhere; they can only be detected by an incorrect search. Therefore, it is not recommended to index important fields (subfields) in the second phase. Typically, in the second phase, the content fields of large volumes of text are indexed, for example the contents of a document, abstract, note, etc.

2.3. Configuring access points to MARC records An access point (AP) is a number uniquely associated with a search attribute (“Author”, “Title”, etc.). Access points provide searches for both bibliographic (MARC) and service records in the library databases of the Ruslan ABIS. In ABIS "Ruslan" you can configure access points to bibliographic records, i.e. determine which fields of MARC records are mapped to which access points. Each MARC format will have a different display. One set (list) of access points is associated with each bibliographic database. Therefore, each bibliographic database can only contain records of a specific MARC format.

Each AP list has a numeric identifier. The following identifiers are usually used (1 – UNIMARC, 10 – USMARC, 28 – RUSMARC bibliographic, 281 – RUSMARC authoritative).

– – –

Adding a new list of access points To add a list of APs, select the “Access Points” object in the navigator window and call the context menu. In the context menu, call the “Add new AP list” command (Fig. 14). A dialog box will appear in which you must enter the identifier of the new AP list (Fig. 15).

– – –

Working with the list of access points Any actions with the list of APs are performed in the main window from the context menu (Fig. 17).

Rice. 17 The “New” command creates a new access point. Edit command

calls up a dialog box for editing the selected access point (Fig. 18).

The same command can be called by double-clicking the left mouse button. The Delete command deletes the selected access point. Save command

saves all changes made to this list of APs. The “Restore” command cancels all changes made to this list of APs. The Load command loads an AP from a text file into an existing AP list.

After downloading, to save the list of APs, you must execute the “Save” command. The “Upload” command uploads the AP of the selected list to a text file.

The Ruslan ABIS distribution includes TD lists for UNIMARC (file ap1.txt), for USMARC (file ap10.txt), for RUSMARC bibliographic (file ap28.txt) and for RUSMARC authoritative (file ap281.txt) .

The mapping of MARC fields/subfields to TD (Fig. 18) is described using logical expression, each term of which identifies one or more MARC fields/subfields. The expression structure corresponds to the WHERE clause in the SQL SELECT statement.

The term has the form:

field op "###A" or field in ("###A",...,"###A"), where op is one of the operators: =,=,=,like,not like (most = and like are often used);

### – MARC field number;

A is the MARC subfield symbol of the corresponding MARC field.

Rice. 18 Instead of the character(s) # or A, it is allowed to use the underscore (_) to denote any character or the percent symbol (%) to denote any number of any characters. The use of the percent symbol, as well as the and not like operators (also like for Oracle Standard Edition) is not recommended where enumeration using the field in expression can be done, since this will reduce search speed. If several terms are specified, they can be combined using the logical operators and, or and not and.

To bind search attributes to the positions of coded fields and markers, pseudo-fields are used, as they are defined in the indexing table (see section 2.2, special field template values), i.e. ### – field template, A – subfield template as in the indexing table.

– – –

Deleting a list of access points To delete a list of APs, select the required list in the navigator window, select all attributes of the list (select the first attribute, press the “Shift” key, select the last attribute) and call the “Delete” command from the context menu (Fig. 19). Confirm the operation - all access points will be deleted from the main window (view as in Fig. 17). Call the “Save” command from the context menu. Confirm the operation. Then call the “Update” command from the context menu of the navigator window (Fig. 14). After this, the ID of the remote AP list will disappear from the navigator window.

ATTENTION! To apply changes to the list of access points, they must be updated for each bibliographic database that uses this list(see clause 5.7).

2.4. Updating the Ruslan data schema

Data schema updates can be of two types:

simple update – updating one or more (there are three in total) packages of stored procedures;

complex update - updating the data storage structure, including possible updating of the data itself.

A complex update is usually delivered as executable file patch program. Documentation on its use is supplied with the patch.

A simple update comes in the form of files with a plb extension (usually pkg_phbase.plb for a base package or pkg_phupd.plb for an advanced services package or pkg_phutil.plb for a utilities package).

To perform a simple schema update, you need to call the “Update DB Schema” command from the “File” menu (Fig. 20). A standard file selection window will appear in which you need to select a file with a new package. While the package is being updated, a window will appear and disappear. command line. If the update is successful, in the main window, when selecting the “Ruslan Database” object (Fig. 5), the new version of the package should be reflected. This procedure should be repeated for all files included in the update.

Rice. 20

Note. After carrying out the procedure of simply updating the data schema, it is possible that in some operations a one-time non-critical error may appear when working from automated workstations of the ABIS “Ruslan”, associated with a change in the context of the Oracle database. You just need to repeat the operation. To eliminate the possibility of errors, it is recommended to stop the Ruslan server before updating the data schema, and start it again after the update.

3. Setting up the Ruslan server

This section describes the operations for setting up the Ruslan server

ABIS "Ruslan". The server is configured from the “RUSLANDatabase” interface.

3.1. Configuring Ruslan server parameters

To add, delete or edit server parameters, select the “Parameters” object in the navigator window and call the context menu in the main window (Fig. 21). Each parameter consists of three elements: parameter name, parameter value and comment. The length of each parameter element cannot exceed 255 characters.

The New command creates a new parameter. The "Edit" command puts the table cell the cursor is pointing at into edit mode.

The same command can be called by left-clicking on a cell (if the parameter is selected). The Delete command removes the selected option.

It is possible to delete several parameters or all (with multiple selection in a standard way using the "Shift" and "Ctrl" keys).

The Load command loads parameters from a text file. This assumes that the parameters have not yet been loaded (the main window is empty). After downloading, to save the settings, you must execute the “Save” command. The "Upload" command uploads the parameters to a text file. The "Load with Merge" command is designed to load new version parameters from a text file (parameters have already been loaded).

After downloading with a merge, you must also run the Save command to save your changes. The “Save” command saves all parameters to the database. The "Restore" command undoes everything done using the "Change", "Load" or "Load with Merge" operations in the change parameters (loads parameters from the database).

A description of the parameters is given in the comment field. More detailed description parameters, if necessary, are contained in separate documentation or in sections of this manual. Most of the parameters do not need to be changed and are strictly not recommended, since it can lead to the inoperability of the Ruslan server or its individual services.

Rice. 21 Creating a new parameter or loading a new parameter file (the “Load with Merge” operation) are quite rare operations and are performed at the direction of the system support service.

There are parameters that have their own values for each organization (library). When loading a new settings file, these settings should retain their previous value. To automate this process, the “Load with Merge” operation is provided. While performing this operation, if it detects old version parameter values, for each parameter a dialog box is displayed (Fig. 22), where the administrator is asked to select the old or new value.

Rice. 22 Next, we will consider the main server parameters that the administrator will need to change after downloading the parameters from the file included in the distribution kit of the server part of the IBS "Ruslan" (see IBS "Ruslan". Installation Guide).

You always need to change the OrgEng and OrgRus parameters. The first contains the abbreviation name of the organization (library) on English language, the second is in Russian.

The ActsDB, BillsDB, CircDB, DirsDB, OrderDB, QueueDB, ReaderDB, ReaderADB, SubscrDB parameters contain the names of special-purpose service library databases. If during the installation of ABIS default library databases were created (see ABIS "Ruslan". Installation Guide), then these parameters should not be changed. If you create library databases manually, you can specify different names for the databases that match these parameters than the default ones.

The GroupDB parameter allows you to specify virtual (group) names for several real library databases. It is possible to specify several virtual names. The field value format is given in the field comment.

In this case, the virtual name should come first, followed by the names of the real library databases included in the group, separated by commas. If you want to define several groups, separate their descriptions with a semicolon. A virtual name can be useful when searching. When searching a database with a virtual name, a search is performed in all databases associated with this name. A virtual name is convenient, for example, to use in the settings of the Reader workstation (HTTPZ39.50 - gateway), since when adding a new library database to the group, you will not need to change the Reader workstation settings. It is impossible to edit records found in the virtual database.

The Scan parameter contains a list of search attributes (see documentation for the Z39.50 protocol, set of search attributes bib1), for which the “Scan” service will be supported, i.e. search index viewing service.

In the list of search attributes, you should only include those attributes that are actually used in this service. To speed up their browsing, search indexes are loaded into RAM. Number of occupied random access memory depends on the number of search attributes in the Scan parameter, on the number of bibliographic databases for which the “Scan” service is enabled, on the number of records in these bibliographic databases, as well as on the number of different words that may contain the fields of bibliographic records corresponding to the search attributes.

The DafLog parameter controls the maintenance of a log file of interaction with the Oracle database (daf.log), which is located in the working folder of the Administrator's workstation (by default C:/Program Files/Ruslan/SysAdmin) and in the working folder of the Ruslan server (by default C:/ Program Files/Ruslan/Server).

By default, the parameter is set to "1". This means that a log file is maintained for the workstation and for the server. Periodically, when files become large, they should be deleted. If the parameter is set to “0”, then log files will not be maintained. Log files can help determine the cause of system problems or if the system does not provide certain functionality. In case of problems, you should set this parameter to 1 and send the log files obtained as a result of the work of the workstation and the Ruslan server to the system support service.

3.2. Setting up the operation of directories All directories are divided into two types. The first type (main) are reference books, which are used to view and select values from them for insertion into the fields of a bibliographic record. In such directories, each element consists of a search term and a note to it (may be missing). The second type is special-purpose directories such as a directory of inventory number generators.

All directories are maintained using two specialized service databases. The first database, DDIR, contains a description of all directories in the system. This database used by workstations to generate lists of available directories and organize access to them. The second database, DIR (the database name can be changed, see the previous paragraph), contains all directories.

Each directory has a unique identifier. Registered directories are given in the documentation for the Acquisition/Cataloging Workstation. When creating a new directory, you must agree on its identifier with the service technical support systems.

Each directory consists of a set of entries in internal format ABIS Ruslan (see Appendix 3). It is recommended that the total volume of all directories does not exceed 200,000 entries. Each directory entry consists of a maximum of 3 tags: 5 (directory identifier), 17 (term) and 18 (term note). The value under tag 18 is optional and is usually used to decipher terms containing an abbreviation or some kind of code.

To organize the work of directories of the second type, you should:

1. Check that the DDIR and DIR service databases have been created. If during the installation of ABIS default library databases were created (see ABIS “Ruslan” Installation Guide), then the database data must be present. Otherwise, they should be created manually (see section 5.1).

2. Load directory descriptions from the ddir.dat file supplied with the distribution into the DDIR database (see section 5.8) with the “Generate record key” option.

If you need to add a new directory, you need to get its identifier from the system support service and then create a file similar to ddir.dat (which will contain a description of only the new directory) and load it into the DDIR database. For more details, see paragraph 3.4.

3. Give users the appropriate rights to the DDIR and DIR databases (see clause 4).

If the database data was created by default, then a group of access rights gdir was also created for them, which must be given to users working with directories (in particular, with the directory of inventory number generators).

To organize the work of directories of the first type, in addition to the above steps, you should:

4. Create a directory file in the format described in Appendix 3 with tags 5 (directory identifier), 17 (term), 18 (term note). For more details, see paragraph 3.3.

5. Upload the file created in paragraph 4 of this list into the DIR database (see paragraph 5.8) with the “Generate record key” option.

6. Set the “Scan by words” flag for the DIR database (see section 5.2).

7. Check the server parameters (see paragraph 3.1). They should be as follows:

ServiceDBScanFilterTag 5 ServiceDBScanFilterValue must contain, separated by commas, all directory identifiers of the first type ServiceDBScanTag 17 ServiceDBScanNoteTag 18

8. When changing parameters, they must be reloaded in the server (see.

clause 11.1) or restart the server itself. After downloading directories from the Administrator's workstation, the server also needs to be restarted.

The DIR database is also used to store the “Inventory Number Generator” directory. This directory is specialized and work with it is carried out only using the Acquisition/Cataloging Workstation. The identifier of this directory is 200. It is necessary to ensure that when working with the DIR database, the directory data of the inventory number generator is not accidentally damaged.

It should be remembered that directories begin to download a minute after the start of the Ruslan server and this process takes certain time, depending on the power of the computer and the volume of reference books. After loading the directories into EventViewer (Application Log), a corresponding message appears (Fig. 23) for each database with the “Scan by words” flag set.

Rice. 23

3.3. Loading and activating a directory Activating a directory involves adding the identifier of the activated directory to the list of values for the ServiceDBScanFilterValue server parameter. Activation means permission to work with the directory from workstations (the directory can be described in the DDIR database, loaded into the DIR database, but if it is not activated, then when you try to access it from workstations, a diagnostic message number 114 will be issued). It is possible to activate the directory without loading data into the DIR database. In this case, the data can be filled in “manually” using the capabilities of automated workstations.

Before loading directories into the DIR database, you must first obtain records in the internal format of the Ruslan ABIS. To do this, you can use a specialized converter available for users of IBS "Ruslan". This converter allows you to obtain the required format from data placed in a text file with a tab character as a column separator.

A file in this format can be obtained, for example, by saving data from a spreadsheet program (for example, Microsoft Excel), specifying the file type “Text files (tab delimited) (*.txt)”. Instructions for using the converter can be obtained by running it without specifying parameters. A directory entry must contain two required tags. Under tag 5 the directory identifier should be indicated, under tag 17 there should be the actual reference data. An optional tag 18 may contain a reference data note. A note is used to explain coded reference data (for example, a directory of library departments).

For example, to obtain a file with keyword records in the format required for IBS "Ruslan", you need to run the converter with the following parameters:

lconv input_file.txt output_file.dat 5=6 After loading directory entries into the DIR database, you need to restart the server.

3.4. Adding a new directory For each new directory, you must request a new identifier from the developers of IBS "Ruslan". To avoid compatibility problems with future versions of ASIS, it is not recommended to create an identifier yourself.

The full cycle of adding a new directory includes steps to configure the Ruslan server and configure the workstation (see the documentation for the required workstation) in which the directory is supposed to be used.

Sequence of steps for adding a new directory on the server side of IBS "Ruslan":

1. Make sure that the existing list, supplied to the distribution as a file ddir.dat, there is no suitable reference book. If there is, then use it. Otherwise, ask the developers of ABIS Ruslan for the identifier of the new directory.

2. Create a record describing the new directory. To do this, you can take any entry from the ddir.dat file and, based on it, create a new entry in separate file. In the entry you need to change the values of two tags 5 and

4. Tag 5 contains the directory identifier, tag 4 contains the name of the directory.

3. Using the Administrator's workstation, upload the generated record to the DDIR database.

4. Follow the instructions in paragraph 3.3.

After completing this sequence of actions, access to the directory is possible from any workstation.

4. User management

– – –

IBA (ILL) - the right to process orders under IBA

List of functional groups (not complete, for more details see the documentation for the Acquisition/Cataloging Workstation):

compl - gives the privileges to edit fields required to implement the picking functionality catal - gives the rights required to implement the cataloging functionality billcreator - gives the right to administer accounts (create, change, delete) billdispatch - gives the right to change the account status printadmin - gives the right to administer the print service The list of functional groups (roles) is specified by the FGroups parameter. This parameter can be changed either during the process of updating parameters (see clause 3.1), or by special instructions from the system support service.

Rice. 24 A group includes one or more BDBs indicating access rights to each BDB (Fig. 24). One or more groups can be assigned to a user. A user receives rights to a certain BDB if this BDB is present in at least one of the groups assigned to him. If a given BDB is present in several groups assigned to a user, and if the rights to a given BDB are different in different groups, then the user receives all the rights established in a particular group (rights from different groups are combined).

The user is also usually assigned one or more roles that provide the corresponding functionality of the workstation(s).

Effective security management requires advance planning. It is necessary to determine the list of required UDBs and group access rights to them into specific groups, which should then be assigned to the appropriate users. The names of both the UDB and groups are set by the system administrator. Roles have predefined names (see documentation for the corresponding workstations). If during the installation of ABIS default library databases were created (see ABIS "Ruslan". Installation Guide), then groups were also created: gcompl for compilers, gcatal for catalogers and gdir for working with reference books.

When installing the system, the user anonymous is created and the group nobody is assigned to him. This user can connect to the Ruslan server without a password. When each bibliographic database is created, it is automatically included in the nobody group with Search rights and in the library group with Search and Present rights. When creating each service database, it is automatically included in the library group with Search and Present rights. The library group should be given to all ALIS users. This automatically provides access to search and full viewing of all databases for registered users of ABIS and access to search and partial viewing to any Internet users who can connect (under the anonymous user) to the Ruslan server. The latter is determined by the network security policy specific to each organization. If you delete the anonymous user, then only registered users will have access to the Ruslan server.

4.1. Operations on access rights groups To add, delete or change GPAs, select the “Security-Groups” object in the navigator window. A table will appear in the main window, which displays all GPAs and associated BDUs. The group does not exist on its own, but only in conjunction with the UBI. The GPD-BBD pair is unique. The table can be sorted by any column. To do this, left-click on the column header.

Rice. 25 All operations are performed from the context menu (Fig. 25). The “Add” command calls up a dialog box for adding a new GPD-BBD pair (Fig. 26). The “Add by sample” command calls up a dialog box for adding a new GPD-BBD pair, in which all fields are filled in in accordance with the selected GPD-BBD pair. The “Change” command calls up a dialog box for editing the selected GPD-BBD pair (Fig. 27). The same command can be called by double-clicking the left mouse button. In this case, you can only change the comment and access rights (“0” – no right, “1” – yes). The “Delete” command deletes the selected GPA-BBD pair. Each of the operations discussed above changes (after a warning) information about groups directly in the database.

Rice. 26 The “Filter” command (Fig. 28) applies a filter to the table in the main window. It is possible to filter only one column of the main window table.

– – –

filters, they are also canceled. The filter is also canceled automatically when you move to another object in the navigator window and when performing one of the operations described above.

4.2. Operations on users To add, delete or edit a user, select the “Security-Users” object in the navigator window. A table will appear in the main window, which displays all users. The table can be sorted by any column. To do this, left-click on the column header.

Rice. 29 All operations are performed from the context menu (Fig. 29). The “Add” command calls up the user addition dialog box (Fig. 30). The “Add by sample” command calls up a dialog box for adding a user, in which some of the fields (GPA, FG, User Type) are filled in in accordance with the selected user. The “Edit” command calls up the user editing dialog box (Fig. 31). The same command can be called by double-clicking the left mouse button. The Delete command deletes the selected user. Each of the operations discussed above changes (after a warning) information about groups directly in the database.

The "Filter" command applies a filter to the table in the main window. The command action is similar to that described in the previous paragraph.

Rice. 30 In the dialog for adding/editing a user (Fig. 30, Fig. 31), to enter a new password, you must fill in two adjacent fields. The “User name” field contains the user name of the ABIS “Ruslan”, which the user uses for authorization from automated workstations of the ABIS “Ruslan” when connecting to the “Ruslan” server. All unauthorized users can connect to the system only under a user named anonymous (without a password), unless this user is removed from the user list. The username in IBS "Ruslan" is in no way connected with the username in operating system, from which automated workstations are launched.

ATTENTION! The IBS user name “Ruslan” cannot coincide with the group name (GPD).

Rice. 31 To assign a GPA (see previous paragraph) to a user, select a group from existing groups in the “Available Groups” list and click the button with the corresponding arrow. To assign a role (see previous paragraph), select a role from the list " Available roles» and press the button with the corresponding arrow. For roles, their order may matter (see documentation on workstations). To change the position of a role, select it in the Roles list and click the button with the corresponding arrow (up or down).

The user can be either "Local" or "External". "External" users are required to organize a corporate IBA service when storing electronic catalogs of other libraries in this library.

To ensure the normal functioning of workstations, correct installation of both groups and roles is necessary. So, to ensure the operation of acquisition, it is necessary to give the user the roles billcreator and compl, as well as give group(s) that will have the rights to search, extract, insert, change, delete records in the bibliographic databases with which work is carried out, and in service databases accounts, acts, books of summary accounting, descriptions of directories, reference books. In a particular case, rights may differ even for work of the same type, in particular the right to delete records.

5. Library database management

This section describes all operations associated with managing library databases. Library databases are stored in one or more databases. To access library databases, select the required database in the navigator window by expanding the “Data Sources” object (see Fig. 11). A list of library databases in the form of a table will appear in the main window. All operations on library databases are performed from the context menu of the main window (Fig. 32).

Rice. 32 The “Filter” command (Fig. 33) applies a filter to the table in the main window. It is possible to filter only one column of the main window table.

It is supported to apply a filter to the filtering result (nested filters). To do this, set the “Apply to the result of the previous filter” flag. The filter mask is a substring, i.e. using the “BOOKS” mask, rows not only with “BOOKS”, but also with “ABOOKS” will be selected

and with "BOOKS1". The mask is case sensitive.

Rice. 33 To cancel a filter, call the “Filter” command and, leaving the fields empty, click the “Apply” button. If nested filters were used, they are also canceled. The filter is also canceled automatically when you move to another object in the navigator window and when performing one of the operations described above.

5.1. Creation of library databases for an organization Library databases are divided into bibliographic and service. Bibliographic databases are designed to store bibliographic records.

Service databases are intended for storing library non-bibliographic data, such as reference books, acts, subscription data, orders, data about readers, etc.

Rice. 34 Bibliographic databases store records in a format close to ISO2709.

Service databases store records in the specialized format of the ABIS "Ruslan".

Each service database record consists of one or more fields. The field name is a numeric identifier (tag). Each field can have one or more instances. The field value can be either a string (up to 1500 characters) or binary data (not indexed, size up to 4 GB). Binary type fields store photographs of readers, data on MBA orders, etc.

To create a bibliographic database, select the “Create-Bibliographic Database” command from the context menu (Fig. 32). A dialog box will appear (Fig. 34), in which you need to enter the name of the database (in English letters), select the record format and storage areas for storing database elements: records, dictionary and index (see IBS "Ruslan". Installation Guide, paragraphs. 3.1, 3.3, 3.4). After selecting a record format (except for the “MARC” format), some of the fields in the dialog box will be automatically filled in. It is not recommended to change these values.

When selecting the “MARC” record format, the administrator is given the opportunity to independently set the values for the fields:

“Access point list identifier” (see clause 2.3) “Scheme identifier” (last number in the scheme OID, see description of the Z39.50 protocol) “Write syntax identifier” (last number in the write syntax OID, see description of the Z39 protocol .50) “MARC record indexing table identifier” for the first and second phase (see clause 2.2) If single-phase indexing is used, then the MARC record indexing table identifier for the second phase should be “0”.

After filling out all the fields, click the “Run” button. A new bibliographic database will be created.

To create a service database, select the “Create-Service DB” command from the context menu (Fig. 32). A dialog box will appear (Fig. 35), in which you need to enter the name of the database (in English letters) and select storage areas (see IBS "Ruslan". Installation Guide, paragraphs 3.1, 3.3, 3.4) for storing database elements: data ( row fields of records) and LOB data (polar binary data of records).

Rice. 35 After filling in all fields, click the “Run” button. A new service database will be created.

ATTENTION! The names of library databases must be unique not only within one source (IDB), but also within all sources registered in the system (see clause 2.1).

5.2. Editing the parameters of an organization's library databases To edit the parameters of a library database, select the row with the required database in the table in the main window and call the “Edit” command from the context menu (Fig. 32). A dialog box will appear (Fig. 36).

Rice. 36 Most database parameters (except for name and type) can be changed. Setting the “Available” flag means that access to the database is allowed via the Z39.50 protocol. Setting the “Scan by words” flag means that according to the specified access points (see paragraph 3.1, Scan parameter) when the “Ruslan” server starts

scan indexes will be loaded into RAM ( search indexes), which are accessed through the Scan service (see description of the Z39.50 protocol). The Scan service is integrated into the Acquisition/Cataloging workstation. If, after setting the “Scan by words” flag for the required databases, signs of a lack of RAM appear on the computer on which the “Ruslan” server is running, then you must either turn off this flag for some databases, or reduce the number of search attributes for the “Scan” service. (in the Scan parameter). The “Scan by value” flag is not supported in this version.

The "Directory" parameter can have two values: "Local" and "External". When creating a database, this parameter is set to “Local”.

The value “External” is set for bibliographic databases that belong to third-party organizations and from which it is possible to order literature on MBA.

DB aliases are synonyms for the database name. The database name can only be in English. The alias can be specified in any language and is stored in unicode encoding. Aliases are usually used in the Acquisition/Cataloging workstation and the Reader workstation for a better and more understandable reflection of the content of the database. The database alias is also always its name. This alias cannot be deleted. A database can have several aliases. It is strictly not recommended to give the same aliases to different databases, not only within one source (IDB), but also within all sources registered in the system (see clause 2.1). If you need to combine several databases (of the same type) under one name (alias), you should create a virtual group name (see section 3.1, GroupDB parameter).

An entry key consists of a prefix and an entry number. The record number is generated automatically upon insertion new entry. The numbering of records is sequential, starting from 1 (by default, see clause 5.10). Deleted numbers (generated when records are deleted) are not reused. The prefix consists of several parts. The prefix structure is not a standard. It is recommended to select three fields in the prefix, separated by a slash: country code, organization code, database name. For example, the key prefix for records from the database

BOOKS of the Fundamental Library of St. Petersburg State Technical University is as follows:

RU\SPSTU\books\. In general, it is not recommended to give the same prefixes to different bibliographic databases of an organization. This, in most cases (excluding special management of the number part of the key), will lead to the appearance of different records with the same key, which can create certain problems when loading/unloading, linking records, for the operation of the order service. The entry key prefix can be specified in any language (stored in unicode).

The dialog also allows you to change the identifiers of the indexing tables and the list of access points. However, this is not recommended. When changing the identifier of an indexing table, if this database contains records, you must delete the index (see section 5.4) and reindex the database (see section 5.4).

clause 5.5). When changing the identifier of the list of access points, they must be updated (see clause 5.7).

It is strictly not recommended to change the parameters “Scheme OID”, “Record syntax OID”, “Attribute set OID” except as specifically stated in this manual and in the installation manual.

5.3. Determining quantitative indicators of library databases To determine the number of records in a library database, select the row with the required database in the table in the main window and call the “Number of records” command from the context menu (Fig. 32). The result of the command execution is displayed in the log window. This information is the most reliable (compared to determining the number of records through search queries).

For bibliographic databases, you can determine such processing indicators as the number of unique barcodes and the number of document copies in the database. To determine these indicators, select the row with the required database in the table in the main window and call the “Number of barcodes” and “Number of copies” commands from the context menu (Fig. 32). The result of command execution is displayed in the log window.

5.4. Removing a library database or data from a library database To delete a library database, select the row with the required database in the table in the main window and call the “DeleteDelete database” command from the context menu (Fig. 32). After two warnings, the selected database will be deleted with all data. Data can only be restored from an archived copy.

To delete data from a library database, select the row with the required database in the table in the main window and call the “Delete-Delete data from database” command from the context menu (Fig. 32). After two warnings, a dialog box will appear (Fig. 37), in which you must select the part of the data that needs to be deleted. The Delete All Data option deletes all entries, including old versions and the index. Data can only be restored from an archived copy. The Remove Index option removes only the index. This operation is required when it is necessary to re-index the entire bibliographic database after significant changes to (batch) records. The "Delete all old versions of entries" option deletes all old entries. After this operation, it is possible to restore the old version of a record from this database only from an archive copy. The options “Delete old versions of records older than 1 year” and “Delete old versions of records older than 2 years” delete old records with a specified period of limitation with a corresponding reduction in recovery options.

The “Delete records by request” option deletes all records that match the request, including the index. These entries are not included in the rollback table, but older versions of the deleted entries are retained in the rollback table.

Before performing the actual deletion, a message will be displayed with the search result (how many records were found) and at this stage you can still refuse the deletion. The search query format is given in Appendix 4. The format will also be displayed on the screen if you click on the “?” button.

Rice. 37

5.5. Indexing/re-indexing of a bibliographic database This operation (indexing) is required after loading records, otherwise the records will be unavailable for search. Also, the operation (reindexing) is necessary after changing the indexing tables of records, as well as after performing batch changes.

Rice. 38 During the reindexing process, the old index will be deleted sequentially for each record and a new one will be created. Moreover, during the reindexing process, all records are searchable, but it takes significantly more time to complete compared to indexing.

first delete the index (see section 5.4), and then perform indexing. It is not recommended to allow modification operations (insert, change, delete) to occur during reindexing. Therefore, either perform re-indexing during non-working hours, or make the database temporarily unavailable (see.

To index/reindex records in a bibliographic database, select the row with the required database in the table in the main window and call the “Reindex” command from the context menu (Fig. 32). A dialog box will appear as in Fig. 38.

By default, indexing/reindexing is performed using indexing tables whose identifiers are specified in the database parameters.

If you need to perform an operation with another indexing table, then in the “Indexing Table” field you should specify the identifier of the required indexing table. It is possible to re-index/re-index only certain fields. To do this, in the “Indexing table” field you should specify the required fragment of the descriptive part of the indexing table (see clause 2.2). It is not recommended to enter anything into the Indexing Table field unless you are sure of what you are doing.

There are three modes of indexing/re-indexing: all records, a certain range of records, or records not indexed in phase 1 (in phase 1 - since only the successful completion of phase 1 of indexing is recorded - see paragraph 2.2). The latter mode is applied if new records were additionally loaded into the database containing indexed records or if the database indexing was interrupted. In the second mode, the record numbers in the range correspond to the order in which records are entered into the database. That's why this opportunity should be used when indexing/re-indexing the entire database in known portions. For example, to test the result or in case of time constraints.

To start the indexing/reindexing process, click the “Start” button. It is possible to interrupt the process at any time by clicking the “Close” button and continue at another time. It is also possible to pause the process by clicking the "Stop" button and then continue by clicking the "Continue" button. Processing the “Stop” and “Close” commands (but not in the case when the dialog box is closed using the “x” button) may take some time, since statistics are analyzed (see section 5.6), which is also carried out after indexing/re-indexing the first 1000 records, every 10000 records and at the end of the operation.

5.6. Analysis of statistics for library databases The Ruslan data schema uses various indexes of the Oracle DBMS.

Oracle DBMS provides best quality(by time) search based on statistical data. The DBMS does not collect this data automatically - for this there is a special statistics analysis command that is integrated into the automated workplace. Over time (if record modification operations have been carried out), the statistics become outdated and the quality of the search decreases. Therefore, statistics analysis must be carried out periodically for all library databases (when the database size increases by several thousand records). The need to analyze statistics is indicated by a gradual (not sharp) increase in search time for known queries (if there have been no changes in the equipment and configuration of the physical database). During the process of loading records and indexing (re-indexing) records, statistics are analyzed automatically.

To analyze the statistics of a library database, select the row with the required database in the table in the main window and call the “Analysis” command from the context menu (Fig. 32). After the analysis is completed, a corresponding message will appear in the log window. It is possible to set statistics analysis for several databases simultaneously (the analysis itself will be carried out sequentially for each database).

To do this, select several databases in the table and select the “Analysis” command in the context menu.

The Ruslan server version 2.13 and higher performs automatic analysis of statistics every night, and it is recommended to perform manual analysis only after making significant changes during a batch change with partial reindexing.

5.7. Updating access points to bibliographic databases The description of access points (see section 2.3) is separated from their application to bibliographic databases (as opposed to indexing tables). Those. When changing access points in a certain list of APs, these changes are not automatically applied to the databases associated with this list of APs. Also, if the identifier of the TD list for a certain database changes (see section 5.2), the TDs for this database remain the same. You must update the TD manually. This operation is quick and non-critical.

To update the TD of a bibliographic database, select the row with the required DB in the table in the main window and call the “Update TD” command from the context menu (Fig. 32). After the operation is completed, a corresponding message will appear in the log window.

It is possible to update access points for several bibliographic databases simultaneously. To do this, select several databases in the table and select the "Update TD" command in the context menu. After processing each database, a message will appear indicating the successful (in the log) or unsuccessful (message blocking further work) completion of the process for the specified database. If a message is issued about the unsuccessful completion of the process for any database, after clicking the "OK" button, the program proceeds to updating access points for the next database. In the future, for the database for which the process failed, it is necessary to repeat the operation. If the process fails for all selected databases, then this means an error in the syntax of specifying some access point. To simplify the selection of a database with the required AP list identifier, you can sort the table by the “Access Points” column or apply a filter (see step 5).

5.8. Loading records into library databases The loading operation ensures loading of data into both bibliographic and service databases. For bibliographic databases, loading from a file in ISO2709 format is supported. For service databases, loading from a file in the Ruslan format is supported (see Appendix 3). The following record encodings are supported: DOS (866), MS Windows (1251), KOI-8, UNICODE (UTF-8).

Records of the format (RUSMARC, USMARC,...) for which this database was created should be loaded into the bibliographic database. After downloading bibliographic records, to provide search capabilities, the records must be indexed (see clause 5.5). Service database records are indexed during the loading process.

To load records into the library database, select the row with the required database in the table in the main window and call the “Load” command from the context menu (Fig. 32). In the dialog box that appears (Fig. 39), you must specify the file either manually (with the full path) or using the standard file selection dialog box. To open the file selection dialog, click the "" button to the right of the file name input field. After this, select the encoding in which the records in the file are presented and wait until the process of counting the number of records in the file is completed (the “Number of records in file” field will no longer change).

For the bibliographic records file, you must select the MARC format (RUSMARC, UNIMARC, USMARC, MARC - if different from the first three) and the type of MARC format (bibliographic, authoritative, classification). It is also possible, if necessary, to specify the options “Add a prefix to the key” (in field 001) and “Generate a doublet key”

(in field 998 and only for RUSMARC).

If there are no keys in the downloaded records or they do not suit you, then you should set the “Generate record key” option. In this case, a new key will be generated for each inserted record in accordance with the current database prefix (for bibliographic databases) and the setting of the key number generator (see clause 5.10). When creating a new database, the key number generator is set to “1” (key numbers will be generated starting from 1).

Rice. 39 The options “Generate record key” and “Add prefix to key” are mutually exclusive.

The loading operation allows you to control the order of loading records - you can load all records, records in a range (the numbers of records in the range correspond to the order of records in the downloaded file), records “From the first not inserted to the end.” Last option will work correctly if the database into which the records are loaded was initially empty, and also if the original records file and the bad (damaged) records file were not modified between loading stages. The bad records file has the name corresponding to the source file of the downloaded records and the extension ".bad" and is created in the same directory as the source records file. If it is impossible to insert a record into the database, the record is placed in the bad records file.

To start the download process, click the “Run” button. You can interrupt the downloading of records at any time by clicking the “Close” button and continue at another time. You can also pause the downloading of recordings by clicking the "Stop" button, and then continue by clicking the "Continue" button.

Note.

5. If among the loaded records there are related records, then generating new keys will break these connections.

6. The doublet key is generated according to the rules of the automated information system "Ruslan".

7. Checking for duplication is carried out when entering new records from the Acquisition/Cataloging Workstation. Duplicate checking is not performed during loading.

8. After loading records without generating new keys, you must set the key number generator to a new value (see clause 5.10) to prevent the generation of doublet keys.

5.9. Unloading records from library databases The unloading operation ensures unloading of data from both bibliographic and service databases.

For bibliographic databases, uploading to a file in ISO2709 format is supported. For service databases, uploading to a file in the Ruslan format is supported (see Appendix 3). When uploading, records can be recoded into the following encodings: DOS (866), MS Windows (1251), KOI-8, UNICODE (UTF-8). In the latter case, no recoding is performed, since records in library databases are stored in UTF-8 encoding.

To upload records from the library database to a file, select the row with the required database in the table in the main window and call the “Upload” command from the context menu (Fig. 32). In the dialog box that appears (Fig. 40), you must specify the file either manually (with the full path) or using the standard file selection dialog box. To open the file selection dialog, click the "" button to the right of the file name input field. After this, select the encoding in which the entries in the file should be presented.

Rice. 40

It is possible to either overwrite the file (the old contents are lost) or add the uploaded records to the end specified file. The “Line by Line” option specifies that a newline character (in Windows style, i.e. two bytes) will be inserted after each record in the file.

The “Delete tags” field is used to specify the list of tags that should be deleted when unloading from service database records. Tags are separated by commas (without a comma at the end).

The upload operation allows you to control the order in which records are uploaded - you can upload all records, a certain range of records, and records selected by request (for the request format, see Appendix 4). The record numbers in the range correspond to the order in which records are entered into the database. Therefore, this feature should be used when unloading the entire (or part) of the database in known portions.

On-demand record upload can be used to archive changes (newly created and modified records from certain point time). Thus, the request “@1012,5,0,2,0,0,8=20010521” will download (from the specified bibliographic database) all records created or changed during the period from May 21, 2001 to the present.

For a service database, a similar query would look like this:

"@3.5,0.2,0.0.8=20010521."

To start the upload process, click the “Start” button. You can interrupt the uploading of records at any time by clicking the “Close” button and continue at another time. You can also pause uploading records by clicking the Stop button, and then continue by clicking the Continue button.

Note.

1. Unloading from bibliographic databases is possible only in the “native” MARC format, i.e. in the one in which the records were loaded.

2. If unloading from the database occurs at a time when users can work with this database through the Ruslan server, then the loss of records in the file (their number does not correspond to the expected one) is possible as a result of deleting records by users from this database.

5.10. Setting the initial number of the library database record key generator After creating a new database, the generator for this database is set to “1”, i.e.

when inserting new records from library workstations, they will be numbered (using the key for service databases and the numerical part of the key for bibliographic databases) sequentially starting from 1.

Rice. 41 If, after creating a database, records are loaded into it without generating a key (see clause 5.8), then when inserting new records from library workstations, it may turn out that the newly generated key will already exist.

As a result, an error will occur when inserting a record. For example, you loaded 3 records into some bibliographic database without generating keys. These records have keys with the numeric part "5", "6" and "7". Next, 4 records from the library workstation were inserted into this database. They received keys with the numerical part “1”, “2”, “3”, “4”. If you try to insert a 5th record into this database, an error will occur because the key with the numeric part “5” already exists. To prevent this from happening, the key generator should be shifted, i.e. set a new starting number for it. For the example given, the new generator starting number should be "8".

To set a new initial number of the key generator, select the row with the required database in the table in the main window and call the “Set key” command from the context menu (Fig. 32). In the dialog box that appears (Fig. 41), you will see last number in the key in the records of this database, the current generator number and the new initial generator number proposed by the system. If you are not satisfied with the new starting number proposed by the system, you can set the number that you think is correct.

Click on the "Run" button to set the specified new key generator seed number. A message indicating the successful completion of the operation will appear in the log window.

Note.

1. If the operation is canceled, the value of the generator will be increased by 1. Therefore, if you decide not to change the starting number of the generator (the current number corresponds to the new starting number), click the “Run” button anyway.

5.11. Viewing records in library databases To view records, select the row with the required database in the table in the main window and call the “View” command from the context menu (Fig. 32).

The same command can be called by double-clicking the left mouse button on the line with the required database. For a bibliographic database, a dialog box will appear as in Fig. 42, and for a service database – as in Fig. 43. If there are no records in the database, or in case of errors, the message “Error retrieving the first record!” is displayed.

Rice. 42 Navigation buttons allow you to go to the first record in the database (“|”), to last entry to the database (“|”), to the next record (“”), to the previous record (“”). If you go to a non-existent record, the message “Error retrieving record!” is displayed. For bibliographic databases, it is possible to navigate to a specific record identified by an internal (DB key) or external (key from MARC field 001) key. To do this, enter the key in the appropriate field of the dialog box and press the "Enter" key.

(“Enter”). For service databases, it is possible to move to a specific record identified by an internal key.

The status of a bibliographic record means: 0 – the record is not indexed, 1 – the record is indexed (by at least on phase 1 in case of two-phase indexing).

Rice. 43 For a bibliographic database, it is possible to select (to select the entire record, place the cursor in the record field and press Ctrl+A) and copy the text representation of the record to the clipboard (the standard key combination is Ctrl+C).

For a bibliographic record, information about who created it and when is displayed in appropriately named fields. For an official record, information about who created it and when is located in fields 2 and 3 of the tag, respectively (date format: YYYYMMDDDHHMMSS). If the record was created during the download process from the Administrator's workstation, then the name of the creator is “phloader”.

The “Delete” button is used to delete a record from the database. When deleted, the entry is placed in the rollback table (see section 5.13). After removing it, it still remains on the screen. For bibliographic databases, the operation of indexing/reindexing the viewed record is supported (the “Reindex” button). Indexing/reindexing is performed in accordance with the indexing tables defined for the selected database (see clause 5.1).

5.12. Control of doublets in the fields of MARC records and service records Control of doublets allows you to obtain a list of doublet values in a specified field (subfield) of a MARC record or field of a service record. This operation is useful for controlling the duplication of inventory numbers, barcodes, etc.

To obtain a list of doublets in the bibliographic database, select the row with the required database in the table in the main window and call the “Doublets” command from the context menu (Fig. 32). In the dialog box that appears (Fig. 44), in the “Field” field, enter the number of the field (subfield), in the “Quantity” field – a limit on the number of values to be retrieved.

To search for doublets, click the “Find” button. After the search operation is completed, a message appears indicating the number of doublets retrieved. If it is equal to the limit, then there are probably more doublets. The doublets will be displayed in the table of the dialog box. The “Value” column displays the values of the specified field (subfield), which are repeated in the records of the selected database. For service databases, this value is truncated to the first 32 characters. The “Duplicity” column displays the number of repetitions of a value in all records of the selected database.

When you close the Doublet Search dialog box, a message appears asking you to save the found doublets to a text file for later use by librarians.

Rice. 44

5.13. Viewing the history of changes in bibliographic records and restoring a deleted or changed record IBS "Ruslan" stores the history of changes in bibliographic records for each bibliographic database. When a record is changed, the old version of the record is placed in what is called a rollback table. When an entry is deleted, it is also placed in the rollback table. For each record, it is stored who created it and when. It is possible to restore any version of a record to the database (if this version has not been deleted).

Rice. 45 To view the rollback table of a certain database, select the row with the required bibliographic database in the table in the main window and call the “Rollback” command from the context menu (Fig. 32). A dialog box will appear as in Fig. 45.

For each record, the internal key (DB key) is displayed; foreign key (from MARC field 001); operation, as a result of which this entry was placed in the rollback table; the user who created (as a result of a load, insert or modification operation) this version of the record in the case of the Change and Delete operations, or who deleted the record in the case of the Delete operation; time when it was created (and not placed in the rollback table!) in the database this version record, in the case of Modify and Delete operations, or the time at which the Delete operation was performed (when the record was placed in the rollback table as a result of the delete operation).

Rice. 46 In the example in Fig. 45, a record with the key “ru\spstu\books\139427” was loaded into the Administrator’s workstation (user phloader) on 02/14/2004 at 15:53:23.

The following version of the entry was created by the user compl on 02/24/2004 at 11:35:29 and was rolled back as a result of the change operation. The following version of the entry was also created by the user compl on 02/24/2004 at 11:36:34 and was rolled back as a result of a delete operation performed by the user compl_admin on 02/24/2004 at 11:40:23. Record with key “ru\spstu\books\139435”

was uploaded to the Administrator's workstation (user phloader) on 02/14/2004 at 15:53:23. On 02/24/2004 at 11:38:30 this entry was deleted by the system administrator (libmgr) from the Administrator's workstation.

Rice. 47 All operations in the rollback window are carried out through the context menu (Fig. 46). To compare the old version of a record with the current one (in the working database), select the table row with the old version and double-click on it with the left mouse button or select the “Compare” command from the context menu. A dialog will appear as in Fig. 47. The top part of the dialog contains the current record from the database, its creator and the date of creation. The bottom part of the dialog contains an entry from the rollback table, its creator and the date the entry was created. If the current record (in the database) has been deleted, the top part will be empty.

To compare entries from the rollback table, select the two entries you are interested in and select the “Compare” command from the context menu.

To restore an old version of a record, select the required old version and select the “Restore” command from the context menu. To restore the latest version of a deleted record, you can select a table row with either a Delete or a Deleted operation. If you restore an old version of a recording that was not deleted, Current version will be placed in the rollback table. The restored record is considered to be created by the DBMS user, who is the owner of the database (see clause 2.1) in which this bibliographic database is located. In the example discussed in this tutorial, this user would be lib1 (see

for example Fig. 45).

Rice. 48 Information about old versions of records is displayed in the rollback dialog box in portions of 30 versions. When you open the rollback dialog, the 30 most recent versions of records in the specified database are displayed. By default, entries are sorted by date in descending order. You can sort the rollback table by any column by left-clicking on the column header. To retrieve the next 30 versions, select Select More from the context menu. To quickly find a new portion of versions, before issuing the “Select More” command, select the last line in the list - this line will remain selected after executing the command.

Since many versions of records accumulate in the rollback table over time, it is possible to filter them. After applying the filter, record versions are also displayed in portions of 30 pieces. To set a filter, select the “Filter” command from the context menu. A dialog box will appear (Fig. 48), in which you can set filtering by internal key (database key), by foreign key (from MARC field 001), by the operation that resulted in the entry being included in the rollback table, by the user who created the version record or the person who deleted the record and by the date the record version was created or the record was deleted. For the internal key and date, you can specify a relationship (, =...). A foreign key is always filtered by the LIKE operation. In the absence of special characters (“_”, “%”), this operation works for equality. The special character underscore (“_”) means any character (one!). The percentage special character (“%”) means any number of characters. Usually the special character percentage is used to avoid specifying a key prefix, which is normally the same for all bibliographic database records. To remove a filter, call up the filter dialog box, first click on the “Clear” button and then “Accept”. The “Leave unchanged” button closes the filter window without making any changes to the filtering conditions.

To reduce the overall size of the database and increase the speed of working with old versions of records, it is recommended to periodically clean the rollback table (deleting very old versions). This operation can be performed in several ways. Most quick way Removing all old versions is given in paragraph 5.4. You can also delete all old versions from the rollback dialog box by selecting the “Delete-All” command from the context menu. To delete selected versions of records, select the “Delete-Selected” command from the context menu. To delete all versions of records that match the applied filter, select the “Delete-All by filter” command from the context menu.

5.14. Batch modification of bibliographic records IBS "Ruslan" provides two options for batch modification of bibliographic records: simple and advanced. The simple option is limited in its capabilities, but has a friendly user interface. The advanced option allows you to make any changes to records, but requires the participation of a programmer to create a program for these changes. Therefore, for the extended version, the support service supplies a special library (DLL) with typical changes. As part of technical support, you can order the necessary changes (contact [email protected]).

To perform a simple batch change on a certain database, select the row with the required bibliographic database in the table in the main window and call the “Change records - Simple change” command from the context menu (Fig. 32). A dialog box will appear as in Fig. 49.

It is possible to carry out three simultaneous change operations:

replacing/adding a substring in a field (subfield) or in an embedded field (subfield) in a communication field. The change operation is performed on all instances of the subfield in all instances of the record field. Adding a subfield is done only for existing fields and in all instances of fields, i.e.

if there is no field, it will not be created automatically. It is possible to replace an entire string when setting the option " whole line", performing the operation of deleting a field (subfield) when specifying the "delete" option, performing the operation of adding a substring (possibly together with adding a subfield) when specifying the "add" option (the value in the "replace" field acts as a record filter). In the latter case, you can specify what to do if the subfield exists: add, do not add, concatenate on the left (option “lk”) or on the right (option “pc”). If you enable the "add" option, a non-existent subfield will be added only if the field exists;

replacing indicators in a field or in a built-in field in a communication field;

replacing a substring in a coded field (subfield) or in an embedded coded field (subfield) in a communication field. The “add” option allows you to add a coded field (subfield) always or if it does not exist. A missing indicator is specified by a space. The token is specified by specifying 000 in the coded field. For coded fields, the position from which changes are made is specified (starting from 0). In this case, the lengths of the replaced and replacing substrings must match.

Rice. 49 To add a subfield along with adding a field (when the field does not exist), you must set its parameters in the section for the coded field, regardless of whether the field is coded or not.

In the areas for entering data strings ("replace" and "to"), you can specify macro substitutions in the form of a link to a subfield, for example, (999a). In this case, the value of the string will be taken from the corresponding subfield. If the field specified in the macro matches the field on which the modification operation is performed (entered in “In Field”), then the row value for each instance of the field will be taken from the corresponding instance of the field. If the fields are different, then the row value will be taken from the first instance of the field specified in the macro.

Rice. 50 Using macro substitutions allows you to copy data from one subfield to another (add operation) and obtain more complex filters during delete/replace operations.

To perform an extended batch change on a certain database, select the row with the required bibliographic database in the table in the main window and call the “Change recordsExtended change” command from the context menu (Fig. 32). A dialog box will appear as in Fig. 50.

In the “DLL File” field, you must enter the name of the dynamic library file (must have a dll extension) indicating the full path manually or using the standard file selection dialog. To open the dialog, click the "" button to the right of the file name input field. After selecting the DLL file from the Change Name list, select the desired function function (FuncName). If DLL file supplied by the system support service, the assignment of functions is given in the accompanying documentation. After selecting a function, the “Log” field will display Additional Information on working with the function. In the Options File field, enter the name of the options file if one is required for the selected feature.

Both the simple and advanced batch change options have the following common customization elements. Changes can be made either directly in the working database, which is specified in the “Database name” field, or by copying new records to another (preferably empty) database (to do this, its name must be selected in the “Name of the database into which to place the changed records”) field. . The copy base must be created before the batch change procedure can begin. This makes it possible to check the correctness of changes in records and avoid damage to records in the working database. If changes to records occur correctly, then you can start the procedure for changing records directly in the working database. To do this, the “Name of the database in which to place the changed records” field must remain empty; you do not need to select anything in it! Wherein old version each entry (before modification) will be put into rollback. It is recommended that before correcting records in the working database, make an archive copy of it (see paragraph 7).

In the “Parsing table” field, you can specify a special indexing table or a fragment of the descriptive part of the indexing table (see.

clause 2.2) for indexing/re-indexing of changed records. It is not recommended to enter anything into the Indexing Table field unless you are sure of what you are doing. The value “0” (default) in this field means: do not index changed records. It is recommended to specify this value if non-indexed fields/subfields are modified.

If you do not enter anything in the Indexing Table field, the default indexing tables for the given database will be used (recommended if the indexed fields are changing).

It is possible to view all records for changes or in a certain range (in the order of entry into the database). When simple change It is also possible to change the records selected by request (see Appendix 4).

The “Rollback” flag determines whether or not old versions of records will be rolled back. It is recommended to clear this flag if you are confident in the correctness of the changes made (the correctness of the changes was carefully checked using a test database into which the changed records were placed) and a large number of records are changed.

To start the batch change process, click the “Run” button. The process can be paused by clicking the “Stop” button, and then continued by clicking the “Continue” button. The Close button pressed during the process interrupts its execution. The process of changing records is reflected in the log. Indicates how many records were viewed, how many were proposed for change, and how many were successfully changed.

Note.

1. In case batch change(in which the indexed fields/subfields are changed) covers a significant percentage of records in the database, it is recommended to set the “Indexing table” field to “0” and, after a batch change, delete the entire index (see section 5.4) and index the database again (see. clause 5.5).

2. If the change process is interrupted, the records that have been changed up to this point will remain in the changed state. To restore the original recordings, use the function of restoring old versions of recordings (see.

p. 5.13) or restore an archived copy of the database.

3. During the batch change process, statistics are not analyzed.

The administrator must, if necessary (if indexed fields/subfields are changed), perform it independently (see clause 5.6). It is recommended to analyze the statistics after making all the required changes.

6. Library technologies This section describes the operations necessary to configure applied technological cycles performed both independently by the Ruslan server and technological cycles implemented in conjunction with various workstations of the system.

6.1. Working with the buffer database IBS "Ruslan" supports two technologies for entering new records. The first technology assumes the presence of one main bibliographic database (for a type of document, for example, for books). Library staff create records in this database. Readers, when working with the electronic catalogue, also work with this database. In this case, a problem arises related to the accessibility for readers of bibliographic descriptions that have not yet gone through the full cycle of bibliographic processing, i.e. the documents were not received by the service departments. The reader can order documents that are not available for service. This problem can be resolved in the following way. For records that have not been processed, a status is “set” (in the record marker), meaning the document is not fully catalogued. And in the reader's user interface, a hidden filter is introduced based on the status of the entry. The disadvantage of this method of hiding records on incompletely cataloged documents from readers is that it is resource intensive (reduced system performance).

The Ruslan system also offers another technology for hiding records of incompletely cataloged documents from readers. In addition to the main bibliographic database (for the document type), a buffer bibliographic database (for the document type) is created. New records are entered and processed in the buffer database. Upon completion of processing, documents are transferred to service departments, and records on these documents are transferred from the buffer database to the main one. The buffer database is made inaccessible to readers (see point 4). The advantage of this technology is that you can configure different levels of access to the buffer and main database for library employees. This increases the security of the main database (for example, the delete operation is allowed only for the buffer database).

To transfer complete records from the buffer bibliographic database to the main one, select the row with the required buffer database in the table in the main window and call the “Move records” command from the context menu

(Fig. 32). After a certain period of time, during which the records in the buffer database are analyzed, a dialog box will appear (Fig. 51), in which you must select the main database into which the records will be moved.

Rice. 51

Only complete records are moved. In the case of hierarchically related records, the top-level complete records are always moved. The number of moved records of not the highest level can be varied manually, automatically made a multiple of 5 or 10. In addition, it is possible to simultaneously save moved records of not the highest level to a file in one of the encodings: DOS (866), MS Windows (1251), KOI-8 or UNICODE (UTF-8). To save records to a file, you must specify the file name manually (with the full path) or using the standard file selection dialog box.

To open the file selection dialog, click the "" button to the right of the file name input field. You can either overwrite the file (the old contents are lost) or append paged records to the end of the specified file. The “Line by Line” option specifies that a newline character (in Windows style, i.e. two bytes) will be inserted after each record in the file.

To start the operation of moving records, click the “Run” button. The progress of the operation will be reflected in the log. After moving records, you will be prompted to index them. If you agree, indexing will be performed in accordance with the indexing tables specified in the parameters of the main database (see clause 5.1). In case of failure, the indexing operation (if required) is performed manually (see clause 5.5).

6.2. Borrowing analytics Borrowing analytics is borrowing bibliographic records from component serial publication.

When working on compiling analytical records, it is recommended to make sure to establish connections based on field 001 between the record for the component part, the record for the release of the serial publication and the record for the serial publication as a whole. When manually creating an analytical record in the Cataloger's workstation, connections based on fields 001 are established automatically. The procedure for borrowing analytical records from external source has a number of features that complicate the restoration of communication based on the 001 field. The main reason is that borrowing is carried out immediately from all records of the serial publication. At the same time, restoring connections in the Cataloger's workstation is only possible individually for each record.

To increase the efficiency of the process of borrowing analytical records, the Ruslan server version 2.11 and higher has implemented a mechanism for automatically restoring communication based on fields 001. Based on the information about the serial publication (ISSN, title, year, issue number) available in the analytical record, local databases contain own entries for the serial publication as a whole and entry for the release of the serial publication. In the borrowed analytical record, the original contents of the fields embedded in fields 461 and 463 are replaced with data from the found records. If the records could not be found, the server returns a diagnostic. In this case, it is necessary to carry out the procedure of relinking records in manual mode using the standard capabilities of the AWS Cataloger.

The implemented mechanism does not guarantee a 100% successful rebinding result. There is a fairly large percentage of publications (2-10%) for which the result of relinking may be incorrect. Also, the result of relinking significantly depends on compliance with the RUSMARC format when creating (or converting) bibliographic records.

To ensure the correctness of the main working databases, it is not recommended to borrow analytical records directly into working databases, but to use intermediate databases for temporary storage and control of linked records. Starting from Ruslan server version 2.11, the restriction on mandatory storage of records for a component and records for a source in one physical database has been removed. In this regard, it is recommended to create separate working databases for storing analytical records and another intermediate database.

Rebinding using an intermediate base

The procedure for setting up the rebinding mechanism using an intermediate base consists of the following 4 steps:

1. Create an additional bibliographic database for temporary storage of analytical records (for example, ANALIT_TMP). If necessary, create a new bibliographic database for permanent storage of analytical records (for example, ANALIT), if the standard SERIAL database will not be used for this purpose.

2. In the CorpDB server parameter, add the ANALIT_TMP database.

3. In the SerialItemDBMap server parameter, specify the correspondence between the database used to store serial records and the databases used to store analytical records (for example, if serial records are stored in the SERIAL database, then the string “SERIAL,ANALIT_TMP,ANALIT;” must be specified in the parameter).

4. Restart the server.

This mode allows you to add analytical records to the working database (for example, ANALIT) without using the relinking mechanism.

Rebinding without using an intermediate base

The procedure for setting up the rebinding mechanism without using an intermediate base consists of the following 4 steps:

1. Create a new bibliographic database for permanent storage of analytical records (for example, ANALIT_2005).

2. In the CorpDB server parameter, add the ANALIT_2005 database. Do not use the SERIAL database in the CorpDB parameter.

3. In the SerialItemDBMap server parameter, add an indication of the correspondence between the database used for storing serial records and the databases used for storing analytical records (for example, if serial records are stored in the SERIAL database, then in the parameter you must specify the string “SERIAL,ANALIT_2005;”).

4. Restart the server.

This mode does not provide the ability to add analytical records to the working database (for example, ANALIT_2005) without using the relinking mechanism (i.e. the relinking mechanism always works), but has, on average, a higher operating speed.

Rebinding via intermediate base

To use the relinking mechanism through an intermediate base, you must perform the following steps in the Cataloger Workstation:

4. Copy records to the intermediate database (for example, ANALIT_TMP).

5. Find records in the intermediate database.

6. If the resulting records are satisfactory, then copy them to the working analytics database (in this mode of use it can be either SERIAL or ANALIT).

7. If the results of relinking are not satisfactory, then perform manual relinking in the working database.

8. Delete entries from ANALIT_TMP.

Rebinding without an intermediate base To use the rebinding mechanism without an intermediate base, you should perform the following steps in the Cataloger Workstation:

1. Connect to the local server.

2. Connect to a remote server.

3. Find analytical records for the desired serial issue.

4. Copy records to the working database (for example, ANALIT_2005).

5. Find records in the working database.

6. If you are satisfied with the resulting records, then continue working on the next batch of records (or complete the work).

7. If the results of relinking are not satisfactory, then adjust the records and manually relink in the working database (for example, ANALIT_2005).

To speed up the operation of record relinking mechanisms, it is recommended to process the old array of serial and analytical records (reduce the size of the database used to store serials).

If in previous work the SERIAL database was used to store serial and analytical records, then it is recommended to select all analytical records from this database and place them in a separate database (for example, ANALIT_OLD). Create a separate database for storing analytical records (for example, ANALIT) and use it to store new analytical records. Since when using borrowing technologies, the volume of databases can grow at a much faster pace than when creating descriptions independently, it is recommended to create a new database for storing analytics when the current database reaches a volume of about 200,000 thousand records.

6.3. Setting up means for background processing of bibliographic records The Ruslan server supports the ability to automatically process records in bibliographic or authoritative databases based on data files in the RUSMARC, USMARC, UNIMARC format. Processing includes three operations: loading (inserting a new record), updating and deleting (for old records). When an update operation is performed, a record in the database is replaced with the entire record from the file.

The Ruslan server supports four automatic processing schemes.

F035Type, MARSType, RKPType. The main difference in the schemes is the method of unique identification of a service record. To ensure work of this service two mandatory (for this service) server parameters are used:

LoadFilesDB Contains a list of bibliographic databases to load.

If you intend to perform update and delete operations, then four additional parameters must be specified (present in the distribution kit of the server part of the IBS "Ruslan" by default):

RF24 Contains a service line for generating a request to delete a bibliographic record (records) from the database. Used for RKPType processing scheme.

RF25 Contains a service line for generating a request to delete a bibliographic record (records) from the database. Used for the MARSType processing scheme.

RF26 Contains a service line for generating a request to delete a bibliographic record (records) from the database. Used for processing scheme F001Type.

RF27 Contains a service line for generating a request for

– – –

Setting up file processing To activate the procedure for processing bibliographic records into a specific database, you must perform the following sequence of actions:

3. If update or delete operations are planned, make sure that there is a request in the RFXX parameter corresponding to the loading scheme.

4. Create nested subdirectories, starting from the root directory, in accordance with the following sequence: database name, processing scheme (F001TYPE, F035TYPE, MARSTYPE, RKPTYPE), operation (INSERT,

UPDATE, DELETE), record format (RUSMARC,USMARC,UNIMARC), record encoding (DOS,KOI,WIN,UTF8). Example path:

X:\Root\USMARC_DEMO\MARSTYPE\INSERT\USMARC\DO S\test.mrc

5. Place files that require certain processing in the resulting directory. The file must have the mrc extension.

6. Make sure that the user under whom the Ruslan server is running (RUSLANServiceR6 service) has the right to read, write and delete files from the created directory.

7. Restart the RUSLANServiceR6 service.

If the path of the resulting directory does not contain a format type, it will be detected automatically ( precise definition format is not guaranteed).

If the operation is successful, the processed file is deleted for any processing scheme.

10 MB. For an INSERT operation, the volume is calculated as the sum of the volume of all files defined for this operation. For delete operations (DELETE) a multiplying factor of 9 is used, for updating operations (UPDATE) the multiplying factor is 10. The coefficients are correct for databases with a volume of up to 100,000 records. The 10 MB limit applies to the total volume for all three operations. Those. for 3 files of 300 KB in size, defined for all three operations, the “conditional” volume will be equal to 300 + 300*9 + 300*10 = 6 MB.

Thus, through this service, in one session you can download about 5-20 thousand records or change about 500 bibliographic records. The actual number may vary greatly depending on the performance of the computer used and the size of the database being operated on.

The automatic file processing service is time synchronized with other tasks initiated by the server itself. But for tasks initiated by means external to the Ruslan server, “manual” synchronization is required.

Diagnostics

Processing features for the F001Type circuit

The F001Type processing scheme is designed to process records received from a source that guarantees the uniqueness of the record identifier (record key) stored in field 001 of the MARC family formats. When an insert operation is performed, the record ID does not change. The change operation is based on searching for a record by its identifier (field 001).

The delete operation is not supported.

Processing Features for the F035Type Scheme The F035Type processing scheme is designed for processing records received from a source that does not guarantee the uniqueness of the record identifier (record key) stored in field 001 of the MARC family formats. When an insert operation is performed, the record identifier changes and the old value is stored in field 035. Delete and change operations are based on searching for a record by its old identifier (field 035). This scheme does not guarantee correct execution of record modification and deletion operations.

Processing features for the MARSType scheme

The MARSType processing scheme is intended for processing records received within the MARS project. The value of the record identifier (record key) stored in field 001 must be unique. Records are identified by blocks, by the value stored in field 910a and the file name.

When an insert operation is performed, the record ID does not change. Delete and change operations are based on a special attribute search based on field 910a. All operations are performed only on the block of records as a whole. An error when performing any operation on any record from a block causes a diagnostic message to be issued and file processing to stop (without deleting it).

Note. In earlier versions of the server, when an insert operation was performed, a new identifier was generated and the old identifier value was stored in field 035.

Processing features for the RKPType B scheme this moment The RKPType processing scheme is similar to the F001Type processing scheme. Change and delete operations are not used.

6.4. Configuring means for background processing of service records The Ruslan server supports the ability to automatically process records in service databases based on data files in the internal format of the Ruslan ABIS. Processing includes three operations: loading (inserting a new record), updating and deleting (for old records). The resulting update operation record is the sum of the following sets of tags:

“new” tags from the record in the file (which were not in the record from the database);

“old” tags from the record in the database (which were not in the record from the file);

“general” tags taken from a record in a file (the values of the tags in the file overwrite the values of the tags in the database).

The Ruslan server supports three automatic processing schemes.

R010Type, R100Type. The main difference in the schemes is the method of unique identification of a service record. To ensure the operation of this service, two server parameters are used:

LoadFilesDB Contains a list of service databases for processing.

LoadFilesPath Specifies the root directory from which subdirectories begin to contain files involved in processing operations. It is not recommended to use a directory connected over the network as the root directory - in the event of a network failure, the server may be blocked for the duration of the network timeout.

Setting up file processing

To activate the procedure for processing service records in a specific database, you must perform the following sequence of actions:

1. Add the name of the new database to the list of databases in the LoadFilesDB parameter.

2. Make sure the correct path is present in the LoadFilesPath parameter.

3. Create nested subdirectories, starting from the root directory, in accordance with the following sequence: database name, processing scheme (R001TYPE, R010TYPE, R100TYPE), operation (INSERT, UPDATE, DELETE), record format (RUSLAN), record encoding (DOS, KOI,WIN,UTF8). Example path:

X:\Root_directory\LUSR\R010TYPE\UPDATE\RUSLAN\DOS\users.dat

4. Place files that require certain processing in the resulting directory. The file must have a dat extension.

5. Make sure that the user under whom the Ruslan server is running (RUSLANServiceR6 service) has the right to read, write and delete files from the created directory.

6. Restart the RUSLANServiceR6 service.

If the resulting directory path does not contain an operation type, the INSERT operation will be performed (the default operation).

If the resulting directory path does not contain a format type, processing of the file will stop.

If the operation is successful, the processed file is deleted for any processing scheme.

Placing files in directories that indicate modification and deletion operations can lead to irreversible changes to the database. It is necessary to restrict access to such directories.

General restrictions on use

The file processing task is launched by the Ruslan server automatically during the time period from 00:00 to 04:00 in accordance with priority relative to other background tasks. The task is not guaranteed to complete by 04:00. The volume of work performed (and indirectly the operating time) is limited to a “conditional” 10 MB. For the operation of inserting records (INSERT), the volume is calculated as the sum of the volume of all files defined for this operation. For delete operations (DELETE) a multiplying factor of 9 is used, for updating operations (UPDATE) the multiplying factor is 10. The coefficients are correct for databases with a volume of up to 100,000 records. The 10 MB limit applies to the total volume for all three operations. Those. for 3 files of 300 kb each, defined for all three operations, the “conditional” volume will be 300 + 300*9 + 300*10 = 6 MB.

Thus, through this service, in one session you can download about 5-20 thousand records or change about 500-2000 bibliographic records. The actual number may vary greatly depending on the performance of the computer used and the size of the database being operated on.

If the processing of a file was canceled due to a limitation of the total volume of several files, then its processing will be launched in all subsequent sessions until it is successfully loaded (and deleted from the directory by the Ruslan server) or is explicitly deleted by the administrator from the processing directory.

The following points need to be monitored:

1. Control the time overlap with automatic archiving of the physical Oracle database.

2. Monitor the time overlap with batch change procedures launched from the Administrator's workstation.

3. Monitor the time overlap with the loading and indexing procedures launched from the Administrator's workstation.

Diagnostics

As a means of monitoring the results of operations, a mechanism common to the entire Ruslan server is used - the system event monitor (EventLog). The message code 120 is defined for the automatic file processing service. The meaning of the diagnostic message is explained in the text part.

Processing features for the R001Type circuit

The R001Type processing scheme is designed to process records received from a source that guarantees the uniqueness of the record identifier (record key in tag 1). When an insert operation is performed, the record ID does not change. Deletion and modification operations are based on searching for a record by its identifier (tag 1). The delete operation is not supported.

This scheme is focused on processing service records downloaded from the working version of the Ruslan server.

Processing features for the R010Type circuit

The R010Type processing scheme is designed to process records received from a source that does not guarantee the uniqueness of the record identifier (record key in tag 1), but guarantees the uniqueness of the external identifier, which must be placed in tag 10. When performing an insert operation, a new record identifier is generated (in tag 1) . Deletion and modification operations are based on searching for a record by an external identifier (tag 10). The delete operation is not supported.

This scheme is focused on processing service records downloaded from external systems (university automated control systems).

Processing features for the R100Type circuit

The R100Type processing circuit is designed to process service records about readers. The reader's unique identifier (tag 100) is used as the transaction identifier. When an insert operation is performed, a new record ID is generated (in tag 1). Delete and modify operations are based on searching for a record using the reader ID (tag 100). The delete operation is not supported.

This scheme is focused on processing service records downloaded from external systems and should be used if the R001TYPE and R010TYPE schemes cannot be used for some reason.

6.5. Setting up the export and import of data for a university automated control system In the Ruslan ABIS, you can implement two options for creating a reader description. The first option, which provides an individual description of the reader, is implemented in the Book Issue workstation. This mode is most suitable for libraries that do not have any automated reader registration system not associated with ABIS. The second option involves exporting data from an external reader accounting system, as well as periodic synchronization of data in ABIS and external system. This option is typical for most university libraries, where the university's automated control system, as a rule, contains most of the information necessary to describe the reader in the ABIS. Interaction

ABIS Ruslan and the university's automated control system can be represented as consisting of three independent processes:

initial import of data from the university’s automated control system into ABIS;

periodic updating of information in ABIS based on data received from the university’s automated control system;

periodic import of data from ABIS to the university’s automated control system.

Initial import of information about readers To import information about readers into ABIS "Ruslan", it is necessary to prepare a reader description file containing records in the internal format of ABIS "Ruslan". Physical structure format is given in Appendix 3. The set of tags used in service databases, including those containing descriptions of library readers, is given in the document “List of Tags for Book Lending Workstation”. A set of special (reserved) tags is given in Appendix 2.

If the university’s automated control system data contains a unique identifier for the reader’s description, then it can also be used as a unique identifier in the Ruslan ABIS, i.e. display it in tag 1. There are two requirements for the value of tag 1: the value must be a number (contain only digit symbols) and the value must be unique throughout the entire time the reader’s record is stored in the Ruslan IBS (information about a retired reader is posted in the archive database and is stored there until explicitly deleted by the ALIS administrator). If tag 1 is present in the output records, then when loading into the Administrator's workstation, you should not specify the “Generate record key” attribute. When using tag 1 to store the reader's identifier, the potential opportunities for integration of the university's automated control system and automated information system are maximum.

In this case, the ability to add readers bypassing the university’s automated control system (via the Book Issuing Workstation) should be limited to ensure the possibility of reverse export.

To store a unique external reader identifier, tag 10 is reserved. Using tag 10 instead of tag 1 is preferable if you intend to create descriptions of readers in the Book Issue workstation. When loading such records into the Administrator's workstation, you must specify the “Generate record key” attribute.

Of all the tags used to create a reader record, only tag 100, which contains the reader's barcode, is required.

There are three strategies for generating the tag value 100:

1. Using any external unique code that is assigned to the reader of the external library information system(for example, in the automated control system of a university). This method it is preferable if the organization already has technical access control tools based on magnetic cards, barcode cards, etc. With this solution, library computers must be equipped with appropriate devices for reading information from cards. In this embodiment, tag values 1, 10 and 100 can be equivalent.

2. Generating a unique code when creating a record about a reader of any kind external program. This method is suitable when option 1 is not applicable and the reader records obtained in this way are used for batch printing of library cards from the Book Issue workstation.

3. A common constant is set for all, which is guaranteed not to intersect with the values of tag 100 already available in the records about readers. The assignment of a unique value must be made the first time a reader visits the library. This method is suitable when options 1 and 2 are not suitable, or pre-made barcodes are used (in the form of stickers on “standard” library cards or in the form of non-personal plastic cards issued to readers).

To generate a file with data in the internal format of the ABIS "Ruslan", you can use a specialized converter that allows you to obtain the required format from the data placed in a text file with a tab character as a column separator. A file in this format can be obtained by saving data from MS Excel, specifying the file type “Text files (tab delimited) (*.txt)”. Instructions for using the converter can be obtained by running it without specifying parameters. When comparing columns of a text file and tags, it is necessary to take into account special processing for tags 101, 102, 103 (the reader’s last name, first name and patronymic, respectively). If in text file the first name and patronymic are in the same column as the last name and when converting it is indicated that this column corresponds to tag 101, then the converter will automatically separate the second and third words and place them in tags 102 (first name) and 103 (patronymic). The fourth and subsequent words in the column are ignored.

The data recording format of some tags (109, 112, 113, 114) must correspond to the data recording format in the list.ini file of the Book Issue Workstation. In particular, it should be noted that the “type” of the organization or its division should not be included in the name of the organization or division.

For example it should be:

@109,5,1,9=Faculty@112,5,1,22=Civil Engineering and not:

@109,5,1,9=Faculty@112,5,1,22=Civil Engineering Faculty and:

@109,5,1,9=Faculty@112,5,1,22=Technical cybernetics and not:

@112,5,1,33=Faculty of Technical Cybernetics Tag 115 is used to store the reader's password. The presence of a password is only necessary to provide the reader with the ability to generate and control an electronic order from the Reader's workstation. The presence or absence of a password for the reader does not affect his service in the Book Issue workstation.

Periodic updating of information in ABIS based on data coming from the university's automated control system. Periodic updating of information about the reader (primarily information about the reader's status) can be implemented using the service for processing service records from a file. This technology allows you to synchronize data in the university’s automated control system and the Ruslan automated information system with a frequency of up to once a day.

Depending on the method of generating a unique identifier for a reader record, it is necessary to select the most appropriate processing scheme.

When creating records to update information about readers, it is necessary to ensure that they do not contain tags that can be modified in the Ruslan IBS in the process of servicing the reader.

Periodic export of data from ABIS to the university’s automated control system

A number of universities face the task of exporting part of the data from the Ruslan ABIS to the university's automated control system. Such data includes any information that is updated in the library more often than in the university (information about address, passport data, etc.).

In IBS "Ruslan" you can use two methods to export service data:

1. Standard ability to download service data in the internal format of the ABIS "Ruslan". To ensure security during uploading, you should delete tag 115 by specifying it in the “Delete tags” field (see section 5.9).

2. Export individual tags of service records using the GetTagValueByTag, GetTagNocaseUniqueValue and GetTagUniqueValue functions of the batch data processing mechanism.

6.6. Setting up a server to support the process of automated book issuance The Ruslan-Lite server version is supplied configured and does not require additional settings. The Ruslan-Lite server version does not process the configuration parameters used in the corporate version of the server except for the CircADB and CircADBs parameters.

The corporate version of the Ruslan server is supplied minimally configured. In some cases, you may need to change the default settings or expand them.

Configuring the corporate version of the Ruslan server to support the book issuing process consists of the following steps:

1. For employees of library departments directly involved in the process of serving readers, it is required to add the right to insert, modify and delete records in the database of issued books (by default, a database named CIRC is created). This database must be specified in the CircDB server parameter. The CIRC database must be registered in the settings of the Book Issuing Workstation.

2. Set up the current database of the archive of issued books (by default, the ACIRC database is created). The database name must be specified in the CircADB server parameter.

Service records about books issued when they are returned by a reader are moved to this database. Additional access rights to the archive database of issued books are not required. It is recommended to periodically create a new archive database of issued books when the current archive database is filled to approximately 100,000-150,000 records or when a significant slowdown in the process of writing off a book from a reader is identified. All archive databases, including the current one, must be specified in the CircADBs server parameter.

3. Set up a virtual database for the archive of issued books (ALLACIRC), which at the first stage includes only the current archive database. As new archive databases are created, it is necessary to modify the description of the virtual database. The ALLACIRC database must be registered in the settings of the Book Issuing Workstation.

4. For employees of library departments directly involved in the process of serving readers, it is required to add the right to insert, modify and delete records in the reader database (by default, one database is created with the name LUSR). The need for several databases may arise if the library serves several groups of readers, the registration of which is carried out by different departments of the library.

The database data must be specified in the ReaderDBs server parameter. It is necessary to control that the databases specified in the ReaderDBs parameter are real (that is, they are visible in the list of databases displayed by the Administrator's workstation).

5. Set up a virtual database (ALLUSERS) containing descriptions of all readers. By default, only the LUSR database is included in the virtual database. When creating new reader databases, it is necessary to modify the description of the virtual database. The ALLUSERS database must be registered in the settings of the Book Delivery Workstation. In some cases, in some established Book Distribution workstations, a separate real reader base may be registered. In this case, readers described in other databases will not be available for service in these workstations.

6. Set up an archived database of reader descriptions (the ALUSR database is created by default). This database must be specified in the ReaderADB server parameter.

7. Configure the queue database (by default, the QUEUE database is created). This database must be specified in the QueueDB server parameter.

For a description of setting up the Book Issuing automated workstation to support the technological cycle of automated book issuing, see the documentation for the Book Issuing automated workstation.

The absence of electronic order dispatch settings and/or settings for collecting book issuance statistics does not affect the process of automated book issuance.

ATTENTION! It is not allowed to perform upload/download operations of bibliographic records (as well as carry out any other actions that may lead to a change in the internal or external identifier of a bibliographic record) that are referenced in the database of issued books (CIRC).

The Ruslan server does not allow deleting bibliographic records that are referenced in the database of issued books (CIRC) using the Acquisition/Cataloging Workstation, but deleting such records is possible in the Administrator Workstation. Deleting records in the CIRC database can be performed using the Administrator's workstation only if deleting it in the Book Issue workstation according to the standard scheme is impossible for some reason.

6.7. Setting up a server to support the process of control by the reader of books issued in hand. Control by the reader of books issued in hand is carried out through the Reader's workstation. For a description of the Reader's workstation settings to support this mode, see the documentation for the workstation.

Setting up the Ruslan server involves setting the correct value of the fine for the day of delay (in the PenaltyPerDay server parameter). The PenaltyCurrency server parameter must set the monetary unit in which the penalty is calculated (by default, “rubles”).

6.8. Setting up a server to support the process of collecting book issue statistics The Ruslan server performs preliminary processing of book issue data for every day. Statistics calculation starts in the time range 23:50-24:00. The result of preprocessing is placed in the CIRCSTAT database.

The calculation of statistical values is based on three main indicators:

issuing a document to the user (upon adding a record to the database specified in the CircDB parameter);

return of the document (upon the fact of adding a record to the database specified in the CircADB parameter);

attendance.

Attendance is considered as one continuous chain of operations of issuing or returning documents from one reader to one library employee.

Two additional one-dimensional distributions can also be constructed:

by the time of issuance/return of documents and by the content of the issued documents (areas of knowledge). The division of the distribution by content is similar to the division when calculating the GSF.

Each statistical indicator is calculated for objects of four classes. The first class (1) is the library as a whole (always one entry in the CIRCSTAT database per day). Objects of the second class (2) are funds (signs) from which the issue was issued per day. The third class (3) of objects is the point of issue (TV). The issue point means an abstract identifier installed on each instance of the Book Issue workstation (at each workstation where the Book Issue Workstation is installed). If you set the same TV identifier on several copies of the Book Issue workstation, then a summary accounting will be made for them. The fourth class of objects are library employees.

The Ruslan server allows you to construct one two-dimensional distribution as an extension of the one-dimensional distribution according to the content of documents.

The second dimension can be a set of values, which is specified through the STATAddDistr parameter (no more than 10 aggregated values) of one of the tags (the tag is specified through the STATAddDistrAttr parameter) of a record from the database of issued books. If the service record does not contain the required tag, the value specified in the STATAddDistrDefValue parameter is taken. The STATAddDistrLevel parameter limits the class of objects for which the two-dimensional distribution is calculated (the default value is 1; it is not recommended to set this parameter to a value greater than 2). In the server parameters, by default, for calculating a two-dimensional distribution, the second dimension is the reader category.

Setting up the Ruslan server to support the process of collecting book circulation statistics consists of the following steps:

1. Check the availability of the CIRCSTAT service database.

2. Set the server parameter STATClassDistrLevel to the most appropriate value for the library. The parameter value sets the minimum class for which additional distributions are built (the default value is 3, i.e. for all classes excluding library employees).

The Scientific and Technical Library of Tomsk Polytechnic University conducts
internship to work in the automated library and information system "Ruslan"
for specialists from other libraries. Internships are organized according to contracts.
The number of hours and the program are formed individually at the request of libraries.

Contact Information
Tomsk, st. Belinskogo 55,
Scientific and technical library of Tomsk Polytechnic University.
Simakovskaya Svetlana Gennadievna, head. innovation and methodological department of NTB TPU, tel. (8-3822) 55-80-42, e-mail: [email protected]
Chuprikova Natalya Trofimovna, chief librarian-technologist,
tel (8-3822) 56-37-48, e-mail: [email protected]

Sample program:

Topic 1. General introduction to the work of the library
Library tour. Mission, policy, structure of NTB. Organizational and regulatory documentation, QMS documentation, Comprehensive NTB development program. Library participation in projects.

Topic 2. Organizational and technological aspects of library automation
Implementation of ALIS in NTB TPU. Library program. Objectives and principles of technological work. Necessary conditions and stages of implementation of ALIS. Development of local area network (LAN). Development of technological documentation. Technological management and control. Training.

Topic 3. Automated library and information system (ALIS) “Ruslan”
Compound, a brief description of and purpose of the system. General principles of organizing ABIS. Main components: Server "Ruslan", DBMS, Administrator's workstation, Acquisition/Cataloging workstation, Book Issue workstation, ORAS, Reader's workstation, MBA's workstation.

Main functions of the Ruslan server. Basic operations of searching, retrieving, inserting, deleting, changing and others. Support for bibliographic and authoritative databases (MARC), specialized databases (Explain, Extended), service databases (reference books, readers, acts, CSU). Control access to the database by user categories. Support for multilingual data (UNICODE).

Main functions of the Administrator's workstation. Managing the server and database access rights. Establishment and support of the database. Indexing records and batch editing. Restoring a deleted or changed entry in a bibliographic database. Backup DB. Rollback to previous versions of entries. Alert to ABIS users. Loading/unloading records from a file. Work statistics, history of work of any user with ABIS. Security management.

Topic 4. RUSMARC
Presentation and updating of formats on the website of the National Service for the Development of the RUSMARC Format System at http://www.rba.ru:8101/rusmarc/

Russian communicative format for presenting bibliographic records. Basic concepts. Standards and regulations. Purpose and structure of the format. Composition of the recording. Marker. Blocks of information. Composition of fields, subfields. Communication fields. Methodological recommendations for describing certain types of documents in the RUSMARC format.

Russian communicative format for presenting authoritative/normative records. Definitions. Principles of construction and purpose of the format. Records format: authority/normative, reference and reference. Functional blocks. Link tracing.
Topic 5. The main functions of the Acquisition/Cataloging workstation in the acquisition department
Ordering documents using electronic price lists and thematic plans publishing houses Formation of an order in ABIS "Ruslan". Generating a copy of the order and sending it to the publishing house by e-mail or fax.

Borrowing records from the RKP and RNL databases. Inventory number generator. Creating records using templates. Checking for duplication. Posting invoices and write-offs. Output forms in MS Excel format: Automated Book of Summary Accounting (KSU); Inventory book. Formation of reporting documents for the accounting department (acts, reports, etc.). Distribution of documents according to storage codes. Transfer of documents for vouchers.

Topic 6. Formation of an electronic catalog of periodicals
Subscription of periodicals and information publications in IBS "Ruslan". Output forms in MS Excel format: Copy of subscription application, delivery cards. Accounting and registration of new arrivals of periodicals. Maintaining the electronic catalog “Periodicals”. Multi-level cataloging of periodicals.

Topic 7. Book availability in the educational process
Book Supply Program. Formation of directories. Entering information about the educational process of the university. Working with lists of recommended literature for disciplines. Importing information from ORAS ABIS "Ruslan". Generating book availability reports.

Topic 8. Main functions of the Acquisition/Cataloging workstation in the cataloging department
Systematization. Classification schemes in NTB: Universal Decimal Classification (UDC), Library and Bibliographic Classification (LBC), All-Russian classifier specialties of the highest scientific qualification (oksvnk). Subjectification (keyword definition). Directory of keywords.

Bibliographic description of documents in electronic catalog with full support for the RUSMARC format (link fields, link tracing, authority files). Setting up the record format (fields, subfields, lists, sets of values, directories, etc.). Enter various types records according to corporate templates and instructions. Contextual help on the RUSMARC record format. Maintaining directories and authority files. UNICODE support using built-in virtual keyboard. Closing accounts and transferring documents to fundholders.

Document retro-entry technology. Borrowing records from external sources.

Topic 9. Creating a Newsletter of New Arrivals
Purpose and structure of the newsletter. Technology of formation in the Acquisition / Cataloging workstation. The process of editing bibliographic descriptions. Preparing a newsletter for posting on a WWW server in the New Arrivals section.

Topic 10. Analytical painting
Analytical description of articles from periodicals. Description template “Periodical-analytics”. Communication fields. Definition of keywords.

Analytical description of articles from books, proceedings and conference materials. Description template “Analytics from the book.” Communication fields. Definition of keywords.

Topic 11. Formation of the TPU Electronic Library
Tasks and functions. Technologies for collection, storage, technical processing electronic versions publications of TPU employees, digitization of paper media, their presentation in the NTB electronic catalog. Methodology for describing an electronic resource. Description templates for an electronic resource: dissertation abstract, dissertation, floppy disk, CD-ROM, remote resource.

Topic 12. Main functions of the Reader's workstation
Search modes: Search, Search and order, Order execution control. User identification. User guide. Methodology for composing search queries. Simple and advanced search. Information about the location and availability of free copies of documents.

Technology of consulting work using an electronic catalogue.
Methodology for training users to work in the electronic catalogue.

Topic 13. Main functions of the Book Issuing Workstation
Registration/re-registration of users. Electronic user form. Laminated library card. Statistics on a single library card.

Reception/issuance and accounting of issued documents using barcoding technology for library cards and documents. Maintaining electronic queues on the issued document. Working with debtors. Information about issued documents, current orders, users according to various search criteria.
Technology of work at the subscription and in the reading room. Attribution of barcodes of documents from the Book Issuing Workstation. Technology of execution and completion of orders in book storage and subscription. Work statistics.

Topic 14. Main functions of the automated automated banking system (IBA)
Search for bibliographic information in the electronic catalogue. Ordering IBA services: a document for temporary use, a copy of the document, a certificate of location, a certificate of the cost of delivery of the document. Cancellations. Notifications: about sending a document to the subscriber, about the timing of the order, and others. Refusal of service indicating the reason. Incoming and outgoing orders.

Use of Z39.50 and ISO ILL protocols.

Topic 15. Round table (for specialists from other libraries)
Summing up the results of the internship. Answers on questions. Setting tasks for the implementation of ALIS. Recommendations for further work.

Ministry of Education of the Russian Federation

Barnaul State Pedagogical University

________________________________________________________________

I approve

Rector of BSPU

________________

"___"_______________ 2004

Technological instructions for creation analytical description articles from the collection in the ABIS "Ruslan" in the reference and bibliographic department of the Scientific Library of the BSPU

Vice-Rector for Innovation and Information Technologies

__________

"____"__________ 2004

Director of the National Library

________

"____"____________ 2004

2004

The goal of the work is to create machine-readable bibliographic records in the RUSMARC format for analytical-level documents. The work is carried out using the workstation of the completer-cataloger in the Ruslan program.

Descriptions of documents are created in the acquisition department and finalized in the cataloging department, so when creating a record for an article, a number of fields are already filled in, for some fields the values are set by default or automatically.

The bibliographer’s task is to supplement necessary elements description of this document by filling in the missing fields.

When filling out fields and subfields, remember:

Punctuation marks are not placed at the end of fields and subfields;

Analytical processing of the document:

The articles are being systematized according to the BBK (Library and Bibliographic Classification) tables.

Determined keywords according to " Methodological recommendations on coordinate indexing".

Creating a new bibliographic record:

Select name the desired template entries from the main window menu “Record - Create a new bibliography” - “Analytics from a book” or use the button "B".

The fields (subfields) of the template are pre-configured.

Check that the parameters are filled in correctly Marker.

The record marker (index) is located at the beginning of each record of the Russian Communication Format. Contains data necessary when processing a record.

6 Record type (a) – text materials, printed – is set by default.

7 Bibliographic level (a) – analytical.

8 Hierarchical level code (2) .

17 Coding level (#) – full level – select from the list.

1. Block of encoded information.

The block contains fixed-length encoded data elements.

The data in these fields is determined by the relative position of the character, considering the first character following the subfield identifier to be null. If this field is not required and the bibliographic agency does not provide the corresponding coded information, the field is not provided. If non-required data is not used, its field positions contain " | " placeholder characters.

100 General processing data.

The field contains fixed-length encoded data applicable to document records presented in any media .

0-7 The date the entry was entered into the file is set automatically.

8 Publication date type - monograph.

9-12 Date of publication1 -<>- year of publication of the document.

13-16 Publication date 2 -<>

17-19 Purpose code - for adults, scientific - set by default.

<у>-non-governmental publication – set by default.

21 Modified entry code<0>.

22-24 Cataloging language “rus” – set by default.

34-35 Title graphics (alphabet) “rus” - default.

101 Document language.

The field contains encoded information about the language of the cataloged document, its parts and title, and also indicates the original language if the document is a translation. Mandatory

And 1 Translation indicator 0 - document in original language - default.

$a - text language “rus” - default.

Repeats when text is written in more than one language.

If the document is a translation, you should establish:

And 1 Translation indicator 1 - the document is a translation of the original.

$a - text language “rus”;

$c - original language - select from the list.

102 Country of publication or production.

The field contains codes for one or more countries of publication or production of the document.

$a - country of publication “RU” - default.

2 Block of descriptive information.

200 Title and statement of responsibility. Mandatory. Doesn't repeat.

The field corresponds to the area of the title proper of GOST 7.1-84. The field contains, in the form and sequence determined by the Rules: Title proper, Parallel titles, Information related to the title, Information about responsibility.

And 1 Title as access point<1>is an access point. Default.

$a Title proper – the title of the article.

$e Title information - title continued. Repeated.

$f First information about responsibility - Full name - copied automatically from fields 700, 701 when adding this subfield. Filled in at the end of record creation. Doesn't repeat.

$g Subsequent Responsibility Information - Automatically copied from fields 702. Completed at the end of record creation. Repeated.

3 Note block.

320 Notes about the presence of a bibliography/index in the document.

The field contains notes about the reference apparatus (bibliographies, auxiliary indexes, etc.) available in the document. Optional. Repeated.

4 Record communication block.

Each link field must contain data fields with embedded labels, indicators, and subfield identifiers that identify the document to be linked to. The field must contain sufficient data to identify the record (if one exists) of the cataloged document to which the link is to be made, or, if there is no record, to identify the document itself.

Record linking technique:

Select the generated connection field in the record navigator (with one click of the left mouse button). Go to "Tab" to the "Post" page of the post editor. In the upper right window, select the source directory with which the connection is established - “Main directory”. Enter a search characteristic (collection name). Features available here simple search with value truncated on the left and right (use the * symbol). Click on the picture of binoculars. The linked entry can also be retrieved from the catalog using the Catalog Search window. After executing the query, view the retrieved records. You can use the window at the bottom of the list to view the full entry. Select the line with the desired record and double-click the left mouse button (or click the “Link Records” button). A built-in record for the document with which the link is being established will appear in the record navigator.

The following field applies:

463 Physical unit level.

The field is used to identify a hierarchical relationship with a document at the level of a physically separate unit. The record being linked to is at the physical unit level, and the record containing this field is at the analytical, set, or subset levels.

And 2 Note indicator<1>.

After linking the record with the document, field 200 - Title and information about responsibility and subfields $a, $b, Se are filled in automatically. Here we add a subfield $v “Volume designation”, where we ourselves put the pages of the article. The period at the end is required.

The field is automatically filled in -

210 Publication, distribution, etc.:

$a Place of publication, distribution, etc. -<М.>.

$c Name of publisher, distributor, etc. -<Либерия>.

$d Date of document, distribution, etc. -<>- year of publication of the document.

6 Topic definition block.

The block contains thematic data, both textual and presented in coded form, compiled according to the rules various systems subjectification and systematization.

The value of fields 600-608 can be selected from authoritative/normative files.

Add the required field if it is not in the document template. Select the line with the field name (with one click of the left mouse button). In the upper right “Value” window, select the rubricator in which the authoritative record with which the connection is being established is located. Enter a search feature. Click the “Run Query” button or the picture of binoculars. After executing the query, view the found records. Select the line with the desired record and double-click the left mouse button (or click the “Link Records” button). On the left side of the screen, an embedded authority record will appear in a highlighted field that you want to link to.

To do this, you need to select the required field in the record navigator, use the “Tab” key or the mouse cursor to go to the “Value” page, in the value editor of the current record, use the keyboard to enter the necessary information, which, when you press the “Enter” key, is transferred to the field.

600 Person's name as a subject heading (person). Optional. Repeated.

The field contains, in the form of an access point, the name of the person who is one of the objects of consideration in the document. Optionally, additional thematic formal, chronological and geographical information may be added to the person's name.

And 2 Method of entering a person's name<1>- default.

$bThe part of the name other than the initial input element is the author's initials.

610 Uncontrolled subject terms (keywords). Optional. Repeated.

The field contains subject terms in the form of an access point that are not borrowed from controlled lists of subject headings

AND 1 Level of significance of the topic term<1>- default.

$a Subject term. If there is a built-in reference book, we take the term from the reference book. A directory represents a list of values. Selecting a value from the list is done by pressing the “Enter” key or double-clicking the mouse. The “Directory” page has its own button panel with operations for adding new, editing and deleting directory elements.

The field contains indexes of classification systems that are not used internationally, but have widely available printed tables.

LBC indices, separated by a "+" sign, are recorded in separate repetitions of field 686.

$a Classification index - taken from a reference book or typed in from the keyboard.

$2 System code "rubbk" - set by default.

7 Intellectual responsibility block.

The block contains the names of persons and names of organizations bearing intellectual responsibility for the creation of the document. Intellectual responsibility extends to all personal and generic names and organizations associated with the document, including publishers if they require the creation of an access point

700 Name of person – primary intellectual responsibility (author).

The field contains, in hotspot form, the name of the person having primary intellectual responsibility (the first or only person in the title containing the name of the individual author). Mandatory if an access point is to be created in the name of the person with primary intellectual responsibility.

This field cannot be present in the same record where there is a 710 organization name - primary intellectual responsibility or 720 - generic name - primary intellectual responsibility field, since the record can only have one access point with primary intellectual responsibility.

And 2 - under<1>.

701 Name of person - alternative intellectual responsibility (2 and subsequent authors).

The field contains, on the access point form, the name of the person who has the alternative intellectual responsibility. If a bibliographic record is to be displayed under the heading of an individual author, then alternative intellectual responsibility lies with the co-authors of the cataloged document, used as access points. If a bibliographic record is to be displayed under a title, then alternative intellectual responsibility lies with all individual authors of the cataloged document, used as access points. (If a bibliographic record should be displayed under the title of a collective author, then the individual author can only bear secondary intellectual responsibility - field 702).

Mandatory if an access point is to be created in the name of a person bearing alternative intellectual responsibility. Repeated for each person with alternative intellectual responsibility.

<1>.

$b Part of the name, except for the initial element, is the initials of the author.

After processing, the record is saved in the directory by left-clicking on the “Save record” icon in the right top menu, open the “Main catalog” and copy the entry..jpg" width="179" height="112 src=">, by clicking on the "Print" icon, print the required number of cards. If necessary, edit the card manually. To switch to editing mode you need to left-click where you edit the card and a flickering cursor should appear in the card field. Further actions editing is no different from working with any text editor.

Copying a record.

The entry can be copied to the editor window (button https://pandia.ru/text/78/403/images/image006_20.jpg" width="19" height="25 src="> or the "Delete entry" menu item. This will display a window confirming the user's desire to delete the entry.

Editing a record.

After connecting to the main server of the NPB BSPU, click the button “Select an entry from the directory” Select the line “Main directory” (double-click the left mouse button). Enter the search feature of the publication (author or title). Click the “Run Query” button or the binoculars picture. After executing the query, view the found records, highlighting the desired line by clicking the left mouse button. For a detailed view, press the “View record” button or double-click on the line with the left mouse button. To return to the “Catalog Search” window, click the “Request” button. If the found entry fully matches the described document, click the “Edit entry” button0 " style="margin-left:-39.6pt;border-collapse:collapse;border:none">

Current edition 01/16/2004

Compiled by: , head. SBO NPB BSPU

Approved at a meeting of the Methodological Council of the NPB BSPU

Chairman of the Methodological Council

RUSLANA (Ruslana database) contains comprehensive information about companies in Russia, Ukraine and Kazakhstan. You can use it to analyze a specific company, as well as search and analyze companies with a specific profile. RUSLANA is presented with software new generation from BvD - simple and easy to use.

Benefit for you

What information does RUSLANA contain?

Financial indicators of the company, detailed format, data for 10 recent years
Leaders and contacts
Activity code and trade description
Stock data for public companies
Detailed corporate structure, search for companies with the same owner
Shareholders and subsidiaries
Business news about the company
M&A transactions and rumors about them

Ruslana is an ideal solution for transfer pricing specialists, marketers, sales and marketing specialists, M&A, credit risk and compliance professionals.

Using the Ruslana product, you will find the necessary information about the company you are looking for and will be able to evaluate the given company.

Search by more than 100 criteria - You can create searches in several steps, compare data over the past years. The product interface allows you to combine a large number of search criteria and use Boolean search (and, or, and not). After selecting a group of companies, you can compare them with each other, create graphs and tables
Thanks to the flexible product interface, you can use Ruslana for a variety of research projects, including: detailed financial analysis and credit risk assessment, corporate finance, venture capital and M&A research, to study the effectiveness of sales and marketing, conduct feasibility assessments, collect data for various campaigns, for academic purposes
You can create your own indicators, calculate the average value for the sector, change the report format and customize data structure, make comparisons and assessments, export data(Excel, Access...)
The Addin function allows you to analyze data from Ruslana in Excel/Access, so you can compare your own data with data from our database (they are updated daily), thereby expanding your own database
You can also conduct transfer pricing analysis
credit risk analysis department
department of corporate finance, M&A and consulting companies
marketing department
educational and scientific institutions