# Study on Effective Temporal Data Retrieval Leveraging Complex Indexed Architecture
## 3 Transaction Support and Integrity
### Extended Temporal Log Ahead Rule (ETLAR)--The Proposed Extension  
In this paper, we propose an extended solution for the TLAR covering the particular data model, as well. Thus, in the first phase, data are logged regardless of the constraints. Thanks to which all changes are preserved, regardless of their correctness and applicability. Secondly, state overlapping is detected, covered by the TLAR, as well. As stated, any object can be defined by just one state anytime. The third phase evaluates the data model. The data model can evolve by extending, adding, or dropping existing constraints. Data attributes and integrity can be enhanced, as well. Thus, each database element is determined by the activity time frame, to which it belongs. Data model image is then composed as applying all data model segments, which are valid in the defined time positions. In conventional systems, the Two-Phase Commit protocol ensuring transaction durability and whole process reliability is used [10; 11]. It is based on the logging, by which any data portion should be placed in the logs before the change itself. For the temporal environment, log management was extended by collision detection and management forming the Three-Phase Commit protocol. In this paper, we propose Four-Phase Commit protocol (4 PCP) to manage the data model covering, as well. Figure 8 shows the data flow. The first step is associated with the transaction logging in the autonomous transaction, thus even after the main transaction refuse, objects are present in the temporal layer, however, just with the User rollback flag. Afterward, consistency reflecting the data model is measured. If the new state temporality reflects state immediately valid, respectively data correction to the historical data images, \"AS-IS\", respectively \"AS-WAS\" model can be used, reflecting the data model valid in the defined time point or interval. Transaction control can evaluate, whether the states fulfill all the requirements and all constraints are passed, even if multiple data models are valid during the time interval. Dealing with future valid data is, however, far more complicated. First of all, the \"AS-IS\" approach cannot be used, whereas it must reflect conditions in the objective time frame denoted by the validity. In ideal conditions, the particular data model is available, thus the transaction can evaluate and reflect either data model, as well as all constraints. Thus, the \"AS WILL BE\" delimitation can be done. Vice versa, if the data model is not defined for that moment or time frame, evaluation cannot be done, transaction control cannot manage constraints, at all. In that case, the transaction has ended successfully and constraint management is shifted to the time, the data model is present and properly defined. By specifying a new data model or changing environment, the original transaction can be reopened to notify the data model. As the result, the originally conditionally approved transaction is reevaluated. Naturally, dependent objects can be identified in other transactions, thus the constraint checking does not need to cover only one transaction, however, the transaction chain can be necessary to be reevaluated. The temporal layer comes to the solution of the problem, which covers all the changes, even refused or corrected. By referencing time and transaction pointers, it is always possible to ensure data correctness and consistency, if any metadata characterizing conditions or environment is changed. Figure 8 shows the evaluation data flow in the UML diagram. The first phase is delimited by the logging until reaching the Ready to Log (RL) data point. The second phase deals with collision management. State overlapping is managed regarding the defined rules. The transaction timeline is bordered by the Ready to Transaction Collision (RT) point. Data model reflection checking is done in the third phase, ensuring that all constraints will be passed in the future valid model, if available. It is delimited by the Ready to Model (RM) point.