RU66567U1 - SYSTEM OF SUPPORT OF NON-REGULAR REQUESTS FOR THE AUTOMATED MANAGEMENT SYSTEM - Google Patents

Abstract

The utility model relates to computer technology, namely, to the means of collecting and processing data designed to manage the budget process at the regional level.

The essence of the utility model: The system for providing non-regulatory queries to a database, including a block for input, registration, approval, processing and compilation of information of remote users and a block for input, registration and storage of objects and information of a central database, is additionally equipped with a block for input, registration and storage of meta-information and a unit for the interaction of the meta-information database and the database connected to each of the above blocks with two-way communication, as well as a unit for optimizing the execution of ad hoc requests, input for which it is connected to the unit for interacting with the meta-information database and the database, the data filtering unit, the unit for the submission of information for ad hoc requests, the unit for uploading the results of ad hoc requests, and the unit for parametric calling of the input form, which are connected in a certain way.

Technical result: Improving the efficiency and reliability of the automated budget process management system at the regional (municipal) level, as well as expanding its functional capabilities due to the presence of interconnected blocks and modules in the system that ensure the implementation and optimization of the process of performing unregular requests to the budget process database.

Description

The utility model relates to computer technology, namely, data collection and processing tools designed to manage the budget process at the regional level (the level of the subject of the Russian Federation and the municipality), and can be used, in particular, in the implementation of budget planning processes (including medium-term ), financing, accounting, reporting, including the treasury method of budget execution, for the level of the financial authority, the main managers of budget funds and budgetary institutions.

One of the tasks of the budget process management system at the regional (municipal) level, which is an information system of the OLTP (OnLine Transaction Processing) class with a complex information base structure, large database volumes and a large number of both local and geographically remote users, is the need to organize unregulated requests generated directly by users to database information. This necessitates the development of an original mechanism for the dynamic generation of queries to the database of an automated control system, in the context of a continuously ongoing increase in the functional complexes of the system, an increase in the number of users and an increase in their information needs.

Known Automated system for providing information on debts and payments of consumers of services according to the patent of the Russian Federation No. 2256215, G 06 F 17/60, publ. July 10, 2005, chosen as the closest analogue for its functional purpose, which consists in creating and storing a central information database on a database server, generating and transmitting requests from users to this database, and processing them using the appropriate system units and presentation in one form or another (in electronic or paper) of the results (responses to inquiries).

In this automated system, each of the terminals installed at payment acceptance points from service consumers and service providers through a network

the data transmission is connected to a unit for storing and processing information about debts and payments of consumers of services, which includes the first means of communication with the terminals installed at payment points, the second means of communication with the terminals installed at service providers, and a database server containing a registration unit participants of the system, a data storage unit, an account management unit and a payment document generation unit, the interfaces of which are connected to the first communication medium, and also comprising a generating unit based on their registries, a processing unit for incoming registries and a payment document generation unit, the participant registration unit is connected by a bi-directional information connection to a data storage unit connected by a bi-directional information connection to an account management unit, one output of which is connected to an input of a payment document generation unit, and the other output is connected to the input of the block forming the outgoing registers, and the input is connected to the output of the processing unit of the incoming registers, the input of which is connected to the output of the storage unit p sisters connected by the input to the output of the block for generating outgoing registries, while the interface of the register storage unit is connected to the second means of communication.

The known device allows for the entire exchange of information, including the formation of requests and receiving answers, via electronic communication channels, which greatly facilitates the process of making payments for subscribers. In addition, the speed of obtaining information on debts and payments by service providers is increased, the possibility of operational control over the process of passing funds from making payments to subscribers to crediting to a current account and the possibility of increasing (scaling) the system are provided.

However, at the same time, the known system does not allow using it for purposes other than accounting for debts and payments of consumers of public utilities, as it is characterized by limited functionality and speed, high time and material costs for collecting, processing and providing information, low reliability system, which ultimately leads to a decrease in the overall system performance. These shortcomings are due to the fact that in the known system it is impossible to quickly generate arbitrary user requests to the database for arbitrary parameters, but only for a specific list of them; presentation forms selected

at the request of the data are strictly regulated and their number is limited; the possibility of the operational formation of analytical reporting, etc. is not provided.

The claimed utility model solves the problem of creating a highly efficient and reliable automated budget process management system at the regional (municipal) level, as well as expanding its functionality due to the presence of interconnected blocks and modules in the system that ensure the implementation and optimization of the process of performing unregulated queries to the budget process database .

At the same time, unregulated requests within the framework of the present invention are understood to mean structures (using setting mechanisms) randomly generated by the user during operation and sets (using filter mechanisms) of the requested data, in contrast to regular requests, i.e. user-defined structures and forms for presenting requested data. Forms for presenting the results of non-ad hoc queries may vary (views, reports, uploaded files, supported by Windows).

In addition, the system should provide users with a mechanism for generating derived values on filtered aggregates of grouped data.

The stated task is ensured by the fact that the system for providing non-regulatory queries to the database, including a block for input, registration, approval, processing and compilation of information of remote users and a block for input, registration and storage of objects and information of a central database, the functions of each of which are similar to the functions of the input terminal, data transmission network and information storage and processing unit in the prototype, is additionally equipped with an input, registration and storage unit of meta-information and an interaction unit vii meta-information base and database, connected to each of the above blocks by two-way communication, as well as an optimization block for the execution of ad hoc requests, the input of which is connected to the interaction unit of the meta-information database and the database, a data filtering unit, an ad-hoc information presentation unit, an output unloading unit ad-hoc queries and the unit of parametric call of the input form, and the first output of the ad-hoc execution optimization unit is connected to the filtering unit for data, and its second output is connected to each of the inputs of the block for the submission of information of ad hoc queries, the block of filtering data and the block for the presentation of information of ad hoc requests

two-way communication with the meta-information base interaction unit, the output of the data filtering unit is connected to the second input of the ad-hoc information presentation unit, the second output of which, in turn, is connected to the input of the ad-hoc query output unit, and its third output is connected by two-way communication with the parametric call unit input forms.

In addition, the block of input, registration and storage of meta-information includes a block of request identifiers, a block of table identifiers and a block of identifiers of table aliases, a block of identifiers of global selection conditions and a block for generating a subscheme of the request, the outputs of which are connected simultaneously to the inputs of the block of request identifiers and a block of table identifiers; a query field identifier block and a field link table identifier block connected by a two-way communication, the outputs of the latter being connected to the corresponding inputs of the query identifier block and the table identifier block; a block of identifiers of viewing forms, a block of identifiers of fields of forms, and a block of identifiers of fields of filters, sequentially connected by a two-way communication, the output of a block of identifiers of fields of forms being connected to the input of a block of identifiers of request.

In addition, the unit for input, registration and storage of objects and information of the central database is made in the form of a unit for storing objects and information, including a control module and a data storage module connected by two-way communication, which also contains a central and local database connected to the output of the input and registration unit objects and information, including a sequentially connected module for registering objects and information, an object and information input module, a data receiving module and a control module.

In addition, the interaction block of the meta-information database and the database is made in the form of a database information storage unit connected by two-way communication with the metabase information storage unit, including a metadata input module and a meta-information database.

In addition, the unit for optimizing the execution of non-regulatory requests is made in the form of a block for returning the number of records, including a query execution module and a record return module connected in series, and a result output unit connected to its output, including a query execution module and a record return module connected in series.

In addition, the data filtering unit is made in the form of series-connected unit for forming ranges of values, a unit for constructing lists, a unit for switches, and a unit for dynamically changing a request.

In addition, the block for the submission of information of non-regulatory requests is made in the form of a filtering and grouping unit, to the output of which an aggregation unit is connected, including a series-connected table module, a report module and a sorting module.

In addition, the unit for input, registration, approval, processing and compilation of information of remote users is made in the form of a series-connected by two-way communication unit for collecting and issuing information, including a series-connected registration module, data input module, data receiving module and control module, local version description block a base, a transaction execution unit, and a storage and information storage unit including a storage module and a control module.

In addition, the block for unloading the results of non-regulatory requests is made in the form of a reporting unit, to the output of which an export unit is connected.

The essence of the utility model is that due to the use of meta-information in the system by introducing a block of input, registration and storage of meta-information connected to the system through the interaction block of the meta-information database and the database, the quality and reliability of the system’s work significantly increases, and due to the presence of such interconnected blocks, such as a block for optimizing the execution of ad hoc requests, a data filtering unit, a unit for presenting information for ad hoc requests, and an unloading unit for results eglamentnyh queries, the system ensures the implementation and optimization of the process of implementation nereglamentnyh database queries, which greatly enhances its functionality, in particular in comparison with the prototype. The latter advantage is also provided by the presence in the system of such interconnected blocks as a data filtering unit, a unit for presenting information of irregular requests, and a unit for parametric calling of the information input form, which enable users of the system to obtain a mechanism for generating derived values from the obtained sets of grouped data.

The utility model is illustrated by drawings, in which Fig. 1 shows a general block diagram of a system of ad hoc queries, Fig. 2 shows an example of a specific implementation of a block for input, registration and storage of meta-information, Fig. 3 is an example

Fig. 4 is an example of a specific implementation of a block of input, registration, approval, processing and arching of information of remote users, Fig. 5 is an example of a specific implementation of a block of interaction between a meta-information base and database, Fig.6 is an example of a specific implementation of the unit for optimizing the execution of ad hoc queries, Fig.7 is an example of a specific implementation of the data filtering unit, Fig.8 shows an example of a specific implementation of bl ka presentation nereglamentnyh requests 9 - example of embodiment of the discharge unit results nereglamentnyh requests to external systems.

The system for ensuring non-regulatory queries to the database contains a unit 1 for input, registration and storage of meta-information, a unit 2 for input, registration and storage of objects and information of the central database, and a unit 3 for input, registration, approval, processing and compilation of information of remote users, each of which is connected two-way communication with block 4 of interaction between the meta-information database and the database. Each of the blocks 1, 2 and 3 performs the function of the information input of the system.

To the output of block 4 of interaction between the meta-information base and the database is connected a block 5 for optimizing the execution of non-regulatory requests, the output of which, in turn, is connected to the first input of the block 6 for filtering data, the first output of which is connected to the input of the block 7 for representing information of non-regulatory requests, and the second input and the output of block 6 is connected by two-way communication with block 4 of interaction between the meta-information base and the database. The second output of the unit for optimizing the execution of non-regulatory requests is connected to another input of the unit 7 for representing information of non-regulatory requests, which is also connected by two-way communication with the unit 4 for interaction between the meta-information database and the database.

In addition, to the output of block 7 is connected a block 8 for unloading the results of pending requests that performs the function of an output terminal, and a block 9 for parametric invocation of an input form associated with block 7 for two-way communication.

All blocks of the claimed system in the above example of its implementation are implemented using software and hardware on standard personal computers, including those operating in server mode. In particular, the input, output and transmission of data between elements of the computer equipment of the system are carried out, as a rule, using well-known terminal devices (for example, keyboards, scanners, printers, etc.) and communication channels (for example, wired and wireless lines) , and registration, accumulation, exchange,

storage and various processing of information arrays obtained by the system is performed using software tools, i.e. in a certain way of organized space (cells) of memory of operational (RAM) and permanent (ROM) computer storage devices, due to the allocation in this space of areas (sections) responsible for certain computing operations. In this case, more often than not, a device that implements a specific operation and allocated in a separate block on the general block diagram of the device (see Fig. 1) is provided with memory and hardware parts of not one but several computers of the system, and vice versa, on one computer, for example working in server mode, several functional blocks of the information system can be concentrated.

Specific examples of the execution of individual blocks of the system are given below. Block 1 of input, registration and storage of meta-information (Figure 2) contains a block 1.1 of query identifiers, block 1.2 of table identifiers and block 1.3 of identifiers of table aliases sequentially connected by two-way communication, as well as block 1.4 of identifiers of global selection conditions and block 1.5 of generating a request subcircuit, whose outputs are connected simultaneously to the inputs of block 1.1 of query identifiers and block 1.2 of table identifiers. Block 1 also contains a block 1.6 identifiers of query fields and a block 1.7 of identifiers for linking fields with tables interconnected by two-way communication, and the outputs of block 1.7 are connected to the corresponding inputs of block 1.1 of query identifiers and block 1.2 of table identifiers, and series 1.8 of identifiers in series viewing forms, block 1.9 identifiers of form fields, block 1.10 identifiers of filter fields, and the output of block 1.9 identifiers of form fields is connected to the input of block 1.1 identifiers request.

The operation of block 1 is implemented as follows. In block 1, meta-information is entered from the input terminal, which is understood as information about the properties of the document (site page) used by the search system when indexing this document. For this, the initial meta-information is loaded into the meta-information database. When entering, the information entered is registered in the corresponding metabase objects. In each of the device blocks, data is received, where all the details of the input fields of the meta-information database are filled in. After that, through block 4 of interaction between the meta-information database and the database, the process of generating representations of the database information is carried out, for example, for the automated information system of the budget process (AISBP), in accordance with the user query structures described in the meta-information database for the class of viewing forms.

Meta-information in the devices of this block is stored in the form of the following set of relations:

In block 1.1 of request identifiers, identifiers, names and global conditions for query selection are stored. The global selection condition may contain selection conditions, for example, the selection of documents by a group of users. In block 1.2, table identifiers are stored identifiers and table names (for example, a list of tables available to users for data sampling). In block 1.3 identifiers of table aliases are stored identifiers of aliases, identifiers of tables and names of aliases of names used in queries. The presence of such identifiers is necessary due to the fact that the same table can participate several times in the same query. The table identifier is usually an alias identifier. In block 1.4 of the identifiers of the global selection conditions, the Request identifier, Table identifier, Table number in the query selection condition are stored. This device is necessary due to the fact that the table names in the global selection conditions are set parametrically. In block 1.5 of the formation of the subcircuit of the request, the Request ID, Table ID, a number of links are stored. This description allows, if necessary, to carry out manual query optimization. In block 1.6 of the request field identifiers, a description of domains and types of default field formatting is stored. As field parameters, the block contains the Field identifier, Field name, Field description, Field data (the expression used in queries with a parametric reference to the table), Field type, Field size, Number of output characters, Output format, Number of decimal places, Text alignment. In block 1.7 of the identifiers for linking fields with tables, a list of query fields is stored, namely: Request identifier, Field identifier, Grouping field identifier, Sign of permission to apply a filter by field. In block 1.8 identifiers of viewing forms, a list of viewing forms is stored. The block contains the Form identifier, Form name, Report title, Request identifier, Output of additional information to the status bar in the form, Display of the filter name in the report header, Correction form name as parameters of the forms. In block 1.9 of the form field identifiers, the Form identifier, Request identifier, Field identifier, Status line field identifier, Field position in the form, Field position in the form by default, Field signature (column heading) are stored. The output of the field in the form. Output of totals by field (total for the report). The field is passed as a parameter. In block 1.10, filter field identifiers are stored Filter identifier, Request identifier, Field identifier, Initial range value, End range value.

Data from block 1 is input to block 4 of the interaction of the meta-information database and the database. All actions related to changing the data of the meta-information database and descriptions of the meta-information database are performed in this block 1 in accordance with the rights of the registered user. Procedures leading to a change in the meta-information base are received at the input of each of the devices of the base of the block.

Block 2 input, registration and storage of objects and information of the central database (Figure 3) contains a block 2.1 of the storage of objects and information of the database and block 2.2 input and registration of objects and information of the database.

Unit 2.1 for storing objects and information includes a control module 2.1.1 and data storage unit 2.1.2 connected by a two-way communication, also containing directly the central 2.1.3 and local 2.1.4 of the AISBP database, and is connected to the output of unit 2.2 for input and registration of objects and information, which, in turn, includes sequentially connected module 2.2.1 for registering objects and information, module 2.2.2 for inputting objects and information, module 2.2.3 for receiving data and module 2.2.4 for monitoring.

In block 2, through block 2.2 for input and registration of objects and database information, information is entered on functional complexes of users of the central database, for which initial data from paper media through module 2.2.1 for registering objects and database information and module 2.2.2 for entering objects and information Databases are uploaded to the central database 2.1.3. When entering, the user is registered through the registration device. Data is transmitted through the module 2.2.3 receiving data, where all the details of the input fields are filled in, to the module 2.2.4 control, where the control is carried out on the completeness and correctness of filling in the input forms.

Block 3 of input, registration, approval, processing and arching of information of remote users (Figure 3) is made in the form of sequentially connected by two-way communication block 3.1 of collecting and issuing information, block 3.2 description of versions of the local database, block 3.3 transaction and block 3.4 storage and arch information, including the control module 3.4.1 and the module 3.4.2 of storage and data archiving, managed with the help of a server or file-server DBMS. At the same time, the unit 3.1 for collecting and issuing information includes sequentially connected registration module 3.1.1, data input module 3.1.2, data receiving module 3.1.3 and control module 3.1.4.

In block 3, through block 3.1 of information collection and delivery, information is entered on the functional complexes of remote workstation AWSs. To do this, the source data from paper media through module 3.1.2 data entry is loaded into

local database (LBD) (shown in figure 3). When entering, the user is registered through the registration module 3.1.1. Data is transmitted through the data receiving module 3.1.3, where all the details of the input fields are filled in, to the control module 3.1.4, where the control is carried out on the completeness and correctness of filling in the input forms.

Block 3.1 of collecting and issuing information is based on the description of the created local database (LBD). Such a description is stored in block 3.2 of the local database version descriptions in the form of a relationship system, which includes: Table of tables; Table of table fields; Table index tables; Table of index fields of tables; Table links tables; Table of table link fields.

Data from the unit 3.1 for collecting and issuing information is fed to the input of the unit 3.4 for storing and arching information, where using the control module 3.4.1, control is carried out on the compliance of the data storage structures with the entered data. Then, the monitored data goes to the input of the module 3.4.2 of storage and data archives, in which, depending on the storage organization (server or file-server organization of the storage module) and in accordance with the version of the local database, they are stored on the respective storage media. In addition to the actual data transferred to this module, a description of the database version is also stored, as well as the previous state of the database at the time of the last synchronization.

All actions related to changing the database data and database descriptions are carried out in transaction execution block 3.3. All procedures that lead to a change in the database go to the input of this block and are logged, namely, the called procedures and their parameters are logged, as well as the contents of the worksheets received from the client and used by the procedure during execution.

After the synchronization process, the data is updated in block 3.4 storage and data arch. Data compilation is carried out at the level of the main managers of budgetary funds in accordance with their role in the technological process. At the output of block 3.4, in accordance with the rights of a registered user, output results are generated, which are input to the control module 3.1.4 of the block 3.1 for collecting and issuing information, and then are output to paper and electronic media in the form of reports or viewing forms (processing of non-regulatory requests) .

Block 4 of the interaction of the meta-information database and the database (Figure 4) is made in the form of a database information storage unit 4.1, connected by two-way communication with the metabase information storage unit 4.2, including the metadata input module 4.2.1 and the meta-information database 4.2.2 directly.

The input of this block 4 receives data from block 2 for input, registration and storage of objects and information of the central database, block 6 for filtering data and block 3 for input, registration and approval, processing and collection of information from remote users.

This block provides the process of interaction between two databases, namely, the database 4.2.2 meta-information, providing operations for the formation of data descriptions of this database and their changes, and the central 2.1.3 or local 2.1.4 databases that provide storage and change the actual data described in the metabase.

The output data of the corresponding form from block 4 are then transferred to block 5 for optimizing the execution of ad hoc requests, a data filtering unit 6, and an ad hoc information presentation unit 7.

Block 5 for optimizing the execution of non-regulatory requests (Fig. 5) contains a block 5.1 for returning the number of records, including a query execution module 5.1.1 and a module 5.1.2 for returning the number of records, and a result output block 5.2 connected to its output, including a module connected in series 5.2.1 execution of the request and module 5.2.2 return records.

Block 5 carries out optimization when executing generated queries.

Execution of requests takes place in two stages. First, in block 5.1 of the return of the number of records, a query is executed that returns the number of records in the result set. If this quantity exceeds the limit set by the user or the default, then a message is displayed on the number of records that will be sent as a result of the request. This mechanism is necessary due to the fact that it is very easy to set such query parameters that will lead to very large traffic when working with large amounts of data.

Next, in block 5.2 of the result, the query is executed and the result is issued. Queries before execution are converted to the syntax of the version of SQL that the corresponding processing environment supports (currently there are two such syntaxes - MS JET SQL syntax, Transact SQL syntax).

During the optimization process, you can delete intersection operations from the query with those tables whose fields do not participate in the result set or selection, and they are not needed for subsequent intersection operations. If the intersection task with any table limits the actual result set itself, that is, the table must necessarily participate in the resulting query, then you can describe some required field from this table that is not output to the form or report, and then

the desired intersection will always be included in the result set. Another important point in the functioning of this block is the fact that the inclusion of some intersections in the result set is also necessary due to the fact that it restricts the reproduction of records at intersections on relations of type m to n.

Block 6 data filtering (Fig.6) is made in the form of series-connected block 6.1 forming the ranges of values, block 6.2 building lists, block 6.3 switches and block 6.4 dynamic change request.

The input of this block receives data from the block 5 for optimizing the execution of ad hoc requests, and the output generates data for the block 7 for presenting information of ad hoc requests and the unit 4 for interaction between the meta-information database and the database.

In block 6, the formation of a system of filters is ensured, which ensures the execution of queries to the database to provide it in the form of objects formed in block 7 of the presentation of information of unregulated queries.

Data filtering is carried out in the model according to the fields of the first category (see explanations to block 7 for the submission of information for non-regulatory requests). A filter job in the general case can be represented as a job of n ranges of values for each of the fields connected by “or”, and the filters by different fields are combined by “and”. At the same time, lists of values for the beginning and end of ranges can also be built on a query that is generated similarly to a query for a selection, only the list of selectable fields must contain a filtering field, and it is also a grouping field. In addition to the filter field, other fields may be present in the filter list request. But these fields must be fields of the second category. When sequentially setting filters, you can dynamically change the query, substituting the already defined filter values in the query for filter formation. Requests for building lists for filters should include the intersection of all tables of the subcircuit (the intersection limits the list of possible values), and one of the possible filtering values may be the absence of a value. The execution of such queries when specifying some filters is quite resource-intensive, and therefore rather slow. It is possible to set filters without building lists of values

Block 7 of the presentation of information of non-regulatory requests (Fig.7) is made in the form of block 7.1 filtering and grouping, to the output of which is connected block 7.2

aggregation, including sequentially connected module 7.2.1 tables, module 7.2.2 reports and module 7.2.3 sorting.

The input of this block receives data from the data filtering unit 6, the meta-information base and database interaction unit 4, and the input form parametric call block 9.

Aggregation block 7.2 includes a module 7.2.1 of tables and a module 7.2.2 of reports. This is determined by the fact that there are different views on the fragments of the general data model that are associated with the totality of the functional complexes of the system. The functioning of the block 7 for the submission of information of non-regulatory requests is generally directed, firstly, to search for documents, and secondly, to the formation of derived values on filtered aggregates of grouped data. The above views from the point of view of the system are called views. Each view from the interface point of view is a combination of a tabular form and a similar report.

The set and sequence of objects (fields) displayed in the form is not fixed, but is selected arbitrarily from the set of fields that are possible on the query class implemented on the corresponding subcircuit. Fields are divided into two categories: those fields by the values of which filtering and grouping are possible, and the values of which, when displayed, will correspond to the selected ones, and those by which it is impossible, since they are fields using functions such as aggregation (sum, average, minimum, maximum, etc.), and filtering by the initial values of which will not correspond to the output results. We believe that it is always possible to group according to the fields of the first category and always apply the corresponding aggregation function for the fields of the second category. That is, the choice of the list of objects (fields) determines not only the list of fields in the request, but also its grouping. If you connect the fields with the corresponding objects (tables) from the fields of which they are selected, and have a description of the relationships between the tables, then specifying a list of fields allows you to build a query for the selection with the necessary table intersections and grouping. At the same time, setting the sequence of displayed fields allows the creation and formatting of form and report elements.

The final step in the presentation of information is the sorting of data in the resulting query, which is carried out for all selected fields, starting from the selected and ending with the field preceding the specified one. Moreover, when the field is first indicated, it is performed in ascending order, and in the second, in descending order.

The sorting task initiates the mechanism of the final formation and execution of the request.

Block 8 for uploading the results of non-regulatory requests (Fig. 9) contains a reporting unit 8.1, to the output of which a file exporting unit 8.2 is connected, and performs the function of an output terminal, i.e. provides the provision of information on non-regulatory requests in the form of files.

To the input of this block, data is transferred from the block 7 for the submission of information of non-regulatory requests, namely, the resulting data set in the form of a viewing, in relation to which further user actions can be performed. In particular, in block 8.1 of generating reports, a report can be generated and printed, the name of which, like the names of the columns, can be specified arbitrarily or by default.

The result set through export block 8.2 can be exported to a file, for example, MS EXCEL or to any format for which there are ISAM drivers on the workstation. In addition, the generated reports can also be exported through the export block 8.2 to any format for which ISAM drivers are available on the workstation.

Block 9 parametric call input form (Figure 10)

To the input of this block, the data of the Block for the submission of information of non-regulatory requests are transferred - the result set in the viewing form.

From the viewing form, a data adjustment form can be loaded with substitution as arguments for opening the values of the fields that are marked as parameters. The implementation of such a mechanism allows for a direct transition to a specific information object of the system (document). To do this, you must use the switches that specify either a one-to-one correspondence between the viewing form and the correction form, or indirect. When using the second type of switches, a form is first opened that determines, by parameters, which form of adjustment and with which parameters to open.

The following is an example of how the system works when performing one of the ad hoc queries.

Suppose a system user needs to receive information about payment orders for a specific date interval (for example, for a month), display information in a grouped by necessary parameters on the monitor screen,

and then upload the result to an external system, for example, to a file with the extension .xls.

Initial information on payment orders is entered in block 2 for the local network user or in block 3 for the remote user. In block 2.2, information on payment orders is entered and registered. This information is transmitted and stored in block 2.1. After that, from the output of block 2, information about payment orders falls into block 4 on its block 4.2.

From the user, in block 7, the input of block 7.1 receives information containing filter fields and fields by which information is grouped (request). Upon the first output, the request is transmitted to block 4 to the input of the metabase information storage block 4.2. From block 4, the query falls into block 1, which contains meta-information that describes, using block 1.1, the identifier of the queries, using block 1.2, the identifier of the tables, block 1.3, the identifier of alias tables, block 1.4, the identifier of global selection conditions, and in block 1.5, the order of generating the request subcircuit, in block 1.6 — the identifier of the query fields, in 1.7 — the identifier of the relationships of the fields with the tables, in 1.8 — the identifier of the view forms, in 1.9 — the identifier of the form fields, in 1.10 — the identifier of the filter fields.

From block 1, the request is returned to block 4 to device 4.2, then in block 5 the query execution is optimized first in block 5.1, which returns the number of records in the result set, and then in block 5.2 of the result.

From block 5, the request is transmitted to block 6 to the input of block 6.1 to form a range of values of the selected data about payment orders, to block 6.2 - to build lists, to block 6.3 of switches to ensure the formation of a range of values of selected data from the constructed lists or, for a large amount data, without building lists, in block 6.4 - for dynamically changing a request. From block 6, the request returns to block 4 to the input of block 4.2, where, upon a given request, information is selected from the database.

Further, from block 4, information about payment orders goes to block 7 at the input of its block 7.2, and from block 6, the request goes to block 7 to block 7.1 of filtering and grouping. The resulting data set (information on payment orders) can be transferred at the request of the user to block 8 of the unloading of the results of non-regulatory requests, for example, to a file with the extension .xls, .doc, etc.

From block 7, the signal can also be transmitted to block 9, where the data entry form can be loaded with substitution as arguments

opening field values that are marked as parameters. The implementation of such a mechanism allows for a direct transition to a specific information object of the system (payment order).

The advantages of the claimed system of non-regulatory database queries over the prototype and other devices of similar purpose are as follows:

- Provides the rapid formation of arbitrary user requests to the database for arbitrary parameters;

- A variety of presentation forms of data selected upon request is provided, namely, in the form of views, reports, files, etc .;

- Provides the ability to sort query results;

- It is possible to display the name of the filter on the basis of which the output data set is generated, as well as the job of the name of the report;

- Provides the ability to quickly generate reports in a user-friendly context;

- It is possible to save query parameters (filters) for their subsequent use without re-setting.

Thus, the claimed system of non-regulatory requests to the AISBP database contributed to the creation of a new automated technology for managing the budget process with the treasury method of execution at the regional level (the level of the subject of the Russian Federation and the municipality).

Claims (9)

1. A system for providing non-regulatory requests for an automated control system, including a unit for input, registration, approval, processing and compilation of information of remote users and a unit for input, registration and storage of objects and information of a central database, characterized in that it is additionally equipped with an input, registration unit and storing meta-information and the interaction unit of the meta-information database and the database connected to each of the above blocks by two-way communication, as well as the optimization unit is executed I have ad-hoc queries, the input of which is connected to the interaction block of the meta-information database and the database, a data filtering unit, an ad-hoc request presentation unit, an ad hoc query output unit, and an input form parametric invocation unit, the first output of an ad-hoc execution optimization unit being connected to a filtering unit data, and its second output - with one of the inputs of the block for the presentation of information of unregulated requests, the data filtering block and the block are presented The information of the non-regulatory requests is connected by each two-way communication with the interaction block of the meta-information base, the output of the data filtering unit is connected to the second input of the block of the information of non-regulatory requests, the second output of which, in turn, is connected to the input of the block of unloading the results of non-regular requests, and its third output is connected two-way communication with the parametric call block of the input form. 2. The system according to claim 1, characterized in that the input, registration and storage unit of meta-information includes a block of request identifiers, a block of table identifiers and a block of identifiers of table aliases, as well as a block of identifiers of global selection conditions and a block for generating a subscheme of the request, the outputs of which are connected simultaneously to the inputs of the block of request identifiers and the block of table identifiers; a query field identifier block and a field link table identifier block connected by a two-way communication, the outputs of the latter being connected to the corresponding inputs of the query identifier block and the table identifier block; a block of identifiers of viewing forms, a block of identifiers of fields of forms, and a block of identifiers of fields of filters, sequentially connected by a two-way communication, the output of a block of identifiers of fields of forms being connected to the input of a block of identifiers of request. 3. The system according to claim 1, characterized in that the unit for input, registration and storage of objects and information of the central database is made in the form of a unit for storing objects and information, including a control module and a data storage module connected by two-way communication, also containing a central and local database data connected to the output of the unit for input and registration of objects and information, including a sequentially connected module for registering objects and information, an input module for objects and information, a data receiving module and a control module I am. 4. The system according to claim 1, characterized in that the unit of interaction of the meta-information database and the database is made in the form of a database information storage unit associated with two-way communication with a metabase information storage unit, including a metadata input module and a meta-information database. 5. The system according to claim 1, characterized in that the unit for optimizing the execution of non-regulatory requests is made in the form of a unit for returning the number of records, including a query execution module and a module for returning the number of records connected in series, and a result output unit connected to its output, including a module connected in series query execution and module return records. 6. The system according to claim 1, characterized in that the data filtering unit is made in the form of series-connected value range forming unit, list building unit, switch unit and dynamic request change unit. 7. The system according to claim 1, characterized in that the unit for the submission of information of unregulated requests is made in the form of a filtering and grouping unit, to the output of which an aggregation unit is connected, including a series-connected table module, a report module, and a sorting module. 8. The system according to claim 1, characterized in that the unit for input, registration, approval, processing and compilation of information of remote users is made in the form of series-connected by two-way communication unit for collecting and issuing information, including serially connected registration module, data input module, reception module data and a control module, a version description block of a local database, a transaction execution unit, and a storage and information storage unit including a storage module and a control module. 9. The system according to claim 1, characterized in that the block for unloading the results of unregulated requests is made in the form of a reporting unit, to the output of which an export unit is connected.