# Semi-Automated Approach for Building Event Logs for Process Mining from Relational Database
## 4 Results
### Requirements Identification Stage  
#### 4.1.1 Data Interpretation Analysis  
The analysis of the schema database schema (DB) of the air quality monitoring system allowed us to identify and interpret the data stored in its tables. The database is made up of 12 tables distributed as follows (see Figure 2):* Five tables store values of the data collected by the sensors that make up the air quality monitoring system.
* Three tables support the operation of various web services that manage data transfer between the system that collects them and their storage in the cloud.
* Four tables that support embedded functionalities of various software components that work collaboratively within the air quality monitoring system.  
The main table _data_infosensors_ stores data on the place, date, and time of values collection. In addition, it is related to four reference tables (_data_O3_, _data_CO_CO2_, _data_PM_, and _data_MF_) that store the collected values of pollution by gases and particles, as well as meteorological factors. These tables are referenced by the foreign key (FK) _id_infosensors_ with the _data_infosensors_ table. This table has a relationship with the _web_service_t table since it acts as the main table. _Web service_C has the functionality to receive, transmit, and insert the data collected by the sensors. It coordinates with a _repository management service_ to validate and process the data received. These activities are deployed in the business process as service and script tasks, supplemented with exclusive gateways and returns to previous activities. Subsequently, the processed data are returned to the _Web service_C to perform the insertion in the corresponding tables. Secondary tables are related to the main table using the FK _IdProcess3_.  
The _IoT_AirQuality_Monitor_Access_ and _IoT_AirQuality_Monitor_Collector_ tables store data from the business process flow of a single participant. At the design time of the information system, it was decided to store them in different tables due to the context of the data. The table _IoT_AirQuality_Monitor_Access_ stores information on the validation of the operation of the sensors, request for IP address assignment, and access requests to the cloud storage system. These activities are done through various service tasks that process, execute, and validate data to make decisions about the business process flow through exclusive gateways. The tasks' status, date and time of execution, and the data exchanged  
Figure 2: The entity-relationship diagram of the IoT air quality information system database.  
are stored in the _IoT_AirQuality_Monitor_Access_ table. The software system access requests are coordinated by the _Web service A_, with which there is a relationship through the FK _IdProcess_. On the other hand, in the _IoT_AirQuality_Monitor_Collector_ table, information about data collection, validation, and sending of the collected values to _web_service_a_ is stored through a relationship between tables with the FK _IdProcess_. This part of the business process is executed by automatic service and business rule tasks that enable data collection, validation, and sending. Moreover, the actions carried out during the business process execution, the date was executed, and the resources sent or received in each completed task are saved.  
Finally, in the _system_access_service_ table, information is stored on the access requests to the cloud storage system accepted or rejected and on the assignment of IP to each monitoring station equipment. These actions were modeled in the business process as automatic service tasks that process and evaluate requests, generate system access agreements or rejections, and assign valid IP addresses to monitoring stations. Values of the unique identifier (primary key, PK), the status of the executed task, the date of execution, and the data exchanged with _Web service B_ are stored in this table. This service supports management with the _system_access_service_ table through a relationship defined in the FK _IdProcess2_.