The next element implemented in the system is the block of work with the database. This subsystem is necessary in order to be able to evaluate the dynamics of the system and check the stability of the work. Moreover, when new models appear in the system, you can run tests on old data to compare the results on a specific data set. The structure of the Database is dictated by the purposes for which it is used. It stores data about all industries and all stocks of the company, as well as about all the models and performance criteria that are used in the system, and all the tests that were carried out in the system. All these tables are reference books. As for the measurement tables, the database contains the initial data for each test for each stock, as well as the results for all models for all criteria for each test (see Figure 6).
Figure 6. Database schema. The database has seven entities that allow you to store data as conveniently as possible, as well as interact with them: Industries - industries - this entity includes all industries according to the Global Standard for the Classification of Industries. Company_Stocks - company stocks - this entity includes the names of company stocks and their interpretation. Raw_Data - raw data - this entity includes the data on which the tests were carried out for each stock. Test - test - an entity that reflects all tests conducted on the model Effectiveness_Parameters - performance parameters - an entity that describes all system parameters that are used to evaluate the efficiency and quality of the built models. Model - model - an entity that describes all the models that are used in building this system.
Test_Result - test results - an entity that reflects the values of performance parameters for a given model for a particular test. Each entity has attributes that allow you to describe the stored data as fully as possible (Table 1). Table 1. Entities and attributes of the database. which should be taken into account when building a model All entities implemented in the database are interconnected: Industries - Company_Stocks - one to many - this relationship reflects that each company whose shares are traded on the stock market belongs to one industry and only one. Company_Stock - Raw Data - one to many - this relationship reflects that for a certain value of time, certain values of price indicators can belong to only one stock. One stock has many dimensions - as many as the number of days this stock has been traded on the market.
Whereas one dimension belongs to only one particular stock. Model - Test_Result - one to many - there can be multiple test results for one model, but one test result cannot apply to multiple models. Effectiveness_parametrs - Test_Result - one to many - there can be multiple values for one efficiency parameter, while several efficiency parameters cannot have the same value. Test - Test_Result - one to many - this relationship shows that one test can have many results, while one record belongs to only one test. Test - Raw_Data - one-to-many - all uploaded data relate to one or another test. This is done in order to be able to understand on what data this or that result was obtained. In order to interact with the database, a number of queries have been implemented that can be dividedinto three categories.
The first category of requests are requests to display information to familiarize yourself with the system. This system requires two queries: the first query should reflect all the shares that exist in the system and the industry to which the companies whose shares are entered in the system belong; the second query should reflect the analytical part, namely, the output of models and performance criteria that are used in this database. The second category of requests are requests that are responsible for data administration, namely for adding, because. it is necessary to store all the data on which the tests were carried out and all the models that were used. Add requests must be implemented for all tables, namely stocks, industries, tests, raw data, performance parameters, models, and performance parameters results for each model. The third category is directly related to evaluating the effectiveness of models. Queries of this category check models for stability in dynamics.
Also, these queries allow you to compare models with each other in terms of stability and parameter values. The database block algorithm is divided directly into two components. The first part processes raw data, the second part is related to evaluating the effectiveness of models. The algorithm of the first part is initiated after the request block and data processing. After receiving data from the site, a record of a new test is created, then the stock is checked for in the system. If the stock is new, the system adds it to the database. Then all the data downloaded from the site is written to the raw data table (see Figure 7) Figure 7.
The first part of the algorithm for working with the database. The algorithm of the second part is initiated after the completion of the analysis and tests. First, the presence of models in the database is checked. If there is no record of the presence of the model, the process of adding a record of the model occurs. Then the efficiency parameter is checked and then added. If all of these checks are successful, the value of the results is added to the database, and then the stability scores for each model are output. (See Figure 8) Figure 8.
The second part of the database block algorithm.